作者公眾號：org_yijiaoqian

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

兩臺主機(jī)間會通過非常多網(wǎng)絡(luò)設(shè)備，不管哪個網(wǎng)絡(luò)設(shè)備都會發(fā)生數(shù)據(jù)丟失，如果發(fā)生數(shù)據(jù)丟失的話，會發(fā)生數(shù)據(jù)重傳，會出現(xiàn)數(shù)據(jù)重復(fù)（之前丟失的包并不是丟失而是產(chǎn)生了延時）。數(shù)據(jù)傳輸?shù)慕橘|(zhì)也可能多樣，如內(nèi)網(wǎng)里通過網(wǎng)線進(jìn)行傳輸，連接到公網(wǎng)的話會通過光纖進(jìn)行連接，所以要實(shí)現(xiàn)不同介質(zhì)間信號的轉(zhuǎn)換，還有從光纖到路由器無線脈沖轉(zhuǎn)換，距離遠(yuǎn)的話還有信號衰減問題。所以在網(wǎng)絡(luò)傳輸過程中有非常多的問題需要解決，把問題分組分層，不同層次間解決不同問題，不同層次間定義標(biāo)準(zhǔn)化接口讓它們間可以進(jìn)行數(shù)據(jù)的通信。

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

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

• • OSI( Open System Interconnection Reference Model): 開放系統(tǒng)互聯(lián)參考模型
  • TCP/IP 協(xié)議族

OSI七層理論體系結(jié)構(gòu)

1. 物理層：解決兩臺主機(jī)的通信問題—A往B發(fā)送比特流（0101），B能接收到這些比特流。定義了物理設(shè)備的標(biāo)準(zhǔn)如網(wǎng)線的類型，光纖的接口類型以及傳輸介質(zhì)的傳輸速率等。
2. 數(shù)據(jù)鏈路層：由于物理層上的傳輸?shù)谋忍亓骺赡軙霈F(xiàn)錯傳、誤傳等，所以數(shù)據(jù)鏈路層定義了如何格式化數(shù)據(jù)即將比特流封裝成幀，提供了錯誤檢測。
3. 網(wǎng)絡(luò)層：隨著節(jié)點(diǎn)的增加，點(diǎn)對點(diǎn)通信是需要經(jīng)過多個節(jié)點(diǎn)的，如何找到目標(biāo)節(jié)點(diǎn)，如何找到最優(yōu)路徑變成為了首要需求。所以出現(xiàn)了網(wǎng)絡(luò)層，主要目的是將網(wǎng)絡(luò)地址翻譯成對應(yīng)的物理地址，分組傳輸、路由選擇，本層的傳輸單位是數(shù)據(jù)報（分組），本層需要注意的TCP/IP協(xié)議中的TCP協(xié)議。
4. 傳輸層：隨著網(wǎng)絡(luò)需要的進(jìn)一步擴(kuò)大，通信過程中需要傳輸大量的數(shù)據(jù)，網(wǎng)絡(luò)可能會發(fā)生中斷，為了保證傳輸大量文件時的準(zhǔn)確性，需要對發(fā)送的數(shù)據(jù)進(jìn)行切分，切分成一個個的segment進(jìn)行發(fā)送，考慮如何在接受方拼接切分的segment組成完整的數(shù)據(jù)，以及發(fā)現(xiàn)丟失segment時該如何處理，需要注意的協(xié)議TCP、UDP。
5. 會話層：不同機(jī)器上的用戶之間建立以及管理會話。用于保證應(yīng)用程序自動收發(fā)包和尋址。
6. 表示層：信息的語義語法，加密解密，轉(zhuǎn)換翻譯，壓縮解壓縮。
7. 應(yīng)用層：規(guī)定雙方必須使用固定長度的消息頭，且消息頭必須記錄消息長度等信息。需要注意的是TCP/IP協(xié)議中的HTTP協(xié)議。

TCP/IP四層模型

是OSI的一種實(shí)現(xiàn)，包括應(yīng)用層、運(yùn)輸層、網(wǎng)際層和網(wǎng)絡(luò)接口層。

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

