TCP協議要點和難點全解

說明：

• 1).本文以TCP的發展歷程解析容易引起混淆，誤會的方方面面
• 2).本文不會貼大量的原始碼，大多數是以文字形式描述，我相信文字看起來是要比程式碼更輕鬆的
• 3).針對物件：對TCP已經有了全面瞭解的人。因為本文不會解析TCP頭裡面的每一個欄位或者3次握手的細節，也不會解釋慢啟動和快速重傳的定義
• 4).除了《TCP/IP詳解》(卷一，卷二)以及《Unix網路程式設計》以及Linux原始碼之外，學習網路更好的資源是RFC
• 5).本文給出一個提綱，如果想了解細節，請直接查閱RFC
• 6).翻來覆去，終於找到了這篇備忘，本文基於這篇備忘文件修改。

1.網路協議設計

ISO提出了OSI分層網路模型，這種分層模型是理論上的，TCP/IP最終實現了一個分層的協議模型，每一個層次對應一組網路協議完成一組特定的功能，該組網路協議被其下的層次複用和解複用。這就是分層模型的本質，最終所有的邏輯被編碼到線纜或者電磁波。

分層模型是很好理解的，然而對於每一層的協議設計卻不是那麼容易。TCP/IP的漂亮之處在於：協議越往上層越複雜。我們把網路定義為互相連線在一起的裝置，網路的本質作用還是“端到端”的通訊，然而希望互相通訊的裝置並不一定要“直接”連線在一起，因此必然需要一些中間的裝置負責轉發資料，因此就把連線這些中間裝置的線纜上跑的協議定義為鏈路層協議，實際上所謂鏈路其實就是始發與一個裝置，通過一根線，終止於另一個裝置。我們把一條鏈路稱為“一跳”。因此一個端到端的網路包含了“很多跳”。

2.TCP和IP協議

終止於IP協議，我們已經可以完成一個端到端的通訊，為何還需要TCP協議？這是一個問題，理解了這個問題，我們就能理解TCP協議為何成了現在這個樣子，為何如此“複雜”，為何又如此簡單。

正如其名字所展示的那樣，TCP的作用是傳輸控制，也就是控制端到端的傳輸，那為何這種控制不在IP協議中實現的。答案很簡單，那就是這會增加IP協議的複雜性，而IP協議需要的就是簡單。這是什麼原因造成的呢？

首先我們認識一下為何IP協議是沙漏的細腰部分。它的下層是繁多的鏈路層協議，這些鏈路提供了相互截然不同且相差很遠的語義，為了互聯這些異構的網路，我們需要一個網路層協議起碼要提供一些適配的功能，另外它必然不能提供太多的“保證性服務”，因為上層的保證性依賴下層的約束性更強的保證性，你永遠無法在一個100M吞吐量的鏈路之上實現的IP協議保證1000M的吞吐量…

IP協議設計為分組轉發協議，每一跳都要經過一箇中間節點，路由的設計是TCP/IP網路的另一大創舉，這樣，IP協議就無需方向性，路由資訊和協議本身不再強關聯，它們僅僅通過IP地址來關聯，因此，IP協議更加簡單。路由器作為中間節點也不能太複雜，這涉及到成本問題，因此路由器只負責選路以及轉發資料包。

因此傳輸控制協議必然需要在端點實現。在我們詳談TCP協議之前，首先要看一下它不能做什麼，由於IP協議不提供保證，TCP也不能提供依賴於IP下層鏈路的這種保證，比如頻寬，比如時延，這些都是鏈路層決定的，既然IP協議無法修補，TCP也不能，然而它卻能修正始於IP層的一些“不可保證性質”，這些性質包括IP層的不可靠，IP層的不按順序，IP層的無方向/無連線。

將該小節總結一下，TCP/IP模型從下往上，功能增加，需要實現的裝置減少，然而裝置的複雜性卻在增加，這樣保證了成本的最小化，至於效能或者因素，靠軟體來調節吧，TCP協議就是這樣的軟體，實際上最開始的時候，TCP並不考慮效能，效率，公平性，正是考慮了這些，TCP協議才複雜了起來。

3.TCP協議

這是一個純軟體協議，為何將其設計上兩個端點，參見上一小節，本節詳述TCP協議，中間也穿插一些簡短的論述。

3.1.TCP協議

確切的說，TCP協議有兩重身份，作為網路協議，它彌補了IP協議盡力而為服務的不足，實現了有連線，可靠傳輸，報文按序到達。作為一個主機軟體，它和UDP以及左右的傳輸層協議隔離了主機服務和網路，它們可以被看做是一個多路複用/解複用器，將諸多的主機程式資料複用/解複用到IP層。
可以看出，不管從哪個角度，TCP都作為一個介面存在，作為網路協議，它和對端的TCP介面，實現TCP的控制邏輯，作為多路複用/解複用器，它和下層IP協議介面，實現協議棧的功能，而這正是分層網路協議模型的基本定義(兩類介面，一類和下層介面，另一類和對等層介面)。

我們習慣於將TCP作為協議棧的最頂端，而不把應用層協議當成協議棧的一部分，這部分是因為應用層被TCP/UDP解複用了之後，呈現出了一種太複雜的局面，應用層協議用一種不同截然不同的方式被解釋，應用層協議習慣於用類似ASN.1標準來封裝，這正體現了TCP協議作為多路複用/解複用器的重要性，由於直接和應用介面，它可以很容易直接被應用控制，實現不同的傳輸控制策略，這也是TCP被設計到離應用不太遠的地方的原因之一。

總之，TCP要點有四，一曰有連線，二曰可靠傳輸，三曰資料按照到達，四曰端到端流量控制。注意，TCP被設計時只保證這四點，此時它雖然也有些問題，然而很簡單，然而更大的問題很快呈現出來，使之不得不考慮和IP網路相關的東西，比如公平性，效率，因此增加了擁塞控制，這樣TCP就成了現在這個樣子。

3.2.有連線，可靠傳輸，資料按序到達的TCP

IP協議是沒有方向的，資料包傳輸能到達對端全靠路由，因此它是一跳一跳地到達對端的，只要有一跳沒有到達對端的路由，那麼資料傳輸將失敗，其實路由也是網際網路的核心之一，實際上IP層提供的核心基本功能有兩點，第一點是地址管理，第二點就是路由選路。TCP利用了IP路由這個簡單的功能，因此TCP不必考慮選路，這又一個它被設計成端到端協議的原因。

