從一個HTTP請求來讀懂HTTP、TCP協議
從一個HTTP請求來看網絡分層原理
兩臺主機間會通過非常多網絡設備，不管哪個網絡設備都會發生數據丟失，如果發生數據丟失的話，會發生數據重傳，會出現數據重復(之前丟失的包并不是丟失而是產生了延時)。數據傳輸的介質也可能多樣，如內網里通過網線進行傳輸，連接到公網的話會通過光纖進行連接，所以要實現不同介質間信號的轉換，還有從光纖到路由器無線脈沖轉換，距離遠的話還有信號衰減問題。所以在網絡傳輸過程中有非常多的問題需要解決，把問題分組分層，不同層次間解決不同問題，不同層次間定義標準化接口讓它們間可以進行數據的通信。
復雜的網絡
為了簡化網絡的復雜度，網絡通信的不同方面被分解為多層次結構，每一層只與緊挨著的上層或者下層進行交互，將網絡分層，這樣就可以修改，甚至替換某一層的軟件，只要層與層之間的接口保持不變，就不會影響到其他層。
- OSI( Open System Interconnection Reference Model): 開放系統互聯參考模型
- TCP/IP 協議族
OSI七層理論體系結構
- 物理層：解決兩臺主機的通信問題—A往B發送比特流(0101)，B能接收到這些比特流。定義了物理設備的標準如網線的類型，光纖的接口類型以及傳輸介質的傳輸速率等。
- 數據鏈路層：由于物理層上的傳輸的比特流可能會出現錯傳、誤傳等，所以數據鏈路層定義了如何格式化數據即將比特流封裝成幀，提供了錯誤檢測。
- 網絡層：隨著節點的增加，點對點通信是需要經過多個節點的，如何找到目標節點，如何找到最優路徑變成為了首要需求。所以出現了網絡層，主要目的是將網絡地址翻譯成對應的物理地址，分組傳輸、路由選擇，本層的傳輸單位是數據報(分組)，本層需要注意的TCP/IP協議中的TCP協議。
- 傳輸層：隨著網絡需要的進一步擴大，通信過程中需要傳輸大量的數據，網絡可能會發生中斷，為了保證傳輸大量文件時的準確性，需要對發送的數據進行切分，切分成一個個的segment進行發送，考慮如何在接受方拼接切分的segment組成完整的數據，以及發現丟失segment時該如何處理，需要注意的協議TCP、UDP。
- 會話層：不同機器上的用戶之間建立以及管理會話。用于保證應用程序自動收發包和尋址。
- 表示層：信息的語義語法，加密解密，轉換翻譯，壓縮解壓縮。
- 應用層：規定雙方必須使用固定長度的消息頭，且消息頭必須記錄消息長度等信息。需要注意的是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特點
- 無狀態：協議對客戶端沒有狀態存儲，對事物處理沒有“記憶”能力，比如訪問一個網站需要反復進行登錄操作。
- 無連接：HTTP/1.1之前，由于無狀態特點，每次請求需要通過TCP三次握手四次揮手，和服務器重新建立連接。比如某個客戶機在短時間多次請求同一個資源，服務器并不能區別是否已經響應過用戶的請求，所以每次需要重新響應請求，需要耗費不必要的時間和流量。
- 基于請求和響應：基本的特性，由客戶端發起請求，服務端響應。
- 簡單快速、靈活。
- 通信使用明文、請求和響應不會對通信方進行確認、無法保護數據的完整性。
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后釋放連接
- 防止報文丟失，導致B重復發送FIN
- 防止滯留在網絡中的報文，對新建立的連接造成數據擾亂
字節流的協議
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以后的報文全要重傳，已確認的報文在緩沖區丟棄掉。
