TCP大致工作原理介紹：

工作原理

TCP-IP詳解卷1第17章中17.2節對TCP服務原理作了一個簡明介紹(以下藍色字型摘自《TCP-IP詳解卷1第17章17.2節》)：

儘管T C P和U D P都使用相同的網路層（I P），T C P卻嚮應用層提供與UD P完全不同的服務。

TC P提供一種面向連線的、可靠的位元組流服務。面向連線意味著兩個使用T C P的應用（通常是一個客戶和一個伺服器）在彼此交換資料之前必須先建立一個TCP連線。這一過程與打電話很相似，先撥號振鈴，等待對方摘機說“喂”，然後才說明是誰。在第1 8章我們將看到一個T C P連線是如何建立的，以及當一方通訊結束後如何斷開連線。

在一個TCP連線中，僅有兩方進行彼此通訊。在第12章介紹的廣播和多播不能用於TCP。

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

•應用資料被分割成T C P認為最適合傳送的資料塊。這和U D P完全不同，應用程式產生的資料報長度將保持不變。由T C P傳遞給I P的資訊單位稱為報文段或段（s e g m e n t）（參見圖1-7）。在18.4節我們將看到T C P如何確定報文段的長度。

•當TCP發出一個段後，它啟動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發這個報文段。在第2 1章我們將瞭解TCP協議中自適應的超時及重傳策略。

•當TCP收到發自TCP連線另一端的資料，它將傳送一個確認。這個

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

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

•既然I P資料報會發生重複，T C P的接收端必須丟棄重複的資料。

• T C P還能提供流量控制。T C P連線的每一方都有固定大小的緩衝空間。TCP

例如：如果一方的應用程式先傳1 0位元組，又傳2 0位元組，再傳5 0位元組，連線的另一方將無法瞭解發方每次傳送了多少位元組。收方可以分4次接收這8 0個位元組，每次接收2 0位元組。一端將位元組流放到TCP連線上，同樣的位元組流將出現在T C P連線的另一端。另外，TC P對位元組流的內容不作任何解釋。T C P不知道傳輸的資料位元組流是二進位制資料，還是A S C I I字元、E B C D I C字元或者其他型別資料。對位元組流的解釋由T C P連線雙方的應用層解釋。這種對位元組流的處理方式與Un i x作業系統對檔案的處理方式很相似。U n i x的核心對一個應用讀或寫的內容不作任何解釋，而是交給應用程式處理。對U n i x的核心來說，它無法區分一個二進位制檔案與一個文字檔案。

TC P如何確定報文段的長度

我仍然引用官方解釋《TCP-IP詳解卷1》第18章18.4節：

最大報文段長度（M S S）表示T C P傳往另一端的最大塊資料的長度。當一個連線建立時【三次握手】，連線的雙方都要通告各自的M S S。我們已經見過M S S都是1 0 2 4。這導致IP資料報通常是4 0位元組長：2 0位元組的T C P首部和2 0位元組的I P首部。

在有些書中，將它看作可“協商”選項。它並不是任何條件下都可協商。當建立一個連線時，每一方都有用於通告它期望接收的M S S選項（M S S選項只能出現在SY N報文段中）。如果一方不接收來自另一方的M S S值，則MS S就定為預設值5 3 6位元組（這個預設值允許2 0位元組的I P首部和2 0位元組的T C P首部以適合5 7 6位元組I P資料報)。

一般說來，如果沒有分段發生，M S S還是越大越好（這也並不總是正確，參見圖2 4 -3和圖2 4 - 4中的例子）。報文段越大允許每個報文段傳送的資料就越多，相對I P和T C P首部有更高的網路利用率。當T C P傳送一個S Y N時，或者是因為一個本地應用程序想發起一個連線，或者是因為另一端的主機收到了一個連線請求，它能將MS S值設定為外出介面上的M T U長度減去固定的IP首部和T C P首部長度。對於一個乙太網，M S S值可達1 4 6 0位元組。使用IEEE 802.3的封裝（參見2 . 2節），它的M S S可達1 45 2位元組。

