TCP通過確認應答和超時重傳可以保證資料可靠傳輸

使用滑動視窗完成流量控制和擁塞控制

使用延遲應答來保證滑動視窗足夠大

接下來對這些機制進行詳細的介紹

確認應答（ACK）機制

TCP將每個位元組的資料都設定了序列號，每一個ACK都帶有對應的確認序列號，告訴傳送者，我收到了資料，你下一次應該從哪一個序列號開始發

超時重傳機制

當主機A向主機B傳送的資料發生丟包，無法到達主機B時，主機A在一段時間內沒有收到主機B的確認應答，就會進行重發

超時時間的確認：

Linux中，超時以500ms為一個單位進行控制每次判定超時重發的時間都是500ms的整數倍

如果重發一次後，仍然得不到應答，經過2*500ms後重新發送

以此類推，以指數的形式增長，累計到一定的重傳次數，TCP會強制關閉連線

滑動視窗

在確認應答中，對每一個傳送的資料段，都要有一個ACK應答，收到ACK應答後才能再發送下一個資料段，這樣做效能較差。

於是TCP採用滑動視窗機制一次傳送多條資料，將多個段的等待時間重疊在一起來提高效能

滑動視窗的大小就是無需等待確認應答可以持續傳送的資料的大小，上圖中的視窗大小為4000

當收到第一個確認應答後，視窗後移繼續傳送第五個段的資料，以此類推

作業系統核心為了維護滑動視窗，開闢了一個緩衝區來記錄當前還有那些資料沒有做出應答，只有應答了之後才會從緩衝區裡刪除掉

丟包的兩種情況：

• ACK丟失:部分ACK丟失，不要緊，可以通過後序的ACK進行確認
• 資料包丟失：
  • 假如上圖中1001~2000的資料段丟失，主機B會不斷的給主機A傳送ACK=1001的回覆，當主機A連續三次收到ACK=1001的回覆後，會重新發送1001~2000的資料段，再次返回的就是7001了（因為2001-7000）接收端之前就已經收到了，只是被放到接收緩衝區中了。

流量控制

接收端處理資料的速度有限，如果傳送端傳送資料太快，導致接收緩衝區滿了，如果傳送端再進行傳送資料，就會造成丟包

所以TCP支援根據接收端的處理能力來決定傳送端的傳送速度，也就是流量控制

• 接收端將自己的緩衝區大小放入TCP首部中的“視窗大小”欄位，通過ACK告訴傳送端；
• 視窗越大，說明網路的吞吐量越高
• 接收端發現自己的緩衝區快滿的時候，就會減小視窗的大小，當傳送端接收到這個訊息後也會降低自己的傳送速度
• 當接收端的緩衝區滿了之後，接收端會將視窗大小設定為0，這時傳送端就不會再發送資料了，但是它會定期傳送一個視窗探測資料段來獲取接收端的視窗大小

擁塞控制

同一時間可能有多人上網，造成網路擁堵，如果此時滑動視窗在開始階段就傳送大量的資料同樣有可能出現問題

TCP引入慢啟動機制，先發少量的資料，探探路，摸清網路當前的擁堵狀態，再決定按照多大的速度傳輸，此時就引入了擁塞視窗這個概念

• 剛開始將擁塞視窗置為1
• 每接收到一個ACK，擁塞視窗加1
• 每次傳送資料時，將擁塞視窗與接收端反饋的緩衝區視窗作比較，選擇較小的視窗傳輸
• 擁塞視窗的增長是指數級增長，為了不讓增長的太快，引入一個慢啟動的閾值
• 當擁塞視窗按指數級增長超過閾值時，就以線性方式增長
• 當TCP開始啟動的時候，慢啟動閾值等於視窗最大值
• 在每次超時重發的時候，閾值會變成原來的一半，擁塞視窗重新置為1

少量的丟包，僅僅是觸發超時重傳，但是當大量的丟包時就是網路擁塞

擁塞控制歸根結底是想盡可能快的把資料傳送給對方，但又避免造成網路擁堵

延遲應答

如果接受資料的主機立刻返回ACK應答，這時返回的視窗可能比較小

接收端處理資料的速度很快，可能很快就處理完緩衝區的資料，接收端稍微遲一會兒作出應答，完全可以給傳送端返回一個更大的視窗傳送資料。

視窗越大，網路吞吐量就越大，傳輸效率就會提高

但是也並不是所有的包都需要延時應答，一般每隔2個包就應答一次，超過最大延遲時間就應答一次（一般取200ms）

捎帶應答

在延遲應答的基礎上，很多情況下，客戶端伺服器在應用層也是“一發一收的”，這時ACK就可以搭順風車和伺服器迴應的訊息一起發給客戶端