[[381273]]

本文轉(zhuǎn)載自微信公眾號(hào)「sowhat1412」，作者sowhat1412  。轉(zhuǎn)載本文請(qǐng)聯(lián)系sowhat1412公眾號(hào)。

1 TCP/IP

1.1 TCP/IP 定義

TCP/IP 協(xié)議族是一組協(xié)議的集合，也叫互聯(lián)網(wǎng)協(xié)議族，計(jì)算機(jī)之間只有遵守這些規(guī)則，才能進(jìn)行通信。TCP 和 IP 只是其中2個(gè)重要的協(xié)議，所以用 TCP/IP 來(lái)命名這個(gè)互聯(lián)網(wǎng)協(xié)議族，實(shí)際上他大致包括四層協(xié)議。

1.2 TCP/IP 功能

上文說(shuō)過(guò) TCP/IP 宏觀上分為四層，接下來(lái)說(shuō)下四層的具體作用。

1.2.1. 應(yīng)用層

應(yīng)用層 為用戶直接提供不同的網(wǎng)絡(luò)服務(wù)協(xié)議，比如 HTTP、Email、FTP 等，這些協(xié)議都是為了解決實(shí)際生活中不同的需求而產(chǎn)生的協(xié)議。用戶大部分時(shí)間也是在此層操作跟組裝數(shù)據(jù)，說(shuō)白了就是socket 編程!至于具體的數(shù)據(jù)是如何進(jìn)行網(wǎng)絡(luò)傳輸?shù)?，是由下面的三層?fù)責(zé)的。

1.2.2. 傳輸層

傳輸層為應(yīng)用層提供通信服務(wù)，屬于面向通信部分的最高層，也是用戶功能中的最底層。傳輸層為相互通信的應(yīng)用進(jìn)程提供了邏輯通信。主要包括 TCP 協(xié)議和 UDP 協(xié)議。

TCP 提供面向連接的數(shù)據(jù)流支持、可靠性、流量控制、多路復(fù)用等服務(wù)。

UDP 不提供復(fù)雜的控制機(jī)制。

傳輸層的作用：

1. 分段及封裝應(yīng)用層送來(lái)的數(shù)據(jù)。
2. 提供端到端的傳輸服務(wù)。
3. 在發(fā)送主機(jī)與接收主機(jī)之間構(gòu)建邏輯通信。

1.2.3. 網(wǎng)絡(luò)層

網(wǎng)絡(luò)層功能是實(shí)現(xiàn)數(shù)據(jù)包的選路和轉(zhuǎn)發(fā)。廣域網(wǎng)通常使用眾多分級(jí)的路由器來(lái)連接分散的主機(jī)或局域網(wǎng)，因此，通信的兩臺(tái)主機(jī)一般是通過(guò)多個(gè)中間節(jié)點(diǎn)路由器連接的。網(wǎng)絡(luò)層的任務(wù)就是選擇這些中間節(jié)點(diǎn)，以確定兩臺(tái)主機(jī)之間的通信路徑。同時(shí)對(duì)上層協(xié)議隱藏了網(wǎng)絡(luò)拓?fù)溥B接的細(xì)節(jié)，使得在傳輸層和網(wǎng)絡(luò)應(yīng)用程序看來(lái)，通信的雙方是直接相連的。

IP 協(xié)議即處于這一層，提供路由和尋址的功能，使兩終端系統(tǒng)能夠互連且決定最佳路徑，並具有一定的擁塞控制和流量控制的能力。

1.2.4. 鏈路層

數(shù)據(jù)鏈路層實(shí)現(xiàn)了網(wǎng)卡接口的網(wǎng)絡(luò)驅(qū)動(dòng)程序，以處理數(shù)據(jù)在物理媒介上的傳輸。數(shù)據(jù)鏈路層兩個(gè)常用的協(xié)議是ARP協(xié)議(Address Resolve Protocol，地址解析協(xié)議)和 RARP 協(xié)議(ReverseAddress Resolve Protocol，逆地址解析協(xié)議)。它們實(shí)現(xiàn)了 IP 地址和機(jī)器物理 MAC 地址之間的相互轉(zhuǎn)換。

1.2.5 數(shù)據(jù)傳輸

