系統架構設計筆記（95）—— TCP 協議

傳輸控制協議（ TCP ， Transmission Control Protocol ）是一種面向連線的 、 可靠的 、 基於位元組流的傳輸層通訊協議，由 IETF 的 RFC793 定義。

TCP 旨在適應支援多網路應用的分層協議層次結構。連線到不同但互連的計算機通訊網路的主計算機中的成對程式之間依靠 TCP 提供可靠的通訊服務。 TCP 假設它可以從較低階別的協議獲得簡單的，可能不可靠的資料包服務。原則上， TCP 應該能夠在從硬線連線到分組交換或電路交換網路的各種通訊系統之上操作。

1 簡介

傳輸控制協議（ TCP ， Transmission Control Protocol ）是為了在不可靠的網際網路絡上提供可靠的端到端位元組流而專門設計的一個傳輸協議 。

網際網路絡與單個網路有很大的不同，因為網際網路絡的不同部分可能有截然不同的拓撲結構 、 頻寬 、 延遲 、 資料包大小和其他引數。 TCP 的設計目標是能夠動態地適應網際網路絡的這些特性，而且具備面對各種故障時的健壯性 。

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

應用層向 TCP 層傳送用於網間傳輸的 、 用8位位元組表示的資料流，然後 TCP 把資料流分割槽成適當長度的報文段（通常受該計算機連線的網路的資料鏈路層的最大傳輸單元（ MTU ）的限制）。之後 TCP 把結果包傳給 IP 層，由它來通過網路將包傳送給接收端實體的 TCP 層。 TCP 為了保證不發生丟包，就給每個包一個序號，同時序號也保證了傳送到接收端實體的包的按序接收。然後接收端實體對已成功收到的包發回一個相應的確認（ ACK ）；如果傳送端實體在合理的往返時延（ RTT ）內未收到確認，那麼對應的資料包就被假設為已丟失將會被進行重傳。 TCP 用一個校驗和函式來檢驗資料是否有錯誤；在傳送和接收時都要計算校驗和 。

IP 層並不保證資料包一定被正確地遞交到接收方，也不指示資料包的傳送速度有多快。正是 TCP 負責既要足夠快地傳送資料包，以便使用網路容量，但又不能引起網路擁塞：而且， TCP 超時後，要重傳沒有遞交的資料包。即使被正確遞交的資料包，也可能存在錯序的問題，這也是 TCP 的責任，它必須把接收到的資料包重新裝配成正確的順序。簡而言之， TCP 必須提供可靠性的良好效能，這正是大多數使用者所期望的而 IP 又沒有提供的功能 。

2 主要功能

當應用層向 TCP 層傳送用於網間傳輸的 、 用8位位元組表示的資料流， TCP 則把資料流分割成適當長度的報文段，最大傳輸段大小（ MSS ）通常受該計算機連線的網路的資料鏈路層的最大傳送單元（ MTU ）限制。之後 TCP 把資料包傳給 IP 層，由它來通過網路將包傳送給接收端實體的 TCP 層。

TCP 為了保證報文傳輸的可靠，就給每個包一個序號，同時序號也保證了傳送到接收端實體的包的按序接收。然後接收端實體對已成功收到的位元組發回一個相應的確認（ ACK ）；如果傳送端實體在合理的往返時延（ RTT ）內未收到確認，那麼對應的資料（假設丟失了）將會被重傳。

• 在資料正確性與合法性上， TCP 用一個校驗和函式來檢驗資料是否有錯誤，在傳送和接收時都要計算校驗和；同時可以使用 md5 認證對資料進行加密。
• 在保證可靠性上，採用超時重傳和捎帶確認機制。
• 在流量控制上，採用滑動視窗協議，協議中規定，對於視窗內未經確認的分組需要重傳。
• 在擁塞控制上，採用廣受好評的 TCP 擁塞控制演算法（也稱 AIMD 演算法）。

3 主要特點

TCP 是一種面向廣域網的通訊協議，目的是在跨越多個網路通訊時，為兩個通訊端點之間提供一條具有下列特點的通訊方式：

（1）基於流的方式；
（2）面向連線；
（3）可靠通訊方式；
（4）在網路狀況不佳的時候儘量降低系統由於重傳帶來的頻寬開銷；
（5）通訊連線維護是面向通訊的兩個端點的，而不考慮中間網段和節點。

為滿足 TCP 協議的這些特點， TCP 協議做了如下的規定：

① 資料分片：在傳送端對使用者資料進行分片，在接收端進行重組，由 TCP 確定分片的大小並控制分片和重組；

② 到達確認：接收端接收到分片資料時，根據分片資料序號向傳送端傳送一個確認；

③ 超時重發：傳送方在傳送分片時啟動超時定時器，如果在定時器超時之後沒有收到相應的確認，重發分片；

