[[381273]]

本文轉載自微信公眾號「sowhat1412」，作者sowhat1412  。轉載本文請聯系sowhat1412公眾號。

1 TCP/IP

1.1 TCP/IP 定義

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

1.2 TCP/IP 功能

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

1.2.1. 應用層

應用層 為用戶直接提供不同的網絡服務協議，比如 HTTP、Email、FTP 等，這些協議都是為了解決實際生活中不同的需求而產生的協議。用戶大部分時間也是在此層操作跟組裝數據，說白了就是socket 編程!至于具體的數據是如何進行網絡傳輸的，是由下面的三層負責的。

1.2.2. 傳輸層

傳輸層為應用層提供通信服務，屬于面向通信部分的最高層，也是用戶功能中的最底層。傳輸層為相互通信的應用進程提供了邏輯通信。主要包括 TCP 協議和 UDP 協議。

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

UDP 不提供復雜的控制機制。

傳輸層的作用：

1. 分段及封裝應用層送來的數據。
2. 提供端到端的傳輸服務。
3. 在發(fā)送主機與接收主機之間構建邏輯通信。

1.2.3. 網絡層

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

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

1.2.4. 鏈路層

數據鏈路層實現了網卡接口的網絡驅動程序，以處理數據在物理媒介上的傳輸。數據鏈路層兩個常用的協議是ARP協議(Address Resolve Protocol，地址解析協議)和 RARP 協議(ReverseAddress Resolve Protocol，逆地址解析協議)。它們實現了 IP 地址和機器物理 MAC 地址之間的相互轉換。

1.2.5 數據傳輸

1. 利用 TCP/IP 協議族進行網絡通信時，會通過分層順序與對方進行通信。發(fā)送端從應用層往下走，接收端則從鏈路層往上走。
2. 發(fā)送端在層與層之間傳輸數據時，每經過一層時必定會被打上一個該層所屬的首部信息。反之，接受端在層與層傳輸數據時，每經過一層時會把對應的首部消去。
3. 這種把數據信息包裝起來的做法成為封裝。

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

以太網的MTU是1500，基本IP首部長度為20，TCP首部是20，所以MSS的值最大可達1460(MSS不包括協議首部，只包含應用數據)。

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

數據分包發(fā)送

1.3 OSI 跟 TCP/IP

OSI

OSI又稱 開放式系統(tǒng)互聯通信參考模型 ，是由國際標準化組織提出的一種概念模型，一個試圖使各種計算機在世界范圍內互連為網絡的標準框架，它注重通信協議必要的功能是什么。

TCP/IP

現實生活中真正的網絡傳輸通訊協議，注重在計算機上實現協議應該開發(fā)哪種程序。

OSI 跟 TCP/IP 區(qū)別

1. OSI 引入了服務、接口、協議、分層的概念，TCP/IP 借鑒了 OSI 的這些概念建立 TCP/IP 模型。
2. OSI 先有模型后有協議，先有標準后進行實踐。
3. TCP/IP 先有協議和應用再提出了模型，且是參照的OSI模型。
4. OSI 是一種理論下的模型，而 TCP/IP 已被廣泛使用，成為網絡互聯事實上的標準。

介紹完宏觀的TCP/IP 協議簇后，接下來讓我們從上到下進入網絡的世界吧。

2 應用層 HTTP

2.1 HTTP 簡單了解

2.1.1 HTTP 定義

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

HTTP

2.1.2 URI、 URN 、URL

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

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

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

URL模板

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

舉例三者關系：

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

2.2 HTTP 報文格式

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

2.2.1 請求

請求報文格式

2.2.1.1 請求行

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

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

URL：指定就是本次訪問的目標地址。

協議版本：指定了客戶端當前支持的 HTTP 版本，HTTP 目前通用的有 1.1、 2.0、3.0 三個版本，如果請求方指定了 1.1，應答方收到之后也會使用 HTTP 1.1 協議進行回復。

2.2.1.2 請求頭

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

2.2.1.3 空行

只包含一個回車符和一個換行符，不包含其它任何內容。這個空行用于標記請求頭部已結束，它是必須要有的。

2.2.1.4 請求體

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

2.2.1.5 請求樣例

請求樣例

2.2.2 響應

響應報文格式

2.2.2.1 響應行

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

2.2.2.2 響應頭

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

2.2.2.4 響應樣例

響應樣例