1. 利用 TCP/IP 協(xié)議族進(jìn)行網(wǎng)絡(luò)通信時(shí)，會(huì)通過(guò)分層順序與對(duì)方進(jìn)行通信。發(fā)送端從應(yīng)用層往下走，接收端則從鏈路層往上走。
2. 發(fā)送端在層與層之間傳輸數(shù)據(jù)時(shí)，每經(jīng)過(guò)一層時(shí)必定會(huì)被打上一個(gè)該層所屬的首部信息。反之，接受端在層與層傳輸數(shù)據(jù)時(shí)，每經(jīng)過(guò)一層時(shí)會(huì)把對(duì)應(yīng)的首部消去。
3. 這種把數(shù)據(jù)信息包裝起來(lái)的做法成為封裝。

但是需注意一點(diǎn)， IP 層是有 Maximum Transmission Unit 最大傳輸單元 MTU 限制的，同理一次數(shù)據(jù)傳輸時(shí) TCP 層是有 Maximum Segment Size 最大報(bào)文段長(zhǎng)度 MSS 限制的，

以太網(wǎng)的MTU是1500，基本IP首部長(zhǎng)度為20，TCP首部是20，所以MSS的值最大可達(dá)1460(MSS不包括協(xié)議首部，只包含應(yīng)用數(shù)據(jù))。

所以一個(gè)大的應(yīng)用層信息傳輸時(shí)候可能會(huì)被切分若干塊然后逐個(gè)傳輸。接收方收到每個(gè)包的應(yīng)用層數(shù)據(jù)再組裝成應(yīng)用層數(shù)據(jù)，然后一個(gè)請(qǐng)求才算接收完成，這也是 Content-Length 字段存在的意義。

數(shù)據(jù)分包發(fā)送

1.3 OSI 跟 TCP/IP

OSI

OSI又稱 開(kāi)放式系統(tǒng)互聯(lián)通信參考模型 ，是由國(guó)際標(biāo)準(zhǔn)化組織提出的一種概念模型，一個(gè)試圖使各種計(jì)算機(jī)在世界范圍內(nèi)互連為網(wǎng)絡(luò)的標(biāo)準(zhǔn)框架，它注重通信協(xié)議必要的功能是什么。

TCP/IP

現(xiàn)實(shí)生活中真正的網(wǎng)絡(luò)傳輸通訊協(xié)議，注重在計(jì)算機(jī)上實(shí)現(xiàn)協(xié)議應(yīng)該開(kāi)發(fā)哪種程序。

OSI 跟 TCP/IP 區(qū)別

1. OSI 引入了服務(wù)、接口、協(xié)議、分層的概念，TCP/IP 借鑒了 OSI 的這些概念建立 TCP/IP 模型。
2. OSI 先有模型后有協(xié)議，先有標(biāo)準(zhǔn)后進(jìn)行實(shí)踐。
3. TCP/IP 先有協(xié)議和應(yīng)用再提出了模型，且是參照的OSI模型。
4. OSI 是一種理論下的模型，而 TCP/IP 已被廣泛使用，成為網(wǎng)絡(luò)互聯(lián)事實(shí)上的標(biāo)準(zhǔn)。

介紹完宏觀的TCP/IP 協(xié)議簇后，接下來(lái)讓我們從上到下進(jìn)入網(wǎng)絡(luò)的世界吧。

2 應(yīng)用層 HTTP

2.1 HTTP 簡(jiǎn)單了解

2.1.1 HTTP 定義

HyperText Transfer Protocol，又名 超文本傳輸協(xié)議。HTTP 是對(duì)計(jì)算機(jī)世界里任意兩點(diǎn)之間傳輸文字、圖片、音視頻等超文本數(shù)據(jù)的約定和規(guī)范。

HTTP

2.1.2 URI、 URN 、URL

URI：Uniform Resource Identifier 統(tǒng)一資源標(biāo)志符，表示的是web上每一種可用的資源，URI只是一種概念，怎樣實(shí)現(xiàn)無(wú)所謂，重點(diǎn)在于標(biāo)識(shí)一個(gè)資源。

URN ：Universal Resource Name 統(tǒng)一資源名稱，通過(guò)特定命名空間中的唯一名稱或ID來(lái)標(biāo)識(shí)資源。

