注意事項：

1.TCP發送窗口是由對方發回的報文段(窗口大小，ack)設置的但是同一時刻發送窗口接收窗口大小未必相等(當接收方發回一個報文窗口大小改變但由于網絡時延發送方窗口值可能不變)。

2.接收方應該有累計確認功能這樣可以減小傳輸開銷。

3.TCP是全雙工通信，所以兩端都有發送窗口和接收窗口。

3.2、發送緩沖區和接收緩沖區

發送窗口只是發送緩沖區的一部分，發送緩沖區通常包括發送方應用程序傳送給發送方TCP準備發送的數據。這里面包括已發送但還未收到確認的數據和未發送但在發送窗口的數據以及未發送但不再發送窗口的數據。

接收緩沖區包含了按序到達但尚未被應用程序讀取的數據，不按序到達以及尚未進入接收窗口的數據。

4、TCP的流量控制

4.1、流量控制介紹

發送方一次發送的字節數量不要太多要讓對方來的及接收。接收方是通過調整滑動窗口來進行流量控制的。

?來看下面這樣一個實例A為發送方，B為接收方。B的接收窗口由400字節。

?首先A向B發送了一個序號為1的100字節的數據(1~100)。此時B的接收窗口還剩300字節。

?然后A向B發送了序號為101的100字節數據(101~200).此時B的接收窗口還剩200字節。

?然后A向B發送了序號為201的100字節的數據(201~300)但是這個報文丟失了。

?此時B向A發送一個回復報文ACK = 201說明我已經接收1200字節的數據下一次要從201開始發。同時進行了一次流量控制即rwnd = 300也就是說B能接收300字節。所以A要發送201500的報文。

?A已經發送過201的報文了所以它連續發送301,401的報文此時他知道201發送失敗進行超時重傳。

?這時A收到了B成功收到401的報文下一次要從501開始發而且又進行了一次流量控制rwnd = 100還能接收100字節的數據。

?然后A又繼續發送了一個序號為501的報文，然后A停止發送。然后收到了B返回的回復序號為601滑動窗口置為0的報文。

4.2、死鎖問題及解決

接上文，過了一段時間后B的接收緩存又有了一些存儲空間。這時候會向A發送一個報文下次發送的序號為601，rwnd=400滑動窗口。但是如果這個報文丟失那么就會造成A不知道B中滑動窗口更新的消息那么就永遠不會向B發送報文。

解決方案：TCP為每個連接都設置了一個持續計時器。只要收到對方的零窗口通知，就啟動該持續計時器：

持續計時器到期發送一個零窗口探測報文段，對方再確認這個探測報文段時給出現在的窗口值如果窗口值仍然是0，接收方確認報文方重新設置持續計數器；若窗口不是0，死鎖的僵局便被打破了。

5、TCP的效率問題

5.1、TCP的3種發送時機

1.當發送緩存中達到雙方約定的MSS時然后發送。

2.當URG = 1時立刻發送。

3.當發送方一個計時器期限到了就把當前已有的數據裝入報文段發送出去(這個數據長度不能超過MSS)

5.2、TCP的效率問題

舉例：

比如說Telnet遠程終端協議客戶端A向服務端B發送一個字符需要消耗41字節，B端服務器向A發送一個確認報文40字節，同時服務端要向客戶端回顯那一個字符。又是41字節，A客戶端向B服務端發送一個確認報文40個字節我一共要交流2字節的數據我卻用了162字節的報文利用率太低了。

解決方案：Nagle算法

發送方發送第一個字節，然后緩存剩下的數據字節。發送方收到對方發送的確認報文以后才把發送緩存中所有數據組裝成一個報文段發送出去。當發送緩存中數據達到對方接收窗口一半或者達到MSS時立刻發送。

5.3、糊涂窗口綜合癥

當接收方緩沖區已滿會向發送方發送一個rwnd為0的報文告訴對方不要再發了。當應用進程讀取1字節接收緩存時，接收方向發送方發送rwnd = 1的報文此時發送方將1字節的數據打包成報文段發送給接收方。如此循環往復每次只能發一個字節。

解決方案：

接收方等待一段時間，使得接收緩存已有足夠空間容納一個最長的報文段，或者等到接收緩存已有一半空間；只要出現這兩種情況之一，接收方就發出確認報文，并向發送方通知當前窗口的大小。