2.3 HTTP 頭字段

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

1. 通用字段：在請求頭和響應頭里都可以出現。
2. 請求字段：僅能出現在請求頭里，進一步說明請求信息或者額外的附加條件。
3. 響應字段：僅能出現在響應頭里，補充說明響應報文的信息。
4. 實體字段：它實際上屬于通用字段，但專門描述 body 的額外信息。

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

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

2.4 HTTPS 跟 HTTP

HTTP 是明文傳輸的，存在如下幾個風險：

1. 竊聽風險：信息保密性，比如通信鏈路上可以獲取通信內容。
2. 篡改風險：信息完整性，比如強制入垃圾廣告。
3. 冒充風險：身份識別，比如雜牌網址冒充淘寶等購物網站。

2.4.1 SSL/TLS 概述

SSL/TLS

為了保證安全性 HTTPS 應運而生，HTTPS 在 HTTP 與 TCP 層之間加入了 SSL/TLS 加密協議，可以解決上述三個問題。

1. 通過混合加密實現了信息的機密性。
2. 通過摘要算法的方式來實現完整性，它能夠為數據生成獨一無二的序列號。
3. 將服務器公鑰放入到數字證書中，解決了冒充的風險。

這里需注意一般 HTTP 默認是 80 端口，而 HTTPS 默認 443 端口。

2.4.2 加密算法

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

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

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

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

2.4.3 摘要算法

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

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

校驗完整性

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

2.4.4 CA 證書

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

非對稱加密信息泄露

問題的關鍵就是如何保證客戶端收到的是服務器的公鑰!此時 數字證書就出現了，它就是基于上上面所說的私鑰加密數據，公鑰解密來驗證其身份。

CA確保公鑰正確傳輸

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

2.4.5 SSL/TLS 建立流程

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

SSL/TLS 建立流程

• 客戶端請求

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

• 服務端請求

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

• 客戶端證書驗證

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

• 服務器最后回應

1. 服務端收到Random3 + 最終加密算法 最終定下 會話秘鑰 Session Key。
2. 服務端向客戶端告知加密算法改變，后面會用Session Key 加密信息。
3. 服務端也會將握手過程的消息生成摘要再用秘鑰加密，這是服務端發(fā)出的第一條加密消息?？蛻舳私邮蘸髸妹罔€解密，能解出來說明協商的秘鑰是一致的。

• 正常發(fā)送數據

至此，雙方已安全地協商出了同一份秘鑰， SSL/TLS 的握手階段全部結束。所有的應用層數據都會用這個秘鑰加密后再通過 TCP 進行可靠傳輸。

2.4 HTTP 發(fā)展史

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

HTTP版本對比

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. 請求/響應頭未經壓縮就發(fā)送，只能壓縮Body部分。
2. 來回發(fā)送冗余的配置信息。
3. 會引發(fā)頭部阻塞。
4. FIFO模式，沒有優(yōu)先級概念。
5. 只能客戶端請求，服務器響應。

2.4.1 HTTP/2

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

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

缺點：

阻塞問題：HTTP/2 的分幀傳輸是在應用層進行的，最終數據要經過 TCP 傳輸，而 TCP 是可靠性連接，有丟包重傳功能。如果有包丟失會導致所有的 HTTP 請求在等待被丟的包被重傳回來。

2.4.1 HTTP/3

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

1. QUIC 獨有一套機制來保證傳輸的可靠性的。當某個流發(fā)生丟包時，只會阻塞這個流，其他流不會受到影響。
2. TLS 算法也由1.2升級到了1.3，頭部壓縮算法升級為 QPack。
3. HTTP/3 之前通信要先三次 TCP 握手 + TLS 三次加密交互。QUIC 底層將6步合并成了3步。
4. QUIC 是一個在 UDP 之上的 TCP + TLS + HTTP/2 的多路復用的協議。

2.5 HTTP 特性

• 靈活擴展

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

• 可靠傳輸

不管是 TCP 還是 QUIC 都保證了 數據傳輸的可靠性。

• 請求-應答模式

HTTP 是 基于-請求 應答模型實現數據傳輸的。

• 無狀態(tài)

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

• 應用層協議

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

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

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

3 附錄

只大致講解了TCP/IP協議的應用層跟傳輸層，網絡層下篇見，看個更詳細版本的 TCP/IP 協議。

TCP/IP協議

4 參考

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

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

小林網絡專題：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