既然IP已經能盡力讓單獨的資料包到達對端，那麼TCP就可以在這種盡力而為的網路上實現其它的更加嚴格的控制功能。TCP給無連線的IP網路通訊增加了連線性，確認了已經傳送出去的資料的狀態，並且保證了資料的順序。

3.2.1.有連線

這是TCP的基本，因為後續的傳輸的可靠性以及資料順序性都依賴於一條連線，這是最簡單的實現方式，因此TCP被設計成一種基於流的協議，既然TCP需要事先建立連線，之後傳輸多少資料就無所謂了，只要是同一連線的資料能識別出來即可。
疑難雜症1：3次握手和4次揮手
TCP使用3次握手建立一條連線，該握手初始化了傳輸可靠性以及資料順序性必要的資訊，這些資訊包括兩個方向的初始序列號，確認號由初始序列號生成，使用3次握手是因為3次握手已經準備好了傳輸可靠性以及資料順序性所必要的資訊，該握手的第3次實際上並不是需要單獨傳輸的，完全可以和資料一起傳輸。
TCP使用4次揮手拆除一條連線，為何需要4次呢？因為TCP是一個全雙工協議，必須單獨拆除每一條通道。注意，4次揮手和3次握手的意義是不同的，很多人都會問為何建立連線是3次握手，而拆除連線是4次揮手。

3次握手的目的很簡單，就是分配資源，初始化序列號，這時還不涉及資料傳輸，3次就足夠做到這個了，而4次揮手的目的是終止資料傳輸，並回收資源，此時兩個端點兩個方向的序列號已經沒有了任何關係，必須等待兩方向都沒有資料傳輸時才能拆除虛鏈路，不像初始化時那麼簡單，發現SYN標誌就初始化一個序列號並確認SYN的序列號。因此必須單獨分別在一個方向上終止該方向的資料傳輸。
疑難雜症2：TIME_WAIT狀態

為何要有這個狀態，原因很簡單，那就是每次建立連線的時候序列號都是隨機產生的，並且這個序列號是32位的，會迴繞。現在我來解釋這和TIME_WAIT有什麼關係。

任何的TCP分段都要在盡力而為的IP網路上傳輸，中間的路由器可能會隨意的快取任何的IP資料包，它並不管這個IP資料包上被承載的是什麼資料，然而根據經驗和網際網路的大小，一個IP資料包最多存活MSL(這是根據地球表面積，電磁波在各種介質中的傳輸速率以及IP協議的TTL等綜合推算出來的，如果在火星上，這個MSL會大得多…)。

現在我們考慮終止連線時的被動方傳送了一個FIN，然後主動方回覆了一個ACK，然而這個ACK可能會丟失，這會造成被動方重發FIN，這個FIN可能會在網際網路上存活MSL。

如果沒有TIME_WAIT的話，假設連線1已經斷開，然而其被動方最後重發的那個FIN(或者FIN之前傳送的任何TCP分段)還在網路上，然而連線2重用了連線1的所有的5元素(源IP，目的IP，TCP，源埠，目的埠)，剛剛將建立好連線，連線1遲到的FIN到達了，這個FIN將以比較低但是確實可能的概率終止掉連線2.

為何說是概率比較低呢？這涉及到一個匹配問題，遲到的FIN分段的序列號必須落在連線2的一方的期望序列號範圍之內。雖然這種巧合很少發生，但確實會發生，畢竟初始序列號是隨機產生了。因此終止連線的主動方必須在接受了被動方且回覆了ACK之後等待2*MSL時間才能進入CLOSE狀態，之所以乘以2是因為這是保守的演算法，最壞情況下，針對被動方的ACK在以最長路線(經歷一個MSL)經過網際網路馬上到達被動方時丟失。

為了應對這個問題，RFC793對初始序列號的生成有個建議，那就是設定一個基準，在這個基準之上搞隨機，這個基準就是時間，我們知道時間是單調遞增的。然而這仍然有問題，那就是迴繞問題，如果發生迴繞，那麼新的序列號將會落到一個很低的值。因此最好的辦法就是避開“重疊”，其含義就是基準之上的隨機要設定一個範圍。

要知道，很多人很不喜歡看到伺服器上出現大量的TIME_WAIT狀態的連線，因此他們將TIME_WAIT的值設定的很低，這雖然在大多數情況下可行，然而確實也是一種冒險行為。最好的方式就是，不要重用一個連線。

疑難雜症3：重用一個連線和重用一個套接字
這是根本不同的，單獨重用一個套接字一般不會有任何問題，因為TCP是基於連線的。比如在伺服器端出現了一個TIME_WAIT連線，那麼該連線標識了一個五元素，只要客戶端不使用相同的源埠，連線伺服器是沒有問題的，因為遲到的FIN永遠不會到達這個連線。記住，一個五元素標識了一個連線，而不是一個套接字(當然，對於BSD套接字而言，服務端的accept套接字確實標識了一個連線)。

3.2.2.傳輸可靠性

基本上傳輸可靠性是靠確認號實現的，也就是說，每傳送一個分段，接下來接收端必然要傳送一個確認，傳送端收到確認後才可以傳送下一個位元組。這個原則最簡單不過了，教科書上的“停止-等待”協議就是這個原則的位元組版本，只是TCP使用了滑動視窗機制使得每次不一定傳送一個位元組，但是這是後話，本節僅僅談一下確認的超時機制。

怎麼知道資料到達對端呢？那就是對端傳送一個確認，但是如果一直收不到對端的確認，傳送端等多久呢？如果一直等下去，那麼將無法發現資料的丟失，協議將不可用，如果等待時間過短，可能確認還在路上，因此等待時間是個問題，另外如何去管理這個超時時間也是一個問題。

疑難雜症4：超時時間的計算
絕對不能隨意去揣測超時的時間，而應該給出一個精確的演算法去計算。毫無疑問，一個TCP分段的回覆到達的時間就是一個資料包往返的時間，因此標準定義了一個新的名詞RTT，代表一個TCP分段的往返時間。然而我們知道，IP網路是盡力而為的，並且路由是動態的，且路由器會毫無先兆的快取或者丟棄任何的資料包，因此這個RTT是需要動態測量的，也就是說起碼每隔一段時間就要測量一次，如果每次都一樣，萬事大吉，然而世界並非如你所願，因此我們需要找到的恰恰的一個“平均值”，而不是一個準確值。

