作者：京東零售 王樂

一、從一個請求來看網(wǎng)絡(luò)分層原理

1.1 復(fù)雜的網(wǎng)絡(luò)

以下為一次請求過程中可能遇到的問題，預(yù)示著網(wǎng)絡(luò)的復(fù)雜性。

??

1.2 如何簡化復(fù)雜度

為了簡化網(wǎng)絡(luò)的復(fù)雜度，網(wǎng)絡(luò)通信的不同方面被分解為多層次結(jié)構(gòu)，每一層只與緊挨著的上層或者下層進行交互，將網(wǎng)絡(luò)分層，這樣就可以修改，甚至替換某一層的軟件，只要層與層之間的接口保持不變，就不會影響到其他層。

1.2.1 OSI( Open System Interconnection Reference Model): 開放系統(tǒng)互聯(lián)參考模型

??

?

1.2.2 TCP/IP 協(xié)議族

??

1.2.3 兩種協(xié)議的對應(yīng)關(guān)系

應(yīng)用層：應(yīng)用程序負責(zé)的部分

傳輸層：TCP、UDP、SCTP 等

網(wǎng)絡(luò)層：IPv4、IPv6等

數(shù)據(jù)鏈路層：以太網(wǎng)、無限LAN(WIFI)

物理層：光纖、雙絞線電纜、無線設(shè)備

??

1.3 一個請求的分層解析流程

請求各層之間都是調(diào)用對應(yīng)層的接口(這個接口可以類比java中的接口，它可以有各種實現(xiàn)方式)。

1.在請求過程中域名是無法直接被計算機識別的，必須先轉(zhuǎn)換成ip，此時先檢測本地是否配置了host，如果沒有配置的話會發(fā)起一個dns請求。

2.DNS使用UDP作為傳輸層,DNS服務(wù)器IP配置在你的操作系統(tǒng)中，可以直接獲取。

3.數(shù)據(jù)鏈路層在接收到網(wǎng)絡(luò)層調(diào)用后，會通過IP使用ARP協(xié)議獲取當前IP對應(yīng)的MAC地址。

4.最終通過物理層將數(shù)據(jù)傳入路由器，路由器進行逆向解析(MAC地址->IP)，如果路由器判斷此信息不是給自己的會將信息繼續(xù)傳給下游電信運營商。

5.運營商判斷是DNS請求還是HTTP請求，如果是DNS請求會調(diào)用DNS服務(wù)器換取IP并返回。

6.獲取IP后DNS請求完成，此時再次發(fā)送一次HTTP請求，HTTP在傳輸層使用的是TCP協(xié)議，其他層同理。

7.運營商判斷如果非DNS請求，那么電信會通過運營商直接的協(xié)議進行消息的發(fā)送，最終找到ip對應(yīng)的服務(wù)器。

8.接收端服務(wù)器的物理層接受到此次請求，通過對應(yīng)的協(xié)議進行數(shù)據(jù)的層層解析獲取對應(yīng)的信息，最終將數(shù)據(jù)傳給本地服務(wù)器（nginx、tomcat等），服務(wù)器將響應(yīng)報文通過HTTP方式將數(shù)據(jù)返回。

一次請求的流轉(zhuǎn)如下圖：

??

二、HTTP協(xié)議

超文本傳輸協(xié)議(HyperText Transfer Protocol，HTTP)： 一種無狀態(tài)的，以請求/應(yīng)答方式運行的協(xié)議，它使用可擴展的語義和自描述消息格式，與 基于網(wǎng)絡(luò)的超文本信息系統(tǒng)靈活的互動

2.1 HTTP報文格式

請求報文和響應(yīng)報文的結(jié)構(gòu)基本相同。

起始行：描述請求或響應(yīng)的基本信息。

頭部字段集合：key-value結(jié)構(gòu)，報文的詳細信息。

消息體：真實傳輸?shù)膬?nèi)容，可以是文本或二進制等。

2.1.1 HTTP請求報文

一個HTTP請求報文由請求行（request line）、請求頭部（header）、空行和請求數(shù)據(jù)4個部分組成，下圖給出了請求報文的一般格式。

??

2.1.1.1 請求行

請求行由請求方法字段、URL字段和HTTP協(xié)議版本字段3個字段組成，它們用空格分隔。例如，GET /index.html HTTP/1.1。

