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

TCP 的交互數(shù)據(jù)流

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

客戶端產(chǎn)生一個41bit長的報文(20字節(jié)的IP首部，20字節(jié)的TCP首部，1字節(jié)的數(shù)據(jù))，發(fā)送到服務(wù)端;

服務(wù)端發(fā)送確認報文，不包含應(yīng)用數(shù)據(jù)(長度為0);

服務(wù)端發(fā)送回顯的字符;

客戶端發(fā)送確認報文，不包含應(yīng)用數(shù)據(jù)(長度為0)。

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

捎帶 ACK

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

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

Nagle 算法

該算法要求一個 TCP 連接的通信雙方在任意時刻最多只能發(fā)送一個未被確認的 TCP 報文段，在該 TCP 報文段的確認到達之前不能發(fā)送其他TCP報文段。另一方面，發(fā)送方在等待確認的同時收集本端需要發(fā)送的微量數(shù)據(jù)，并在確認到來時以一個 TCP 報文段將它們?nèi)堪l(fā)出。這樣就極大地減少了網(wǎng)絡(luò)上的微小 TCP 報文段的數(shù)量。該算法的另一個優(yōu)點在于其自適應(yīng)性：確認到達得越快，數(shù)據(jù)也就發(fā)送得越快。