傳輸控制協(xié)議（TCP, transport   control 3356 protocol）是面向連接的、可靠的、IETF的RFC 793  定義了基于字節(jié)流的傳輸層通信協(xié)議。

TCP旨在適應(yīng)支持多網(wǎng)絡(luò)應(yīng)用的分層協(xié)議體系。連接到不同但互連的計算機(jī)通信網(wǎng)絡(luò)的主機(jī)中的成對進(jìn)程依賴于TCP來提供可靠的通信服務(wù)。TCP假設(shè)它可以從較低層協(xié)議獲得簡單且可能不可靠的數(shù)據(jù)報服務(wù)。原則上，TCP應(yīng)該能夠在從硬線連接到分組交換或電路交換網(wǎng)絡(luò)的各種通信系統(tǒng)上運(yùn)行。

傳輸控制協(xié)議（TCP, transport   control 3356 protocol）是一種傳輸協(xié)議，專門設(shè)計用于在不可靠的互聯(lián)網(wǎng)上提供可靠的端到端字節(jié)流。

互聯(lián)網(wǎng)與單一網(wǎng)絡(luò)非常不同，因?yàn)榛ヂ?lián)網(wǎng)的不同部分可能具有完全不同的拓?fù)浣Y(jié)構(gòu)、帶寬、延遲、數(shù)據(jù)包大小和其他參數(shù)。TCP的設(shè)計目標(biāo)是能夠動態(tài)地適應(yīng)互聯(lián)網(wǎng)的這些特性，并且在面對各種故障時是健壯的。

不同主機(jī)的應(yīng)用層通常需要可靠的、像管道一樣連接，但是IP層不提供這樣的流機(jī)制，而是提供不可靠的包交換。

應(yīng)用層向TCP層發(fā)送、用8位字節(jié)表示的數(shù)據(jù)流，然后TCP將數(shù)據(jù)流分割成適當(dāng)長度的段（通常是這臺計算機(jī)所連接的網(wǎng)絡(luò)的數(shù)據(jù)鏈路層的最大傳輸單元（MTU）的限制）然后TCP將結(jié)果包發(fā)送到IP層，IP層將通過網(wǎng)絡(luò)將包發(fā)送到接收實(shí)體的TCP層。TCP為每個數(shù)據(jù)包指定一個序列號，以確保數(shù)據(jù)包不會丟失，序列號還確保發(fā)送到接收實(shí)體的數(shù)據(jù)包按順序接收。則接收實(shí)體發(fā)送回對成功接收的分組的相應(yīng)確認(rèn)（ACK）如果發(fā)送實(shí)體具有合理的往返延遲（RTT）如果在內(nèi)沒有收到確認(rèn)，則認(rèn)為相應(yīng)的數(shù)據(jù)包丟失，并將重新發(fā)送。TCP使用校驗(yàn)和功能來檢查數(shù)據(jù)是否有錯誤；發(fā)送和接收時應(yīng)計算校驗(yàn)和。

每臺支持TCP的機(jī)器都有一個TCP傳輸實(shí)體。TCP實(shí)體可以是庫進(jìn)程、用戶進(jìn)程或內(nèi)核的一部分。在所有這些情況下，它管理TCP流和與IP層的接口。TCP傳輸實(shí)體接受本地進(jìn)程的用戶數(shù)據(jù)流，并將它們分成不超過64KB的部分（事實(shí)上，IP和TCP報頭被去除，通常不超過1460個數(shù)據(jù)字節(jié)）每個數(shù)據(jù)段作為單獨(dú)的IP數(shù)據(jù)報發(fā)送。當(dāng)包含TCP數(shù)據(jù)的數(shù)據(jù)報到達(dá)機(jī)器時，它們被提交給TCP傳輸實(shí)體，后者重建原始字節(jié)流。為了簡單起見，我們有時只用“TCP”來表示TCP傳輸實(shí)體（一段軟件）或者TCP協(xié)議（一組規(guī)則）根據(jù)上下文語義，你應(yīng)該能夠很容易地推斷出它的實(shí)際含義。例如，在“用戶將數(shù)據(jù)交給TCP”在這句話中，很明顯這指的是TCP傳輸實(shí)體。