HTTP協(xié)議的請求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。

2.1.1.2 請求頭部

請求頭部由關(guān)鍵字/值對組成，每行一對，關(guān)鍵字和值用英文冒號“:”分隔。請求頭部通知服務(wù)器有關(guān)于客戶端請求的信息，典型的請求頭有：

User-Agent：產(chǎn)生請求的瀏覽器類型。 Accept：客戶端可識別的內(nèi)容類型列表。 Host：請求的主機名，允許多個域名同處一個IP地址，即虛擬主機。

2.1.1.3 空行

最后一個請求頭之后是一個空行，發(fā)送回車符和換行符，通知服務(wù)器以下不再有請求頭。

2.1.1.4 請求數(shù)據(jù)

請求數(shù)據(jù)不在GET方法中使用，而是在POST方法中使用。POST方法適用于需要客戶填寫表單的場合。與請求數(shù)據(jù)相關(guān)的最常使用的請求頭是Content-Type（這個主體的對象類型）和Content-Length（主體的長度）。

2.1.1.5 頭部字段注意事項

字段名不區(qū)分大小寫，字段名里不允許出現(xiàn)空格，可以使用連字符“-”，但不能使用下劃線“_”（有的服務(wù)器不會解析帶“_”的頭字段）。字段名后面必須緊接著“:”，不能有空格，而“:”后的字段值前可以有多個空格； 字段的順序是沒有意義的，可以任意排列不影響語義； 字段原則上不能重復(fù)，除非這個字段本身的語義允許，例如 Set-Cookie。

2.1.2 HTTP響應(yīng)報文

HTTP響應(yīng)也由三個部分組成，分別是：狀態(tài)行、消息報頭、響應(yīng)正文。

??

2.1.2.1 狀態(tài)行格式如下

HTTP-Version Status-Code Reason-Phrase CRLF

其中，HTTP-Version表示服務(wù)器HTTP協(xié)議的版本；Status-Code表示服務(wù)器發(fā)回的響應(yīng)狀態(tài)代碼；Reason-Phrase表示狀態(tài)代碼的文本描述。狀態(tài)代碼由三位數(shù)字組成，第一個數(shù)字定義了響應(yīng)的類別，且有五種可能取值。

?1xx：指示信息–表示請求已接收，繼續(xù)處理。

?2xx：成功–表示請求已被成功接收、理解、接受。

?3xx：重定向–要完成請求必須進行更進一步的操作。

?4xx：客戶端錯誤–請求有語法錯誤或請求無法實現(xiàn)。

?5xx：服務(wù)器端錯誤–服務(wù)器未能實現(xiàn)合法的請求。

常見狀態(tài)代碼、狀態(tài)描述的說明如下：

?200 OK：客戶端請求成功。

?400 Bad Request：客戶端請求有語法錯誤，不能被服務(wù)器所理解。

?401 Unauthorized：請求未經(jīng)授權(quán)，這個狀態(tài)代碼必須和WWW-Authenticate報頭域一起使用。

?403 Forbidden：服務(wù)器收到請求，但是拒絕提供服務(wù)。

?404 Not Found：請求資源不存在，舉個例子：輸入了錯誤的URL。

?500 Internal Server Error：服務(wù)器發(fā)生不可預(yù)期的錯誤。

?503 Server Unavailable：服務(wù)器當前不能處理客戶端的請求，一段時間后可能恢復(fù)正常，舉個例子：HTTP/1.1 200 OK（CRLF）。

百度百科 狀態(tài)碼參考網(wǎng)址?

2.1.2.1 響應(yīng)頭

Access-Control-Allow-Credentials:true

Access-Control-Allow-Origin:*

Access-Control-Expose-Headers:Date,X-API-Request-Id

Content-Encoding:gzip

Content-Type:application/json;charset=UTF-8

Date:Sun, 10 Mar 2024 12:00:17 GMT

2.1.2.2 響應(yīng)實體內(nèi)容

服務(wù)器發(fā)給瀏覽器，要讓瀏覽器顯示的內(nèi)容（html，js，css，圖片，數(shù)據(jù)等信息）。

三、HTTP請求完整過程

3.1 請求過程描述

1.首先瀏覽器先解析URL中的域名。

