大家好，我是Alex，今天分享一篇好文章，來自好友dog250，本文深入淺出地分析了TCP協議為什么要這樣設計的背后原因，解答了幾乎所有TCP疑難雜癥問題，可以幫助大家查缺補漏，加深對TCP協議的理解，攻克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程序出自你手！

整理：Alex 來源：

https://blog.csdn.net/dog250/article/details/6612496

網絡硬核文章推薦

• 計算機網絡硬核指南|網絡設計核心思想

• 云網絡丟包故障定位全景指南
  

hello， 大家好，我是Alex，騰訊云資深后臺開發，騰訊云網絡核心開發，獲得過多次五星員工（鵝廠優秀員工），本人工作多年，面試經驗豐富，負責騰訊云網絡核心架構設計和開發，對大規模，大流量，高并發，高可用，極致高性能系統有豐富的經驗，擅長后臺開發，網絡技術和性能優化，希望可以通過公眾號分享多年技術研究心得，高質量的文章，面試經驗，工作經驗，希望輸出的文章對大家有用，非常歡迎大家和我一起討論技術，面試跳槽，技術咨詢，職場經驗，歡迎星標置頂。

總結

以上是生活随笔為你收集整理的TCP协议疑难杂症全景解析|硬核的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。