URL：Universal Resource Locator 統(tǒng)一資源定位符，URL 其實(shí)是 URI 的一種子集，不僅標(biāo)識(shí)了一個(gè)資源還告訴了你如何訪問(wèn)它，一個(gè)標(biāo)準(zhǔn)的URL必須包括：protocol、host、port、path。

URL模板

1. protocol：通訊雙方采用什么協(xié)議交流，HTTP、ftp、file等
2. IP：服務(wù)器的真實(shí)IP地址。
3. Port：服務(wù)資源在IP機(jī)器上暴露的端口。
4. path：資源在服務(wù)器上的存放路徑，一般就是文件或者訪問(wèn)目錄。
5. query：可選配置，用&分割，參數(shù)以KV方式存儲(chǔ)。

舉例三者關(guān)系：

1. 你想去找一個(gè)人，此處人就是一種資源 URI。
2. 如果用身份證號(hào) + 名字去找就是URN，身份證號(hào) + 名字只標(biāo)識(shí)了人這個(gè)資源，但無(wú)法確認(rèn)資源的地址。
3. 如果用地址：XX省XX市XX區(qū)XX單元XX房間的住戶 就是URL，不僅標(biāo)識(shí)人這個(gè)資源，而且定位了其地址

2.2 HTTP 報(bào)文格式

請(qǐng)求 和 響應(yīng) 報(bào)文都由 起始行、頭部、空行、實(shí)體四個(gè)部分組成，只不過(guò) 起始行 稍有不同。

2.2.1 請(qǐng)求

請(qǐng)求報(bào)文格式

2.2.1.1 請(qǐng)求行

請(qǐng)求行又包含3個(gè)部分：請(qǐng)求方法、URL、協(xié)議版本。它們之間用空格分開(kāi)，請(qǐng)求行最后以一個(gè)回車(chē)符 + 一個(gè)換行符結(jié)尾。

請(qǐng)求方法：表明想對(duì)目標(biāo)資源進(jìn)行何種操作，HTTP1.1 定義了下表中列出的 8 種請(qǐng)求方法，其中最常用的是 GET 和 POST。

URL：指定就是本次訪問(wèn)的目標(biāo)地址。

協(xié)議版本：指定了客戶端當(dāng)前支持的 HTTP 版本，HTTP 目前通用的有 1.1、 2.0、3.0 三個(gè)版本，如果請(qǐng)求方指定了 1.1，應(yīng)答方收到之后也會(huì)使用 HTTP 1.1 協(xié)議進(jìn)行回復(fù)。

2.2.1.2 請(qǐng)求頭

請(qǐng)求頭部 用來(lái)告知服務(wù)器該請(qǐng)求和客戶端本身的一些額外信息，每個(gè)請(qǐng)求頭都是一個(gè)鍵值對(duì)，鍵和值之間用英文冒號(hào)隔開(kāi)。每個(gè)請(qǐng)求頭單獨(dú)形成一行，它們的末尾都是一個(gè)回車(chē)符和換行符。在所有的請(qǐng)求頭中，只有 Host 是必需的，其它請(qǐng)求頭都是可選的，列舉一些常見(jiàn)請(qǐng)求頭：

2.2.1.3 空行

只包含一個(gè)回車(chē)符和一個(gè)換行符，不包含其它任何內(nèi)容。這個(gè)空行用于標(biāo)記請(qǐng)求頭部已結(jié)束，它是必須要有的。

2.2.1.4 請(qǐng)求體

一般就是用戶自定義的 信息體了，在消息頭中可以通過(guò) Content-Type 指定類型。

2.2.1.5 請(qǐng)求樣例

請(qǐng)求樣例

2.2.2 響應(yīng)

響應(yīng)報(bào)文格式

2.2.2.1 響應(yīng)行

指定返回信息對(duì)應(yīng)的 HTTP 版本、響應(yīng)信息狀態(tài)碼、簡(jiǎn)單原因。

2.2.2.2 響應(yīng)頭

至于空行跟消息體幾乎跟跟請(qǐng)求類似，而消息體類型是由 Content-Type 指定的。

2.2.2.4 響應(yīng)樣例

響應(yīng)樣例

2.3 HTTP 頭字段

