作者：京東零售 王樂(lè)

一、從一個(gè)請(qǐng)求來(lái)看網(wǎng)絡(luò)分層原理

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

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

??

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

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

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

??

?

1.2.2 TCP/IP 協(xié)議族

??

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

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

傳輸層：TCP、UDP、SCTP 等

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

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

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

??

1.3 一個(gè)請(qǐng)求的分層解析流程

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

1.在請(qǐng)求過(guò)程中域名是無(wú)法直接被計(jì)算機(jī)識(shí)別的，必須先轉(zhuǎn)換成ip，此時(shí)先檢測(cè)本地是否配置了host，如果沒(méi)有配置的話會(huì)發(fā)起一個(gè)dns請(qǐng)求。

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

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

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

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

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

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

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

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

??

二、HTTP協(xié)議

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

2.1 HTTP報(bào)文格式

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

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

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

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

2.1.1 HTTP請(qǐng)求報(bào)文

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

??

2.1.1.1 請(qǐng)求行

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

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

2.1.1.2 請(qǐng)求頭部

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

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

2.1.1.3 空行

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

2.1.1.4 請(qǐng)求數(shù)據(jù)

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

2.1.1.5 頭部字段注意事項(xiàng)

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

2.1.2 HTTP響應(yīng)報(bào)文

HTTP響應(yīng)也由三個(gè)部分組成，分別是：狀態(tài)行、消息報(bào)頭、響應(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ù)字組成，第一個(gè)數(shù)字定義了響應(yīng)的類別，且有五種可能取值。

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

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

?3xx：重定向–要完成請(qǐng)求必須進(jìn)行更進(jìn)一步的操作。

?4xx：客戶端錯(cuò)誤–請(qǐng)求有語(yǔ)法錯(cuò)誤或請(qǐng)求無(wú)法實(shí)現(xiàn)。

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

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

?200 OK：客戶端請(qǐng)求成功。

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

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

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

?404 Not Found：請(qǐng)求資源不存在，舉個(gè)例子：輸入了錯(cuò)誤的URL。

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

?503 Server Unavailable：服務(wù)器當(dāng)前不能處理客戶端的請(qǐng)求，一段時(shí)間后可能恢復(fù)正常，舉個(gè)例子：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)實(shí)體內(nèi)容

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

三、HTTP請(qǐng)求完整過(guò)程

3.1 請(qǐng)求過(guò)程描述

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

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

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

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

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

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

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

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

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

?

四、TCP協(xié)議

4.1 TCP協(xié)議描述

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

4.2 TCP協(xié)議特點(diǎn)

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

?全雙工的：雙向傳輸

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

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

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

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

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

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

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

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

4.3 TCP連接管理

4.3.1 TCP連接四元組

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

4.3.2 TCP頭部格式

??

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

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

控制位：

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

RST：該位為 1 時(shí)，表示 TCP 連接中出現(xiàn)異常必須強(qiáng)制斷開(kāi)連接。

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

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

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

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

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

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

4.4 TCP 三次握手

??

說(shuō)明：

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

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

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

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

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

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

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

8.握手過(guò)程中會(huì)消耗序號(hào)，建立鏈接后不會(huì)消耗。

以下是三次握手的示例過(guò)程：

??

4.5 TCP 四次揮手

??

說(shuō)明：

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

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

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

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

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

4.5 TCP 可靠性傳輸

4.5.1 停止等待協(xié)議

描述：沒(méi)傳送一個(gè)報(bào)文，服務(wù)端都回復(fù)一個(gè)確認(rèn)消息，效率低下。

??

4.5.1 重傳機(jī)制

4.5.1.1 ack丟失

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

??

4.5.1.2 報(bào)文丟失

??

4.5.2 滑動(dòng)窗口協(xié)議與累計(jì)確認(rèn)（延時(shí)ack）

??

說(shuō)明：

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

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

3.客戶端收到確認(rèn)后，從3開(kāi)始在滑動(dòng)下一個(gè)窗口，進(jìn)行數(shù)據(jù)傳輸。

參考文獻(xiàn)

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

審核編輯 黃宇