轉自：http://blog.csdn.net/ns_code/article/details/32329157
前言
建立在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、接收緩衝區用來暫按序到達但尚未被上層應用程序讀取的數據合未按序到達的數據。
