TCP

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

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

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

互聯(lián)網與單一網絡非常不同，因為互聯(lián)網的不同部分可能具有完全不同的拓撲結構、帶寬、延遲、數(shù)據(jù)包大小和其他參數(shù)。TCP的設計目標是能夠動態(tài)地適應互聯(lián)網的這些特性，并且在面對各種故障時是健壯的。

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

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

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

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

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

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

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

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

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

為了保證可靠性，采用了超時重傳和捎帶確認機制。

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

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

1）慢啟動

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

2）擁塞避免

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

3）快速重傳

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

4）快速恢復

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

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

1）基于流的方式；

2）面向連接；

3）可靠通信方式；

4）當網絡條件不好時，盡量減少重傳帶來的帶寬開銷；

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

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

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

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

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

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

⑤失序處理：作為IP數(shù)據(jù)報傳輸?shù)腡CP片段在到達時可能是無序的TCP將對接收到的數(shù)據(jù)進行重新排序，并按照正確的順序將其移交給應用層；

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

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

建立連接

圖2 TCP的三次握手

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

TCP三次握手的過程如下：

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

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

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

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

連接終止

圖3 TCP連接的TCP終止

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

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

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

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

3）一段時間后，收到這個文件終止符的應用程序進程會調用close來關閉它的套接字。這導致其TCP也發(fā)送FIN。

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

因為每個方向需要一個FIN和一個ACK，所以通常需要四個部分。

注意：

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

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

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

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

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

實行標準

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

TCP/IP的標準在一個叫做RF的系列中

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

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