標籤: 暫無標籤

傳輸控制協議(Transmission Control Protocol, TCP)是一種面向連接(連接導向)的、可靠的、基於位元組流的運輸層(Transport layer)通信協議,由IETF的RFC 793說明(specified)。

1 TCP -傳輸控制協議

傳輸控制協議(Transmission Control Protocol, TCP)是一種面向連接(連接導向)的、可靠的、基於位元組流的運輸層(Transport layer)通信協議,由IETF的RFC 793說明(specified)。在簡化的計算機網路OSI模型中,它完成第四層傳輸層所指定的功能,UDP是同一層內另一個重要的傳輸協議。

在網際網路協議族(Internet protocol suite)中,TCP層是位於IP層之上,應用層之下的中間層。不同主機的應用層之間經常需要可靠的、像管道一樣的連接,但是IP層不提供這樣的流機制,而是提供不可靠的包交換。

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

2 TCP -運作方式


通路的建立和終結


TCP連接包括三個狀態:連接建立、數據傳送和連接終止。TCP用三路握手(three-way handshake)過程建立一個連接,用四路握手(four-way handshake)過程來拆除一個連接。在連接建立過

TCPtcp建立連接

程中,很多參數要被初始化,例如序號被初始化以保證按序傳輸和連接的強壯性。
TCP連接的正常建立一對終端同時初始化一個它們之間的連接是可能的。但通常是由一端打開一個介面(socket)然後監聽來自另一方的連接,這就是通常所指的被動打開(passive open)。伺服器端被被動打開以後,用戶端就能開始建立主動打開(active open)。
1.客戶端通過向伺服器端發送一個SYN來建立一個主動打開,作為三路握手的一部分。
2.伺服器端應當為一個合法的SYN回送一個SYN/ACK。
3.最後,客戶端再發送一個ACK。這樣就完成了三路握手,並進入了連接建立狀態。 

數據傳輸

在TCP的數據傳送狀態,很多重要的機制保證了TCP的可靠性和強壯性。它們包括:使用序號,對收到的TCP報文段進行排序以及檢測重複的數據;使用校驗和來檢測報文段的錯誤;使用確認和計時器來檢測和糾正丟包或延時。


序列號和確認 

在TCP的連接建立狀態,兩個主機的TCP層間要交換初始序號 (ISN:initial sequence number)。這些序號用於標識位元組流中的數據,並且還是對應用層的數據位元組進行記數的整數。通常在每個TCP報文段中都有一對序號和確認號。TCP報文發送者認為自己的位元組編號為序號,而認為接收者的位元組編號為確認號。TCP報文的接收者為了確保可靠性,在接收到一定數量的連續位元組流后才發送確認。這是對TCP的一種擴展,通常稱為選擇確認(Selective Acknowledgement)。選擇確認使得TCP接收者可以對亂序到達的數據塊進行確認。每一個位元組傳輸過後,ISN號都會遞增1。

通過使用序號和確認號,TCP層可以把收到的報文段中的位元組按正確的順序交付給應用層。序號是32位的無符號數,在它增大到232-1時,便會迴繞到0。對於ISN的選擇是TCP中關鍵的一個操作,它可以確保強壯性和安全性。

數據傳輸舉例 

1.發送方首先發送第一個包含序列號為1(可變化)和1460位元組數據的TCP報文段給接收方。接收方以一個沒有數據的TCP報文段來回復(只含報頭),用確認號1461來表示已完全收到並請求下

TCPTCP數據傳輸

一個報文段。
2.發送方然後發送第二個包含序列號為1461和1460位元組數據的TCP報文段給接收方。正常情況下,接收方以一個沒有數據的TCP報文段來回復,用確認號2921(1461+1460)來表示已完全收到並請求下一個報文段。發送接收這樣繼續下去。
3.然而當這些數據包都是相連的情況下,接收方沒有必要每一次都回應。比如,他收到第1到5條TCP報文段,只需回應第五條就行了。在例子中第3條TCP報文段被丟失了,所以儘管他收到了第4和5條,然而他只能回應第2條。
4.發送方在發送了第三條以後,沒能收到回應,因此當時鐘(timer)過時(expire)時,他重發第三條。(每次發送者發送一條TCP報文段后,都會重啟動一次時鐘:RTT)。
5.這次第三條被成功接收,接收方可以直接確認第5條,因為4,5兩條已收到。


校驗和 

TCP的16位的校驗和(checksum)的計算和檢驗過程如下:發送者將TCP報文段的頭部和數據部分的和計算出來,再對其求反碼(一的補數),就得到了校驗和,然後將結果裝入報文中傳輸。(這裡用反碼和的原因是這種方法的循環進位使校驗和可以在16位、32位、64位等情況下的計算結果在疊加后相同)接收者在收到報文後再按相同的演算法計算一次校驗和。這裡使用的反碼使得接收者不用再將校驗和欄位保存起來后清零,而可以直接將報文段連同校驗加總。如果計算結果是全部為一,那麼就表示了報文的完整性和正確性。

注意:TCP校驗和也包括了96位的偽頭部,其中有源地址、目的地址、協議以及TCP的長度。這可以避免報文被錯誤地路由。