HTTP 協(xié)議規(guī)定了非常多的頭字段，可以實(shí)現(xiàn)各種各樣的功能，但基本上可以分為以下四類：

1. 通用字段：在請(qǐng)求頭和響應(yīng)頭里都可以出現(xiàn)。
2. 請(qǐng)求字段：僅能出現(xiàn)在請(qǐng)求頭里，進(jìn)一步說(shuō)明請(qǐng)求信息或者額外的附加條件。
3. 響應(yīng)字段：僅能出現(xiàn)在響應(yīng)頭里，補(bǔ)充說(shuō)明響應(yīng)報(bào)文的信息。
4. 實(shí)體字段：它實(shí)際上屬于通用字段，但專門(mén)描述 body 的額外信息。

通過(guò)對(duì) HTTP 頭字段的設(shè)置，HTTP 提供了如下幾個(gè)重要功能：

1. 內(nèi)容協(xié)商：客戶端跟服務(wù)端就響應(yīng)的資源內(nèi)容約定好，比如語(yǔ)言、字符集、編碼方式、壓縮類型。
2. 緩存管理 : 針對(duì)資源特性可進(jìn)行資源是否緩存到客戶端，注意 max-age、no-cache、no-store、must-revalidate 之間區(qū)別。
3. 實(shí)體類型：通過(guò)解析 Content-Type 來(lái)獲得請(qǐng)求跟響應(yīng)的 MIME 類型。
4. 連接管理：通過(guò)讀取配置參數(shù)實(shí)現(xiàn)長(zhǎng)短連接。

2.4 HTTPS 跟 HTTP

HTTP 是明文傳輸?shù)?，存在如下幾個(gè)風(fēng)險(xiǎn)：

1. 竊聽(tīng)風(fēng)險(xiǎn)：信息保密性，比如通信鏈路上可以獲取通信內(nèi)容。
2. 篡改風(fēng)險(xiǎn)：信息完整性，比如強(qiáng)制入垃圾廣告。
3. 冒充風(fēng)險(xiǎn)：身份識(shí)別，比如雜牌網(wǎng)址冒充淘寶等購(gòu)物網(wǎng)站。

2.4.1 SSL/TLS 概述

SSL/TLS

為了保證安全性 HTTPS 應(yīng)運(yùn)而生，HTTPS 在 HTTP 與 TCP 層之間加入了 SSL/TLS 加密協(xié)議，可以解決上述三個(gè)問(wèn)題。

1. 通過(guò)混合加密實(shí)現(xiàn)了信息的機(jī)密性。
2. 通過(guò)摘要算法的方式來(lái)實(shí)現(xiàn)完整性，它能夠?yàn)閿?shù)據(jù)生成獨(dú)一無(wú)二的序列號(hào)。
3. 將服務(wù)器公鑰放入到數(shù)字證書(shū)中，解決了冒充的風(fēng)險(xiǎn)。

這里需注意一般 HTTP 默認(rèn)是 80 端口，而 HTTPS 默認(rèn) 443 端口。

2.4.2 加密算法

加密算法 分為 對(duì)稱加密 跟 非對(duì)稱加密。

1. 對(duì)稱加密：加密解密使用一個(gè)密鑰，運(yùn)算速度快，密鑰必須保密，無(wú)法做到安全的密鑰交換。常見(jiàn)加密算法有 AES、DES、RC4、BlowFish 等。
2. 非對(duì)稱加密：使用公鑰和私鑰兩個(gè)秘鑰，公鑰可以任意分發(fā)而私鑰保密，解決了密鑰交換問(wèn)題但速度慢。私鑰到公鑰的推導(dǎo)過(guò)程是單向的，可保證私鑰的安全性。常見(jiàn)加密算法有 RSA、 DSA、Diffie-Hellman等。

HTTPS 采用的是 對(duì)稱加密 + 非對(duì)稱加密 = 混合加密方式：

1. 在通信建立前采用非對(duì)稱加密的方式交換秘鑰，后續(xù)就不再使用非對(duì)稱加密。
2. 在通信過(guò)程中全部使用對(duì)稱加密的會(huì)話秘鑰的方式加密明文數(shù)據(jù)。

2.4.3 摘要算法