這個平均值如果僅僅直接通過計算多次測量值取算術平均，那是不恰當的，因為對於資料傳輸延時，我們必須考慮的路徑延遲的瞬間抖動，否則如果兩次測量值分別為2和98，那麼超時值將是50，這個值對於2而言，太大了，結果造成了資料的延遲過大(本該重傳的等待了好久才重傳)，然而對於98而言，太小了，結果造成了過度重傳(路途遙遠，本該很慢，結果大量重傳已經正確確認但是遲到的TCP分段)。

因此，除了考慮每兩次測量值的偏差之外，其變化率也應該考慮在內，如果變化率過大，則通過以變化率為自變數的函式為主計算RTT(如果陡然增大，則取值為比較大的正數，如果陡然減小，則取值為比較小的負數，然後和平均值加權求和)，反之如果變化率很小，則取測量平均值。這是不言而喻的，這個演算法至今仍然工作的很好。

疑難雜症5：超時計時器的管理-每連線單一計時器
很顯然，對每一個TCP分段都生成一個計時器是最直接的方式，每個計時器在RTT時間後到期，如果沒有收到確認，則重傳。然而這只是理論上的合理，對於大多數作業系統而言，這將帶來巨大的記憶體開銷和排程開銷，因此採取每一個TCP連線單一計時器的設計則成了一個預設的選擇。可是單一的計時器怎麼管理如此多的發出去的TCP分段呢？又該如何來設計單一的計時器呢。

設計單一計時器有兩個原則：1.每一個報文在長期收不到確認都必須可以超時；2.這個長期收不到中長期不能和測量的RTT相隔太遠。因此RFC2988定義一套很簡單的原則：

a.傳送TCP分段時，如果還沒有重傳定時器開啟，那麼開啟它。
b.傳送TCP分段時，如果已經有重傳定時器開啟，不再開啟它。
c.收到一個非冗餘ACK時，如果有資料在傳輸中，重新開啟重傳定時器。
d.收到一個非冗餘ACK時，如果沒有資料在傳輸中，則關閉重傳定時器。

我們看看這4條規則是如何做到以上兩點的，根據a和c(在c中，注意到ACK是非冗餘的)，任何TCP分段只要不被確認，超時定時器總會超時的。然而為何需要c呢？只有規則a存在的話，也可以做到原則1。實際上確實是這樣的，但是為了不會出現過早重傳，才新增了規則c，如果沒有規則c，那麼萬一在重傳定時器到期前，傳送了一些資料，這樣在定時器到期後，除了很早傳送的資料能收到ACK外，其它稍晚些傳送的資料的ACK都將不會到來，因此這些資料都將被重傳。有了規則c之後，只要有分段ACK到來，則重置重傳定時器，這很合理，因此大多數正常情況下，從資料的發出到ACK的到來這段時間以及計算得到的RTT以及重傳定時器超時的時間這三者相差並不大，一個ACK到來後重置定時器可以保護後發的資料不被過早重傳。

這裡面還有一些細節需要說明。一個ACK到來了，說明後續的ACK很可能會依次到來，也就是說丟失的可能性並不大，另外，即使真的有後發的TCP分段丟失現象發生，也會在最多2倍定時器超時時間的範圍內被重傳(假設該報文是第一個報文發出啟動定時器之後馬上發出的，丟失了，第一個報文的ACK到來後又重啟了定時器，又經過了一個超時時間才會被重傳)。雖然這裡還沒有涉及擁塞控制，但是可見網路擁塞會引起丟包，丟包會引起重傳，過度重傳反過來加重網路擁塞，設定規則c的結果可以緩解過多的重傳，畢竟將啟動定時器之後傳送的資料的重傳超時時間拉長了最多一倍左右。最多一倍左右的超時偏差做到了原則2，即“這個長期收不到中長期不能和測量的RTT相隔太遠”。

還有一點，如果是一個傳送序列的最後一個分段丟失了，後面就不會收到冗餘ACK，這樣就只能等到超時了，並且超時時間幾乎是肯定會比定時器超時時間更長。如果這個分段是在傳送序列的靠後的時間傳送的且和前面的傳送時間相隔時間較遠，則其超時時間不會很大，反之就會比較大。

疑難雜症6：何時測量RTT
目前很多TCP實現了時間戳，這樣就方便多了，傳送端再也不需要儲存傳送分段的時間了，只需要將其放入協議頭的時間戳欄位，然後接收端將其回顯在ACK即可，然後傳送端收到ACK後，取出時間戳，和當前時間做算術差，即可完成一次RTT的測量。

3.2.3.資料順序性

基本上傳輸可靠性是靠序列號實現的。

疑難雜症7：確認號和超時重傳
確認號是一個很詭異的東西，因為TCP的傳送端對於傳送出去的一個資料序列，它只要收到一個確認號就認為確認號前面的資料都被收到了，即使前面的某個確認號丟失了，也就是說，傳送端只認最後一個確認號。這是合理的，因為確認號是接收端發出的，接收端只確認按序到達的最後一個TCP分段。

另外，傳送端重發了一個TCP報文並且接收到該TCP分段的確認號，並不能說明這個重發的報文被接收了，也可能是資料早就被接收了，只是由於其ACK丟失或者其ACK延遲到達導致了超時。值得說明的是，接收端會丟棄任何重複的資料，即使丟棄了重複的資料，其ACK還是會照發不誤的。

標準的早期TCP實現為，只要一個TCP分段丟失，即使後面的TCP分段都被完整收到，傳送端還是會重傳從丟失分段開始的所有報文，這就會導致一個問題，那就是重傳風暴，一個分段丟失，引起大量的重傳。這種風暴實則不必要的，因為大多數的TCP實現中，接收端已經快取了亂序的分段，這些被重傳的丟失分段之後的分段到達接收端之後，很大的可能性是被丟棄。關於這一點在擁塞控制被引入之後還會提及(問題先述為快：本來報文丟失導致超時就說明網路很可能已然擁塞，重傳風暴只能加重其擁塞程度)。

