tcp[傳輸控制協定]

TCP（Transmission Control Protocol 傳輸控制協定）是一種面向連線的、可靠的、基於位元組流的傳輸層通信協定，由IETF的RFC 793定義。在簡化的計算機網路OSI模型中，它完成第四層傳輸層所指定的功能，用戶數據報協定（UDP）是同一層內 另一個重要的傳輸協定。在網際網路協定族（Internet protocol suite）中，TCP層是位於IP層之上，套用層之下的中間層。不同主機的套用層之間經常需要可靠的、像管道一樣的連線，但是IP層不提供這樣的流機制，而是提供不可靠的包交換。 套用層向TCP層傳送用於網間傳輸的、用8位位元組表示的數據流，然後TCP把數據流分區成適當長度的報文段（通常受該計算機連線的網路的數據鏈路層的最大傳輸單元（ MTU）的限制）。之後TCP把結果包傳給IP層，由它來通過網路將包傳送給接收端實體 的TCP層。TCP為了保證不發生丟包，就給每個包一個序號，同時序號也保證了傳送到接收端實體的包的按序接收。然後接收端實體對已成功收到的包發回一個相應的確認（ACK）；如果傳送端實體在合理的往返時延（RTT）內未收到確認，那么對應的數據包就被假設為已丟失將會被進行重傳。TCP用一個校驗和函式來檢驗數據是否有錯誤；在傳送和接收時都要計算校驗和。

基本信息

• 中文名稱：傳輸控制協定
• 外文名：Transmission Control Protocol

• 簡稱：TCP
• 行業標準：IETF RFC 793
• 套用範圍I：nternet

網路協定

功能

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

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

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

•在保證可靠性上，採用逾時重傳和捎帶確認機制。

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

在擁塞控制上，採用廣受好評的TCP擁塞控制算法（也稱AIMD算法）。該算法主要包括三個主要部分：1）加性增、乘性減；2）慢啟動；3）對逾時事件做出反應。

實行標準

TCP/IP(Transmission Control Protocol/Internet Protocol) 即傳輸控制協定/網間協定，是一個工業標準的協定集，它是為廣域網（WAN）設計的。它是由ARPANET網的研究機構發展起來的。

TCP/IP的標準在一系列稱為RF C的文檔中公布。文檔由技術專家、特別工作組、或RFC編輯修訂。公布一個文檔時，該文檔被賦予一個RFC編號，如RFC959（FTP的說明文檔）、RFC793（TCP的說明文檔）、RFC791（IP的說明文檔）等。最初的RFC一直保留而從來不會被更新， 如果修改了該文檔，則該文檔又以一個新號碼公布。因此，重要的是要確認你擁有了關於某個專題的最新RFC文檔。通常在RFC的開頭部分，有相關RFC的更新(update)、排錯（errata）、作廢（obsolete）信息，提示讀者信息的時效性。

首部格式

TCP的首部格式圖右圖所示：

TCP首部

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

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

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

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

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

---標誌位： 6位，URG表示Urgent Pointer欄位有意義：

ACK表示Acknowledgment Number欄位有意義

PSH表示Push功能，RST表示復位TCP連線

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

FIN表示沒有數據需要傳送了（在關閉TCP連線的時候使用）

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

---Checksum是校驗和，16位。

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

連線建立

TCP的三次握手

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

TCP三次握手的過程如下：

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

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

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

1.

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

2.

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

3.

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

三次握手完成，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) “通常”是指，某些情況下，步驟1的FIN隨數據一起傳送，另外，步驟2和步驟3傳送的分節都出自執行被動關閉那一端，有可能被合併成一個分節。

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

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

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

可靠性實現

可靠性

　TCP提供一種面向連線的、可靠的位元組流服務。面向連線意味著兩個使用TCP的套用（通常是一個客戶和一個伺服器）在彼此交換數據包之前必須先建立一個TCP連線。這一過程與打電話很相似，先撥號振鈴，等待對方摘機說“餵”，然後才說明是誰。在一個TCP連線中，僅有兩方進行彼此通信。廣播和多播不能用於TCP。

TCP通過下列方式來提供可靠性：

1．套用數據被分割成TCP認為最適合傳送的數據塊。這和UDP完全不同，應用程式產生的數據長度將保持不變。由TCP傳遞給IP的信息單位稱為報文段或段（segment）。

2．當TCP發出一個段後，它啟動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發這個報文段。當TCP收到發自TCP連線另一端的數據，它將傳送一個確認。TCP有延遲確認的功能，在此功能沒有打開，則是立即確認。功能打開，則由定時器觸發確認時間點。

3．TCP將保持它首部和數據的檢驗和。這是一個端到端的檢驗和，目的是檢測數據在傳輸過程中的任何變化。如果收到段的檢驗和有差錯，TCP將丟棄這個報文段和不確認收到此報文段（希望發端逾時並重發）。