2.通過域名獲取對應(yīng)的ip地址，上邊已經(jīng)說過ip是通過DNS服務(wù)器獲取，我們可以在谷歌瀏覽器中查看到域名對應(yīng)ip的解析。

3.獲取到IP地址后，瀏覽器就可以發(fā)起與服務(wù)器的三次握手

4.建立連接后，就開始組裝http請求，發(fā)送請求。

5.接收端收到請求后，開始處理請求解析請求頭中的數(shù)據(jù)，并生成對應(yīng)的響應(yīng)數(shù)據(jù)，給發(fā)送端返回響應(yīng)數(shù)據(jù)。

6.瀏覽器收到響應(yīng)后，會通過響應(yīng)頭類型，解析對應(yīng)的數(shù)據(jù)報文。

補充：上邊2中從瀏覽器中獲取域名的步驟。

瀏覽器中輸入：chrome://net-export/

打開對應(yīng)文件搜索你想找的域名即可。

?

四、TCP協(xié)議

4.1 TCP協(xié)議描述

面向連接的，可靠的，基于字節(jié)流的傳輸層通信協(xié)議

4.2 TCP協(xié)議特點

?基于連接的：數(shù)據(jù)傳輸之前需要建立連接

?全雙工的：雙向傳輸

?客戶端和服務(wù)端可以互相雙向?qū)憯?shù)據(jù)

?字節(jié)流：不限制數(shù)據(jù)大小，打包成報文段，保證有序接收，重復(fù)報文自動丟棄

?發(fā)送方：每次傳輸不限制數(shù)據(jù)大小，不是一次性將所有的數(shù)據(jù)都傳輸，會將數(shù)據(jù)切分成多個片段，并進行排序，通過網(wǎng)絡(luò)介質(zhì)傳輸給接收方。

?接收方：不同的數(shù)據(jù)包會通過網(wǎng)絡(luò)不同的路線傳入接受方，因此接收方收到的數(shù)據(jù)有可能是亂序的，因此需要對數(shù)據(jù)包進行重排序。

?流量緩沖：解決雙方處理能力的不匹配

?可靠的傳輸服務(wù)：保證可達，丟包時通過重發(fā)機制實現(xiàn)可靠性

?擁塞控制：防止網(wǎng)絡(luò)出現(xiàn)惡性擁塞

?當網(wǎng)絡(luò)環(huán)境比較差的時候，會控制報文大小減小傳輸速率。

4.3 TCP連接管理

4.3.1 TCP連接四元組

四元組分別為：源地址、 源端口、 目的地址、 目的端口

4.3.2 TCP頭部格式

??

序列號：在建?連接時由計算機?成的隨機數(shù)作為其初始值，通過 SYN 包傳給接收端主機，每發(fā)送?次數(shù)據(jù)，就累加?次該數(shù)據(jù)字節(jié)數(shù)的??。?來解決?絡(luò)包亂序問題。

確認應(yīng)答號：指下?次期望收到的數(shù)據(jù)的序列號，發(fā)送端收到這個確認應(yīng)答以后可以認為在這個序號以前的數(shù)據(jù)都已經(jīng)被正常接收。?來解決不丟包的問題。

控制位：

ACK：該位為 1 時，確認應(yīng)答的字段變?yōu)橛行В琓CP 規(guī)定除了最初建?連接時的 SYN 包之外該位必須設(shè)置為 1 。

RST：該位為 1 時，表示 TCP 連接中出現(xiàn)異常必須強制斷開連接。

SYN：該位為 1 時，表示希望建?連接，并在其序列號的字段進?序列號初始值的設(shè)定。

FIN：該位為 1 時，表示今后不會再有數(shù)據(jù)發(fā)送，希望斷開連接。當通信結(jié)束希望斷開連接時，通信雙?的 主機之間就可以相互交換FIN位為 的 TCP 段。

URG：當URG=1時，表明緊急指針字段有效。它告訴系統(tǒng)此報文段中有緊急數(shù)據(jù)，應(yīng)該盡快傳送，而不按照原來的排隊序列來傳送。

PSH：推送（PuSH），當兩個應(yīng)用進程進行交互式的通信時，有時一端的應(yīng)用進程希望在鍵入一個命令之后就能立即收到對方的響應(yīng)。在這樣的情況下，就可以使用推送操作，此時，發(fā)送方將PSH置為1，并創(chuàng)建一個報文發(fā)送出去，接收端接受到該報文，發(fā)現(xiàn)PSH為1，就盡快交付接受應(yīng)用進程，而不用等到整個緩存都滿了之后再向上交付。