如上圖右邊一個服務(wù)器部署了一個靜態(tài)頁面，通過Nginx部署在公網(wǎng)上，瀏覽器通過域名對它進(jìn)行訪問，瀏覽器輸入域名點(diǎn)回車后是怎么工作的呢？

http://www.dumain.com

服務(wù)端只認(rèn)ip地址，瀏覽器將域名解析出來，看下瀏覽器里有沒有域名對應(yīng)DNS的緩存，有的話直接拿到服務(wù)端的ip地址，沒有的話去本地的host文件看有沒有配置，沒有配置的話才會發(fā)起一個DNS請求用來獲取服務(wù)器ip地址。

DNS也是臺服務(wù)器也有自己的ip地址，這時候應(yīng)用層會構(gòu)造一個DNS請求報文，應(yīng)用層會去調(diào)用傳輸層的接口一個socket的API，DNS默認(rèn)使用UDP實(shí)現(xiàn)數(shù)據(jù)傳輸，即應(yīng)用層調(diào)用傳輸層的API，傳輸層會在DNS請求報文基礎(chǔ)上加一個UDP的請求頭，傳輸層將數(shù)據(jù)交給網(wǎng)絡(luò)層，網(wǎng)絡(luò)層同樣在UDP請求報文基礎(chǔ)上加IP的請求頭，網(wǎng)絡(luò)層會將IP請求報文交給數(shù)據(jù)鏈路層，數(shù)據(jù)鏈路層會將自己的mac頭加上去并把對應(yīng)的請求報文交給下一個機(jī)器的mac地址也會加上去，下一個機(jī)器的mac地址通過網(wǎng)絡(luò)層ARP協(xié)議找到，ARP會發(fā)送一些請求看下你對應(yīng)的ip地址的mac地址是多少，最后通過物理層物理介質(zhì)傳出去，通常傳到路由器上.

路由器是三層設(shè)備（從下向上）從物理層開始連接，物理層交給數(shù)據(jù)鏈路層，數(shù)據(jù)鏈路層看下地址是不是給我的，是給我的進(jìn)行解析，不是給我的就丟棄，報文再傳給上面一層網(wǎng)絡(luò)層，網(wǎng)絡(luò)層把數(shù)據(jù)傳到下一個路由器的地址是多少，會通過運(yùn)營商的網(wǎng)絡(luò)接口傳到運(yùn)營商的路由器上，運(yùn)營商有自己的DNS服務(wù)器，如果配置的是運(yùn)營商自己的DNS服務(wù)器的話會直接在這個DNS服務(wù)器里找自己對應(yīng)的域名拿到對應(yīng)的ip地址，也就是剛請求DNS報文地址，然后原路返回解析直到應(yīng)用層拿到剛域名對應(yīng)的ip地址，這樣就可以進(jìn)行HTTP請求報文的發(fā)送，再調(diào)用傳輸層協(xié)議是TCP參數(shù)，同樣每到一層加頭。

HTTP

什么是HTTP?

超文本傳輸協(xié)議，是一個基于請求與響應(yīng)，無狀態(tài)的，應(yīng)用層的協(xié)議，常基于TCP/IP協(xié)議傳輸數(shù)據(jù)，互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議,所有的WWW文件都必須遵守這個標(biāo)準(zhǔn)。設(shè)計HTTP的初衷是為了提供一種發(fā)布和接收html頁面的方法。

HTTP特點(diǎn)

