Wireshark理解TCP亂序重組和HTTP解析渲染

TCP數據傳輸過程

TCP亂序重組原理

HTTP解析渲染 

 

TCP亂序重組

TCP具備亂序重組的功能。
（1）TCP具備緩衝區
（2）TCP報文具備序列號
因此，對於你說的問題，一種常見的處理方式是：TCP會先將報文段3緩存下來，當報文段2到達時，再根據序列號進行拼接。
2 固然緩衝區也有滿的時候，這時接收端會直接丟棄報文，不作任何其餘處理；
發送方的定時器發現遲遲收不到接收方丟棄報文的確認號（ack number），就會重傳該報文。這就是TCP的超時重傳功能

Sequence Number是包的序號，用來解決網絡包亂序（reordering）問題。
Acknowledgement Number就是ACK——用於確認收到，用來解決不丟包的問題。
MTU: Maxitum Transmission Unit 最大傳輸單元
MSS: Maxitum Segment Size 最大分段大小

對於建連接的3次握手，主要是要初始化Sequence Number 的初始值。通訊的雙方要互相通知對方本身的初始化的Sequence Number（縮寫爲ISN：Inital Sequence Number）——因此叫SYN
全稱Synchronize Sequence Numbers。也就上圖中的 x 和 y。
這個號要做爲之後的數據通訊的序號，以保證應用層接收到的數據不會由於網絡上的傳輸的問題而亂序
（TCP會用這個序號來拼接數據）。

網絡文件時流量巨大，出現不少
TCP segment of a reassembled PDU
其實主機響應一個查詢或者命令時若是要回應不少數據（信息）而這些數據超出了TCP的最大MSS時，
主機會經過發送多個數據包來傳送 這些數據（注意：這些包並未被分片）
。對wireshark來講這些對相應同一個查詢命令的數據包被標記了「TCP segment of a reassembled PDU」

問題，wireshark如何識別多個數據包是對同一個查詢數據包的響應?
wireshark是根據sequence number來識別，這些數據包ACK number是相同的，
固然number的數值與查詢數據包中的next sequence number也是同樣的。
對於TCP協議而言就不同了，這個協議是面向鏈接的協議，
對於TCP協議而言它很是在乎數據包的到達順序以及是否傳輸中有錯誤發生。因此有些TCP應用對分片有要求---不能分片（DF）。

這個仍是取決於對TCP協議的理解，參照TCP序列號和確認號詳解，講解很清晰

基於本身理解

Statistics ->Flow Graph

重點講數據傳輸過程：

TCP數據傳輸過程

1)  發送數據：服務器向客戶端發送一個帶有數據的數據包，該數據包中的序列號Seq和確認號Ack與創建鏈接第三步的數據包中的序列號和確認號相同；

如上圖Seq=1 ACK=1 

2)  確認收到：客戶端收到該數據包，向服務器發送一個確認數據包，該數據包中，序列號是爲上一個數據包中的確認號值，而確認號爲服務器發送的上一個數據包中的序列號+所該數據包中所帶數據的大小。

如上圖Seq=1 Ack=999　　　　Seq(x)=Ack(y)  1 　　Ack(x)=Seq(x)+998 (data len) 　999　 　　　　 c——》s

　　Seq=999 Ack=1381　　　Seq(y)=Ack(x)  999   Ack(y)=Seq(y)+1381(data len) 　1381  　　　　 s——》c

　　Seq=1381　Ack=999 　　Seq(x)=Ack(y) 1381  Ack(x)=Seq(x)+998 (data len)　 999　　　        c——》s　

　　Seq=999　 Ack=2761     Seq(y)=Ack(x)  999  Ack(y)=Seq(y)+1381(data len)     2761　  　　　  s——》c
　　SeqNum的增長是和傳輸的字節數相關的, 數據分段中的序列號Seq能夠保證全部傳輸的數據按照正常的次序進行重組，並且經過確認保證數據傳輸的完整性。

　　上圖中，三次握手後，來了兩個Len:1381的包，而第二個包的SeqNum就成了1381。而後第一個ACK回的是1381，表示第一個1381收到了,第二個Ack回的是 2761，表示第二個1381收到了

注意：1.Wireshark使用了Relative SeqNum——相對序號，以便更容易觀察，在protocol preference 中取消掉就能夠看到「Absolute SeqNum」。

　　   2.服務器端處理一次客戶端請求，發送的多個數據包的ACK是相同的，如上，均爲999

　　　3.ack遞增，seq鏈接（開始的位置），只須要Seq便可重組。

　

TCP亂序重組原理

對於亂序和擁塞，TCP的處理：

　Tcp引入快速重傳機制，不以時間驅動而是以數據驅動重傳。若是包沒有連續到達，就ack可能被丟了的包，若是發送方連續收到3次相同的ACK，就重傳，這樣就不等timeout就重傳了。並且對於亂序報文不丟棄，而是緩存下來（減小重傳）當即發送但願接受的報文確認。

　　例子：

　　發送端A發送瞭如下幾個包：第一個：1001－1100，第二個1101－1200，第三個FIN包(序列號是1201，一個虛字節)。
　　1）第二個包在傳輸的過程當中丟失了，接收端收到第三個包後並不丟棄，而是緩存下來，而後，當即發送一個ACK，確認號是1101（這樣作的目的是沒必要等到發送端A的第二個包超時後重傳，發送端A收到3個一樣的ACK後當即重傳，這是快速重傳的概念）。
　　2）當發送端A收到3個確認號都是1101或者第二個包的超時計時器到時間後，當即從新發送第二個包（之因此能夠重傳，是由於TCP協議在接收端和發送端都各自創建了兩個發送、接收緩存）。
　　3）這樣，當接收端B收到來自A的第二個包後，緩存中的數據都是按序的了。
　　4）對於按序包，接收端B對序列號的最後一個字節+1，也就是發送確認號是1202的ACK包。

