2.?HTTP版本之概念篇
HTTP（超文本傳輸協(xié)議),是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議，定義了瀏覽器怎樣向服務(wù)器請求文檔，以及服務(wù)器怎樣把文檔傳送給瀏覽器。HTTP基于TCP/IP協(xié)議的應(yīng)用層協(xié)議，它不涉及數(shù)據(jù)包傳輸，主要規(guī)定了客戶端和服務(wù)器之間的通信格式，默認(rèn)使用80端口。
HTTP/0.9版本篇
要點
客戶端向服務(wù)器請求網(wǎng)頁，服務(wù)器只能回應(yīng)HTML格式的字符串，不能回應(yīng)別的格式。
只有GET方式
服務(wù)器發(fā)送完畢。就關(guān)閉TCP連接
缺點
每個TCP連接只能發(fā)送一個請求;發(fā)送數(shù)據(jù)完畢，連接就關(guān)閉，如果還要請求其他資源，就必須再新建一個連接
TCP連接的新建成本很高，因為需要客戶端和服務(wù)器三次握手，并且開始時發(fā)送速率較慢
網(wǎng)頁加載的外部資源越多，性能就越差
只有一種請求方式
HTTP/1.0版本篇
要點
任何格式的內(nèi)容都可以發(fā)送?；ヂ?lián)網(wǎng)不僅可以傳輸文字，還可以傳輸圖像，視頻，二進(jìn)制文件。（由于發(fā)送的數(shù)據(jù)可以是任何格式，因此可以把數(shù)據(jù)壓縮后再發(fā)送。CONTENT-ENCODING字段說明數(shù)據(jù)壓縮的方法
壓縮的方式有（可以并列多個，用逗號隔開）：CONTENT-ENCODING:GZIPCONTENT-ENCODING:COMPRESSCONTENT-ENCODING:DEATE
除了GET命令，還引入POST命令和HEAD命令，豐富了瀏覽器與服務(wù)器的互動手段。
HTTP請求和回應(yīng)格式發(fā)生改變，除了數(shù)據(jù)部分，每次通信都包括頭部分，用來描述數(shù)據(jù)，
新增的功能還包括：狀態(tài)碼(STATUS CODE)，多字符集支持，多部分發(fā)送(MULTI-PART TYPE)，權(quán)限(ANTHORIZATION)，緩存(CACHE)，內(nèi)容編碼(CONTENT ENCODING)等
HTTP/1.0請求的例子：
GET/HTTP/1.0 USER-AGENT:MOZILLA/5.0(MACINTOSH;INTEL MAC OS X 10_10_5 ) ACCEPT:*/*第一行為請求命令,必須在尾部添加協(xié)議版本(HTTP/1.0)
后面為多行頭信息，描述客戶端情況
HTTP/1.0回應(yīng)的例子：
HTTP/1.0 200 OK? ? ? ? ? ? ? /*協(xié)議版本+狀態(tài)碼+狀態(tài)描述*/CONTENT-TYPE: TEXT/PLAIN? CONTENT-LENGTH: 137582EXPIRES: THU, 05 DEC 1997 16:00:00 GMTLAST-MODIFIED: WED, 5 AUGUST 1996 15:55:28 GMTSERVER: APACHE 0.84
<HTML>
? <BODY>HELLO WORLD</BODY>
</HTML>
CONTENT-TYPE:字符編碼，HTTP 1.0規(guī)定 頭部必須是ASCII碼，后面可以是任何格式，
因此，服務(wù)器回應(yīng)時，CONTENT-TYPE的作用是：告訴客戶端，數(shù)據(jù)是什么格式
缺點
非持續(xù)連接：每個TCP連接只能發(fā)送一個請求，每請求一個文檔就需要兩倍的RTT往返時間開銷(一個RTT用于連接TCP連接，另一個用于請求和接收文檔)。
如圖所示：當(dāng)HTTP協(xié)議首先要與服務(wù)器建立TCP連接，這就需要三次握手。當(dāng)三次握手的前兩部分完成后(即經(jīng)過一個RTT時間后)，萬維網(wǎng)客戶就把HTTP請求報文作為第三次握手的第三個報文的數(shù)據(jù)發(fā)送給萬維網(wǎng)服務(wù)器，服務(wù)器收到HTTP報文后，就把所請求的文檔作為響應(yīng)報文返回給客戶。
發(fā)送數(shù)據(jù)完畢，連接就關(guān)閉，如果還要請求其他資源，就必須再新建一個連接。
TCP連接的新建成本很高，因為需要客戶端和服務(wù)器三次握手，并且開始時發(fā)送速率較慢。（為了解決這個問題：有些瀏覽器在請求時，用了一個非標(biāo)準(zhǔn)的CONNECTION字段。即CONNECTION:KEEP-ALIVE請求服務(wù)器不要關(guān)閉TCP連接，以便其他請求復(fù)用，服務(wù)器同樣回復(fù)這個字段；以實現(xiàn)TCP的復(fù)用，直到客戶端或服務(wù)器主動關(guān)閉連接，但，這不是標(biāo)準(zhǔn)字段，不同實現(xiàn)的行為可能不一致，因此不是根本的解決辦法。
網(wǎng)頁加載的外部資源越多，性能就越差。
5. HTTP/1.1版本篇
要點
引入了持久連接(PERSISITENT CONNECTION),即TCP連接默認(rèn)不關(guān)閉，可以被多個請求復(fù)用，不用聲明（簡單的說：就是服務(wù)器在發(fā)送響應(yīng)后仍熱在一段時間內(nèi)保持這條連接，使同一個用戶（瀏覽器）和該服務(wù)器可以繼續(xù)在這條連接上傳送后續(xù)的HTTP請求報文和響應(yīng)報文）。CONNECTION:KEEP-ALIVE客戶端和服務(wù)器發(fā)現(xiàn)對方一段時間沒有活動，就可以主動關(guān)閉連接。不過，規(guī)范的做法是，客戶端在最后一個請求時明確要求服務(wù)器關(guān)閉TCP連接。CONNECTION:CLOSE
目前，對于同一個域名，大多數(shù)瀏覽器允許同時建立6個持久連接。
引入了管道機(jī)制，即在同一個TCP連接里面，客戶端可以同時發(fā)送多個請求。（提高HTTP協(xié)議的效率）；舉例說明：客戶端需要請求兩個資源，HTTP1.0是在同一個TCP連接里面，先發(fā)送A請求，然后等待服務(wù)器做出回應(yīng)，收到后再發(fā)送B請求；管道機(jī)制是允許瀏覽器同時發(fā)生A請求和B請求，但是服務(wù)器還是按照順序，先回應(yīng)A請求，完成后再回應(yīng)B請求
一個TCP連接可以傳送多個回應(yīng)，勢必要有機(jī)制，區(qū)分?jǐn)?shù)據(jù)包是屬于哪一個回應(yīng)的。這就是CONTENT-LENGTH字段的作用，聲明本次回應(yīng)的數(shù)據(jù)長度。
CONTENT-LENGTH:3495告訴瀏覽器本次回應(yīng)的長度是3495個字節(jié)，后面的字節(jié)就屬于下一個回應(yīng)
分塊傳輸編碼；HTTP1.1采用分塊傳輸編碼；使用CONTENT-LENGTH字段的前提是服務(wù)器發(fā)送回應(yīng)之前，必須知道回應(yīng)數(shù)據(jù)的長度。但對于一些耗時的動態(tài)操作來說，這意味著，服務(wù)器要等所有操作完成，才能發(fā)送數(shù)據(jù)，顯然效率不高，更好的處理方式是：服務(wù)器每產(chǎn)生一塊數(shù)據(jù)，就發(fā)送一塊，采用“流模式（STREAM）”取代“緩存模式(BUFFER)”.因此1.1版規(guī)定可以不使用CONTENT-LENGTH字段，而使用“分塊傳輸編碼”，只要請求或回應(yīng)的頭信息有TRANSFER-ENCODING字段，就表明回應(yīng)的數(shù)據(jù)將由數(shù)量未定的數(shù)據(jù)塊組成。TRANSFER-ENCODING:CHUNKED?每個非空的數(shù)據(jù)塊之前，會有16進(jìn)制的數(shù)值，表示這個塊的長度，最后是一個大小為0的塊，就表示本次回應(yīng)的數(shù)據(jù)發(fā)送完。
Eg:
HTTP/1.1 200 OKCONTENT-TYPE: TEXT/PLAINTRANSFER-ENCODING: CHUNKED
25
THIS IS THE DATA IN THE FIRST CHUNK
1CAND THIS IS THE SECOND ONE
3
CON
8
SEQUENCE
0
** 新增功能**：PUT,PATCH,HEAD,OPTIONS,DELECT. 客戶端的頭信息增加HOST字段，用來指定服務(wù)器的域名。?HOST:WWW.EXAMPLE.COM?有了HOST字段，就可以將請求發(fā)往同一臺服務(wù)器的不同的網(wǎng)站，為虛擬主機(jī)的新起打下了基礎(chǔ)。
缺點
雖然復(fù)用TCP連接，但是在同一個TCP連接里面，所有的數(shù)據(jù)通信都是按照次序進(jìn)行的。服務(wù)器只有處理完一個回應(yīng)，才能進(jìn)行下一個回應(yīng)。(解決辦法：A. 減少HTTP請求數(shù);B:同時多開持久連接)
6. HTTP/2版本篇
要點
采用二進(jìn)制協(xié)議：HTTP/1.1的頭信息是文本（ASCII編碼），數(shù)據(jù)體可以是文本（解析非常麻煩），也可以是二進(jìn)制。而HTTP/2則是一個徹底的二進(jìn)制協(xié)議，頭信息和數(shù)據(jù)體都是二進(jìn)制，通稱為“幀”（FRAME）:頭信息幀和數(shù)據(jù)幀。二進(jìn)制協(xié)議的一個好處是：可以定義額外的幀，解析方便。
多路復(fù)用(雙向，實時的通信)：HTTP/2復(fù)用TCP連接，在一個連接里，客戶端和服務(wù)端都可以同時發(fā)送多個請求或回應(yīng)，而不用按照順序一一對應(yīng)，這樣就避免“隊頭阻塞”。舉例來說：在一個TCP連接里面，服務(wù)器同時收到A請求和B請求，先回應(yīng)A請求，結(jié)果發(fā)現(xiàn)處理過程非常耗時，于是就發(fā)送A請求已經(jīng)處理好的部分，接著回應(yīng)B請求，完成后，才發(fā)送B請求剩下的部分。
數(shù)據(jù)流：HTTP/2的數(shù)據(jù)流是不按順序發(fā)送的，同一個連接里面連續(xù)的數(shù)據(jù)包，可能屬于不同的回應(yīng)。因此必須要對數(shù)據(jù)包標(biāo)記，指出它屬于哪個回應(yīng)。HTTP/2將每一個請求或回應(yīng)的所有數(shù)據(jù)包，稱為一個數(shù)據(jù)流。每個數(shù)據(jù)流都有一個獨一無二的編號。數(shù)據(jù)包發(fā)送時，都必須標(biāo)記數(shù)據(jù)流ID，用于區(qū)分它屬于哪一個數(shù)據(jù)流，另外規(guī)定：客戶端發(fā)出的數(shù)據(jù)流，ID一律為奇數(shù)，服務(wù)器發(fā)出的，ID為偶數(shù)。數(shù)據(jù)流發(fā)送一半時，客戶端和服務(wù)器都可以發(fā)送信號，取消這個數(shù)據(jù)流。即HTTP/2可以取消某一個請求，同時保證TCP連接還開著，可以被其他請求使用?？蛻舳诉€可以指定數(shù)據(jù)流的優(yōu)先級，優(yōu)先級越高，服務(wù)器就越早回應(yīng)。
頭信息壓縮：HTTP2以前的版本協(xié)議不帶有狀態(tài)，每次請求都必須附上所有的信息。所以，請求的很多字段都是重復(fù)的，比如COOKIE和USER AGENT,一模一樣的內(nèi)容，每次請求都必須附帶，這很浪費很多寬帶，也影響速度。HTTP/2優(yōu)化了這一點。引入了頭信息壓縮機(jī)制。一方面：頭信息使用GZIP或COMPRESS壓縮后再發(fā)送，另一方面，客戶端和服務(wù)端同時維護(hù)一張頭信息表，所有字段都會存入這個表，生成一個索引號，以后就不發(fā)送同樣字段，只發(fā)送索引號，提高速度。
服務(wù)器推送：HTTP/2允許服務(wù)器未經(jīng)請求，主動向客戶端發(fā)送資源-->服務(wù)器推送。eg:客戶端請求一個網(wǎng)頁，這個網(wǎng)頁里面包含靜態(tài)資源。正常情況下，客戶端必須收到網(wǎng)頁后，解析HTML源碼，發(fā)現(xiàn)有靜態(tài)資源，再發(fā)送靜態(tài)資源請求；其實，服務(wù)器可以預(yù)期到客戶端請求網(wǎng)頁后，很可能再請求靜態(tài)資源，所以主動把這些靜態(tài)資源隨網(wǎng)頁一起發(fā)給客戶端。
缺點
請求太多時也需要排隊
7. HTTPS版本篇
要點
HTTPS 是以安全為目標(biāo)的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細(xì)內(nèi)容就需要SSL
HTTPS協(xié)議的主要作用是：建立一個信息安全通道，來確保數(shù)組的傳輸，確保網(wǎng)站的真實性
HTTPS的SSL加密是在傳輸層實現(xiàn)的
工作原理
客戶使用HTTPS URL訪問服務(wù)器，則要求WEB 服務(wù)器建立SSL鏈接。
WEB服務(wù)器接收到客戶端的請求之后，會將網(wǎng)站的證書（證書中包含了公鑰），返回或者說傳輸給客戶端。
客戶端和WEB服務(wù)器端開始協(xié)商SSL鏈接的安全等級，也就是加密等級。
客戶端瀏覽器通過雙方協(xié)商一致的安全等級，建立會話密鑰，然后通過網(wǎng)站的公鑰來加密會話密鑰，并傳送給網(wǎng)站。
WEB服務(wù)器通過自己的私鑰解密出會話密鑰。
WEB服務(wù)器通過會話密鑰加密與客戶端之間的通信。
優(yōu)點
使用HTTPS協(xié)議可認(rèn)證用戶和服務(wù)器，確保數(shù)據(jù)發(fā)送到正確的客戶機(jī)和服務(wù)器
HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，要比HTTP協(xié)議安全，可防止數(shù)據(jù)在傳輸過程中不被竊取、改變，確保數(shù)據(jù)的完整性。
HTTPS是現(xiàn)行架構(gòu)下最安全的解決方案，雖然不是絕對安全，但它大幅增加了中間人攻擊的成本。
缺點
HTTPS握手階段比較費時，會使頁面加載時間延長50%，增加10%~20%的耗電。
HTTPS緩存不如HTTP高效，會增加數(shù)據(jù)開銷。
SSL證書也需要錢，功能越強(qiáng)大的證書費用越高。
SSL證書需要綁定IP，不能再同一個IP上綁定多個域名，IPV4資源支持不了這種消耗。
HTTP和HTTPS的區(qū)別
HTTPS協(xié)議需要證書，費用較高。
HTTP是超文本傳輸協(xié)議，傳輸?shù)臄?shù)據(jù)都是未加密的即明文傳輸，HTTPS則是具有安全性的SSL加密傳輸協(xié)議。
使用不同的鏈接方式，端口也不同，一般而言，HTTP協(xié)議的端口為80，HTTPS的端口為443
HTTP協(xié)議是無連接，無狀態(tài)的；(無連接：雖然HTTP使用了TCP連接，但通信的雙方在交換HTTP報文之前不需要建立HTTP連接;無狀態(tài)：是指服務(wù)端對于客戶端每次發(fā)送的請求都認(rèn)為它是一個新的請求，上一次會話和下一次會話沒有聯(lián)系);HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比HTTP協(xié)議安全。
HTTPS提升訪問速度（可以對于，請求資源所需時間更少，訪問速度更快，相比HTTP1.0）
HTTPS允許多路復(fù)用：多路復(fù)用允許同時通過單一的HTTP/2連接發(fā)送多重請求-響應(yīng)信息。改善了：在HTTP1.1中，瀏覽器客戶端在同一時間，針對同一域名下的請求有一定數(shù)量限制（連接數(shù)量），超過限制會被阻塞。
二進(jìn)制分幀：HTTP2.0會將所有的傳輸信息分割為更小的信息或者幀，并對他們進(jìn)行二進(jìn)制編碼
HTTP2首部壓縮;服務(wù)器端推送(相對于HTTP1.0)
7. SSL/TLS協(xié)議介紹
互聯(lián)網(wǎng)的通信安全是建立在SSL/TLS協(xié)議之上。不使用SSL/TLS的HTTP協(xié)議，就是不加密的通信；會帶來三大風(fēng)險：
（1）竊聽風(fēng)險：第三方可以獲取通信內(nèi)容；
（2）篡改風(fēng)險：第三方可以修改通信內(nèi)容。
（3）冒失風(fēng)險：第三方可以冒充他人身份參與通信。
SSL/TLS就是為了解決這三大風(fēng)險而設(shè)計的，希望達(dá)到：
（1）所有信息都是加密傳播，第三方無法竊聽
（2）具有校驗機(jī)制，一旦被篡改，通信雙方立即發(fā)現(xiàn)。
（3）配備身份證書，防止身份被冒充。
SSL/TLS協(xié)議的基本思路
采用公鑰加密法，即客戶端先向服務(wù)端索要公鑰，然后用公鑰加密信息，客戶端收到密文后，用自己的私鑰解密。
如何保證公鑰不被篡改？
解決方法：將公鑰放在數(shù)字證書中。只要證書是可信的，公鑰就是可信的。
公鑰加密計算量太大，如何減少耗用的時間？
解決方法：每一次對話（SESSION），客戶端和服務(wù)器端都生成一個"對話密鑰"（SESSION KEY），用它來加密信息。由于"對話密鑰"是對稱加密，所以運算速度非常快，而服務(wù)器公鑰只用于加密"對話密鑰"本身，這樣就減少了加密運算的消耗時間。
SSL/TLS協(xié)議的基本過程：
（1） 客戶端向服務(wù)器端索要并驗證公鑰。
（2） 雙方協(xié)商生成"對話密鑰"。
（3） 雙方采用"對話密鑰"進(jìn)行加密通信。 上面過程的前兩步，又稱為"握手階段"（HANDSHAKE）。 開始加密通信之前，客戶端和服務(wù)器首先必須建立連接和交換參數(shù)，這個過程叫做握手；HTTP耗時 = TCP握手；HTTPS耗時 = TCP握手 + SSL握手 所以，HTTPS肯定比HTTP耗時，這就叫SSL延遲
8.** 參考文章**
http://www.ruanyifeng.com/blog/2012/05/internet_protocol_suite_part_i.html
http://www.ruanyifeng.com/blog/2016/08/http.html