緊急數(shù)據(jù)指針：當發(fā)送端需要發(fā)送一些緊急數(shù)據(jù)時，可以設(shè)置緊急指針來指示接收端，在接收到該指針之后盡快處理這些數(shù)據(jù)。緊急指針的值是一個相對于當前序列號的偏移量，用于指示緊急數(shù)據(jù)在整個數(shù)據(jù)流中的位置。

窗口大小：當前服務(wù)器緩存可接受的數(shù)據(jù)報文大小。

4.4 TCP 三次握手

??

說明：

1.開始時服務(wù)端和客戶端的連接處于斷開狀態(tài)。

2.服務(wù)端啟動后會監(jiān)聽特定端口，處于監(jiān)聽狀態(tài)，等待客戶端的請求。

3.客戶端發(fā)起請求，變更成發(fā)送狀態(tài)，此時會在請求中攜帶同步序列號 x。

4.服務(wù)端接受到請求后，保存客戶端對應(yīng)的信息，并發(fā)送確認收到應(yīng)答消息，此消息的應(yīng)答碼需要在x的基礎(chǔ)上加1，此時服務(wù)端處于等待客戶端確認狀態(tài)。

5.客戶端收到服務(wù)端確認后，狀態(tài)變更為已連接，客戶端也需要給服務(wù)端回復(fù)確認收到，此時應(yīng)答碼為服務(wù)端確認碼y+1。

6.服務(wù)端收到客戶端確認消息后，狀態(tài)變更為已連接。

7.連接建立成功，此為三次握手。

8.握手過程中會消耗序號，建立鏈接后不會消耗。

以下是三次握手的示例過程：

??

4.5 TCP 四次揮手

??

說明：

1.客戶端和服務(wù)端都可以主動發(fā)起關(guān)閉連接。

2.圖中為客戶端發(fā)起關(guān)閉連接，首先客戶端發(fā)起 FIN 關(guān)閉連接請求。

3.服務(wù)端收到關(guān)閉請求后，先回復(fù)收到關(guān)閉請求的確認消息給客戶端，此時客戶端處于等待關(guān)閉2狀態(tài)，等待服務(wù)端完成收尾工作，服務(wù)端完成收尾(剩余未完成傳輸數(shù)據(jù)同步)，執(zhí)行關(guān)閉連接方法，并給客戶端發(fā)送FIN 關(guān)閉鏈接請求。

4.客戶端收到關(guān)閉請求后，給服務(wù)端回復(fù)確認關(guān)閉應(yīng)答消息，服務(wù)端關(guān)閉，客戶端處于等待狀態(tài)，此時需要等待兩個最大請求時長(防止服務(wù)端由于網(wǎng)絡(luò)原因未收到應(yīng)答消息，服務(wù)端會重試發(fā)送FIN消息)。

5.等待時間到期后關(guān)閉連接。

4.5 TCP 可靠性傳輸

4.5.1 停止等待協(xié)議

描述：沒傳送一個報文，服務(wù)端都回復(fù)一個確認消息，效率低下。

??

4.5.1 重傳機制

4.5.1.1 ack丟失

描述：如果出現(xiàn)丟包如何處理

??

4.5.1.2 報文丟失

??

4.5.2 滑動窗口協(xié)議與累計確認（延時ack）

??

說明：

1.約定窗口大小為4，每次發(fā)送四個報文。

2.服務(wù)端收到后只收到，1，2，4。 3丟失，此時服務(wù)端確認只確認到2。

3.客戶端收到確認后，從3開始在滑動下一個窗口，進行數(shù)據(jù)傳輸。

參考文獻

OSI參考模型： https://baike.baidu.com/item/OSI%E5%8F%82%E8%80%83%E6%A8%A1%E5%9E%8B/708028?fr=aladdin

HTTP狀態(tài)碼： https://baike.baidu.com/item/HTTP%E7%8A%B6%E6%80%81%E7%A0%81?fromModule=lemma_search-box

TCP協(xié)議： https://baike.baidu.com/item/TCP/33012?fr=ge_ala

TCP與UDP的可靠性傳輸： https://zhuanlan.zhihu.com/p/636141175

審核編輯 黃宇