如果目的I P地址為“非本地的( n o n l o c a l )”，M S S通常的預設值為5 3 6。而區分地址是本地還是非本地是簡單的，如果目的I P地址的網路號與子網號都和我們的相同，則是本地的；如果目的I P地址的網路號與我們的完全不同，則是非本地的；如果目的I P地址的網路號與我們的相同而子網號與我們的不同，則可能是本地的，也可能是非本地的。大多數T C P實現版都提供了一個配置選項（附錄E和圖E - 1），讓系統管理員說明不同的子網是屬於本地還是非本地。這個選項的設定將確定M SS可以選擇儘可能的大（達到外出介面的M T U長度）或是預設值53 6。

MS S讓主機限制另一端傳送資料報的長度。加上主機也能控制它傳送資料報的長度，這將使以較小M T U連線到一個網路上的主機避免分段。

只有當一端的主機以小於5 7 6位元組的M T U直接連線到一個網路中，避免這種分段才會有效。

如果兩端的主機都連線到乙太網上，都採用5 3 6的M S S，但中間網路採用29 6的M T U，也將會

出現分段。使用路徑上的M TU發現機制（參見2 4 . 2節）是關於這個問題的唯一方法。

以上說明MSS的值可以通過協商解決，這個協商過程會涉及MTU的值的大小，前面說了：【MSS=外出介面上的MTU-IP首部-TCP首部】，我們來看看資料進入TCP協議棧的封裝過程：

最後一層乙太網幀的大小應該就是我們的出口ＭＴＵ大小了。當目的主機收到一個乙太網資料幀時，資料就開始從協議棧中由底向上升，同時去掉各層協議加上的報文首部。每層協議盒都要去檢查報文首部中的協議標識，以確定接收資料的上層協議。這個過程稱作分用（ D e m u l t i p l e x i n g），圖1 - 8顯示了該過程是如何發生的。

那麼什麼是MTU呢，這實際上是資料鏈路層的一個概念，乙太網和802.3這兩種區域網技術標準都對“鏈路層”的資料幀有大小限制：

最大傳輸單元MTU

正如在圖2 - 1看到的那樣，乙太網和8 0 2 . 3對資料幀的長度都有一個限制，其最大值分別是1 5 0 0和1 4 9 2位元組。鏈路層的這個特性稱作M T U，最大傳輸單元。不同型別的網路大多數都有一個上限。

如果I P層有一個數據報要傳，而且資料的長度比鏈路層的M T U還大，那麼I P層就需要進行分片（f r a g m e n t a t i o n），把資料報分成若干片，這樣每一片都小於M T U。我們將在11 . 5節討論IP分片的過程。

圖2 - 5列出了一些典型的M T U值，它們摘自RFC 1191[Mogul and Deering 1990]。點到點的鏈路層（如SL I P和P P P）的M T U並非指的是網路媒體的物理特性。相反，它是一個邏輯限制，目的是為互動使用提供足夠快的響應時間。在2 . 1 0節中，我們將看到這個限制值是如何計算出來的。在3 . 9節中，我們將用n e t s t a t命令打印出網路介面的M T U。

路徑MTU

當在同一個網路上的兩臺主機互相進行通訊時，該網路的M T U是非常重要的。但是如果

兩臺主機之間的通訊要通過多個網路，那麼每個網路的鏈路層就可能有不同的M T U。重要的

不是兩臺主機所在網路的M TU的值，重要的是兩臺通訊主機路徑中的最小M T U。它被稱作路

徑M T U。

兩臺主機之間的路徑M T U不一定是個常數。它取決於當時所選擇的路由。而選路不一定

是對稱的（從A到B的路由可能與從B到A的路由不同），因此路徑M T U在兩個方向上不一定是

一致的。

RFC 1191[Mogul and Deering1990]描述了路徑M T U的發現機制，即在任何時候確定路徑

M T U的方法。我們在介紹了I C M P和I P分片方法以後再來看它是如何操作的。在11 . 6節中，我