摘要算法的主要特征是加密過(guò)程不需要密鑰，并且經(jīng)過(guò)加密的數(shù)據(jù)無(wú)法被解密，目前可以被解密逆向的只有CRC32算法，只有輸入相同的明文數(shù)據(jù)經(jīng)過(guò)相同的消息摘要算法才能得到相同的密文。

消息摘要算法主要應(yīng)用在數(shù)字簽名領(lǐng)域，作為對(duì)明文的摘要算法。著名的摘要算法有RSA公司的MD5算法和 SHA-1 算法及其大量的變體。

校驗(yàn)完整性

1. 客戶端將明文數(shù)據(jù)通過(guò)指定的摘要算法生成摘要。
2. 明文數(shù)據(jù) + 摘要算法 經(jīng)過(guò)公鑰加密后傳輸。
3. 服務(wù)器收到信息后用私鑰解密信息得到明文 + 摘要。
4. 服務(wù)器通過(guò)相同的摘要算法對(duì)明文生成摘要。
5. 對(duì)比客戶端跟服務(wù)器生成的兩個(gè)摘要是否一樣，以此檢測(cè)數(shù)據(jù)是否完整。

2.4.4 CA 證書(shū)

非對(duì)稱加密時(shí)，客戶端保存公鑰，如何確保公鑰的準(zhǔn)確性是個(gè)難題，如果有人竊取服務(wù)器公鑰搞事情，那么整個(gè)數(shù)據(jù)傳輸過(guò)程中客戶端跟服務(wù)器是感知不到第三方存在，但信息卻早就泄露了!

非對(duì)稱加密信息泄露

問(wèn)題的關(guān)鍵就是如何保證客戶端收到的是服務(wù)器的公鑰!此時(shí) 數(shù)字證書(shū)就出現(xiàn)了，它就是基于上上面所說(shuō)的私鑰加密數(shù)據(jù)，公鑰解密來(lái)驗(yàn)證其身份。

CA確保公鑰正確傳輸

1. CA 是權(quán)威的證書(shū)簽發(fā)機(jī)構(gòu)，全球就那么幾個(gè)公司比較權(quán)威，該機(jī)構(gòu)用RSA生成一對(duì)公私鑰。
2. 服務(wù)器公鑰內(nèi)容 + 簽發(fā)者ID + 證書(shū)簽發(fā)給誰(shuí)Subject + 有效期 + 其他信息 = 明文內(nèi)容P
3. 明文內(nèi)容 P 經(jīng)過(guò)Hash算法生成 H1，用 CA 的私鑰對(duì) H1 進(jìn)行 RSA 加密獲得 S。
4. P + S = 數(shù)字證書(shū)。
5. 客戶端得到數(shù)字證書(shū)后，用同樣Hash算法對(duì) P 進(jìn)行 Hash計(jì)算得到 H2。
6. 我們用 CA 公鑰解密 S 得到了一個(gè) H3。
7. 比較 H2 跟 H3 是否一樣，一樣說(shuō)明這個(gè)證書(shū)OK。不一樣說(shuō)明 P 被修改了或者證書(shū)不是CA簽發(fā)的。
8. 一樣就可以正確拿出服務(wù)器公鑰了，搞定!

2.4.5 SSL/TLS 建立流程

先進(jìn)行 TCP 的三次握手，然后準(zhǔn)備加密通信，開(kāi)始加密通信之前，客戶端和服務(wù)器首先必須建立連接和交換參數(shù)，這個(gè)過(guò)程叫做握手 HandShake，也就是前面一直說(shuō)的SSL/TLS模塊，那么它的主要工作流程是啥呢，你可以認(rèn)為是 ClientHello、ServerHello、Finish。

SSL/TLS 建立流程

• 客戶端請(qǐng)求

客戶端向服務(wù)器發(fā)起加密通信請(qǐng)求 : 客戶端給出SSL/TLS協(xié)議版本號(hào) + 一個(gè)客戶端生成的隨機(jī)數(shù)Random1 + 客戶端支持的加密方法。

• 服務(wù)端請(qǐng)求

服務(wù)器端確認(rèn)SSL/TLS版本是否支持，確認(rèn)使用的加密算法，生成隨機(jī)數(shù)Random2 (用來(lái)生成會(huì)話秘鑰)，生成服務(wù)器數(shù)字證書(shū)。