1. 無狀態(tài)：協(xié)議對客戶端沒有狀態(tài)存儲，對事物處理沒有“記憶”能力，比如訪問一個網(wǎng)站需要反復(fù)進(jìn)行登錄操作。
2. 無連接：HTTP/1.1之前，由于無狀態(tài)特點(diǎn)，每次請求需要通過TCP三次握手四次揮手，和服務(wù)器重新建立連接。比如某個客戶機(jī)在短時間多次請求同一個資源，服務(wù)器并不能區(qū)別是否已經(jīng)響應(yīng)過用戶的請求，所以每次需要重新響應(yīng)請求，需要耗費(fèi)不必要的時間和流量。
3. 基于請求和響應(yīng)：基本的特性，由客戶端發(fā)起請求，服務(wù)端響應(yīng)。
4. 簡單快速、靈活。
5. 通信使用明文、請求和響應(yīng)不會對通信方進(jìn)行確認(rèn)、無法保護(hù)數(shù)據(jù)的完整性。

HTTP協(xié)議版本已經(jīng)演化到3.0版本，關(guān)于協(xié)議版本可以查看 快速掌握HTTP1.0 1.1 2.0 3.0的特點(diǎn)及其區(qū)別

HTTP報文格式

HTTP 協(xié)議的請求報文和響應(yīng)報文的結(jié)構(gòu)基本相同，由三大部分組成:

• 起始行(start line)：描述請求或響應(yīng)的基本信息
• 頭部字段集合(header)：使用 key-value 形式更詳細(xì)地說明報文
• 消息正文(entity)：實(shí)際傳輸?shù)臄?shù)據(jù)，它不一定是純文本，可以是圖片、視頻等二進(jìn)制數(shù)據(jù)

其中起始行和頭部的字段并成為 請求頭 或者 響應(yīng)頭，統(tǒng)稱為 Header；消息正文也叫實(shí)體，稱為 body。HTTP 協(xié)議規(guī)定每次發(fā)送的報文必須要有 Header，但是可以沒有 body，也就是說頭信息是必須的，實(shí)體信息可以沒有。而且在 header 和 body 之間必須要有一個空行（CRLF）。

請求行報文格式

• 請求方法:如 GET/HEAD/PUT/POST，表示對資源的操作;
• 請求目標(biāo):通常是一個 URI，標(biāo)記了請求方法要操作的資源;
• 版本號:表示報文使用的 HTTP 協(xié)議版本。

響應(yīng)報文格式

• 版本號:表示報文使用的 HTTP 協(xié)議版本;
• 狀態(tài)碼:一個三位數(shù)，用代碼的形式表示處理的結(jié)果，比如 200 是成功，500 是服務(wù)器錯誤;
• 原因:作為數(shù)字狀態(tài)碼補(bǔ)充，是更詳細(xì)的解釋文字，幫助人理解原因。

請求及響應(yīng)報文格式對比

HTTP 頭字段

頭部字段是 key-value 的形式，key 和 value 之間用“:”分隔，最后用 CRLF 換行表示字

段結(jié)束。比如前后分離時經(jīng)常遇到的要與后端協(xié)商傳輸數(shù)據(jù)的類型“Content-type: Application/json”，這里 key 就是“Content-type”，value 就 是“application/json”。HTTP 頭字段非常靈活，不僅可以使用標(biāo)準(zhǔn)里的 Host、 Connection 等已有頭，也可以任意添加自定義頭，這就給 HTTP 協(xié)議帶來了無限的擴(kuò)展可能。

頭字段注意事項

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

HTTP 協(xié)議中有非常多的頭字段，但基本上可以分為四大類：通用標(biāo)頭、實(shí)體標(biāo)頭、請求標(biāo)頭、響應(yīng)標(biāo)頭。

HTTP 頭字段更多內(nèi)容請查看《深入掌握HTTP四種標(biāo)頭基本概念 》

TCP 協(xié)議

TCP(Transmission Control Protocol)，傳輸控制協(xié)議：面向連接的，可靠的，基于字節(jié)流的傳輸層通信協(xié)議。它能幫助你確定計算機(jī)連接到 Internet 以及它們之間的數(shù)據(jù)傳輸。通過三次握手來建立 TCP 連接，三次握手就是用來啟動和確認(rèn) TCP 連接的過程。一旦連接建立后，就可以發(fā)送數(shù)據(jù)了，當(dāng)數(shù)據(jù)傳輸完成后，會通過關(guān)閉虛擬電路來斷開連接。