疑難雜症8：亂序資料快取以及選擇確認
TCP是保證資料順序的，但是並不意味著它總是會丟棄亂序的TCP分段，具體會不會丟棄是和具體實現相關的，RFC建議如果記憶體允許，還是要快取這些亂序到來的分段，然後實現一種機制等到可以拼接成一個按序序列的時候將快取的分段拼接，這就類似於IP協議中的分片一樣，但是由於IP資料包是不確認的，因此IP協議的實現必須快取收到的任何分片而不能將其丟棄，因為丟棄了一個IP分片，它就再也不會到來了。

現在，TCP實現了一種稱為選擇確認的方式，接收端會顯式告訴傳送端需要重傳哪些分段而不需要重傳哪些分段。這無疑避免了重傳風暴。

疑難雜症9：TCP序列號的迴繞的問題
TCP的序列號迴繞會引起很多的問題，比如序列號為s的分段發出之後，m秒後，序列號比s小的序列號為j的分段發出，只不過此時的j比上一個s多了一圈，這就是迴繞問題，那麼如果這後一個分段到達接收端，這就會引發徹底亂序-本來j該在s後面，結果反而到達前面了，這種亂序是TCP協議檢查不出來的。我們仔細想一下，這種情況確實會發生，資料分段並不是一個位元組一個位元組傳送出去的，如果存在一個速率為1Gbps的網路，TCP傳送端1秒會傳送125MB的資料，32位的序列號空間能傳輸2的32次方個位元組，也就是說32秒左右就會發生迴繞，我們知道這個值遠小於MSL值，因此會發生的。

有個細節可能會引起誤會，那就是TCP的視窗大小空間是序列號空間的一半，這樣恰好在滿載情況下，資料能填滿傳送視窗和接收視窗，序列號空間正好夠用。然而事實上，TCP的初始序列號並不是從0開始的，而是隨機產生的(當然要輔助一些更精妙的演算法)，因此如果初始序列號比較接近2的32次方，那麼很快就會迴繞。

當然，如今可以用時間戳選項來輔助作為序列號的一個識別的部分，接收端遇到迴繞的情況，需要比較時間戳，我們知道，時間戳是單調遞增的，雖然也會迴繞，然而回繞時間卻要長很多。這只是一種策略，在此不詳談。還有一個很現實的問題，理論上序列號會迴繞，但是實際上，有多少TCP的端點主機直接架設在1G的網路線纜兩端並且接收方和傳送方的視窗還能恰好被同時填滿。另外，就算髮生了迴繞，也不是一件特別的事情，迴繞在計算機裡面太常見了，只需要能識別出來即可解決，對於TCP的序列號而言，在高速網路(點對點網路或者乙太網)的兩端，資料發生亂序的可能性很小，因此當收到一個序列號突然變為0或者終止序列號小於起始序列號的情況後，很容易辨別出來，只需要和前一個確認的分段比較即可，如果在一個經過路由器的網路兩端，會引發IP資料包的順序重排，對於TCP而言，雖然還會發生迴繞，也會慢得多，且考慮到擁塞視窗(目前還沒有引入)一般不會太大，視窗也很難被填滿到65536。

3.2.4.端到端的流量控制

端到端的流量控制使用滑動視窗來實現。滑動視窗的原理非常簡單，基本就是一個生產者/消費者模型

疑難雜症10：流量控制的真實意義
很多人以為流量控制會很有效的協調兩端的流量匹配，確實是這樣，但是如果你考慮到網路的利用率問題，TCP的流量控制機制就不那麼完美了，造成這種局面的原因在於，滑動視窗只是限制了最大傳送的資料，卻沒有限制最小傳送的資料，結果導致一些很小的資料被封裝成TCP分段，報文協議頭所佔的比例過於大，造成網路利用率下降，這就引出了接下來的內容，那就是端到端意義的TCP協議效率。

~~~~~~~~~~~~~~~~~~~~
承上啟下
終於到了闡述問題的時候了，以上的TCP協議實現的非常簡單，這也是TCP的標準實現，然而很快我們就會發現各種各樣的問題。這些問題導致了標準化協會對TCP協議進行了大量的修補，這些修補雜糅在一起讓人們有些雲裡霧裡，不知所措。本文件就旨在分離這些雜亂的情況，實際上，根據RFC，這些雜亂的情況都是可以找到其單獨的發展軌跡的。
~~~~~~~~~~~~~~~~~~~~

4.端到端意義上的TCP協議效率

4.1.三個問題以及解決

問題1描述：接收端處理慢，導致接收視窗被填滿
這明顯是速率不匹配引發的問題，然而即使速率不匹配，只要滑動視窗能協調好它們的速率就好，要快都快，要慢都慢，事實上滑動視窗在這一點上做的很好。但是如果我們不得不從效率上來考慮問題的話，事實就不那麼樂觀了。考慮此時接收視窗已然被填滿，慢速的應用程式慢騰騰的讀取了一個位元組，空出一個位置，然後通告給TCP的傳送端，傳送端得知空出一個位置，馬上發出一個位元組，又將接收端填滿，然後接收應用程式又一次慢騰騰…這就是糊塗視窗綜合症，一個大多數人都很熟悉的詞。這個問題極大的浪費了網路頻寬，降低了網路利用率。好比從大同拉100噸煤到北京需要一輛車，拉1Kg煤到北京也需要一輛車(超級誇張的一個例子，請不要相信)，但是一輛車開到北京的開銷是一定的…

問題1解決：視窗通告
對於問題1，很顯然問題出在接收端，我們沒有辦法限制傳送端不傳送小分段，但是卻可以限制接收端通告小視窗，這是合理的，這並不影響應用程式，此時經典的延遲/吞吐量反比律將不再適用，因為接收視窗是滿的，其空出一半空間表示還有一半空間有資料沒有被應用讀取，和其空出一個位元組的空間的效果是一樣的，因此可以限制接收端當視窗為0時，直接通告給傳送端以阻止其繼續傳送資料，只有當其接收視窗再次達到MSS的一半大小的時候才通告一個不為0的視窗，此前對於所有的傳送端的視窗probe分段(用於探測接收端視窗大小的probe分段，由TCP標準規定)，全部通告視窗為0，這樣傳送端在收到視窗不為0的通告，那麼肯定是一個比較大的視窗，因此傳送端可以一次性發出一個很大的TCP分段，包含大量資料，也即拉了好幾十噸的煤到北京，而不是隻拉了幾公斤。