4．既然TCP報文段作為IP數據報來傳輸，而IP數據報的到達可能會失序，因此TCP報文段的到達也可能會失序。如果必要，TCP將對收到的數據進行重新排序，將收到的數據以正確的順序交給套用層。

5．既然IP數據報會發生重複，TCP的接收端必須丟棄重複的數據。

6．TCP還能提供流量控制。TCP連線的每一方都有固定大小的緩衝空間。TCP的接收端只允許另一端傳送接收端緩衝區所能接納的數據。這將防止較快主機致使較慢主機的緩衝區溢出。

兩個應用程式通過TCP連線交換8bit位元組構成的位元組流。TCP不在位元組流中插入記錄標識符。我們將這稱為位元組流服務（bytestreamservice）。如果一方的應用程式先傳10位元組，又傳20位元組，再傳50位元組，連線的另一方將無法了解發方每次傳送了多少位元組。只要自己的接收快取沒有塞滿，TCP 接收方將有多少就收多少。一端將位元組流放到TCP連線上，同樣的位元組流將出現在TCP連線的另一端。

另外，TCP對位元組流的內容不作任何解釋。TCP不知道傳輸的數據位元組流是二進制數據，還是ASCⅡ字元、EBCDIC字元或者其他類型數據。對位元組流的解釋由TCP連線雙方的套用層解釋。

這種對位元組流的處理方式與Unix作業系統對檔案的處理方式很相似。Unix的核心對一個套用讀或寫的內容不作任何解釋，而是交給應用程式處理。對Unix的核心來說，它無法區分一個二進制檔案與一個文本檔案。

重傳策略

TCP協定用於控制數據段是否需要重傳的依據是設立重發定時器。在傳送一個數據段的同時啟動一個重傳，如果在重傳逾時前收到確認(Acknowlegement)就關閉該重傳，如 果重傳逾時前沒有收到確認，則重傳該數據段。在選擇重發時間的過程中，TCP必須具有自適應性。它需要根據網際網路當時的通信情況，給出合適的重發時間。

這種重傳策略的關鍵是對定時器初值的設定。採用較多的算法是Jacobson於1988年提出的一種不斷調整逾時時間間隔的動態算法。其工作原理是：對每條連線TCP都保持一個 變數RTT（Round Trip Time），用於存放當前到目的端往返所需要時間最接近的估計值。當傳送一個數據段時，同時啟動連線的定時器，如果在定時器逾時前確認到達，則記錄所需要的時間（M），並修正 RTT的值，如果定時器逾時前沒有收到確認，則將RTT的值增加1倍。通過測量一系列的RTT（往返時間）值，TCP協定可以估算數據包重發前需要等待的時間。在估計該連線所需的當前延遲時通常利用一些統計學的原理和算法（如Karn算法），從而得到TCP重發之前需要等待的時間值。

視窗確認

TCP的狀態機

TCP的一項功能就是確保每個數據段都能到達目的地。位於目的主機的TCP服務對接受到的數據進行確認，並向源應用程式傳送確認信息。

使用數據報頭序列號以及確認號來確認已收到包含在數據段的相關的數據位元組。

TCP在發回源設備的數據段中使用確認號，指示接收設備期待接收的下一位元組。這個過程稱為 期待確認。

源主機在收到確認訊息之前可以傳輸的數據的大小稱為 視窗大小。用於管理丟失數據和流量控制。這些變化如右圖所示。

配置TCP

修改建立TCP連線的逾時時間

建立TCP連線需要經過三次握手：主動端先傳送SYN報文，被動放回應SYN+ACK報文，然後主動端再回應ACK。

l在主動端傳送SYN後，如果被動端一直不回應SYN+ACK報文，主動端會不斷的重傳SYN報文直到超過一定的重傳次數或逾時時間。

l在主動端傳送SYN後，被動端回應SYN+ACK報文，但主動端不再回復ACK，被動端也會一直重傳直到超過一定的重傳次數或逾時時間。（SYN報文攻擊會出現這種情況）

可以通過以下命令配置SYN報文的逾時時間（傳送SYN報文到三次握手成功的最大時間），也就是建立TCP連線的逾時時間。

命令	作用
R(config)# ip tcp syntime-out seconds	修改建立TCP連線的逾時時間。 單位秒，取值範圍5-300，預設值20

使用 no ip tcp syntime-out命令恢復參數預設值。

修改緩衝區大小

TCP的接收緩衝區是用來快取從對端接收到的數據，這些數據後續會被應用程式讀取。一般情況下，TCP報文的視窗值反映接收緩衝區的空閒空間的大小。對於頻寬比較大、有大批量數據的連線，增大接收緩衝區的大小可以顯著提供TCP傳輸性能。TCP的傳送緩衝區是用來快取應 用程式的數據，傳送緩衝區的每個位元組都有序列號，被應答確認的序列號對應的數據會從傳送緩衝區刪除掉。增大傳送緩衝區可以提高TCP跟應用程式的互動能力，也因此會提高性能。但是增大接收和傳送緩衝區會導致TCP占用比較多的記憶體。