IP層不保證數(shù)據(jù)報必須被正確地傳遞給接收者，也不指示數(shù)據(jù)報發(fā)送的速度。TCP負(fù)責(zé)以足夠快的速度發(fā)送數(shù)據(jù)報，以便在不造成網(wǎng)絡(luò)擁塞的情況下使用網(wǎng)絡(luò)容量：而且TCP超時后，需要重新發(fā)送未送達(dá)的數(shù)據(jù)報。即使數(shù)據(jù)報提交正確，也有可能是亂序的，這也是TCP的責(zé)任，它必須將收到的數(shù)據(jù)報重新組裝成正確的順序。簡而言之，TCP必須提供可靠的性能，這正是大多數(shù)用戶所期望的，而IP并沒有提供。

RFC793  在1981年9月給出了TCP的正式定義。隨著時間的推移，對它進(jìn)行了許多改進(jìn)，各種錯誤和不一致之處也逐漸得到了修復(fù)。

為了讓你感受到TCP的擴(kuò)展，現(xiàn)在重要的RFC有：RFC793plus澄清了描述，RFC1122  修復(fù)了bug、RFC1323  做了高性能的擴(kuò)展，RFC2018  定義了選擇性確認(rèn)，RFC2581解釋了擁塞控制、RFC2873定義了用于服務(wù)質(zhì)量的報頭字段，RFC2988  改進(jìn)了重傳定時器，RFC3168  定義了顯式擁塞通知。整套協(xié)議非常龐大，所以專門出版了一個針對很多RFC的指南，就是作為另一個RFC文檔出版的RFC4614。

當(dāng)應(yīng)用層向TCP層發(fā)送、對于用8位字節(jié)表示的數(shù)據(jù)流，TCP將數(shù)據(jù)流分成適當(dāng)長度的段，最大傳輸段大?。∕SS）通常是這臺計算機(jī)所連接的網(wǎng)絡(luò)的數(shù)據(jù)鏈路層的最大傳輸單元（MTU）限制。然后TCP將數(shù)據(jù)包發(fā)送到IP層，IP層將通過網(wǎng)絡(luò)將數(shù)據(jù)包發(fā)送到接收實(shí)體的TCP層。

為了保證消息傳輸?shù)目煽啃?，TCP給每個包一個序列號，序列號也保證了發(fā)送給接收實(shí)體的包的有序接收。則接收實(shí)體發(fā)送回對成功接收的字節(jié)的相應(yīng)確認(rèn)（ACK）如果發(fā)送實(shí)體具有合理的往返延遲（RTT）內(nèi)沒有收到確認(rèn)，則相應(yīng)的數(shù)據(jù)（假設(shè)丟失了）將會被重傳。

在數(shù)據(jù)正確性和合法性方面，TCP使用校驗(yàn)和函數(shù)來檢查數(shù)據(jù)是否有錯誤，并在發(fā)送和接收時計算校驗(yàn)和；同時，md5認(rèn)證可用于加密數(shù)據(jù)。

為了保證可靠性，采用了超時重傳和捎帶確認(rèn)機(jī)制。

在流量控制中，采用滑動窗口協(xié)議，規(guī)定窗口內(nèi)未確認(rèn)的數(shù)據(jù)包需要重傳。

在擁塞控制中，采用了廣受好評的TCP擁塞控制算法（也稱為AIMD算法）該算法主要包括四個主要部分：

1）慢啟動

每次建立TCP連接或TCP連接超時重新傳輸后，連接進(jìn)入慢啟動階段。進(jìn)入慢啟動后，TCP實(shí)體將擁塞窗口的大小初始化為一個消息段，即：cwnd=1。此后，每當(dāng)接收到消息段的確認(rèn)時（ACK），cwnd值加1，即擁塞窗口呈指數(shù)增長。當(dāng)cwnd值超過慢啟動值時（the third time）或者當(dāng)消息段丟失并重新傳輸時，慢啟動階段結(jié)束。前者進(jìn)入擁塞避免階段，后者重新進(jìn)入慢啟動階段。

2）擁塞避免

在慢啟動階段，當(dāng)cwnd值超過慢啟動解釋值時（the third time）之后，慢啟動過程結(jié)束，TCP連接進(jìn)入擁塞避免階段。在擁塞避免階段，每次發(fā)送的cwnd段被完全確認(rèn)后，cwnd值加1。在這個階段，cwnd值線性增加。

3）快速重傳

快速重傳是對超時重傳的改進(jìn)。當(dāng)源收到同一消息的三個重復(fù)確認(rèn)時，它確定某個消息段已丟失，因此它立即重新傳輸丟失的消息段，而不等待重新傳輸計時器（RTO）超時。以便減少不必要的等待時間。

4）快速恢復(fù)