即，限制視窗通告時機，解決糊塗視窗綜合症
問題2描述：傳送端持續傳送小包，導致視窗閒置
這明顯是傳送端引起的問題，此時接收端的視窗開得很大，然而傳送端卻不積累資料，還是一味的傳送小塊資料分段。只要傳送了任和的分段，接收端都要無條件接收並且確認，這完全符合TCP規範，因此必然要限制傳送端不傳送這樣的小分段。

問題2解決：Nagle演算法
Nagel演算法很簡單，標準的Nagle演算法為：

IF 資料的大小和視窗的大小都超過了MSS
Then 傳送資料分段
ELSE
IF 還有發出的TCP分段的確認沒有到來
Then 積累資料到傳送佇列的末尾的TCP分段
ELSE
傳送資料分段
EndIF
EndIF

可是後來，這個演算法變了，變得更加靈活了，其中的：
 IF 還有發出的TCP分段的確認沒有到來
變成了
IF 還有發出的不足MSS大小的TCP分段的確認沒有到來

這樣如果發出了一個MSS大小的分段還沒有被確認，後面也是可以隨時傳送一個小分段的，這個改進降低了演算法對延遲時間的影響。這個演算法體現了一種自適應的策略，越是確認的快，越是傳送的快，雖然Nagle演算法看起來在積累資料增加吞吐量的同時也加大的時延，可事實上，如果對於類似互動式的應用，時延並不會增加，因為這類應用回覆資料也是很快的，比如Telnet之類的服務必然需要回顯字元，因此能和對端進行自適應協調。

注意，Nagle演算法是預設開啟的，但是卻可以關閉。如果在開啟的情況下，那麼它就嚴格按照上述的演算法來執行。

問題3.確認號(ACK)本身就是不含資料的分段，因此大量的確認號消耗了大量的頻寬
這是TCP為了確保可靠性傳輸的規範，然而大多數情況下，ACK還是可以和資料一起捎帶傳輸的。如果沒有捎帶傳輸，那麼就只能單獨回來一個ACK，如果這樣的分段太多，網路的利用率就會下降。從大同用火車拉到北京100噸煤，為了確認煤已收到，北京需要派一輛同樣的火車空載開到大同去覆命，因為沒有別的交通工具，只有火車。如果這位覆命者剛開著一列火車走，又從大同來了一車煤，這拉煤的哥們兒又要開一列空車去覆命了。

問題3的解決：
RFC建議了一種延遲的ACK，也就是說，ACK在收到資料後並不馬上回復，而是延遲一段可以接受的時間，延遲一段時間的目的是看能不能和接收方要發給傳送方的資料一起回去，因為TCP協議頭中總是包含確認號的，如果能的話，就將ACK一起捎帶回去，這樣網路利用率就提高了。往大同覆命的確認者不必開一輛空載火車回大同了，此時北京正好有一批貨物要送往大同，這位覆命者搭著這批貨的火車返回大同。

如果等了一段可以接受的時間，還是沒有資料要發往傳送端，此時就需要單獨傳送一個ACK了，然而即使如此，這個延遲的ACK雖然沒有等到可以被捎帶的資料分段，也可能等到了後續到來的TCP分段，這樣它們就可以取最大者一起返回了，要知道，TCP的確認號是收到的按序報文的最後一個位元組的後一個位元組。最後，RFC建議，延遲的ACK最多等待兩個分段的積累確認。

4.2.分析三個問題之間的關聯

三個問題導致的結果是相同的，但是要知道它們的原因本質上是不同的，問題1幾乎總是出現在接收端視窗滿的情況下，而問題2幾乎總是發生在視窗閒置的情況下，問題3看起來是最無聊的，然而由於TCP的要求，必須要有確認號，而且一個確認號就需要一個TCP分段，這個分段不含資料，無疑是很小的。

三個問題都導致了網路利用率的降低。雖然兩個問題導致了同樣的結果，但是必須認識到它們是不同的問題，很自然的將這些問題的解決方案彙總在一起，形成一個全域性的解決方案，這就是如今的作業系統中的解決方案。

4.3.問題的雜糅情況

疑難雜症11：糊塗視窗解決方案和Nagle演算法
糊塗視窗綜合症患者希望傳送端積累TCP分段，而Nagle演算法確實保證了一定的TCP分段在傳送端的積累，另外在延遲ACK的延遲的那一會時間，傳送端會利用這段時間積累資料。然而這卻是三個不同的問題。Nagle演算法可以緩解糊塗視窗綜合症，卻不是治本的良藥。

疑難雜症12：Nagle演算法和延遲ACK
延遲ACK會延長ACK到達傳送端的時間，由於標準Nagle演算法只允許一個未被確認的TCP分段，那無疑在接收端，這個延遲的ACK是毫無希望等待後續資料到來最終進行積累確認的，如果沒有資料可以捎帶這個ACK，那麼這個ACK只有在延遲確認定時器超時的時候才會發出，這樣在等待這個ACK的過程中，傳送端又積累了一些資料，因此延遲ACK實際上是在增加延遲的代價下加強了Nagle演算法。在延遲ACK加Nagle演算法的情況下，接收端只有不斷有資料要發回，才能同時既保證了傳送端的分段積累，又保證了延遲不增加，同時還沒有或者很少有空載的ACK。

要知道，延遲ACK和Nagle是兩個問題的解決方案。
疑難雜症13：到底何時可以傳送資料
到底何時才能傳送資料呢？如果單從Nagle演算法上看，很簡單，然而事實證明，情況還要更復雜些。如果傳送端已經排列了3個TCP分段，分段1，分段2，分段3依次被排入，三個分段都是小分段(不符合Nagle演算法中立即傳送的標準)，此時已經有一個分段被髮出了，且其確認還沒有到來，請問此時能傳送分段1和2嗎？如果按照Nagle演算法，是不能傳送的，但實際上它們是可以傳送的，因為這兩個分段已經沒有任何機會再積累新的資料了，新的資料肯定都積累在分段3上了。問題在於，分段還沒有積累到一定大小時，怎麼還可以產生新的分段？這是可能的，但這是另一個問題，在此不談。

