TCP 報文段所攜帶的應用程序數據按照長度分為兩種：交互數據和成塊數據。交互數據僅包含很少的字節。使用交互數據的應用程序(或協議)對實時性要求高，比如 Telnet、ssh 等。成塊數據的長度則通常為 TCP 報文段允許的最大數據長度。使用成塊數據的應用程序(或協議)對傳輸效率要求高，比如 FTP。

TCP 的交互數據流

交互數據流總是以小于最大報文段長度的分組發送，即進行小分組數據傳輸。主要應用在實時性要求比較高的場合。比如 Rlogin 遠程登錄中，需要回顯客戶端輸入的字符，每發送一個字節到服務端，并回顯到客戶端的過程如下：

客戶端產生一個41bit長的報文(20字節的IP首部，20字節的TCP首部，1字節的數據)，發送到服務端;

服務端發送確認報文，不包含應用數據(長度為0);

服務端發送回顯的字符;

客戶端發送確認報文，不包含應用數據(長度為0)。

上面的過程中，雖然達到了實時性要求，但是交互數據太頻繁，并且在服務器發送的確認報文中并沒有返回有用應用程序數據，回顯數據是服務器單獨發送，并不跟確認報文一起發送，這樣頻繁的交互數據會導致網絡擁塞。為了防止網絡擁塞，在進行交互數據流時可采用兩種方法：捎帶 ACK和Nagle 算法;

捎帶 ACK

當服務器收到遠程主機的 TCP 數據報之后，通常不立即發送 ACK 確認數據報，而是推遲發送，即等待一個短暫的時間，這個時間一般是 200 ms。如果這段時間里面服務器有需要發送給遠程主機的 TCP 數據報，那么就把這個 ACK 確認數據報“捎帶”著發送出去，把本來兩個 TCP 數據報整合成一個發送。由于 TCP 具有超時重傳機制，若等待時間超過了200 ms，若此時服務器依然沒有數據要一起發送，就直接發送 ACK 確認報文段。這種機制可以提高 TCP 數據報的利用率。

使用捎帶 ACK 機制的交互數據流時，客戶端針對服務器返回的數據所發送的確認報文段都不攜帶任何應用程序數據(長度為0)，而服務器每次發送的確認報文段都包含它需要發送的應用程序數據。服務器的這種處理方式稱為延遲確認，即它不馬上確認上次收到的數據，而是在一段延遲時間后查看本端是否有數據需要發送，如果有，則和確認信息一起發出。因為服務器對客戶請求處理得很快，所以它發送確認報文段的時候總是有數據一起發送。延遲確認可以減少發送 TCP 報文段的數量。而由于用戶的輸入速度明顯慢于客戶端程序的處理速度，所以客戶端的確認報文段總是不攜帶任何應用程序數據。

Nagle 算法

該算法要求一個 TCP 連接的通信雙方在任意時刻最多只能發送一個未被確認的 TCP 報文段，在該 TCP 報文段的確認到達之前不能發送其他TCP報文段。另一方面，發送方在等待確認的同時收集本端需要發送的微量數據，并在確認到來時以一個 TCP 報文段將它們全部發出。這樣就極大地減少了網絡上的微小 TCP 報文段的數量。該算法的另一個優點在于其自適應性：確認到達得越快，數據也就發送得越快。