作者丨sowhat1412

來源丨sowhat1412

1.1 ?TCP/IP 定義

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

1.2 TCP/IP ?功能

上文說過 TCP/IP 宏觀上分為四層，接下來說下四層的具體作用。

1.2.1. 應(yīng)用層

應(yīng)用層 為用戶直接提供不同的網(wǎng)絡(luò)服務(wù)協(xié)議，比如 HTTP、Email、FTP 等，這些協(xié)議都是為了解決實際生活中不同的需求而產(chǎn)生的協(xié)議。用戶大部分時間也是在此層操作跟組裝數(shù)據(jù)，說白了就是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é)議。

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

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

傳輸層的作用：

1. 分段及封裝應(yīng)用層送來的數(shù)據(jù)。

2. 提供端到端的傳輸服務(wù)。

3. 在發(fā)送主機(jī)與接收主機(jī)之間構(gòu)建邏輯通信。

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

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

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

1.2.4. 鏈路層

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

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

1. 利用 TCP/IP 協(xié)議族進(jìn)行網(wǎng)絡(luò)通信時，會通過分層順序與對方進(jìn)行通信。發(fā)送端從應(yīng)用層往下走，接收端則從鏈路層往上走。

2. 發(fā)送端在層與層之間傳輸數(shù)據(jù)時，每經(jīng)過一層時必定會被打上一個該層所屬的首部信息。反之，接受端在層與層傳輸數(shù)據(jù)時，每經(jīng)過一層時會把對應(yīng)的首部消去。

3. 這種把數(shù)據(jù)信息包裝起來的做法成為封裝。

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

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

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

1.3 OSI 跟 TCP/IP

OSI

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

TCP/IP

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

OSI 跟 TCP/IP 區(qū)別

1. OSI 引入了服務(wù)、接口、協(xié)議、分層的概念，TCP/IP 借鑒了 OSI 的這些概念建立 TCP/IP 模型。

2. OSI 先有模型后有協(xié)議，先有標(biāo)準(zhǔn)后進(jìn)行實踐。

3. TCP/IP 先有協(xié)議和應(yīng)用再提出了模型，且是參照的OSI模型。

4. OSI 是一種理論下的模型，而 TCP/IP 已被廣泛使用，成為網(wǎng)絡(luò)互聯(lián)事實上的標(biāo)準(zhǔn)。

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

2 應(yīng)用層 HTTP

2.1 ?HTTP 簡單了解

2.1.1 HTTP 定義

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

2.1.2 URI、 URN 、URL

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

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

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

1. protocol：通訊雙方采用什么協(xié)議交流，HTTP、ftp、file等

2. IP：服務(wù)器的真實IP地址。

3. Port：服務(wù)資源在IP機(jī)器上暴露的端口。

4. path：資源在服務(wù)器上的存放路徑，一般就是文件或者訪問目錄。

5. query：可選配置，用&分割，參數(shù)以KV方式存儲。

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

1. 你想去找一個人，此處人就是一種資源 URI。

2. 如果用身份證號 + 名字去找就是URN，身份證號 + 名字只標(biāo)識了人這個資源，但無法確認(rèn)資源的地址。

3. 如果用地址：XX省XX市XX區(qū)XX單元XX房間的住戶 就是URL，不僅標(biāo)識人這個資源，而且定位了其地址

2.2 HTTP 報文格式

請求 和 響應(yīng) 報文都由 起始行、頭部、空行、實體四個部分組成，只不過 起始行 稍有不同。

2.2.1 請求

2.2.1.1 ?請求行

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

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

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

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

2.2.1.2 請求頭

請求頭部 用來告知服務(wù)器該請求和客戶端本身的一些額外信息，每個請求頭都是一個鍵值對，鍵和值之間用英文冒號隔開。每個請求頭單獨形成一行，它們的末尾都是一個回車符和換行符。在所有的請求頭中，只有 Host 是必需的，其它請求頭都是可選的，列舉一些常見請求頭：

2.2.1.3 空行

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

2.2.1.4 請求體

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

2.2.1.5 請求樣例

2.2.2 響應(yīng)

2.2.2.1 ?響應(yīng)行

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

2.2.2.2 ?響應(yīng)頭

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

2.2.2.4 響應(yīng)樣例

2.3 HTTP 頭字段

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

1. 通用字段：在請求頭和響應(yīng)頭里都可以出現(xiàn)。

