前言

    建立在TCP協議上的應用層協議有很多，如FTP、HTTP、Telnet等，這些協議根據傳輸資料的多少可以分為兩類：互動資料型別和成塊資料型別。

    互動資料型別，如：Telnet，這類協議一般只做小流量的資料交換，比如每按下一個鍵，要回顯一些字元。

    成塊資料型別，如：FTP，這類協議需要傳輸的資料比較多，一般傳輸的資料量比較大。

    針對這兩種不同的情況，TCP採用不同的策略進行資料傳輸。

   互動資料流

    針對互動性要求比較高的應用，比如Rlogin遠端登入中，需要回顯客戶端輸入的字元，每傳送一個位元組到服務端，並回顯到客戶端的過程如下：

    1、客戶端產生一個41bit長的報文（20位元組的IP首部，20位元組的TCP首部，1位元組的資料），傳送到服務端；

    2、服務端傳送過來一個40bit的確認報文；

    3、服務端傳送回顯的字元，報文長為41bit；

    4、客戶端傳送確認報文，報文長為40bit。

    如果在區域網中，通常不會有什麼麻煩，因為區域網一般不會出現擁塞，但在廣域網中，這些小分組則會增加網路擁塞出現的可能。為了提高這類資料的傳送效率和降低網路負擔，TCP採用了兩種策略：捎帶ACK和Nagle演算法。

    捎帶ACK

    捎帶ACK的意思是，當接收端接收到TCP報文段後，並不立即傳送ACK報文，而是等上一段時間，如果這段時間裡該主機有資料要傳送到遠端主機，就將該資料捎帶上ACK一起傳送過去，很明顯，這樣可以減少傳輸開銷。為了防止產生超時重傳，絕大多數情況下，這個等待時間為200ms，超過了200ms，如果沒有資料要一起傳送，就直接傳送ACK報文。

    捎帶ACK的策略一般也只有在互動性比較高的應用中才會使用，對於成塊資料流，一般大多數應用程式不會同時在兩個方向上傳送資料。

    Nagle演算法

    該演算法的重點是要求在TCP連線上組多隻能有一個未被確認的資料包在傳輸。演算法的大致思路如下：應用程式把要傳送的資料逐個位元組地從到TCP的傳送快取，傳送方把線面的一部分資料先傳送出去，並把後面到達的位元組繼續快取起來，當傳送方收到前面位元組的確認後，再把傳送緩衝中的所有資料組裝成一個報文段傳送出去，同時繼續對隨後到來的資料進行快取。只有收到前一個報文段的確認後才能繼續傳送下一個報文段。另外，Nagle演算法還規定，當傳送快取中的資料已達到傳送視窗大小的一半或已達到報文段的MSS值時，就立即傳送一個報文段。

    當資料到達較快而網路速率較慢時，用這種方法可明顯地減少所用的網路頻寬。很明顯，該演算法也是專門為互動性高的應用而設計的，對於成塊資料流，如果每收到一次確認才能傳送下一個報文段，那麼傳輸速率就會很低。

   成塊資料流

    對於一些資料吞吐量要求較高的應用，總是希望每次傳送儘可能多的資料到主機，對於這類應用，TCP使用滑動視窗協議，該協議允許傳送方在停止傳送前和等待確認前可以連續傳送多個分組，因此可以加速資料的傳輸。  

    滑動視窗

    滑動視窗的滑動是以位元組為單位的，傳送方A和接收方B在TCP三次握手的前兩次握手時協商好了傳送視窗和接受視窗的大小，傳送方A根據B傳送來的確認連線報文中標明的視窗的大小，來確定收到確認前的最大傳送資料量，如果A接收到的B發來的確認報文中標明的視窗大小為0，則停止傳送資料，直到收到不為0的確認報文，再繼續傳送。傳送視窗表示在沒有收到B的確認的情況下，A可以連續把視窗內的資料都傳送出去，凡是已傳送過的資料，在沒有收到確認前都要暫時保留，以便超時重傳時使用。

    需要注意的一點是：使用TCP滑動視窗協議時，接收方不必確認每一個收到的分組，在TCP中，ACK確認是累積的，可以在接收到幾個序號連續的報文段後只傳送一個ACK確認報文，但累積等待的時間最長不能超過0.5秒，以防止傳送端超時重傳。

    另外，要注意滑動視窗的三種變化：

    1、視窗合攏。視窗左邊沿向右邊沿靠近，這種情況發生在資料被髮送後收到確認時；

    2、視窗張開。視窗右邊沿向右移動，說明允許傳送更多的資料，這種情況發生在另一端的接收程式從TCP接收快取中讀取了已經確認的資料時；

    3、視窗收縮。視窗右邊沿向左移動，一般很少發生，RFC也強烈不建議這麼做，因為很可能會產生一些錯誤，比如一些資料已經傳送出去了，又要收縮視窗，不讓傳送這些資料。

    另外，視窗的左邊沿是肯定不可能左移的，如果接收到一個指示視窗左邊沿向左移動的ACK，則它被認為是一個重複ACK，並被丟棄。

    總結以下幾點：

    1、傳送方不必傳送一個全視窗大小的資料，一次傳送一部分即可。

    2、視窗的大小可以減小，但是視窗的右邊沿卻不能向左移動。

    3、接收方在傳送一個ACK前不必等待視窗被填滿。

    4、視窗的大小是相對於確認序號的，收到確認後的視窗的左邊沿從確認序號開始。

    傳送接收緩衝區

    本部分主要明確一下幾點：

    1、緩衝空間和序號空間都是有限的，並且都是迴圈使用的。

    2、視窗大小一定不大於收發緩衝區的大小

    3、傳送緩衝區用來暫存傳送方準備傳送的TCP報文段和已傳送但尚未收到確認的資料。

    4、接收緩衝區用來暫按序到達但尚未被上層應用程式讀取的資料合未按序到達的資料。