建立在tcp協議上的應用層協議有非常多，如ftp、http、telnet等，這些協議依據資料傳輸的多少能夠分為兩類：互動資料型別和成塊資料型別。
互動資料型別，如：telnet，這類協議一般僅僅做小流量的資料交換。比方每按下乙個鍵，要回顯一些字元。
成塊資料型別。如：ftp，這類協議須要傳輸的資料比較多。一般傳輸的資料量比較大。
針對這兩種不同的情況，tcp採用不同的策略進行資料傳輸。
針對互動性要求比較高的應用，比方rlogin遠端登入中，須要回顯client輸入的字元，每傳送乙個位元組到服務端。並回顯到client的步驟例如以下：
1、client產生乙個41bit長的報文（20位元組的ip首部。20位元組的tcp首部，1位元組的資料）。傳送到服務端；
2、服務端傳送過來乙個40bit的確認報文。
3、服務端傳送回顯的字元。報文長為41bit；
4、client傳送確認報文。報文長為40bit。
假設在區域網中，通常不會有什麼麻煩，由於區域網一般不會出現擁塞，但在廣域網中。這些小分組則會新增網路擁塞出現的可能。為了提高這類資料的傳送效率和降低網路負擔，tcp採用了兩種策略：捎帶ack和nagle演算法。
捎帶ack的意思是，當接收端接收到tcp報文段後，並不馬上傳送ack報文，而是等上一段時間，假設這段時間裡該主機有資料要傳送到遠端主機，就將該資料捎帶上ack一起傳送過去，非常明顯。這樣能夠降低傳輸開銷。為了防止產生超時重傳。絕大多數情況下。這個等待時間為200ms，超過了200ms，假設沒有資料要一起傳送。就直接傳送ack報文。
捎帶ack的策略一般也僅僅有在互動性比較高的應用中才會使用，對於成塊資料流，一般大多數應用程式不會同一時候在兩個方向上傳送資料。
該演算法的重點是要求在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、接收緩衝區用來暫按序到達但尚未被上層應用程式讀取的資料合未按序到達的資料。
TCP 互動資料流
tcp通訊量如果按分組數量計算，約一半的tcp報文段包含成塊資料 如ftp 電子郵件和usenet新聞 另一半則包含互動資料 如telnet,rlogin 如果按位元組計算，則成塊資料與互動資料的比例約為90 和10 這是因為成塊資料報文段基本上是滿長度的，而互動式資料則小得多。tcp同時處理這兩類...
TCP互動資料流 成塊資料流
tcp資料流分類 基於tcp的各類解決方案，可以根據資料吞吐量來大致分成兩大類 1 互動資料型別，例如telnet，ssh，這種型別的協議在大多數情況下只是做小流量的資料交換，比如說按一下鍵盤，回顯一些文字等等。2 資料成塊型別，例如ftp，這種型別的協議要求tcp能盡量的運載資料，把資料的吞吐量做...
TCP的互動資料流
在 tcp進行資料傳輸時 可以分為成塊資料流和互動資料流兩種 且處理的 演算法不同.每乙個互動按鍵都會產生乙個分組,也就是說,每次從客戶傳到伺服器的是乙個位元組的按鍵 而不是每次一行 報文段2可以和報文段3進行合併 按鍵確認和按鍵回顯一起傳送 按鍵確認和按鍵回顯兩個報文段合併在一起傳送，這種技術叫做...