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