[[347384]]

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

兩臺(tái)主機(jī)間會(huì)通過非常多網(wǎng)絡(luò)設(shè)備，不管哪個(gè)網(wǎng)絡(luò)設(shè)備都會(huì)發(fā)生數(shù)據(jù)丟失，如果發(fā)生數(shù)據(jù)丟失的話，會(huì)發(fā)生數(shù)據(jù)重傳，會(huì)出現(xiàn)數(shù)據(jù)重復(fù)(之前丟失的包并不是丟失而是產(chǎn)生了延時(shí))。數(shù)據(jù)傳輸?shù)慕橘|(zhì)也可能多樣，如內(nèi)網(wǎng)里通過網(wǎng)線進(jìn)行傳輸，連接到公網(wǎng)的話會(huì)通過光纖進(jìn)行連接，所以要實(shí)現(xiàn)不同介質(zhì)間信號(hào)的轉(zhuǎn)換，還有從光纖到路由器無線脈沖轉(zhuǎn)換，距離遠(yuǎn)的話還有信號(hào)衰減問題。所以在網(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ò)分層，這樣就可以修改，甚至替換某一層的軟件，只要層與層之間的接口保持不變，就不會(huì)影響到其他層。

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

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

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

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

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

http://www.dumain.com 

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

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

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

HTTP

什么是HTTP?

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

HTTP特點(diǎn)

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

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

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

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

請(qǐng)求行報(bào)文格式

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

響應(yīng)報(bào)文格式

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

請(qǐng)求及響應(yīng)報(bào)文格式對(duì)比

HTTP 頭字段

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

段結(jié)束。比如前后分離時(shí)經(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ò)展可能。

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

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

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

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

TCP 協(xié)議

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

TCP特點(diǎn)

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

TCP報(bào)文格式 

• 16位源端口/16位目的端口：負(fù)責(zé)實(shí)現(xiàn)應(yīng)用程序之間的數(shù)據(jù)傳輸
• 32位序號(hào)/32位確認(rèn)序號(hào)：用于實(shí)現(xiàn)tcp在傳輸層的包序管理——tcp有序交付數(shù)據(jù)
• 4位頭部長度：以4個(gè)字節(jié)為單位;4位保存的最大數(shù)字是15;因此tcp報(bào)頭最大長度是15*4=60個(gè)字節(jié)
• 6位保留位;
• 6位標(biāo)志：
• URG——緊急指針標(biāo)志
• ACK——確認(rèn)回復(fù)標(biāo)志
• PSH——提示立即接受位
• RST——重置連接位
• SYN——連接建立請(qǐng)求位
• FIN——斷開連接請(qǐng)求位
• 16位窗口大?。?/strong>滑動(dòng)窗口機(jī)制–>流量控制–>告訴對(duì)端所能發(fā)送的最大數(shù)據(jù)量
• 校驗(yàn)和：二進(jìn)制反碼求和–>校驗(yàn)數(shù)據(jù)一致性
• 緊急指針：指明哪些數(shù)據(jù)是緊急數(shù)據(jù)
• 選項(xiàng)數(shù)據(jù)：三次握手時(shí)，協(xié)商MSS大小的數(shù)據(jù)

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

TCP三次握手

同步通信雙方初始序列號(hào)( ISN, initial sequence number )

協(xié)商TCP通信參數(shù)(MSS, 窗口信息，指定校驗(yàn)和算法)

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

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

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)程的連接請(qǐng)求。然后服務(wù)器進(jìn)程就處于LISTEN(收聽)狀態(tài)，等待客戶的連接請(qǐng)求。若有，則作出響應(yīng)。

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

 

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

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

  

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

tcpdump -i en0 -S -c 3 port 8000 

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

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: 收到請(qǐng)求，開始應(yīng)答 ，避免了A重新發(fā)送FIN重試(應(yīng)答機(jī)制)
• B: 處理完數(shù)據(jù)之后關(guān)閉，關(guān)閉連接,及發(fā)送FIN請(qǐng)求
• A: 收到請(qǐng)求后發(fā)送ACK應(yīng)答，B服務(wù)可以釋放連接

等待 2MSL后釋放連接

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

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

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

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

  

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

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

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

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

 

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

重傳機(jī)制如下：

ack 報(bào)文丟失 

請(qǐng)求報(bào)文丟失

 

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

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

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

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

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