議全解：握手、重傳、抓包與選型排障)
凌晨兩點被告警電話叫起來某服務(wù)的接口超時率十幾分鐘內(nèi)從 0.3% 飆到 30%日志里刷屏connection reset by peer抓包一看滿屏 RST 和大量重傳最后定位到一個中間設(shè)備的空閑連接超時策略和業(yè)務(wù)的長連接心跳沒對齊。這種場面只要做過線上服務(wù)遲早會碰上一兩次。而每一次追到最底層你都會撞上同一個東西計算機網(wǎng)絡(luò)里的UDP / TCP 協(xié)議。這兩個協(xié)議是所有上層玩意的地基。上面架著 HTTP、gRPC、DNS、數(shù)據(jù)庫連接、消息隊列、音視頻推流、游戲同步、物聯(lián)網(wǎng)上報下面踩著 IP 層的盡力而為。框架再花哨、網(wǎng)關(guān)再智能、SDK 封裝再厚落到網(wǎng)線上跑的無非就是這兩種傳輸層協(xié)議之一。我見過不少寫了三四年業(yè)務(wù)的同學(xué)能把框架的線程模型講得頭頭是道但一問他為什么這個接口偶爾會多出 40 毫秒延遲為什么這條消息偶發(fā)丟了沒報錯為什么服務(wù)端 ESTABLISHED 一堆但業(yè)務(wù)就是不通就答不上來了。原因很簡單這些問題不在框架層在傳輸層。這篇內(nèi)容我想把它寫成一個完整的、可以拿來當手冊用的東西從兩個協(xié)議的報文頭逐字節(jié)拆到 TCP 的連接管理和可靠性機制怎么堆出來的再到用抓包和代碼把協(xié)議看見最后是選型決策和線上排障實錄。寫的過程中我會把參數(shù)的計算過程、我踩過的坑、以及那些文檔里不會寫的經(jīng)驗都放進去。適合誰看寫后端業(yè)務(wù)服務(wù)、做客戶端和嵌入式、搞音視頻或?qū)崟r同步、以及在準備技術(shù)面試的同學(xué)都能從中拿到東西。基礎(chǔ)弱的可以先把第 1、2 章讀透把是什么釘死有經(jīng)驗的可以直接跳到第 4、5、7 章那里全是我在實踐中反復(fù)驗證過的細節(jié)。代碼示例我統(tǒng)一用 Python 寫因為它最接近偽代碼你換成 Go、Java、C 都能一一對應(yīng)。1. 先把兩個協(xié)議擺到臺面上它們到底在解決什么問題1.1 從一次發(fā)消息說起傳輸層到底負責(zé)什么任何一次網(wǎng)絡(luò)通信本質(zhì)上都是一臺機器上的某個進程把一段字節(jié)交給另一臺機器上的某個進程。IP 層只負責(zé)把數(shù)據(jù)包送到目標主機它不知道什么是進程也不保證送達、不保證順序、不保證不重復(fù)。傳輸層就是把 IP 層的這個盡力而為服務(wù)加工成應(yīng)用能直接用的東西。這里有兩個必須解決的問題UDP 和 TCP 各自給出了不同答案。第一個是進程尋址。一臺機器上可能開著幾百個進程數(shù)據(jù)包到了網(wǎng)卡操作系統(tǒng)怎么知道該交給誰答案就是端口。源端口和目的端口各 16 位加起來 65535 個可用端口0 保留這就是傳輸層最基礎(chǔ)的一塊磚。第二個是服務(wù)質(zhì)量。要不要保證送達要不要保證順序要不要控制速度這些問題的答案就拉開了 UDP 和 TCP 的分野。我習(xí)慣用兩個生活場景來類比講了無數(shù)遍效果最好UDP 像是往對方信箱里塞明信片塞進去就完事對方收沒收到、幾張、順序?qū)Σ粚募艘桓挪还艿俣瓤?、成本低、想寄幾張寄幾張TCP 像是打電話先要撥通握手說話要對方嗯一聲確認對方?jīng)]聲了你要重說重傳對方聽不過來你要放慢流控掛電話前還要互相道別揮手。這個類比能解釋絕大部分現(xiàn)象。比如為什么 DNS 默認用 UDP因為一次查詢就一問一答包很小丟了重發(fā)一次成本極低為它建立連接反而是浪費。為什么文件下載用 TCP因為少一個字節(jié)文件就廢了必須保證完整和有序。1.2 一條流水線對比一張明信片核心差異的全景圖把差異鋪開成表格看得最清楚。這張表我建議你手抄一遍面試和排障時腦子里能直接調(diào)出來。維度TCPUDP連接面向連接三次握手建立四次揮手釋放無連接發(fā)了就發(fā)可靠性確認、重傳、排序、去重保證不丟不亂不保證送達不保證順序不保證不重復(fù)數(shù)據(jù)形態(tài)字節(jié)流無消息邊界數(shù)據(jù)報保留邊界一次發(fā)一次收頭部開銷20 字節(jié)起步帶選項可到 60 字節(jié)固定 8 字節(jié)傳輸方式支持全雙工有發(fā)送/接收緩沖區(qū)無緩沖概念直接交給 IP 層流量與擁塞控制有滑動窗口 擁塞控制四階段沒有應(yīng)用自己控制節(jié)奏廣播/組播不支持支持典型場景HTTP、數(shù)據(jù)庫、消息隊列、文件傳輸DNS、音視頻、游戲同步、日志上報、DHCP這張表里有個細節(jié)經(jīng)常被講錯UDP 不是不可靠協(xié)議而是不提供可靠性保證的協(xié)議。它只是不做不是做不到。你完全可以在 UDP 上面自己實現(xiàn)確認、重傳、排序——QUIC 就是這么干的在 UDP 之上重建了一套可靠傳輸還順手解決了 TCP 的隊頭阻塞問題。所以選型時不要被UDP 不可靠這句話嚇住要問的是我需要的那部分可靠性自己實現(xiàn)劃算還是直接用 TCP 劃算。還有一個常被忽略的點TCP 的字節(jié)流特性意味著它不保留應(yīng)用層消息邊界。你發(fā)兩次 100 字節(jié)對方可能一次 read 到 200 字節(jié)也可能分三次 read 到 30/70/100。這就是所謂粘包問題的根源——它根本不是 TCP 的 bug而是你把流當成了包來用。UDP 反而天然保留邊界一次 sendto 對應(yīng)一次 recvfrom代價是單包有大小限制理論上 65507 字節(jié)實際受 MTU 限制。2. 報文頭逐字節(jié)拆解字段設(shè)計背后的取舍2.1 UDP 頭部8 字節(jié)里藏著什么UDP 頭部只有 4 個字段各 16 位一共 8 字節(jié)簡潔到近乎粗暴0 7 8 15 16 23 24 31 -------------------------------- | 源端口號 | 目的端口號 | -------------------------------- | 長度 | 校驗和 | -------------------------------- | 數(shù)據(jù) ... | -----------------------------------長度字段指的是頭部 數(shù)據(jù)的總長度最小值是 8只有頭沒有數(shù)據(jù)最大值 65535。注意因為這個字段只有 16 位UDP 單個數(shù)據(jù)報的理論上限就是 65535 減去 IP 頭20再減去 UDP 頭8即 65507 字節(jié)。但這是理論值實際跑在以太網(wǎng)上MTU 是 1500IP 頭占 20UDP 頭占 8你能塞進單個不分片數(shù)據(jù)報的載荷只有 1472 字節(jié)。校驗和字段是最容易被忽略的。它覆蓋的不只是 UDP 頭和載荷還包括一個 12 字節(jié)的偽首部——源 IP、目的 IP、協(xié)議號、UDP 長度。為什么要拉上 IP 地址一起算因為要防止包被錯誤地投遞到別的主機上而沒被發(fā)現(xiàn)。這個偽首部只參與計算不實際傳輸。這里有個坑一定要記住IPv4 下 UDP 校驗和是可選的發(fā)送方算出來如果是 0要寫成全 10xFFFF如果壓根不想算填全 0接收方看到全 0 就跳過校驗。IPv6 下則是強制的。我見過真實案例某中間設(shè)備重算校驗和時出了 bug把本該是 0 的結(jié)果寫成了 0x0000接收端直接判定未計算校驗和而放行一個損壞的包被業(yè)務(wù)當成正常數(shù)據(jù)處理排查了兩天才找到。2.2 TCP 頭部20 字節(jié)起步的代價與控制力TCP 頭部最少 20 字節(jié)帶選項最多 60 字節(jié)。多出來的每一個字節(jié)都是在為可靠性、流量控制、擁塞控制買單。0 7 8 15 16 23 24 31 -------------------------------- | 源端口號 | 目的端口號 | -------------------------------- | 序號 (seq) | ----------------------------------- | 確認號 (ack) | -------------------------------- |偏移|保留 | 標志位 | 窗口大小 | -------------------------------- | 校驗和 | 緊急指針 | --------------------------------- | 選項可選 | -----------------------------------序號和確認號各 32 位是整個 TCP 可靠性的基石第 4 章會細講。數(shù)據(jù)偏移占 4 位單位是 4 字節(jié)所以它能表示的最大頭部長度是 15 × 4 60 字節(jié)——這也是 TCP 頭部上限的由來。窗口大小16 位最大 65535 字節(jié)這在高帶寬高延遲鏈路上遠遠不夠BDP 一算就知道所以有了窗口擴大因子Window Scale選項移位最大 14 位理論上窗口上限能到 2^30 字節(jié)左右約 1GB。標志位里SYN、ACK、FIN、RST 四個是日常打交道最多的SYN 建連、ACK 確認、FIN 正常關(guān)閉、RST 強制重置。PSH 提示接收方盡快把數(shù)據(jù)交給應(yīng)用URG 配合緊急指針現(xiàn)代實現(xiàn)基本不用了CWR 和 ECE 服務(wù)于顯式擁塞通知ECN。RST 這個位值得單獨說它表示這個連接我不認了立即終止。收到 RST 時緩沖區(qū)里未發(fā)送的數(shù)據(jù)會被直接丟棄這也是為什么長連接遇到中間設(shè)備超時后業(yè)務(wù)側(cè)經(jīng)?？吹秸埱蟀l(fā)出去了但沒響應(yīng)然后連接斷了。2.3 端口與校驗和兩個容易被忽略的細節(jié)端口這塊日常開發(fā)最容易踩的是端口耗盡。一個 TCP 連接由四元組唯一確定源 IP、源端口、目的 IP、目的端口。作為客戶端去連同一個目標源 IP 和目的端口固定能變的只有源端口Linux 默認的本地端口范圍是 32768–60999不到 3 萬個。如果業(yè)務(wù)大量短連接、又沒開SO_REUSEADDR、TIME_WAIT 堆積就可能出現(xiàn)Cannot assign requested address的報錯。這時候調(diào)大net.ipv4.ip_local_port_range到1024 65535、減少 TIME_WAIT 占用比優(yōu)化業(yè)務(wù)代碼見效快得多。校驗和這塊TCP 和 UDP 一樣帶偽首部一樣覆蓋頭部和數(shù)據(jù)。區(qū)別在于 TCP 校驗和是強制的沒有跳過這個選項。另外現(xiàn)代網(wǎng)卡普遍支持校驗和卸載Checksum Offload你在本機抓包看到的校驗和可能是錯的因為網(wǎng)卡還沒算——別急著以為是協(xié)議棧 bug先確認是不是卸載導(dǎo)致的假象。這個坑我踩過一次當時以為內(nèi)核有問題折騰了半天最后ethtool -K eth0 tx off關(guān)掉卸載才看到正確值。3. TCP 的連接管理三次握手、四次揮手與狀態(tài)機3.1 三次握手為什么是三次握手過程本身很好記客戶端 服務(wù)端 | ---- SYN, seqx ----------- | 客戶端進 SYN_SENT | --- SYNACK, seqy,ackx1 | 服務(wù)端進 SYN_RCVD | ---- ACK, acky1 --------- | 雙方進 ESTABLISHED關(guān)鍵問題是為什么不能兩次為什么不能四次兩次握手的問題在于服務(wù)端無法確認客戶端收到了我的 SYN-ACK。如果客戶端發(fā)了一個 SYN因為網(wǎng)絡(luò)延遲很久之后才到達服務(wù)端客戶端早就超時放棄了服務(wù)端兩次握手就建立連接然后傻等一個永遠不會來的數(shù)據(jù)資源白白占著。三次握手讓服務(wù)端在收到第三個 ACK 之后才確認對方真的還在、真的收到了我的回應(yīng)這才算雙向確認。從信息論角度看雙方各自需要確認兩件事我的發(fā)送能力對方能收到、對方的發(fā)送能力我能收到?？蛻舳送ㄟ^ SYN-ACK 確認了這兩點服務(wù)端只有收到第三個 ACK才能確認這兩點。兩個方向各需要一次交互交叉起來最少就是三次。四次當然也行把 SYNACK 拆成兩個包但純屬浪費。序號的選擇也有講究。初始序號 ISN 不是從 0 或 1 開始的而是隨機化的。早期實現(xiàn)用時鐘驅(qū)動現(xiàn)在RFC 6528一般用源 IP、目的 IP、源端口、目的端口四元組加上一個密鑰做哈希。為什么要隨機防止攻擊者預(yù)測序號后偽造報文注入數(shù)據(jù)也防止同一四元組的歷史連接殘包被誤認為當前連接的數(shù)據(jù)。有個實操細節(jié)服務(wù)端在 SYN_RCVD 狀態(tài)時會把這個半連接放進半連接隊列syn queue等第三個 ACK 到了才移進全連接隊列accept queue。如果應(yīng)用層 accept 太慢全連接隊列滿了新完成的連接會被丟掉或者回 RST客戶端看到的就是握手成功了但立刻斷開。隊列長度由net.core.somaxconn和 listen 的 backlog 參數(shù)共同決定默認值往往偏小高并發(fā)服務(wù)記得調(diào)。另一個相關(guān)參數(shù)是net.ipv4.tcp_max_syn_backlog半連接隊列滿了會觸發(fā) SYN cookie 機制。3.2 四次揮手與 TIME_WAIT 的真實困擾關(guān)閉比建立復(fù)雜因為 TCP 是全雙工的兩個方向要各自關(guān)閉主動關(guān)閉方 被動關(guān)閉方 | ---- FIN, sequ ------------ | 被動方進 CLOSE_WAIT | --- ACK, acku1 ----------- | | --- FIN, seqw, acku1 ---- | 被動方進 LAST_ACK | ---- ACK, ackw1 ---------- | 被動方進 CLOSED | 主動方進 TIME_WAIT等 2MSL |為什么是四次因為 FIN 只表示我沒有數(shù)據(jù)要發(fā)了不代表我不能再收。被動方收到 FIN 后可以先回 ACK然后繼續(xù)把剩下的數(shù)據(jù)發(fā)完發(fā)完了再發(fā)自己的 FIN。這兩件事不能合并成一個包所以是四次。當然如果被動方此時也沒有數(shù)據(jù)要發(fā)FIN 和 ACK 可以合并實際抓包里經(jīng)?？吹饺尉徒Y(jié)束。TIME_WAIT 是投訴率最高的一個狀態(tài)。主動關(guān)閉方在發(fā)完最后一個 ACK 后要等 2MSL 才能徹底關(guān)閉Linux 上 MSL 固定為 60 秒所以 TIME_WAIT 持續(xù) 60 秒。它存在的理由有兩個一是保證最后的 ACK 能到達對方如果 ACK 丟了對方會重發(fā) FIN此時自己還能回一次 ACK二是讓這條連接上所有迷路的舊報文在網(wǎng)絡(luò)中消亡避免污染下一個同四元組的新連接。代價是高并發(fā)的短連接服務(wù)主動關(guān)閉方會積累海量 TIME_WAIT占滿本地端口。標準解法有幾個讓服務(wù)端主動關(guān)閉服務(wù)端端口固定不受本地端口限制影響用連接池復(fù)用長連接開啟net.ipv4.tcp_tw_reuse1注意它只對出向連接生效而且依賴時間戳tcp_max_tw_buckets調(diào)大但要謹慎超限會打日志并直接銷毀。tcp_tw_recycle千萬不要開它在 NAT 環(huán)境下會導(dǎo)致大量連接失敗新內(nèi)核已經(jīng)把它移除了。比 TIME_WAIT 更值得警惕的是CLOSE_WAIT 堆積。大量連接卡在 CLOSE_WAIT說明對端已經(jīng)發(fā)了 FIN而你的應(yīng)用沒有調(diào)用 close() 釋放 socket。這是純粹的代碼問題可能是業(yè)務(wù)邏輯里 return 提前了沒走 finally可能是線程池耗盡導(dǎo)致回調(diào)沒執(zhí)行也可能是用了連接池但歸還邏輯有 bug?？吹?CLOSE_WAIT 數(shù)量只增不減別調(diào)內(nèi)核參數(shù)去查代碼。3.3 狀態(tài)機速查與抓包識別TCP 一共 11 個狀態(tài)日常排查其實只需要認出幾個關(guān)鍵的狀態(tài)出現(xiàn)位置含義與常見問題LISTEN服務(wù)端正常監(jiān)聽數(shù)量異常多說明服務(wù)開得太多SYN_SENT客戶端發(fā)了 SYN 沒收到回應(yīng)通常是網(wǎng)絡(luò)不通或被防火墻丟包SYN_RCVD服務(wù)端半連接大量堆積可能是 SYN Flood 或 backlog 太小ESTABLISHED雙方連接已建立數(shù)量持續(xù)增長要警惕連接泄漏FIN_WAIT_1主動關(guān)閉方發(fā)了 FIN 還沒收到 ACKFIN_WAIT_2主動關(guān)閉方收到 ACK 但對方還沒發(fā) FIN長期卡住說明對端應(yīng)用沒關(guān)連接TIME_WAIT主動關(guān)閉方正常等 2MSLCLOSE_WAIT被動關(guān)閉方應(yīng)用沒調(diào) close()堆積就是代碼 bugLAST_ACK被動關(guān)閉方發(fā)了 FIN 等最后 ACK一般很快消失用ss -tan state time-wait | wc -l這類命令能快速統(tǒng)計各狀態(tài)數(shù)量ss -tanp還能看到對應(yīng)進程。抓包時狀態(tài)轉(zhuǎn)換在報文里一目了然看到SYN就是建連開始看到RST, ACK就是異常終止看到FIN, ACK就是正常關(guān)閉。有個小技巧抓包文件里篩選tcp.flags.reset 1能一次性把所有異常重置的連接撈出來排障效率極高。4. 可靠性是怎么堆出來的序號、確認、重傳與滑動窗口4.1 序號與確認號的計算TCP 把應(yīng)用層交下來的字節(jié)流當成一個連續(xù)的字節(jié)序列每個字節(jié)都有一個編號。序號字段填的是本報文段第一個數(shù)據(jù)字節(jié)的編號。確認號填的是我期待收到的下一個字節(jié)編號也就是這個編號之前的所有字節(jié)我都收到了。舉個具體例子。客戶端要發(fā) 3000 字節(jié)MSS 是 1000假設(shè)那么會切成三個段第一段seq1000ISN1長度 1000攜帶字節(jié) 1000–1999第二段seq2000長度 1000攜帶字節(jié) 2000–2999第三段seq3000長度 1000攜帶字節(jié) 3000–3999服務(wù)端收到第一段后回ack2000含義是1999 及之前的我都收到了下一個我要 2000。如果第一段和第二段都到了但第三段丟了服務(wù)端會回ack3000而不是 4000明確告訴發(fā)送方我只到 2999。這里有兩個容易搞混的點。第一SYN 和 FIN 各消耗一個序號所以握手時seqx的 SYN對方回ackx1關(guān)閉時 FIN 也一樣。第二純 ACK 報文不消耗序號也不攜帶數(shù)據(jù)它只是確認。抓包時看到Seq1, Ack1, Len0這種就是純確認包。序號字段只有 32 位超過 4GB 會回繞。如果鏈路兩端對回繞的處理不一致就會出現(xiàn)序號跳變的詭異問題?，F(xiàn)代內(nèi)核用 PAWSProtection Against Wrapped Sequences機制配合時間戳選項來判斷基本能自動處理但如果你在自研協(xié)議棧或者做中間件這塊必須特別注意。4.2 超時重傳與快速重傳發(fā)出去的段沒收到確認怎么辦重傳。但多久沒收到就重傳這個時間RTO不能拍腦袋定定短了會瘋狂重傳加劇擁塞定長了恢復(fù)慢。TCP 的做法是動態(tài)估算第一次測量SRTT R, RTTVAR R/2 后續(xù)測量 RTTVAR (1-β) × RTTVAR β × |SRTT - R| SRTT (1-α) × SRTT α × R RTO SRTT 4 × RTTVAR其中 α 1/8β 1/4。這個公式的意思是維護一個平滑的往返時間 SRTT 和一個偏差估計 RTTVARRTO 取平滑值 4 倍偏差這樣在鏈路抖動時能自動放寬。Linux 上 RTO 有下限通常 200ms和上限通常 120 秒初始值一般是 1 秒。但等超時太慢了。TCP 還有一條更快的路徑快速重傳。如果發(fā)送方連續(xù)收到 3 個重復(fù)的 ACK說明某個段丟了后面的段都到了就立刻重傳丟失的段不用等 RTO 到期。配合 **SACK選擇性確認**選項接收方還能告訴發(fā)送方我收到了哪些不連續(xù)的段發(fā)送方就只用重傳真正缺的那幾段而不是把后面全重傳一遍。這里有個參數(shù)值得記net.ipv4.tcp_sack默認開啟不要關(guān)。我見過有人為了省流量關(guān)掉 SACK結(jié)果丟包率一高重傳量翻了三四倍帶寬反而被吃滿。實際排查中如果你在抓包文件里看到連續(xù)多個[TCP Dup ACK]緊接著一個[TCP Retransmission]那就是標準的快速重傳現(xiàn)場。如果看到的是[TCP Retransmission]前面沒有任何 Dup ACK那就是超時重傳說明丟包發(fā)現(xiàn)得晚延遲會明顯變高。4.3 滑動窗口與流量控制重傳解決丟了補上滑動窗口解決別發(fā)太快把對方撐爆。接收方在每次 ACK 里帶上自己的接收窗口rwnd含義是我當前緩沖區(qū)還能接這么多字節(jié)。發(fā)送方維護一個發(fā)送窗口窗口內(nèi)的數(shù)據(jù)可以連續(xù)發(fā)出去不用等確認窗口左邊界隨著 ACK 前移。這就是滑動的含義。窗口大小直接決定吞吐量上限。公式很簡單吞吐量上限 窗口大小 / RTT假設(shè)窗口 64KBRTT 40ms那單連接吞吐上限就是 65536 / 0.04 ≈ 1.6 MB/s約 13 Mbps。這就是為什么跨地域傳輸大文件時單條 TCP 連接怎么都跑不滿帶寬——不是帶寬不夠是窗口太小、RTT 太大。解決辦法是開窗口擴大因子或者多開幾條連接并行。窗口縮到 0 時發(fā)送方會停止發(fā)送并啟動零窗口探測定期發(fā)一個小包問現(xiàn)在能收了嗎。如果接收方應(yīng)用一直不 read 數(shù)據(jù)緩沖區(qū)滿了就會一直零窗口發(fā)送方就一直等著——這也是服務(wù)端不讀數(shù)據(jù)導(dǎo)致客戶端卡死這類問題的原理。用ss -tmi能看到每個連接的rwnd、cwnd、rtt等詳細指標排障時非常有用。4.4 擁塞控制從慢啟動到 CUBIC流量控制是照顧接收方擁塞控制是照顧整個網(wǎng)絡(luò)。發(fā)送方額外維護一個擁塞窗口cwnd實際能發(fā)的數(shù)據(jù)量取min(cwnd, rwnd)。擁塞控制分四個階段慢啟動連接剛建立時 cwnd 很小Linux 現(xiàn)代版本初始值是 10 個 MSSRFC 6928 之前的舊實現(xiàn)是 1-4 個每收到一個 ACK 就把 cwnd 加一個 MSS效果是指數(shù)增長——1、2、4、8、16一個 RTT 翻一倍。漲到慢啟動閾值ssthresh就切換。擁塞避免超過閾值后改成線性增長每個 RTT 大約加一個 MSS謹慎試探網(wǎng)絡(luò)容量。快速重傳與快速恢復(fù)收到 3 個重復(fù) ACK 時說明網(wǎng)絡(luò)還有余量后面的包能到把 ssthresh 設(shè)為當前 cwnd 的一半cwnd 也減半然后直接進入擁塞避免不用回到慢啟動從頭爬。超時重傳說明情況更嚴重直接把 cwnd 打回 1 個 MSS重新慢啟動。Linux 默認的擁塞控制算法是 CUBIC它的增長曲線是三次函數(shù)在高帶寬長距離鏈路上比傳統(tǒng)的 Reno 表現(xiàn)好很多。近些年 BBR 也很流行思路完全不同——它不靠丟包判斷擁塞而是測量帶寬和最小 RTT 來建模。切換算法很簡單# 查看當前算法和可用算法 sysctl net.ipv4.tcp_congestion_control sysctl net.ipv4.tcp_available_congestion_control # 臨時切換為 bbr sysctl -w net.ipv4.tcp_congestion_controlbbr我的經(jīng)驗是跨國或跨運營商的長肥鏈路高帶寬高延遲BBR 通常能帶來明顯的吞吐提升內(nèi)網(wǎng)短鏈路CUBIC 和 BBR 差異不大用默認的就行。切換前一定要在灰度環(huán)境壓測不要直接上生產(chǎn)。5. 實操用抓包和代碼把協(xié)議看見5.1 環(huán)境與工具準備紙上得來終覺淺協(xié)議這東西必須親手抓一次才算真懂。你需要的東西不多一臺 Linux 機器云主機或本地虛擬機都行、一個能跑 Python 的環(huán)境、抓包工具。命令行抓包我用tcpdump輕量、隨處可用圖形化分析用帶界面的抓包軟件看時序圖和流追蹤更直觀。安裝和基礎(chǔ)用法# 抓本機 8080 端口的 TCP 包不做域名解析直接寫文件 tcpdump -i any -nn -s 0 tcp port 8080 -w /tmp/tcp8080.pcap # 只看握手和揮手相關(guān)的標志位 tcpdump -i any -nn tcp port 8080 and (tcp[tcpflags] (tcp-syn|tcp-fin|tcp-rst) ! 0) # 實時看 UDP 53 端口DNS tcpdump -i any -nn udp port 53 -c 20幾個參數(shù)的含義值得記牢-i any抓所有網(wǎng)卡-nn不做 IP 和端口反解避免 DNS 查詢干擾抓包-s 0抓完整包老版本默認只抓 68 字節(jié)頭部以下會被截斷這個坑很多人踩過-w寫文件供后續(xù)分析。生產(chǎn)環(huán)境抓包注意加過濾條件并限制包數(shù)不然一個高流量服務(wù)幾分鐘就能抓出幾十 GB。5.2 TCP 三次握手抓包實錄啟動一個最簡單的服務(wù)端然后用 curl 連一下同時抓包。這是最經(jīng)典的一組報文值得反復(fù)看No. Time Source Destination Info 1 0.000000 10.0.0.5 10.0.0.9 54321 → 8080 [SYN] Seq0 Win64240 Len0 MSS1460 SACK_PERM TSval... 2 0.000312 10.0.0.9 10.0.0.5 8080 → 54321 [SYN, ACK] Seq0 Ack1 Win65160 Len0 MSS1460 SACK_PERM TSval... 3 0.000398 10.0.0.5 10.0.0.9 54321 → 8080 [ACK] Seq1 Ack1 Win64240 Len0 4 0.000521 10.0.0.5 10.0.0.9 54321 → 8080 [PSH, ACK] Seq1 Ack1 Len78對著看幾點第 1 個包Seq0是抓包工具顯示的相對序號真實 ISN 是隨機的工具做了偏移處理方便閱讀。MSS1460是客戶端告訴服務(wù)端我這邊最多能收 1460 字節(jié)的 TCP 載荷——這是 MTU 1500 減去 IP 頭 20 再減去 TCP 頭 20 得到的。SACK_PERM表示支持選擇性確認。Win64240是接收窗口。TSval是時間戳選項用于更精確的 RTT 測量和防回繞。第 2 個包服務(wù)端的Ack1因為 SYN 消耗了一個序號。服務(wù)端也報了自己的 MSS 和窗口。注意 MSS 是雙向協(xié)商的各自報各自能接收的最大值實際發(fā)送時按較小的那個來。第 3 個包是純 ACKLen0沒有數(shù)據(jù)。這一步完成后雙方進入 ESTABLISHED。第 4 個包才是真正的業(yè)務(wù)數(shù)據(jù)PSH標志表示盡快交給應(yīng)用層。整個握手在 0.4 毫秒內(nèi)完成因為都在同一個局域網(wǎng)。如果是跨地域第 1 到第 3 個包之間的時間差就是一次 RTT這也是為什么TCP 建連本身就要消耗一個 RTT——HTTPS 還要再多花一兩個 RTT 做密鑰協(xié)商首屏慢的鍋有時候真不在業(yè)務(wù)代碼。你可以在抓包工具里看Statistics → TCP Stream Graphs → Time-Sequence能直觀看到每個包在時間軸上的分布、重傳在哪、窗口怎么變化。這張圖我排障時幾乎必看比肉眼數(shù)報文高效得多。5.3 UDP 與 TCP 的代碼對比寫兩段最小可運行的代碼把兩者行為差異看得最清楚。先看 TCP 服務(wù)端import socket # SOCK_STREAM 表示 TCP server socket.socket(socket.AF_INET, socket.SOCK_STREAM) # 允許端口復(fù)用避免重啟時報 Address already in use server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) # 關(guān)閉 Nagle 算法避免小包合并帶來的延遲 server.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1) server.bind((0.0.0.0, 8080)) server.listen(128) # backlog對應(yīng)全連接隊列長度 print(listening on 8080) while True: conn, addr server.accept() with conn: while True: data conn.recv(4096) # TCP 是字節(jié)流一次 recv 不保證一個完整消息 if not data: break # 對端關(guān)閉 conn.sendall(becho: data)再看 UDP 服務(wù)端import socket # SOCK_DGRAM 表示 UDP server socket.socket(socket.AF_INET, socket.SOCK_DGRAM) server.bind((0.0.0.0, 8081)) print(udp listening on 8081) while True: # 一次 recvfrom 對應(yīng)一個數(shù)據(jù)報天然保留消息邊界 data, addr server.recvfrom(65535) server.sendto(becho: data, addr)兩段代碼一對比差異全在細節(jié)里。TCP 多了accept()這一步說明它是有連接概念的recv()的返回值需要自己判斷消息邊界因為一個 4096 的緩沖區(qū)可能裝到半條消息加一條半消息sendall()和send()不同前者會循環(huán)直到發(fā)完后者只保證發(fā)了一部分。UDP 則完全不需要考慮這些一次recvfrom就是一個完整數(shù)據(jù)報但你得自己處理丟包和亂序?？蛻舳诉@邊UDP 還有個特殊行為值得注意如果你用connect()綁定了一個目標地址之后發(fā)往其他地址的包會被靜默丟棄同時能找到對方端口不可達的 ICMP 錯誤。不connect()的話一次性發(fā)送大包會頻繁觸發(fā)sendto返回EMSGSIZE因為載荷超過了單包上限。5.4 用系統(tǒng)命令觀察連接狀態(tài)抓包看報文系統(tǒng)命令看狀態(tài)兩者配合才完整。下面這幾條我基本天天在用# 按狀態(tài)統(tǒng)計當前連接數(shù)量 ss -tan | awk NR1 {print $1} | sort | uniq -c | sort -rn # 查看某個端口的連接詳情含內(nèi)存和定時器信息 ss -tmn sport :8080 # 查看 TCP 全局統(tǒng)計重傳率、握手失敗、隊列溢出都在這 netstat -s | grep -iE retrans|overflow|listen|reset # 查看內(nèi)核連接相關(guān)參數(shù) sysctl -a | grep -E somaxconn|tcp_max_syn|tcp_tw|tcp_keepalivenetstat -s里的listen overflows和listen drops兩個計數(shù)特別關(guān)鍵前者表示全連接隊列滿導(dǎo)致新連接被丟后者表示半連接隊列滿。這兩個值只要在持續(xù)增長就說明應(yīng)用 accept 不過來或者 backlog 配小了跟業(yè)務(wù)邏輯無關(guān)調(diào)參數(shù)就能解決。6. 選型決策什么場景該用哪個6.1 一張決策表背后的判斷邏輯選型不是站隊是權(quán)衡。我把常見場景整理成下面這張表附上判斷依據(jù)場景推薦判斷依據(jù)網(wǎng)頁請求、API 調(diào)用TCP需要完整、有序且請求量不極端數(shù)據(jù)庫連接TCP一個字節(jié)都不能錯長連接還能復(fù)用文件傳輸TCP完整性優(yōu)先順序錯亂無法處理DNS 查詢UDP大響應(yīng)回退 TCP一問一答包小重試成本低音視頻實時通話UDPRTP/RTCP寧可丟一幀也不要卡 200ms 等重傳游戲狀態(tài)同步UDP舊的位置數(shù)據(jù)沒有重傳價值新的覆蓋舊的日志、指標上報UDP 或批量 TCP少量丟失可接受優(yōu)先低開銷局域網(wǎng)服務(wù)發(fā)現(xiàn)UDP 廣播/組播TCP 不支持廣播物聯(lián)網(wǎng)低功耗上報UDP或輕量封裝建連開銷和功耗都難以承受判斷邏輯可以濃縮成三個問題按順序問自己第一丟了這一份數(shù)據(jù)業(yè)務(wù)能接受嗎能接受就用 UDP不能就用 TCP。注意是這一份不是任何一份——音視頻丟一幀沒事但控制信令丟了就有事所以很多實時系統(tǒng)是 UDP 傳媒體流、TCP或可靠 UDP傳信令的混合架構(gòu)。第二延遲敏感度有多高TCP 的隊頭阻塞是硬傷前面一個包丟了后面即使全到了也得在緩沖區(qū)里等著應(yīng)用層收不到。在弱網(wǎng)環(huán)境下這個等待可能是幾百毫秒。實時性要求高的場景這個代價通常不可接受。第三能不能承擔(dān)自己實現(xiàn)可靠性的成本基于 UDP 做可靠傳輸不是加個重傳就完事還要處理擁塞控制、RTT 估計、亂序重組、防放大攻擊等等工作量以人月計。除非你有明確的性能訴求否則別自己造。6.2 那些看起來該用 UDP 卻用了 TCP的案例選型最忌諱教條。我見過幾個反直覺但合理的例子值得說說。第一個是某些即時通訊的長連接。直覺上消息推送應(yīng)該快但實際主流方案走的都是 TCP 長連接。原因是消息必須到達可靠性權(quán)重遠高于延遲而 TCP 的連接狀態(tài)讓服務(wù)端能主動推送UDP 沒有連接概念NAT 穿透后還得自己維護會話再加上有心跳和重連機制兜底偶發(fā)的隊頭阻塞影響被攤薄了。第二個是短查詢類接口。有人覺得就查一條記錄一次往返用 UDP 省掉握手不是更快。理論上一問一答確實 UDP 少一個 RTT但實際收益微乎其微——因為現(xiàn)在普遍是長連接 連接復(fù)用握手成本早被攤銷掉了。而你需要自己處理丟包重試、請求 ID 匹配、超時判定代碼復(fù)雜度翻倍收益卻是零點幾毫秒。這筆賬怎么算都不劃算。第三個是內(nèi)網(wǎng)的 RPC。某些高性能 RPC 框架在延遲敏感場景下會提供 UDP 模式但默認還是 TCP。原因還是那個內(nèi)網(wǎng)丟包率極低萬分之一以下TCP 的隊頭阻塞幾乎不發(fā)生而 UDP 省下的那點開銷在整體鏈路里占比很小。反過來也有看起來該用 TCP 卻用了 UDP的日志采集。某系統(tǒng)每秒產(chǎn)生幾十萬條日志如果每條都建 TCP 連接光握手就把 CPU 打滿了。改成 UDP 批量發(fā)送允許在極端情況下丟少量日志——因為日志的價值是統(tǒng)計趨勢不是逐條審計丟 0.1% 完全不影響結(jié)論。這個決策的關(guān)鍵在于明確業(yè)務(wù)對數(shù)據(jù)完整性的真實要求而不是籠統(tǒng)地說日志很重要所以不能丟。6.3 在 UDP 上重建可靠性要補哪些課如果你確實決定走 UDP 自建可靠傳輸至少要補齊這幾塊缺一不可。序號與重組。每個數(shù)據(jù)報帶一個遞增序號接收端按序號排序、去重、檢測空洞。要注意序號回繞的處理以及亂序窗口的大小——窗口太小會誤判丟包太大內(nèi)存扛不住。確認與重傳?？梢灾鸢?ACK也可以累積 ACK 加選擇性確認。重傳要配合 RTO 估算公式可以直接抄 TCP 的 SRTT 4×RTTVAR。別忘了重傳次數(shù)上限否則網(wǎng)絡(luò)徹底斷了會無限重試。擁塞控制。這是最容易被跳過、也最容易出事的一塊。沒有擁塞控制你的協(xié)議在丟包時會繼續(xù)猛發(fā)把整條鏈路和其他流量一起拖死。哪怕只做一個簡化版的 AIMD加性增、乘性減也比沒有強。分片與 MTU。UDP 超過 MTU 會觸發(fā) IP 分片任何一個分片丟失整個數(shù)據(jù)報就廢了重傳成本極高。正確做法是在應(yīng)用層做分片單包載荷控制在 1200 字節(jié)以內(nèi)給 IPv6 和隧道封裝留余量這也是 QUIC 選 1200 的原因。安全。裸 UDP 極易被用于反射放大攻擊——攻擊者偽造源 IP 發(fā)一個小請求你回一個大響應(yīng)受害者就被淹了。所以必須做源地址驗證比如要求客戶端先回一個隨機 token并且限制響應(yīng)與請求的大小比例。QUIC 把這套東西完整實現(xiàn)了一遍還順帶把握手和加密合并0-RTT 或 1-RTT 建連并在應(yīng)用層解決了隊頭阻塞。如果你想理解可靠 UDP到底該長什么樣去讀 QUIC 的協(xié)議文檔是最快的路徑。6.4 MTU、粘包、心跳三個繞不開的工程細節(jié)MTU 與分片。以太網(wǎng)默認 MTU 1500這是歷史遺留值。路徑上任何一跳的 MTU 更小都會導(dǎo)致分片或丟棄而路徑 MTU 發(fā)現(xiàn)PMTUD依賴 ICMP很多防火墻把 ICMP 全禁了于是出現(xiàn)小包能通、大包不通的經(jīng)典故障。經(jīng)驗值TCP 的 MSS 協(xié)商后一般是 1460IPv4或 1440IPv6UDP 應(yīng)用層載荷控制在 1200 以內(nèi)最穩(wěn)。如果你在容器或隧道環(huán)境里MTU 還要減去封裝開銷比如某些隧道要減 60–80 字節(jié)。粘包。前面說過這是把流當包用造成的。解決方式就三種定長消息、分隔符如換行、\r\n、長度前綴先發(fā) 4 字節(jié)長度再發(fā)內(nèi)容。工程上最推薦長度前綴解析簡單、無轉(zhuǎn)義問題、二進制安全。千萬不要用每次 recv 正好是一條消息這種假設(shè)寫代碼它在你本機測試時永遠是對的一上線就出問題。心跳。TCP 自帶 keepalive但默認空閑 7200 秒才探測太長了而且只能探測連接是否還活著探測不到對端進程假死。所以業(yè)務(wù)層必須自己做心跳客戶端每 30 秒發(fā)一次 ping服務(wù)端回 pong連續(xù) 3 次沒收到就判定斷線重連。心跳間隔要比中間設(shè)備負載均衡、NAT 網(wǎng)關(guān)的連接空閑超時短常見設(shè)備超時是 60 秒或 300 秒心跳間隔取 30 秒比較安全。7. 常見問題與排查實錄7.1 高頻問題速查表下面這張表是我這些年攢下來的遇到問題先對照它能省掉一大半瞎猜的時間。現(xiàn)象可能原因排查手段偶發(fā)多出 40ms 延遲Nagle 算法與延遲 ACK 疊加抓包看是否有小包等待開 TCP_NODELAY大量 CLOSE_WAIT應(yīng)用沒調(diào)用 close()ss -tan state close-wait查代碼釋放路徑大量 TIME_WAIT短連接多、主動關(guān)閉方在本地改連接池、調(diào)整端口范圍、tcp_tw_reuse連接不上報 Address already in use端口被占或 TIME_WAIT 未復(fù)用開 SO_REUSEADDRss -tanp查占用小包能通大包不通MTU 不匹配、ICMP 被攔ping -M do -s 1472逐段探測間歇性 connection reset中間設(shè)備超時、服務(wù)端 backlog 滿看netstat -s的 overflow 計數(shù)傳輸吞吐上不去窗口太小或 RTT 太大ss -tmi看 cwnd/rwnd考慮開窗口擴大UDP 偶發(fā)丟包無報錯緩沖區(qū)和 MTU 問題調(diào)rmem_max控制載荷在 1200 內(nèi)服務(wù)端 ESTABLISHED 很多但業(yè)務(wù)超時隊頭阻塞、線程池打滿看 recv-q/send-qss -tmn觀察隊列7.2 一次典型的排障路徑說個真實經(jīng)歷的變形版。某服務(wù)每天有幾個時段出現(xiàn)請求偶發(fā)超時超時率約 2%重試一次就好監(jiān)控上看不出明顯規(guī)律。第一步先確定問題在哪一層。在客戶端和服務(wù)端同時抓包對比兩端看到的報文。結(jié)果發(fā)現(xiàn)客戶端發(fā)了請求服務(wù)端過了 800ms 才收到——說明問題在中間鏈路不在應(yīng)用。第二步看 TCP 層的行為。抓包里出現(xiàn)了零星的[TCP Retransmission]重傳間隔正好是 200ms 左右符合最小 RTO。說明有丟包但丟包率很低。第三步看丟在哪里。用mtr做路徑探測發(fā)現(xiàn)某一跳有 1%–2% 的丟包。再和運維確認那臺設(shè)備負載偏高在跑大流量轉(zhuǎn)發(fā)。第四步驗證假設(shè)。把請求大小從 8KB 降到 2KB 以內(nèi)減少分片和占用時間超時率下降到 0.3%。最終通過擴容那臺設(shè)備、同時把服務(wù)端的tcp_slow_start_after_idle關(guān)掉避免空閑后重新慢啟動問題徹底消失。這條路子的核心方法論是分層定位逐層收斂。先確定是應(yīng)用層、傳輸層還是網(wǎng)絡(luò)層的問題再往下一層層縮小范圍。最忌諱的是一上來就懷疑業(yè)務(wù)代碼改半天沒效果最后還是抓包解決了。7.3 幾個只有踩過才知道的坑坑一關(guān)掉 TCP_NODELAY 以為能省流量結(jié)果延遲爆炸。Nagle 算法會把小包攢起來一起發(fā)配合接收方的延遲 ACK最多等 200ms在高頻小包場景下會出現(xiàn)每個請求卡 40ms的詭異現(xiàn)象。這個現(xiàn)象在本地測試環(huán)境幾乎復(fù)現(xiàn)不出來因為本機 RTT 極低Nagle 攢不到包就發(fā)出去了。IO 密集型的 RPC、實時消息推送一律開TCP_NODELAY?？佣詾?UDP 的緩沖區(qū)跟 TCP 一樣能自動背壓。TCP 緩沖區(qū)滿了會阻塞發(fā)送方天然形成背壓UDP 緩沖區(qū)滿了內(nèi)核直接把包丟掉發(fā)送方毫不知情。如果你的 UDP 接收端處理慢就會出現(xiàn)明明發(fā)了 10000 條只收到 8000 條且毫無報錯。解決辦法是調(diào)大net.core.rmem_max并在應(yīng)用層做隊列水位監(jiān)控?？尤齌IME_WAIT 數(shù)量高就無腦開tcp_tw_recycle。這個參數(shù)在 NAT 環(huán)境下的行為會導(dǎo)致大量正常連接被拒表現(xiàn)為同一出口 IP 的多個客戶端只有部分能連上。較新的內(nèi)核已經(jīng)移除該參數(shù)老系統(tǒng)上如果開了建議立刻關(guān)掉?？铀陌?keepalive 當成心跳用。系統(tǒng)級 keepalive 只能探測對端主機是否可達對端進程崩了但主機還在keepalive 是探不出來的除非進程退出導(dǎo)致內(nèi)核發(fā)了 FIN。真正的存活檢測必須靠應(yīng)用層心跳而且要帶業(yè)務(wù)語義能反映服務(wù)真的能處理請求?？游迦萜鳝h(huán)境下忽略 MTU。容器網(wǎng)絡(luò)通常有 VXLAN 等封裝實際可用 MTU 會比宿主機的 1500 小常見 1450 甚至 1400。如果應(yīng)用不感知這件事大包會被丟棄且現(xiàn)象極其隱蔽小請求都正常一傳大文件就卡死。部署到容器集群時務(wù)必確認 Pod 內(nèi)的ip link顯示的實際 MTU并據(jù)此調(diào)整應(yīng)用層的包大小。我個人在實際操作中的體會是UDP 和 TCP 這兩塊知識光看文檔永遠學(xué)不透必須抓一次包 寫一次代碼 排一次障三件套都走一遍腦子里才會長出真正的模型。我自己是被一次線上 RST 風(fēng)暴逼著把 RFC 從頭翻了一遍那之后再看框架的日志、再看監(jiān)控的曲線很多以前覺得莫名其妙的東西突然就對上了。如果你現(xiàn)在手上的系統(tǒng)有偶發(fā)超時、有說不清的重傳、有莫名的連接數(shù)增長別急著調(diào)參數(shù)先抓個包答案八成寫在報文里。 TCP/UDP協(xié)議全解：握手、重傳、抓包與選型排障
凌晨兩點被告警電話叫起來某服務(wù)的接口超時率十幾分鐘內(nèi)從 0.3% 飆到 30%日志里刷屏connection reset by peer抓包一看滿屏 RST 和大量重傳最后定位到一個中間設(shè)備的空閑連接超時策略和業(yè)務(wù)的長連接心跳沒對齊。這種場面只要做過線上服務(wù)遲早會碰上一兩次。而每一次追到最底層你都會撞上同一個東西計算機網(wǎng)絡(luò)里的UDP / TCP 協(xié)議。這兩個協(xié)議是所有上層玩意的地基。上面架著 HTTP、gRPC、DNS、數(shù)據(jù)庫連接、消息隊列、音視頻推流、游戲同步、物聯(lián)網(wǎng)上報下面踩著 IP 層的盡力而為。框架再花哨、網(wǎng)關(guān)再智能、SDK 封裝再厚落到網(wǎng)線上跑的無非就是這兩種傳輸層協(xié)議之一。我見過不少寫了三四年業(yè)務(wù)的同學(xué)能把框架的線程模型講得頭頭是道但一問他為什么這個接口偶爾會多出 40 毫秒延遲為什么這條消息偶發(fā)丟了沒報錯為什么服務(wù)端 ESTABLISHED 一堆但業(yè)務(wù)就是不通就答不上來了。原因很簡單這些問題不在框架層在傳輸層。這篇內(nèi)容我想把它寫成一個完整的、可以拿來當手冊用的東西從兩個協(xié)議的報文頭逐字節(jié)拆到 TCP 的連接管理和可靠性機制怎么堆出來的再到用抓包和代碼把協(xié)議看見最后是選型決策和線上排障實錄。寫的過程中我會把參數(shù)的計算過程、我踩過的坑、以及那些文檔里不會寫的經(jīng)驗都放進去。適合誰看寫后端業(yè)務(wù)服務(wù)、做客戶端和嵌入式、搞音視頻或?qū)崟r同步、以及在準備技術(shù)面試的同學(xué)都能從中拿到東西。基礎(chǔ)弱的可以先把第 1、2 章讀透把是什么釘死有經(jīng)驗的可以直接跳到第 4、5、7 章那里全是我在實踐中反復(fù)驗證過的細節(jié)。代碼示例我統(tǒng)一用 Python 寫因為它最接近偽代碼你換成 Go、Java、C 都能一一對應(yīng)。1. 先把兩個協(xié)議擺到臺面上它們到底在解決什么問題1.1 從一次發(fā)消息說起傳輸層到底負責(zé)什么任何一次網(wǎng)絡(luò)通信本質(zhì)上都是一臺機器上的某個進程把一段字節(jié)交給另一臺機器上的某個進程。IP 層只負責(zé)把數(shù)據(jù)包送到目標主機它不知道什么是進程也不保證送達、不保證順序、不保證不重復(fù)。傳輸層就是把 IP 層的這個盡力而為服務(wù)加工成應(yīng)用能直接用的東西。這里有兩個必須解決的問題UDP 和 TCP 各自給出了不同答案。第一個是進程尋址。一臺機器上可能開著幾百個進程數(shù)據(jù)包到了網(wǎng)卡操作系統(tǒng)怎么知道該交給誰答案就是端口。源端口和目的端口各 16 位加起來 65535 個可用端口0 保留這就是傳輸層最基礎(chǔ)的一塊磚。第二個是服務(wù)質(zhì)量。要不要保證送達要不要保證順序要不要控制速度這些問題的答案就拉開了 UDP 和 TCP 的分野。我習(xí)慣用兩個生活場景來類比講了無數(shù)遍效果最好UDP 像是往對方信箱里塞明信片塞進去就完事對方收沒收到、幾張、順序?qū)Σ粚募艘桓挪还艿俣瓤?、成本低、想寄幾張寄幾張TCP 像是打電話先要撥通握手說話要對方嗯一聲確認對方?jīng)]聲了你要重說重傳對方聽不過來你要放慢流控掛電話前還要互相道別揮手。這個類比能解釋絕大部分現(xiàn)象。比如為什么 DNS 默認用 UDP因為一次查詢就一問一答包很小丟了重發(fā)一次成本極低為它建立連接反而是浪費。為什么文件下載用 TCP因為少一個字節(jié)文件就廢了必須保證完整和有序。1.2 一條流水線對比一張明信片核心差異的全景圖把差異鋪開成表格看得最清楚。這張表我建議你手抄一遍面試和排障時腦子里能直接調(diào)出來。維度TCPUDP連接面向連接三次握手建立四次揮手釋放無連接發(fā)了就發(fā)可靠性確認、重傳、排序、去重保證不丟不亂不保證送達不保證順序不保證不重復(fù)數(shù)據(jù)形態(tài)字節(jié)流無消息邊界數(shù)據(jù)報保留邊界一次發(fā)一次收頭部開銷20 字節(jié)起步帶選項可到 60 字節(jié)固定 8 字節(jié)傳輸方式支持全雙工有發(fā)送/接收緩沖區(qū)無緩沖概念直接交給 IP 層流量與擁塞控制有滑動窗口 擁塞控制四階段沒有應(yīng)用自己控制節(jié)奏廣播/組播不支持支持典型場景HTTP、數(shù)據(jù)庫、消息隊列、文件傳輸DNS、音視頻、游戲同步、日志上報、DHCP這張表里有個細節(jié)經(jīng)常被講錯UDP 不是不可靠協(xié)議而是不提供可靠性保證的協(xié)議。它只是不做不是做不到。你完全可以在 UDP 上面自己實現(xiàn)確認、重傳、排序——QUIC 就是這么干的在 UDP 之上重建了一套可靠傳輸還順手解決了 TCP 的隊頭阻塞問題。所以選型時不要被UDP 不可靠這句話嚇住要問的是我需要的那部分可靠性自己實現(xiàn)劃算還是直接用 TCP 劃算。還有一個常被忽略的點TCP 的字節(jié)流特性意味著它不保留應(yīng)用層消息邊界。你發(fā)兩次 100 字節(jié)對方可能一次 read 到 200 字節(jié)也可能分三次 read 到 30/70/100。這就是所謂粘包問題的根源——它根本不是 TCP 的 bug而是你把流當成了包來用。UDP 反而天然保留邊界一次 sendto 對應(yīng)一次 recvfrom代價是單包有大小限制理論上 65507 字節(jié)實際受 MTU 限制。2. 報文頭逐字節(jié)拆解字段設(shè)計背后的取舍2.1 UDP 頭部8 字節(jié)里藏著什么UDP 頭部只有 4 個字段各 16 位一共 8 字節(jié)簡潔到近乎粗暴0 7 8 15 16 23 24 31 -------------------------------- | 源端口號 | 目的端口號 | -------------------------------- | 長度 | 校驗和 | -------------------------------- | 數(shù)據(jù) ... | -----------------------------------長度字段指的是頭部 數(shù)據(jù)的總長度最小值是 8只有頭沒有數(shù)據(jù)最大值 65535。注意因為這個字段只有 16 位UDP 單個數(shù)據(jù)報的理論上限就是 65535 減去 IP 頭20再減去 UDP 頭8即 65507 字節(jié)。但這是理論值實際跑在以太網(wǎng)上MTU 是 1500IP 頭占 20UDP 頭占 8你能塞進單個不分片數(shù)據(jù)報的載荷只有 1472 字節(jié)。校驗和字段是最容易被忽略的。它覆蓋的不只是 UDP 頭和載荷還包括一個 12 字節(jié)的偽首部——源 IP、目的 IP、協(xié)議號、UDP 長度。為什么要拉上 IP 地址一起算因為要防止包被錯誤地投遞到別的主機上而沒被發(fā)現(xiàn)。這個偽首部只參與計算不實際傳輸。這里有個坑一定要記住IPv4 下 UDP 校驗和是可選的發(fā)送方算出來如果是 0要寫成全 10xFFFF如果壓根不想算填全 0接收方看到全 0 就跳過校驗。IPv6 下則是強制的。我見過真實案例某中間設(shè)備重算校驗和時出了 bug把本該是 0 的結(jié)果寫成了 0x0000接收端直接判定未計算校驗和而放行一個損壞的包被業(yè)務(wù)當成正常數(shù)據(jù)處理排查了兩天才找到。2.2 TCP 頭部20 字節(jié)起步的代價與控制力TCP 頭部最少 20 字節(jié)帶選項最多 60 字節(jié)。多出來的每一個字節(jié)都是在為可靠性、流量控制、擁塞控制買單。0 7 8 15 16 23 24 31 -------------------------------- | 源端口號 | 目的端口號 | -------------------------------- | 序號 (seq) | ----------------------------------- | 確認號 (ack) | -------------------------------- |偏移|保留 | 標志位 | 窗口大小 | -------------------------------- | 校驗和 | 緊急指針 | --------------------------------- | 選項可選 | -----------------------------------序號和確認號各 32 位是整個 TCP 可靠性的基石第 4 章會細講。數(shù)據(jù)偏移占 4 位單位是 4 字節(jié)所以它能表示的最大頭部長度是 15 × 4 60 字節(jié)——這也是 TCP 頭部上限的由來。窗口大小16 位最大 65535 字節(jié)這在高帶寬高延遲鏈路上遠遠不夠BDP 一算就知道所以有了窗口擴大因子Window Scale選項移位最大 14 位理論上窗口上限能到 2^30 字節(jié)左右約 1GB。標志位里SYN、ACK、FIN、RST 四個是日常打交道最多的SYN 建連、ACK 確認、FIN 正常關(guān)閉、RST 強制重置。PSH 提示接收方盡快把數(shù)據(jù)交給應(yīng)用URG 配合緊急指針現(xiàn)代實現(xiàn)基本不用了CWR 和 ECE 服務(wù)于顯式擁塞通知ECN。RST 這個位值得單獨說它表示這個連接我不認了立即終止。收到 RST 時緩沖區(qū)里未發(fā)送的數(shù)據(jù)會被直接丟棄這也是為什么長連接遇到中間設(shè)備超時后業(yè)務(wù)側(cè)經(jīng)?？吹秸埱蟀l(fā)出去了但沒響應(yīng)然后連接斷了。2.3 端口與校驗和兩個容易被忽略的細節(jié)端口這塊日常開發(fā)最容易踩的是端口耗盡。一個 TCP 連接由四元組唯一確定源 IP、源端口、目的 IP、目的端口。作為客戶端去連同一個目標源 IP 和目的端口固定能變的只有源端口Linux 默認的本地端口范圍是 32768–60999不到 3 萬個。如果業(yè)務(wù)大量短連接、又沒開SO_REUSEADDR、TIME_WAIT 堆積就可能出現(xiàn)Cannot assign requested address的報錯。這時候調(diào)大net.ipv4.ip_local_port_range到1024 65535、減少 TIME_WAIT 占用比優(yōu)化業(yè)務(wù)代碼見效快得多。校驗和這塊TCP 和 UDP 一樣帶偽首部一樣覆蓋頭部和數(shù)據(jù)。區(qū)別在于 TCP 校驗和是強制的沒有跳過這個選項。另外現(xiàn)代網(wǎng)卡普遍支持校驗和卸載Checksum Offload你在本機抓包看到的校驗和可能是錯的因為網(wǎng)卡還沒算——別急著以為是協(xié)議棧 bug先確認是不是卸載導(dǎo)致的假象。這個坑我踩過一次當時以為內(nèi)核有問題折騰了半天最后ethtool -K eth0 tx off關(guān)掉卸載才看到正確值。3. TCP 的連接管理三次握手、四次揮手與狀態(tài)機3.1 三次握手為什么是三次握手過程本身很好記客戶端 服務(wù)端 | ---- SYN, seqx ----------- | 客戶端進 SYN_SENT | --- SYNACK, seqy,ackx1 | 服務(wù)端進 SYN_RCVD | ---- ACK, acky1 --------- | 雙方進 ESTABLISHED關(guān)鍵問題是為什么不能兩次為什么不能四次兩次握手的問題在于服務(wù)端無法確認客戶端收到了我的 SYN-ACK。如果客戶端發(fā)了一個 SYN因為網(wǎng)絡(luò)延遲很久之后才到達服務(wù)端客戶端早就超時放棄了服務(wù)端兩次握手就建立連接然后傻等一個永遠不會來的數(shù)據(jù)資源白白占著。三次握手讓服務(wù)端在收到第三個 ACK 之后才確認對方真的還在、真的收到了我的回應(yīng)這才算雙向確認。從信息論角度看雙方各自需要確認兩件事我的發(fā)送能力對方能收到、對方的發(fā)送能力我能收到?？蛻舳送ㄟ^ SYN-ACK 確認了這兩點服務(wù)端只有收到第三個 ACK才能確認這兩點。兩個方向各需要一次交互交叉起來最少就是三次。四次當然也行把 SYNACK 拆成兩個包但純屬浪費。序號的選擇也有講究。初始序號 ISN 不是從 0 或 1 開始的而是隨機化的。早期實現(xiàn)用時鐘驅(qū)動現(xiàn)在RFC 6528一般用源 IP、目的 IP、源端口、目的端口四元組加上一個密鑰做哈希。為什么要隨機防止攻擊者預(yù)測序號后偽造報文注入數(shù)據(jù)也防止同一四元組的歷史連接殘包被誤認為當前連接的數(shù)據(jù)。有個實操細節(jié)服務(wù)端在 SYN_RCVD 狀態(tài)時會把這個半連接放進半連接隊列syn queue等第三個 ACK 到了才移進全連接隊列accept queue。如果應(yīng)用層 accept 太慢全連接隊列滿了新完成的連接會被丟掉或者回 RST客戶端看到的就是握手成功了但立刻斷開。隊列長度由net.core.somaxconn和 listen 的 backlog 參數(shù)共同決定默認值往往偏小高并發(fā)服務(wù)記得調(diào)。另一個相關(guān)參數(shù)是net.ipv4.tcp_max_syn_backlog半連接隊列滿了會觸發(fā) SYN cookie 機制。3.2 四次揮手與 TIME_WAIT 的真實困擾關(guān)閉比建立復(fù)雜因為 TCP 是全雙工的兩個方向要各自關(guān)閉主動關(guān)閉方 被動關(guān)閉方 | ---- FIN, sequ ------------ | 被動方進 CLOSE_WAIT | --- ACK, acku1 ----------- | | --- FIN, seqw, acku1 ---- | 被動方進 LAST_ACK | ---- ACK, ackw1 ---------- | 被動方進 CLOSED | 主動方進 TIME_WAIT等 2MSL |為什么是四次因為 FIN 只表示我沒有數(shù)據(jù)要發(fā)了不代表我不能再收。被動方收到 FIN 后可以先回 ACK然后繼續(xù)把剩下的數(shù)據(jù)發(fā)完發(fā)完了再發(fā)自己的 FIN。這兩件事不能合并成一個包所以是四次。當然如果被動方此時也沒有數(shù)據(jù)要發(fā)FIN 和 ACK 可以合并實際抓包里經(jīng)?？吹饺尉徒Y(jié)束。TIME_WAIT 是投訴率最高的一個狀態(tài)。主動關(guān)閉方在發(fā)完最后一個 ACK 后要等 2MSL 才能徹底關(guān)閉Linux 上 MSL 固定為 60 秒所以 TIME_WAIT 持續(xù) 60 秒。它存在的理由有兩個一是保證最后的 ACK 能到達對方如果 ACK 丟了對方會重發(fā) FIN此時自己還能回一次 ACK二是讓這條連接上所有迷路的舊報文在網(wǎng)絡(luò)中消亡避免污染下一個同四元組的新連接。代價是高并發(fā)的短連接服務(wù)主動關(guān)閉方會積累海量 TIME_WAIT占滿本地端口。標準解法有幾個讓服務(wù)端主動關(guān)閉服務(wù)端端口固定不受本地端口限制影響用連接池復(fù)用長連接開啟net.ipv4.tcp_tw_reuse1注意它只對出向連接生效而且依賴時間戳tcp_max_tw_buckets調(diào)大但要謹慎超限會打日志并直接銷毀。tcp_tw_recycle千萬不要開它在 NAT 環(huán)境下會導(dǎo)致大量連接失敗新內(nèi)核已經(jīng)把它移除了。比 TIME_WAIT 更值得警惕的是CLOSE_WAIT 堆積。大量連接卡在 CLOSE_WAIT說明對端已經(jīng)發(fā)了 FIN而你的應(yīng)用沒有調(diào)用 close() 釋放 socket。這是純粹的代碼問題可能是業(yè)務(wù)邏輯里 return 提前了沒走 finally可能是線程池耗盡導(dǎo)致回調(diào)沒執(zhí)行也可能是用了連接池但歸還邏輯有 bug?？吹?CLOSE_WAIT 數(shù)量只增不減別調(diào)內(nèi)核參數(shù)去查代碼。3.3 狀態(tài)機速查與抓包識別TCP 一共 11 個狀態(tài)日常排查其實只需要認出幾個關(guān)鍵的狀態(tài)出現(xiàn)位置含義與常見問題LISTEN服務(wù)端正常監(jiān)聽數(shù)量異常多說明服務(wù)開得太多SYN_SENT客戶端發(fā)了 SYN 沒收到回應(yīng)通常是網(wǎng)絡(luò)不通或被防火墻丟包SYN_RCVD服務(wù)端半連接大量堆積可能是 SYN Flood 或 backlog 太小ESTABLISHED雙方連接已建立數(shù)量持續(xù)增長要警惕連接泄漏FIN_WAIT_1主動關(guān)閉方發(fā)了 FIN 還沒收到 ACKFIN_WAIT_2主動關(guān)閉方收到 ACK 但對方還沒發(fā) FIN長期卡住說明對端應(yīng)用沒關(guān)連接TIME_WAIT主動關(guān)閉方正常等 2MSLCLOSE_WAIT被動關(guān)閉方應(yīng)用沒調(diào) close()堆積就是代碼 bugLAST_ACK被動關(guān)閉方發(fā)了 FIN 等最后 ACK一般很快消失用ss -tan state time-wait | wc -l這類命令能快速統(tǒng)計各狀態(tài)數(shù)量ss -tanp還能看到對應(yīng)進程。抓包時狀態(tài)轉(zhuǎn)換在報文里一目了然看到SYN就是建連開始看到RST, ACK就是異常終止看到FIN, ACK就是正常關(guān)閉。有個小技巧抓包文件里篩選tcp.flags.reset 1能一次性把所有異常重置的連接撈出來排障效率極高。4. 可靠性是怎么堆出來的序號、確認、重傳與滑動窗口4.1 序號與確認號的計算TCP 把應(yīng)用層交下來的字節(jié)流當成一個連續(xù)的字節(jié)序列每個字節(jié)都有一個編號。序號字段填的是本報文段第一個數(shù)據(jù)字節(jié)的編號。確認號填的是我期待收到的下一個字節(jié)編號也就是這個編號之前的所有字節(jié)我都收到了。舉個具體例子。客戶端要發(fā) 3000 字節(jié)MSS 是 1000假設(shè)那么會切成三個段第一段seq1000ISN1長度 1000攜帶字節(jié) 1000–1999第二段seq2000長度 1000攜帶字節(jié) 2000–2999第三段seq3000長度 1000攜帶字節(jié) 3000–3999服務(wù)端收到第一段后回ack2000含義是1999 及之前的我都收到了下一個我要 2000。如果第一段和第二段都到了但第三段丟了服務(wù)端會回ack3000而不是 4000明確告訴發(fā)送方我只到 2999。這里有兩個容易搞混的點。第一SYN 和 FIN 各消耗一個序號所以握手時seqx的 SYN對方回ackx1關(guān)閉時 FIN 也一樣。第二純 ACK 報文不消耗序號也不攜帶數(shù)據(jù)它只是確認。抓包時看到Seq1, Ack1, Len0這種就是純確認包。序號字段只有 32 位超過 4GB 會回繞。如果鏈路兩端對回繞的處理不一致就會出現(xiàn)序號跳變的詭異問題?，F(xiàn)代內(nèi)核用 PAWSProtection Against Wrapped Sequences機制配合時間戳選項來判斷基本能自動處理但如果你在自研協(xié)議棧或者做中間件這塊必須特別注意。4.2 超時重傳與快速重傳發(fā)出去的段沒收到確認怎么辦重傳。但多久沒收到就重傳這個時間RTO不能拍腦袋定定短了會瘋狂重傳加劇擁塞定長了恢復(fù)慢。TCP 的做法是動態(tài)估算第一次測量SRTT R, RTTVAR R/2 后續(xù)測量 RTTVAR (1-β) × RTTVAR β × |SRTT - R| SRTT (1-α) × SRTT α × R RTO SRTT 4 × RTTVAR其中 α 1/8β 1/4。這個公式的意思是維護一個平滑的往返時間 SRTT 和一個偏差估計 RTTVARRTO 取平滑值 4 倍偏差這樣在鏈路抖動時能自動放寬。Linux 上 RTO 有下限通常 200ms和上限通常 120 秒初始值一般是 1 秒。但等超時太慢了。TCP 還有一條更快的路徑快速重傳。如果發(fā)送方連續(xù)收到 3 個重復(fù)的 ACK說明某個段丟了后面的段都到了就立刻重傳丟失的段不用等 RTO 到期。配合 **SACK選擇性確認**選項接收方還能告訴發(fā)送方我收到了哪些不連續(xù)的段發(fā)送方就只用重傳真正缺的那幾段而不是把后面全重傳一遍。這里有個參數(shù)值得記net.ipv4.tcp_sack默認開啟不要關(guān)。我見過有人為了省流量關(guān)掉 SACK結(jié)果丟包率一高重傳量翻了三四倍帶寬反而被吃滿。實際排查中如果你在抓包文件里看到連續(xù)多個[TCP Dup ACK]緊接著一個[TCP Retransmission]那就是標準的快速重傳現(xiàn)場。如果看到的是[TCP Retransmission]前面沒有任何 Dup ACK那就是超時重傳說明丟包發(fā)現(xiàn)得晚延遲會明顯變高。4.3 滑動窗口與流量控制重傳解決丟了補上滑動窗口解決別發(fā)太快把對方撐爆。接收方在每次 ACK 里帶上自己的接收窗口rwnd含義是我當前緩沖區(qū)還能接這么多字節(jié)。發(fā)送方維護一個發(fā)送窗口窗口內(nèi)的數(shù)據(jù)可以連續(xù)發(fā)出去不用等確認窗口左邊界隨著 ACK 前移。這就是滑動的含義。窗口大小直接決定吞吐量上限。公式很簡單吞吐量上限 窗口大小 / RTT假設(shè)窗口 64KBRTT 40ms那單連接吞吐上限就是 65536 / 0.04 ≈ 1.6 MB/s約 13 Mbps。這就是為什么跨地域傳輸大文件時單條 TCP 連接怎么都跑不滿帶寬——不是帶寬不夠是窗口太小、RTT 太大。解決辦法是開窗口擴大因子或者多開幾條連接并行。窗口縮到 0 時發(fā)送方會停止發(fā)送并啟動零窗口探測定期發(fā)一個小包問現(xiàn)在能收了嗎。如果接收方應(yīng)用一直不 read 數(shù)據(jù)緩沖區(qū)滿了就會一直零窗口發(fā)送方就一直等著——這也是服務(wù)端不讀數(shù)據(jù)導(dǎo)致客戶端卡死這類問題的原理。用ss -tmi能看到每個連接的rwnd、cwnd、rtt等詳細指標排障時非常有用。4.4 擁塞控制從慢啟動到 CUBIC流量控制是照顧接收方擁塞控制是照顧整個網(wǎng)絡(luò)。發(fā)送方額外維護一個擁塞窗口cwnd實際能發(fā)的數(shù)據(jù)量取min(cwnd, rwnd)。擁塞控制分四個階段慢啟動連接剛建立時 cwnd 很小Linux 現(xiàn)代版本初始值是 10 個 MSSRFC 6928 之前的舊實現(xiàn)是 1-4 個每收到一個 ACK 就把 cwnd 加一個 MSS效果是指數(shù)增長——1、2、4、8、16一個 RTT 翻一倍。漲到慢啟動閾值ssthresh就切換。擁塞避免超過閾值后改成線性增長每個 RTT 大約加一個 MSS謹慎試探網(wǎng)絡(luò)容量。快速重傳與快速恢復(fù)收到 3 個重復(fù) ACK 時說明網(wǎng)絡(luò)還有余量后面的包能到把 ssthresh 設(shè)為當前 cwnd 的一半cwnd 也減半然后直接進入擁塞避免不用回到慢啟動從頭爬。超時重傳說明情況更嚴重直接把 cwnd 打回 1 個 MSS重新慢啟動。Linux 默認的擁塞控制算法是 CUBIC它的增長曲線是三次函數(shù)在高帶寬長距離鏈路上比傳統(tǒng)的 Reno 表現(xiàn)好很多。近些年 BBR 也很流行思路完全不同——它不靠丟包判斷擁塞而是測量帶寬和最小 RTT 來建模。切換算法很簡單# 查看當前算法和可用算法 sysctl net.ipv4.tcp_congestion_control sysctl net.ipv4.tcp_available_congestion_control # 臨時切換為 bbr sysctl -w net.ipv4.tcp_congestion_controlbbr我的經(jīng)驗是跨國或跨運營商的長肥鏈路高帶寬高延遲BBR 通常能帶來明顯的吞吐提升內(nèi)網(wǎng)短鏈路CUBIC 和 BBR 差異不大用默認的就行。切換前一定要在灰度環(huán)境壓測不要直接上生產(chǎn)。5. 實操用抓包和代碼把協(xié)議看見5.1 環(huán)境與工具準備紙上得來終覺淺協(xié)議這東西必須親手抓一次才算真懂。你需要的東西不多一臺 Linux 機器云主機或本地虛擬機都行、一個能跑 Python 的環(huán)境、抓包工具。命令行抓包我用tcpdump輕量、隨處可用圖形化分析用帶界面的抓包軟件看時序圖和流追蹤更直觀。安裝和基礎(chǔ)用法# 抓本機 8080 端口的 TCP 包不做域名解析直接寫文件 tcpdump -i any -nn -s 0 tcp port 8080 -w /tmp/tcp8080.pcap # 只看握手和揮手相關(guān)的標志位 tcpdump -i any -nn tcp port 8080 and (tcp[tcpflags] (tcp-syn|tcp-fin|tcp-rst) ! 0) # 實時看 UDP 53 端口DNS tcpdump -i any -nn udp port 53 -c 20幾個參數(shù)的含義值得記牢-i any抓所有網(wǎng)卡-nn不做 IP 和端口反解避免 DNS 查詢干擾抓包-s 0抓完整包老版本默認只抓 68 字節(jié)頭部以下會被截斷這個坑很多人踩過-w寫文件供后續(xù)分析。生產(chǎn)環(huán)境抓包注意加過濾條件并限制包數(shù)不然一個高流量服務(wù)幾分鐘就能抓出幾十 GB。5.2 TCP 三次握手抓包實錄啟動一個最簡單的服務(wù)端然后用 curl 連一下同時抓包。這是最經(jīng)典的一組報文值得反復(fù)看No. Time Source Destination Info 1 0.000000 10.0.0.5 10.0.0.9 54321 → 8080 [SYN] Seq0 Win64240 Len0 MSS1460 SACK_PERM TSval... 2 0.000312 10.0.0.9 10.0.0.5 8080 → 54321 [SYN, ACK] Seq0 Ack1 Win65160 Len0 MSS1460 SACK_PERM TSval... 3 0.000398 10.0.0.5 10.0.0.9 54321 → 8080 [ACK] Seq1 Ack1 Win64240 Len0 4 0.000521 10.0.0.5 10.0.0.9 54321 → 8080 [PSH, ACK] Seq1 Ack1 Len78對著看幾點第 1 個包Seq0是抓包工具顯示的相對序號真實 ISN 是隨機的工具做了偏移處理方便閱讀。MSS1460是客戶端告訴服務(wù)端我這邊最多能收 1460 字節(jié)的 TCP 載荷——這是 MTU 1500 減去 IP 頭 20 再減去 TCP 頭 20 得到的。SACK_PERM表示支持選擇性確認。Win64240是接收窗口。TSval是時間戳選項用于更精確的 RTT 測量和防回繞。第 2 個包服務(wù)端的Ack1因為 SYN 消耗了一個序號。服務(wù)端也報了自己的 MSS 和窗口。注意 MSS 是雙向協(xié)商的各自報各自能接收的最大值實際發(fā)送時按較小的那個來。第 3 個包是純 ACKLen0沒有數(shù)據(jù)。這一步完成后雙方進入 ESTABLISHED。第 4 個包才是真正的業(yè)務(wù)數(shù)據(jù)PSH標志表示盡快交給應(yīng)用層。整個握手在 0.4 毫秒內(nèi)完成因為都在同一個局域網(wǎng)。如果是跨地域第 1 到第 3 個包之間的時間差就是一次 RTT這也是為什么TCP 建連本身就要消耗一個 RTT——HTTPS 還要再多花一兩個 RTT 做密鑰協(xié)商首屏慢的鍋有時候真不在業(yè)務(wù)代碼。你可以在抓包工具里看Statistics → TCP Stream Graphs → Time-Sequence能直觀看到每個包在時間軸上的分布、重傳在哪、窗口怎么變化。這張圖我排障時幾乎必看比肉眼數(shù)報文高效得多。5.3 UDP 與 TCP 的代碼對比寫兩段最小可運行的代碼把兩者行為差異看得最清楚。先看 TCP 服務(wù)端import socket # SOCK_STREAM 表示 TCP server socket.socket(socket.AF_INET, socket.SOCK_STREAM) # 允許端口復(fù)用避免重啟時報 Address already in use server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) # 關(guān)閉 Nagle 算法避免小包合并帶來的延遲 server.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1) server.bind((0.0.0.0, 8080)) server.listen(128) # backlog對應(yīng)全連接隊列長度 print(listening on 8080) while True: conn, addr server.accept() with conn: while True: data conn.recv(4096) # TCP 是字節(jié)流一次 recv 不保證一個完整消息 if not data: break # 對端關(guān)閉 conn.sendall(becho: data)再看 UDP 服務(wù)端import socket # SOCK_DGRAM 表示 UDP server socket.socket(socket.AF_INET, socket.SOCK_DGRAM) server.bind((0.0.0.0, 8081)) print(udp listening on 8081) while True: # 一次 recvfrom 對應(yīng)一個數(shù)據(jù)報天然保留消息邊界 data, addr server.recvfrom(65535) server.sendto(becho: data, addr)兩段代碼一對比差異全在細節(jié)里。TCP 多了accept()這一步說明它是有連接概念的recv()的返回值需要自己判斷消息邊界因為一個 4096 的緩沖區(qū)可能裝到半條消息加一條半消息sendall()和send()不同前者會循環(huán)直到發(fā)完后者只保證發(fā)了一部分。UDP 則完全不需要考慮這些一次recvfrom就是一個完整數(shù)據(jù)報但你得自己處理丟包和亂序?？蛻舳诉@邊UDP 還有個特殊行為值得注意如果你用connect()綁定了一個目標地址之后發(fā)往其他地址的包會被靜默丟棄同時能找到對方端口不可達的 ICMP 錯誤。不connect()的話一次性發(fā)送大包會頻繁觸發(fā)sendto返回EMSGSIZE因為載荷超過了單包上限。5.4 用系統(tǒng)命令觀察連接狀態(tài)抓包看報文系統(tǒng)命令看狀態(tài)兩者配合才完整。下面這幾條我基本天天在用# 按狀態(tài)統(tǒng)計當前連接數(shù)量 ss -tan | awk NR1 {print $1} | sort | uniq -c | sort -rn # 查看某個端口的連接詳情含內(nèi)存和定時器信息 ss -tmn sport :8080 # 查看 TCP 全局統(tǒng)計重傳率、握手失敗、隊列溢出都在這 netstat -s | grep -iE retrans|overflow|listen|reset # 查看內(nèi)核連接相關(guān)參數(shù) sysctl -a | grep -E somaxconn|tcp_max_syn|tcp_tw|tcp_keepalivenetstat -s里的listen overflows和listen drops兩個計數(shù)特別關(guān)鍵前者表示全連接隊列滿導(dǎo)致新連接被丟后者表示半連接隊列滿。這兩個值只要在持續(xù)增長就說明應(yīng)用 accept 不過來或者 backlog 配小了跟業(yè)務(wù)邏輯無關(guān)調(diào)參數(shù)就能解決。6. 選型決策什么場景該用哪個6.1 一張決策表背后的判斷邏輯選型不是站隊是權(quán)衡。我把常見場景整理成下面這張表附上判斷依據(jù)場景推薦判斷依據(jù)網(wǎng)頁請求、API 調(diào)用TCP需要完整、有序且請求量不極端數(shù)據(jù)庫連接TCP一個字節(jié)都不能錯長連接還能復(fù)用文件傳輸TCP完整性優(yōu)先順序錯亂無法處理DNS 查詢UDP大響應(yīng)回退 TCP一問一答包小重試成本低音視頻實時通話UDPRTP/RTCP寧可丟一幀也不要卡 200ms 等重傳游戲狀態(tài)同步UDP舊的位置數(shù)據(jù)沒有重傳價值新的覆蓋舊的日志、指標上報UDP 或批量 TCP少量丟失可接受優(yōu)先低開銷局域網(wǎng)服務(wù)發(fā)現(xiàn)UDP 廣播/組播TCP 不支持廣播物聯(lián)網(wǎng)低功耗上報UDP或輕量封裝建連開銷和功耗都難以承受判斷邏輯可以濃縮成三個問題按順序問自己第一丟了這一份數(shù)據(jù)業(yè)務(wù)能接受嗎能接受就用 UDP不能就用 TCP。注意是這一份不是任何一份——音視頻丟一幀沒事但控制信令丟了就有事所以很多實時系統(tǒng)是 UDP 傳媒體流、TCP或可靠 UDP傳信令的混合架構(gòu)。第二延遲敏感度有多高TCP 的隊頭阻塞是硬傷前面一個包丟了后面即使全到了也得在緩沖區(qū)里等著應(yīng)用層收不到。在弱網(wǎng)環(huán)境下這個等待可能是幾百毫秒。實時性要求高的場景這個代價通常不可接受。第三能不能承擔(dān)自己實現(xiàn)可靠性的成本基于 UDP 做可靠傳輸不是加個重傳就完事還要處理擁塞控制、RTT 估計、亂序重組、防放大攻擊等等工作量以人月計。除非你有明確的性能訴求否則別自己造。6.2 那些看起來該用 UDP 卻用了 TCP的案例選型最忌諱教條。我見過幾個反直覺但合理的例子值得說說。第一個是某些即時通訊的長連接。直覺上消息推送應(yīng)該快但實際主流方案走的都是 TCP 長連接。原因是消息必須到達可靠性權(quán)重遠高于延遲而 TCP 的連接狀態(tài)讓服務(wù)端能主動推送UDP 沒有連接概念NAT 穿透后還得自己維護會話再加上有心跳和重連機制兜底偶發(fā)的隊頭阻塞影響被攤薄了。第二個是短查詢類接口。有人覺得就查一條記錄一次往返用 UDP 省掉握手不是更快。理論上一問一答確實 UDP 少一個 RTT但實際收益微乎其微——因為現(xiàn)在普遍是長連接 連接復(fù)用握手成本早被攤銷掉了。而你需要自己處理丟包重試、請求 ID 匹配、超時判定代碼復(fù)雜度翻倍收益卻是零點幾毫秒。這筆賬怎么算都不劃算。第三個是內(nèi)網(wǎng)的 RPC。某些高性能 RPC 框架在延遲敏感場景下會提供 UDP 模式但默認還是 TCP。原因還是那個內(nèi)網(wǎng)丟包率極低萬分之一以下TCP 的隊頭阻塞幾乎不發(fā)生而 UDP 省下的那點開銷在整體鏈路里占比很小。反過來也有看起來該用 TCP 卻用了 UDP的日志采集。某系統(tǒng)每秒產(chǎn)生幾十萬條日志如果每條都建 TCP 連接光握手就把 CPU 打滿了。改成 UDP 批量發(fā)送允許在極端情況下丟少量日志——因為日志的價值是統(tǒng)計趨勢不是逐條審計丟 0.1% 完全不影響結(jié)論。這個決策的關(guān)鍵在于明確業(yè)務(wù)對數(shù)據(jù)完整性的真實要求而不是籠統(tǒng)地說日志很重要所以不能丟。6.3 在 UDP 上重建可靠性要補哪些課如果你確實決定走 UDP 自建可靠傳輸至少要補齊這幾塊缺一不可。序號與重組。每個數(shù)據(jù)報帶一個遞增序號接收端按序號排序、去重、檢測空洞。要注意序號回繞的處理以及亂序窗口的大小——窗口太小會誤判丟包太大內(nèi)存扛不住。確認與重傳?？梢灾鸢?ACK也可以累積 ACK 加選擇性確認。重傳要配合 RTO 估算公式可以直接抄 TCP 的 SRTT 4×RTTVAR。別忘了重傳次數(shù)上限否則網(wǎng)絡(luò)徹底斷了會無限重試。擁塞控制。這是最容易被跳過、也最容易出事的一塊。沒有擁塞控制你的協(xié)議在丟包時會繼續(xù)猛發(fā)把整條鏈路和其他流量一起拖死。哪怕只做一個簡化版的 AIMD加性增、乘性減也比沒有強。分片與 MTU。UDP 超過 MTU 會觸發(fā) IP 分片任何一個分片丟失整個數(shù)據(jù)報就廢了重傳成本極高。正確做法是在應(yīng)用層做分片單包載荷控制在 1200 字節(jié)以內(nèi)給 IPv6 和隧道封裝留余量這也是 QUIC 選 1200 的原因。安全。裸 UDP 極易被用于反射放大攻擊——攻擊者偽造源 IP 發(fā)一個小請求你回一個大響應(yīng)受害者就被淹了。所以必須做源地址驗證比如要求客戶端先回一個隨機 token并且限制響應(yīng)與請求的大小比例。QUIC 把這套東西完整實現(xiàn)了一遍還順帶把握手和加密合并0-RTT 或 1-RTT 建連并在應(yīng)用層解決了隊頭阻塞。如果你想理解可靠 UDP到底該長什么樣去讀 QUIC 的協(xié)議文檔是最快的路徑。6.4 MTU、粘包、心跳三個繞不開的工程細節(jié)MTU 與分片。以太網(wǎng)默認 MTU 1500這是歷史遺留值。路徑上任何一跳的 MTU 更小都會導(dǎo)致分片或丟棄而路徑 MTU 發(fā)現(xiàn)PMTUD依賴 ICMP很多防火墻把 ICMP 全禁了于是出現(xiàn)小包能通、大包不通的經(jīng)典故障。經(jīng)驗值TCP 的 MSS 協(xié)商后一般是 1460IPv4或 1440IPv6UDP 應(yīng)用層載荷控制在 1200 以內(nèi)最穩(wěn)。如果你在容器或隧道環(huán)境里MTU 還要減去封裝開銷比如某些隧道要減 60–80 字節(jié)。粘包。前面說過這是把流當包用造成的。解決方式就三種定長消息、分隔符如換行、\r\n、長度前綴先發(fā) 4 字節(jié)長度再發(fā)內(nèi)容。工程上最推薦長度前綴解析簡單、無轉(zhuǎn)義問題、二進制安全。千萬不要用每次 recv 正好是一條消息這種假設(shè)寫代碼它在你本機測試時永遠是對的一上線就出問題。心跳。TCP 自帶 keepalive但默認空閑 7200 秒才探測太長了而且只能探測連接是否還活著探測不到對端進程假死。所以業(yè)務(wù)層必須自己做心跳客戶端每 30 秒發(fā)一次 ping服務(wù)端回 pong連續(xù) 3 次沒收到就判定斷線重連。心跳間隔要比中間設(shè)備負載均衡、NAT 網(wǎng)關(guān)的連接空閑超時短常見設(shè)備超時是 60 秒或 300 秒心跳間隔取 30 秒比較安全。7. 常見問題與排查實錄7.1 高頻問題速查表下面這張表是我這些年攢下來的遇到問題先對照它能省掉一大半瞎猜的時間。現(xiàn)象可能原因排查手段偶發(fā)多出 40ms 延遲Nagle 算法與延遲 ACK 疊加抓包看是否有小包等待開 TCP_NODELAY大量 CLOSE_WAIT應(yīng)用沒調(diào)用 close()ss -tan state close-wait查代碼釋放路徑大量 TIME_WAIT短連接多、主動關(guān)閉方在本地改連接池、調(diào)整端口范圍、tcp_tw_reuse連接不上報 Address already in use端口被占或 TIME_WAIT 未復(fù)用開 SO_REUSEADDRss -tanp查占用小包能通大包不通MTU 不匹配、ICMP 被攔ping -M do -s 1472逐段探測間歇性 connection reset中間設(shè)備超時、服務(wù)端 backlog 滿看netstat -s的 overflow 計數(shù)傳輸吞吐上不去窗口太小或 RTT 太大ss -tmi看 cwnd/rwnd考慮開窗口擴大UDP 偶發(fā)丟包無報錯緩沖區(qū)和 MTU 問題調(diào)rmem_max控制載荷在 1200 內(nèi)服務(wù)端 ESTABLISHED 很多但業(yè)務(wù)超時隊頭阻塞、線程池打滿看 recv-q/send-qss -tmn觀察隊列7.2 一次典型的排障路徑說個真實經(jīng)歷的變形版。某服務(wù)每天有幾個時段出現(xiàn)請求偶發(fā)超時超時率約 2%重試一次就好監(jiān)控上看不出明顯規(guī)律。第一步先確定問題在哪一層。在客戶端和服務(wù)端同時抓包對比兩端看到的報文。結(jié)果發(fā)現(xiàn)客戶端發(fā)了請求服務(wù)端過了 800ms 才收到——說明問題在中間鏈路不在應(yīng)用。第二步看 TCP 層的行為。抓包里出現(xiàn)了零星的[TCP Retransmission]重傳間隔正好是 200ms 左右符合最小 RTO。說明有丟包但丟包率很低。第三步看丟在哪里。用mtr做路徑探測發(fā)現(xiàn)某一跳有 1%–2% 的丟包。再和運維確認那臺設(shè)備負載偏高在跑大流量轉(zhuǎn)發(fā)。第四步驗證假設(shè)。把請求大小從 8KB 降到 2KB 以內(nèi)減少分片和占用時間超時率下降到 0.3%。最終通過擴容那臺設(shè)備、同時把服務(wù)端的tcp_slow_start_after_idle關(guān)掉避免空閑后重新慢啟動問題徹底消失。這條路子的核心方法論是分層定位逐層收斂。先確定是應(yīng)用層、傳輸層還是網(wǎng)絡(luò)層的問題再往下一層層縮小范圍。最忌諱的是一上來就懷疑業(yè)務(wù)代碼改半天沒效果最后還是抓包解決了。7.3 幾個只有踩過才知道的坑坑一關(guān)掉 TCP_NODELAY 以為能省流量結(jié)果延遲爆炸。Nagle 算法會把小包攢起來一起發(fā)配合接收方的延遲 ACK最多等 200ms在高頻小包場景下會出現(xiàn)每個請求卡 40ms的詭異現(xiàn)象。這個現(xiàn)象在本地測試環(huán)境幾乎復(fù)現(xiàn)不出來因為本機 RTT 極低Nagle 攢不到包就發(fā)出去了。IO 密集型的 RPC、實時消息推送一律開TCP_NODELAY?？佣詾?UDP 的緩沖區(qū)跟 TCP 一樣能自動背壓。TCP 緩沖區(qū)滿了會阻塞發(fā)送方天然形成背壓UDP 緩沖區(qū)滿了內(nèi)核直接把包丟掉發(fā)送方毫不知情。如果你的 UDP 接收端處理慢就會出現(xiàn)明明發(fā)了 10000 條只收到 8000 條且毫無報錯。解決辦法是調(diào)大net.core.rmem_max并在應(yīng)用層做隊列水位監(jiān)控?？尤齌IME_WAIT 數(shù)量高就無腦開tcp_tw_recycle。這個參數(shù)在 NAT 環(huán)境下的行為會導(dǎo)致大量正常連接被拒表現(xiàn)為同一出口 IP 的多個客戶端只有部分能連上。較新的內(nèi)核已經(jīng)移除該參數(shù)老系統(tǒng)上如果開了建議立刻關(guān)掉?？铀陌?keepalive 當成心跳用。系統(tǒng)級 keepalive 只能探測對端主機是否可達對端進程崩了但主機還在keepalive 是探不出來的除非進程退出導(dǎo)致內(nèi)核發(fā)了 FIN。真正的存活檢測必須靠應(yīng)用層心跳而且要帶業(yè)務(wù)語義能反映服務(wù)真的能處理請求?？游迦萜鳝h(huán)境下忽略 MTU。容器網(wǎng)絡(luò)通常有 VXLAN 等封裝實際可用 MTU 會比宿主機的 1500 小常見 1450 甚至 1400。如果應(yīng)用不感知這件事大包會被丟棄且現(xiàn)象極其隱蔽小請求都正常一傳大文件就卡死。部署到容器集群時務(wù)必確認 Pod 內(nèi)的ip link顯示的實際 MTU并據(jù)此調(diào)整應(yīng)用層的包大小。我個人在實際操作中的體會是UDP 和 TCP 這兩塊知識光看文檔永遠學(xué)不透必須抓一次包 寫一次代碼 排一次障三件套都走一遍腦子里才會長出真正的模型。我自己是被一次線上 RST 風(fēng)暴逼著把 RFC 從頭翻了一遍那之后再看框架的日志、再看監(jiān)控的曲線很多以前覺得莫名其妙的東西突然就對上了。如果你現(xiàn)在手上的系統(tǒng)有偶發(fā)超時、有說不清的重傳、有莫名的連接數(shù)增長別急著調(diào)參數(shù)先抓個包答案八成寫在報文里。