互動式資料指泛指每次傳遞的位元組很少，比如telnet,rlogin以rlogin為例，它每次傳到伺服器的是乙個位元組的按鍵，並且要求伺服器回顯客戶端輸入的字元。理論上完整的互動包括4個報文段：
客戶端傳送互動的資料
服務端對互動的資料進行ack
服務端對資料進行會顯
客戶端對資料回顯進行確認
輸入字元date\n產生的資料流如下：
可以發現真實的資料流存在如下特點：
對應客戶端傳送的序號為 1、4、7、10、13，可以看到位元組長度都是1，其中13的回顯確認位元組長度為2是因為換行符包括兩個字元
以序號為2的資料流為例，服務端傳送了資料，並進行了ack操作，也就是合併了資料回顯和客戶端資料傳送的ack，資料互動理論上的4次在實際中只有3次報文互動
ack傳送時間序號對應3、6、9、12等，值分別是 139.9ms、539.9ms、940.1ms、1339.9ms,其時間間隔為 400ms,400.2ms,399.8ms
側面反應tcp傳送資料最大的等待時延也就是200ms
資料到達和回顯的時間間隔為序號1-2，4-5，7-8等，值為16.5ms 16.3ms 16.5ms，也就是在200ms定時器溢位之前，都有資料到達
每次只傳送乙個位元組的資料，那麼在網路中很有可能充斥這許多41位元組長的分組（20的ip包首部，20的tcp包首部，1位元組的資料），過多的這種小分組則會增加擁塞的可能性
tcp連線上最多只有乙個未被確認的未完成的小分組
未完成確認的小分組確認之前，不能傳送其它的小分組
在確認到達之前收集少量的分組，在確認到達之後以乙個分組的方式傳送出去
如果應用場景使得使用者能夠感覺到明顯的延遲，那麼就可以選擇關閉nagle選項。
通常情況使用nagle演算法是在較慢的廣域網中，以便能夠減少小報文的數目
成塊的資料比如電子郵件tcp通過滑動視窗來控制成塊資料的流量，使得傳送方在不需要每傳送乙個分組就等待確認，從而加快了資料的傳輸
上圖是滑動視窗的乙個快照，以時間為橫軸，其中1-11表示傳送方傳送的位元組的標號。視窗是指資料處理方【傳送方和接收方】維護的乙個序列，在tcp協議中可以看做是報文片段序列，所謂滑動視窗則是描述隨著時間的推移，原始的報文已經被處理，可從視窗中移除，並開始去處理新加入視窗的報文序列。
滑動視窗本身可以看做是乙個協議，適合於資料傳輸過程中要求有嚴格順序處理的場景
上圖中，滑動視窗將時間軸上的資料分成了4個部分：
a：標識所在表示當前快照產生時，1-3個位元組已經被接收方所處理，並且傳送方確認了ack;
b：標識所在表示快照下的滑動視窗內傳送方已經傳送了3個位元組，但是接收方還沒確認；
c：標識標識接收方當前的可用視窗大小，也是傳送方能夠傳送的資料量；
d：標識標識當前快照下，接收方無法再接收資料了，空間不足，傳送方無法傳送；
左邊沿到達右邊沿稱為零視窗，此時傳送方不能傳送任何資料報文中的win用來描述視窗的大小。接收方視窗的大小可以通過接收方來實現控制，預設情況下4.3bsd中視窗大小為4096個位元組，如果視窗中有還沒來得及被應用程式讀取的資料，那麼返回報文中的win就會相應減小，當視窗中資料被處理之後，可能會出現攜帶ack但不確認任何資料，而win值變大的包，這種情況是用來增加視窗的有邊沿，也稱作視窗更新。
tcp實現了乙個慢啟動演算法，它為傳送方提供乙個擁塞視窗，開始時只會傳送1個報文段，然後等待ack
圖中顯示的是離散的時間單元，時間點1、2、3表示報文段從左向右移動乙個時間單元，時間4接收方讀取報文段並產生乙個確認，時間點5、6、7表示ack傳輸給傳送方，整個過程經歷了乙個8個時間單元的rtt（round-trip time）收到ack後，進而傳送兩個報文段
時間點12和時間點13產生的兩個ack之間的間隔和報文段之間的間隔一樣，被稱為tcp的自計時（self-clocking）行為。實際運用過程中，返回路徑上的排隊會改變ack的到達率兩個ack的到達使得擁塞視窗從2個報文段增加為4個
4個ack到達增加為8個
在時間點31之後的時間裡，傳送方和接收方的管道都被填滿，此時無論擁塞視窗和通告視窗是多少，它都不能再容納更多的資料，此時放回路徑上總是能保持相同數量的ack，也就是連線的理想穩定狀態
擁塞視窗是傳送方使用的流量控制，通告視窗是接收方使用的流量控制；傳送方的傳送上限為擁塞視窗和通告視窗的最小值。客戶端用來通知tcp在向伺服器傳送乙個報文時，不要因等待額外資料而使已提交資料在快取中滯留。伺服器收到帶push標識的tcp報文時，則立即將這些資料遞交給伺服器程序。
它使得一端可以告知另一端有些具有某種方式的「緊急資料」已經放置在普通資料流中，接收方收到通知後可以做相應處理。
以telnet和rlogin為例。當伺服器進入了緊急方式，此時伺服器是無法傳送任何資料的，但伺服器tcp會立即傳送緊急指標和urg標誌，當客戶端tcp收到這個通知時，便會通知客戶端程序，於是客戶端可以從伺服器讀取其輸入、開啟視窗使資料流動
設定tcp首部的urg標誌為1，並且乙個16bit的緊急指標被置為乙個正的偏移量，次偏移量與tcp首部中的序號字段相加，便得到緊急資料的最後乙個位元組的序號。
只要接收方當前讀取位置到緊急指標之間有資料存在，就認為應用程式處於「緊急方式」
如果接收方在處理第乙個緊急方式之前，傳送方多次進入緊急方式，接收方收到的舊緊急指標將會被新值覆蓋把書讀薄(tcp/ip詳解 卷一 第十九章 第二十章)
TCP是怎麼實現可靠傳輸的
tcp協議傳輸的特點主要是面向位元組流 傳輸可靠 面向連線。答 tcp協議保證資料傳輸可靠性的方式主要有 序列號 tcp傳輸時將每個位元組的資料都進行了編號，即序列號。確認應答 tcp傳輸過程中，每次接收方收到資料後，都會對傳輸方進行確認應答。也就是傳送ack報文。這個ack報文當中帶有對應的確認序...
TCP可靠性傳輸是怎麼是實現的？
tcp ip 這本書中提到 tcp通過校驗和，序列號，確認應答，重發控制，連線管理以及視窗控制等機制實現可靠性傳輸。序列號 確認應答 重發控制在tcp三次握手 連線管理 和四次揮手中都有體現，這幾個機制在很多博文中寫的很不錯，我也學習總結過一篇，沒有創新，一直是知識的搬運工。現在我更關心的是視窗控制...
網路資料是怎麼傳輸的
上圖是iso的七層網路體系結構，每一層都有其相應的工作協議。資料傳輸過程如下 如qq 在傳送主機a上，傳送的資料經過應用層時，應用層對資料進行了包裝，它在要傳輸的資料上加了乙個應用層首部ah後，繼續向傳輸層傳送。傳輸層接收到應用層的資料後，將資料 應用層ah當做資料，給它進行包裝，加上自己的首部，此...