很多團隊第一次把服務(wù)從 TCP 切到 UDP都是奔著快和省事去的覺得無連接、不用握手、不用維護狀態(tài)怎么算都劃算。結(jié)果第一版上線監(jiān)控面板上接收側(cè)丟包率穩(wěn)定在 3%~8%第一反應(yīng)是機房網(wǎng)絡(luò)有問題拉著運維查路由、查交換機、查對端限速折騰兩天最后發(fā)現(xiàn)發(fā)送端的sendto全部返回成功一個錯誤都沒有包是在本機內(nèi)核的接收緩沖區(qū)里被默默丟掉的。這個場景我見過不止一次它幾乎概括了 UDP 協(xié)議最容易被誤解的地方——它把控制權(quán)交給你同時也把責(zé)任甩給了你。這篇內(nèi)容就把 UDP 從首部字段一路拆到工程落地講清楚它的邊界在哪里、哪些事情必須自己做、哪些坑幾乎人人都會踩一遍。適合已經(jīng)寫過 socket、但被 UDP 的各種玄學(xué)丟包折磨過的開發(fā)者也適合還在猶豫該不該上 UDP 的技術(shù)選型人看完你應(yīng)該能自己判斷手里這個業(yè)務(wù)到底該不該用它。1. 實時鏈路為什么敢用UDP一次看起來像網(wǎng)絡(luò)故障的排查開場1.1 從5%丟包說起問題并不在網(wǎng)絡(luò)上那次排查的起點非常典型一個實時數(shù)據(jù)上報的場景客戶端每秒發(fā) 200 個數(shù)據(jù)報單個報文 800 字節(jié)左右服務(wù)端用單線程recvfrom循環(huán)收。壓測環(huán)境一切正常上了真實流量之后服務(wù)端統(tǒng)計到的收包數(shù)比客戶端統(tǒng)計的發(fā)送數(shù)少了 5% 上下而且這個比例和流量大小強相關(guān)——流量越大丟得越多。一開始所有人的注意力都在網(wǎng)絡(luò)上因為丟包這個詞天然指向鏈路。但我當(dāng)時堅持先在本機看了一眼中斷和 socket 隊列用ss -u -a -n -i觀察接收隊列發(fā)現(xiàn)Recv-Q在流量高峰時幾乎一直是滿的。這一步基本就定性了包已經(jīng)到達(dá)內(nèi)核只是應(yīng)用沒來得及取走緩沖區(qū)滿了之后新來的包被內(nèi)核直接丟棄發(fā)送端完全感知不到。改用多進程加SO_REUSEPORT、把接收緩沖區(qū)調(diào)大之后丟包率降到 0.02% 以下剩下的部分才是真正的鏈路丟包。這里的關(guān)鍵認(rèn)知是UDP 的丟包至少有四個完全不同的來源從下往上分別是物理鏈路擁塞或錯包、中間設(shè)備限速或策略丟棄、本機內(nèi)核接收緩沖區(qū)溢出、應(yīng)用層自己處理不及。它們的現(xiàn)象長得一模一樣但處理手段天差地別。不從下往上分層定位就只能靠猜而猜的代價通常是幾天時間。1.2 UDP到底放棄了什么又換回了什么把 UDP 和 TCP 擺在一起對比的文章很多但大多數(shù)只停留在可靠 vs 不可靠這種口號層面實際指導(dǎo)意義有限。我更愿意從內(nèi)核幫你做了什么這個角度看TCP 在內(nèi)核里維護了一整套狀態(tài)機包括連接建立與拆除、序號與確認(rèn)、超時重傳、滑動窗口、擁塞控制、亂序重組、粘包拆包的處理。這些東西你一行代碼都不用寫代價是內(nèi)核要替你決策而且很多決策的參數(shù)你改不動。UDP 把這些幾乎全部去掉了只留下端口尋址和一層可選的校驗。換來的是三樣?xùn)|西第一是延遲的可預(yù)測性沒有重傳等待沒有擁塞窗口爬坡一個包發(fā)出去要么到要么不到不會出現(xiàn)因為前面一個包丟了所以后面全卡住的隊頭阻塞第二是控制權(quán)的完整性什么時候重傳、重傳幾次、要不要讓路給別的流全部由應(yīng)用層說了算第三是拓?fù)渖系撵`活性廣播、組播這些一對多的尋址方式TCP 從設(shè)計上就不支持。代價也同樣明確所有可靠性工作下移到了應(yīng)用層而且內(nèi)核不再提供背壓。TCP 發(fā)送緩沖區(qū)滿了會把send阻塞住逼著生產(chǎn)者降速UDP 的sendto只要把數(shù)據(jù)塞進發(fā)送緩沖區(qū)就返回成功緩沖區(qū)滿了才返回EAGAIN接收端更是徹底沒有反饋通道。這意味著 UDP 鏈路上任何一個環(huán)節(jié)的處理能力不足都會以丟包的形式體現(xiàn)而不是以延遲上升的形式體現(xiàn)。理解這一點后面所有的工程細(xì)節(jié)才有落腳點。1.3 什么樣的業(yè)務(wù)適合把可靠性交給上層不是所有業(yè)務(wù)都值得為 UDP 付出這些額外成本。我的判斷標(biāo)準(zhǔn)通常看三條能不能容忍偶發(fā)丟包、延遲敏感度有多高、有沒有必要做一對多。能容忍丟包的典型是實時音視頻和游戲狀態(tài)同步。一幀視頻丟了解碼器做個錯誤隱藏人眼基本看不出來一個位置同步包丟了下一個包 20ms 后就到插值一下就補上了。這類場景里重傳一個已經(jīng)過時的包不僅沒用反而會占用帶寬、加劇擁塞所以 TCP 的重傳機制在這里是負(fù)資產(chǎn)。延遲敏感度高的典型是實時交互類業(yè)務(wù)比如遠(yuǎn)程操作的指令下發(fā)。這類場景對丟包的容忍度其實不高但對確定性延遲的要求極高寧可快速失敗讓上層做降級也不能出現(xiàn)幾百毫秒的不可預(yù)測停頓。至于一對多組播和廣播是 UDP 獨占的能力做局域網(wǎng)設(shè)備發(fā)現(xiàn)、行情推送、流媒體分發(fā)時幾乎繞不開。反過來說凡是每條消息都必須到達(dá)、順序不能亂、數(shù)據(jù)量還不小的場景老老實實用 TCP 或者基于 UDP 的成熟可靠傳輸方案自己從零寫一套可靠層大概率會在某個邊界條件上翻車。2. 拆開那8個字節(jié)UDP首部字段與偽首部校驗的完整推演2.1 四個字段各自的職責(zé)與邊界UDP 首部固定 8 字節(jié)四個 16 位字段簡單到可以背下來但每個字段的邊界條件都值得說清楚。源端口和目的端口各 2 字節(jié)取值范圍 0~65535。源端口在多數(shù)客戶端場景下由內(nèi)核自動分配走的是臨時端口范圍Linux 上默認(rèn)是net.ipv4.ip_local_port_range定義的那一段。這里有個容易被忽略的限制單個客戶端 IP 對同一個服務(wù)端IP:Port組合理論上最多只能建立 65535 個不同的源端口會話做大規(guī)模長連接或高并發(fā) UDP 會話時這個上限會先于帶寬成為瓶頸。解決辦法是多綁幾個本地 IP或者用多臺機器分?jǐn)偂ｉL度字段 2 字節(jié)指的是首部 數(shù)據(jù)的總長度最小值是 8純首部、無數(shù)據(jù)最大值是 65535。注意它統(tǒng)計的是 UDP 層的長度不含 IP 首部。IPv4 下 UDP 載荷最大是 65535 - 8 - 20 65507 字節(jié)IPv6 下因為 UDP 長度字段可以為 0走 Jumbogram 擴展理論上能更大但實際工程中幾乎沒人這么用。校驗和字段 2 字節(jié)覆蓋范圍包括偽首部、UDP 首部和數(shù)據(jù)。在 IPv4 里它是可選的填 0 表示發(fā)送端不計算校驗和接收端也不校驗在 IPv6 里它是強制的填 0 是非法值。實踐中我不建議關(guān)掉它因為關(guān)掉之后錯包只能靠上層協(xié)議自己發(fā)現(xiàn)而很多上層協(xié)議并沒有做這件事。提示判斷一個 UDP 包是否真的到了應(yīng)用層看的是應(yīng)用有沒有recvfrom到它而不是發(fā)送端有沒有返回成功。sendto返回的字節(jié)數(shù)只代表數(shù)據(jù)進入了本機 socket 發(fā)送緩沖區(qū)和對面是否收到?jīng)]有任何關(guān)系。2.2 校驗和為什么要把偽首部算進去偽首部這個概念初次接觸時很反直覺——它并不在網(wǎng)絡(luò)上真實傳輸只是參與校驗和計算時臨時拼出來的 12 字節(jié)IPv4或 40 字節(jié)IPv6結(jié)構(gòu)。IPv4 的偽首部包含源 IP、目的 IP、一個保留字節(jié)、協(xié)議號UDP 是 17和 UDP 長度IPv6 的偽首部包含 16 字節(jié)源地址、16 字節(jié)目的地址、4 字節(jié)上層報文長度、3 字節(jié)零和 1 字節(jié)下一首部值。為什么要多此一舉因為如果只校驗 UDP 首部和數(shù)據(jù)那么一個被錯誤路由到本機的包只要它內(nèi)部數(shù)據(jù)自洽校驗就能通過應(yīng)用會收到一個看起來合法但不屬于自己的報文。把 IP 地址納入校驗范圍之后地址在傳輸過程中被篡改或出錯的情況就能被檢出。這是一個很樸素但有效的設(shè)計用上層校驗覆蓋下層關(guān)鍵字段。計算過程本身是標(biāo)準(zhǔn)的 16 位反碼求和把偽首部、UDP 首部校驗和字段先置 0和數(shù)據(jù)按 16 位一組切開逐組相加進位回卷加到低位最后取反碼。有一個細(xì)節(jié)值得記住如果計算結(jié)果恰好是 0x0000發(fā)送時要寫成 0xFFFF因為全 0 在校驗和字段里有未計算的特殊含義兩者在反碼運算里是等價的但語義不能混。# 手工計算 UDP 校驗和的最小示例用于理解過程 def udp_checksum(src_ip, dst_ip, payload: bytes, src_port, dst_port): udp_len 8 len(payload) pseudo src_ip dst_ip bytes([0, 17]) udp_len.to_bytes(2, big) udp_hdr src_port.to_bytes(2, big) dst_port.to_bytes(2, big) \ udp_len.to_bytes(2, big) b\x00\x00 data pseudo udp_hdr payload if len(data) % 2: data b\x00 total 0 for i in range(0, len(data), 2): total (data[i] 8) data[i 1] total (total 0xFFFF) (total 16) total ~total 0xFFFF return total if total ! 0 else 0xFFFF實際抓包時你會看到校驗和錯誤的包在大部分網(wǎng)卡上會被硬件直接丟掉只有開了混雜模式或者網(wǎng)卡關(guān)閉了校驗和卸載checksum offload才能抓到。這也是為什么用tcpdump在本機抓包看到包明明在但應(yīng)用收不到——很可能就是校驗和有問題被丟了。排查這類問題時先看一眼/proc/net/snmp里的InCsumErrors計數(shù)比盲猜快得多。2.3 抓包對照一個1472字節(jié)的包長什么樣理解協(xié)議最快的方式還是看真實報文。以太網(wǎng) MTU 是 1500 字節(jié)扣掉 20 字節(jié) IPv4 首部和 8 字節(jié) UDP 首部UDP 載荷上限就是 1472 字節(jié)。這個數(shù)字在工程中出現(xiàn)頻率極高很多采集類系統(tǒng)就是按 1472 來切包目的就是讓每個 UDP 報文塞進一個以太網(wǎng)幀避免 IP 分片。下面是一個典型的 1472 字節(jié)載荷的 UDP 報文在tcpdump里的樣子十六進制部分略去數(shù)據(jù)區(qū)IP 10.0.0.12.54321 10.0.0.34.9000: UDP, length 1472 0x0000: 4500 05dc 1a2b 4000 4011 8f3c 0a00 000c 0x0010: 0a00 0022 d431 2328 05dc 1a2e逐段讀4500是 IPv4 版本 4 加首部長度 55×420 字節(jié)05dc是總長度 15001a2b是標(biāo)識4000里高 3 位是標(biāo)志DF 位置 1表示不分片4011里40是 TTL 6411是協(xié)議號 17 也就是 UDP后面是首部校驗和與源目 IP。再往后d431是源端口 543212328是目的端口 900005dc是 UDP 長度 15001a2e是校驗和。從這個報文能讀出兩件事第一UDP 長度字段填的是 1500包含了 8 字節(jié)首部所以載荷是 1492不對這里我做個小修正——如果 UDP 長度是 1500那 IP 總長度應(yīng)該是 1520但以太網(wǎng) MTU 只有 1500所以這個包必然分片。真正不分片的情況下UDP 長度字段應(yīng)該是 14801472 載荷 8 首部IP 總長度 1500。第二DF標(biāo)志位一旦置 1任何加上了首部之后超過 MTU 的包都會被中間設(shè)備丟棄并回一個 ICMP 需要分片的消息這反而是件好事——它讓問題暴露出來而不是被悄悄分片。3. 無連接不等于無責(zé)任把可靠性補在上層還是在中間件3.1 可靠UDP的四種典型補全路線既然 UDP 不保證送達(dá)那保證送達(dá)這件事就得有人做。業(yè)界大致有四條路線選哪條取決于你的業(yè)務(wù)邊界和對可控性的要求。第一條是自己寫最小可靠層。核心就三件事給每個報文加序號、接收端回確認(rèn)、發(fā)送端維護重傳隊列。聽起來簡單但一旦要考慮亂序、去重、窗口、超時估算代碼量就會迅速膨脹到幾千行而且?guī)缀醣厝粫┑裟硞€邊界條件。我只建議在報文語義非常簡單、丟包容忍度較高的場景下自己寫比如局域網(wǎng)內(nèi)的控制指令通道。第二條是在 UDP 之上套一層成熟的可靠傳輸協(xié)議。QUIC 是最典型的代表它在 UDP 之上重建了可靠流、擁塞控制、多路復(fù)用還順帶把 TLS 1.3 集成進來解決了隊頭阻塞問題。如果你的場景是需要一個比 TCP 更快的可靠傳輸QUIC 基本是首選不用自己造。KCP 是另一個選擇它用犧牲部分帶寬換取更低延遲的策略在同等的丟包率下延遲表現(xiàn)通常優(yōu)于 TCP代價是流量放大約 10%~20%。第三條是用 RTP/RTCP 這類面向媒體的協(xié)議棧。它們不強求每個包都到而是通過序列號、時間戳和接收端報告來做丟包隱藏、抖動緩沖和碼率自適應(yīng)。做音視頻的話這條路是標(biāo)準(zhǔn)答案。第四條是在應(yīng)用層做冪等加補償。傳輸層索性不保證業(yè)務(wù)層通過消息 ID 去重、定時對賬、定期全量同步來兜底。這條路線對基礎(chǔ)設(shè)施改動最小適合內(nèi)部系統(tǒng)之間的數(shù)據(jù)上報。路線典型方案適用場景主要代價自研最小可靠層序號 ACK 重傳隊列語義簡單的控制通道邊界條件多維護成本高成熟可靠傳輸協(xié)議QUIC、KCP需要可靠且低延遲的數(shù)據(jù)流需要引入額外依賴或改造接入層媒體協(xié)議棧RTP/RTCP、SRTP音視頻、實時流需要配套的抖動緩沖與擁塞控制應(yīng)用層冪等補償消息 ID 去重 對賬內(nèi)部數(shù)據(jù)上報、日志采集有延遲需要業(yè)務(wù)側(cè)配合3.2 重傳、序號與擁塞控制的最小實現(xiàn)骨架如果你確實要自己寫一層那么有幾個設(shè)計決策必須先定下來它們是后續(xù)所有問題的根源。序號怎么編。單調(diào)遞增的 32 位或 64 位整數(shù)是最常見的做法回繞問題一定要提前想清楚比較大小的時候用差值而不是直接比大小。另一種是包序號加時間戳的組合好處是能同時支撐亂序重組和 RTT 估算。ACK 怎么回。逐包 ACK 在包量大時會把上行帶寬吃光通常用累積 ACK 加選擇性 ACK 的組合告訴對端我連續(xù)收到了到 N 為止的所有包另外還額外收到了這幾個。ACK 本身也要做聚合比如每收到 2 個包或者每 10ms 回一次。重傳超時怎么定。固定超時是最簡單也最容易出問題的做法。稍微認(rèn)真一點的做法是維護 RTT 的平滑值和方差超時時間取平滑 RTT 加上若干倍方差同時設(shè)一個下限比如 50ms避免在低延遲鏈路上因為抖動觸發(fā)大量無謂重傳。擁塞控制要不要做。這一條最容易被省略也是自研可靠層在生產(chǎn)環(huán)境翻車的主要原因。沒有擁塞控制一旦鏈路出現(xiàn)丟包發(fā)送端還在全速發(fā)只會讓丟包率進一步上升最終整條鏈路退化到幾乎不可用。哪怕只做一個最簡單的版本——丟包時把發(fā)送速率減半一段時間無丟包再線性增長——也比完全沒有強得多。# 極簡的 RTT 估算與重傳超時計算只演示思路 class RttEstimator: def __init__(self): self.srtt None # 平滑 RTT self.rttvar None # RTT 方差 self.min_rto 0.05 # 50ms 下限 def update(self, sample): if self.srtt is None: self.srtt sample self.rttvar sample / 2 else: self.rttvar 0.75 * self.rttvar 0.25 * abs(self.srtt - sample) self.srtt 0.875 * self.srtt 0.125 * sample def rto(self): if self.srtt is None: return 0.2 return max(self.min_rto, self.srtt 4 * self.rttvar)3.3 別自己造輪子什么情況下該直接上成熟方案有個很實用的判斷原則如果你的可靠層需要處理連接遷移多路復(fù)用加密握手路徑 MTU 發(fā)現(xiàn)中的任意兩項以上就別自己寫了。這四件事每一項單獨做都不算難但組合起來的復(fù)雜度是指數(shù)級上升的而且出問題的時候極難復(fù)現(xiàn)。QUIC 已經(jīng)把這些都做完了而且有成熟的開源實現(xiàn)可以直接嵌入語言覆蓋也夠全。真正適合自研的場景通常是協(xié)議語義極簡比如只有固定 32 字節(jié)的狀態(tài)包、運行環(huán)境受限嵌入式設(shè)備內(nèi)存只有幾十 KB、或者需要和已有協(xié)議做深度耦合比如自定義的私有協(xié)議棧已經(jīng)有大量存量設(shè)備。還有一種情況值得單獨提只是想在局域網(wǎng)內(nèi)做高可靠傳輸。局域網(wǎng)丟包率極低鏈路 RTT 通常小于 1ms這種情況下可靠的實現(xiàn)難度會大幅下降簡單的序號加超時重傳就夠用不需要復(fù)雜的擁塞控制。但要注意一旦這套東西要跨公網(wǎng)前面的假設(shè)就全部失效了。4. 緩沖區(qū)、MTU與IO模型UDP工程化的三個硬約束4.1 接收緩沖區(qū)溢出UDP丟包最常見的一號元兇回到開頭那個 5% 丟包的故事根因就是接收緩沖區(qū)。這里把機制講透。每個 UDP socket 在內(nèi)核里有一塊接收緩沖區(qū)大小由net.core.rmem_default決定可以用SO_RCVBUF調(diào)整。數(shù)據(jù)到達(dá)網(wǎng)卡之后經(jīng)過驅(qū)動、協(xié)議棧最終掛到這個 socket 的接收隊列上。應(yīng)用調(diào)用recvfrom時從隊列里取走一個數(shù)據(jù)報。如果隊列滿了新到的包直接被丟棄不通知發(fā)送端也不通知接收端最多在/proc/net/snmp的RcvbufErrors計數(shù)上加一。這意味著兩件事。第一UDP 的丟包在緩沖區(qū)這一層是靜默的只能靠計數(shù)器事后發(fā)現(xiàn)。第二能不能扛住突發(fā)流量取決于緩沖區(qū)能裝下多少個包。舉個具體的數(shù)假設(shè)單個報文 1200 字節(jié)緩沖區(qū)設(shè)為 2MB那么大約能緩存的報文數(shù)是 2097152 / 1200 ≈ 1747 個扣除內(nèi)核的結(jié)構(gòu)體開銷實際更少。如果應(yīng)用處理能力是每秒 5 萬包那么 2MB 緩沖區(qū)只能吸收約 35ms 的處理停頓。一旦發(fā)生一次 100ms 的 GC 或者磁盤抖動溢出就是必然的。所以調(diào)緩沖區(qū)之前先算清楚兩個數(shù)峰值收包速率和最長處理停頓時間兩者相乘就是最低需要的緩沖字節(jié)數(shù)再乘個 1.5 的安全系數(shù)。# 查看當(dāng)前系統(tǒng)的 UDP 相關(guān)統(tǒng)計重點看 RcvbufErrors netstat -su | grep -A 10 ^Udp: # 或者直接讀 proc cat /proc/net/snmp | grep ^Udp: # 查看內(nèi)核緩沖區(qū)上限 sysctl net.core.rmem_default net.core.rmem_max sysctl net.core.netdev_max_backlog # tcpdump 之外用 ss 看接收隊列積壓情況 ss -u -a -n -i調(diào)優(yōu)的時候有幾個容易踩的坑。第一個是SO_RCVBUF設(shè)置的值會被內(nèi)核翻倍用于內(nèi)部簿記開銷所以設(shè)置 4MB 實際得到 8MB反過來說如果你讀回來是 8MB 不要驚訝。第二個是設(shè)置值受net.core.rmem_max限制超過部分會被靜默截斷所以必須先把 sysctl 調(diào)大。第三個是netdev_max_backlog這個參數(shù)管的是網(wǎng)卡到協(xié)議棧之間的隊列很多人在收包瓶頸時只調(diào)了 socket 緩沖區(qū)忘了這一層也會丟包現(xiàn)象是RcvbufErrors不漲但包就是少了。注意一味把緩沖區(qū)調(diào)大并不是好事。緩沖區(qū)越大應(yīng)用處理不過來時積壓的包越多而這些包往往已經(jīng)過時處理它們只是浪費 CPU還會掩蓋真實的問題。合理的做法是調(diào)到能吸收正常的抖動就夠了然后通過監(jiān)控RcvbufErrors來持續(xù)觀察。4.2 MTU與IP分片1472這個數(shù)字的來歷和它的陷阱前面提到 1500 減去 20 減 8 得到 1472這是 IPv4 下的經(jīng)典值。IPv6 的首部是 40 字節(jié)所以對應(yīng)的值是 1500 - 40 - 8 1452。除此之外還有幾層封裝會繼續(xù)吃掉空間PPPoE 要扣 8 字節(jié)VXLAN 要扣 50 字節(jié)GRE 要扣 24 字節(jié)IPsec 隧道也要扣掉幾十字節(jié)。這就是為什么在云上或者跨專線的環(huán)境里按 1472 發(fā)包很可能直接被丟。分片的機制是這樣的如果 IP 層的包超過了出接口 MTU且沒有設(shè)置 DF 標(biāo)志IP 層會把它切成多個分片分別發(fā)送接收端根據(jù) IP 首部的標(biāo)識、偏移和 MF 標(biāo)志重組。問題在于只要任何一個分片丟失整個原始數(shù)據(jù)報就作廢接收端無法交付半個 UDP 報文。而且重組需要占用接收端的內(nèi)存緩沖區(qū)還有超時限制。在丟包率 1% 的鏈路上發(fā)一個 8000 字節(jié)的包需要切成 6 個分片只要其中一個丟了整包重傳實際有效丟包率會放大到接近 6%。所以工程上的原則很明確盡量不讓 UDP 報文觸發(fā) IP 分片。具體做法有幾個層次一是把應(yīng)用層的報文大小控制在 1200 字節(jié)左右。這個數(shù)字不是隨便定的QUIC 選它是因為 IPv6 的最小 MTU 要求是 1280減去 40 字節(jié) IPv6 首部和 8 字節(jié) UDP 首部正好剩 1232再留一點余量給隧道封裝。按 1200 來切包走絕大多數(shù)網(wǎng)絡(luò)都不會分片。二是開啟路徑 MTU 發(fā)現(xiàn)PMTUD也就是設(shè)置IP_MTU_DISCOVER為IP_PMTUDISC_DO讓內(nèi)核在包超過 MTU 時返回EMSGSIZE而不是默默分片。這樣問題會在發(fā)送端立刻暴露而不是變成對端的神秘丟包。但 PMTUD 依賴 ICMP 反饋而很多網(wǎng)絡(luò)會屏蔽 ICMP所以實踐中通常還會配一個保守的兜底值。三是如果真的需要傳大塊數(shù)據(jù)在應(yīng)用層做分片和重組自己維護分片序號和超時丟棄而不是依賴 IP 層。import socket sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) # 禁止 IP 層分片超過 MTU 直接報 EMSGSIZE sock.setsockopt(socket.IPPROTO_IP, socket.IP_MTU_DISCOVER, socket.IP_PMTUDISC_DO) # 設(shè)置發(fā)送與接收緩沖區(qū) sock.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 4 * 1024 * 1024) sock.setsockopt(socket.SOL_SOCKET, socket.SO_SNDBUF, 1 * 1024 * 1024) try: sock.sendto(bx * 2000, (10.0.0.34, 9000)) except OSError as e: # 在開啟了 PMTUD 的情況下超長報文會拋 EMSGSIZE print(send failed:, e)4.3 單socket還是多socket并發(fā)收包的幾種組織方式UDP 是無連接的一個 socket 天然就能處理來自任意客戶端的報文所以最直觀的寫法是單線程recvfrom加業(yè)務(wù)分發(fā)。這種寫法在低流量下完全夠用但流量一大就會遇到兩個問題單核打滿以及前面提到的緩沖區(qū)溢出。往下走有幾條路各有利弊。多線程共享同一個 socket。多個線程同時recvfrom內(nèi)核會加鎖串行化實際吞吐提升有限而且在高并發(fā)下鎖競爭反而會拖慢。這條路我不太推薦除非線程數(shù)很少。多進程綁同一個端口加SO_REUSEPORT。內(nèi)核會按四元組哈希把報文分發(fā)到不同的 socket每個進程各自處理互不干擾。這是目前 Linux 上最實用的方案擴展性好進程掛掉一個也只影響一部分流量。缺點是哈希固定某個熱點客戶端可能一直落在同一個進程上需要靠增加分片數(shù)來攤平。另外要注意SO_REUSEPORT的負(fù)載均衡是按流做的對于 UDP 來說流就是四元組所以同一對 IP 端口之間的所有報文會固定落到同一個 socket。單線程加epoll加批量收取。recvmmsg一次系統(tǒng)調(diào)用可以收多個數(shù)據(jù)報能顯著降低系統(tǒng)調(diào)用開銷。在 10 萬 pps 這個量級批量收取帶來的提升是肉眼可見的。配合sendmmsg批量發(fā)送單核處理能力可以再上一個臺階。內(nèi)核旁路方案。當(dāng)單機需要處理百萬級 pps 時常規(guī)協(xié)議棧的開銷就成了瓶頸這時候會考慮 DPDK、AF_XDP 這類方案把網(wǎng)卡數(shù)據(jù)直接搬到用戶態(tài)。代價是復(fù)雜度陡增需要獨占網(wǎng)卡、自己做協(xié)議棧運維和調(diào)試成本都很高。除非確實撞到了性能墻否則我不建議走這條路。方案適用規(guī)模優(yōu)點主要限制單線程 recvfrom萬 pps 以下實現(xiàn)最簡單單核上限無冗余多線程共享 socket萬級 pps改動小鎖競爭擴展性差多進程 SO_REUSEPORT十萬級 pps水平擴展容錯好哈希傾斜需調(diào)分片數(shù)recvmmsg 批量收發(fā)十萬級 pps系統(tǒng)調(diào)用開銷低需要處理批量語義AF_XDP / DPDK百萬級 pps極致性能復(fù)雜度高運維成本大5. 廣播、組播與穿透邊界UDP的拓?fù)淠芰εc限制5.1 單播之外的三種尋址方式TCP 只能一對一這是它的設(shè)計前提。UDP 支持三種額外的尋址方式這是它在某些場景下不可替代的根本原因。廣播發(fā)往本地網(wǎng)段內(nèi)的所有主機。IPv4 里有受限廣播地址 255.255.255.255 和子網(wǎng)廣播地址比如 192.168.1.255。使用前必須在 socket 上設(shè)置SO_BROADCAST選項否則會返回權(quán)限錯誤。廣播的局限很明顯不跨路由器只在本地網(wǎng)段有效而且所有主機都要消耗資源處理這個包網(wǎng)段里設(shè)備一多就會造成明顯的廣播風(fēng)暴。組播是更精細(xì)的方案發(fā)送方把包發(fā)到一個組播地址只有加入了該組的主機才會收到。IPv4 的組播地址范圍是 224.0.0.0/4其中 224.0.0.0/24 是本地鏈路保留段像 mDNS 用的 224.0.0.251、SSDP 用的 239.255.255.250 都屬于約定俗成的固定地址。使用組播需要加入組IP_ADD_MEMBERSHIP并關(guān)注 TTL 設(shè)置——組播包的 TTL 決定了它能跨多少個路由器默認(rèn)值 1 意味著只在本地網(wǎng)段生效。任播在 UDP 層面沒有專門的支持它是靠路由層面把同一個地址宣告到多個位置來實現(xiàn)的客戶端看起來是在單播實際被路由到了最近的一個節(jié)點。很多公共 DNS 服務(wù)用的就是這套機制。import socket, struct # 加入組播組并接收 sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP) sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) sock.bind((, 5353)) mreq struct.pack(4s4s, socket.inet_aton(224.0.0.251), socket.inet_aton(0.0.0.0)) sock.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq) while True: data, addr sock.recvfrom(2048) print(addr, len(data))實踐中組播最大的坑在于中間網(wǎng)絡(luò)設(shè)備對組播的支持程度參差不齊。交換機需要開啟 IGMP snooping 才能避免把組播泛洪成廣播路由器需要配置 PIM 才能跨網(wǎng)段轉(zhuǎn)發(fā)云環(huán)境里組播往往直接被禁用。所以組播方案在落地前一定要先在目標(biāo)網(wǎng)絡(luò)環(huán)境里做連通性驗證不能想當(dāng)然。5.2 NAT與連接跟蹤UDP會話為什么放著放著就斷了UDP 本身沒有連接概念但中間設(shè)備為了做地址轉(zhuǎn)換和狀態(tài)過濾會給它維護一份會話表。這份表的條目是有超時時間的一旦超時表項被刪除后續(xù)的包就會被丟棄或者拒絕。不同設(shè)備的默認(rèn)超時差異很大。常見的家用路由器和運營商級 NAT 上UDP 會話的空閑超時可能在 30 秒到 5 分鐘之間。這意味著如果一個 UDP 會話超過這個時間沒有任何報文往來通道就會被回收。表現(xiàn)出來就是客戶端和服務(wù)端都覺得自己還活著但包發(fā)不過去了。解決辦法很直接——保活。定期發(fā)一個小的探測包讓中間設(shè)備的狀態(tài)表保持活躍。間隔要比最短的超時時間更短實踐中常用 15 到 25 秒。但?；畋旧硪灿写鷥r移動端上頻繁喚醒無線網(wǎng)卡會顯著增加耗電所以在移動場景里需要配合應(yīng)用層的前后臺狀態(tài)來動態(tài)調(diào)整。還有一種更隱蔽的情況NAT 設(shè)備重啟或者表項被提前回收但客戶端仍然按原來的映射發(fā)數(shù)據(jù)這時候包會被丟棄而服務(wù)端完全不知道。所以客戶端必須有一個長時間收不到響應(yīng)就重建會話的機制不能假設(shè)通道一直有效。提示Linux 上的nf_conntrack_udp_timeout和nf_conntrack_udp_timeout_stream兩個參數(shù)控制 UDP 連接跟蹤的超時前者用于沒有回包的會話默認(rèn) 30 秒后者用于雙向都有流量的會話默認(rèn) 120 秒。做網(wǎng)關(guān)或代理類服務(wù)時這兩個值往往要調(diào)大。5.3 反射放大風(fēng)險與必須做的收口UDP 有一個天然的安全弱點源地址可以偽造。因為不需要握手攻擊者可以偽造受害者的 IP 向服務(wù)發(fā)送請求服務(wù)把響應(yīng)發(fā)給了受害者。如果請求很小而響應(yīng)很大就形成了放大效應(yīng)。DNS、NTP、SSDP 這些基于 UDP 的服務(wù)歷史上都因為這個問題被濫用過。作為服務(wù)提供方該做的事情很明確而且都是常規(guī)工程手段對無認(rèn)證的請求做響應(yīng)大小限制。如果協(xié)議允許把響應(yīng)控制在請求大小的一定倍數(shù)以內(nèi)最理想的是不超過請求本身的大小。對來源做速率限制和異常檢測。同一來源在短時間內(nèi)發(fā)送大量請求時降低響應(yīng)優(yōu)先級或者直接丟棄。注意這里要小心誤傷NAT 后面的合法用戶共享一個出口 IP限速閾值要留足余量。能加認(rèn)證就加認(rèn)證。哪怕是最簡單的 cookie 機制也能讓偽造源地址的攻擊者收不到有效響應(yīng)因為第二個包需要帶上第一個包里的隨機值。別暴露不必要的服務(wù)。開放的調(diào)試接口、狀態(tài)查詢接口如果響應(yīng)很大又不需要認(rèn)證就是最理想的放大工具。這類接口應(yīng)該只監(jiān)聽內(nèi)網(wǎng)地址或者干脆默認(rèn)關(guān)閉。做入口流量清洗。對于規(guī)模較大的服務(wù)上游的流量清洗是兜底手段但這是最后一道防線不能替代前面的收口。6. 選型決策與壓測把UDP用在正確的地方6.1 一張對照表什么時候選UDP什么時候老實回TCP做了這么多年前后端我發(fā)現(xiàn)選型失誤的根源往往不是技術(shù)能力不夠而是問題定義不清楚。下面這張表是我自己常用的判斷依據(jù)按場景歸類。場景特征推薦選擇理由音視頻通話、直播推流UDPRTP/WebRTC丟包可隱藏重傳無意義實時游戲狀態(tài)同步UDP狀態(tài)有時效性舊包無用高頻行情推送UDP 組播優(yōu)先一對多延遲敏感局域網(wǎng)設(shè)備發(fā)現(xiàn)UDP 廣播/組播TCP 不支持一對多大文件傳輸TCP 或 QUIC需要可靠且有序支付、訂單類業(yè)務(wù)TCP不允許丟消息語義強依賴順序內(nèi)部服務(wù)間 RPCTCP 或 QUIC生態(tài)成熟調(diào)試工具全指標(biāo)采集、日志上報UDP 加應(yīng)用層補償量大允許少量丟失跨公網(wǎng)的穩(wěn)定長連接QUIC基于 UDP兼顧低延遲與可靠性有個判斷技巧值得分享問自己如果這條消息丟了業(yè)務(wù)能不能自己發(fā)現(xiàn)并補救。如果能UDP 是可以考慮的如果不能而且補救成本很高那還是老實上可靠傳輸。很多團隊選 UDP 是覺得性能好但實際瓶頸根本不在傳輸層換過去之后性能沒提升多少可靠性問題倒是接二連三。6.2 壓測怎么做才有意義指標(biāo)、工具與觀測點UDP 的壓測和 TCP 差別很大因為發(fā)送端收不到任何反饋很容易測出發(fā)送 100 萬包全部成功這種毫無意義的結(jié)論。有效的壓測必須同時在發(fā)送端和接收端埋點然后對賬。發(fā)送端要記錄的是應(yīng)用層調(diào)用sendto的次數(shù)、成功次數(shù)、失敗次數(shù)區(qū)分EAGAIN、EMSGSIZE、ENOBUFS等錯誤碼、實際發(fā)出的字節(jié)數(shù)。接收端要記錄的是recvfrom收到的包數(shù)、字節(jié)數(shù)、丟包數(shù)發(fā)送數(shù)減接收數(shù)、亂序數(shù)、重復(fù)數(shù)、端到端延遲分布。工具方面iperf3的 UDP 模式可以做基礎(chǔ)帶寬測試但它只能告訴你吞吐和丟包率測不出應(yīng)用層的處理能力。真正壓業(yè)務(wù)邏輯還得自己寫客戶端或者用現(xiàn)成的壓測框架。我通常會用一個小腳本做發(fā)包接收端跑真實服務(wù)并暴露 Prometheus 指標(biāo)這樣能得到最貼近生產(chǎn)的結(jié)論。觀測點上除了應(yīng)用層指標(biāo)一定要看這幾個內(nèi)核計數(shù)器# UDP 層統(tǒng)計重點是 InErrors / RcvbufErrors / SndbufErrors / InCsumErrors cat /proc/net/snmp | grep ^Udp: # 網(wǎng)卡層丟棄看 drop 和 fifo 兩列 ip -s link show eth0 # socket 隊列積壓 ss -u -a -n -i | head -20 # 中斷分布如果集中在單個核上說明需要開 RSS 或者調(diào)整親和性 cat /proc/interrupts | grep eth0壓測的節(jié)奏也要注意。不要一上來就打滿應(yīng)該從小到大分幾檔每一檔穩(wěn)定跑夠時間至少 60 秒讓緩沖區(qū)進入穩(wěn)態(tài)觀察各項指標(biāo)隨流量增長的變化曲線。如果丟包率在某個流量點突然從 0 跳到明顯的百分比那個點就是系統(tǒng)的實際容量上限比理論計算值靠譜得多。6.3 上線前的檢查清單按我自己的習(xí)慣UDP 服務(wù)上線前會過一遍下面這些項每一條都對應(yīng)過真實的故障。報文大小是否控制在 1200 字節(jié)以內(nèi)有沒有針對隧道封裝的余量。曾經(jīng)有個服務(wù)在測試環(huán)境跑得好好的上了生產(chǎn)走了 VXLAN 隧道1500 的包全部被丟因為隧道封裝后又多了 50 字節(jié)。緩沖區(qū)是否按峰值速率和最長停頓算過rmem_max和netdev_max_backlog是否同步調(diào)過。這兩個不一起調(diào)光調(diào)前者沒用。保活機制是否存在間隔是否短于目標(biāo)網(wǎng)絡(luò)的最短 NAT 超時?？邕\營商、跨云廠商的鏈路超時值差異會很大。錯誤處理是否覆蓋了EAGAIN、EMSGSIZE、ECONNREFUSED。特別是ECONNREFUSED在對端沒監(jiān)聽的時候如果 socket 調(diào)過connectrecvfrom會收到這個錯誤很多人沒處理導(dǎo)致進程直接崩掉。監(jiān)控是否覆蓋了接收側(cè)丟包、緩沖區(qū)溢出、校驗和錯誤、亂序和重復(fù)。只在發(fā)送端埋點是不夠的發(fā)送端的成功什么都不能說明。限速與收口是否做了特別是響應(yīng)大小和來源速率。這一條經(jīng)常被當(dāng)成以后再說然后就沒有以后了。容量驗證是否在真實網(wǎng)絡(luò)拓?fù)渖献鲞^而不是只在同機房的低延遲環(huán)境里跑。同機房 RTT 小于 0.5ms跨公網(wǎng)可能 30ms 以上緩沖區(qū)需求差了幾十倍?；赝朔桨甘欠駵?zhǔn)備好。UDP 服務(wù)出問題時能不能快速切回 TCP 或者降級到低頻上報這個開關(guān)要提前做好。最后分享一個我自己踩過的坑。有次排查一個偶發(fā)的丟包問題各種計數(shù)器都正常緩沖區(qū)沒溢出網(wǎng)卡沒丟包鏈路也沒問題最后發(fā)現(xiàn)是應(yīng)用層的線程池隊列滿了任務(wù)被靜默丟棄但日志里只記了處理成功——因為丟棄發(fā)生在一個try/except的寬泛捕獲里。這件事之后我改了一個習(xí)慣凡是可能靜默丟棄數(shù)據(jù)的地方無論在哪一層都必須有一個計數(shù)器哪怕只是一個內(nèi)存里的累加值定期打到日志里。UDP 這套架構(gòu)最大的特點就是沒有反饋你必須自己造出反饋來否則排查問題的時候只能靠猜而猜出來的結(jié)論往往離真相很遠(yuǎn)。 UDP工程化避坑：從首部字段到丟包、MTU與IO模型
很多團隊第一次把服務(wù)從 TCP 切到 UDP都是奔著快和省事去的覺得無連接、不用握手、不用維護狀態(tài)怎么算都劃算。結(jié)果第一版上線監(jiān)控面板上接收側(cè)丟包率穩(wěn)定在 3%~8%第一反應(yīng)是機房網(wǎng)絡(luò)有問題拉著運維查路由、查交換機、查對端限速折騰兩天最后發(fā)現(xiàn)發(fā)送端的sendto全部返回成功一個錯誤都沒有包是在本機內(nèi)核的接收緩沖區(qū)里被默默丟掉的。這個場景我見過不止一次它幾乎概括了 UDP 協(xié)議最容易被誤解的地方——它把控制權(quán)交給你同時也把責(zé)任甩給了你。這篇內(nèi)容就把 UDP 從首部字段一路拆到工程落地講清楚它的邊界在哪里、哪些事情必須自己做、哪些坑幾乎人人都會踩一遍。適合已經(jīng)寫過 socket、但被 UDP 的各種玄學(xué)丟包折磨過的開發(fā)者也適合還在猶豫該不該上 UDP 的技術(shù)選型人看完你應(yīng)該能自己判斷手里這個業(yè)務(wù)到底該不該用它。1. 實時鏈路為什么敢用UDP一次看起來像網(wǎng)絡(luò)故障的排查開場1.1 從5%丟包說起問題并不在網(wǎng)絡(luò)上那次排查的起點非常典型一個實時數(shù)據(jù)上報的場景客戶端每秒發(fā) 200 個數(shù)據(jù)報單個報文 800 字節(jié)左右服務(wù)端用單線程recvfrom循環(huán)收。壓測環(huán)境一切正常上了真實流量之后服務(wù)端統(tǒng)計到的收包數(shù)比客戶端統(tǒng)計的發(fā)送數(shù)少了 5% 上下而且這個比例和流量大小強相關(guān)——流量越大丟得越多。一開始所有人的注意力都在網(wǎng)絡(luò)上因為丟包這個詞天然指向鏈路。但我當(dāng)時堅持先在本機看了一眼中斷和 socket 隊列用ss -u -a -n -i觀察接收隊列發(fā)現(xiàn)Recv-Q在流量高峰時幾乎一直是滿的。這一步基本就定性了包已經(jīng)到達(dá)內(nèi)核只是應(yīng)用沒來得及取走緩沖區(qū)滿了之后新來的包被內(nèi)核直接丟棄發(fā)送端完全感知不到。改用多進程加SO_REUSEPORT、把接收緩沖區(qū)調(diào)大之后丟包率降到 0.02% 以下剩下的部分才是真正的鏈路丟包。這里的關(guān)鍵認(rèn)知是UDP 的丟包至少有四個完全不同的來源從下往上分別是物理鏈路擁塞或錯包、中間設(shè)備限速或策略丟棄、本機內(nèi)核接收緩沖區(qū)溢出、應(yīng)用層自己處理不及。它們的現(xiàn)象長得一模一樣但處理手段天差地別。不從下往上分層定位就只能靠猜而猜的代價通常是幾天時間。1.2 UDP到底放棄了什么又換回了什么把 UDP 和 TCP 擺在一起對比的文章很多但大多數(shù)只停留在可靠 vs 不可靠這種口號層面實際指導(dǎo)意義有限。我更愿意從內(nèi)核幫你做了什么這個角度看TCP 在內(nèi)核里維護了一整套狀態(tài)機包括連接建立與拆除、序號與確認(rèn)、超時重傳、滑動窗口、擁塞控制、亂序重組、粘包拆包的處理。這些東西你一行代碼都不用寫代價是內(nèi)核要替你決策而且很多決策的參數(shù)你改不動。UDP 把這些幾乎全部去掉了只留下端口尋址和一層可選的校驗。換來的是三樣?xùn)|西第一是延遲的可預(yù)測性沒有重傳等待沒有擁塞窗口爬坡一個包發(fā)出去要么到要么不到不會出現(xiàn)因為前面一個包丟了所以后面全卡住的隊頭阻塞第二是控制權(quán)的完整性什么時候重傳、重傳幾次、要不要讓路給別的流全部由應(yīng)用層說了算第三是拓?fù)渖系撵`活性廣播、組播這些一對多的尋址方式TCP 從設(shè)計上就不支持。代價也同樣明確所有可靠性工作下移到了應(yīng)用層而且內(nèi)核不再提供背壓。TCP 發(fā)送緩沖區(qū)滿了會把send阻塞住逼著生產(chǎn)者降速UDP 的sendto只要把數(shù)據(jù)塞進發(fā)送緩沖區(qū)就返回成功緩沖區(qū)滿了才返回EAGAIN接收端更是徹底沒有反饋通道。這意味著 UDP 鏈路上任何一個環(huán)節(jié)的處理能力不足都會以丟包的形式體現(xiàn)而不是以延遲上升的形式體現(xiàn)。理解這一點后面所有的工程細(xì)節(jié)才有落腳點。1.3 什么樣的業(yè)務(wù)適合把可靠性交給上層不是所有業(yè)務(wù)都值得為 UDP 付出這些額外成本。我的判斷標(biāo)準(zhǔn)通常看三條能不能容忍偶發(fā)丟包、延遲敏感度有多高、有沒有必要做一對多。能容忍丟包的典型是實時音視頻和游戲狀態(tài)同步。一幀視頻丟了解碼器做個錯誤隱藏人眼基本看不出來一個位置同步包丟了下一個包 20ms 后就到插值一下就補上了。這類場景里重傳一個已經(jīng)過時的包不僅沒用反而會占用帶寬、加劇擁塞所以 TCP 的重傳機制在這里是負(fù)資產(chǎn)。延遲敏感度高的典型是實時交互類業(yè)務(wù)比如遠(yuǎn)程操作的指令下發(fā)。這類場景對丟包的容忍度其實不高但對確定性延遲的要求極高寧可快速失敗讓上層做降級也不能出現(xiàn)幾百毫秒的不可預(yù)測停頓。至于一對多組播和廣播是 UDP 獨占的能力做局域網(wǎng)設(shè)備發(fā)現(xiàn)、行情推送、流媒體分發(fā)時幾乎繞不開。反過來說凡是每條消息都必須到達(dá)、順序不能亂、數(shù)據(jù)量還不小的場景老老實實用 TCP 或者基于 UDP 的成熟可靠傳輸方案自己從零寫一套可靠層大概率會在某個邊界條件上翻車。2. 拆開那8個字節(jié)UDP首部字段與偽首部校驗的完整推演2.1 四個字段各自的職責(zé)與邊界UDP 首部固定 8 字節(jié)四個 16 位字段簡單到可以背下來但每個字段的邊界條件都值得說清楚。源端口和目的端口各 2 字節(jié)取值范圍 0~65535。源端口在多數(shù)客戶端場景下由內(nèi)核自動分配走的是臨時端口范圍Linux 上默認(rèn)是net.ipv4.ip_local_port_range定義的那一段。這里有個容易被忽略的限制單個客戶端 IP 對同一個服務(wù)端IP:Port組合理論上最多只能建立 65535 個不同的源端口會話做大規(guī)模長連接或高并發(fā) UDP 會話時這個上限會先于帶寬成為瓶頸。解決辦法是多綁幾個本地 IP或者用多臺機器分?jǐn)偂ｉL度字段 2 字節(jié)指的是首部 數(shù)據(jù)的總長度最小值是 8純首部、無數(shù)據(jù)最大值是 65535。注意它統(tǒng)計的是 UDP 層的長度不含 IP 首部。IPv4 下 UDP 載荷最大是 65535 - 8 - 20 65507 字節(jié)IPv6 下因為 UDP 長度字段可以為 0走 Jumbogram 擴展理論上能更大但實際工程中幾乎沒人這么用。校驗和字段 2 字節(jié)覆蓋范圍包括偽首部、UDP 首部和數(shù)據(jù)。在 IPv4 里它是可選的填 0 表示發(fā)送端不計算校驗和接收端也不校驗在 IPv6 里它是強制的填 0 是非法值。實踐中我不建議關(guān)掉它因為關(guān)掉之后錯包只能靠上層協(xié)議自己發(fā)現(xiàn)而很多上層協(xié)議并沒有做這件事。提示判斷一個 UDP 包是否真的到了應(yīng)用層看的是應(yīng)用有沒有recvfrom到它而不是發(fā)送端有沒有返回成功。sendto返回的字節(jié)數(shù)只代表數(shù)據(jù)進入了本機 socket 發(fā)送緩沖區(qū)和對面是否收到?jīng)]有任何關(guān)系。2.2 校驗和為什么要把偽首部算進去偽首部這個概念初次接觸時很反直覺——它并不在網(wǎng)絡(luò)上真實傳輸只是參與校驗和計算時臨時拼出來的 12 字節(jié)IPv4或 40 字節(jié)IPv6結(jié)構(gòu)。IPv4 的偽首部包含源 IP、目的 IP、一個保留字節(jié)、協(xié)議號UDP 是 17和 UDP 長度IPv6 的偽首部包含 16 字節(jié)源地址、16 字節(jié)目的地址、4 字節(jié)上層報文長度、3 字節(jié)零和 1 字節(jié)下一首部值。為什么要多此一舉因為如果只校驗 UDP 首部和數(shù)據(jù)那么一個被錯誤路由到本機的包只要它內(nèi)部數(shù)據(jù)自洽校驗就能通過應(yīng)用會收到一個看起來合法但不屬于自己的報文。把 IP 地址納入校驗范圍之后地址在傳輸過程中被篡改或出錯的情況就能被檢出。這是一個很樸素但有效的設(shè)計用上層校驗覆蓋下層關(guān)鍵字段。計算過程本身是標(biāo)準(zhǔn)的 16 位反碼求和把偽首部、UDP 首部校驗和字段先置 0和數(shù)據(jù)按 16 位一組切開逐組相加進位回卷加到低位最后取反碼。有一個細(xì)節(jié)值得記住如果計算結(jié)果恰好是 0x0000發(fā)送時要寫成 0xFFFF因為全 0 在校驗和字段里有未計算的特殊含義兩者在反碼運算里是等價的但語義不能混。# 手工計算 UDP 校驗和的最小示例用于理解過程 def udp_checksum(src_ip, dst_ip, payload: bytes, src_port, dst_port): udp_len 8 len(payload) pseudo src_ip dst_ip bytes([0, 17]) udp_len.to_bytes(2, big) udp_hdr src_port.to_bytes(2, big) dst_port.to_bytes(2, big) \ udp_len.to_bytes(2, big) b\x00\x00 data pseudo udp_hdr payload if len(data) % 2: data b\x00 total 0 for i in range(0, len(data), 2): total (data[i] 8) data[i 1] total (total 0xFFFF) (total 16) total ~total 0xFFFF return total if total ! 0 else 0xFFFF實際抓包時你會看到校驗和錯誤的包在大部分網(wǎng)卡上會被硬件直接丟掉只有開了混雜模式或者網(wǎng)卡關(guān)閉了校驗和卸載checksum offload才能抓到。這也是為什么用tcpdump在本機抓包看到包明明在但應(yīng)用收不到——很可能就是校驗和有問題被丟了。排查這類問題時先看一眼/proc/net/snmp里的InCsumErrors計數(shù)比盲猜快得多。2.3 抓包對照一個1472字節(jié)的包長什么樣理解協(xié)議最快的方式還是看真實報文。以太網(wǎng) MTU 是 1500 字節(jié)扣掉 20 字節(jié) IPv4 首部和 8 字節(jié) UDP 首部UDP 載荷上限就是 1472 字節(jié)。這個數(shù)字在工程中出現(xiàn)頻率極高很多采集類系統(tǒng)就是按 1472 來切包目的就是讓每個 UDP 報文塞進一個以太網(wǎng)幀避免 IP 分片。下面是一個典型的 1472 字節(jié)載荷的 UDP 報文在tcpdump里的樣子十六進制部分略去數(shù)據(jù)區(qū)IP 10.0.0.12.54321 10.0.0.34.9000: UDP, length 1472 0x0000: 4500 05dc 1a2b 4000 4011 8f3c 0a00 000c 0x0010: 0a00 0022 d431 2328 05dc 1a2e逐段讀4500是 IPv4 版本 4 加首部長度 55×420 字節(jié)05dc是總長度 15001a2b是標(biāo)識4000里高 3 位是標(biāo)志DF 位置 1表示不分片4011里40是 TTL 6411是協(xié)議號 17 也就是 UDP后面是首部校驗和與源目 IP。再往后d431是源端口 543212328是目的端口 900005dc是 UDP 長度 15001a2e是校驗和。從這個報文能讀出兩件事第一UDP 長度字段填的是 1500包含了 8 字節(jié)首部所以載荷是 1492不對這里我做個小修正——如果 UDP 長度是 1500那 IP 總長度應(yīng)該是 1520但以太網(wǎng) MTU 只有 1500所以這個包必然分片。真正不分片的情況下UDP 長度字段應(yīng)該是 14801472 載荷 8 首部IP 總長度 1500。第二DF標(biāo)志位一旦置 1任何加上了首部之后超過 MTU 的包都會被中間設(shè)備丟棄并回一個 ICMP 需要分片的消息這反而是件好事——它讓問題暴露出來而不是被悄悄分片。3. 無連接不等于無責(zé)任把可靠性補在上層還是在中間件3.1 可靠UDP的四種典型補全路線既然 UDP 不保證送達(dá)那保證送達(dá)這件事就得有人做。業(yè)界大致有四條路線選哪條取決于你的業(yè)務(wù)邊界和對可控性的要求。第一條是自己寫最小可靠層。核心就三件事給每個報文加序號、接收端回確認(rèn)、發(fā)送端維護重傳隊列。聽起來簡單但一旦要考慮亂序、去重、窗口、超時估算代碼量就會迅速膨脹到幾千行而且?guī)缀醣厝粫┑裟硞€邊界條件。我只建議在報文語義非常簡單、丟包容忍度較高的場景下自己寫比如局域網(wǎng)內(nèi)的控制指令通道。第二條是在 UDP 之上套一層成熟的可靠傳輸協(xié)議。QUIC 是最典型的代表它在 UDP 之上重建了可靠流、擁塞控制、多路復(fù)用還順帶把 TLS 1.3 集成進來解決了隊頭阻塞問題。如果你的場景是需要一個比 TCP 更快的可靠傳輸QUIC 基本是首選不用自己造。KCP 是另一個選擇它用犧牲部分帶寬換取更低延遲的策略在同等的丟包率下延遲表現(xiàn)通常優(yōu)于 TCP代價是流量放大約 10%~20%。第三條是用 RTP/RTCP 這類面向媒體的協(xié)議棧。它們不強求每個包都到而是通過序列號、時間戳和接收端報告來做丟包隱藏、抖動緩沖和碼率自適應(yīng)。做音視頻的話這條路是標(biāo)準(zhǔn)答案。第四條是在應(yīng)用層做冪等加補償。傳輸層索性不保證業(yè)務(wù)層通過消息 ID 去重、定時對賬、定期全量同步來兜底。這條路線對基礎(chǔ)設(shè)施改動最小適合內(nèi)部系統(tǒng)之間的數(shù)據(jù)上報。路線典型方案適用場景主要代價自研最小可靠層序號 ACK 重傳隊列語義簡單的控制通道邊界條件多維護成本高成熟可靠傳輸協(xié)議QUIC、KCP需要可靠且低延遲的數(shù)據(jù)流需要引入額外依賴或改造接入層媒體協(xié)議棧RTP/RTCP、SRTP音視頻、實時流需要配套的抖動緩沖與擁塞控制應(yīng)用層冪等補償消息 ID 去重 對賬內(nèi)部數(shù)據(jù)上報、日志采集有延遲需要業(yè)務(wù)側(cè)配合3.2 重傳、序號與擁塞控制的最小實現(xiàn)骨架如果你確實要自己寫一層那么有幾個設(shè)計決策必須先定下來它們是后續(xù)所有問題的根源。序號怎么編。單調(diào)遞增的 32 位或 64 位整數(shù)是最常見的做法回繞問題一定要提前想清楚比較大小的時候用差值而不是直接比大小。另一種是包序號加時間戳的組合好處是能同時支撐亂序重組和 RTT 估算。ACK 怎么回。逐包 ACK 在包量大時會把上行帶寬吃光通常用累積 ACK 加選擇性 ACK 的組合告訴對端我連續(xù)收到了到 N 為止的所有包另外還額外收到了這幾個。ACK 本身也要做聚合比如每收到 2 個包或者每 10ms 回一次。重傳超時怎么定。固定超時是最簡單也最容易出問題的做法。稍微認(rèn)真一點的做法是維護 RTT 的平滑值和方差超時時間取平滑 RTT 加上若干倍方差同時設(shè)一個下限比如 50ms避免在低延遲鏈路上因為抖動觸發(fā)大量無謂重傳。擁塞控制要不要做。這一條最容易被省略也是自研可靠層在生產(chǎn)環(huán)境翻車的主要原因。沒有擁塞控制一旦鏈路出現(xiàn)丟包發(fā)送端還在全速發(fā)只會讓丟包率進一步上升最終整條鏈路退化到幾乎不可用。哪怕只做一個最簡單的版本——丟包時把發(fā)送速率減半一段時間無丟包再線性增長——也比完全沒有強得多。# 極簡的 RTT 估算與重傳超時計算只演示思路 class RttEstimator: def __init__(self): self.srtt None # 平滑 RTT self.rttvar None # RTT 方差 self.min_rto 0.05 # 50ms 下限 def update(self, sample): if self.srtt is None: self.srtt sample self.rttvar sample / 2 else: self.rttvar 0.75 * self.rttvar 0.25 * abs(self.srtt - sample) self.srtt 0.875 * self.srtt 0.125 * sample def rto(self): if self.srtt is None: return 0.2 return max(self.min_rto, self.srtt 4 * self.rttvar)3.3 別自己造輪子什么情況下該直接上成熟方案有個很實用的判斷原則如果你的可靠層需要處理連接遷移多路復(fù)用加密握手路徑 MTU 發(fā)現(xiàn)中的任意兩項以上就別自己寫了。這四件事每一項單獨做都不算難但組合起來的復(fù)雜度是指數(shù)級上升的而且出問題的時候極難復(fù)現(xiàn)。QUIC 已經(jīng)把這些都做完了而且有成熟的開源實現(xiàn)可以直接嵌入語言覆蓋也夠全。真正適合自研的場景通常是協(xié)議語義極簡比如只有固定 32 字節(jié)的狀態(tài)包、運行環(huán)境受限嵌入式設(shè)備內(nèi)存只有幾十 KB、或者需要和已有協(xié)議做深度耦合比如自定義的私有協(xié)議棧已經(jīng)有大量存量設(shè)備。還有一種情況值得單獨提只是想在局域網(wǎng)內(nèi)做高可靠傳輸。局域網(wǎng)丟包率極低鏈路 RTT 通常小于 1ms這種情況下可靠的實現(xiàn)難度會大幅下降簡單的序號加超時重傳就夠用不需要復(fù)雜的擁塞控制。但要注意一旦這套東西要跨公網(wǎng)前面的假設(shè)就全部失效了。4. 緩沖區(qū)、MTU與IO模型UDP工程化的三個硬約束4.1 接收緩沖區(qū)溢出UDP丟包最常見的一號元兇回到開頭那個 5% 丟包的故事根因就是接收緩沖區(qū)。這里把機制講透。每個 UDP socket 在內(nèi)核里有一塊接收緩沖區(qū)大小由net.core.rmem_default決定可以用SO_RCVBUF調(diào)整。數(shù)據(jù)到達(dá)網(wǎng)卡之后經(jīng)過驅(qū)動、協(xié)議棧最終掛到這個 socket 的接收隊列上。應(yīng)用調(diào)用recvfrom時從隊列里取走一個數(shù)據(jù)報。如果隊列滿了新到的包直接被丟棄不通知發(fā)送端也不通知接收端最多在/proc/net/snmp的RcvbufErrors計數(shù)上加一。這意味著兩件事。第一UDP 的丟包在緩沖區(qū)這一層是靜默的只能靠計數(shù)器事后發(fā)現(xiàn)。第二能不能扛住突發(fā)流量取決于緩沖區(qū)能裝下多少個包。舉個具體的數(shù)假設(shè)單個報文 1200 字節(jié)緩沖區(qū)設(shè)為 2MB那么大約能緩存的報文數(shù)是 2097152 / 1200 ≈ 1747 個扣除內(nèi)核的結(jié)構(gòu)體開銷實際更少。如果應(yīng)用處理能力是每秒 5 萬包那么 2MB 緩沖區(qū)只能吸收約 35ms 的處理停頓。一旦發(fā)生一次 100ms 的 GC 或者磁盤抖動溢出就是必然的。所以調(diào)緩沖區(qū)之前先算清楚兩個數(shù)峰值收包速率和最長處理停頓時間兩者相乘就是最低需要的緩沖字節(jié)數(shù)再乘個 1.5 的安全系數(shù)。# 查看當(dāng)前系統(tǒng)的 UDP 相關(guān)統(tǒng)計重點看 RcvbufErrors netstat -su | grep -A 10 ^Udp: # 或者直接讀 proc cat /proc/net/snmp | grep ^Udp: # 查看內(nèi)核緩沖區(qū)上限 sysctl net.core.rmem_default net.core.rmem_max sysctl net.core.netdev_max_backlog # tcpdump 之外用 ss 看接收隊列積壓情況 ss -u -a -n -i調(diào)優(yōu)的時候有幾個容易踩的坑。第一個是SO_RCVBUF設(shè)置的值會被內(nèi)核翻倍用于內(nèi)部簿記開銷所以設(shè)置 4MB 實際得到 8MB反過來說如果你讀回來是 8MB 不要驚訝。第二個是設(shè)置值受net.core.rmem_max限制超過部分會被靜默截斷所以必須先把 sysctl 調(diào)大。第三個是netdev_max_backlog這個參數(shù)管的是網(wǎng)卡到協(xié)議棧之間的隊列很多人在收包瓶頸時只調(diào)了 socket 緩沖區(qū)忘了這一層也會丟包現(xiàn)象是RcvbufErrors不漲但包就是少了。注意一味把緩沖區(qū)調(diào)大并不是好事。緩沖區(qū)越大應(yīng)用處理不過來時積壓的包越多而這些包往往已經(jīng)過時處理它們只是浪費 CPU還會掩蓋真實的問題。合理的做法是調(diào)到能吸收正常的抖動就夠了然后通過監(jiān)控RcvbufErrors來持續(xù)觀察。4.2 MTU與IP分片1472這個數(shù)字的來歷和它的陷阱前面提到 1500 減去 20 減 8 得到 1472這是 IPv4 下的經(jīng)典值。IPv6 的首部是 40 字節(jié)所以對應(yīng)的值是 1500 - 40 - 8 1452。除此之外還有幾層封裝會繼續(xù)吃掉空間PPPoE 要扣 8 字節(jié)VXLAN 要扣 50 字節(jié)GRE 要扣 24 字節(jié)IPsec 隧道也要扣掉幾十字節(jié)。這就是為什么在云上或者跨專線的環(huán)境里按 1472 發(fā)包很可能直接被丟。分片的機制是這樣的如果 IP 層的包超過了出接口 MTU且沒有設(shè)置 DF 標(biāo)志IP 層會把它切成多個分片分別發(fā)送接收端根據(jù) IP 首部的標(biāo)識、偏移和 MF 標(biāo)志重組。問題在于只要任何一個分片丟失整個原始數(shù)據(jù)報就作廢接收端無法交付半個 UDP 報文。而且重組需要占用接收端的內(nèi)存緩沖區(qū)還有超時限制。在丟包率 1% 的鏈路上發(fā)一個 8000 字節(jié)的包需要切成 6 個分片只要其中一個丟了整包重傳實際有效丟包率會放大到接近 6%。所以工程上的原則很明確盡量不讓 UDP 報文觸發(fā) IP 分片。具體做法有幾個層次一是把應(yīng)用層的報文大小控制在 1200 字節(jié)左右。這個數(shù)字不是隨便定的QUIC 選它是因為 IPv6 的最小 MTU 要求是 1280減去 40 字節(jié) IPv6 首部和 8 字節(jié) UDP 首部正好剩 1232再留一點余量給隧道封裝。按 1200 來切包走絕大多數(shù)網(wǎng)絡(luò)都不會分片。二是開啟路徑 MTU 發(fā)現(xiàn)PMTUD也就是設(shè)置IP_MTU_DISCOVER為IP_PMTUDISC_DO讓內(nèi)核在包超過 MTU 時返回EMSGSIZE而不是默默分片。這樣問題會在發(fā)送端立刻暴露而不是變成對端的神秘丟包。但 PMTUD 依賴 ICMP 反饋而很多網(wǎng)絡(luò)會屏蔽 ICMP所以實踐中通常還會配一個保守的兜底值。三是如果真的需要傳大塊數(shù)據(jù)在應(yīng)用層做分片和重組自己維護分片序號和超時丟棄而不是依賴 IP 層。import socket sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) # 禁止 IP 層分片超過 MTU 直接報 EMSGSIZE sock.setsockopt(socket.IPPROTO_IP, socket.IP_MTU_DISCOVER, socket.IP_PMTUDISC_DO) # 設(shè)置發(fā)送與接收緩沖區(qū) sock.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 4 * 1024 * 1024) sock.setsockopt(socket.SOL_SOCKET, socket.SO_SNDBUF, 1 * 1024 * 1024) try: sock.sendto(bx * 2000, (10.0.0.34, 9000)) except OSError as e: # 在開啟了 PMTUD 的情況下超長報文會拋 EMSGSIZE print(send failed:, e)4.3 單socket還是多socket并發(fā)收包的幾種組織方式UDP 是無連接的一個 socket 天然就能處理來自任意客戶端的報文所以最直觀的寫法是單線程recvfrom加業(yè)務(wù)分發(fā)。這種寫法在低流量下完全夠用但流量一大就會遇到兩個問題單核打滿以及前面提到的緩沖區(qū)溢出。往下走有幾條路各有利弊。多線程共享同一個 socket。多個線程同時recvfrom內(nèi)核會加鎖串行化實際吞吐提升有限而且在高并發(fā)下鎖競爭反而會拖慢。這條路我不太推薦除非線程數(shù)很少。多進程綁同一個端口加SO_REUSEPORT。內(nèi)核會按四元組哈希把報文分發(fā)到不同的 socket每個進程各自處理互不干擾。這是目前 Linux 上最實用的方案擴展性好進程掛掉一個也只影響一部分流量。缺點是哈希固定某個熱點客戶端可能一直落在同一個進程上需要靠增加分片數(shù)來攤平。另外要注意SO_REUSEPORT的負(fù)載均衡是按流做的對于 UDP 來說流就是四元組所以同一對 IP 端口之間的所有報文會固定落到同一個 socket。單線程加epoll加批量收取。recvmmsg一次系統(tǒng)調(diào)用可以收多個數(shù)據(jù)報能顯著降低系統(tǒng)調(diào)用開銷。在 10 萬 pps 這個量級批量收取帶來的提升是肉眼可見的。配合sendmmsg批量發(fā)送單核處理能力可以再上一個臺階。內(nèi)核旁路方案。當(dāng)單機需要處理百萬級 pps 時常規(guī)協(xié)議棧的開銷就成了瓶頸這時候會考慮 DPDK、AF_XDP 這類方案把網(wǎng)卡數(shù)據(jù)直接搬到用戶態(tài)。代價是復(fù)雜度陡增需要獨占網(wǎng)卡、自己做協(xié)議棧運維和調(diào)試成本都很高。除非確實撞到了性能墻否則我不建議走這條路。方案適用規(guī)模優(yōu)點主要限制單線程 recvfrom萬 pps 以下實現(xiàn)最簡單單核上限無冗余多線程共享 socket萬級 pps改動小鎖競爭擴展性差多進程 SO_REUSEPORT十萬級 pps水平擴展容錯好哈希傾斜需調(diào)分片數(shù)recvmmsg 批量收發(fā)十萬級 pps系統(tǒng)調(diào)用開銷低需要處理批量語義AF_XDP / DPDK百萬級 pps極致性能復(fù)雜度高運維成本大5. 廣播、組播與穿透邊界UDP的拓?fù)淠芰εc限制5.1 單播之外的三種尋址方式TCP 只能一對一這是它的設(shè)計前提。UDP 支持三種額外的尋址方式這是它在某些場景下不可替代的根本原因。廣播發(fā)往本地網(wǎng)段內(nèi)的所有主機。IPv4 里有受限廣播地址 255.255.255.255 和子網(wǎng)廣播地址比如 192.168.1.255。使用前必須在 socket 上設(shè)置SO_BROADCAST選項否則會返回權(quán)限錯誤。廣播的局限很明顯不跨路由器只在本地網(wǎng)段有效而且所有主機都要消耗資源處理這個包網(wǎng)段里設(shè)備一多就會造成明顯的廣播風(fēng)暴。組播是更精細(xì)的方案發(fā)送方把包發(fā)到一個組播地址只有加入了該組的主機才會收到。IPv4 的組播地址范圍是 224.0.0.0/4其中 224.0.0.0/24 是本地鏈路保留段像 mDNS 用的 224.0.0.251、SSDP 用的 239.255.255.250 都屬于約定俗成的固定地址。使用組播需要加入組IP_ADD_MEMBERSHIP并關(guān)注 TTL 設(shè)置——組播包的 TTL 決定了它能跨多少個路由器默認(rèn)值 1 意味著只在本地網(wǎng)段生效。任播在 UDP 層面沒有專門的支持它是靠路由層面把同一個地址宣告到多個位置來實現(xiàn)的客戶端看起來是在單播實際被路由到了最近的一個節(jié)點。很多公共 DNS 服務(wù)用的就是這套機制。import socket, struct # 加入組播組并接收 sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP) sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) sock.bind((, 5353)) mreq struct.pack(4s4s, socket.inet_aton(224.0.0.251), socket.inet_aton(0.0.0.0)) sock.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq) while True: data, addr sock.recvfrom(2048) print(addr, len(data))實踐中組播最大的坑在于中間網(wǎng)絡(luò)設(shè)備對組播的支持程度參差不齊。交換機需要開啟 IGMP snooping 才能避免把組播泛洪成廣播路由器需要配置 PIM 才能跨網(wǎng)段轉(zhuǎn)發(fā)云環(huán)境里組播往往直接被禁用。所以組播方案在落地前一定要先在目標(biāo)網(wǎng)絡(luò)環(huán)境里做連通性驗證不能想當(dāng)然。5.2 NAT與連接跟蹤UDP會話為什么放著放著就斷了UDP 本身沒有連接概念但中間設(shè)備為了做地址轉(zhuǎn)換和狀態(tài)過濾會給它維護一份會話表。這份表的條目是有超時時間的一旦超時表項被刪除后續(xù)的包就會被丟棄或者拒絕。不同設(shè)備的默認(rèn)超時差異很大。常見的家用路由器和運營商級 NAT 上UDP 會話的空閑超時可能在 30 秒到 5 分鐘之間。這意味著如果一個 UDP 會話超過這個時間沒有任何報文往來通道就會被回收。表現(xiàn)出來就是客戶端和服務(wù)端都覺得自己還活著但包發(fā)不過去了。解決辦法很直接——保活。定期發(fā)一個小的探測包讓中間設(shè)備的狀態(tài)表保持活躍。間隔要比最短的超時時間更短實踐中常用 15 到 25 秒。但?；畋旧硪灿写鷥r移動端上頻繁喚醒無線網(wǎng)卡會顯著增加耗電所以在移動場景里需要配合應(yīng)用層的前后臺狀態(tài)來動態(tài)調(diào)整。還有一種更隱蔽的情況NAT 設(shè)備重啟或者表項被提前回收但客戶端仍然按原來的映射發(fā)數(shù)據(jù)這時候包會被丟棄而服務(wù)端完全不知道。所以客戶端必須有一個長時間收不到響應(yīng)就重建會話的機制不能假設(shè)通道一直有效。提示Linux 上的nf_conntrack_udp_timeout和nf_conntrack_udp_timeout_stream兩個參數(shù)控制 UDP 連接跟蹤的超時前者用于沒有回包的會話默認(rèn) 30 秒后者用于雙向都有流量的會話默認(rèn) 120 秒。做網(wǎng)關(guān)或代理類服務(wù)時這兩個值往往要調(diào)大。5.3 反射放大風(fēng)險與必須做的收口UDP 有一個天然的安全弱點源地址可以偽造。因為不需要握手攻擊者可以偽造受害者的 IP 向服務(wù)發(fā)送請求服務(wù)把響應(yīng)發(fā)給了受害者。如果請求很小而響應(yīng)很大就形成了放大效應(yīng)。DNS、NTP、SSDP 這些基于 UDP 的服務(wù)歷史上都因為這個問題被濫用過。作為服務(wù)提供方該做的事情很明確而且都是常規(guī)工程手段對無認(rèn)證的請求做響應(yīng)大小限制。如果協(xié)議允許把響應(yīng)控制在請求大小的一定倍數(shù)以內(nèi)最理想的是不超過請求本身的大小。對來源做速率限制和異常檢測。同一來源在短時間內(nèi)發(fā)送大量請求時降低響應(yīng)優(yōu)先級或者直接丟棄。注意這里要小心誤傷NAT 后面的合法用戶共享一個出口 IP限速閾值要留足余量。能加認(rèn)證就加認(rèn)證。哪怕是最簡單的 cookie 機制也能讓偽造源地址的攻擊者收不到有效響應(yīng)因為第二個包需要帶上第一個包里的隨機值。別暴露不必要的服務(wù)。開放的調(diào)試接口、狀態(tài)查詢接口如果響應(yīng)很大又不需要認(rèn)證就是最理想的放大工具。這類接口應(yīng)該只監(jiān)聽內(nèi)網(wǎng)地址或者干脆默認(rèn)關(guān)閉。做入口流量清洗。對于規(guī)模較大的服務(wù)上游的流量清洗是兜底手段但這是最后一道防線不能替代前面的收口。6. 選型決策與壓測把UDP用在正確的地方6.1 一張對照表什么時候選UDP什么時候老實回TCP做了這么多年前后端我發(fā)現(xiàn)選型失誤的根源往往不是技術(shù)能力不夠而是問題定義不清楚。下面這張表是我自己常用的判斷依據(jù)按場景歸類。場景特征推薦選擇理由音視頻通話、直播推流UDPRTP/WebRTC丟包可隱藏重傳無意義實時游戲狀態(tài)同步UDP狀態(tài)有時效性舊包無用高頻行情推送UDP 組播優(yōu)先一對多延遲敏感局域網(wǎng)設(shè)備發(fā)現(xiàn)UDP 廣播/組播TCP 不支持一對多大文件傳輸TCP 或 QUIC需要可靠且有序支付、訂單類業(yè)務(wù)TCP不允許丟消息語義強依賴順序內(nèi)部服務(wù)間 RPCTCP 或 QUIC生態(tài)成熟調(diào)試工具全指標(biāo)采集、日志上報UDP 加應(yīng)用層補償量大允許少量丟失跨公網(wǎng)的穩(wěn)定長連接QUIC基于 UDP兼顧低延遲與可靠性有個判斷技巧值得分享問自己如果這條消息丟了業(yè)務(wù)能不能自己發(fā)現(xiàn)并補救。如果能UDP 是可以考慮的如果不能而且補救成本很高那還是老實上可靠傳輸。很多團隊選 UDP 是覺得性能好但實際瓶頸根本不在傳輸層換過去之后性能沒提升多少可靠性問題倒是接二連三。6.2 壓測怎么做才有意義指標(biāo)、工具與觀測點UDP 的壓測和 TCP 差別很大因為發(fā)送端收不到任何反饋很容易測出發(fā)送 100 萬包全部成功這種毫無意義的結(jié)論。有效的壓測必須同時在發(fā)送端和接收端埋點然后對賬。發(fā)送端要記錄的是應(yīng)用層調(diào)用sendto的次數(shù)、成功次數(shù)、失敗次數(shù)區(qū)分EAGAIN、EMSGSIZE、ENOBUFS等錯誤碼、實際發(fā)出的字節(jié)數(shù)。接收端要記錄的是recvfrom收到的包數(shù)、字節(jié)數(shù)、丟包數(shù)發(fā)送數(shù)減接收數(shù)、亂序數(shù)、重復(fù)數(shù)、端到端延遲分布。工具方面iperf3的 UDP 模式可以做基礎(chǔ)帶寬測試但它只能告訴你吞吐和丟包率測不出應(yīng)用層的處理能力。真正壓業(yè)務(wù)邏輯還得自己寫客戶端或者用現(xiàn)成的壓測框架。我通常會用一個小腳本做發(fā)包接收端跑真實服務(wù)并暴露 Prometheus 指標(biāo)這樣能得到最貼近生產(chǎn)的結(jié)論。觀測點上除了應(yīng)用層指標(biāo)一定要看這幾個內(nèi)核計數(shù)器# UDP 層統(tǒng)計重點是 InErrors / RcvbufErrors / SndbufErrors / InCsumErrors cat /proc/net/snmp | grep ^Udp: # 網(wǎng)卡層丟棄看 drop 和 fifo 兩列 ip -s link show eth0 # socket 隊列積壓 ss -u -a -n -i | head -20 # 中斷分布如果集中在單個核上說明需要開 RSS 或者調(diào)整親和性 cat /proc/interrupts | grep eth0壓測的節(jié)奏也要注意。不要一上來就打滿應(yīng)該從小到大分幾檔每一檔穩(wěn)定跑夠時間至少 60 秒讓緩沖區(qū)進入穩(wěn)態(tài)觀察各項指標(biāo)隨流量增長的變化曲線。如果丟包率在某個流量點突然從 0 跳到明顯的百分比那個點就是系統(tǒng)的實際容量上限比理論計算值靠譜得多。6.3 上線前的檢查清單按我自己的習(xí)慣UDP 服務(wù)上線前會過一遍下面這些項每一條都對應(yīng)過真實的故障。報文大小是否控制在 1200 字節(jié)以內(nèi)有沒有針對隧道封裝的余量。曾經(jīng)有個服務(wù)在測試環(huán)境跑得好好的上了生產(chǎn)走了 VXLAN 隧道1500 的包全部被丟因為隧道封裝后又多了 50 字節(jié)。緩沖區(qū)是否按峰值速率和最長停頓算過rmem_max和netdev_max_backlog是否同步調(diào)過。這兩個不一起調(diào)光調(diào)前者沒用。保活機制是否存在間隔是否短于目標(biāo)網(wǎng)絡(luò)的最短 NAT 超時?？邕\營商、跨云廠商的鏈路超時值差異會很大。錯誤處理是否覆蓋了EAGAIN、EMSGSIZE、ECONNREFUSED。特別是ECONNREFUSED在對端沒監(jiān)聽的時候如果 socket 調(diào)過connectrecvfrom會收到這個錯誤很多人沒處理導(dǎo)致進程直接崩掉。監(jiān)控是否覆蓋了接收側(cè)丟包、緩沖區(qū)溢出、校驗和錯誤、亂序和重復(fù)。只在發(fā)送端埋點是不夠的發(fā)送端的成功什么都不能說明。限速與收口是否做了特別是響應(yīng)大小和來源速率。這一條經(jīng)常被當(dāng)成以后再說然后就沒有以后了。容量驗證是否在真實網(wǎng)絡(luò)拓?fù)渖献鲞^而不是只在同機房的低延遲環(huán)境里跑。同機房 RTT 小于 0.5ms跨公網(wǎng)可能 30ms 以上緩沖區(qū)需求差了幾十倍?；赝朔桨甘欠駵?zhǔn)備好。UDP 服務(wù)出問題時能不能快速切回 TCP 或者降級到低頻上報這個開關(guān)要提前做好。最后分享一個我自己踩過的坑。有次排查一個偶發(fā)的丟包問題各種計數(shù)器都正常緩沖區(qū)沒溢出網(wǎng)卡沒丟包鏈路也沒問題最后發(fā)現(xiàn)是應(yīng)用層的線程池隊列滿了任務(wù)被靜默丟棄但日志里只記了處理成功——因為丟棄發(fā)生在一個try/except的寬泛捕獲里。這件事之后我改了一個習(xí)慣凡是可能靜默丟棄數(shù)據(jù)的地方無論在哪一層都必須有一個計數(shù)器哪怕只是一個內(nèi)存里的累加值定期打到日志里。UDP 這套架構(gòu)最大的特點就是沒有反饋你必須自己造出反饋來否則排查問題的時候只能靠猜而猜出來的結(jié)論往往離真相很遠(yuǎn)。