TCP特點(diǎn)

• 基于連接的：數(shù)據(jù)傳輸之前需要建立連接
  全雙工的：雙向傳輸
• 字節(jié)流：不限制數(shù)據(jù)大小，打包成報文段，保證有序接收，重復(fù)報文自動丟棄
• 流量緩沖：解決雙方處理能力的不匹配
• 可靠的傳輸服務(wù)：保證可達(dá)，丟包時通過重發(fā)機(jī)制實(shí)現(xiàn)可靠性
• 擁塞控制：防止網(wǎng)絡(luò)出現(xiàn)惡性擁塞

TCP報文格式

• 16位源端口/16位目的端口：負(fù)責(zé)實(shí)現(xiàn)應(yīng)用程序之間的數(shù)據(jù)傳輸
• 32位序號/32位確認(rèn)序號：用于實(shí)現(xiàn)tcp在傳輸層的包序管理——tcp有序交付數(shù)據(jù)
• 4位頭部長度：以4個字節(jié)為單位；4位保存的最大數(shù)字是15；因此tcp報頭最大長度是15*4=60個字節(jié)
• 6位保留位；
• 6位標(biāo)志：

• • URG——緊急指針標(biāo)志
  • ACK——確認(rèn)回復(fù)標(biāo)志
  • PSH——提示立即接受位
  • RST——重置連接位
  • SYN——連接建立請求位
  • FIN——斷開連接請求位

• 16位窗口大小：滑動窗口機(jī)制–>流量控制–>告訴對端所能發(fā)送的最大數(shù)據(jù)量
• 校驗和：二進(jìn)制反碼求和–>校驗數(shù)據(jù)一致性
• 緊急指針：指明哪些數(shù)據(jù)是緊急數(shù)據(jù)
• 選項數(shù)據(jù)：三次握手時，協(xié)商MSS大小的數(shù)據(jù)

TCP連接:四元組[ 源地址， 源端口， 目的地址， 目的端口 ]

TCP三次握手

• 同步通信雙方初始序列號( ISN, initial sequence number )
• 協(xié)商TCP通信參數(shù)(MSS, 窗口信息，指定校驗和算法)

在了解具體流程之前，我們先認(rèn)識幾個概念

最初兩端的TCP進(jìn)程都處于CLOSED關(guān)閉狀態(tài)，A主動打開連接，而B被動打開連接。

A、B關(guān)閉狀態(tài)CLOSED — B收聽狀態(tài)LISTEN — A同步已發(fā)送狀態(tài)SYN-SENT — B同步收到狀態(tài)SYN-RCVD— A、B連接已建立狀態(tài)ESTABLISHED

B的TCP服務(wù)器進(jìn)程先創(chuàng)建傳輸控制塊TCB，準(zhǔn)備接受客戶進(jìn)程的連接請求。然后服務(wù)器進(jìn)程就處于LISTEN（收聽）狀態(tài)，等待客戶的連接請求。若有，則作出響應(yīng)。

• SYN：它的全稱是 Synchronize Sequence Numbers ，同步序列編號。是 TCP/IP 建立連接時使用的握手信號。在客戶機(jī)和服務(wù)器之間建立 TCP 連接時，首先會發(fā)送的一個信號。客戶端在發(fā)送 SYN 消息時，就會在自己的段內(nèi)生成一個隨機(jī)值 X。
• SYN-ACK：服務(wù)器收到 SYN 后，應(yīng)答客戶端連接，發(fā)送一個 SYN-ACK作為答復(fù)。確認(rèn)號設(shè)置為比接收到的序列號多一個，即 X + 1，服務(wù)器為數(shù)據(jù)包選擇的序列號是另一個隨機(jī)數(shù) Y。
• ACK： Ackowledge character ，確認(rèn)字符，表示發(fā)來的數(shù)據(jù)已確認(rèn)接收無誤。最后客戶端將 ACK 發(fā)送給服務(wù)器。序列號被設(shè)置為所接收的確認(rèn)值即 Y+ 1。

