TCP(傳輸控制協定)

傳輸控制協定（TCP，TransmissionControl Protocol）是一種面向連線的、可靠的、基於位元組流的傳輸層通信協定，由IETF的RFC 793定義。

TCP旨在適應支持多網路套用的分層協定層次結構，互連的計算機通信網路中成對的應用程式進程之間能夠依靠TCP提供可靠的通信服務來傳輸位元組流。TCP支持雙向數據流，應用程式也可以僅單向傳送數據。在主機之間，TCP使用連線埠號標識應用程式服務並且可以多路傳輸數據流。

基本介紹

• 中文名：傳輸控制協定
• 外文名：Transmission Control Protocol
• 套用層次：傳輸層
• 縮寫：TCP
• 最新標準：IETFRFC 9293 
• OSI模型層次：傳輸層

定義

傳輸控制協定（TCP，Transmission Control Protocol）是為了在不可靠的網際網路上提供可靠的端到端位元組流而專門設計的一個傳輸協定。

網際網路中的不同部分可能有截然不同的拓撲結構、頻寬、延遲、數據包大小和其它參數，而TCP的設計目標是能夠動態地適應網際網路的這些特性，以及具備面對各種故障時的健壯性。

不同主機的套用層之間經常需要可靠的、像管道一樣的連線，但是IP層無法提供這樣的流機制，而是提供了不可靠的包交換機制。

套用層向TCP層傳送用於網間傳輸的、用8位位元組表示的數據流，然後TCP把數據流分成適當長度的報文（通常受該計算機連線的網路的數據鏈路層的最大傳輸單元（MTU）的限制）。之後TCP把結果包傳給IP層，由它來通過網路將包傳送給接收端實體的TCP層。TCP為了保證不發生丟包，給每個包分配了一個序號，同時，這些序號也可以保證傳送到接收端實體的包的按序接收。然後接收端實體對每個已成功收到的包發回一個相應的確認（ACK）；如果傳送端實體在合理的往返時延（RTT）內未收到確認，那么對應的數據包就被假設為已丟失，並將會被重傳。TCP用一個校驗和函式來檢驗收到的數據包是否有傳輸錯誤；一個數據包在傳送和接收時都要校驗和計算和驗證。

每台支持TCP的機器都有一個TCP傳輸實體。TCP實體可以是一個庫過程、一個用戶進程，或者核心的一部分。在所有這些情形下，TCP實體管理TCP流以及與IP層之間的接口。TCP傳輸實體接受本地進程的用戶數據流，將它們分割成不超過64KB（實際上去掉IP和TCP頭，通常不超過1460數據位元組）的分段，每個分段以單獨的IP數據報形式傳送。當包含TCP數據的數據報到達一台機器時，它們被遞交給TCP傳輸實體，TCP傳輸實體重構出原始的位元組流。為簡化起見，我們有時候僅僅用“TCP”來代表TCP傳輸實體（一段軟體）或者TCP協定（一組規則），根據上下文語義可以很清楚地推斷出實際含義。例如，在“用戶將數據交給TCP”這句話中，很顯然這裡指的是TCP傳輸實體。

IP層並不保證數據報一定能夠被正確地遞交到接收方，也不指示數據報的傳送速度有多快。TCP負責既要足夠快地傳送數據報，以便使用可用網路容量，但又不能引起網路擁塞，而且在TCP逾時後，需要重傳沒有遞交的數據報。即使被正確遞交的數據報，也可能存在錯序的問題，把接收到的數據報重新裝配成正確的順序也是TCP的責任。簡而言之，TCP可以提供可靠的良好傳輸性能，這正是大多數用戶所期望的而IP不能提供的功能。

發展歷史

技術起源

TCP的正式定義由IETF(網際網路工程任務組)於1981年9月的RFC793給出。隨著時間的推移，IETF已經對其做了許多改進，各種錯誤和不一致的地方逐漸被修復。

發展歷程

RFC 793plus澄清了說明

RFC 1122 修復了bug

RFC 1323 對TCP做了高性能擴展

RFC 2018定義了TCP的選擇性確認

RFC 2581定義了TCP的擁塞控制

RFC 2873定義了為服務質量而重用的頭欄位

RFC 2988改進了TCP的重傳計時器

RFC 3168定義了TCP的顯式擁塞通知

RFC 6093實現了TCP的緊急機制

RFC 6528指定了用於防範初試序列號攻擊的算法

RFC 6691 提出一種TCP選項和最大段大小的建議

重⼤節點

完整的TCP協定集很大，因而IETF專門發布了一個針對許多RFC的指南，它就是作為另一個RFC文檔公布的RFC4614。

階段性成果

RFC 9293 把過去四十幾年針對TCP協定的各種修補全部合訂到了一起，一次性地替代了RFC 879、RFC 2873、RFC6093、RFC 6429、RFC 6528、RFC 6691和主體RFC 793， 此外整體替換了RFC 1122中關於 TCP 的全部內容。

