1. TCP協(xié)議互聯(lián)網(wǎng)的“可靠信使”如果你用過微信發(fā)消息或者在網(wǎng)上購物有沒有想過你發(fā)送的“在嗎”或者你點(diǎn)擊“支付”按鈕后那串?dāng)?shù)字是如何準(zhǔn)確無誤地穿越成千上萬公里的網(wǎng)絡(luò)到達(dá)對(duì)方手機(jī)或服務(wù)器的這背后TCP協(xié)議扮演著至關(guān)重要的角色。它不像它的兄弟UDP那樣把數(shù)據(jù)包像扔紙飛機(jī)一樣扔出去就不管了TCP更像一個(gè)負(fù)責(zé)任的快遞員確保每一個(gè)包裹數(shù)據(jù)段都親手交到收件人手里并且順序正確、完好無損。今天我們就來徹底拆解這個(gè)互聯(lián)網(wǎng)的基石協(xié)議——TCP從它是什么開始深入到它報(bào)文結(jié)構(gòu)的每一個(gè)比特位讓你不僅知道怎么用更明白它為何如此設(shè)計(jì)。簡單來說TCP是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。這句話包含了三個(gè)核心關(guān)鍵詞“面向連接”意味著通信前要先“握手”建立虛擬鏈路“可靠”意味著它有一套復(fù)雜的機(jī)制保證數(shù)據(jù)不丟、不亂、不錯(cuò)“基于字節(jié)流”意味著它對(duì)上層應(yīng)用比如你的瀏覽器提供的是一個(gè)無結(jié)構(gòu)的字節(jié)流服務(wù)而不管這些字節(jié)是圖片的一部分還是一段文字。理解TCP是理解現(xiàn)代網(wǎng)絡(luò)通信、進(jìn)行高性能服務(wù)端開發(fā)、乃至高效排查網(wǎng)絡(luò)故障的必修課。無論是你遇到的“TCP三次握手”問題還是令人頭疼的“TCP retransmission”重傳告警其根源都藏在協(xié)議的細(xì)節(jié)里。2. TCP協(xié)議的核心特性與設(shè)計(jì)哲學(xué)在深入報(bào)文結(jié)構(gòu)之前我們必須先理解TCP協(xié)議設(shè)計(jì)的初衷和它要解決的根本問題。網(wǎng)絡(luò)底層IP層提供的是“盡力而為”的不可靠服務(wù)數(shù)據(jù)包可能丟失、重復(fù)、亂序。TCP就是在這樣不可靠的IP網(wǎng)絡(luò)之上為應(yīng)用程序構(gòu)建一個(gè)可靠的“邏輯通信信道”。2.1 可靠性是如何實(shí)現(xiàn)的TCP的可靠性并非魔法而是通過一系列精巧的機(jī)制組合實(shí)現(xiàn)的序列號(hào)與確認(rèn)應(yīng)答這是可靠性的基石。TCP將發(fā)送的數(shù)據(jù)每個(gè)字節(jié)都編號(hào)。接收方收到數(shù)據(jù)后會(huì)回送一個(gè)確認(rèn)報(bào)文告知發(fā)送方“我已經(jīng)成功收到了到第N個(gè)字節(jié)之前的所有數(shù)據(jù)”。這個(gè)確認(rèn)號(hào)ACK Number指明了期望收到的下一個(gè)字節(jié)的序號(hào)。如果發(fā)送方在一定時(shí)間內(nèi)沒收到確認(rèn)就認(rèn)為數(shù)據(jù)丟失觸發(fā)重傳。超時(shí)重傳為每個(gè)發(fā)出的數(shù)據(jù)段啟動(dòng)一個(gè)定時(shí)器。如果在定時(shí)器到期前未收到對(duì)應(yīng)的確認(rèn)發(fā)送方會(huì)重新發(fā)送該數(shù)據(jù)段。這個(gè)超時(shí)時(shí)間RTO是動(dòng)態(tài)計(jì)算的基于網(wǎng)絡(luò)往返時(shí)間RTT非常智能。連接管理著名的“三次握手”建立連接“四次揮手”釋放連接。這確保了通信雙方都明確知道連接的開始與結(jié)束同步了初始序列號(hào)為有序可靠傳輸打下基礎(chǔ)。流量控制接收方通過“窗口大小”字段告訴發(fā)送方“我還能接收多少字節(jié)”。這防止了發(fā)送方發(fā)送過快導(dǎo)致接收方緩沖區(qū)溢出、數(shù)據(jù)被丟棄。這是一種端到端的速率限制機(jī)制。擁塞控制這是TCP最精妙的部分之一。它感知網(wǎng)絡(luò)整體的擁堵狀況動(dòng)態(tài)調(diào)整發(fā)送速率避免“高速公路堵車”。經(jīng)典算法包括慢啟動(dòng)、擁塞避免、快速重傳和快速恢復(fù)。這不再是點(diǎn)對(duì)點(diǎn)的控制而是發(fā)送方對(duì)網(wǎng)絡(luò)公共資源的友好利用。2.2 面向字節(jié)流 vs 面向報(bào)文這是一個(gè)關(guān)鍵概念。UDP是面向報(bào)文的應(yīng)用層交給UDP多長的報(bào)文UDP就原樣發(fā)送一次發(fā)送一個(gè)報(bào)文接收方一次接收一個(gè)完整的報(bào)文邊界清晰。TCP則不同。應(yīng)用進(jìn)程比如你寫的服務(wù)端程序調(diào)用write操作時(shí)數(shù)據(jù)先進(jìn)入TCP的發(fā)送緩沖區(qū)。TCP協(xié)議?？梢詻Q定如何拆分這些數(shù)據(jù)。它可能將多次write的數(shù)據(jù)合并成一個(gè)大的TCP段發(fā)送也可能將一次write的大數(shù)據(jù)拆分成多個(gè)TCP段發(fā)送。對(duì)接收方而言數(shù)據(jù)先進(jìn)入TCP接收緩沖區(qū)應(yīng)用進(jìn)程調(diào)用read時(shí)可能一次讀出對(duì)方多次發(fā)送的數(shù)據(jù)也可能一次read只讀出一部分?jǐn)?shù)據(jù)需要多次read才能拿全。這帶來的一個(gè)直接影響是“粘包”和“拆包”問題。因?yàn)門CP不維護(hù)消息邊界所以上層的應(yīng)用協(xié)議如HTTP、自定義協(xié)議必須自己定義消息的邊界常見方法有定長消息每個(gè)消息長度固定。分隔符用特殊字符如換行符\n分隔消息。長度前綴在消息頭部用一個(gè)字段如2字節(jié)或4字節(jié)整數(shù)標(biāo)明后續(xù)消息體的長度。理解這一點(diǎn)對(duì)于用C#、Java等語言實(shí)現(xiàn)TCP網(wǎng)絡(luò)編程至關(guān)重要。你不能假設(shè)一次Receive調(diào)用拿到的是一個(gè)完整的“業(yè)務(wù)消息”。3. TCP報(bào)文段格式詳解TCP協(xié)議的所有機(jī)制都體現(xiàn)在其報(bào)文段Segment的頭部結(jié)構(gòu)中。一個(gè)TCP報(bào)文段由“頭部”和“數(shù)據(jù)”兩部分組成。頭部通常20字節(jié)不含選項(xiàng)其結(jié)構(gòu)如下所示我們將逐字段拆解0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 -------------------------------- | 源端口號(hào) (Source Port) | 目的端口號(hào) (Destination Port) | -------------------------------- | 序列號(hào) (Sequence Number) | -------------------------------- | 確認(rèn)號(hào) (Acknowledgment Number) | -------------------------------- | 數(shù)據(jù)偏移 | 保留 |U|A|P|R|S|F| 窗口大小 (Window Size) | | (4 bits)| (6) |R|C|S|S|Y|I| | | | |G|K|H|T|N|N| | -------------------------------- | 校驗(yàn)和 (Checksum) | 緊急指針 (Urgent Pointer) | -------------------------------- | 選項(xiàng)和填充 (Options Padding) | -------------------------------- | 數(shù)據(jù) (Data) | --------------------------------3.1 端口號(hào)與套接字源端口號(hào)16位范圍0-65535。標(biāo)識(shí)發(fā)送方應(yīng)用程序。目的端口號(hào)16位標(biāo)識(shí)接收方應(yīng)用程序。端口號(hào)與IP地址共同構(gòu)成了“套接字”它唯一標(biāo)識(shí)了互聯(lián)網(wǎng)中的一條通信鏈路的一端。例如192.168.1.100:54321 - 203.0.113.5:80就是一個(gè)典型的套接字對(duì)表示IP為192.168.1.100的機(jī)器上端口54321的進(jìn)程正在與IP為203.0.113.5的機(jī)器的80端口通常是Web服務(wù)通信。注意客戶端端口通常由操作系統(tǒng)隨機(jī)分配大于1024而服務(wù)器端口則是眾所周知的如HTTP:80, HTTPS:443, SSH:22。在編寫服務(wù)器程序時(shí)你需要bind一個(gè)特定端口編寫客戶端時(shí)通常不需要手動(dòng)指定端口。3.2 序列號(hào)與確認(rèn)號(hào)可靠傳輸?shù)淖鴺?biāo)軸這是TCP頭部中最核心的兩個(gè)字段各32位。序列號(hào)指本報(bào)文段所發(fā)送的數(shù)據(jù)的第一個(gè)字節(jié)的編號(hào)。在建立連接時(shí)雙方會(huì)隨機(jī)生成一個(gè)初始序列號(hào)以增加安全性和避免舊連接的報(bào)文干擾。例如初始序列號(hào)為1000如果第一個(gè)報(bào)文段攜帶了500字節(jié)數(shù)據(jù)那么這個(gè)報(bào)文段的序列號(hào)就是1000下一個(gè)報(bào)文段的序列號(hào)就是1500。確認(rèn)號(hào)32位。指接收方期望收到的下一個(gè)字節(jié)的序列號(hào)。同時(shí)它也隱式地確認(rèn)了所有該序號(hào)之前的數(shù)據(jù)都已正確接收。例如接收方收到了序列號(hào)為1000、長度500的報(bào)文它應(yīng)該回送一個(gè)確認(rèn)號(hào)1500的ACK報(bào)文表示“我已收到1000-1499的數(shù)據(jù)請(qǐng)下次從1500開始發(fā)”。這里有一個(gè)關(guān)鍵點(diǎn)確認(rèn)是累積的。如果接收方先收到序列號(hào)1500-1999的報(bào)文后收到1000-1499的報(bào)文當(dāng)1000-1499到達(dá)后接收方會(huì)立即回復(fù)確認(rèn)號(hào)2000因?yàn)?000-1999的數(shù)據(jù)都齊了。這有助于減少ACK報(bào)文的數(shù)量。3.3 標(biāo)志位控制通信狀態(tài)頭部第13字節(jié)從0開始計(jì)的6個(gè)比特位是控制標(biāo)志位它們決定了報(bào)文段的類型和狀態(tài)。URG緊急指針有效。很少使用。ACK確認(rèn)號(hào)有效。除了初始的SYN報(bào)文幾乎所有報(bào)文ACK位都被置1。PSH推送功能。提示接收端應(yīng)立即將數(shù)據(jù)提交給上層應(yīng)用而不是等緩沖區(qū)滿。在實(shí)際棧實(shí)現(xiàn)中這個(gè)標(biāo)志位經(jīng)常被忽略。RST重置連接。表示出現(xiàn)嚴(yán)重錯(cuò)誤必須釋放并重新建立連接。當(dāng)你看到“Connection reset by peer”錯(cuò)誤時(shí)就是對(duì)方發(fā)來了RST報(bào)文。SYN同步序列號(hào)。用于建立連接。“三次握手”中前兩個(gè)報(bào)文SYN位都是1。FIN終止連接。用于禮貌地關(guān)閉連接?！八拇螕]手”中主動(dòng)關(guān)閉方會(huì)發(fā)送FIN。標(biāo)志位的組合定義了經(jīng)典場(chǎng)景SYN1, ACK0連接請(qǐng)求。SYN1, ACK1連接請(qǐng)求的應(yīng)答。ACK1普通的數(shù)據(jù)傳輸或確認(rèn)。FIN1, ACK1連接終止請(qǐng)求。RST1, ACK1強(qiáng)制重置連接。3.4 窗口大小、校驗(yàn)和與緊急指針窗口大小16位。這是流量控制的關(guān)鍵。它告訴對(duì)方“我的接收緩沖區(qū)還有多少空閑字節(jié)”即對(duì)方最多還能發(fā)送多少未被確認(rèn)的數(shù)據(jù)。這是一個(gè)動(dòng)態(tài)變化的值。由于只有16位在高速網(wǎng)絡(luò)中可能成為瓶頸因此有了“窗口縮放”選項(xiàng)來擴(kuò)大窗口。校驗(yàn)和16位。用于校驗(yàn)TCP頭部、數(shù)據(jù)和偽首部包含IP頭部分信息在傳輸過程中是否出錯(cuò)。如果校驗(yàn)失敗報(bào)文會(huì)被靜默丟棄等待發(fā)送方超時(shí)重傳。緊急指針16位。與URG標(biāo)志配合使用指示緊急數(shù)據(jù)在報(bào)文段中的結(jié)束位置。實(shí)際應(yīng)用極少。3.5 數(shù)據(jù)偏移與選項(xiàng)數(shù)據(jù)偏移4位。以4字節(jié)為單位指示TCP頭部長度。因?yàn)轭^部有可變長的“選項(xiàng)”字段。最小值為5表示20字節(jié)最大值為15表示60字節(jié)。選項(xiàng)可變長用于擴(kuò)展TCP功能。最常見的選項(xiàng)包括最大報(bào)文段長度在連接建立時(shí)雙方通告自己愿意接收的最大報(bào)文段長度。窗口縮放因子用于擴(kuò)大窗口字段的表示范圍應(yīng)對(duì)高速網(wǎng)絡(luò)。選擇性確認(rèn)允許接收方只確認(rèn)不連續(xù)的數(shù)據(jù)塊提高重傳效率。時(shí)間戳用于更精確地計(jì)算RTT防止序列號(hào)回繞。4. 從報(bào)文結(jié)構(gòu)看三次握手與四次揮手理解了報(bào)文結(jié)構(gòu)我們?cè)倩仡^看經(jīng)典的“三次握手”和“四次揮手”就會(huì)一目了然。4.1 三次握手建立連接假設(shè)客戶端C要連接服務(wù)器S。C - S: 發(fā)送報(bào)文SYN1,ACK0,seqJ。C進(jìn)入SYN_SENT狀態(tài)。這個(gè)報(bào)文不攜帶應(yīng)用數(shù)據(jù)。S - C: 發(fā)送報(bào)文SYN1,ACK1,seqK,ackJ1。S進(jìn)入SYN_RCVD狀態(tài)。這個(gè)報(bào)文也不攜帶應(yīng)用數(shù)據(jù)。ackJ1表示“我確認(rèn)了你的序列號(hào)J期待你下一個(gè)發(fā)J1”。C - S: 發(fā)送報(bào)文SYN0,ACK1,seqJ1,ackK1。C進(jìn)入ESTABLISHED狀態(tài)。這個(gè)報(bào)文可以攜帶應(yīng)用數(shù)據(jù)。ackK1表示“我確認(rèn)了你的序列號(hào)K期待你下一個(gè)發(fā)K1”。為什么是三次不是兩次核心是防止已失效的連接請(qǐng)求報(bào)文突然又傳到了服務(wù)器。假設(shè)只有兩次握手一個(gè)舊的連接請(qǐng)求報(bào)文延遲后到達(dá)服務(wù)器服務(wù)器會(huì)誤認(rèn)為客戶端發(fā)起新連接于是分配資源并回應(yīng)進(jìn)入連接狀態(tài)。但客戶端并沒有發(fā)起新連接不會(huì)理會(huì)服務(wù)器的回應(yīng)導(dǎo)致服務(wù)器資源白白浪費(fèi)。三次握手的情況下客戶端會(huì)對(duì)這個(gè)無效的服務(wù)器回應(yīng)發(fā)出RST服務(wù)器能及時(shí)釋放資源。4.2 四次揮手釋放連接連接是全雙工的每一方都必須單獨(dú)關(guān)閉自己的發(fā)送通道。 假設(shè)客戶端C主動(dòng)關(guān)閉。C - S: 發(fā)送報(bào)文FIN1,ACK1,seqU。C進(jìn)入FIN_WAIT_1狀態(tài)。表示“我的數(shù)據(jù)發(fā)完了要關(guān)閉我這邊到你的連接”。S - C: 發(fā)送報(bào)文ACK1,seqV,ackU1。S進(jìn)入CLOSE_WAIT狀態(tài)。C收到后進(jìn)入FIN_WAIT_2狀態(tài)。這僅僅是確認(rèn)收到了C的關(guān)閉請(qǐng)求但S可能還有數(shù)據(jù)要發(fā)送給C。S - C: 當(dāng)S的數(shù)據(jù)也發(fā)送完畢后發(fā)送報(bào)文FIN1,ACK1,seqW,ackU1。S進(jìn)入LAST_ACK狀態(tài)。C - S: 發(fā)送報(bào)文ACK1,seqU1,ackW1。C進(jìn)入TIME_WAIT狀態(tài)等待2MSL后關(guān)閉。S收到后立即關(guān)閉。為什么要有TIME_WAIT狀態(tài)且等待2MSLMSL是報(bào)文最大生存時(shí)間。等待2MSL有兩個(gè)目的確保最后一個(gè)ACK能到達(dá)S。如果S沒收到ACK會(huì)重發(fā)FIN。C在TIME_WAIT狀態(tài)下能再次回應(yīng)ACK。讓本次連接產(chǎn)生的所有報(bào)文都在網(wǎng)絡(luò)中消逝。避免相同四元組源IP、源端口、目的IP、目的端口的新連接收到舊連接的延遲報(bào)文造成數(shù)據(jù)混亂。實(shí)操心得在高并發(fā)短連接服務(wù)中TIME_WAIT狀態(tài)連接過多會(huì)耗盡端口資源。常見的優(yōu)化是在服務(wù)器端被動(dòng)關(guān)閉方調(diào)整內(nèi)核參數(shù)如net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle注意tcp_tw_recycle在NAT環(huán)境下有問題Linux 4.12后已移除或者讓客戶端承擔(dān)關(guān)閉連接的代價(jià)即讓服務(wù)端主動(dòng)關(guān)閉但需設(shè)計(jì)好協(xié)議。5. 流量控制與滑動(dòng)窗口協(xié)議流量控制解決的是“接收方處理不過來”的問題。其核心是TCP頭部的“窗口大小”字段。接收方在每次發(fā)送ACK時(shí)都會(huì)通過“窗口大小”字段告知發(fā)送方自己接收緩沖區(qū)剩余的空間。發(fā)送方維護(hù)一個(gè)“發(fā)送窗口”這個(gè)窗口內(nèi)的數(shù)據(jù)可以分為四類已發(fā)送且已確認(rèn)已發(fā)送但未確認(rèn)未發(fā)送但允許發(fā)送在窗口內(nèi)未發(fā)送且不允許發(fā)送在窗口外隨著接收方ACK的到達(dá)和窗口通告的更新這個(gè)發(fā)送窗口會(huì)向右“滑動(dòng)”故名“滑動(dòng)窗口協(xié)議”。零窗口與窗口探測(cè)如果接收方緩沖區(qū)滿了它會(huì)通告一個(gè)大小為0的窗口。發(fā)送方此時(shí)必須停止發(fā)送。為了打破僵局發(fā)送方會(huì)啟動(dòng)一個(gè)“持續(xù)定時(shí)器”定時(shí)發(fā)送一個(gè)1字節(jié)的“窗口探測(cè)”報(bào)文以獲取最新的窗口大小。6. 擁塞控制TCP的“大局觀”如果說流量控制是關(guān)心對(duì)端的處理能力那么擁塞控制就是關(guān)心整條網(wǎng)絡(luò)路徑的通行能力。其目標(biāo)是避免網(wǎng)絡(luò)因過載而癱瘓。TCP通過維護(hù)一個(gè)“擁塞窗口”來實(shí)現(xiàn)。經(jīng)典算法慢啟動(dòng)連接開始時(shí)擁塞窗口從一個(gè)很小的值開始每收到一個(gè)ACK窗口就增加一個(gè)MSS。這是指數(shù)增長目的是快速探測(cè)網(wǎng)絡(luò)容量。擁塞避免當(dāng)窗口達(dá)到一個(gè)閾值時(shí)進(jìn)入線性增長階段每經(jīng)過一個(gè)RTT窗口增加一個(gè)MSS。快速重傳與快速恢復(fù)當(dāng)發(fā)送方連續(xù)收到3個(gè)重復(fù)的ACK時(shí)例如收到了ACK 1000, 1000, 1000它認(rèn)為有個(gè)報(bào)文段丟失了但后續(xù)報(bào)文已到達(dá)接收方。此時(shí)會(huì)立即重傳丟失的報(bào)文并將擁塞窗口減半然后進(jìn)入“快速恢復(fù)”階段線性增長窗口而不是退回到慢啟動(dòng)。這大幅提升了性能。擁塞控制的體現(xiàn)你在下載大文件時(shí)速度會(huì)從慢到快迅速上升慢啟動(dòng)然后穩(wěn)定在一個(gè)相對(duì)高的速率擁塞避免如果網(wǎng)絡(luò)出現(xiàn)波動(dòng)速度會(huì)突然下降然后再次爬升這就是擁塞控制算法在起作用。7. 常見TCP問題分析與實(shí)戰(zhàn)關(guān)聯(lián)理解了報(bào)文和機(jī)制我們就能解釋很多熱搜詞和實(shí)際問題?！癟CP retransmission”這是Wireshark等抓包工具中的常見標(biāo)識(shí)。表示一個(gè)TCP段被重傳了。原因可能是1原始報(bào)文丟失2ACK丟失發(fā)送方超時(shí)3網(wǎng)絡(luò)延遲大ACK在超時(shí)后才到達(dá)。偶爾的重傳是正常的頻繁重傳則意味著網(wǎng)絡(luò)質(zhì)量差?！癟CP acked unseen segment”這個(gè)提示意味著抓包工具看到了一個(gè)確認(rèn)號(hào)但這個(gè)確認(rèn)號(hào)所確認(rèn)的數(shù)據(jù)它并沒有抓到。這通常不是問題只是抓包不完整比如抓包點(diǎn)不在路徑起點(diǎn)?！癈onnection reset by peer”對(duì)方發(fā)送了RST標(biāo)志位為1的報(bào)文。常見原因?qū)Ψ竭M(jìn)程崩潰重啟對(duì)方端口未監(jiān)聽收到了不期望的報(bào)文如半連接狀態(tài)收到數(shù)據(jù)手動(dòng)關(guān)閉了連接?！皌cp: sendmsg failed due to socket memory overlimit”這通常發(fā)生在發(fā)送方。當(dāng)應(yīng)用發(fā)送數(shù)據(jù)過快而TCP發(fā)送緩沖區(qū)已滿且內(nèi)核內(nèi)存緊張時(shí)send系統(tǒng)調(diào)用可能返回此錯(cuò)誤。這涉及到TCP的發(fā)送緩沖區(qū)管理和內(nèi)存壓力控制。端口占用與查看在Windows下netstat -ano | findstr :端口號(hào)可以查看TCP連接和監(jiān)聽狀態(tài)。netsh命令可以管理端口范圍。在Linux下常用netstat -tunlp或ss -tunlp。對(duì)于開發(fā)者而言無論是用C#實(shí)現(xiàn)TCP代理轉(zhuǎn)發(fā)、處理Modbus TCP協(xié)議還是進(jìn)行嵌入式TCP開發(fā)底層原理都是相通的。在C#中TcpListener和TcpClient類封裝了TCP通信但你必須自己處理消息邊界粘包拆包。在調(diào)試時(shí)使用“TCP調(diào)試助手”這類工具可以直觀地發(fā)送和接收原始報(bào)文但深入排查復(fù)雜問題最終還是要依靠像Wireshark這樣的抓包工具對(duì)照TCP報(bào)文結(jié)構(gòu)分析每一個(gè)字段才能真正洞悉問題所在。TCP協(xié)議的設(shè)計(jì)充滿了權(quán)衡與智慧它平衡了可靠性、效率和公平性。雖然像QUIC這樣的新協(xié)議在特定場(chǎng)景下帶來了改進(jìn)但TCP作為互聯(lián)網(wǎng)的脊梁其地位在可預(yù)見的未來依然不可動(dòng)搖。掌握它就是掌握了網(wǎng)絡(luò)通信的命脈。在下一篇中我們將深入TCP的狀態(tài)機(jī)、內(nèi)核參數(shù)調(diào)優(yōu)以及如何在代碼中更好地駕馭它。