Linux的TCP實現在這個問題上表現的更加靈活，它是這麼判斷能否傳送的(在開啟了Nagle的情況下)：

IF (沒有超過擁塞視窗大小的資料分段未確認 || 資料分段中包含FIN ) &&
資料分段沒有超越視窗邊界
Then
IF 分段在中間(上述例子中的分段1和2) ||
分段是緊急模式            ||
通過上述的Nagle演算法(改進後的Nagle演算法)
Then 傳送分段
EndIF
EndIF

曾經我也改過Nagle演算法，確切的說不是修改Nagle演算法，而是修改了“到底何時能傳送資料”的策略，以往都是傳送端判斷能否傳送資料的，可是如果此時有延遲ACK在等待被捎帶，而待傳送的資料又由於積累不夠或者其它原因不能傳送，因此兩邊都在等，這其實在某些情況下不是很好。我所做的改進中對待何時能傳送資料又增加了一種情況，這就是“ACK拉”的情況，一旦有延遲ACK等待傳送，判斷一下有沒有資料也在等待傳送，如果有的話，看看資料是否大到了一定程度，在此，我選擇的是MSS的一半：

IF (沒有超過擁塞視窗大小的資料分段未確認 || 資料分段中包含FIN ) &&
資料分段沒有超越視窗邊界
Then
IF 分段在中間(上述例子中的分段1和2) ||
分段是緊急模式            ||
通過上述的Nagle演算法(改進後的Nagle演算法)
Then 傳送分段
EndIF
ELSE IF 有延遲ACK等待傳輸                &&
傳送佇列中有待傳送的TCP分段       &&
傳送佇列的頭分段大小大於MSS的一半
Then 傳送佇列頭分段且捎帶延遲ACK
EndIF

另外，傳送佇列頭分段的大小是可以在統計意義上動態計算的，也不一定非要是MSS大小的一半。我們發現，這種演算法對於互動式網路應用是自適應的，你打字越快，特定時間內積累的分段就越長，對端回覆的越快(可以捎帶ACK)，本端傳送的也就越快(以Echo舉例會更好理解)。

疑難雜症14：《TCP/IP詳解(卷一)》中Nagle演算法的例子解讀
這個問題在網上搜了很多的答案，有的說RFC的建議，有的說別的。可是實際上這就是一個典型的“競態問題”：

首先伺服器發了兩個分段：
資料段12：ack 14
資料段13：ack 14，54:56
然後客戶端發了兩個分段：
資料段14：ack 54，14:17
資料段15：ack 56，17:18

可以看到資料段14本來應該確認56的，但是確認的卻是54。也就是說，資料段已經移出佇列將要傳送但還未傳送的時候，資料段13才到來，軟中斷處理程式搶佔了資料段14的傳送程式，要知道此時只是把資料段14移出了佇列，還沒有更新任何的狀態資訊，比如“發出但未被確認的分段數量”，此時軟中斷處理程式順利接收了分段13，然後更新視窗資訊，並且檢檢視有沒有資料要傳送，由於分段14已經移出佇列，下一個接受傳送檢查的就是分段15了，由於狀態資訊還沒有更新，因此分段15順利通過傳送檢測，傳送完成。

可以看Linux的原始碼瞭解相關資訊，tcp_write_xmit這個函式在兩個地方會被呼叫，一個是TCP的傳送程式中，另一個就是軟中斷的接收處理中，兩者在呼叫中的競態就會引起《詳解》中的那種情況。注意，這種不加鎖的傳送方式是合理的，也是最高效的，因此TCP的處理語義會做出判斷，丟棄一切不該接收或者重複接收的分段的。

~~~~~~~~~~~~~~~~~~~~
承上啟下
又到了該承上啟下，到此為止，我們敘述的TCP還都是簡單的TCP，就算是簡單的TCP，也存在上述的諸多問題，就更別提繼續增加TCP的複雜性了。到此為止，我們的TCP都是端到端意義上的，然而實際上TCP要跑在IP網路之上的，而IP網路的問題是很多的，是一個很擁堵網路。不幸的是，TCP的有些關於確認和可靠性的機制還會加重IP網路的擁堵。
~~~~~~~~~~~~~~~~~~~~

5.IP網路之上的TCP

5.1.端到端的TCP協議和IP協議之間的矛盾

端到端的TCP只能看到兩個節點，那就是自己和對方，它們是看不到任何中間的路徑的。可是IP網路卻是一跳一跳的，它們的矛盾之處在於TCP的端到端流量控制必然會導致網路擁堵。因為每條TCP連線的一端只知道它對端還有多少空間用於接收資料，它們並不管到達對端的路徑上是否還有這麼大的容量，事實上所有連線的這些空間加在一起將瞬間超過IP網路的容量，因此TCP也不可能按照滑動視窗流量控制機制很理想的執行。

勢必需要一種擁塞控制機制，反應路徑的擁塞情況。
疑難雜症15：擁塞控制的本質
由於TCP是端到端協議，因此兩端之間的控制範疇屬於流量控制，IP網路的擁塞會導致TCP分段的丟失，由於TCP看不到中間的路由器，因此這種丟失只會發生中間路由器，當然兩個端點的網路卡或者IP層丟掉資料分段也是TCP看不到的。因此擁塞控制必然作用於IP鏈路。事實上我們可以得知，只有在以下情況下擁塞控制才會起作用：

a.兩個或兩個以上的連線(其中一個一定要是TCP，另一個可以是任意連線)經過同一個路由器或者同一個鏈路時；
b.只有一個TCP連線，然而它經過了一個路由器時。

其它情況下是不會擁塞的。因為一個TCP總是希望獨享整條網路通路，而這對於多個連線而言是不可能的，必須保證TCP的公平性，這樣這種擁塞控制機制才合理。本質上，擁塞的原因就是大家都想獨享全部頻寬資源，結果導致擁塞，這也是合理的，畢竟TCP看不到網路的狀態，同時這也決定了TCP的擁塞控制必須採用試探性的方式，最終到達一個足以引起其“反應”的“刺激點”。

擁塞控制需要完成以下兩個任務：1.公平性；2.擁塞之後退出擁塞狀態。

