百科解釋
目錄·運(yùn)作方式·TCP的端口·TCP的封包結(jié)構(gòu)·TCP的發(fā)展過程·對(duì)TCP的選用情況·外部鏈接·參考資料 傳輸控制協(xié)議(Transmission Control Protocol, TCP)是一種面向連接的、可靠的、基于字節(jié)流的運(yùn)輸層(Transport layer)通信協(xié)議,由IETF的RFC 793說明(specified)。在簡(jiǎn)化的計(jì)算機(jī)網(wǎng)絡(luò)OSI模型中,它完成第四層傳輸層所指定的功能,UDP是同一層內(nèi)另一個(gè)重要的傳輸協(xié)議。 在因特網(wǎng)協(xié)議族(Internet protocol suite)中,TCP層是位于IP層之上,應(yīng)用層之下的中間層。不同主機(jī)的應(yīng)用層之間經(jīng)常需要可靠的、像管道一樣的連接,但是IP層不提供這樣的流機(jī)制,而是提供不可靠的包交換。 應(yīng)用層向TCP層發(fā)送用于網(wǎng)間傳輸?shù)、?位字節(jié)表示的數(shù)據(jù)流,然后TCP把數(shù)據(jù)流分割成適當(dāng)長(zhǎng)度的報(bào)文段(通常受該計(jì)算機(jī)連接的網(wǎng)絡(luò)的數(shù)據(jù)鏈路層的最大傳送單元(MTU)的限制)。之后TCP把結(jié)果包傳給IP層,由它來通過網(wǎng)絡(luò)將包傳送給接收端實(shí)體的TCP層。TCP為了保證不發(fā)生丟包,就給每個(gè)字節(jié)一個(gè)序號(hào),同時(shí)序號(hào)也保證了傳送到接收端實(shí)體的包的按序接收。然后接收端實(shí)體對(duì)已成功收到的字節(jié)發(fā)回一個(gè)相應(yīng)的確認(rèn)(ACK);如果發(fā)送端實(shí)體在合理的往返時(shí)延(RTT)內(nèi)未收到確認(rèn),那么對(duì)應(yīng)的數(shù)據(jù)(假設(shè)丟失了)將會(huì)被重傳。TCP用一個(gè)校驗(yàn)和函數(shù)來檢驗(yàn)數(shù)據(jù)是否有錯(cuò)誤;在發(fā)送和接收時(shí)都要計(jì)算校驗(yàn)和。 運(yùn)作方式 通路的建立和終結(jié) TCP連接包括三個(gè)狀態(tài):連接建立、數(shù)據(jù)傳送和連接終止。TCP用三路握手(three-way handshake)過程建立一個(gè)連接,用四路握手(four-way handshake)過程來拆除一個(gè)連接。在連接建立過程中,很多參數(shù)要被初始化,例如序號(hào)被初始化以保證按序傳輸和連接的強(qiáng)壯性。 TCP連接的正常建立 一對(duì)終端同時(shí)初始化一個(gè)它們之間的連接是可能的。但通常是由一端打開一個(gè)套接字(socket)然后監(jiān)聽來自另一方的連接,這就是通常所指的被動(dòng)打開(passive open)。服務(wù)器端被被動(dòng)打開以后,用戶端就能開始建立主動(dòng)打開(active open)。 客戶端通過向服務(wù)器端發(fā)送一個(gè)SYN來建立一個(gè)主動(dòng)打開,作為三路握手的一部分。 服務(wù)器端應(yīng)當(dāng)為一個(gè)合法的SYN回送一個(gè)SYN/ACK。 最后,客戶端再發(fā)送一個(gè)ACK。這樣就完成了三路握手,并進(jìn)入了連接建立狀態(tài)。 數(shù)據(jù)傳輸 在TCP的數(shù)據(jù)傳送狀態(tài),很多重要的機(jī)制保證了TCP的可靠性和強(qiáng)壯性。它們包括:使用序號(hào),對(duì)收到的TCP報(bào)文段進(jìn)行排序以及檢測(cè)重復(fù)的數(shù)據(jù);使用校驗(yàn)和來檢測(cè)報(bào)文段的錯(cuò)誤;使用確認(rèn)和計(jì)時(shí)器來檢測(cè)和糾正丟包或延時(shí)。 序列號(hào)和確認(rèn) 在TCP的連接建立狀態(tài),兩個(gè)主機(jī)的TCP層間要交換初始序號(hào) (ISN:initial sequence number)。這些序號(hào)用于標(biāo)識(shí)字節(jié)流中的數(shù)據(jù),并且還是對(duì)應(yīng)用層的數(shù)據(jù)字節(jié)進(jìn)行記數(shù)的整數(shù)。通常在每個(gè)TCP報(bào)文段中都有一對(duì)序號(hào)和確認(rèn)號(hào)。TCP報(bào)文發(fā)送者認(rèn)為自己的字節(jié)編號(hào)為序號(hào),而認(rèn)為接收者的字節(jié)編號(hào)為確認(rèn)號(hào)。TCP報(bào)文的接收者為了確保可靠性,在接收到一定數(shù)量的連續(xù)字節(jié)流后才發(fā)送確認(rèn)。這是對(duì)TCP的一種擴(kuò)展,通常稱為選擇確認(rèn)(Selective Acknowledgement)。選擇確認(rèn)使得TCP接收者可以對(duì)亂序到達(dá)的數(shù)據(jù)塊進(jìn)行確認(rèn)。每一個(gè)字節(jié)傳輸過后,ISN號(hào)都會(huì)遞增1。 通過使用序號(hào)和確認(rèn)號(hào),TCP層可以把收到的報(bào)文段中的字節(jié)按正確的順序交付給應(yīng)用層。序號(hào)是32位的無符號(hào)數(shù),在它增大到232-1時(shí),便會(huì)回繞到0。對(duì)于ISN的選擇是TCP中關(guān)鍵的一個(gè)操作,它可以確保強(qiáng)壯性和安全性。 數(shù)據(jù)傳輸舉例 TCP數(shù)據(jù)傳輸 放送方首先發(fā)送第一個(gè)包含序列號(hào)為1(可變化)和1460字節(jié)數(shù)據(jù)的TCP報(bào)文段給接收方。接收方以一個(gè)沒有數(shù)據(jù)的TCP報(bào)文段來回復(fù)(只含報(bào)頭),用確認(rèn)號(hào)1461來表示已完全收到并請(qǐng)求下一個(gè)報(bào)文段。 放送方然后發(fā)送第二個(gè)包含序列號(hào)為1461和1460字節(jié)數(shù)據(jù)的TCP報(bào)文段給接收方。正常情況下,接收方以一個(gè)沒有數(shù)據(jù)的TCP報(bào)文段來回復(fù),用確認(rèn)號(hào)2921來表示已完全收到并請(qǐng)求下一個(gè)報(bào)文段。發(fā)送接收這樣繼續(xù)下去。 然而當(dāng)這些數(shù)據(jù)包都是相連的情況下,接收方?jīng)]有必要每一次都回應(yīng)。比如,他收到第1到5條TCP報(bào)文段,只需回應(yīng)第五條就行了。在例子中第3條TCP報(bào)文段被丟失了,所以盡管他收到了第4和5條,然而他只能回應(yīng)第2條。 放送方在發(fā)送了第三條以后,沒能收到回應(yīng),因此當(dāng)時(shí)鐘(timer)過時(shí)(expire)時(shí),他重發(fā)第三條。(每次發(fā)送者發(fā)送一條TCP報(bào)文段后,都會(huì)重啟動(dòng)一次時(shí)鐘:RTT)。 這次第三條被成功接收,接收方可以直接確認(rèn)第5條,因?yàn)?,5兩條已收到。 校驗(yàn)和 TCP的16位的校驗(yàn)和(checksum)的計(jì)算和檢驗(yàn)過程如下:發(fā)送者將TCP報(bào)文段的頭部和數(shù)據(jù)部分的和計(jì)算出來,再對(duì)其求反碼(一的補(bǔ)數(shù)),就得到了校驗(yàn)和,然后將結(jié)果裝入報(bào)文中傳輸。(這里用反碼和的原因是這種方法的循環(huán)進(jìn)位使校驗(yàn)和可以在16位、32位、64位等情況下的計(jì)算結(jié)果在疊加后相同)接收者在收到報(bào)文后再按相同的算法計(jì)算一次校驗(yàn)和。這里使用的反碼使得接收者不用再將校驗(yàn)和字段保存起來后清零,而可以直接將報(bào)文段連同校驗(yàn)加總。如果計(jì)算結(jié)果是全部為一,那么就表示了報(bào)文的完整性和正確性。 注意:TCP校驗(yàn)和也包括了96位的偽頭部,其中有源地址、目的地址、協(xié)議以及TCP的長(zhǎng)度。這可以避免報(bào)文被錯(cuò)誤地路由。 按現(xiàn)在的標(biāo)準(zhǔn),TCP的校驗(yàn)和是一個(gè)比較脆弱的校驗(yàn)。具有高出錯(cuò)率的數(shù)據(jù)鏈路層需要額外的連接錯(cuò)誤糾正和探測(cè)能力。如果TCP是在今天被設(shè)計(jì),它很可能有一個(gè)32位的CRC校驗(yàn)來糾錯(cuò),而不是使用校驗(yàn)和。但是通過在第二層使用通常的CRC或更完全一點(diǎn)的校驗(yàn)可以部分地彌補(bǔ)這種脆弱的校驗(yàn)。第二層是在TCP層和IP層之下的,比如PPP或以太網(wǎng),它們使用了這些校驗(yàn)。但是這也并不意味著TCP的16位校驗(yàn)和是冗余的,對(duì)于因特網(wǎng)傳輸?shù)挠^察,表明在受CRC保護(hù)的各跳之間,軟件和硬件的錯(cuò)誤通常也會(huì)在報(bào)文中引入錯(cuò)誤,而端到端的TCP校驗(yàn)?zāi)軌虿蹲降胶芏嗟倪@種錯(cuò)誤。這就是應(yīng)用中的端到端原則。 流量控制和阻塞管理 數(shù)據(jù)發(fā)送者之間用對(duì)接收數(shù)據(jù)的確認(rèn)或不予確認(rèn)來顯式的表示TCP發(fā)送者和接收者之間的網(wǎng)絡(luò)狀態(tài)。再加上計(jì)時(shí)器,TCP發(fā)送者和接收者就可以改變數(shù)據(jù)的流動(dòng)情況。這就是通常所指的流量控制(Flow control),擁塞控制/或擁塞避免。TCP使用大量的機(jī)制來同時(shí)獲得強(qiáng)壯性和高可靠性。這些機(jī)制包括:滑動(dòng)窗口、慢啟動(dòng)算法、擁塞避免算法、快速重啟和快速恢復(fù)算法等等。對(duì)于TCP的可靠的丟包處理、錯(cuò)誤最小化、擁塞管理以及高速運(yùn)行環(huán)境等機(jī)制的優(yōu)化的研究和標(biāo)準(zhǔn)制定,正在進(jìn)行之中。 TCP數(shù)據(jù)傳輸不同于UDP之處 有序數(shù)據(jù)傳輸 重發(fā)丟失的封包 舍棄重復(fù)的封包 無錯(cuò)誤數(shù)據(jù)傳輸 阻塞/流量控制 通路的終結(jié) TCP連接的正常終止 連接終止?fàn)顟B(tài)使用了四路握手過程,在這個(gè)過程中每個(gè)終端的連接都能獨(dú)立地被終止。因此,一個(gè)典型的拆接過程需要每個(gè)終端都提供一對(duì)FIN和ACK。 TCP的端口 TCP使用了端口號(hào)的概念來標(biāo)識(shí)發(fā)送方和接收方的應(yīng)用層。對(duì)每個(gè)TCP連接的一端都有一個(gè)相關(guān)的16位元的無符號(hào)端口號(hào)分配給它們。端口被分為三類:眾所周知的、注冊(cè)的和動(dòng)態(tài)/私有的。眾所周知的端口號(hào)是由因特網(wǎng)賦號(hào)管理局(IANA)來分配的,并且通常被用于系統(tǒng)一級(jí)或根進(jìn)程。眾所周知的應(yīng)用程序作為服務(wù)器程序來運(yùn)行,并被動(dòng)地偵聽經(jīng)常使用這些端口的連接。例如:FTP、TELNET、SMTP、HTTP等。注冊(cè)的端口號(hào)通常被用來作為終端用戶連接服務(wù)器時(shí)短暫地使用的源端口號(hào),但它們也可以用來標(biāo)識(shí)已被第三方注冊(cè)了的、被命名的服務(wù)。動(dòng)態(tài)/私有的端口號(hào)在任何特定的TCP連接外不具有任何意義?赡艿摹⒈徽匠姓J(rèn)的端口號(hào)有65535個(gè)。 TCP的封包結(jié)構(gòu) TCP的發(fā)展過程 TCP是一個(gè)復(fù)雜的但同時(shí)又是在發(fā)展之中的協(xié)議。盡管許多重要的改進(jìn)被提出和實(shí)施,發(fā)表于1981年的RFC793中說明的TCP (TCP-Tahoe)的許多基本操作還是未作多大改動(dòng)。RFC1122:《因特網(wǎng)對(duì)主機(jī)的要求》闡明了許多TCP協(xié)議的實(shí)現(xiàn)要求。RFC2581:《TCP的擁塞控制》是一篇近年來關(guān)于TCP的很重要的RFC,描述了更新后的避免過度擁塞的算法。寫于2001年的RFC3168描述了對(duì)明顯擁塞的報(bào)告,這是一種擁塞避免的信號(hào)量機(jī)制。在21世紀(jì)早期,在所有因特網(wǎng)的數(shù)據(jù)包中,通常有大約95%的包使用了TCP協(xié)議。常見的使用TCP的應(yīng)用層有HTTP/HTTPS(萬維網(wǎng)協(xié)議),SMTP/POP3/IMAP(電子郵件協(xié)議)以及FTP(文件傳輸協(xié)議)。這些協(xié)議在今天被廣泛地使用,這證明了它們的原作者的創(chuàng)造是卓越的。 最近,一個(gè)新協(xié)議已經(jīng)被加州理工學(xué)院的科研人員開發(fā)出來,命名為FAST TCP(基于快速活動(dòng)隊(duì)列管理的規(guī)模可變的傳輸控制協(xié)議)。它使用排隊(duì)延遲作為擁塞控制信號(hào);但是因?yàn)槎说蕉说难舆t通常不僅僅包括排隊(duì)延遲,所以FAST TCP (或更一般地,所有基于排隊(duì)延遲的算法) 在實(shí)際互聯(lián)網(wǎng)中的能否工作仍然是一個(gè)沒有解決的問題。 對(duì)TCP的選用情況 TCP并不是對(duì)所有的應(yīng)用都適合,一些新的帶有一些內(nèi)在的脆弱性的運(yùn)輸層協(xié)議也被設(shè)計(jì)出來。比如,實(shí)時(shí)應(yīng)用并不需要甚至無法忍受TCP的可靠傳輸機(jī)制。在這種類型的應(yīng)用中,通常允許一些丟包、出錯(cuò)或擁塞,而不是去校正它們。例如通常不使用TCP的應(yīng)用有:實(shí)時(shí)流多媒體(如因特網(wǎng)廣播)、實(shí)時(shí)多媒體播放器和游戲、IP電話(VoIP)等等。任何不是很需要可靠性或者是想將功能減到最少的應(yīng)用可以避免使用TCP。在很多情況下,當(dāng)只需要多路復(fù)用應(yīng)用服務(wù)時(shí),用戶數(shù)據(jù)報(bào)協(xié)議(UDP)可以代替TCP為應(yīng)用提供服務(wù)。 外部鏈接 RFC 793 (1981年) RFC 1323 (1992年) 參考資料 Timothy S. Ramteke: Networks, Second Edition., Prentice-Hall 2001, ISBN 0-13-901265-6 Torsten Braun , Martina Zitterbart: Hochleistungskommunikation, Bd.2, Transportdienste und Transportprotokolle , Oldenbourg 1996, ISBN 978-3486230888
移動(dòng)通信網(wǎng) | 通信人才網(wǎng) | 更新日志 | 團(tuán)隊(duì)博客 | 免責(zé)聲明 | 關(guān)于詞典 | 幫助