們將看到I C M P的不可到達錯誤就採用這種發現方法。在11 . 7節中，還會看到， t r a c e r o u t e程式

也是用這個方法來確定到達目的節點的路徑M T U。在11 . 8節和2 4 .2節，將介紹當產品支援路

徑M T U的發現方法時，U D P和T C P是如何進行操作的。

ＴＣＰ的超時與重傳

前面談到TCP如何保證傳輸可靠性是說到“當T C P發出一個段後，它啟動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發這個報文段”，下面我看一下TCP的超時與重傳。

TC P提供可靠的運輸層。它使用的方法之一就是確認從另一端收到的資料。但資料和確認都有可能會丟失。T C P通過在傳送時設定一個定時器來解決這種問題。如果當定時器溢位時還沒有收到確認，它就重傳該資料。對任何實現而言，關鍵之處就在於超時和重傳的策略，即怎樣決定超時間隔和如何確定重傳的頻率。

對每個連線，T C P管理4個不同的定時器。

1)重傳定時器使用於當希望收到另一端的確認。

2)堅持( persist)定時器使視窗大小資訊保持不斷流動，即使另一端關閉了其接收視窗。

3)保活( keep alive)定時器可檢測到一個空閒連線的另一端何時崩潰或重啟。

4)2MSL定時器測量一個連線處於T I M E _ WA I T狀態的時間。

TC P超時與重傳中最重要的部分就是對一個給定連線的往返時間（RT T）的測量。由於路由器和網路流量均會變化，因此我們認為這個時間可能經常會發生變化，T C P應該跟蹤這些變化並相應地改變其超時時間。

大多數源於伯克利的T C P實現在任何時候對每個連線僅測量一次RT T值。在傳送一個報文段時，如果給定連線的定時器已經被使用，則該報文段不被計時。

具體RTT值的估算比較麻煩，需要可以參考《TCP-IP詳解卷1第21章》

TCP經受延時的確認

互動資料總是以小於最大報文段長度的分組傳送。對於這些小的報文段，接收方使用經受時延的確認方法來判斷確認是否可被推遲傳送，以便與回送資料一起傳送。這樣通常會減少報文段的數目。

通常TC P在接收到資料時並不立即傳送A C K；相反，它推遲傳送，以便將A C K與需要沿該方向傳送的資料一起傳送（有時稱這種現象為資料捎帶A C K）。絕大多數實現採用的時延為200 ms，也就是說，T C P將以最大200 ms 的時延等待是否有資料一起傳送。

我們看看另一位朋友的blog對此的介紹：

摘要：當使用TCP傳輸小型資料包時，程式的設計是相當重要的。如果在設計方案中不對TCP資料包的延遲應答，Nagle演算法，Winsock緩衝作用引起重視，將會嚴重影響程式的效能。這篇文章討論了這些問題，列舉了兩個案例，給出了一些傳輸小資料包的優化設計方案。

背景：當Microsoft TCP棧接收到一個數據包時，會啟動一個200毫秒的計時器。當ACK確認資料包發出之後，計時器會復位，接收到下一個資料包時，會再次啟動200毫秒的計時器。為了提升應用程式在內部網和Internet上的傳輸效能，Microsoft TCP棧使用了下面的策略來決定在接收到資料包後什麼時候傳送ACK確認資料包：

1、如果在200毫秒的計時器超時之前，接收到下一個資料包，則立即傳送ACK確認資料包。

2、如果當前恰好有資料包需要發給ACK確認資訊的接收端，則把ACK確認資訊附帶在資料包上立即傳送。3、當計時器超時，ACK確認資訊立即傳送。

為了避免小資料包擁塞網路，MicrosoftTCP棧 預設啟用了Nagle演算法，這個演算法能夠將應用程式多次呼叫Send傳送的資料拼接起來，當收到前一個數據包的ACK確認資訊時，一起傳送出去。下面是Nagle演算法的例外情況：

1、如果Microsoft TCP棧拼接起來的資料包超過了MTU值，這個資料會立即傳送，而不等待前一個數據包的ACK確認資訊。在乙太網中，TCP的MTU(Maximum Transmission Unit)值是1460位元組。

