在TCP進行數據傳輸時，可以分爲成塊數據流和交互數據流兩種，如果按字節計算，成塊數據與交互數據的比例約爲90%和10%，TCP需要同時處理這兩類數據，且處理的算法不同。
書籍本章中以Rlogin應用爲例觀察交互數據的傳輸過程。提示經受時延的確認是如何工作以及Nagle算法怎樣減少了通過廣域網絡傳輸的小分組的數目。
交互式輸入
上圖爲沒有優化的字符輸入回顯的數據傳輸過程，一共需要四個報文段。
經受時延的確認
上圖第二，三個報文段可以合併---按鍵確認和按鍵回顯一起發送。這種技術叫做經受時延的確認。
通常TCP在接收到數據時並不立即發送ACK，相反，它推遲發送，以便將ACK與需要沿該方向發送的數據一起發送（有時這種現象爲數據捎帶的ACK）。絕大數實現採用的時延爲200ms，也就是說，TCP將以最大200ms的時延等待是否有數據一起發送。
ACK延時等待時間不大於TCP定時器的原因:
假如TCP使用200ms的定時器，該定時器將相對於內核引導的200ms固定時間溢出，由於將要確定的數據隨機到達，TCP將在下一次內核的200ms定時器溢出時得到通知，所以ACK實際等待的時間爲1~200ms中任一刻。
Nagle算法
Nagle算法要求TCP連接上最多隻有一個未被確認的未完成小分組，在該分組確認到達之前不能發送其他的小分組。相反，TCP收集這些少量的分組，並在確認到達時以一個大的分組發出去。
該算法的優點在於它是自適應的：確認到達得越快，數據也就發送得越快。可以減少網絡上的微小分組數目，降低擁塞出現的可能（局域網這些小分組通常不會引起麻煩，但在較慢的廣域網則存在擁塞的可能）。但相應的，因爲不是立即ACK，也會增加更多的時延。
有時我們也需要關閉Nagle算法，例如鼠標移動必須無時延地發送，以便爲用戶的交互提供實時的反饋。
流程:(1)發送端TCP將從應用進程接收到的第一數據塊立即發送，不管其大小，哪怕只有一個字節。
(2)發送端輸出第一塊數據後開始收集數據，並等待確認。
(3)確認未達到時，若收集數據達到窗口的一半或一個MSS段，立即發送。
(4)確認到達後，把緩衝區中的數據組成一個TCP段，然後發送。
窗口大小通知
在圖19－4，客戶端與服務器端的通告窗口分別爲4096與8192。但報文5通告的窗口大小爲4095個字節，這意味着在TCP緩衝區中仍然有一個字節等待應用程序讀取。
