[[347384]]

 從一個HTTP請求來看網絡分層原理

兩臺主機間會通過非常多網絡設備，不管哪個網絡設備都會發生數據丟失，如果發生數據丟失的話，會發生數據重傳，會出現數據重復(之前丟失的包并不是丟失而是產生了延時)。數據傳輸的介質也可能多樣，如內網里通過網線進行傳輸，連接到公網的話會通過光纖進行連接，所以要實現不同介質間信號的轉換，還有從光纖到路由器無線脈沖轉換，距離遠的話還有信號衰減問題。所以在網絡傳輸過程中有非常多的問題需要解決，把問題分組分層，不同層次間解決不同問題，不同層次間定義標準化接口讓它們間可以進行數據的通信。

復雜的網絡

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

• OSI( Open System Interconnection Reference Model): 開放系統互聯參考模型
• TCP/IP 協議族

OSI七層理論體系結構

 

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

TCP/IP四層模型 

是OSI的一種實現，包括應用層、運輸層、網際層和網絡接口層。

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

如上圖右邊一個服務器部署了一個靜態頁面，通過nginx部署在公網上，瀏覽器通過域名對它進行訪問，瀏覽器輸入域名點回車后是怎么工作的呢？

http://www.dumain.com 

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

DNS也是臺服務器也有自己的ip地址，這時候應用層會構造一個DNS請求報文，應用層會去調用傳輸層的接口一個socket的API，DNS默認使用UDP實現數據傳輸，即應用層調用傳輸層的API，傳輸層會在DNS請求報文基礎上加一個UDP的請求頭，傳輸層將數據交給網絡層，網絡層同樣在UDP請求報文基礎上加IP的請求頭，網絡層會將IP請求報文交給數據鏈路層，數據鏈路層會將自己的mac頭加上去并把對應的請求報文交給下一個機器的mac地址也會加上去，下一個機器的mac地址通過網絡層ARP協議找到，ARP會發送一些請求看下你對應的ip地址的mac地址是多少，最后通過物理層物理介質傳出去，通常傳到路由器上.

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

HTTP

什么是HTTP?

超文本傳輸協議，是一個基于請求與響應，無狀態的，應用層的協議，常基于TCP/IP協議傳輸數據，互聯網上應用最為廣泛的一種網絡協議,所有的WWW文件都必須遵守這個標準。設計HTTP的初衷是為了提供一種發布和接收HTML頁面的方法。

HTTP特點

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

HTTP協議版本已經演化到3.0版本，關于協議版本可以查看 快速掌握HTTP1.0 1.1 2.0 3.0的特點及其區別

HTTP報文格式

HTTP 協議的請求報文和響應報文的結構基本相同，由三大部分組成:

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

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

請求行報文格式

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

響應報文格式

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

請求及響應報文格式對比

HTTP 頭字段

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

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

頭字段注意事項

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

HTTP 協議中有非常多的頭字段，但基本上可以分為四大類：通用標頭、實體標頭、請求標頭、響應標頭。

HTTP 頭字段更多內容請查看《深入掌握HTTP四種標頭基本概念 》

TCP 協議

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

TCP特點

• 基于連接的：數據傳輸之前需要建立連接
• 全雙工的：雙向傳輸
• 字節流：不限制數據大小，打包成報文段，保證有序接收，重復報文自動丟棄
• 流量緩沖：解決雙方處理能力的不匹配
• 可靠的傳輸服務：保證可達，丟包時通過重發機制實現可靠性
• 擁塞控制：防止網絡出現惡性擁塞

TCP報文格式 

 

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

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

TCP三次握手

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

協商TCP通信參數(MSS, 窗口信息，指定校驗和算法)

在了解具體流程之前，我們先認識幾個概念  

最初兩端的TCP進程都處于CLOSED關閉狀態，A主動打開連接，而B被動打開連接。

A、B關閉狀態CLOSED — B收聽狀態LISTEN — A同步已發送狀態SYN-SENT — B同步收到狀態SYN-RCVD— A、B連接已建立狀態ESTABLISHED

B的TCP服務器進程先創建傳輸控制塊TCB，準備接受客戶進程的連接請求。然后服務器進程就處于LISTEN(收聽)狀態，等待客戶的連接請求。若有，則作出響應。

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

 

下面通過一個案例看三次握手是怎么進行的

在Nginx服務器部署一個靜態頁面(我的端口為：8000) 

  

tcpdump指定網卡進行監聽抓取報文

tcpdump -i en0 -S -c 3 port 8000 

在客戶端使用nc網絡工具發送一個請求

nc 192.168.109.200 8000 

三次握手監聽結果如下： 

 

內核在三次握手做的一些事情，如下： 

 

連接狀態查看

netstat -tpn # t:TCP連接裝，p:進程顯示 ，n:數字形式 
 
# 每秒查看一次 

netstat -tpn -c 1 

 

TCP四次揮手 

 

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

等待 2MSL后釋放連接

1. 防止報文丟失，導致B重復發送FIN
2. 防止滯留在網絡中的報文，對新建立的連接造成數據擾亂

字節流的協議

TCP把應用交付的數據僅僅看成是一連串的無結構的字節流，TCP并不 知道字節流的含義，TCP并不關心應用程序一次將多大的報文發送到 TCP的緩存中，而是根據對方給出的窗口值和當前網絡擁堵的程度來決 定一個報文段應該包含多少個字節。

MSS: Max Segment Size, 默認 536byte 實際數據 

  

在網絡傳輸過程中可能會出現以下的一些情況：

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

數據傳輸的可靠性

停止等待協議如下：  

 

停止等待協議，效率比較低

重傳機制如下：

ack 報文丟失 

請求報文丟失

 

滑動窗口協議與累計確認(延時ack)

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

滑動窗口大小同通過tcp三次握手和對端協商，且受網絡狀況影響。

上面是一個一個報文，實際可發一批報文，服務器并不是挨個去確認，上面回一個ack浪費資源，單獨響應一個報文時，tcp本身一個報文至少20個字節再加上ip頭報文20字節，所以一個ack至少40字節。

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