2020.04.27
- 客戶端從FIN_WAIT_1狀態直接進入TIME_WAIT狀態的情況：服務端發送帶確認信息的結束報文段，相當於此時服務端沒有數據需要繼續傳輸。
- 鏈接長時間停留在FIN_WAIT_2狀態的情況：客戶端執行半關閉後，未等待服務器關閉便強行退出。此時客戶端鏈接將有內核接管，相當於孤兒鏈接。
- TIME_WAIT的原因：
- 1）防止發送的確認報文丟失導致服務端無法正常關閉鏈接。服務器未收到客戶端確認報文時會不斷重發結束報文 ，而因爲客戶端已經關閉，所以只回複復位報文，而服務器會認爲這是一個錯誤；
- 2）一個TCP端口不允許被同時打開多次，當處於TIME_WAIT狀態時不允許使用當前端口建立新的連接。如果沒有TIME_WAIT，則應用程序可以立即建立一個和剛關閉的鏈接相似的鏈接（相同的IP和端口），成爲原來連接的化身，此時新的化身可能收到屬於原來連接的、遲到的、攜帶應用程序數據的TCP報文段，這顯然時不應該發生的。
- TIME_WAIT = 2MSL的原因：確保鏈接兩個方向上的TCP報文段全部消失（被路由丟棄），一個化身可以在2MSL後安全的建立。
- 發送復位報文段的情況：
- 訪問不存在的端口，復位報文將RST置1，同時報文中的接收通知窗口爲0，表示收到報文段的一端應該關閉鏈接；
- 異常終止鏈接，給對方直接發送復位報文段，觸發異常終止，此時發送方的所有等待發送的數據都將被丟棄；
- 處理半打開鏈接： 服務端關閉或者異常終止鏈接，而對方沒有收到結束報文段，此時客戶端仍然維持着鏈接狀態，而服務端已經斷開。此時客戶端向半打開狀態的鏈接寫入數據時，服務器將回複復位報文。
- TCP應用程序數據
- 交互數據流：使用交互數據流的應用對高實時性有較高要求，如telnet、ssh等。交互數據僅包含很少的字節，而且由於服務器的處理速度遠快於客戶端的請求速度，所以採取延遲響應（收到客戶端報文後不立即確認，而是在一段延遲後，將本端需要發送的數據和確認報文一起發出），使用Nagle算法減少因爲小報文段過多引起的擁塞。
- 成塊數據流：使用交互數據流的應用對傳輸效率有較高要求，如ftp等。成塊數據的長度通常爲TCP報文段允許的最大數據長度。發送方可以一次發送多個報文段（由接收通告窗口和擁塞窗口決定），接收方可一次確認多個報文段。
- TCP確認重傳：內核參數規定了報文最少和最多重傳次數。每次重傳的間隔時間乘2 。
2020.04.28
擁塞控制
TCP的擁塞控制四個方面：慢啓動、擁塞避免、快重傳、快恢復，linux系統下有很多的實現，如reno算法、vegas算法等。
擁塞控制的最終受控變量是發送端向網絡一次連續寫入的數據量，稱爲SWND(Send Window)，限定了發送端一次發送的TCP報文段數量，這些TCP報文段的最大長度稱爲SMSS（Sender Maximum Segment Size，發送者最大段長度）一般等於MSS。實際上SWND的大小由RWND（接收端通告窗口）和CWND（Congestion Window，擁塞窗口）共同決定，一般取更小值。
- 慢啓動和擁塞避免
CWND設置初值爲IW，一般爲SSMS的2~4倍，此後每接收到一個確認，就更新爲CWND += min(N,SMSS)，N是此次確認中包含的之前的未被確認的字節數，CWND按這種方式實際上是指數級增大。
爲了避免CWND過大，擁塞控制定義了慢啓動門限（slow start threshold size, ssthresh）,當CWND超過ssthresh時進入擁塞避免階段，呈線性增大，以ssrhresh爲16SMSS爲例：
![在這裏插入圖片描述]()
當發送端判斷網絡發生擁堵時，即：- 傳輸超時，即超時未確認，此時仍然使用慢啓動和擁塞避免；
- 收到重複的確認報文段，此時使用快重傳和快恢復。
發生上述第一種情況時，作出如下調整ssthresh = max(FlightSize/2, 2*SMSS), CWND <= SMSS，FlightSize是已發送但未收到確認的字節數，這樣調整使得CWND小於ssthresh，再次進入慢啓動階段
- 快重傳和快恢復
當TCP報文段丟失，或者接收端收到亂序的TCP報文段時，發送端都有可能收到重複確認，如果發送端收到三個重複的確認報文段時，就認爲此時發生了擁塞，然後啓動快重傳和快恢復算法：
1）收到三個重複確認時，按照ssthresh = max(FlightSize/2, 2*SMSS)更新ssthresh，立即重傳丟失報文段；
2）每次收到一個重複確認時，設置CWND=CWND+SMSS；
3）收到新數據的確認時，設置CWND=ssthresh。
由上可知，快重傳和快恢復後，擁塞控制將進入擁塞避免階段。
