章節回顧：
《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演算法來減少這些小報文段的數目。這個演算法限制傳送者任何時候只能有一個傳送的小報文段未被確認。