2、如果設定了TCP_NODELAY選項，就會禁用Nagle演算法，應用程式呼叫Send傳送的資料包會立即被投遞到網路，而沒有延遲。

為了在應用層優化效能，Winsock把應用程式呼叫Send傳送的資料從應用程式的緩衝區複製到Winsock核心緩衝區。Microsoft TCP棧利用類似Nagle演算法的方法，決定什麼時候才實際地把資料投遞到網路。核心緩衝區的預設大小是8K，使用SO_SNDBUF選項，可以改變Winsock核心緩衝區的大小。如果有必要的話，Winsock能緩衝大於SO_SNDBUF緩衝區大小的資料。在絕大多數情況下，應用程式完成Send呼叫僅僅表明資料被複制到了Winsock核心緩衝區，並不能說明資料就實際地被投遞到了網路上。

唯一的一種例外的情況是：

通過設定SO_SNDBUT為0禁用了Winsock核心緩衝區。

Winsock使用下面的規則來嚮應用程式表明一個Send呼叫的完成：

1、如果socket仍然在SO_SNDBUF限額內，Winsock複製應用程式要傳送的資料到核心緩衝區，完成Send呼叫。

2、如果Socket超過了SO_SNDBUF限額並且先前只有一個被緩衝的傳送資料在核心緩衝區，Winsock複製要傳送的資料到核心緩衝區，完成Send呼叫。

3、如果Socket超過了SO_SNDBUF限額並且核心緩衝區有不只一個被緩衝的傳送資料，Winsock複製要傳送的資料到核心緩衝區，然後投遞資料到網路，直到Socket降到SO_SNDBUF限額內或者只剩餘一個要傳送的資料，才完成Send呼叫。

案例1

一個Winsock TCP客戶端需要傳送10000個記錄到Winsock TCP服務端，儲存到資料庫。記錄大小從20位元組到100位元組不等。對於簡單的應用程式邏輯，可能的設計方案如下：

1、客戶端以阻塞方式傳送，服務端以阻塞方式接收。

2、客戶端設定SO_SNDBUF為0，禁用Nagle演算法，讓每個資料包單獨的傳送。

3、服務端在一個迴圈中呼叫Recv接收資料包。給Recv傳遞200位元組的緩衝區以便讓每個記錄在一次Recv呼叫中被獲取到。

效能：

在測試中發現，客戶端每秒只能傳送5條資料到服務段，總共10000條記錄，976K位元組左右，用了半個多小時才全部傳到伺服器。

分析：

因為客戶端沒有設定TCP_NODELAY選項，Nagle演算法強制TCP棧在傳送資料包之前等待前一個數據包的ACK確認資訊。然而，客戶端設定SO_SNDBUF為0，禁用了核心緩衝區。因此，10000個Send呼叫只能一個數據包、一個數據包的傳送和確認，由於下列原因，每個ACK確認資訊被延遲200毫秒：

1、當伺服器獲取到一個數據包，啟動一個200毫秒的計時器。

2、服務端不需要向客戶端傳送任何資料，所以，ACK確認資訊不能被髮回的資料包順路攜帶。

3、客戶端在沒有收到前一個數據包的確認資訊前，不能傳送資料包。

4、服務端的計時器超時後，ACK確認資訊被髮送到客戶端。

如何提高效能：

在這個設計中存在兩個問題：

（1）     存在延時問題。客戶端需要能夠在200毫秒內傳送兩個資料包到服務端。因為客戶端預設情況下使用Nagle演算法，應該使用預設的核心緩衝區，不應該設定SO_SNDBUF為0。一旦TCP棧拼接起來的資料包超過MTU值，這個資料包會立即被髮送，不用等待前一個ACK確認資訊。

（2）     這個設計方案對每一個如此小的的資料包都呼叫一次Send。傳送這麼小的資料包是不很有效率的。在這種情況下，應該把每個記錄補充到100位元組並且每次呼叫Send傳送80個記錄。為了讓服務端知道一次總共傳送了多少個記錄，客戶端可以在記錄前面帶一個頭資訊。

