TCP

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

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

傳輸控制協(xié)議（TCP, transport   control 3356 protocol）是一種傳輸協(xié)議，專門設(shè)計(jì)用于在不可靠的互聯(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è)計(jì)目標(biāo)是能夠動(dòng)態(tài)地適應(yīng)互聯(lián)網(wǎng)的這些特性，并且在面對各種故障時(shí)是健壯的。

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

應(yīng)用層向TCP層發(fā)送、用8位字節(jié)表示的數(shù)據(jù)流，然后TCP將數(shù)據(jù)流分割成適當(dāng)長度的段（通常是這臺計(jì)算機(jī)所連接的網(wǎng)絡(luò)的數(shù)據(jù)鏈路層的最大傳輸單元（MTU）的限制）然后TCP將結(jié)果包發(fā)送到IP層，IP層將通過網(wǎng)絡(luò)將包發(fā)送到接收實(shí)體的TCP層。TCP為每個(gè)數(shù)據(jù)包指定一個(gè)序列號，以確保數(shù)據(jù)包不會(huì)丟失，序列號還確保發(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ù)是否有錯(cuò)誤；發(fā)送和接收時(shí)應(yīng)計(jì)算校驗(yàn)和。

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

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

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

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

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

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

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

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

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

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

1）慢啟動(dòng)

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

2）擁塞避免

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

3）快速重傳

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

4）快速恢復(fù)

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

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

1）基于流的方式；

2）面向連接；

3）可靠通信方式；

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

5）通信連接的維護(hù)面向通信的兩個(gè)端點(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ù)時(shí)，它會(huì)根據(jù)碎片數(shù)據(jù)的序列號向發(fā)送方發(fā)送確認(rèn)；

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

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

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

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

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

建立連接

圖2 TCP的三次握手

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

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

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

2）接收此FIN的對等執(zhí)行“被動(dòng)關(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）一段時(shí)間后，收到這個(gè)文件終止符的應(yīng)用程序進(jìn)程會(huì)調(diào)用close來關(guān)閉它的套接字。這導(dǎo)致其TCP也發(fā)送FIN。

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

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

注意：

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

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

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

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

TCP 是面向連接的傳輸控制協(xié)議，而UDP 提供無連接的數(shù)據(jù)報(bào)服務(wù)；TCP 可靠性高，保證傳輸數(shù)據(jù)的正確性，不丟失，不亂序；UDP 在傳輸數(shù)據(jù)之前不建立連接，不檢查和修改數(shù)據(jù)報(bào)，也不需要等待對方 s回復(fù)，所以會(huì)出現(xiàn)丟包、重復(fù)、壞了，應(yīng)用程序需要負(fù)責(zé)傳輸可靠性的所有工作；UDP 比TCP  具有更好的實(shí)時(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é)議是一個(gè)工業(yè)標(biāo)準(zhǔn)協(xié)議集，用于廣域網(wǎng)（WAN）設(shè)計(jì)的。它是由阿帕網(wǎng)網(wǎng)絡(luò)研究所開發(fā)的。

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

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

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