TCP數(shù)據(jù)流與窗口管理

TCP的動態(tài)數(shù)據(jù)傳輸。
為什么需要管理TCP數(shù)據(jù)流量呢,？
因為網(wǎng)絡(luò)的負(fù)載能力有限,，當(dāng)包的數(shù)量超過網(wǎng)絡(luò)的負(fù)載能力，網(wǎng)絡(luò)就會很慢,。

為什么需要管理TCP窗口呢,？
1、同管理數(shù)據(jù)流量相同,，要減緩網(wǎng)絡(luò)壓力,。
2、當(dāng)包的發(fā)送速率大于接收速率時,，可能會出現(xiàn)丟包的情況,，為了避免丟包和考慮到接收方的處理的能力。

為了一定程度上減緩擁塞,，下面兩種方法,，分別是延時確認(rèn)和Nagle算法,。

1、延時確認(rèn)
TCP并不是對每個數(shù)據(jù)報都返回ACK,，累積確認(rèn)機制使得TCP可以延遲一段時間發(fā)送ACK,。實踐中通常最大延遲取200ms，在達到效果的同時要盡量保證不讓正常的包發(fā)生超時,。

在ssh中,，從客戶端到服務(wù)器鍵入的每個字符都會生成一個獨立的包。（若用戶的輸入速度較快,，每個包可能含有多個字符）如果只有一個字符的話,，由wireshark可以看出，一個包的大小是88字節(jié),，有40字節(jié)作為頭部,，有效數(shù)據(jù)之后48字節(jié)，有效占比不到55%,。

假設(shè)輸入的是date,，本來一個包就可以成功傳輸，但是現(xiàn)在需要四個包,。這會造成網(wǎng)絡(luò)在一定程度上的擁塞,。
為了避免這樣的情況，提出了Nagle算法,。

2、Nagle算法
算法要求：當(dāng)一個TCP連接中有在傳數(shù)據(jù)時,，長度小于發(fā)送方最大段大小SMSS的報文段不能被發(fā)送,，直到所有的在傳數(shù)據(jù)都收到ACK。并且,，在收到ACK后,，TCP需要收集這些小數(shù)據(jù)，將其整合到一個報文段中發(fā)送,。

但是Nagle對于交互式的程序,，比如多人網(wǎng)絡(luò)游戲等，并不適用,。因為把小包整合起來并且等到TCP連接中沒有在傳數(shù)據(jù)后才發(fā)送,，反饋太慢。

窗口管理
滑動窗口,。TCP發(fā)送方和接收方動態(tài)地告知對方最大窗口大小,，一般二者相等?；瑒哟翱诘淖筮吔绮荒茏笠?，只能右移,。因為它控制的是已確認(rèn)的ACK號。

零窗口
當(dāng)窗口變?yōu)?,，可以有效阻止發(fā)送端發(fā)送數(shù)據(jù),。

但是，如果當(dāng)窗口更新的時候,，攜帶窗口更新的ACK丟失了怎么辦,？
這樣發(fā)送方一直不會發(fā)送，接收方一直等待接收數(shù)據(jù),，會形成死鎖,，為了避免這種情況，發(fā)送端會采用一個持續(xù)計時器間歇性地查詢接收端,，看其窗口是否增長,，這成為窗口探測。
[RFC1122]建議在一個RTO之后發(fā)送第一個窗口探測,，隨后以指數(shù)時間間隔發(fā)送,。

糊涂窗口綜合征
待寫

這一章感覺東西比較少，主要就是動態(tài)調(diào)節(jié)窗口大小和一定程度避免擁塞的兩個方法,，一個是延時ACK,，一個是Nagle算法。但這兩種算法都有缺陷,，延時ACK和Nagle都不適用于交互式,，想要迅速得到反饋的應(yīng)用。