基本原理

主要技術

當套用層向TCP層傳送用於網間傳輸的、用8位位元組表示的數據流，TCP則把數據流分割成適當長度的報文，最大傳輸段大小（MSS）通常受該計算機連線的網路的數據鏈路層的最大傳送單元（MTU）限制。之後TCP把數據包傳給IP層，由它來通過網路將包傳送給接收端實體的TCP層。

TCP為了保證可靠報文傳輸，給每個包分配了一個序號，同時序號也保證了傳送到接收端實體的包的按序接收。然後接收端實體對已成功收到的位元組發回一個相應的確認（ACK）；如果傳送端實體在合理的往返時延（RTT）內未收到確認，那么對應的包（假設丟失了）將會被重傳。

在數據正確性與合法性上，TCP用一個校驗和函式來檢驗數據是否有傳輸錯誤，在傳送和接收時都要計算校驗和；同時可以使用md5認證對數據進行加密。

在可靠傳輸方面，採用了逾時重傳和捎帶確認機制。

在流量控制方面，採用了滑動視窗協定，協定中規定，對於視窗內未經確認的分組需要重傳。

在擁塞控制方面，採用了廣受好評的TCP擁塞控制算法（也稱AIMD算法）。

擁塞控制

TCP擁塞控制算法主要包括四個主要部分：

（1）慢啟動

每當建立一個TCP連線時或一個TCP連線發生逾時重傳後，該連線便進入慢啟動階段。進入慢啟動後，TCP實體將擁塞視窗的大小初始化為一個報文，即：cwnd=1。此後，每收到一個報文的確認（ACK），cwnd值加1，即擁塞視窗指數增加。當cwnd值超過慢啟動閾值（ssthresh）或發生報文丟失重傳時，慢啟動階段結束。前者進入擁塞避免階段，後者重新進入慢啟動階段。

（2）擁塞避免

在慢啟動階段，當cwnd值超過慢啟動閾值（ssthresh）後，慢啟動過程結束，TCP連線進入擁塞避免階段。在擁塞避免階段，每次傳送cwnd個報文被完全確認後，才將cwnd值加1。在此階段，cwnd值線性增加。

（3）快速重傳

快速重傳是對逾時重傳的改進。當源端收到對同一個報文的三個重複確認時，就可以確定該報文已經丟失，因此立刻重傳丟失的報文，而不必等到重傳定時器（RTO）逾時。以此減少不必要的等待時間。

（4）快速恢復

快速恢復是對丟失恢復機制的改進。在快速重傳之後，不經過慢啟動過程而直接進入擁塞避免階段。每當快速重傳後，置ssthresh=cwnd/2、cwnd=ssthresh+3。此後，每收到一個重複確認，將cwnd值加1，直至收到對丟失報文和其後若干報文的累積確認後，置cwnd=ssthresh，此後進入擁塞避免階段。

技術特點

TCP是一種面向廣域網的通信協定，目的是在跨越多個網路通信時，為兩個通信端點之間提供一條具有下列特點的通信方式：

（1）基於流的方式；

（2）面向連線；

（3）可靠通信方式；

（4）在網路狀況不佳的時候儘量降低系統由於重傳帶來的頻寬開銷；

（5）通信連線維護是面向通信的兩個端點的，而不考慮中間網段和節點。

為滿足TCP協定的這些特點，TCP協定做了如下的規定：

①數據分片：在傳送端對用戶數據進行分片，在接收端進行重組，由TCP確定分片的大小並控制分片和重組；

②到達確認：接收端接收到分片數據時，根據分片數據序號向傳送端傳送一個確認；

③逾時重傳：傳送方在傳送一個分片時啟動逾時定時器，如果在定時器逾時之後沒有收到相應的確認，重發該分片；

④滑動視窗：TCP連線每一方的接收緩衝空間大小都是固定的，接收端只允許另一端傳送接收端緩衝區所能接納的數據，TCP通過滑動視窗機制提供流量控制，防止較快主機致使較慢主機的緩衝區溢出；

⑤失序處理：作為IP數據報來傳輸的TCP分片到達時可能會失序，TCP將對收到的數據進行重新排序，將收到的數據以正確的順序交給套用層；

⑥重複處理：作為IP數據報來傳輸的TCP分片可能會發生重複傳輸，TCP的接收端必須丟棄重複的數據；

⑦數據校驗：TCP將保持它首部和數據的檢驗和，這是一個端到端的檢驗和，目的是檢測數據在傳輸過程中的任何變化。如果收到分片的檢驗和有差錯，TCP將丟棄這個分片，且不確認收到此報文，從而導致發端逾時並重發。

首部格式

TCP的首部格式如下圖所示：

① Source Port是源連線埠，16位。

② Destination Port是目的連線埠，16位。

③ Sequence Number是傳送數據包中的第一個位元組的序列號，32位。