快速恢復(fù)是對丟失恢復(fù)機(jī)制的改進(jìn)。快速重傳后，不經(jīng)過慢啟動過程，直接進(jìn)入擁塞避免階段?？焖僦貍骱笤O(shè)置ssthresh=cwnd/2、ewnd=ssthresh 3。此后，每當(dāng)接收到重復(fù)確認(rèn)時，cwnd值增加1，直到接收到丟失段和后續(xù)段的累積確認(rèn)，并且cwnd=ssthresh被設(shè)置為進(jìn)入擁塞避免階段。

TCP是用于WAN的通信協(xié)議，其目的是在跨多個網(wǎng)絡(luò)通信時，在兩個通信端點(diǎn)之間提供具有以下特征的通信模式：

1）基于流的方式；

2）面向連接；

3）可靠通信方式；

4）當(dāng)網(wǎng)絡(luò)條件不好時，盡量減少重傳帶來的帶寬開銷；

5）通信連接的維護(hù)面向通信的兩個端點(diǎn)，不考慮中間網(wǎng)段和節(jié)點(diǎn)。

為了滿足TCP協(xié)議的這些特性，TCP協(xié)議做出了如下規(guī)定：

①數(shù)據(jù)分片：用戶數(shù)據(jù)在發(fā)送端被分段，并在接收端被重組TCP確定碎片的大小，并控制碎片和重組；

②到達(dá)確認(rèn)：當(dāng)接收方收到碎片數(shù)據(jù)時，它會根據(jù)碎片數(shù)據(jù)的序列號向發(fā)送方發(fā)送確認(rèn)；

③超時重發(fā)：發(fā)送方在發(fā)送片段時啟動超時定時器，如果定時器超時后沒有收到相應(yīng)的確認(rèn)，則重傳該片段；

④滑動窗口：TCP連接每一端的接收緩沖區(qū)空間是固定的，接收端只允許另一端發(fā)送接收端緩沖區(qū)能容納的數(shù)據(jù)TCP在滑動窗口的基礎(chǔ)上提供流量控制，防止速度較慢的主機(jī)因速度較快的主機(jī)造成緩沖區(qū)溢出；

⑤失序處理：作為IP數(shù)據(jù)報傳輸?shù)腡CP片段在到達(dá)時可能是無序的TCP將對接收到的數(shù)據(jù)進(jìn)行重新排序，并按照正確的順序?qū)⑵湟平唤o應(yīng)用層；

⑥重復(fù)處理：作為IP數(shù)據(jù)報傳輸?shù)腡CP片段會被復(fù)制，TCP的接收端必須丟棄復(fù)制的數(shù)據(jù)；

⑦數(shù)據(jù)校驗(yàn)：TCP將保留其報頭和數(shù)據(jù)的校驗(yàn)和，這是一種端到端校驗(yàn)和，用于檢測傳輸過程中數(shù)據(jù)的任何變化。如果收到的片段的校驗(yàn)和有錯誤，TCP將丟棄該片段，并且不會確認(rèn)收到該片段，這將導(dǎo)致對等方超時并重新發(fā)送它。

建立連接

圖2 TCP的三次握手

TCP是互聯(lián)網(wǎng)中的傳輸層協(xié)議，它使用三次握手協(xié)議來建立連接。當(dāng)主動方發(fā)出SYN連接請求時，等待對方應(yīng)答SYN ACK，最后對對方進(jìn)行 ACK 確認(rèn) s  SYN 。這種建立連接的方法可以防止錯誤連接，TCP使用的流量控制協(xié)議是一種可變大小的滑動窗口協(xié)議。

TCP三次握手的過程如下：

客戶端發(fā)送SYN（SEQ=x）消息發(fā)送到服務(wù)器，輸入SYN_SEND狀態(tài)。

服務(wù)器接收SYN消息，并以SYN 作為響應(yīng)（SEQ=y）ACK（ACK=x+1）消息，輸入SYN_RECV狀態(tài)。

客戶端從服務(wù)器接收SYN消息，并以ACK作為響應(yīng)（ACK=y+1）消息，進(jìn)入已建立狀態(tài)。

三次握手完成，TCP客戶端和服務(wù)器已經(jīng)成功建立連接，可以傳輸數(shù)據(jù)。

連接終止

圖3 TCP連接的TCP終止

建立一個連接需要三次握手，但是終止一個連接需要四次握手，這是TCP半封閉的（half-close）造成的。具體流程如下圖所示。

1）一個應(yīng)用程序進(jìn)程首先調(diào)用close，稱為結(jié)束執(zhí)行“主動關(guān)閉”active close關(guān)閉關(guān)閉）然后，這一端的TCP發(fā)送一個FIN段，表示數(shù)據(jù)傳輸完成。

