TCP 協議是 TCP/IP 協議棧中的傳輸層的協議，TCP協議又叫傳輸控制協議(Transport Control Protocal)。眾所周知，它是一個可靠協議。因為它能保證接收端完整地接受到傳送端傳送的資料包，即保證不丟包。
那 TCP 協議如何保證不丟包呢？
ISO（國際標準化組織）曾提出一個 OSI 七層模型。將網路的協議劃分為 7 個層，從低到高排序是：物理層、資料鏈路層、網路層、傳輸層、會話層、表示層和應用層。但是這個模型僅停留在理論階段。因為該模型過於龐大、複雜，以至於無法被廣泛應用。
後來技術人員在 TCP/IP 等協議集問世之後，提出 TCP/IP 協議棧。該模型很貼近實際場景，所以被廣泛的應用。TCP/IP 協議棧一共分為 4 個層次。從低到高依次排序是：資料鏈路層（有書籍稱之為網路介面層)、網路層、傳輸層、應用層
-
網路介面層：針對不同物理網路的連線形式的協議：乙太網、FDDI 光纖分散式資料介面。其中協議有 ARP 協議(地址解析協議)、RARP 協議(反向地址轉換協議)
-
網際層：負責資料的傳輸，路由以及地址選擇。最主要的協議是 IP 協議。
-
傳輸層：確認資料傳輸以及進行糾錯處理。傳輸層中中有兩個非常重要的協議，即 TCP 協議和 UDP 協議。
-
應用層：各種服務以及應用程式。常見的應用層協議有 HTTP 協議、FTP 協議(檔案傳輸協議)、SMTP 協議(簡單郵件傳輸協議)等
TCP 協議是實現埠到埠的通訊。它虛擬了本文流(byte stream)的通訊。我們知道，計算機資料的本質是有序的 0/1 序列(如果以byte為單位，就叫做文字流)。計算機的功能就是儲存和處理文字流。所以TCP是採用“流”通訊。
但是傳輸層的下一層是網路層。即 TCP 協議的下一層協議是 IP 層。這就意味著 TCP 協議最終還是由 IP 協議規定的形式傳輸資料。而IP 協議是以資料包方式傳送。同時，IP 資料包的 MTU 也有長度限制。所以TCP 協議會將資料切割為一個個片段，然後丟給網路層，接著打包成一個個資料包進行傳輸。
但是這樣，流資料變成了一個個片段資料，這會無法保證資料到達的次序。因為 IP 協議在傳輸過程中，不會按順序進行傳送和接受資料包。針對這問題，TCP 協議為了確保資料到達的順序與文字流順序相同。TCP 協議將每個 TCP 片段中分為頭部(header)和資料(payload)兩部分。每個頭部中帶有一個序號。這相當於給每個片段增加一個序號標記，方便後續排序。
我們都知道 IP 協議是“不太靠譜”。因為 IP 協議是不可靠的，所以 IP 資料包可能在傳輸過程中發生錯誤或者丟失。這就意味著，TCP 協議不得不面對以下三個問題。1）每個資料包有可能傳送不成功 2）資料包在傳輸過程中有可能被丟棄 3）接收端有可能接受不到資料包
TCP 為了解決這丟包問題，提出兩個補救措施
1 ACK 回覆在每收到一個正確的、符合次序的片段之後，就向傳送方(也就是連線的另一段)傳送一個特殊的 TCP 片段，用來知會(ACK，acknowledge)傳送方：我已經收到那個片段了。這個特殊的 TCP片段 叫做 ACK 回覆。如果一個片段序號為 L，對應ACK 回覆有回覆號 L+1，也就是接收方期待接收的下一個傳送片段的序號。
2 重新傳送機制如果傳送方在一定時間等待之後，還是沒有收到 ACK 回覆，那麼它推斷之前傳送的片段一定發生了異常。傳送方會重複傳送(retransmit)那個出現異常的片段，等待 ACK 回覆，如果還沒有收到，那麼再重複傳送原片段… 直到收到該片段對應的 ACK 回覆(回覆號為 L+1 的 ACK)
雖然採用 “ACK 回覆” + “重新傳送機制” 方式能實現不丟包，但是會存在兩個問題。
1.效率低的問題。
傳送方保持傳送 -> 等待ACK -> 傳送 -> 等待ACK…的單線工作方式，這樣的工作方式叫做 stop-and-wait。stop-and-wait 雖然實現了 TCP 通訊的可靠性，但同時犧牲了網路通訊的效率。同時，在等待ACK的時間段內，我們的網路都處於閒置(idle)狀態
2.有點小缺陷
如果片段一直沒有被確認，會導致後續的片段無法傳送出去。
TCP 為了進一步最佳化解決這兩個問題，提出滑動視窗(sliding window)的概念。滑動視窗被同時應用於接收方和傳送方, 傳送方和接收方各有一個滑窗。當片段位於滑窗中時，表示 TCP 正在處理該片段。此外，如果滑窗中可以有多個片段，也就是可以同時處理多個片段。
- TCP協議可靠使用以下機制來保證
- TCP報文段首部sequence欄位唯一標識TCP報文段，也作為順序的標識
- TCP通訊採用ACK+確認號的確認機制
- TCP報文首部的checksum欄位記錄報文段資料的checksum
- TCP協議的最佳化
- 採用滑動視窗機制，提升通訊效率
本作品採用《CC 協議》，轉載必須註明作者和本文連結