傳輸層協議之TCP協議

tcp將每個位元組的資料都進行了編號，即為序列號

每乙個ack都帶有對應的確認序列號，意思是告訴傳送者，我已經收到了哪些資料，下一步你該從**開始傳送

主機a傳送資料給b之後, 可能因為網路擁堵等原因, 資料無法到達主機b;

如果主機a在乙個特定時間間隔內沒有收到b發來的確認應答, 就會進行重發;

但是, 主機a未收到b發來的確認應答, 也可能是因為ack丟失了;

因此主機b會收到很多重複資料. 那麼tcp協議需要能夠識別出那些包是重複的包, 並且把重複的丟棄掉. 這時候我們可以利用前面提到的序列號, 就可以很容易做到去重的效果.

那麼超時的時間該如何確定？？？

tcp為了保證無論在任何環境下都能比較高效能的通訊, 因此會動態計算這個最大超時時間.

在確認應答機制中，對每傳送的乙個資料段，都要給乙個ack確認應答，收到ack後再傳送下乙個資料段，這樣做有乙個比較大的缺點，效能較差，尤其當資料往返的時間較長時；既然這樣一發一收的方式效能較低，那麼我們依次傳送多條資料，就可以大大提高效能（其實是將多個等待的時間重疊到一起了）

接收端處理資料的速度是有限的,如果傳送端發的太快,導致接收端的緩衝區滿時,這個時候如果傳送端繼續傳送資料,就會造成丟包,繼而引起丟包重傳等一系列連鎖反應;

因此tcp支援根據接收端的處理能力,來決定傳送端的傳送速度-------流量控制機制

接收端怎樣把視窗大小告訴傳送端呢???

回憶我們的tcp首部中, 有乙個16位視窗字段, 就是存放了視窗大小資訊; 那麼問題來了, 16位數字最大表示65535, 那麼tcp視窗最大就是65535位元組麼???

實際上, tcp首部40位元組選項中還包含了乙個視窗擴大因子m, 實際視窗大小是視窗欄位的值左移 m 位;

雖然tcp有了滑動視窗這個大殺器, 能夠高效可靠的傳送大量的資料. 但是如果在剛開始階段就傳送大量的資料, 仍然可能引發問題.

因為網路上有很多的計算機, 可能當前的網路狀態就已經比較擁堵. 在不清楚當前網路狀態下, 貿然傳送大量的資料, 是很有可能引起雪上加霜的.

tcp引入慢啟動機制, 先發少量的資料, 探探路, 摸清當前的網路擁堵狀態, 再決定按照多大的速度傳輸資料;

如果接收資料的主機立刻返回ack應答, 這時候返回的視窗可能比較小.

一定要記得, 視窗越大, 網路吞吐量就越大, 傳輸效率就越高. 我們的目標是在保證網路不擁塞的情況下盡量提高傳輸效率;

那麼所有的包都可以延遲應答麼? 肯定也不是;

在延遲應答的基礎上, 我們發現, 很多情況下, 客戶端伺服器在應用層也是「一發一收」的. 意味著客戶端給伺服器說了「how are you」, 伺服器也會給客戶端回乙個「fine, thank you」;

那麼這個時候ack就可以搭順風車, 和伺服器回應的「fine, thank you」一起回給客戶端