章節回顧：
《TCP/IP詳解卷1：協議》第3章 IP：網際協議（1）-讀書筆記
《TCP/IP詳解卷1：協議》第3章 IP：網際協議（2）-讀書筆記
《TCP/IP詳解卷1：協議》第4章 ARP：地址解析協議-讀書筆記
《TCP/IP詳解卷1：協議》第5章 RARP：逆地址解析協議-讀書筆記
《TCP/IP詳解卷1：協議》第6章 ICMP：Internet控制報文協議-讀書筆記
《TCP/IP詳解卷1：協議》第11章 UDP：用戶數據報協議-讀書筆記
《TCP/IP詳解卷1：協議》第17、18章 TCP：傳輸控制協議（1）-讀書筆記
《TCP/IP詳解卷1：協議》第17、18章 TCP：傳輸控制協議（2）-讀書筆記
《TCP/IP詳解卷1：協議》第19章 TCP的交互數據流-讀書筆記
1、引言
有關TCP通信量的研究發現：按分組數量計算，約有一半的TCP報文段包含成塊數據（如FTP、電子郵件和Usenet新聞），另一半則包含交互數據（如Telnet和Rlogin）。按字節計算，成塊數據與交互數據的比例約為90%和10%。
成塊數據的報文段基本上都是滿長度的（通常為512字節的用戶數據），交互數據則小得多（Telnet和Rlogin分組中約90%左右的用戶數據小於10個字節）
TCP需要同時處理這兩類數據，但使用的處理算法不同。
2、交互式輸入
說明：本書是以遠程登錄Rlogin協議模擬交互輸入的，我沒有進行相關實驗，下面我會給出作者所做的實驗截圖。
如圖19-1所示，Rlogin協議需要遠程系統回顯客戶輸入的字符，每按一個字符就會產生一個分組，而不是每次一行作為一個分組。
一般可以將報文段2和3合並（圖中兩個紅框）
當我們鍵入5個字符date\n時的數據流，如圖19-2所示：
說明：
（1）第1行：客戶發送字符d到服務器；第2行：該字符的確認及回顯；第3行：回顯字符的確認。
（2）與字符a有關的是第4~6行，與字符t有關的是第7~9行，與字符e有關的是第10~12行。
（3）13~15行與上面稍有不同。客戶發送到服務器的是一個字符（換行符），而回顯的是兩個字符（圖中14行紅線處），這兩個字符為：回車和換行字符，作用是將光標移動到左邊並換到下一行。
（4）第16行：來自服務器date命令的輸出。這30個字節（圖中紅線處）由28個字符與最后的回車+換行組成。第17、18行：服務器發往客戶7個字符（第18行），它們是在服務器主機上的客戶提示符：svr4%。第19行：確認了這7個字符。
3、經受時延的確認
圖19-3表示了圖19-2中數據交換的時間。
通常TCP在接收到數據時並不立即發送ACK；它會推遲發送，以便將ACK與需要沿該方向發送的數據一起發送，有時稱這種現象為數據捎帶ACK。
說明：絕大多數實現采用的時延為200ms，即TCP將以最大200ms的時延等待是否有數據一起發送。
下面我假設你會看這張圖中標記的時間差，會計算實際時間（累加）。說明如下：
觀察bsdi接收到數據和發送ACK之間的時間差：123.5、65.6、109.0、132.2、42.0、140.3和195.8 ms，似乎是隨機的。觀察bsdi發送ACK的實際時間（從0開始計算）為：139.9、539.3、940.1、1339.9、1739.9、1940.1和2140.1 ms，這些時間差是200ms的整數倍。
注意：因為TCP使用了一個200ms的定時器，以相對於內核引導的200ms固定時間溢出。由於將要確認的數據是隨機到達的，TCP在內核的200ms定時器的下一次溢出時得到通知。
4、Nagle算法
Rlogin連接時，一般每次發送一個字節到服務器，這就產生了一些41字節長的分組：20字節的IP首部、20字節的TCP首部和1個字節的數據。
在局域網上，這些小分組（被稱為微小分組tinygram）通常不會引起麻煩，因為局域網一般不會出現擁塞。在廣域網上，這些小分組則會增加擁塞出現的可能。一種簡單有效的方法就是采用RFC 896建議的Nagle算法。
算法說明：
算法要求一個TCP連接上最多只能有一個未被確認的未完成的小分組，在該分組的確認到達之前不能發送其他的小分組。相反，TCP收集這些少量的分組，並在確認到來時以一個分組的方式發出去。
算法優點：
算法的優越之處在於它是自適應的：確認到達得越快，數據也就發送得越快。在希望減少微小分組數目的低速廣域網上，則會發送更少的分組。
從圖19-3中看到，在以太網上一個字節被發送、確認和回顯的平均往返時間約為16ms。為了產生比這個速度更快的數據，我們每秒鍵入的字符必須多於60個。說明在局域網環境下兩個主機之間發送數據時很少使用這個算法。
當往返時間（RTT）增加時，如通過一個廣域網，情況發生了變化。如圖19-4：
從左到右待發數據的長度是不同的，分別為：1、1、2、1、2、2、3、1和3個字節。這是因為客戶只有收到前一個數據的確認后才發送已經收集的數據。通過使用Nagle算法，為發送16個字節的數據客戶只需要使用9個報文段，而不再是16個。
關閉Nagle算法
有時我們也需要關閉Nagle算法。例如，X窗口系統服務器，小消息（鼠標移動）必須無時延地發送，以便為進行某種操作的交互用戶提供實時的反饋。
5、窗口大小通告
觀察圖19-4，可以看到slip通告窗口大小為4096字節，vangogh通告其窗口大小為8192字節。但報文段5通告的窗口大小為4095個字節，意味着TCP緩沖區中仍然有一個字節等待應用程序（Rlogin客戶）讀取。
說明：
（1）通常服務器通告窗口大小為8192個字節，這是因為服務器在讀取並回顯接收到的數據之前，其TCP沒有數據發送。當服務器已經讀取了來自客戶的輸入后，來自服務器的數據將被發送。
（2）在ACK到來時，客戶的TCP總是有數據需要發送。這是因為它在等待ACK的過程中緩存接收到的字符。當客戶TCP發送緩存的數據時，Rlogin客戶沒有機會讀取來自服務器的數據，因此，客戶通告的窗口大小總是小於4096。
小結：
交互數據總是以小於最大報文段長度的分組發送。對於這些小的報文段，接收方使用經受時延的確認方法來判斷確認是否可被推遲發送，以便與回送數據一起發送。這樣通常會減少報文段的數目。在較慢的廣域網環境中，通常使用Nagle算法來減少這些小報文段的數目。這個算法限制發送者任何時候只能有一個發送的小報文段未被確認。