記一次HTTP/TCP數據報的探究

探究背景：咱們常常說TCP是傳輸層協議，IP是網絡層協議，HTTP協議是應用層協議等等，那麼究竟他們三者是如何融洽的工做在一塊兒的呢？咱們今天主要來實驗探究一下TCP和HTTP究竟是怎麼結合的。

實驗環境：

         server：192.168.254.136，使用httpd做爲web服務，複製nginx的首頁靜態頁做爲demo

         client：192.168.254.1，wireshark抓包

實驗步驟：

         從客戶端訪問服務器端，抓取數據包。

報文摘錄：

報文分析：

         1、第一步，老生成談的TCP三次握手機制，先進行了三次握手，而後創建鏈接，此處再也不展開。

         2、接下來，4號數據包是客戶端向服務器端發送HTTP的get請求，內容略。

         3、而後是此次我要說的重點部分了。4號報文是客戶端向服務器端發送了請求，那麼5號報文則開始響應此次請求，第一個TCP包並無包含任何有效載荷，只有一個60字節的TCP頭。咱們展開這個報文看看60字節包含什麼。

                   目的mac：6B

                   源mac：    6B

                   ipv4類型：2B

------------------------------------------------------------------------------------------------------------------------------

                   IP版本：  0.5B

                   頭部長度：0.5B

                   服務類型：1B

                   總長度：  2B

                   標識：    2B

                   標誌：3bits片偏移：13bits 共2B

                   TTL：     1B

                   協議：    1B

                   校驗和：  2B

                   源IP：    4B

                   目的IP：  4B

-------------------------------------------------------------------------------------------------------------------------------

                   源端口：  2B

                   目的端口：2B

                   序列號：  4B

                   確認號：  4B

                   頭部長度：0.5B

                   保留字段：6bits

                   URG/ACK/PSH/RST/SYN/FIN各1bit

                   窗口大小：2B

                   校驗和：  2B

                   緊急指針：2B

--------------------------------------------------------------------------------------------------------------------------------

                   padding：6B   填充字段，放置在數據鏈路層中。

 

IP報文分析：

4位版本號：IP協議（IPv4）版本號位4

4位頭部長度：標識頭部有多少個4字節，即最大共15*4個字節

8位服務類型：包含一個4位優先權字段：最小延時，最大吞吐量，最高可靠性和最小費用。

16位總長度：表示整個IP數據報的長度，最大表示65535，但因爲MTU限制，通常沒法到達這個值。

16位標識：惟一的標識數據報。系統採用加1的方式邊發送邊賦值。

3位標識（保留，DF禁止分片，MF更多分片）：因此這個標誌是爲分片存在，DF設置時禁止分片因此若是數據報太大則發送失敗。MF設置時，若是產生分片，除了最後一個分片，其餘此片置1。

13位分片偏移：分片相對原始IP數據報開始處的偏移。

8位生存時間（TTL）：數據報到達目的地以前容許通過的路由跳跳數。跳一下減1，得0丟棄。

8位協議：用來區分上層協議（ICMP爲1，TCP爲6，UDP爲17）。

16位頭部校驗和：僅以CRC算法檢驗數據報頭部在傳輸過程當中是否損壞。

32位源IP和目的IP。

 

TCP報文分析：

16位源端口號和16位目的端口號。

32位序號：一次TCP通訊過程當中某一個傳輸方向上的字節流的每一個字節的編號，經過這個來確認發送的數據有序，好比如今序列號爲1000，發送了1000，下一個序列號就是2000。

32位確認號：用來響應TCP報文段，給收到的TCP報文段的序號加1，三握時還要攜帶本身的序號。

4位頭部長度：標識該TCP頭部有多少個4字節，共表示最長15*4=60字節。同IP頭部。

6位保留。6位標誌。URG（緊急指針是否有效）ACK（表示確認號是否有效）PSH（提示接收端應用程序應該當即從TCP接收緩衝區讀走數據）RST（表示要求對方從新創建鏈接）SYN（表示請求創建一個鏈接）FIN（表示通知對方本端要關閉鏈接）

16位窗口大小：TCP流量控制的一個手段，用來告訴對端TCP緩衝區還能容納多少字節。

16位校驗和：由發送端填充，接收端對報文段執行CRC算法以檢驗TCP報文段在傳輸中是否損壞。

16位緊急指針：一個正的偏移量，它和序號段的值相加表示最後一個緊急數據的下一字節的序號。

 

分析完這60個字節的TCP報文以後再接着看6號報文，這個一樣是服務器端發送給客戶端的TCP報文，與上一個報文看看有何不一樣。咱們來逐個對比一下上述字段。

首先就是整個IP數據報的長度不同了，一個是40一個是1500，而後標識不同了，由17800變成了17801，驗證了剛剛說的自增的方式排序。固然校驗和確定也就不同了，因此IP數據報文只有這兩處不一樣，不算校驗和。

TCP報文中前面部分除了校驗和均相同，只是在最後附加了一個1460字節的數據字段，那麼多個數據包之間有什麼聯繫呢？

咱們單獨看5-8這幾個包，當客戶端發出請求後，服務器端先發送一個空的TCP包，因此Seq=1，Len=0，下一個包的Seq仍然是1，可是長度變成了1460，那麼第三個TCP包的Seq則爲1+1460，即Seq2=Seq1+Len。而ACK不變，那麼客戶端接受以後發送反饋包，Seq爲服務器端的Ack數字，Ack爲上一個數據包的Seq+Len，即1461+1460=2921。

而後服務器端繼續向客戶端發送數據，9號報文的序列號爲2921，是客戶端響應報文中的Ack，Ack仍然是370，長度爲1460。10號報文的Seq也是9號報文的Seq+Len=2921+1460=4381，11號爲客戶端響應報文，Seq保持370不變，Ack爲4381+1460=5841。

一樣的道理，下面三個數據包也符合這個規律。最後傳輸完畢，第15個報文組成一段完整的HTTP報文。

可是須要注意的是，儘管第15個包在wireshark裏是寫的HTTP，但實際上這個包也是TCP的數據包，包含TCP的數據！

咱們來看，前四行都是和普通的TCP報文是同樣的，而且長度爲1431，不足1460，說明傳輸完成了。

最後兩行是HTTP報文，也就是說收到了所有的TCP傳輸報文，併合併爲一個完整的HTTP應答報文。

而後TCP四次斷開，再也不詳解。提示一點就是，16號包Seq是15號包中的Seq+Len 即：10192=8761+1431，17號包的Ack是16號包的Seq+1