按現在的標準,TCP的校驗和是一個比較脆弱的校驗。具有高出錯率的數據鏈路層需要額外的連接錯誤糾正和探測能力。如果TCP是在今天被設計,它很可能有一個32位的CRC校驗來糾錯,而不是使用校驗和。但是通過在第二層使用通常的CRC或更完全一點的校驗可以部分地彌補這種脆弱的校驗。第二層是在TCP層和IP層之下的,比如PPP或乙太網,它們使用了這些校驗。但是這也並不意味著TCP的16位校驗和是冗餘的,對於網際網路傳輸的觀察,表明在受CRC保護的各跳之間,軟體和硬體的錯誤通常也會在報文中引入錯誤,而端到端的TCP校驗能夠捕捉到很多的這種錯誤。這就是應用中的端到端原則。

流量控制和阻塞管理 

數據發送者之間用對接收數據的確認或不予確認來顯式的表示TCP發送者和接收者之間的網路狀態。再加上計時器,TCP發送者和接收者就可以改變數據的流動情況。這就是通常所指的流量控制(Flow control),擁塞控制/或擁塞避免。TCP使用大量的機制來同時獲得強壯性和高可靠性。這些機制包括:滑動窗口、慢啟動演算法、擁塞避免演算法、快速重啟和快速恢復演算法等等。對於TCP的可靠的丟包處理、錯誤最小化、擁塞管理以及高速運行環境等機制的優化的研究和標準制定,正在進行之中。若有丟失封包,則從丟失的封包開始重送。UDP因為得確認正確了才能傳送下一階段,因此沒有辦法作流量管制。


TCP數據傳輸不同於UDP之處
1.有序數據傳輸
2.重發丟失的封包
3.捨棄重複的封包
4.無錯誤數據傳輸
5.阻塞/流量控制
6.連接導向(確認有建立三方交握,連線已建立才作傳輸。)

通路的終結

連接終止狀態使用了四路握手過程,在這個過程中每個終端的連接都能獨立地被終止。因此,一個典型的拆接過程需要每個終端都提供一對FIN和ACK。

TCPTCP正常終結


 

3 TCP -TCP的埠

TCP使用了埠號的概念來標識發送方和接收方的應用層。對每個TCP連接的一端都有一個相關的16位元的無符號埠號分配給它們。埠被分為三類:眾所周知的、註冊的和動態/私有的。眾所周知的埠號是由網際網路賦號管理局(IANA)來分配的,並且通常被用於系統一級或根進程。眾所周知的應用程序作為伺服器程序來運行,並被動地偵聽經常使用這些埠的連接。例如:FTP、TELNET、SMTP、HTTP等。註冊的埠號通常被用來作為終端用戶連接伺服器時短暫地使用的源埠號,但它們也可以用來標識已被第三方註冊了的、被命名的服務。動態/私有的埠號在任何特定的TCP連接外不具有任何意義。可能的、被正式承認的埠號有65535個。
 

4 TCP -TCP的封包結構

TCP封包

 

 

 

 

來源連接埠 (16位元長) - 辨識傳送連接埠
目的連接埠 (16位元長) - 辨識接收連接埠
序列號 (32位元長)
    如果含有同步化旗標 (SYN),則此為最初的序列號;第一個資料位元的序列碼為本序列號加一。
    如果沒有同步化旗標 (SYN),則此為第一個資料位元的序列碼。
 

5 TCP -TCP的發展過程

TCP是一個複雜的但同時又是在發展之中的協議。儘管許多重要的改進被提出和實施,發表於1981年的RFC793中說明的TCP (TCP-Tahoe)的許多基本操作還是未作多大改動。RFC1122:《網際網路對主機的要求》闡明了許多TCP協議的實現要求。RFC2581:《TCP的擁塞控制》是一篇近年來關於TCP的很重要的RFC,描述了更新后的避免過度擁塞的演算法。寫於2001年的RFC3168描述了對明顯擁塞的報告,這是一種擁塞避免的信號量機制。在21世紀早期,在所有網際網路的數據包中,通常有大約95%的包使用了TCP協議。常見的使用TCP的應用層有HTTP/HTTPS(萬維網協議),SMTP/POP3/IMAP(電子郵件協議)以及FTP(文件傳輸協議)。這些協議在今天被廣泛地使用,這證明了它們的原作者的創造是卓越的。

最近,一個新協議已經被加州理工學院的科研人員開發出來,命名為FAST TCP(基於快速活動隊列管理的規模可變的傳輸控制協議)。它使用排隊延遲作為擁塞控制信號;但是因為端到端的延遲通常不僅僅包括排隊延遲,所以FAST TCP (或更一般地,所有基於排隊延遲的演算法) 在實際互聯網中的能否工作仍然是一個沒有解決的問題。 

 

6 TCP -對TCP的選用情況

TCP並不是對所有的應用都適合,一些新的帶有一些內在的脆弱性的運輸層協議也被設計出來。比如,實時應用並不需要甚至無法忍受TCP的可靠傳輸機制。在這種類型的應用中,通常允許一些丟包、出錯或擁塞,而不是去校正它們。例如通常不使用TCP的應用有:實時流多媒體(如網際網路廣播)、實時多媒體播放器和遊戲、IP電話(VoIP)等等。任何不是很需要可靠性或者是想將功能減到最少的應用可以避免使用TCP。在很多情況下,當只需要多路復用應用服務時,用戶數據報協議(UDP)可以代替TCP為應用提供服務。
 

外部鏈接

7 TCP -參考資料

1.Timothy S. Ramteke: Networks, Second Edition., Prentice-Hall 2001, ISBN 0-13-901265-6
2.Torsten Braun , Martina Zitterbart: Hochleistungskommunikation, Bd.2, Transportdienste und Transportprotokolle , Oldenbourg 1996, ISBN 978-3486230888 
 

相關評論

同義詞:暫無同義詞