④ 滑動視窗： TCP 連線每一方的接收緩衝空間大小都固定，接收端只允許另一端傳送接收端緩衝區所能接納的資料， TCP 在滑動視窗的基礎上提供流量控制，防止較快主機致使較慢主機的緩衝區溢位；

⑤ 失序處理：作為 IP 資料包來傳輸的 TCP 分片到達時可能會失序， TCP 將對收到的資料進行重新排序，將收到的資料以正確的順序交給應用層；

⑥ 重複處理：作為 IP 資料包來傳輸的 TCP 分片會發生重複， TCP 的接收端必須丟棄重複的資料；

⑦ 資料校驗： TCP 將保持它首部和資料的檢驗和，這是一個端到端的檢驗和，目的是檢測資料在傳輸過程中的任何變化。如果收到分片的檢驗和有差錯， TCP 將丟棄這個分片。

4 可靠性實現

4.1 可靠性

TCP 提供一種面向連線的 、 可靠的位元組流服務。面向連線意味著兩個使用 TCP 的應用（通常是一個客戶和一個伺服器）在彼此交換資料包之前必須先建立一個 TCP 連線。這一過程與打電話很相似，先撥號振鈴，等待對方摘機說 “ 喂 ” ，然後才說明是誰。在一個 TCP 連線中，僅有兩方進行彼此通訊。廣播和多播不能用於 TCP 。

TCP通過下列方式來提供可靠性：

1. 應用資料被分割成 TCP 認為最適合傳送的資料塊。這和 UDP 完全不同，應用程式產生的資料長度將保持不變。由 TCP 傳遞給 IP 的資訊單位稱為報文段或段（ segment ） 。

2. 當 TCP 發出一個段後，它啟動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發這個報文段。當 TCP 收到發自 TCP 連線另一端的資料，它將傳送一個確認。 TCP 有延遲確認的功能，在此功能沒有開啟，則是立即確認。功能開啟，則由定時器觸發確認時間點。

3. TCP 將保持它首部和資料的檢驗和。這是一個端到端的檢驗和，目的是檢測資料在傳輸過程中的任何變化。如果收到段的檢驗和有差錯， TCP 將丟棄這個報文段和不確認收到此報文段（希望發端超時並重發） 。

4. 既然 TCP 報文段作為 IP 資料包來傳輸，而 IP 資料包的到達可能會失序，因此 TCP 報文段的到達也可能會失序。如果必要， TCP 將對收到的資料進行重新排序，將收到的資料以正確的順序交給應用層 。

5. 既然 IP 資料包會發生重複， TCP 的接收端必須丟棄重複的資料。

6. TCP 還能提供流量控制。 TCP 連線的每一方都有固定大小的緩衝空間。 TCP 的接收端只允許另一端傳送接收端緩衝區所能接納的資料。這將防止較快主機致使較慢主機的緩衝區溢位。

兩個應用程式通過 TCP 連線交換 8bit 位元組構成的位元組流。 TCP 不在位元組流中插入記錄識別符號。我們將這稱為位元組流服務（ byte stream service ）。如果一方的應用程式先傳 10 位元組，又傳 20 位元組，再傳 50 位元組，連線的另一方將無法瞭解發方每次傳送了多少位元組。只要自己的接收快取沒有塞滿， TCP 接收方將有多少就收多少。一端將位元組流放到 TCP 連線上，同樣的位元組流將出現在 TCP 連線的另一端。

另外， TCP 對位元組流的內容不作任何解釋。 TCP 不知道傳輸的資料位元組流是二進位制資料，還是 ASCⅡ 字元 、EBCDIC 字元或者其他型別資料。對位元組流的解釋由 TCP 連線雙方的應用層解釋 。

這種對位元組流的處理方式與 Unix 作業系統對檔案的處理方式很相似。 Unix 的核心對一個應用讀或寫的內容不作任何解釋，而是交給應用程式處理。對 Unix 的核心來說，它無法區分一個二進位制檔案與一個文字檔案。

4.2 重傳策略

TCP 協議用於控制資料段是否需要重傳的依據是設立重發定時器。在傳送一個資料段的同時啟動一個重傳，如果在重傳超時前收到確認（ Acknowlegement ）就關閉該重傳，如果重傳超時前沒有收到確認，則重傳該資料段。在選擇重發時間的過程中， TCP 必須具有自適應性。它需要根據網際網路當時的通訊情況，給出合適的重發時間。