④ Acknowledgment Number是確認序列號，32位。

⑤ Data Offset是數據偏移，4位，該欄位的值是TCP首部（包括選項）長度除以4。

⑥ Reserved 是保留位，4位，為將來使用而保留的一組控制位。在生成段中必須為零。

⑦ 控制位(標誌位)： 6位，

CWR 表示減少擁塞視窗

ECE 表示從對方到本方的網路有擁塞

URG表示Urgent Pointer欄位有實際意義

ACK表示Acknowledgment Number欄位有實際意義

PSH表示Push功能

RST表示復位TCP連線

SYN表示SYN報文（在建立TCP連線的時候使用）

FIN表示數據傳送完畢（在關閉TCP連線的時候使用）

⑧ Window表示接收緩衝區的空閒空間，16位，用來告訴TCP連線對端自己能夠接收的最大數據長度。

⑨ Checksum是校驗和，16位。

⑩ Urgent Pointers是緊急指針，16位，只有URG標誌位被設定時該欄位才有意義，表示緊急數據相對序列號（SequenceNumber欄位的值）的偏移。

TCP的首部格式

工作方式

連線建立

TCP是網際網路中的傳輸層協定，使用三次握手協定建立連線。當主動方發出SYN連線請求後，等待對方回答SYN+ACK，並最終對對方發來的 SYN 執行 ACK 確認。這種建立連線方法可以防止產生錯誤的連線，TCP使用的流量控制協定是可變大小的滑動視窗協定。

下面給出了一個在客戶端與伺服器端之間建立一個TCP連線的三次握手過程：

1.客戶端傳送SYN（SEQ=x）報文給伺服器端，進入SYN_SENT狀態。

2.伺服器端收到SYN報文，回應一個SYN （SEQ=y）ACK（ACK=x+1）報文，進入SYN_RECV狀態。

3.客戶端收到伺服器端的SYN報文，回應一個ACK（ACK=y+1）報文，進入Established狀態。

三次握手完成後，TCP客戶端和伺服器端之間就成功地建立一個TCP連線，可以開始傳輸數據了。

三次握手

連線終止

建立一個TCP連線需要三次握手，而終止一個TCP連線要經過四次握手，這是由TCP的半關閉（half-close）造成的。具體過程如下圖所示。

四次握手

1.某個套用進程首先調用close，稱該端執行“主動關閉”（active close）。該端的TCP實體於是傳送一個FIN分節，表示數據傳送完畢。

2.接收到這個FIN的對端執行 “被動關閉”（passive close），這個FIN由TCP確認。

注意：FIN的接收也作為一個檔案結束符（end-of-file）傳遞給接收端套用進程，放在已排隊等候該套用進程接收的任何其它數據之後，這是因為，FIN的接收意味著接收端套用進程在相應連線上再無後續數據可接收。

3.一段時間後，接收到這個檔案結束符的套用進程將調用close關閉它的套接字。這導致它的TCP實體也傳送一個FIN。

4.接收這個最終FIN的原傳送端TCP實體（即執行主動關閉的那一端）確認這個FIN。

既然每個方向都需要一個FIN和一個ACK，因此通常需要4個分節。

注意：

①某些情況下，步驟1的FIN隨數據一起傳送，另外，步驟2和步驟3傳送的分節都出自執行被動關閉那一端，有可能被合併成一個分節。

②在步驟2與步驟3之間，從執行被動關閉一端到執行主動關閉一端流動數據是可能的，因此稱為“半關閉”（half-close）。

③當一個連線的進程無論自願地（調用exit或從main函式返回）還是非自願地（收到一個終止本進程的信號）終止時，所有打開的描述符都被關閉，這也導致仍然打開的任何TCP連線上也發出一個FIN。

④無論是客戶端還是服務端，任何一端都可以執行主動關閉。通常情況是，客戶端執行主動關閉，但是某些協定（例如HTTP/1.0）卻由服務端執行主動關閉。

套用

TCP 用於在傳輸層有必要實現可靠傳輸的情況，例如以下幾種套用場景：

①電子郵件： SMTP（Simple Mail Transfer Protocol）和POP3（Post Office Protocol）等電子郵件協定使用TCP進行郵件的傳輸和接收。

②檔案傳輸： FTP（File Transfer Protocol）是基於TCP的檔案傳輸協定，用於在網路上進行檔案的上傳和下載。

③遠程登錄： SSH（Secure Shell）協定使用TCP提供安全的遠程登錄功能，允許用戶通過網路遠程連線到其他計算機上。

④即時通訊： 許多即時通訊套用，如QQ、微信，使用TCP確保訊息的可靠傳輸，防止訊息的丟失或亂序。

⑤資料庫訪問： 資料庫管理系統（如MySQL、PostgreSQL）使用TCP協定來實現客戶端與服務端之間的可靠數據傳輸，確保資料庫操作的一致性和完整性。