疑難雜症16：影響擁塞的因素
我們必須認識到擁塞控制是一個整體的機制，它不偏向於任何TCP連線，因此這個機制內在的就包含了公平性。那麼影響擁塞的因素都有什麼呢？具有諷刺意味的是，起初TCP並沒有擁塞控制機制，正是TCP的超時重傳風暴(一個分段丟失造成後續的已經傳送的分段均被重傳，而這些重傳大多數是不必要的)加重了網路的擁塞。因此重傳必然不能過頻，必須把重傳定時器的超時時間設定的稍微長一些，而這一點在單一重傳定時器的設計中得到了加強。除此TCP自身的因素之外，其它所有的擁塞都可以靠擁塞控制機制來自動完成。

另外，不要把路由器想成一種線速轉發裝置，再好的路由器只要接入網路，總是會拉低網路的總頻寬，因此即使只有一個TCP連線，由於TCP的傳送方總是以傳送鏈路的頻寬傳送分段，這些分段在經過路由器的時候排隊和處理總是會有時延，因此最終肯定會丟包的。

最後，丟包的延後性也會加重擁塞。假設一個TCP連線經過了N個路由器，前N-1個路由器都能順利轉發TCP分段，但是最後一個路由器丟失了一個分段，這就導致了這些丟失的分段浪費了前面路由器的大量頻寬。

5.2.擁塞控制的策略

在介紹擁塞控制之前，首先介紹一下擁塞視窗，它實際上表示的也是“可以傳送多少資料”，然而這個和接收端通告的接收視窗意義是不一樣的，後者是流量控制用的視窗，而前者是擁塞控制用的視窗，體現了網路擁塞程度。

擁塞控制整體上分為兩類，一類是試探性的擁塞探測，另一類則是擁塞避免(注意，不是常規意義上的擁塞避免)。

5.2.1.試探性的擁塞探測分為兩類，之一是慢啟動，之二是擁塞視窗加性擴大(也就是熟知的擁塞避免，然而這種方式是避免不了擁塞的)。

5.2.2.擁塞避免方式擁塞控制旨在還沒有發生擁塞的時候就先提醒傳送端，網路擁塞了，這樣傳送端就要麼可以進入快速重傳/快速恢復或者顯式的減小擁塞視窗，這樣就避免網路擁塞的一沓糊塗之後出現超時，從而進入慢啟動階段。

5.2.3.快速重傳和快速恢復。所謂快速重傳/快速恢復是針對慢啟動的，我們知道慢啟動要從1個MSS開始增加擁塞視窗，而快速重傳/快速恢復則是一旦收到3個冗餘ACK，不必進入慢啟動，而是將擁塞視窗縮小為當前閥值的一半加上3，然後如果繼續收到冗餘ACK，則將擁塞視窗加1個MSS，直到收到一個新的資料ACK，將視窗設定成正常的閥值，開始加性增加的階段。

當進入快速重傳時，為何要將擁塞視窗縮小為當前閥值的一半加上3呢？加上3是基於資料包守恆來說的，既然已經收到了3個冗餘ACK，說明有三個資料分段已經到達了接收端，既然三個分段已經離開了網路，那麼就是說可以在傳送3個分段了，只要再收到一個冗餘ACK，這也說明1個分段已經離開了網路，因此就將擁塞視窗加1個MSS。直到收到新的ACK，說明直到收到第三個冗餘ACK時期傳送的TCP分段都已經到達對端了，此時進入正常階段開始加性增加擁塞視窗。

疑難雜症17：超時重傳和收到3個冗餘ACK後重傳
這兩種重傳的意義是不同的，超時重傳一般是因為網路出現了嚴重擁塞(沒有一個分段到達，如果有的話，肯定會有ACK的，若是正常ACK，則重置重傳定時器，若是冗餘ACK，則可能是個別報文丟失或者被重排序，若連續3個冗餘ACK，則很有可能是個別分段丟失)，此時需要更加嚴厲的縮小擁塞視窗，因此此時進入慢啟動階段。而收到3個冗餘ACK後說明確實有中間的分段丟失，然而後面的分段確實到達了接收端，這因為這樣才會傳送冗餘ACK，這一般是路由器故障或者輕度擁塞或者其它不太嚴重的原因引起的，因此此時擁塞視窗縮小的幅度就不能太大，此時進入快速重傳/快速恢復階段。

疑難雜症18：為何收到3個冗餘ACK後才重傳
這是一種權衡的結構，收到兩個或者一個冗餘ACK也可以重傳，但是這樣的話可能或造成不必要的重傳，因為兩個資料分段發生亂序的可能性不大，超過三個分段發生亂序的可能性才大，換句話說，如果僅僅收到一個亂序的分段，那很可能被中間路由器重排了，那麼另一個分段很可能馬上就到，然而如果連續收到了3個分段都沒能彌補那個缺漏，那很可能是它丟失了，需要重傳。因此3個冗餘ACK是一種權衡，在減少不必要重傳和確實能檢測出單個分段丟失之間所作的權衡。
注意，冗餘ACK是不能捎帶的。

疑難雜症19：乘性減和加性增的深層含義
為什麼是乘性減而加性增呢？擁塞視窗的增加受惠的只是自己，而擁塞視窗減少受益的大家，可是自己卻受到了傷害。哪一點更重要呢？我們知道TCP的擁塞控制中內建了公平性，恰恰就是這種乘性減實現了公平性。擁塞視窗的1個MSS的改變影響一個TCP傳送者，為了使得自己擁塞視窗的減少影響更多的TCP傳送者-讓更多的傳送者受益，那麼採取了乘性減的策略。

當然，BIC演算法提高了加性增的效率，不再一個一個MSS的加，而是一次加比較多的MSS，採取二分查詢的方式逐步找到不丟包的點，然後加性增。

疑難雜症20：TCP連線的傳輸穩定狀態是什麼
首先，先說一下傳送端的傳送視窗怎麼確定，它取的是擁塞視窗和接收端通告視窗的最小值。然後，我們提出三種傳送視窗的穩定狀態：
a.IP網際網路絡上接收端擁有大視窗的經典鋸齒狀
b.IP網際網路絡上接收端擁有小視窗的直線狀態
c.直連網路端點間的滿載狀態下的直線狀態

