HTTP（HyperText Transfer Protocol，超文本傳輸協(xié)議）是瀏覽器與服務(wù)端之間最主要的通信協(xié)議，這一課時(shí)主要分析 HTTP 及其相關(guān)協(xié)議的特點(diǎn)。
HTTP/0.9
1991 年 HTTP 正式誕生，當(dāng)時(shí)的版本是 0.9，從名字可以看出，該協(xié)議的作用是傳輸超文本內(nèi)容 html。
協(xié)議定義了客戶端發(fā)起請(qǐng)求、服務(wù)端響應(yīng)請(qǐng)求的通信模式。請(qǐng)求報(bào)文內(nèi)容只有 1 行，為 GET 加上請(qǐng)求的文件路徑。服務(wù)端收到請(qǐng)求后返回一個(gè)以 ASCII 字符流編碼的 HTML 文檔。
HTTP/0.9 通信示意圖
HTTP/1.0
隨著互聯(lián)網(wǎng)的發(fā)展以及瀏覽器的出現(xiàn)，單純的文本內(nèi)容已經(jīng)無(wú)法滿足用戶需求了，瀏覽器希望通過(guò) HTTP 來(lái)傳輸腳本、樣式、圖片、音頻和視頻等不同類(lèi)型的文件。
所以在 1996 年 HTTP 更新的 1.0 版本中，針對(duì)上述問(wèn)題，作出了重大改變。
其中最核心的改變是增加了頭部設(shè)定，頭部?jī)?nèi)容以鍵值對(duì)的形式設(shè)置。請(qǐng)求頭部通過(guò) Accept 字段來(lái)告訴服務(wù)端可以接收的文件類(lèi)型，響應(yīng)頭部再通過(guò) Content-Type 字段來(lái)告訴瀏覽器返回文件的類(lèi)型。
這同時(shí)也是一個(gè)相當(dāng)具有前瞻性的設(shè)計(jì)，因?yàn)轭^部字段不僅用于解決不同類(lèi)型文件傳輸?shù)膯?wèn)題，而且其他很多功能也可以依靠頭部字段實(shí)現(xiàn)，比如緩存、認(rèn)證信息。
HTTP/1.0 通信示意圖
HTTP/1.1
隨著互聯(lián)網(wǎng)的迅速發(fā)展，HTTP/1.0 也已經(jīng)無(wú)法滿足需求，最核心的就是連接問(wèn)題。具體來(lái)說(shuō)就是 HTTP/1.0 每進(jìn)行一次通信，都需要經(jīng)歷建立連接、傳輸數(shù)據(jù)和斷開(kāi)連接三個(gè)階段。當(dāng)一個(gè)頁(yè)面引用了較多的外部文件時(shí)，這個(gè)建立連接和斷開(kāi)連接的過(guò)程就會(huì)增加大量網(wǎng)絡(luò)開(kāi)銷(xiāo)。
為了解決這個(gè)問(wèn)題，1999 年推出的 HTTP/1.1 版本增加了一個(gè)創(chuàng)建持久連接的方法。主要實(shí)現(xiàn)是當(dāng)一個(gè)連接傳輸完成時(shí)，并不是馬上進(jìn)行關(guān)閉，而是繼續(xù)復(fù)用它傳輸其他請(qǐng)求的數(shù)據(jù)，這個(gè)連接保持到瀏覽器或者服務(wù)器要求斷開(kāi)連接為止。
HTTP/1.1 通信示意圖
延伸 1：TCP 是怎樣建立/斷開(kāi)連接的？
因?yàn)?HTTP 是基于 TCP 實(shí)現(xiàn)的，所以這里擴(kuò)展一下 TCP 建立連接以及斷開(kāi)連接的過(guò)程，也就是常常被提的“三次握手”和“四次揮手”。
三次握手
在建立 TCP 連接之前，客戶端和服務(wù)器之間會(huì)發(fā)送三次數(shù)據(jù)，以確認(rèn)雙方的接收和發(fā)送能力，這個(gè)過(guò)程稱(chēng)為三次握手（Three-way Handshake）。
三次握手的具體過(guò)程如下所示。
第一次握手：剛開(kāi)始客戶端處于 CLOSED 的狀態(tài)，服務(wù)端處于 LISTEN 狀態(tài)。客戶端給服務(wù)端發(fā)送一個(gè) SYN 報(bào)文，并指明客戶端的初始化序列號(hào) ISN，此時(shí)客戶端處于 SYN_SEND 狀態(tài)。
第二次握手：當(dāng)服務(wù)器收到客戶端的 SYN 報(bào)文之后，會(huì)以自己的 SYN 報(bào)文作為應(yīng)答，并且也指定了自己的初始化序列號(hào) ISN。同時(shí)會(huì)把客戶端的 ISN + 1 作為 ACK 的值，表示自己已經(jīng)收到了客戶端的 SYN，此時(shí)服務(wù)器處于 SYN_REVD 的狀態(tài)。
第三次握手：當(dāng)客戶端收到 SYN 報(bào)文之后，會(huì)發(fā)送一個(gè) ACK 報(bào)文，當(dāng)然，也同樣把服務(wù)器的 ISN + 1 作為 ACK 的值，表示已經(jīng)收到了服務(wù)端的 SYN 報(bào)文，此時(shí)客戶端處于 ESTABLISHED 狀態(tài)。服務(wù)器收到 ACK 報(bào)文之后，也處于 ESTABLISHED 狀態(tài)，此時(shí)，雙方成功建立起了連接。
TCP 三次握手
為什么建立連接的時(shí)候需要進(jìn)行三次握手呢？
分別看看每次握手的目的就能知道了。第一次握手成功讓服務(wù)端知道了客戶端具有發(fā)送能力，第二次握手成功讓客戶端知道了服務(wù)端具有接收和發(fā)送能力，但此時(shí)服務(wù)端并不知道客戶端是否接收到了自己發(fā)送的消息，所以第三次握手就起到了這個(gè)作用。經(jīng)過(guò)三次通信后，服務(wù)端和客戶端都確認(rèn)了雙方的接收和發(fā)送能力。
利用 Wireshark 抓包 TCP 三次握手
四次揮手
當(dāng)客戶端和服務(wù)端斷開(kāi)連接時(shí)要發(fā)送四次數(shù)據(jù)，這個(gè)過(guò)程稱(chēng)之為四次揮手。
四次揮手的具體過(guò)程如下所示。
第一次揮手：在揮手之前服務(wù)端與客戶端都處于 ESTABLISHED 狀態(tài)。客戶端發(fā)送一個(gè) FIN 報(bào)文，用來(lái)關(guān)閉客戶端到服務(wù)器的數(shù)據(jù)傳輸，此時(shí)客戶端處于 FIN_WAIT_1 狀態(tài)。
第二次揮手：當(dāng)服務(wù)端收到 FIN 之后，會(huì)發(fā)送 ACK 報(bào)文，并且把客戶端的序列號(hào)值加 1 作為 ACK 報(bào)文的序列號(hào)值，表明已經(jīng)收到客戶端的報(bào)文了，此時(shí)服務(wù)端處于 CLOSE_WAIT 狀態(tài)。
第三次揮手：如果服務(wù)端同意關(guān)閉連接，則會(huì)向客戶端發(fā)送一個(gè) FIN 報(bào)文，并且指定一個(gè)序列號(hào)，此時(shí)服務(wù)端處于 LAST_ACK 的狀態(tài)。
第四次揮手：當(dāng)客戶端收到 ACK 之后，處于 FIN_WAIT_2 狀態(tài)。待收到 FIN 報(bào)文時(shí)發(fā)送一個(gè) ACK 報(bào)文作為應(yīng)答，并且把服務(wù)端的序列號(hào)值 +1 作為自己 ACK 報(bào)文的序列號(hào)值，此時(shí)客戶端處于 TIME_WAIT 狀態(tài)。等待一段時(shí)間后會(huì)進(jìn)入 CLOSED 狀態(tài)，當(dāng)服務(wù)端收到 ACK 報(bào)文之后，也會(huì)變?yōu)?CLOSED 狀態(tài)，此時(shí)連接正式關(guān)閉。
TCP 四次揮手
為什么建立連接只通信了三次，而斷開(kāi)連接卻用了四次？
因?yàn)楫?dāng)服務(wù)端收到客戶端的 FIN 報(bào)文后，發(fā)送的 ACK 報(bào)文只是用來(lái)應(yīng)答的，并不表示服務(wù)端也希望立即關(guān)閉連接。
當(dāng)只有服務(wù)端把所有的報(bào)文都發(fā)送完了，才會(huì)發(fā)送 FIN 報(bào)文，告訴客戶端可以斷開(kāi)連接了，因此在斷開(kāi)連接時(shí)需要四次揮手。
利用 Wireshark 抓包 TCP 四次揮手
HTTP/2
HTTP/1.1 雖然通過(guò)長(zhǎng)連接減少了大量創(chuàng)建/斷開(kāi)連接造成的性能消耗，但由于它的并發(fā)能力受到限制，所以傳輸性能還有很大提升空間。
為什么說(shuō) HTTP/1.1 的并發(fā)能力受限呢？主要表現(xiàn)在兩個(gè)方面：
瀏覽器為了減輕服務(wù)器的壓力，限制了同一個(gè)域下的 HTTP 連接數(shù)，即 6 ~ 8 個(gè)，所以在 HTTP/1.1 下很容易看到資源文件等待加載的情況，對(duì)應(yīng)優(yōu)化的方式就是使用多個(gè)域名來(lái)加載圖片資源；
HTTP/1.1 本身的問(wèn)題，雖然 HTTP/1.1 中使用持久連接時(shí)，多個(gè)請(qǐng)求能共用一個(gè) TCP 連接，但在一個(gè)連接中同一時(shí)刻只能處理一個(gè)請(qǐng)求，在當(dāng)前的請(qǐng)求沒(méi)有結(jié)束之前，其他的請(qǐng)求只能處于阻塞狀態(tài)，這種情況被稱(chēng)為 “隊(duì)頭阻塞” 。
正是出于這個(gè)問(wèn)題，在 2015 年正式發(fā)布的 HTTP/2 中新增了一個(gè)二進(jìn)制分幀的機(jī)制來(lái)提升傳輸效率。
HTTP/2 將默認(rèn)不再使用 ASCII 編碼傳輸，而是改為二進(jìn)制數(shù)據(jù)。客戶端在發(fā)送請(qǐng)求時(shí)會(huì)將每個(gè)請(qǐng)求的內(nèi)容封裝成不同的帶有編號(hào)的二進(jìn)制幀，然后將這些幀同時(shí)發(fā)送給服務(wù)端。服務(wù)端接收到數(shù)據(jù)之后，會(huì)將相同編號(hào)的幀合并為完整的請(qǐng)求信息。同樣，服務(wù)端返回結(jié)果、客戶端接收結(jié)果也遵循這個(gè)幀的拆分與組合的過(guò)程。
受益于二進(jìn)制分幀，對(duì)于同一個(gè)域，客戶端只需要與服務(wù)端建立一個(gè)連接即可完成通信需求，自然也不再受限于瀏覽器的連接數(shù)限制了，這種利用一個(gè)連接來(lái)發(fā)送多個(gè)請(qǐng)求的方式稱(chēng)為“多路復(fù)用”。
HTTP/2 通信示意圖
HTTP/2 也增加了一些其他的功能，比如通過(guò)壓縮頭部信息來(lái)減少傳輸體積，以及通過(guò)服務(wù)推送來(lái)減少客戶端請(qǐng)求。相對(duì)而言，二進(jìn)制分幀屬于核心功能，所以其他功能就不做詳細(xì)介紹了，有興趣的話可以查看具體規(guī)范。
通過(guò)開(kāi)發(fā)者工具查看 HTTP/2 請(qǐng)求
延伸 2：HTTPS 原理
HTTP 雖然能滿足客戶端與服務(wù)端的通信需求，但這種使用明文發(fā)送數(shù)據(jù)的方式存在一定的安全隱患，因?yàn)橥ㄐ艃?nèi)容很容易被通信鏈路中的第三方截獲甚至篡改。那么怎么解決這個(gè)安全問(wèn)題呢？
對(duì)稱(chēng)加密
當(dāng)然是對(duì)通信數(shù)據(jù)進(jìn)行加密傳輸。加密方式分為對(duì)稱(chēng)加密和非對(duì)稱(chēng)加密，最大的區(qū)別在于，對(duì)稱(chēng)加密在加/解密過(guò)程中使用同一個(gè)密鑰，而非對(duì)稱(chēng)加密使用不同的密鑰進(jìn)行加/解密。在性能方面，對(duì)稱(chēng)密鑰更勝一籌，所以可以使用對(duì)稱(chēng)密鑰。
但是肯定不能在每次通信中都使用同一個(gè)對(duì)稱(chēng)密鑰，因?yàn)槿绻褂猛粋€(gè)密鑰，任何人只要與服務(wù)端建立通信就能獲得這個(gè)密鑰，也就可以輕松解密其他通信數(shù)據(jù)了。所以應(yīng)該是每次通信都要隨機(jī)生成。
非對(duì)稱(chēng)加密
由于不可能保證客戶端和服務(wù)端同時(shí)生成一個(gè)相同的隨機(jī)密鑰，所以生成的隨機(jī)密鑰需要被傳輸，這樣的話在傳輸過(guò)程中也會(huì)存在被盜取的風(fēng)險(xiǎn)。
要解決這個(gè)問(wèn)題還需要通過(guò)將密鑰加密來(lái)進(jìn)行傳輸。除了前面提到的對(duì)稱(chēng)加密，我們只有非對(duì)稱(chēng)加密這個(gè)選項(xiàng)了，比如客戶端通過(guò)公鑰來(lái)加密，服務(wù)端利用私鑰來(lái)解密。
證書(shū)機(jī)制
同樣的問(wèn)題也會(huì)出現(xiàn)，密鑰對(duì)生成后，該怎么分發(fā)呢？
如果在客戶端生成密鑰對(duì)，把私鑰發(fā)給服務(wù)端，那么服務(wù)端需要為每個(gè)客戶端保存一個(gè)密鑰，這顯然是不太現(xiàn)實(shí)的。所以只能由服務(wù)端生成密鑰對(duì)，將公鑰分發(fā)給需要建立連接的客戶端。
直接發(fā)送給客戶端還是會(huì)被篡改，此時(shí)只能借助第三方來(lái)實(shí)現(xiàn)了，比如證書(shū)機(jī)制。
具體來(lái)說(shuō)就是把公鑰放入一個(gè)證書(shū)中，該證書(shū)包含服務(wù)端的信息，比如頒發(fā)者、域名、有效期，為了保證證書(shū)是可信的，需要由一個(gè)可信的第三方來(lái)對(duì)證書(shū)進(jìn)行簽名。這個(gè)第三方一般是證書(shū)的頒發(fā)機(jī)構(gòu)，也稱(chēng) CA（Certification Authority，認(rèn)證中心）。
那么這個(gè)證書(shū)的簽名怎么檢驗(yàn)真假呢？
要回答這個(gè)問(wèn)題先要理解證書(shū)簽名的過(guò)程。證書(shū)簽名就是將證書(shū)信息進(jìn)行 MD5 計(jì)算，獲取唯一的哈希值，然后再利用證書(shū)頒發(fā)方的私鑰對(duì)其進(jìn)行加密生成。
校驗(yàn)過(guò)程與之相反，需要用到證書(shū)頒發(fā)方的公鑰對(duì)簽名進(jìn)行解密，然后計(jì)算證書(shū)信息的 MD5 值，將解密后的 MD5 值與計(jì)算所得的 MD5 值進(jìn)行比對(duì)，如果兩者一致代表簽名是可信的。所以要校驗(yàn)簽名的真?zhèn)危托枰@得證書(shū)頒發(fā)方的公鑰，這個(gè)公鑰就在頒發(fā)方的證書(shū)中。
這種通過(guò)簽名來(lái)頒發(fā)與校驗(yàn)證書(shū)的方式會(huì)形成一個(gè)可追溯的鏈，即證書(shū)鏈。處于證書(shū)鏈頂端的證書(shū)稱(chēng)為根證書(shū)，這些根證書(shū)被預(yù)置在操作系統(tǒng)的內(nèi)部。
通過(guò)瀏覽器查看證書(shū)鏈
上面所述的頒發(fā)證書(shū)與加密機(jī)制就是 HTTPS 的實(shí)現(xiàn)原理。
HTTP/3
當(dāng)然 HTTP/2 也并非完美，考慮一種情況，如果客戶端或服務(wù)端在通信時(shí)出現(xiàn)數(shù)據(jù)包丟失，或者任何一方的網(wǎng)絡(luò)出現(xiàn)中斷，那么整個(gè) TCP 連接就會(huì)暫停。
HTTP/2 由于采用二進(jìn)制分幀進(jìn)行多路復(fù)用，通常只使用一個(gè) TCP 連接進(jìn)行傳輸，在丟包或網(wǎng)絡(luò)中斷的情況下后面的所有數(shù)據(jù)都被阻塞。但對(duì)于 HTTP/1.1 來(lái)說(shuō)，可以開(kāi)啟多個(gè) TCP 連接，任何一個(gè) TCP 出現(xiàn)問(wèn)題都不會(huì)影響其他 TCP 連接，剩余的 TCP 連接還可以正常傳輸數(shù)據(jù)。這種情況下 HTTP/2 的表現(xiàn)就不如 HTTP/1 了。
2018 年 HTTP/3 將底層依賴(lài)的 TCP 改成 UDP，從而徹底解決了這個(gè)問(wèn)題。UDP 相對(duì)于 TCP 而言最大的特點(diǎn)是傳輸數(shù)據(jù)時(shí)不需要建立連接，可以同時(shí)發(fā)送多個(gè)數(shù)據(jù)包，所以傳輸效率很高，缺點(diǎn)就是沒(méi)有確認(rèn)機(jī)制來(lái)保證對(duì)方一定能收到數(shù)據(jù)。
通過(guò)開(kāi)發(fā)者工具查看 HTTP/3 請(qǐng)求
總結(jié)
理解 HTTP 對(duì)于前端工程師而言非常重要，無(wú)論是性能優(yōu)化還是開(kāi)發(fā)設(shè)計(jì) Web 應(yīng)用都離不開(kāi) HTTP，本課時(shí)總結(jié)了 HTTP 各個(gè)版本的核心改進(jìn)以及解決的問(wèn)題，同時(shí)深入 HTTP 底層依賴(lài) 的 TCP，講解了 TCP 建立和斷開(kāi)連接的過(guò)程。分析了 HTTPS 如何通過(guò)證書(shū)機(jī)制以及加密方式來(lái)保障通信數(shù)據(jù)的安全。
下面總結(jié)一張表格方便你的理解和記憶：
最后布置一道思考題：HTTP 解決了客戶端向服務(wù)端請(qǐng)求和提交數(shù)據(jù)的問(wèn)題，如果服務(wù)端要主動(dòng)將數(shù)據(jù)推送到客戶端，你知道有哪些解決方案嗎？