2. 請求字段：僅能出現(xiàn)在請求頭里，進(jìn)一步說明請求信息或者額外的附加條件。

3. 響應(yīng)字段：僅能出現(xiàn)在響應(yīng)頭里，補(bǔ)充說明響應(yīng)報文的信息。

4. 實體字段：它實際上屬于通用字段，但專門描述 body 的額外信息。

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

1. 內(nèi)容協(xié)商：客戶端跟服務(wù)端就響應(yīng)的資源內(nèi)容約定好，比如語言、字符集、編碼方式、壓縮類型。

2. 緩存管理 : 針對資源特性可進(jìn)行資源是否緩存到客戶端，注意 max-age、no-cache、no-store、must-revalidate 之間區(qū)別。

3. 實體類型：通過解析 Content-Type 來獲得請求跟響應(yīng)的 MIME 類型。

4. 連接管理：通過讀取配置參數(shù)實現(xiàn)長短連接。

2.4 HTTPS 跟 HTTP

HTTP 是明文傳輸?shù)模嬖谌缦聨讉€風(fēng)險：

1. 竊聽風(fēng)險：信息保密性，比如通信鏈路上可以獲取通信內(nèi)容。

2. 篡改風(fēng)險：信息完整性，比如強(qiáng)制入垃圾廣告。

3. 冒充風(fēng)險：身份識別，比如雜牌網(wǎng)址冒充淘寶等購物網(wǎng)站。

2.4.1 SSL/TLS 概述

1. 通過混合加密實現(xiàn)了信息的機(jī)密性。

2. 通過摘要算法的方式來實現(xiàn)完整性，它能夠為數(shù)據(jù)生成獨一無二的序列號。

3. 將服務(wù)器公鑰放入到數(shù)字證書中，解決了冒充的風(fēng)險。

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

2.4.2 加密算法

加密算法 分為 對稱加密 跟 非對稱加密。

1. 對稱加密：加密解密使用一個密鑰，運算速度快，密鑰必須保密，無法做到安全的密鑰交換。常見加密算法有 AES、DES、RC4、BlowFish 等。

2. 非對稱加密：使用公鑰和私鑰兩個秘鑰，公鑰可以任意分發(fā)而私鑰保密，解決了密鑰交換問題但速度慢。私鑰到公鑰的推導(dǎo)過程是單向的，可保證私鑰的安全性。常見加密算法有 RSA、 DSA、Diffie-Hellman等。

HTTPS 采用的是 對稱加密 ?+ ?非對稱加密 ?= 混合加密方式：

1. 在通信建立前采用非對稱加密的方式交換秘鑰，后續(xù)就不再使用非對稱加密。

2. 在通信過程中全部使用對稱加密的會話秘鑰的方式加密明文數(shù)據(jù)。

2.4.3 摘要算法

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

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

1. 客戶端將明文數(shù)據(jù)通過指定的摘要算法生成摘要。

2. 明文數(shù)據(jù) + 摘要算法 經(jīng)過公鑰加密后傳輸。

3. 服務(wù)器收到信息后用私鑰解密信息得到明文 + 摘要。

4. 服務(wù)器通過相同的摘要算法對明文生成摘要。

5. 對比客戶端跟服務(wù)器生成的兩個摘要是否一樣，以此檢測數(shù)據(jù)是否完整。

2.4.4 CA 證書

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

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

1. CA 是權(quán)威的證書簽發(fā)機(jī)構(gòu)，全球就那么幾個公司比較權(quán)威，該機(jī)構(gòu)用RSA生成一對公私鑰。

2. 服務(wù)器公鑰內(nèi)容 + 簽發(fā)者ID + 證書簽發(fā)給誰Subject + 有效期 + 其他信息 = ?明文內(nèi)容P

3. 明文內(nèi)容 P 經(jīng)過Hash算法生成 H1，用 CA 的私鑰對 H1 進(jìn)行 RSA 加密獲得 S。

4. P + S ?= 數(shù)字證書。

5. 客戶端得到數(shù)字證書后，用同樣Hash算法對 P 進(jìn)行 Hash計算得到 H2。

6. 我們用 CA 公鑰解密 S 得到了一個 H3。

7. 比較 H2 跟 H3 是否一樣，一樣說明這個證書OK。不一樣說明 P 被修改了或者證書不是CA簽發(fā)的。

