簡介
傳輸控制協定(TCP,Transmission Control Protocol)是為了在不可靠的
網際網路上提供可靠的
端到端位元組流而專門設計的一個
傳輸協定。
網際網路與單個網路有很大的不同,因為網際網路的不同部分可能有截然不同的
拓撲結構、頻寬、延遲、數據包大小和其他參數。TCP的
設計目標是能夠動態地適應網際網路的這些特性,而且具備面對各種故障時的
健壯性。
不同主機的套用層之間經常需要可靠的、像管道一樣的連線,但是IP層不提供這樣的流機制,而是提供不可靠的包交換。
套用層向TCP層傳送用於網間傳輸的、用8位位元組表示的數據流,然後TCP把數據流分區成適當長度的報文段(通常受該計算機連線的網路的數據鏈路層的
最大傳輸單元(MTU)的限制)。之後TCP把結果包傳給IP層,由它來通過網路將包傳送給接收端實體的TCP層。TCP為了保證不發生丟包,就給每個包一個序號,同時序號也保證了傳送到接收端實體的包的按序接收。然後接收端實體對已成功收到的包發回一個相應的確認(
ACK);如果傳送端實體在合理的往返
時延(RTT)內未收到確認,那么對應的數據包就被假設為已丟失將會被進行重傳。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的正式定義由1981年9月的RFC793給出。隨著時間的推移,已經對其做了許多改進,各種錯誤和不一致的地方逐漸被修復。
為了讓你感受到TCP的擴展歷程,現在重要的
RFC有:RFC793plus澄清了說明,RFC1122修復了
bug、RFC1323做了高性能擴展,RFC2018定義了選擇性確認,RFC2581說明了擁塞控制、RFC2873定義了為
服務質量而重用的頭欄位,RFC2988改進了重傳
計時器,RFC3168定義了顯式擁塞通知。完整的協定集合很大,因而專門發布了一個針對許多RFC的指南,它就是作為另一個RFC文檔公布的RFC4614。
主要功能
當套用層向TCP層傳送用於網間傳輸的、用8位位元組表示的
數據流,TCP則把數據流分割成適當長度的
報文段,最大傳輸段大小(
MSS)通常受該計算機連線的網路的
數據鏈路層的最大傳送單元(
MTU)限制。之後TCP把
數據包傳給
IP層,由它來通過網路將包傳送給接收端實體的TCP層。
TCP為了保證報文傳輸的可靠,就給每個包一個序號,同時序號也保證了傳送到接收端實體的包的按序接收。然後接收端實體對已成功收到的位元組發回一個相應的確認(
ACK);如果傳送端實體在合理的往返
時延(RTT)內未收到確認,那么對應的數據(假設丟失了)將會被
重傳。
每當建立一個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,進入擁塞避免階段。
主要特點
(1)基於流的方式;
(2)面向連線;
(3)可靠通信方式;
(4)在網路狀況不佳的時候儘量降低系統由於重傳帶來的頻寬開銷;
(5)通信連線維護是面向通信的兩個端點的,而不考慮中間
網段和節點。
為滿足TCP協定的這些特點,TCP協定做了如下的規定:
①
數據分片:在傳送端對用戶數據進行分片,在接收端進行重組,由TCP確定分片的大小並控制分片和重組;
②到達確認:接收端接收到分片數據時,根據分片數據序號向傳送端傳送一個確認;
③
逾時重發:
傳送方在傳送分片時啟動逾時定時器,如果在定時器逾時之後沒有收到相應的確認,重發分片;
④
滑動視窗:TCP連線每一方的接收緩衝空間大小都固定,接收端只允許另一端傳送接收端緩衝區所能接納的數據,TCP在滑動視窗的基礎上提供流量控制,防止較快主機致使較慢主機的緩衝區溢出;
⑤失序處理:作為IP數據報來傳輸的TCP分片到達時可能會失序,TCP將對收到的數據進行
重新排序,將收到的數據以正確的順序交給套用層;
⑥重複處理:作為IP數據報來傳輸的TCP分片會發生重複,TCP的接收端必須丟棄重複的數據;
⑦
數據校驗:TCP將保持它首部和數據的檢驗和,這是一個端到端的檢驗和,目的是檢測數據在
傳輸過程中的任何變化。如果收到分片的檢驗和有差錯,TCP將丟棄這個分片,並不確認收到此報文段導致對端逾時並重發。
首部格式
TCP的首部格式如圖1所示:
---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連線對端自己能夠接收的最大數據長度。
---Urgent Pointers是緊急指針,16位,只有URG標誌位被設定時該欄位才有意義,表示緊急數據相對序列號(Sequence Number欄位的值)的偏移。
工作方式
建立連線
TCP是
網際網路中的傳輸層協定,使用
三次握手協定建立連線。當主動方發出SYN連線請求後,等待對方回答SYN+ACK,並最終對對方的 SYN 執行 ACK 確認。這種建立連線的方法可以防止產生錯誤的連線,TCP使用的流量
控制協定是可變大小的
滑動視窗協定。
客戶端傳送SYN(SEQ=x)報文給伺服器端,進入SYN_SENT狀態。
伺服器端收到SYN報文,回應一個SYN (SEQ=y)ACK(ACK=x+1)報文,進入
SYN_RECV狀態。
客戶端收到伺服器端的SYN報文,回應一個ACK(ACK=y+1)報文,進入Established狀態。
三次握手完成,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連線需要經過
三次握手:主動端先傳送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報文。
MSS是最大傳輸段大小的縮寫,指一個TCP報文的數據載荷的最大長度,不包括TCP選項。
在TCP建立連線的三次握手中,有一種很重要的工作那就是進行MSS協商。連線的雙方都在SYN報文中增加MSS選項,其選項值表示本端最大能接收的段大小,即對端最大能傳送的段大小。連線的雙方取本端傳送的MSS值和接收對端的MSS值的較小者作為本連線最大傳輸段大小。
傳送SYN報文時的MSS選項值的計算方法如下。
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命令取消此限制。
TCP的路徑最大傳輸單元(PMTU)發現功能是按RFC1191實現的,這個功能可以提高
網路頻寬的利用率。當用戶使用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達到MSS的值,或者用戶停止這個定時器,這個探測過程才會停止。停止這個定時器,使用age-timer infinite參數。
使用no ip tcp path-mtu-discovery命令關閉PMTU發現功能。
設定接口收發SYN報文的MSS選項值
當客戶端發起一個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-mssmax-segment-size | 設定接口收發SYN報文的MSS選項值。 單位為位元組,取值範圍500-1460。 |
使用no ip tcp adjust-mss命令取消此項設定,則接口收發SYN報文時,不會修改報文的MSS選項值。
在接口上配置本命令會使得該接口接收或傳送SYN報文的MSS選項都被改為接口上配置的MSS值。建議出口和入口配置相同的值。如果SYN報文的入口和出口配置了不同的MSS值,經過該設備後,SYN報文的MSS選項被改為這兩個口配置值的較小者。
協定對比
TCP 是面向連線的傳輸控制協定,而
UDP 提供了
無連線的
數據報服務;TCP 具有
高可靠性,確保傳輸數據的正確性,不出現丟失或亂序;UDP 在傳輸數據前不建立連線,不對
數據報進行檢查與修改,無須等待對方的應答,所以會出現分組丟失、重複、亂序,
應用程式需要負責傳輸可靠性方面的所有工作;UDP 具有較好的
實時性,
工作效率較 TCP 協定高;UDP 段結構比 TCP 的段結構簡單,因此網路開銷也小。TCP 協定可以保證接收端毫無差錯地接收到傳送端發出的
位元組流,為應用程式提供可靠的通信服務。對可靠性要求高的
通信系統往往使用 TCP 傳輸數據。比如
HTTP 運用 TCP 進行數據的傳輸。