下面通過一個案例看三次握手是怎么進(jìn)行的

• 在Nginx服務(wù)器部署一個靜態(tài)頁面（我的端口為：8000）

• tcpdump指定網(wǎng)卡進(jìn)行監(jiān)聽抓取報文

tcpdump -i en0 -S -c 3 port 8000

• 在客戶端使用nc網(wǎng)絡(luò)工具發(fā)送一個請求

nc 192.168.109.200 8000

• 三次握手監(jiān)聽結(jié)果如下：

• 內(nèi)核在三次握手做的一些事情，如下：

• 連接狀態(tài)查看

netstat -tpn # t:TCP連接裝，p:進(jìn)程顯示 ，n:數(shù)字形式
# 每秒查看一次
netstat -tpn -c 1

TCP四次揮手

• A: 發(fā)送FIN數(shù)據(jù)包，代表A不再發(fā)送數(shù)據(jù)
• B: 收到請求，開始應(yīng)答 ，避免了A重新發(fā)送FIN重試(應(yīng)答機(jī)制)
• B: 處理完數(shù)據(jù)之后關(guān)閉，關(guān)閉連接,及發(fā)送FIN請求
• A: 收到請求后發(fā)送ACK應(yīng)答，B服務(wù)可以釋放連接

等待 2MSL后釋放連接

1. 防止報文丟失，導(dǎo)致B重復(fù)發(fā)送FIN
2. 防止滯留在網(wǎng)絡(luò)中的報文，對新建立的連接造成數(shù)據(jù)擾亂

字節(jié)流的協(xié)議

TCP把應(yīng)用交付的數(shù)據(jù)僅僅看成是一連串的無結(jié)構(gòu)的字節(jié)流，TCP并不 知道字節(jié)流的含義，TCP并不關(guān)心應(yīng)用程序一次將多大的報文發(fā)送到 TCP的緩存中，而是根據(jù)對方給出的窗口值和當(dāng)前網(wǎng)絡(luò)擁堵的程度來決 定一個報文段應(yīng)該包含多少個字節(jié)。

MSS: Max Segment Size, 默認(rèn) 536byte 實(shí)際數(shù)據(jù)

在網(wǎng)絡(luò)傳輸過程中可能會出現(xiàn)以下的一些情況：

• 客戶端一段時間沒有收到 ack 消息則重傳
• 如果緩沖區(qū)滿了則可能丟包或延時都需要重傳
• 根據(jù)報文 sequeence number 字段重排序，還需要丟棄重復(fù)包。

數(shù)據(jù)傳輸?shù)目煽啃?/h1>

 

停止等待協(xié)議如下：

 

停止等待協(xié)議，效率比較低

 

重傳機(jī)制如下：

• ack 報文丟失

 

• 請求報文丟失

 

滑動窗口協(xié)議與累計確認(rèn)(延時ack)

如上效率低，所以tcp提出了新的協(xié)議-滑動窗口協(xié)議與累計確認(rèn)（延時ack）。

滑動窗口大小同通過tcp三次握手和對端協(xié)商，且受網(wǎng)絡(luò)狀況影響。

上面是一個一個報文，實(shí)際可發(fā)一批報文，服務(wù)器并不是挨個去確認(rèn)，上面回一個ack浪費(fèi)資源，單獨(dú)響應(yīng)一個報文時，tcp本身一個報文至少20個字節(jié)再加上ip頭報文20字節(jié)，所以一個ack至少40字節(jié)。

所以延時ack的發(fā)送，如下圖確認(rèn)最后一個報文如5就可以，但這樣也有一個問題如3的報文丟了，這時只能確認(rèn)1和2連續(xù)報文，從3以后的報文全要重傳，已確認(rèn)的報文在緩沖區(qū)丟棄掉。

 

文章持續(xù)更新，可以公眾號搜一搜「 一角錢技術(shù) 」第一時間閱讀， 本文 GitHub org_hejianhui/JAVAStudy 已經(jīng)收錄，歡迎 Star。