命令	作用
R (config)# ip tcp window-size size	修改TCP連線的接收和傳送緩衝區大小。 單位位元組，取值範圍0-65535，預設值4096。

使用 no ip tcp window-size命令恢復接收和傳送緩衝區大小為預設值。

禁止連線埠不可達時的重置報文

TCP模組在分發TCP報文時，如果找不到該報文所屬的TCP連線會主動回復一個reset報文以終止對端的TCP連線。攻擊者可能利用大量的連線埠不可達 的TCP報文對設備進行攻擊。

可以使用以下命令禁止/恢復在收到連線埠不可達的TCP報文時傳送reset報文。

命令	作用
R (config)# ip tcp not-send-rst	禁止在接收到連線埠不可達的TCP報文時傳送reset報文。

使用 no ip tcp not-send-rst命令恢復傳送reset報文。

限制TCP連線的MSS的最大值

MSS是最大傳輸段大小的縮寫，指一個TCP報文的數據載荷的最大長度，不包括TCP選項。

在TCP建立連線的三次握手中，有一種很重要的工作那就是進行MSS協商。連線的雙方都在SYN報文中增加MSS選項，其選項值表示本端 最大能接收的段大小，即對端最大能傳送的段大小。連線的雙方取本端傳送的MSS值和接收對端的MSS值的較小者作為本連線最大傳輸段大小。

傳送SYN報文時的MSS選項值的計算方法如下。

l非直連網路中：mss = 默認值 536。

l直連網路中：mss = 對端ip地址對應的出口的MTU - 20位元組ip頭 - 20位元組tcp頭。
一般來說如果出口配置的某些套用影響了接口的mtu，那么該套用會相應的設定mtu，如隧道口，vpn口等。

到這裡得到的rmss值就是要傳送的syn報文mss選項的值 。舉例：一般情況下在直連網路中建立bgp鄰居，那么該連線的傳送的mss為1500 – 20 – 20 – 20 = 1440。

ip tcp mss命令的作用是限制即將建立的TCP連線的MSS的最大值。任何新建立的連線協商的MSS值不能超過配置的值。

命令	作用
R (config)# ip tcp mss max-segment-size	限制TCP連線的MSS的最大值。 單位為位元組，取值範圍68-10000。

使用 no ip tcp mss命令取消此限制。

啟用PMTU發現功能

TCP的路徑最大傳輸單元（PMTU）發現功能是按RF C1191實現的，這個功能可以提高網路頻寬的利用率。當用戶使用TCP來批量傳輸大塊數據時，該功能可以使傳輸性能得到明顯提升。

命令	作用
R(config)# ip tcp path-mtu-discovery [ age-timer minutes | age-timer infinite ]	啟用PMTU發現功能。 age-timer minutes：TCP在發現PMTU後，重新進行探測的時間間隔。單位分鐘，取值範圍10-30。預設值10。 age-timer infinite：TCP在發現PMTU後，不重新探測。

按RFC1191的描述，TCP在發現PMTU後，隔一段時間可以使用更大的MSS來探測新的PMTU。這個時間間隔就是使用參數 age-timer來指定。當設備發現的PMTU比TCP連線兩端協商出來的MSS小時，設備就會按上述配置時間間隔，去嘗試發現更大的PMTU。直到PMTU達到MS S的值，或者用戶停止這個定時器，這個探測過程才會停止。停止這個定時器，使用 age-timer infinite參數。

使用 no ip tcp path-mtu-discovery命令關閉PMTU發現功能。

設定接口收發SYN報文的MSS選項值

tcp[傳輸控制協定]

當客戶端發起一個TCP連線時，它通過TCP SYN報文中的MSS選項欄位協商TCP報文數據載荷的最大值，客戶端SYN報文的MSS值表示後續伺服器端傳送TCP報文數據載荷的最大值，反之同理。

如右圖的拓撲，PC用http訪問伺服器可能會出現無法訪問的情況。因為PC與伺服器端建立的連線MSS協商的都會是1460，但1460的MSS無法通過R1和R2，R1和R2用隧道相連，MTU小於1500。

這時可以通過在R2的（1）口和（2）口上配置如下命令，修改SYN報文中的MSS選項值。從而修改經過（1）口和（2）口的TCP連線協商的MSS值。

命令	作用
R (config-if)# ip tcp adjust-mss max-segment-size	設定接口收發SYN報文的MSS選項值。 單位為位元組，取值範圍500-1460。

使用 no ip tcp adjust-mss命令取消此項設定，則接口收發SYN報文時，不會修改報文的MSS選項值。

在接口上配置本命令會使得該接口接收或傳送SYN報文的MSS選項都被改為接口上配置的MSS值。建議出口和入口配置相同的值。如果SYN報文的入口和出口配置了不同的MSS值，經過該設備後，SYN報文的MSS選項被改為這兩個口配置值的較小者。