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序列號和確認號詳解，講解很清晰
基於自己理解
重點講數據傳輸過程：
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的加載、解析、渲染的過程：
- 用戶訪問網頁，DNS服務器（域名解析系統）會根據用戶提供的域名查找對應的IP地址，找到后，系統會向對應IP地址的網絡服務器發送一個http請求。
- 網絡服務器解析請求，並發送請求給數據庫服務器。
- 數據庫服務器將請求的資源返回給網絡服務器，網絡服務器解析數據，並生成html文件，放入http response中，返回給瀏覽器。
- 瀏覽器解析 http response。
- 1~4步驟需要了解HTTP協議。
- 訪問服務器端可能遭遇的問題：如果網絡服務器無法獲取數據庫服務器返回的資源文件（http response 404），或者由於並發原因暫時無法處理用戶的http請求（http response 500）
- 瀏覽器解析 http response后，需要下載html文件，以及html文件內包含的外部引用文件，及文件內涉及的圖片或者多媒體文件。
加載：當瀏覽器獲得一個html文件時，“自上而下”加載，加載過程中進行解析渲染。
資源間互相阻塞
IE下載的順序是從上到下，渲染的順序也是從上到下，下載和渲染是同時進行的。在渲染到頁面的某一部分時，其上面的所有部分都已經下載完成（但並不是說所有相關聯的元素都已經下載完。）在下載過程中，如果遇到某一標簽是嵌入文件，並且文件是具有語義解釋性的（例如：JS腳本，CSS樣式），那么此時IE的下載過程會啟用單獨連接進行下載。並且在下載后進行解析，解析（JS、CSS中如有重定義，后定義函數將覆蓋前定義函數）過程中，停止頁面所有往下元素的下載。樣式表文件比較特殊，在其下載完成后，將和以前下載的所有樣式表一起進行解析，解析完成后，將對此前所有元素（含以前已經渲染的）重新進行樣式渲染。並以此方式一直渲染下去，直到整個頁面渲染完成。