這種重傳策略的關鍵是對定時器初值的設定。採用較多的演算法是 Jacobson 於 1988 年提出的一種不斷調整超時時間間隔的動態演算法。其工作原理是：對每條連線 TCP 都保持一個變數 RTT （ Round Trip Time ），用於存放當前到目的端往返所需要時間最接近的估計值。當傳送一個資料段時，同時啟動連線的定時器，如果在定時器超時前確認到達，則記錄所需要的時間（ M ），並修正 RTT 的值，如果定時器超時前沒有收到確認，則將 RTT 的值增加1倍。通過測量一系列的 RTT （往返時間）值， TCP 協議可以估算資料包重發前需要等待的時間。在估計該連線所需的當前延遲時通常利用一些統計學的原理和演算法（如 Karn 演算法），從而得到 TCP 重發之前需要等待的時間值。

4.3 視窗確認

TCP 的一項功能就是確保每個資料段都能到達目的地。位於目的主機的 TCP 服務對接受到的資料進行確認，並向源應用程式傳送確認資訊。

使用資料包頭序列號以及確認號來確認已收到包含在資料段的相關的資料位元組。 TCP 在發回源裝置的資料段中使用確認號，指示接收裝置期待接收的下一位元組。這個過程稱為期待確認。

源主機在收到確認訊息之前可以傳輸的資料的大小稱為視窗大小。用於管理丟失資料和流量控制。

5 協議對比

TCP 是面向連線的傳輸控制協議，而 UDP 提供了無連線的資料包服務；

TCP 具有高可靠性，確保傳輸資料的正確性，不出現丟失或亂序； UDP 在傳輸資料前不建立連線，不對資料包進行檢查與修改，無須等待對方的應答，所以會出現分組丟失 、 重複 、 亂序，應用程式需要負責傳輸可靠性方面的所有工作；

UDP 具有較好的實時性，工作效率較 TCP 協議高；

UDP 段結構比 TCP 的段結構簡單，因此網路開銷也小。

TCP 協議可以保證接收端毫無差錯地接收到傳送端發出的位元組流，為應用程式提供可靠的通訊服務。對可靠性要求高的通訊系統往往使用 TCP 傳輸資料。比如 HTTP 運用 TCP 進行資料的傳輸。

6 滑動視窗協議

滑動視窗協議的基本原理就是在任意時刻，傳送方都維持了一個連續的允許傳送的幀的序號，稱為傳送視窗；同時，接收方也維持了一個連續的允許接收的幀的序號，稱為接收視窗。傳送視窗和接收視窗的序號的上下界不一定要一樣，甚至大小也可以不同。不同的滑動視窗協議視窗大小一般不同。傳送方視窗內的序列號代表了那些已經被髮送，但是還沒有被確認的幀，或者是那些可以被髮送的幀。

傳送和接受方都會維護一個資料幀的序列，這個序列被稱作視窗。傳送方的視窗大小由接受方確定，目的在於控制傳送速度，以免接受方的快取不夠大，而導致溢位，同時控制流量也可以避免網路擁塞。

上圖中的4，5，6號資料幀已經被髮送出去，但是還未收到關聯的 ACK ，7，8， 9 幀則是等待傳送。可以看出傳送端的視窗大小為 6，這是由接受端確定並告知的。此時如果傳送端收到4號 ACK ，則視窗的左邊緣向右收縮，視窗的右邊緣則向右擴充套件，此時視窗就向前 “ 滑動了 ” ，即資料幀 10 也可以被髮送。

7 擁塞控制

TCP的擁塞控制由4個核心演算法組成：“慢啟動”（Slow Start）、“擁塞避免”（Congestion voidance）、“快速重傳 ”（Fast Retransmit）、“快速恢復”（Fast Recovery）。

7.1 慢開始演算法

當主機開始傳送資料時，如果立即將大量資料位元組注入到網路，那麼就有可能引起網路擁塞，因為現在並不清楚網路的負荷情況。因此，較好的方法是先探測一下，即由小到大逐漸增大傳送視窗，也就是說，由小到大逐漸增大擁塞視窗數值。

通常在剛剛開始傳送報文段時，先把擁塞視窗 cwnd 設定為一個最大報文段MSS的數值。而在每收到一個對新的報文段的確認後，把擁塞視窗增加至多一個MSS的數值。用這樣的方法逐步增大傳送方的擁塞視窗 cwnd ，可以使分組注入到網路的速率更加合理。

7.2 擁塞避免演算法

讓擁塞視窗cwnd緩慢地增大，即每經過一個往返時間RTT就把傳送方的擁塞視窗cwnd加1，而不是加倍。這樣擁塞視窗cwnd按線性規律緩慢增長，比慢開始演算法的擁塞視窗增長速率緩慢得多。

“擁塞避免”是說在擁塞避免階段將擁塞視窗控制為按線性規律增長，使網路比較不容易出現擁塞。

7.3 快速重傳

當發生三次重複確認，即使沒有超時，也會重傳，叫做快速重傳。重傳完畢，閥值減半，就像發生超時一樣，慢啟動開始，到了閥值，再線性增長。

7.4 快速恢復

快速重傳後，擁塞視窗被設定到慢啟動的閥值，開始線性增長。