-
TCP
(傳輸控制協議)
鎖定
- 中文名
- 傳輸控制協議
- 外文名
- Transmission Control Protocol
- 應用層次
- 傳輸層
- 數據格式
- 字節流
- 工 作
- 與IP協議共同使用
- 服 務
- 由套接字端點獲得
TCP簡介
互聯網絡與單個網絡有很大的不同,因為互聯網絡的不同部分可能有截然不同的拓撲結構、帶寬、延遲、數據包大小和其他參數。TCP的設計目標是能夠動態地適應互聯網絡的這些特性,而且具備面對各種故障時的健壯性。
[2]
應用層向TCP層發送用於網間傳輸的、用8位字節表示的數據流,然後TCP把數據流分區成適當長度的報文段(通常受該計算機連接的網絡的數據鏈路層的最大傳輸單元(MTU)的限制)。之後TCP把結果包傳給IP層,由它來通過網絡將包傳送給接收端實體的TCP層。TCP為了保證不發生丟包,就給每個包一個序號,同時序號也保證了傳送到接收端實體的包的按序接收。然後接收端實體對已成功收到的包發回一個相應的確認(ACK);如果發送端實體在合理的往返時延(RTT)內未收到確認,那麼對應的數據包就被假設為已丟失將會被進行重傳。TCP用一個校驗和函數來檢驗數據是否有錯誤;在發送和接收時都要計算校驗和。
[3]
每台支持TCP的機器都有一個TCP傳輸實體。TCP實體可以是一個庫過程、一個用户進程,或者內核的一部分。在所有這些情形下,它管理TCP流,以及與IP層之間的接口。TCP傳輸實體接受本地進程的用户數據流,將它們分割成不超過64KB(實際上去掉IP和TCP頭,通常不超過1460數據字節)的分段,每個分段以單獨的IP數據報形式發送。當包含TCP數據的數據報到達一台機器時,它們被遞交給TCP傳輸實體,TCP傳輸實體重構出原始的字節流。為簡化起見,我們有時候僅僅用“TCP”來代表TCP傳輸實體(一段軟件)或者TCP協議(一組規則)。根據上下文語義你應該能很清楚地推斷出其實際含義。例如,在“用户將數據交給TCP”這句話中,很顯然這裏指的是TCP傳輸實體。
[2]
IP層並不保證數據報一定被正確地遞交到接收方,也不指示數據報的發送速度有多快。正是TCP負責既要足夠快地發送數據報,以便使用網絡容量,但又不能引起網絡擁塞:而且,TCP超時後,要重傳沒有遞交的數據報。即使被正確遞交的數據報,也可能存在錯序的問題,這也是TCP的責任,它必須把接收到的數據報重新裝配成正確的順序。簡而言之,TCP必須提供可靠性的良好性能,這正是大多數用户所期望的而IP又沒有提供的功能。
[2]
TCP發展歷程
為了讓你感受到TCP的擴展歷程,現在重要的RFC有:RFC793plus澄清了説明,RFC1122
[4]
修復了bug、RFC1323
[5]
做了高性能擴展,RFC2018
[6]
定義了選擇性確認,RFC2581説明了擁塞控制、RFC2873定義了為服務質量而重用的頭字段,RFC2988
[7]
改進了重傳計時器,RFC3168
[8]
定義了顯式擁塞通知。完整的協議集合很大,因而專門發佈了一個針對許多RFC的指南,它就是作為另一個RFC文檔公佈的RFC4614
[9]
。
TCP主要功能
當應用層向TCP層發送用於網間傳輸的、用8位字節表示的數據流,TCP則把數據流分割成適當長度的報文段,最大傳輸段大小(MSS)通常受該計算機連接的網絡的數據鏈路層的最大傳送單元(MTU)限制。之後TCP把數據包傳給IP層,由它來通過網絡將包傳送給接收端實體的TCP層。
[3]
TCP為了保證報文傳輸的可靠,就給每個包一個序號,同時序號也保證了傳送到接收端實體的包的按序接收。然後接收端實體對已成功收到的字節發回一個相應的確認(ACK);如果發送端實體在合理的往返時延(RTT)內未收到確認,那麼對應的數據(假設丟失了)將會被重傳。
- 在數據正確性與合法性上,TCP用一個校驗和函數來檢驗數據是否有錯誤,在發送和接收時都要計算校驗和;同時可以使用md5認證對數據進行加密。
- 在保證可靠性上,採用超時重傳和捎帶確認機制。
- 在流量控制上,採用滑動窗口協議,協議中規定,對於窗口內未經確認的分組需要重傳。
(1)慢啓動
每當建立一個TCP連接時或一個TCP連接發生超時重傳後,該連接便進入慢啓動階段。進入慢啓動後,TCP實體將擁塞窗口的大小初始化為一個報文段,即:cwnd=1。此後,每收到一個報文段的確認(ACK),cwnd值加1,即擁塞窗口按指數增加。當cwnd值超過慢啓動閾值(ssthresh)或發生報文段丟失重傳時,慢啓動階段結束。前者進入擁塞避免階段,後者重新進入慢啓動階段。
(2)擁塞避免
在慢啓階段,當cwnd值超過慢啓動閾值(ssthresh)後,慢啓動過程結束,TCP連接進入擁塞避免階段。在擁塞避免階段,每一次發送的cwnd個報文段被完全確認後,才將cwnd值加1。在此階段,cwnd值線性增加。
(3)快速重傳
(4)快速恢復
快速恢復是對丟失恢復機制的改進。在快速重傳之後,不經過慢啓動過程而直接進入擁塞避免階段。每當快速重傳後,置ssthresh=cwnd/2、cwnd=ssthresh+3。此後,每收到一個重複確認,將cwnd值加1,直至收到對丟失報文段和其後若干報文段的累積確認後,置cwnd=ssthresh,進入擁塞避免階段。
TCP主要特點
(1)基於流的方式;
(2)面向連接;
(3)可靠通信方式;
(4)在網絡狀況不佳的時候儘量降低系統由於重傳帶來的帶寬開銷;
(5)通信連接維護是面向通信的兩個端點的,而不考慮中間網段和節點。
①數據分片:在發送端對用户數據進行分片,在接收端進行重組,由TCP確定分片的大小並控制分片和重組;
②到達確認:接收端接收到分片數據時,根據分片數據序號向發送端發送一個確認;
④滑動窗口:TCP連接每一方的接收緩衝空間大小都固定,接收端只允許另一端發送接收端緩衝區所能接納的數據,TCP在滑動窗口的基礎上提供流量控制,防止較快主機致使較慢主機的緩衝區溢出;
⑤失序處理:作為IP數據報來傳輸的TCP分片到達時可能會失序,TCP將對收到的數據進行重新排序,將收到的數據以正確的順序交給應用層;
⑥重複處理:作為IP數據報來傳輸的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連接對端自己能夠接收的最大數據長度。
---Checksum是校驗和,16位。
TCP工作方式
TCP建立連接
TCP是因特網中的傳輸層協議,使用三次握手協議建立連接。當主動方發出SYN連接請求後,等待對方回答SYN+ACK,並最終對對方的 SYN 執行 ACK 確認。這種建立連接的方法可以防止產生錯誤的連接,TCP使用的流量控制協議是可變大小的滑動窗口協議。
[3]
TCP三次握手的過程如下:
- 客户端發送SYN(SEQ=x)報文給服務器端,進入SYN_SENT狀態。
- 服務器端收到SYN報文,迴應一個SYN (SEQ=y)ACK(ACK=x+1)報文,進入SYN_RECV狀態。
- 客户端收到服務器端的SYN報文,迴應一個ACK(ACK=y+1)報文,進入Established狀態。
三次握手完成,TCP客户端和服務器端成功地建立連接,可以開始傳輸數據了。
TCP連接終止
(1) 某個應用進程首先調用close,稱該端執行“主動關閉”(active close)。該端的TCP於是發送一個FIN分節,表示數據發送完畢。
(2) 接收到這個FIN的對端執行 “被動關閉”(passive close),這個FIN由TCP確認。
注意:FIN的接收也作為一個文件結束符(end-of-file)傳遞給接收端應用進程,放在已排隊等候該應用進程接收的任何其他數據之後,因為,FIN的接收意味着接收端應用進程在相應連接上再無額外數據可接收。
(3) 一段時間後,接收到這個文件結束符的應用進程將調用close關閉它的套接字。這導致它的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連接中,僅有兩方進行彼此通信。廣播和多播不能用於TCP。
2.當TCP發出一個段後,它啓動一個定時器,等待目的端確認收到這個報文段。如果不能及時收到一個確認,將重發這個報文段。當TCP收到發自TCP連接另一端的數據,它將發送一個確認。TCP有延遲確認的功能,在此功能沒有打開,則是立即確認。功能打開,則由定時器觸發確認時間點。
3.TCP將保持它首部和數據的檢驗和。這是一個端到端的檢驗和,目的是檢測數據在傳輸過程中的任何變化。如果收到段的檢驗和有差錯,TCP將丟棄這個報文段和不確認收到此報文段(希望發端超時並重發)。
4.既然TCP報文段作為IP數據報來傳輸,而IP數據報的到達可能會失序,因此TCP報文段的到達也可能會失序。如果必要,TCP將對收到的數據進行重新排序,將收到的數據以正確的順序交給應用層。
5.既然IP數據報會發生重複,TCP的接收端必須丟棄重複的數據。
兩個應用程序通過TCP連接交換8bit字節構成的字節流。TCP不在字節流中插入記錄標識符。我們將這稱為字節流服務(bytestreamservice)。如果一方的應用程序先傳10字節,又傳20字節,再傳50字節,連接的另一方將無法瞭解發方每次發送了多少字節。只要自己的接收緩存沒有塞滿,TCP 接收方將有多少就收多少。一端將字節流放到TCP連接上,同樣的字節流將出現在TCP連接的另一端。
TCP重傳策略
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報文。
限制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)發現功能是按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協議對比
TCP 是面向連接的傳輸控制協議,而UDP 提供了無連接的數據報服務;TCP 具有高可靠性,確保傳輸數據的正確性,不出現丟失或亂序;UDP 在傳輸數據前不建立連接,不對數據報進行檢查與修改,無須等待對方的應答,所以會出現分組丟失、重複、亂序,應用程序需要負責傳輸可靠性方面的所有工作;UDP 具有較好的實時性,工作效率較 TCP 協議高;UDP 段結構比 TCP 的段結構簡單,因此網絡開銷也小。TCP 協議可以保證接收端毫無差錯地接收到發送端發出的字節流,為應用程序提供可靠的通信服務。對可靠性要求高的通信系統往往使用 TCP 傳輸數據。比如 HTTP 運用 TCP 進行數據的傳輸。
[11]
- 參考資料
-
- 1. TRANSMISSION CONTROL PROTOCOL .IETF[引用日期2019-06-29]
- 2. Andrew S.Tanenbaum, David J. Wetherall.計算機網絡(第5版).北京:清華大學出版社,2012:438-439
- 3. 馮先成,李德駿主編. 計算機網絡及應用. 武漢市:華中科技大學出版社, 2011.07.
- 4. RFC 1122 .IETF[引用日期2019-06-29]
- 5. TCP Extensions for High Performance .IETF[引用日期2019-06-29]
- 6. RFC 2018 .IETF[引用日期2019-06-29]
- 7. RFC 2988 .IETF[引用日期2019-06-29]
- 8. RFC 3168 .IETF[引用日期2019-06-29]
- 9. A Roadmap for Transmission Control Protocol (TCP) Specification Documents .IETF[引用日期2019-06-29]
- 10. UDP協議與TCP協議的對比分析與可靠性改進 .知網[引用日期2019-06-29]
- 11. TCP、UDP網絡傳輸協議差異之我見 .知網[引用日期2019-06-29]
- 12. TCP三次握手與四次揮手 - 只有時間是永恆 - 博客園 .博客園[引用日期2022-07-24]
- 收起