• 客戶端證書(shū)驗(yàn)證

1. 客戶端通過(guò)CA公鑰確認(rèn)服務(wù)器數(shù)字證書(shū)真實(shí)性，取出服務(wù)器公鑰。
2. 客戶端生成一個(gè)隨機(jī)數(shù)Random3，用服務(wù)器公鑰加密生成 PreMaster Key然后發(fā)送給 服務(wù)器，再發(fā)送個(gè)約定的加密算法。
3. 服務(wù)器用私鑰解密 PreMaster Key得到 Random3。至此服務(wù)器跟客戶端都用相同的加密算法加密Random1 + Random2 + Random3 = 會(huì)話秘鑰 Session Key，以后通信就用這個(gè)了加密通信。
4. 客戶端將前面的握手消息生成摘要再用協(xié)商好的秘鑰加密，這是客戶端發(fā)出的第一條加密消息。服務(wù)端接收后會(huì)用秘鑰解密，能解出來(lái)說(shuō)明前面協(xié)商出來(lái)的秘鑰是一致的。

• 服務(wù)器最后回應(yīng)

1. 服務(wù)端收到Random3 + 最終加密算法 最終定下 會(huì)話秘鑰 Session Key。
2. 服務(wù)端向客戶端告知加密算法改變，后面會(huì)用Session Key 加密信息。
3. 服務(wù)端也會(huì)將握手過(guò)程的消息生成摘要再用秘鑰加密，這是服務(wù)端發(fā)出的第一條加密消息。客戶端接收后會(huì)用秘鑰解密，能解出來(lái)說(shuō)明協(xié)商的秘鑰是一致的。

• 正常發(fā)送數(shù)據(jù)

至此，雙方已安全地協(xié)商出了同一份秘鑰， SSL/TLS 的握手階段全部結(jié)束。所有的應(yīng)用層數(shù)據(jù)都會(huì)用這個(gè)秘鑰加密后再通過(guò) TCP 進(jìn)行可靠傳輸。

2.4 HTTP 發(fā)展史

目前 HTTP 版本分為 HTTP/1.1、HTTP/2、HTTP/3 三個(gè)版本，主流用的是前面?zhèn)z。

HTTP版本對(duì)比

2.4.1 HTTP/1.1

HTTP/1.1 相比于老版本優(yōu)缺點(diǎn)如下：

優(yōu)點(diǎn)：

1. TCP 開(kāi)始使用長(zhǎng)連接替代短連接來(lái)避免不必要的性能開(kāi)銷。
2. 比如發(fā)送ABC時(shí)B的發(fā)送沒(méi)必要必須等待A發(fā)送完才開(kāi)始發(fā)送B。

缺點(diǎn)：

1. 請(qǐng)求/響應(yīng)頭未經(jīng)壓縮就發(fā)送，只能壓縮Body部分。
2. 來(lái)回發(fā)送冗余的配置信息。
3. 會(huì)引發(fā)頭部阻塞。
4. FIFO模式，沒(méi)有優(yōu)先級(jí)概念。
5. 只能客戶端請(qǐng)求，服務(wù)器響應(yīng)。

2.4.1 HTTP/2

HTTP/2 協(xié)議是基于 HTTPS 的，做了向下兼容同時(shí)還有如下優(yōu)化。

1. 頭部壓縮：引入 HPACK 算法，在客戶端和服務(wù)器同時(shí)維護(hù)一張頭信息表，所有字段都會(huì)存入這個(gè)表中，頭部來(lái)回重復(fù)信息不再發(fā)原值直接發(fā)索引號(hào)就好。
2. 二進(jìn)制傳輸：新版本采用對(duì)計(jì)算機(jī)更友好的二進(jìn)制模式傳輸，數(shù)據(jù)按幀傳輸。
3. 流式優(yōu)先級(jí)傳輸：按Stream區(qū)分不同的請(qǐng)求響應(yīng)數(shù)據(jù)包，每個(gè)Stream都有獨(dú)立編號(hào)。并且還可以指定優(yōu)先級(jí)。
4. 多路復(fù)用：一個(gè)連接里多個(gè)流可以同時(shí)收發(fā)請(qǐng)求-應(yīng)答數(shù)據(jù)幀，每個(gè)流中數(shù)據(jù)包按序傳輸組裝，每個(gè)流都是獨(dú)立的，所以誰(shuí)先處理好請(qǐng)求，誰(shuí)就可以先將響應(yīng)通過(guò)連接發(fā)送給對(duì)方。
5. 服務(wù)器推送：服務(wù)器端會(huì)主動(dòng) 推送可能用到的JS、CSS 等 static 變量。

