《TCP/IP具體解釋》讀書筆記（19章）－TCP的交互數據流
阿新 • • 發佈：2017-06-18
font alt 算法 方向 它的 字節 隨機 收集 計算
上圖為沒有優化的字符輸入回顯的傳輸數據過程。一共須要四個報文段。
經受時延的確認
上圖第二，三個報文段能夠合並---按鍵確認和按鍵回顯一起發送。這樣的技術叫做經受時延的確認。
通常TCP在接收到數據時並不馬上發送ACK，相反，它推遲發送，以便將ACK與須要沿該方向發送的數據一起發送（有時這樣的現象為數據捎帶的ACK）。
ACK延時等待時間不大於TCP定時器的原因:
假如TCP使用200ms的定時器。該定時器將相對於內核引導的200ms固定時間溢出，由於將要確定的數據隨機到達，TCP將在下一次內核的200ms定時器溢出時得到通知，所以ACK實際等待的時間為1~200ms中任一刻。
Nagle算法
Nagle算法要求TCP連接上最多僅僅有一個未被確認的未完畢小分組。在該分組確認到達之前不能發送其它的小分組。相反。TCP收集這些少量的分組。並在確認到達時以一個大的分組發出去。
(1)發送端TCP將從應用進程接收到的第一數據塊馬上發送。無論其大小。哪怕僅僅有一個字節。
(2)發送端輸出第一塊數據後開始收集數據，並等待確認。
(3)確認未達到時，若收集數據達到窗體的一半或一個MSS段，馬上發送。
(4)確認到達後。把緩沖區中的數據組成一個TCP段，然後發送。
在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。client與server端的通告窗體分別為4096與8192。
但報文5通告的窗體大小為4095個字節，這意味著在TCP緩沖區中仍然有一個字節等待應用程序讀取。
作者原創。轉載請標明原處：http://blog.csdn.net/xifeijian/article/details/44260601
《TCP/IP具體解釋》讀書筆記（19章）－TCP的交互數據流