TCP

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

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

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

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

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

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

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

IP層不保證數據報必須被正確地傳遞給接收者，也不指示數據報發(fā)送的速度。TCP負責以足夠快的速度發(fā)送數據報，以便在不造成網絡擁塞的情況下使用網絡容量：而且TCP超時后，需要重新發(fā)送未送達的數據報。即使數據報提交正確，也有可能是亂序的，這也是TCP的責任，它必須將收到的數據報重新組裝成正確的順序。簡而言之，TCP必須提供可靠的性能，這正是大多數用戶所期望的，而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é)表示的數據流，TCP將數據流分成適當長度的段，最大傳輸段大?。∕SS）通常是這臺計算機所連接的網絡的數據鏈路層的最大傳輸單元（MTU）限制。然后TCP將數據包發(fā)送到IP層，IP層將通過網絡將數據包發(fā)送到接收實體的TCP層。

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

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

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

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

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

1）慢啟動

每次建立TCP連接或TCP連接超時重新傳輸后，連接進入慢啟動階段。進入慢啟動后，TCP實體將擁塞窗口的大小初始化為一個消息段，即：cwnd=1。此后，每當接收到消息段的確認時（ACK），cwnd值加1，即擁塞窗口呈指數增長。當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ī)定：

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

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

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

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

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

⑥重復處理：作為IP數據報傳輸的TCP片段會被復制，TCP的接收端必須丟棄復制的數據；

⑦數據校驗：TCP將保留其報頭和數據的校驗和，這是一種端到端校驗和，用于檢測傳輸過程中數據的任何變化。如果收到的片段的校驗和有錯誤，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客戶端和服務器已經成功建立連接，可以傳輸數據。

連接終止

圖3 TCP連接的TCP終止

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

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

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

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

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

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

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

注意：

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

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

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

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

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

實行標準

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）信息，提醒讀者信息的時效性。?