缺點(diǎn)：

阻塞問(wèn)題：HTTP/2 的分幀傳輸是在應(yīng)用層進(jìn)行的，最終數(shù)據(jù)要經(jīng)過(guò) TCP 傳輸，而 TCP 是可靠性連接，有丟包重傳功能。如果有包丟失會(huì)導(dǎo)致所有的 HTTP 請(qǐng)求在等待被丟的包被重傳回來(lái)。

2.4.1 HTTP/3

HTTP/3 把 TCP 協(xié)議改成了UDP，因?yàn)?UDP 是不管順序、不管丟包的， 同時(shí) Google 在 UDP 的基礎(chǔ)上也加了 TCP 的連接管理、擁塞窗口、流量控制等機(jī)制，這套協(xié)議我們稱之為 QUIC 協(xié)議。整體來(lái)說(shuō) HTTP/3 優(yōu)化點(diǎn)如下：

1. QUIC 獨(dú)有一套機(jī)制來(lái)保證傳輸?shù)目煽啃缘摹．?dāng)某個(gè)流發(fā)生丟包時(shí)，只會(huì)阻塞這個(gè)流，其他流不會(huì)受到影響。
2. TLS 算法也由1.2升級(jí)到了1.3，頭部壓縮算法升級(jí)為 QPack。
3. HTTP/3 之前通信要先三次 TCP 握手 + TLS 三次加密交互。QUIC 底層將6步合并成了3步。
4. QUIC 是一個(gè)在 UDP 之上的 TCP + TLS + HTTP/2 的多路復(fù)用的協(xié)議。

2.5 HTTP 特性

• 靈活擴(kuò)展

HTTP 牛逼之處在于他只是規(guī)定了 header + body 的基本框架，里面具體填寫(xiě)啥用戶可自定義，同時(shí)它的底層都是插拔式的組件，比如 SSL/TLS 的添加，二進(jìn)制幀傳送，UDP替換TCP等等。

• 可靠傳輸

不管是 TCP 還是 QUIC 都保證了 數(shù)據(jù)傳輸?shù)目煽啃浴?/p>

• 請(qǐng)求-應(yīng)答模式

HTTP 是 基于-請(qǐng)求 應(yīng)答模型實(shí)現(xiàn)數(shù)據(jù)傳輸?shù)摹?/p>

• 無(wú)狀態(tài)

HTTP 的每一個(gè)請(qǐng)求-應(yīng)答都是無(wú)狀態(tài)的，所以每次收發(fā)報(bào)文都是完全獨(dú)立的，如果要實(shí)現(xiàn)一些連鎖反應(yīng)需要用到 Session 跟 Cookie 機(jī)制。

• 應(yīng)用層協(xié)議

HTTP 只是一個(gè)在應(yīng)用層規(guī)定好的傳輸協(xié)議而已，它的底層用的是 TCP 協(xié)議傳輸數(shù)據(jù)。

2.6 HTTP 常見(jiàn)狀態(tài)碼

常見(jiàn)的 HTTP 狀態(tài)碼 有五種類型。

3 附錄

只大致講解了TCP/IP協(xié)議的應(yīng)用層跟傳輸層，網(wǎng)絡(luò)層下篇見(jiàn)，看個(gè)更詳細(xì)版本的 TCP/IP 協(xié)議。

TCP/IP協(xié)議

4 參考

SSL/TLS：https://www.bilibili.com/read/cv1003133

HTTP萬(wàn)字講義：https://t.1yb.co/gcKW

小林網(wǎng)絡(luò)專題：https://t.1yb.co/fQG3

HTTP狀態(tài)碼：http://tools.jb51.net/table/http_status_code

TCP/IP講解：https://developer.51cto.com/art/201906/597961.htm