一、看圖說話

1、基於套接字的TCP伺服器/客戶端程式流程

2、TCP三次握手建立連線

3、TCP四次互動斷開連線

4、TCP狀態轉移圖

這張圖看不懂的話解釋在計算機網路第四版P274。解釋下MSL：最長分節生存週期，他代表了IP資料報載網路上的最長生命週期。保證該連線上的資料包在網路中全部消失。

二、TCP重傳

1、重傳的原因

1）發端計時器超時

TCP每傳送一個報文段，就對這個報文段設定一次計時器。當計時器超時而沒有收到確認時，就重傳該報文。

注：原來報文哪去了呢？兩種可能：1）在中間節點丟了。2）還在路上，走的慢。

對於第一種情況：接收端是不知情的，而對於第二種情況，接收端表現為收到兩個一摸一樣的報文。

2）快重傳

原理說明：自己來張圖吧。

就是說在傳送端一連收到4個ack報文，其中3個重複報文時，就立即重傳相應的報文而不等到定時器超時。

注：1）原來報文的去向以上同。

2）重傳報文可以與原報文不同，就是說重傳報文長度可以比原報文長也可以比原報文短等。

3）說明下逆序問題。還沒到快重傳的時候，走丟的包就出現了。這時候接收端保留逆序包，傳送端不用對其進行重傳。

2、重傳的判定

TCM監測點要求計算一次HTTP過程的重傳率，公式：重傳率=重傳報文數/有效報文數

其中有效報文數：指的是除了純ACK包外的報文總數。因為純ACK包沒有重傳的說法。

重傳報文的判定分雙向進行，現在的演算法（簡要說明）：

設定一個變數MaxSeq，初始化為0.每來一個包，檢視其seq，如果該seq大於MaxSeq，則

MaxSeq = seq，否則判定為重傳包。

該演算法的缺點：目前看到的情況，無法區分逆序後來的包和重傳包。如同逆序圖所示:其實M3只是遲到了，並沒有重傳，但我們的演算法卻把它判定為重傳報文。

不知有人對這個問題有所研究沒，歡迎發表意見。

三、因重傳引起的問題

1. 在測量過程中發現某個網站TCP連線的重置率特別高，抓包後發現，原來都是重傳惹的禍（FIN ACK包重傳）。

圖示：

對照狀態圖，可以理解當伺服器收到客戶端第一個Ack報文時，該次TCP連線就關閉了。再次收到ACK