先補充一個知識：

1.停止等待協議：是tcp保證傳輸可靠的重要途徑，“停止等待”就是指發送完一個分組就停止發送，等待對方確認之後，才能繼續發送下一個分組

停止等待協議的優點是簡單，缺點就是信道的利用率太低，一次只發送一個消息，信道大部分時間都是空閑的。

2：超時重傳有一下三種情況：

1） 分組丟失：發送方發出來了，接收方沒有收到

2） 確認丟失：接收方收到了，也發送了確認分組，但是確認分組丟失了

3） 確認延時：確認分組沒有丟失，由於傳輸太慢，發送方在規定時間內沒有收到接收方發的確認分組。

3.下面兩個協議就是解決信道效率太低和增大吞吐量，以及流量控制：

1）連續ARQ協議：它是指發送方維護著一個窗口，這個窗口中不止有一個分組，而是有好幾個分組。窗口的大小是由接收方返回的win值決定的。所以窗口大小 是動態變化的。只要在窗口中的分組都可以被發送，這就使得TCP一次不是只發送一個分組了。從而大大提高了信道利用率。並且它采用累積確認的方式，對於按序到達的最後一個分組進行確認。

2）滑動窗口協議：因為窗口不斷往前走。該協議允許發送方在停止並等待確認前發送多個數據分組。不需要每發送一個就分組就停下來等待確認。所以可以加速數據的傳輸，還可以控制流量。

3）累積確認：如果發送方發送了5個分組，接收端只收到了1 2 4 5 ，沒有收到3，那麽我的確認信息會是說明我期望下一個收到的組是第三個，此時發送方會將3 4 5都重發一遍。

20.1 引言

本章我們將介紹TCP所使用的被稱為滑動窗口協議的另一種形式的流量控制方法。

該協議允許發送方在停止並等待確認前可以連續發送多個分組。

20.2 正常數據流

經受時延的確認：假設 A -> B，B要對A的數據進行確認，當有一個分組來的時候，B不立即確認，而是啟動一個定時器（RFC規定要小於500ms，很多都是200ms），等待200ms，如果在這期間A又來了其他的數據就可以一起確認了 。或者A要發數據給B了，就順帶把之前的也確認了。

比如下面這樣，對1025的確認放到了跟2049一起。

使用滑動窗口協議，接收方不必確認每一個收到的分組。在TCP中，ACK是累積的—它們表示連接方已經正確收到了一直到確認號減1的所有字節。比如上面的2049，就表示我收到了2048個字節。

20.3 滑動窗口協議

比如上面的例子，應該是右邊發送數據給左邊。左邊進行確認。窗口往右移動。

接收方通告的窗口稱為提出的窗口（offered window）：上面的4 – 9

說明接收方已經收到了3字節的數據，且通告窗口大小為6.

當接收方確認數據後，這個滑動窗口不斷的向右移動。下面用三個術語來描述窗口左右邊沿的運動：

1） 稱窗口左邊沿向右邊沿靠近為窗口合攏

2） 當窗口右邊沿向右移動時將允許發送更多的數據，我們稱之為窗口張開。這種現象發生在另一端的接收進程讀取已經確認的數據，並釋放了TCP的接收緩存時。（就是接收方讀取了緩沖區裏面的數據的時候）

3） 當右邊沿向左移動，稱為窗口收縮。

如果左邊沿到達右邊沿，則稱其為一個零窗口。此時發送方不能發送任何數據。

20.4 窗口大小

由接收方提供的窗口的大小通常可以由接收進程控制，這將影響TCP的性能。

插口API允許進程設置發送和接收緩存的大小。接收緩存的大小是該連接上所能通告的最大窗口大小。有一些應用程序通過修改插口緩存大小來增加性能。

20.5 PUSH標誌

發送方使用該標誌通知接收方將所收到的數據全部提交給接收進程。（這裏的數據包括與PUSH一起傳送的數據，以及接收方TCP已經為接收進程收到的其他數據）

假設一個客戶端發送數據給服務器，設置了PUSH標誌：

