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