其中a是大多數的狀態，因為一般而言，TCP連線都是建立在網際網路上的，而且是大量的，比如Web瀏覽，電子郵件，網路遊戲，Ftp下載等等。TCP傳送端用慢啟動或者擁塞避免方式不斷增加其擁塞視窗，直到丟包的發生，然後進入慢啟動或者擁塞避免階段(要看是由於超時丟包還是由於冗餘ACK丟包)，此時傳送視窗將下降到1或者下降一半，這種情況下，一般接收端的接收視窗是比較大的，畢竟IP網路並不是什麼很快速的網路，一般的機器處理速度都很快。

但是如果接收端特別破，處理速度很慢，就會導致其通告一個很小的視窗，這樣的話，即使擁塞視窗再大，傳送端也還是以通告的接收視窗為傳送視窗，這樣就不會發生擁塞。最後，如果唯一的TCP連線執行在一個直連的兩臺主機上，那麼它將獨享網路頻寬，這樣該TCP的資料流在最好的情況下將填滿網路管道(我們把網路管道定義為頻寬和延時的乘積)，其實在這種情況下是不存在擁塞的，就像你一個人獨自徘徊在飄雨黃昏的街頭一樣…

5.2.4.主動的擁塞避免

前面我們描述的擁塞控制方式都是試探性的檢測，然後擁塞視窗被動的進行乘性減，這樣在接收端視窗很大的情況下(一般都是這樣，網路擁堵，分段就不會輕易到達接收端，導致接收端的視窗大量空置)就可能出現鋸齒形狀的“時間-視窗”圖，類似在一個擁堵的北京X環上開車，傳送機發動，車開動，停止，等待，發動機發動，車開動…聽聲音也能聽出來。

雖然TCP看不到下面的IP網路，然而它還是可以通過檢測RTT的變化以及擁塞視窗的變化推算出IP網路的擁堵情況的。就比方說北京東四環一家快遞公司要持續送快遞到西四環，當發件人發現貨到時間越來越慢的時候，他會意識到“下班高峰期快到了”…

可以通過持續觀測RTT的方式來主動調整擁塞視窗的大小而不是一味的加性增。然而還有更猛的演算法，那就是計算兩個差值的乘積：
(當前擁塞視窗-上一次擁塞視窗)x(當前的RTT-上一次的RTT)

如果結果是正數，則擁塞視窗減少1/8，若結果是負數或者0，則視窗增加一個MSS。注意，這回不再是乘性減了，可以看出，減的幅度比乘性減幅度小，這是因為這種擁塞控制是主動的，而不是之前的那種被動的試探方式。在試探方式中，乘性減以一種懲罰的方式實現了公平性，而在這裡的主動方式中，當意識到要擁塞的時候，TCP傳送者主動的減少了擁塞視窗，為了對這種自首行為進行鼓勵，採用了小幅減少擁塞視窗的方式。需要注意的是，在擁塞視窗減小的過程中，乘積的前一個差值是負數，如果後一個差值也是負數，那麼結果就是繼續縮減視窗，直到擁塞緩解或者視窗減少到了一定程度，使得後一個差值成了正數或者0，這種情況下，其實後一個差值只能變為0。

疑難雜症21：路由器和TCP的互動
雖然有了5.2.4節介紹的主動的擁塞檢測，那麼路由器能不能做點什麼幫助檢測擁塞呢？這種對路由器的擴充套件是必要的，要知道，每天有無數的TCP要通過路由器，雖然路由器不管TCP協議的任何事(當然排除連線跟蹤之類的，這裡所說的是標準的IP路由器)，但是它卻能以一種很簡單的方式告訴TCP的兩端IP網路發生了擁堵，這種方式就是當路由器檢測到自己發生輕微擁堵的時候隨機的丟包，隨機丟包而不是連續丟包對於TCP而言是有重大意義的，隨機丟包會使TCP發現丟棄了個別的分段而後續的分段仍然會到達接收端，這樣TCP傳送端就會接收到3個冗餘ACK，然後進入快速重傳/快速恢復而不是慢啟動。

這就是路由器能幫TCP做的事。

6.其它

疑難雜症22：如何學習TCP
很多人發帖問TCP相關的內容，接下來稀里嘩啦的就是讓看《TCP/IP詳解》和《Unix網路程式設計》裡面的特定章節，我覺得這種回答很不負責任。因為我並不認為這兩本書有多大的幫助，寫得確實很不錯，然而可以看出Richard Stevens是一個實用主義者，他喜歡用例項來解釋一切，《詳解》通篇都是用tcpdump的輸出來講述的，這種方式只是適合於已經對TCP很理解的人，然而大多數的人是看不明白的。

如果想從設計的角度來說，這兩本書都很爛。我覺得應該先看點入門的，比如Wiki之類的，然後看RFC文件,793，896，1122等)，這樣你就明白TCP為何這麼設計了，而這些你永遠都不能在Richard Stevens的書中得到。最後，如果你想，那麼就看一點Richard Stevens的書，最重要的還是寫點程式碼或者敲點命令，然後抓包自己去分析。

疑難雜症23：Linux，Windows和網路程式設計
我覺得在Linux上寫點TCP的程式碼是很不錯的，如果有BSD那就更好了。不推薦用Winsock學習TCP。雖然微軟聲稱自己的API都是為了讓事情更簡單，但實際上事情卻更復雜了，如果你用Winsock學習，你就要花大量的時候去掌握一些和網路程式設計無關但是windows平臺上卻少不了的東西

6.1.總結

TCP協議是一個端到端的協議，雖然話說它是一個帶流量控制，擁塞控制的協議，然而正是因為這些所謂的控制才導致了TCP變得複雜。同時這些特性是互相雜糅的，流量控制帶來了很多問題，解決這些問題的方案最終又帶來了新的問題，這些問題在解決的時候都只考慮了端到端的意義，但實際上TCP需要盡力而為的IP提供的網路，因此擁塞成了最終的結症，擁塞控制演算法的改進也成了一個單獨的領域。

在學習TCP的過程中，切忌一鍋粥一盤棋的方式，一定要分清楚每一個演算法到底是解決什麼問題的，每一個問題和其他問題到底有什麼關聯，這些問題的解決方案之間有什麼關聯，另外TCP的發展歷史也最好了解一下，這些都搞明白了，TCP協議就徹底被你掌控了。接下來你就可以學習Socket API了，然後高效的TCP程式出自你手！