對客戶端來說：客戶進程通知TCP在向服務器發送一個報文段時不要因等待額外數據而使已提交數據在緩沖中滯留。

對服務器來說：TCP收到一個設置了PUSH標誌的報文時，它需要立即將這些數據遞交給服務器進程而不能等待判斷是否還會有額外的數據到達。

目前大多數的API沒有向應用程序提供通知其TCP設置PUSH的方法，很多實現程序任務PUSH已經過時了。一個好的TCP實現能夠自動設置PUSH標誌。

如果待發送數據將清空發送緩存，則大多數的源於伯克利的實現能夠自動設置PUSH標誌。

20.6 慢啟動

“慢啟動”slow start算法：通過觀察到新分組進入網絡的速率應該與另一端返回確認的速率相同而進行工作。

擁塞窗口（congestion window）：當與另一個網絡的主機建立TCP連接時，擁塞窗口被初始化為1個報文段（即另一端通告的報文段大小）。每收到一個ack，擁塞窗口就增加一個報文段（慢啟動以報文段大小為單位進行增加）。

發送方取擁塞窗口與通告窗口中的最小值作為發送上限。

擁塞窗口是發送方用的流量控制，而通告窗口則的接收方用的流量控制。

最開始為1，確認一個後變成了2，就可以發送兩個報文段了，當這兩個被確認以後擁塞窗口就變成了4。這是一種指數增加的關系。

當到達互聯網的極限時，中間路由器開始丟棄分組，這就通知發送方它的擁塞窗口開的過大。

20.7 成塊數據的吞吐量

通常發送一個分組的時間取決於兩個因素：

1） 傳播延時：由光的有限速率、傳輸設備的等待時間引起（這個一般是固定的）

2） 媒體速率的發送延時：媒體每秒可傳輸的比特數。（取決與 分組的大小。）

假設A發數據給B，擁塞窗口慢慢增大，到最後，發送方和接收方的之間的管道被填滿。此時無論擁塞窗口和通過窗口是多少，它都不能再容納更多的數據。每當接收方在某一時間單位從網絡上移去一個報文段，發送方就再發送一個報文段到網絡上。但是不管有多少報文段填充了這個管道，返回路徑上總是有相同數目的ack，這就是連接的理想穩定狀態。

20.7.1 帶寬時延乘積

如何設置窗口大小呢。下面是計算公式： 帶寬 * RTT ，括號裏面是單位。

c a p a c i t y (bit) = b a n d w i d t h (b/s) × ro u n d-trip time ( s )

一般稱之為帶寬時延乘積。這個值依賴於網絡速度和兩端的RTT。

比如：一條穿越美國（RTT約為60ms）的T1電話線路（1544000 b/s）的帶寬時延乘積為11580字節。1544000 * 0.06 / 8 就是字節了。

所以增加RTT和增加帶寬都可以使管道容量增加。

20.7.2 擁塞

發送擁塞的兩種情況：

1） 數據到達一個大的管道並向一個較小的管道發送時便會發送擁塞。

2） 當多個輸入流到達一個路由器，而路由器的輸出流小於這些輸入流的總和時也會發送擁塞

20.8 緊急方式

urgent mode：它使一端可以告訴另一端有些具有某種方式的“緊急數據”已經放置在普通的數據流中。另一端被通知這個緊急數據已被放置在普通數據流中，由接收方決定如何處理。

如何發送緊急數據：設置TCP首部中的兩個字段來發出緊急數據。URG置為1，並且從一個16bit的緊急指針被置為一個正的偏移量，該偏移量必須與TCP首部中的序號字段相加，以便得出緊急數據的最後一個字節的序號。

TCP本身對緊急數據知之甚少，沒有辦法指明緊急數據從數據流的何處開始。TCP通過連接傳送的唯一信息就是緊急方式已經開始（URG置為1）和指向緊急數據最後一個字節的指針。其他的事情留給應用程序去處理。

TCP/IP詳解 卷1 第二十章 TCP的成塊數據流