案例二：

一個Winsock TCP客戶端程式開啟兩個連線和一個提供股票報價服務的Winsock TCP服務端通訊。第一個連線作為命令通道用來傳輸股票編號到服務端。第二個連線作為資料通道用來接收股票報價。兩個連線被建立後，客戶端通過命令通道傳送股票編號到服務端， 然後在資料通道上等待返回的股票報價資訊。客戶端在接收到第一個股票報價資訊後傳送下一個股票編號請求到服務端。客戶端和服務端都沒有設定SO_SNDBUF和TCP_NODELAY選項。

效能：

測試中發現，客戶端每秒只能獲取到5條報價資訊。

分析：

這個設計方案一次只允許獲取一條股票資訊。第一個股票編號資訊通過命令通道傳送到服務端，立即接收到服務端通過資料通道返回的股票報價資訊。然後，客戶端立即傳送第二條請求資訊，send呼叫立即返回，傳送的資料被複制到核心緩衝區。然而，TCP棧不能立即投遞這個資料包到網路，因為沒有收到前一個數據包的ACK確認資訊。200毫秒後，服務端的計時器超時，第一個請求資料包的ACK確認資訊被髮送回客戶端，客戶端的第二個請求包才被投遞到網路。第二個請求的報價資訊立即從資料通道返回到客戶端，因為此時，客戶端的計時器已經超時，第一個報價資訊的ACK確認資訊已經被髮送到服務端。這個過程迴圈發生。

如何提高效能：

在這裡，兩個連線的設計是沒有必要的。如果使用一個連線來請求和接收報價資訊，股票請求的ACK確認資訊會被返回的報價資訊立即順路攜帶回來。要進一步的提高效能，客戶端應該一次呼叫Send傳送多個股票請求，服務端一次返回多個報價資訊。如果由於某些特殊原因必須要使用兩個單向的連線，客戶端和服務端都應該設定TCP_NODELAY選項，讓小資料包立即傳送而不用等待前一個數據包的ACK確認資訊。

提高效能的建議：

上面兩個案例說明了一些最壞的情況。當設計一個方案解決大量的小資料包傳送和接收時，應該遵循以下的建議：

1、如果資料片段不需要緊急傳輸的話，應用程式應該將他們拼接成更大的資料塊，再呼叫Send。因為傳送緩衝區很可能被複制到核心緩衝區，所以緩衝區不應該太大，通常比8K小一點點是很有效率的。只要Winsock核心緩衝區得到一個大於MTU值的資料塊，就會發送若干個資料包，剩下最後一個數據包。傳送方除了最後一個數據包，都不會被200毫秒的計時器觸發。

2、如果可能的話，避免單向的Socket資料流接連。

3、不要設定SO_SNDBUF為0，除非想 確保資料包在呼叫Send完成之後立即被投遞到網路。事實上，8K的緩衝區適合大多數情況，不需要重新改變，除非新設定的緩衝區經過測試的確比預設大小更高效。

4、如果資料傳輸不用保證可靠性，使用UDP。

結論：

1. TCP提供了面向“連續位元組流”的可靠的傳輸服務，TCP並不理解流所攜帶的資料內容，這個內容需要應用層自己解析。

2. “位元組流”是連續的、非結構化的，而我們的應用需要的是有序的、結構化的資料資訊，因此我們需要定義自己的“規則”去解讀這個“連續的位元組流“，那解決途徑就是定義自己的封包型別，然後用這個型別去對映“連續位元組流”。

如何定義封包，我們回顧一下前面這個資料進入協議棧的封裝過程圖：

封包其實就是將上圖中進入協議棧的使用者資料[即使用者要傳送的資料]定義為一種方便識別和交流的型別，這有點類似信封的概念,信封就是一種人們之間通訊的格式,信封格式如下：

信封格式：

收信人郵編

收信人地址

收信人姓名

信件內容

那麼在程式裡面我們也需要定義這種格式：在C++裡面只有結構和類這種兩種型別適合表達這個概念了。