2）接收此FIN的對等執(zhí)行“被動關(guān)閉”Passive   off）TCP證實(shí)了這一發(fā)現(xiàn)。

注意：FIN的收據(jù)也用作文件終止符（end-of-file）將它傳遞給接收端的應(yīng)用程序進(jìn)程，并將其放在任何其他已排隊(duì)等待應(yīng)用程序進(jìn)程接收的數(shù)據(jù)之后，因?yàn)镕IN的接收意味著接收端的應(yīng)用程序進(jìn)程在相應(yīng)的連接上沒有額外的數(shù)據(jù)要接收。

3）一段時間后，收到這個文件終止符的應(yīng)用程序進(jìn)程會調(diào)用close來關(guān)閉它的套接字。這導(dǎo)致其TCP也發(fā)送FIN。

4）接收此最終fin的原始發(fā)送者TCP（即執(zhí)行主動關(guān)機(jī)的一端）確認(rèn)這個FIN。

因?yàn)槊總€方向需要一個FIN和一個ACK，所以通常需要四個部分。

注意：

1） “通?！币簿褪钦f，在某些情況下，步驟1中的FIN是和數(shù)據(jù)一起發(fā)送的另外，步驟2和3中發(fā)送的區(qū)段來自執(zhí)行非能動停堆的端部，并且可以合并成一個區(qū)段。

2）在步驟2和步驟3之間，可以將數(shù)據(jù)從執(zhí)行被動關(guān)閉一端流動到執(zhí)行主動關(guān)閉一端，這被稱為“半關(guān)閉”half-close）

3）當(dāng)一個Unix進(jìn)程，無論是自愿的（）還是非自愿地（收到終止此進(jìn)程的信號）當(dāng)終止時，所有打開的描述符都被關(guān)閉，這也導(dǎo)致FIN在任何仍然打開的TCP連接上被發(fā)出。

客戶端或服務(wù)器都可以執(zhí)行主動關(guān)機(jī)。通常，客戶端執(zhí)行主動關(guān)機(jī)，但是一些協(xié)議，如HTTP/1.0被服務(wù)器主動關(guān)閉。

TCP 是面向連接的傳輸控制協(xié)議，而UDP 提供無連接的數(shù)據(jù)報服務(wù)；TCP 可靠性高，保證傳輸數(shù)據(jù)的正確性，不丟失，不亂序；UDP 在傳輸數(shù)據(jù)之前不建立連接，不檢查和修改數(shù)據(jù)報，也不需要等待對方 s回復(fù)，所以會出現(xiàn)丟包、重復(fù)、壞了，應(yīng)用程序需要負(fù)責(zé)傳輸可靠性的所有工作；UDP 比TCP  具有更好的實(shí)時性和更高的工作效率；UDP 的段結(jié)構(gòu)比TCP  簡單，所以網(wǎng)絡(luò)開銷也小。TCP 協(xié)議可以保證接收方能夠無誤地接收到發(fā)送方發(fā)送的字節(jié)流，為應(yīng)用提供可靠的通信服務(wù)。要求高可靠性的通信系統(tǒng)往往使用 TCP 來傳輸數(shù)據(jù)。比如 HTTP 使用 TCP 進(jìn)行數(shù)據(jù)傳輸。

實(shí)行標(biāo)準(zhǔn)

TCP/IP(Transport   Control   Protocol/Internet   protocol) 是傳輸控制協(xié)議/互聯(lián)網(wǎng)協(xié)議是一個工業(yè)標(biāo)準(zhǔn)協(xié)議集，用于廣域網(wǎng)（WAN）設(shè)計的。它是由阿帕網(wǎng)網(wǎng)絡(luò)研究所開發(fā)的。

TCP/IP的標(biāo)準(zhǔn)在一個叫做RF的系列中

C的文檔中公布。文檔由技術(shù)專家、特別工作組、或RFC編輯版本。當(dāng)文檔發(fā)布時，它會被賦予一個RFC編號，例如RFC959（FTP描述文件）RFC793（TCP描述文件）RFC791（IP的說明文檔）等。原始RFC一直保留，從未更新

如果文檔被修改，它將以新的編號發(fā)布。因此，確保您擁有某個主題的最新RFC文檔是很重要的。通常，在RFC開始時，會有相關(guān)的RFC更新(update)排錯（errata）作廢（discard）信息，提醒讀者信息的時效性。?