8. 一樣就可以正確拿出服務(wù)器公鑰了，搞定！

2.4.5 SSL/TLS 建立流程

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

1. 客戶端請求

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

2. 服務(wù)端請求

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

3. 客戶端證書驗證

1. 客戶端通過CA公鑰確認(rèn)服務(wù)器數(shù)字證書真實性，取出服務(wù)器公鑰。

2. 客戶端生成一個隨機(jī)數(shù)Random3，用服務(wù)器公鑰加密生成 PreMaster Key然后發(fā)送給 服務(wù)器，再發(fā)送個約定的加密算法。

3. 服務(wù)器用私鑰解密 PreMaster Key得到 Random3。至此服務(wù)器跟客戶端都用相同的加密算法加密Random1 + Random2 + Random3 = 會話秘鑰 Session Key，以后通信就用這個了加密通信。

4. 客戶端將前面的握手消息生成摘要再用協(xié)商好的秘鑰加密，這是客戶端發(fā)出的第一條加密消息。服務(wù)端接收后會用秘鑰解密，能解出來說明前面協(xié)商出來的秘鑰是一致的。

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

1. 服務(wù)端收到Random3 + 最終加密算法 最終定下 ?會話秘鑰 Session Key。

2. 服務(wù)端向客戶端告知加密算法改變，后面會用Session Key 加密信息。

3. 服務(wù)端也會將握手過程的消息生成摘要再用秘鑰加密，這是服務(wù)端發(fā)出的第一條加密消息?？蛻舳私邮蘸髸妹罔€解密，能解出來說明協(xié)商的秘鑰是一致的。

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

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

2.4 HTTP 發(fā)展史

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

2.4.1 ?HTTP/1.1

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

優(yōu)點：

1. TCP 開始使用長連接替代短連接來避免不必要的性能開銷。

2. 比如發(fā)送ABC時B的發(fā)送沒必要必須等待A發(fā)送完才開始發(fā)送B。

缺點：

1. 請求/響應(yīng)頭未經(jīng)壓縮就發(fā)送，只能壓縮Body部分。

2. 來回發(fā)送冗余的配置信息。

3. 會引發(fā)頭部阻塞。

4. FIFO模式，沒有優(yōu)先級概念。

5. 只能客戶端請求，服務(wù)器響應(yīng)。

2.4.1 ?HTTP/2

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

1. 頭部壓縮：引入 HPACK 算法，在客戶端和服務(wù)器同時維護(hù)一張頭信息表，所有字段都會存入這個表中，頭部來回重復(fù)信息不再發(fā)原值直接發(fā)索引號就好。

2. 二進(jìn)制傳輸：新版本采用對計算機(jī)更友好的二進(jìn)制模式傳輸，數(shù)據(jù)按幀傳輸。

3. 流式優(yōu)先級傳輸：按Stream區(qū)分不同的請求響應(yīng)數(shù)據(jù)包，每個Stream都有獨立編號。并且還可以指定優(yōu)先級。

4. 多路復(fù)用：一個連接里多個流可以同時收發(fā)請求-應(yīng)答數(shù)據(jù)幀，每個流中數(shù)據(jù)包按序傳輸組裝，每個流都是獨立的，所以誰先處理好請求，誰就可以先將響應(yīng)通過連接發(fā)送給對方。

5. 服務(wù)器推送：服務(wù)器端會主動 推送可能用到的JS、CSS 等 static 變量。

缺點：

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

2.4.1 ?HTTP/3

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

1. QUIC 獨有一套機(jī)制來保證傳輸?shù)目煽啃缘?。?dāng)某個流發(fā)生丟包時，只會阻塞這個流，其他流不會受到影響。

2. TLS 算法也由1.2升級到了1.3，頭部壓縮算法升級為 QPack。

3. HTTP/3 之前通信要先三次 TCP 握手 + TLS 三次加密交互。QUIC 底層將6步合并成了3步。

4. QUIC 是一個在 UDP 之上的 TCP + TLS + HTTP/2 的多路復(fù)用的協(xié)議。

2.5 ?HTTP 特性

1. 靈活擴(kuò)展

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

2. 可靠傳輸

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

3. 請求-應(yīng)答模式

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

4. 無狀態(tài)

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

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

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

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

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

3 附錄

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

4 參考

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

2. HTTP萬字講義：https://t.1yb.co/gcKW

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

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

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