　　5）發送端A收到確認號是1202後，便不能再發送任何數據了。

快速重傳：

　　若是發送方發出了1，2，3，4，5份數據，第一份先到送了，因而就ack回2，結果2由於某些緣由沒收到，3到達了，因而仍是ack回2，後面的4和5都到了，可是仍是ack回2，由於2仍是沒有收到，因而發送端收到了三個ack=2的確認，知道了2尚未到，因而就立刻重轉2。而後，接收端收到了2，此時由於3，4，5都收到了，因而ack回6。

　　接收端收到每一個包，都要發送ACK給服務器端，那麼若是是亂序的話，在接收端作判斷，發送亂序的包的ACK給服務器，(在wireshark中體現爲duplicate ACK )，表示收到一個出問題的分片，TCP當即產生一個應答，這個相同的ACK不會延遲，以告訴服務器端知道一個分片被收到的時候出現問題，而且告訴它但願獲得的序列號，服務器若是收到這樣三次相同的ACK包，則當即重傳。可是重傳成功前，又出現這樣的狀況，那麼丟失的不止一個包，但服務器收到的ACK依然沒有增加。

　　對於上面的示例來講，是重傳#2呢仍是重傳#2，#3，#4，#5呢？由於發送端並不清楚這連續的3個ack(2)是誰傳回來的？也許發送端發了20份數據，是#6，#10，#20傳來的呢。這樣，發送端頗有可能要重傳從2到20的這堆數據（這就是某些TCP的實際的實現）。

　　猜想是在接收端根據序列號進行排序，一接收到重傳的數據包便進行重組，而且seq number增長，立刻發ACK給服務器端。

在127 125位置亂序

　　服務器發送過來的seq按照順序來遞增，客戶端的seq根據接收到的數據包正確的順序來遞增，ack根據上一次數據包的序列號+此次傳輸數據包的大小來遞增，若是接收到有問題的包，則seq和ack不變，每次都發送相同的seq和ack給服務器端，如71和73.包括以後收到seq不按順序遞增的包，客戶端仍是發送相同的ack給服務器端，因此服務器端識別不了具體是哪一個有問題的數據包發送的，只跟初始有問題的數據包有關係。

　　返回服務器端的確認編號其實是客戶端但願收到的序列號。

 

duplicate ACK。接下來幾個報文重複此過程，直到接收到缺失的數據包

TCP Previous Segment Lost，看Frame流程，17940--20699的包沒有按序到達，然後發的包居然先到了，亂序了，後續127重傳的包就是缺乏的包。

71和73的seq和ack是同樣的

接收到125的數據包後，ack遞增，估計是在客戶端進行重組後的結果，發送ack表示已經重組好多少數據，服務器繼續發送以起始位置爲17941的數據包，即爲127。至此，在127以前的數據已經重組完畢。

 另外，若是標記爲 「TCP out of order」，則是後到的包，通常不超過「TCP Dup Ack **#3」（？）。

 

HTTP解析渲染 

　　剛開始認爲http在發出請求後，會併發創建TCP鏈接，鏈接數基本不變，但實際狀況並不是如此，這就涉及到瀏覽器對HTTP的加載、解析、渲染的過程：

1. 用戶訪問網頁，DNS服務器（域名解析系統）會根據用戶提供的域名查找對應的IP地址，找到後，系統會向對應IP地址的網絡服務器發送一個http請求。
2. 網絡服務器解析請求，併發送請求給數據庫服務器。
3. 數據庫服務器將請求的資源返回給網絡服務器，網絡服務器解析數據，並生成html文件，放入http response中，返回給瀏覽器。
4. 瀏覽器解析 http response。
5. 1~4步驟須要瞭解HTTP協議。
6. 訪問服務器端可能遭遇的問題：若是網絡服務器沒法獲取數據庫服務器返回的資源文件（http response 404），或者因爲併發緣由暫時沒法處理用戶的http請求（http response 500）
7. 瀏覽器解析 http response後，須要下載html文件，以及html文件內包含的外部引用文件，及文件內涉及的圖片或者多媒體文件。

加載：當瀏覽器得到一個html文件時，「自上而下」加載，加載過程當中進行解析渲染。

資源間互相阻塞

　　IE下載的順序是從上到下，渲染的順序也是從上到下，下載和渲染是同時進行的。在渲染到頁面的某一部分時，其上面的全部部分都已經下載完成（但並非說全部相關聯的元素都已經下載完。）在下載過程當中，若是遇到某一標籤是嵌入文件，而且文件是具備語義解釋性的（例如：JS腳本，CSS樣式），那麼此時IE的下載過程會啓用單獨鏈接進行下載。而且在下載後進行解析，解析（JS、CSS中若有重定義，後定義函數將覆蓋前定義函數）過程當中，中止頁面全部往下元素的下載。樣式表文件比較特殊，在其下載完成後，將和之前下載的全部樣式表一塊兒進行解析，解析完成後，將對此前全部元素（含之前已經渲染的）從新進行樣式渲染。並以此方式一直渲染下去，直到整個頁面渲染完成。

瀏覽器加載、解析、渲染過程

Nignix一次完整的HTTP事務