我最早意識到必須把STUN協(xié)議啃明白是因為一個特別普通的故障兩臺客戶端都連著同一個信令服務(wù)狀態(tài)欄也都顯示在線可一旦要建立點對點通道數(shù)據(jù)包發(fā)出去就像石沉大海。排查了整整兩天最后定位到的問題不在你我寫的代碼而是雙方都躲在NAT后面彼此根本不知道對方暴露在公網(wǎng)上的真實地址。STUN協(xié)議全稱Session Traversal Utilities for NAT就是專門回答我的公網(wǎng)映射地址到底是什么這個問題的協(xié)議。這篇文章我會從NAT的底層行為講起拆解一次完整的STUN交互報文給你一份能直接跑起來的最小客戶端代碼然后講清楚STUN的邊界在哪、TURN和ICE分別補了什么最后是在實際接入過程中積累的調(diào)試經(jīng)驗和運維教訓(xùn)。做音視頻應(yīng)用、P2P傳輸或者只是單純被NAT問題折騰過的同學(xué)這篇應(yīng)該能幫上忙。1. 從一次失敗的P2P連接說起NAT才是真正的攔路虎1.1 兩個客戶端明明在線為什么就是連不上假設(shè)A同學(xué)在家里B同學(xué)在辦公室兩人用同一個App聊天、傳文件。信令服務(wù)器兩邊都連通好友狀態(tài)也是綠的。但A向B發(fā)一個UDP包B收不到B回一個A也收不到。問題不在應(yīng)用邏輯而在IP包從A出發(fā)那一刻就變樣了。A的電腦通常在192.168.1.0/24這類內(nèi)網(wǎng)網(wǎng)段家里的路由器做了網(wǎng)絡(luò)地址轉(zhuǎn)換。A發(fā)出一個源地址為192.168.1.10:50000的包路由器會把它改寫成公網(wǎng)IP加臨時端口比如203.0.113.7:54321然后在自己的映射表里記一筆內(nèi)網(wǎng)(192.168.1.10:50000)對應(yīng)公網(wǎng)(203.0.113.7:54321)。B收到的任何來自這個地址的流量A才能收到其他陌生地址打進來的包大概率會被路由器按過濾策略丟棄。這就是NAT的核心矛盾它只對由內(nèi)向外主動發(fā)起的會話做一個臨時的、有狀態(tài)的門禁對外部來說這個門禁地址是動態(tài)分配的。兩個客戶端都在NAT后面時A不知道自己在公網(wǎng)眼里的身份是203.0.113.7:54321B也不知道自己是198.51.100.9:60001各自拿自己網(wǎng)卡上的私網(wǎng)地址去通信自然誰也找不到誰。簽入信令服務(wù)器只能證明你能連上服務(wù)器完全不能證明你能被別人直連。打個比方NAT就像一個公司的前臺秘書。內(nèi)網(wǎng)員工只能讓秘書幫忙撥外線電話外線打進來必須先報出分機號可分機號是秘書臨時分配的外面的人不知道而且秘書默認(rèn)不轉(zhuǎn)接陌生來電。1.2 四種NAT行為決定了STUN能不能派上用場既然NAT是核心障礙那NAT的類型不同打通路徑的難度也完全不同。早期RFC 3489把NAT分成四種經(jīng)典類型現(xiàn)在看有點粗糙但用來建立直覺依然非常好用。NAT類型映射行為過濾行為STUN能搞定嗎全錐形 Full Cone內(nèi)網(wǎng)IP:端口固定映射為一個公網(wǎng)IP:端口不限制來源誰都能往這個映射地址發(fā)包最容易拿到映射地址就能直連受限錐形 Restricted Cone同上只允許我主動發(fā)過包的目標(biāo)IP給我回包需要先讓對端發(fā)探測包時序配合端口受限錐形 Port Restricted Cone同上只允許我主動發(fā)過包的目標(biāo)IP:端口回包打洞要精確卡端口難度提升一截對稱型 Symmetric每個目標(biāo)IP:端口都會新建一個不同映射通常也是端口受限過濾STUN學(xué)到的映射地址只在和該服務(wù)器通信時有效基本廢了現(xiàn)在RFC 5389和RFC 8489的視角更精細(xì)把NAT行為拆成兩個獨立的軸一個是映射行為一個是過濾行為。映射行為回答同一個內(nèi)網(wǎng)元組去訪問不同目標(biāo)時公網(wǎng)映射是否一樣過濾行為回答別人往這個映射地址發(fā)包NAT放不放行。家庭路由器絕大多數(shù)是端點無關(guān)映射 端點相關(guān)過濾也就是平時說的錐形NATSTUN能發(fā)揮價值。但運營商級NATCGNAT為了節(jié)省公網(wǎng)IPv4地址往往會做地址端口相關(guān)映射指向每一臺對端服務(wù)器時都臨時開出不同的公網(wǎng)端口行為接近對稱NAT。這也是為什么同樣的客戶端家庭寬帶下直連成功率尚可切到手機4G/5G網(wǎng)絡(luò)后成功率驟降——不是代碼壞了是NAT的映射行為變了。提示判斷一個環(huán)境是否對稱NAT最省錢的辦法就是拿兩個不同的STUN服務(wù)器分別查一次映射地址如果兩次學(xué)到的公網(wǎng)端口不一致說明映射行為與目標(biāo)地址相關(guān)基本可以斷定是對稱NAT。2. 一次Binding請求的完整解剖20字節(jié)頭部和一堆TLV2.1 STUN的核心邏輯讓公網(wǎng)服務(wù)器告訴你你看起來是誰STUN的設(shè)計思路非常直白你無法從內(nèi)網(wǎng)看到自己公網(wǎng)映射那就找一個站在公網(wǎng)上的服務(wù)器幫你照鏡子?？蛻舳藦哪硞€UDP socket發(fā)出一個Binding Request請求經(jīng)過NAT時被路由器改寫源地址STUN服務(wù)器收到這個包時看到的源IP和源端口就是這臺機器在公網(wǎng)上的臨時身份。服務(wù)器把這個身份塞進響應(yīng)報文的屬性里返回客戶端收到后自然就知道原來自己被映射成了什么樣子。這一個簡單的回聲機制解決的是信息問題。但記住一個關(guān)鍵前提服務(wù)器看到的映射是對應(yīng)這條五元組的映射。具體來說是(本地IP, 本地端口, 服務(wù)器IP, 服務(wù)器端口)這一組關(guān)系。將來客戶端想跟另一個對端B通信B的地址和服務(wù)器地址不同NAT可能為這個新目標(biāo)分配完全不同的公網(wǎng)端口。這個映射和目標(biāo)綁定的思想貫穿整個NAT穿透STUN也好、ICE也好都在圍著它打轉(zhuǎn)。2.2 報文結(jié)構(gòu)頭部與屬性STUN報文最前面是一個固定20字節(jié)的頭部所有字段都是大端序網(wǎng)絡(luò)字節(jié)序。字段長度說明消息類型2字節(jié)0x0001是Binding Request0x0101是成功響應(yīng)0x0111是錯誤響應(yīng)消息長度2字節(jié)從Magic Cookie之后的負(fù)載長度按字節(jié)計Magic Cookie4字節(jié)固定值0x2112A442用來快速識別STUN包Transaction ID12字節(jié)隨機值客戶端用來把響應(yīng)和請求對應(yīng)起來很多人看到Magic Cookie會覺得奇怪為什么一個協(xié)議要固定放這么個常數(shù)原因是它能讓接收方在同一個UDP端口上快速區(qū)分不同協(xié)議。在實時通信里同一端口上往往同時跑著RTP、RTCP、DTLS和STUN包RTP第一個字節(jié)高兩位是0b10DTLS也有自己的內(nèi)容類型取值而STUN頭部前四個字節(jié)是0x00 0x01 0x21 0x12識別起來極其廉價一個位運算就能完成分流。這在WebRTC這類高并發(fā)場景里是實打?qū)嵉男阅軆?yōu)化。頭部之后是一個接一個的屬性每個屬性都是TLV結(jié)構(gòu)2字節(jié)類型、2字節(jié)長度、若干字節(jié)的值不足4字節(jié)對齊時補零。屬性類型的最高位是有含義的如果置位表示必須理解服務(wù)器遇到不認(rèn)識但帶此位的屬性要返回420 Unknown Attribute否則可以靜默跳過。屬性類型值作用MAPPED-ADDRESS0x0001舊協(xié)議時代使用的映射地址只用于兼容老客戶端XOR-MAPPED-ADDRESS0x0020新標(biāo)準(zhǔn)推薦的映射地址做了異或編碼RESPONSE-SOURCE-ADDRESS0x002B響應(yīng)實際發(fā)出的源地址多出口場景下排障很有用ERROR-CODE0x0009錯誤響應(yīng)里攜帶的具體錯誤碼USERNAME / REALM / NONCE0x0006 / 0x0014 / 0x0015長程憑證鑒權(quán)用的用戶信息MESSAGE-INTEGRITY0x0008HMAC摘要用于校驗請求和響應(yīng)未被篡改FINGERPRINT0x8028CRC-32異或0x5354554E幫助接收端確認(rèn)這是STUN包2.3 XOR-MAPPED-ADDRESS的編碼為什么要繞一圈早期RFC 3489時代用的是MAPPED-ADDRESS直接明文返回IP和端口屬性值第一個字節(jié)是保留的0x00后面跟著地址族和地址。問題在于有些老式的NAT設(shè)備和中繼盒子會傻乎乎地掃描數(shù)據(jù)包只要看到長得像內(nèi)嵌公網(wǎng)IP的4字節(jié)就自作主張改寫導(dǎo)致明文地址被破壞。于是RFC 5389引入了XOR編碼把地址和端口跟固定值做異或后再傳輸讓數(shù)據(jù)不再長得像IP躲開那些不守規(guī)矩的中間設(shè)備。具體編碼規(guī)則是端口值先和Magic Cookie的高16位做異或也就是0x2112IPv4地址共4字節(jié)和Magic Cookie的4字節(jié)0x2112A442做異或IPv6地址共16字節(jié)則和Magic Cookie(4字節(jié)) Transaction ID(12字節(jié))拼接出的16字節(jié)整體做異或。解碼時再做一次同樣的異或就能還原。這也是為什么新寫的客戶端務(wù)必讀XOR-MAPPED-ADDRESS它對老NAT設(shè)備的兼容性更好也是RFC 8489時代的主流實現(xiàn)。3. 手寫一個最小STUN客戶端從構(gòu)造請求到解析映射地址的完整代碼3.1 準(zhǔn)備工作直接看文檔總歸隔靴搔癢我建議你動手寫一個最小實現(xiàn)。代碼只用Python標(biāo)準(zhǔn)庫不需要裝任何第三方依賴目標(biāo)是把請求構(gòu)造、發(fā)送、響應(yīng)解析整條鏈路跑通。生產(chǎn)環(huán)境不推薦這么裸寫語言生態(tài)里有成熟的開源STUN庫可以用但用最原始的方式過一遍你對協(xié)議的理解會完全不同。假設(shè)本機已經(jīng)安裝Python 3.8以上版本能聯(lián)網(wǎng)能發(fā)UDP包。測試用的服務(wù)器地址我先用stun.example.com占位實際部署時替換成你自己的服務(wù)地址或者云服務(wù)商公開提供的測試服務(wù)器地址。3.2 構(gòu)造Binding Request并發(fā)送先構(gòu)造20字節(jié)頭部。消息類型是0x0001Binding Request沒有負(fù)載所以長度字段為0再拼上4字節(jié)Magic Cookie和12字節(jié)隨機Transaction ID。import socket import struct import random MAGIC_COOKIE 0x2112A442 STUN_SERVER (stun.example.com, 3478) def make_binding_request(): msg_type 0x0001 # Binding Request msg_len 0 txn_id bytes(random.randrange(256) for _ in range(12)) header struct.pack(!HHI, msg_type, msg_len, MAGIC_COOKIE) txn_id return header, txn_id sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.settimeout(1.0) request, txn_id make_binding_request() sock.sendto(request, STUN_SERVER) try: data, addr sock.recvfrom(2048) except socket.timeout: print(timeout, retry...) sock.close()注意一點UDP不保證可靠交付生產(chǎn)代碼必須自帶重傳。STUN規(guī)范里還規(guī)定了按指數(shù)退避重發(fā)這個我們后面專門講。這里為了演示先保持單次收發(fā)后續(xù)補上重傳循環(huán)。3.3 解析Binding Response收到響應(yīng)后先校驗Transaction ID是否一致再遍歷屬性找到XOR-MAPPED-ADDRESS并解碼。下面是完整的解析函數(shù)。def parse_stun_response(data, txn_id): if len(data) 20: return None msg_type, msg_len, cookie struct.unpack(!HHI, data[:8]) resp_txn data[8:20] if resp_txn ! txn_id: print(transaction id mismatch) return None if msg_type 0x0111: print(got error response) return None mapped None offset 20 while offset 4 len(data): attr_type, attr_len struct.unpack(!HH, data[offset:offset 4]) value data[offset 4: offset 4 attr_len] if attr_type 0x0020: family value[1] port struct.unpack(!H, value[2:4])[0] ^ (MAGIC_COOKIE 16) if family 0x01: ip_int struct.unpack(!I, value[4:8])[0] ^ MAGIC_COOKIE ip socket.inet_ntoa(struct.pack(!I, ip_int)) else: key struct.pack(!I, MAGIC_COOKIE) txn_id raw bytes(a ^ b for a, b in zip(value[4:20], key)) ip socket.inet_ntop(socket.AF_INET6, raw) mapped (ip, port) offset 4 attr_len (attr_len % 4 ! 0 and (4 - attr_len % 4) or 0) return mapped mapped parse_stun_response(data, txn_id) if mapped: print(fmapped address: {mapped[0]}:{mapped[1]})解碼的關(guān)鍵點在前面說過IPv4地址與Magic Cookie異或IPv6地址與Magic Cookie加Transaction ID的16字節(jié)組合異或。端口則與0x2112異或。解析時要同時處理屬性值補齊到4字節(jié)的情況漏掉這個會導(dǎo)致后續(xù)屬性全部錯位。3.4 跑通后怎么判斷自己是不是在NAT后面拿到映射地址后再取一下本地socket在網(wǎng)卡上的實際地址兩個值對比一切就明了了。local_addr sock.getsockname() print(flocal address : {local_addr[0]}:{local_addr[1]}) print(fmapped address: {mapped[0]}:{mapped[1]})如果本地是192.168.x.x或10.x.x.x而映射地址是公網(wǎng)地址說明你確實在NAT后面而且你獲得了NAT分配的臨時公網(wǎng)端口。如果兩個地址完全一致說明這臺機器擁有公網(wǎng)IP沒有NAT參與。我實際測試過在云主機公網(wǎng)實例上運行時兩個地址一致在家里寬帶下運行時必然不一致。這個差異本身就是一個很好的線上環(huán)境判斷手段。4. 邊界與分工為什么對稱NAT會打敗STUNTURN和ICE又補了什么4.1 對稱NAT下STUN獲取的地址為什么沒法直接用現(xiàn)在把場景切換到對稱NAT這是STUN翻車最典型的場合。A在對稱NAT后面向STUN服務(wù)器S發(fā)請求。A的NAT為發(fā)往S這個目標(biāo)創(chuàng)建了一個映射假設(shè)是公網(wǎng)203.0.113.7:58452。S把這個地址告訴AA以為這就是自己的公網(wǎng)身份。接著A把這個地址作為候選發(fā)給BB往203.0.113.7:58452發(fā)包。問題來了B發(fā)給這個地址的流量目標(biāo)IP:端口雖然命中了A的NAT公網(wǎng)地址但A的NAT在此之前從未朝B的地址發(fā)過包沒有對應(yīng)目標(biāo)為B的映射入站包直接被丟棄。更擰巴的是A此時向B主動發(fā)包NAT會再為發(fā)往B這個目標(biāo)分配一個新的公網(wǎng)端口比如203.0.113.7:58455。B拿著58452當(dāng)然找不到A。STUN學(xué)到的地址只對服務(wù)器S這一個目標(biāo)是真實有效的對整個公網(wǎng)并不通用。對稱NAT下STUN給了你一個正確但沒法用的答案。這背后是一個自舉悖論你想通過一個地址讓對端找到你但這個地址本身取決于對端是誰而對端是誰恰恰是你還沒法預(yù)先告訴NAT的一件事。想跳出這個循環(huán)只能靠服務(wù)器中轉(zhuǎn)。4.2 TURN把包袱甩給服務(wù)器的中繼方案TURN的全稱是Traversal Using Relays around NAT思路很粗暴既然直連路徑建不起來就讓雙方都連到一臺公網(wǎng)服務(wù)器由服務(wù)器幫兩邊轉(zhuǎn)發(fā)數(shù)據(jù)?？蛻舳讼騎URN服務(wù)器發(fā)起Allocate請求申請一個中繼地址之后對端只要往這個中繼地址發(fā)包服務(wù)器就把負(fù)載再通過一條已建立的通道轉(zhuǎn)發(fā)給客戶端。代價非常實在所有媒體數(shù)據(jù)都要經(jīng)過中繼服務(wù)器帶寬成本翻倍延遲多一跳服務(wù)器要扛巨大的轉(zhuǎn)發(fā)流量。所以TURN在系統(tǒng)工程里從來是最后手段而不是第一選擇。ICE協(xié)議設(shè)計的核心目標(biāo)就是盡量優(yōu)先直連其次走STUN打洞最后才退到TURN。4.3 ICE把STUN從查地址變成打通路徑的探針I(yè)CEInteractive Connectivity Establishment把這套流程串成了一個完整框架。它先讓雙方各收集三類候選地址本機網(wǎng)卡上的host候選通過STUN從公網(wǎng)看到的server-reflexive候選以及通過TURN得到的中繼relay候選。然后雙方互換候選列表按照優(yōu)先級組成候選對逐對做連通性檢測。這個連通性檢測用的就是STUN Binding Request。兩個候選地址之間互發(fā)STUN請求請求里帶PRIORITY、USE-CANDIDATE等屬性以及ICE的短期憑證。能收到響應(yīng)的候選對就是可通的路徑最后根據(jù)優(yōu)先級選出一條最優(yōu)路徑作為媒體通道。所以STUN在ICE里不僅是查自己的公網(wǎng)地址更大價值是作為輕量可靠的探測工具持續(xù)驗證某條路徑是否真的通。這也是為什么STUN和ICE耦合得這么深I(lǐng)CE檢測期間雙方用的是短期憑證請求里帶USERNAME和MESSAGE-INTEGRITY字段任何一方拿不出正確摘要的STUN包都會被丟棄從而防止第三方注入偽造的連通性檢測響應(yīng)。WebRTC、VoIP系統(tǒng)里這套流程每天都在海量運行。5. 接入STUN后的調(diào)試實戰(zhàn)抓包、鑒權(quán)與錯誤碼里的門道5.1 第一件事永遠(yuǎn)是抓包驗證接入STUN之后別急著看業(yè)務(wù)層日志先抓包。抓包能一次性回答三個問題請求是不是真的發(fā)出去了、響應(yīng)是不是真的回來了、服務(wù)器回給我的地址跟我以為的地址是否一致。抓包工具我習(xí)慣用命令行工具配合圖形化協(xié)議分析器過濾規(guī)則直接寫udp port 3478就行STUN報文一般能被自動識別并解析出屬性列表。我踩過一個很典型的坑服務(wù)器部署在有多出口的網(wǎng)絡(luò)里客戶端把請求發(fā)給了A出口IP但響應(yīng)卻從B出口IP回來。單看應(yīng)用層一切正常但某些NAT設(shè)備對源和目的不是同一地址的UDP會直接丟棄導(dǎo)致線上成功率忽高忽低。后來是抓包發(fā)現(xiàn)響應(yīng)來源地址不一致趕緊在服務(wù)器側(cè)固定出口鏈路才解決問題。STUN響應(yīng)里的RESPONSE-SOURCE-ADDRESS屬性就是為這種排查設(shè)計的。另外建議自測腳本里同時打印發(fā)給誰和從誰那里收到響應(yīng)出現(xiàn)不對稱時優(yōu)先懷疑路由、負(fù)載均衡和多出口問題而不是STUN本身。5.2 鑒權(quán)機制401、438這些錯誤碼背后是一整套憑證流程公共STUN服務(wù)器通常不需要鑒權(quán)誰都能來問一句我的映射地址是什么。但TURN服務(wù)器和某些私有化部署的STUN服務(wù)會要求身份認(rèn)證走的是STUN的長程憑證機制客戶端第一次裸請求服務(wù)器回401同時在響應(yīng)里帶上REALM和NONCE客戶端根據(jù)用戶名密碼和NONCE計算出HMAC摘要放到MESSAGE-INTEGRITY屬性里重發(fā)服務(wù)器校驗通過后才返回正常響應(yīng)。NONCE是有狀態(tài)的過期后服務(wù)器會回438 Stale Nonce客戶端應(yīng)當(dāng)丟棄舊NONCE用響應(yīng)里的新NONCE重新計算摘要再重試一次。這跟HTTP認(rèn)證里的challenge-response非常像區(qū)別在于STUN用UDP承載整個流程要自己處理丟包重發(fā)。調(diào)試時如果一上來就報401別慌先看自己是不是漏了帶憑證的第二次請求。錯誤碼含義應(yīng)對300Try Alternate按OTHER-ADDRESS換服務(wù)器重試400Bad Request請求格式錯誤檢查報文401Unauthorized需要長程憑證重發(fā)時帶上認(rèn)證屬性403Forbidden憑證無效或無權(quán)限420Unknown Attribute服務(wù)器不認(rèn)識必須理解的屬性減少自定義屬性438Stale NonceNONCE過期換新NONCE重試500 / 600Server Error / Global Failure服務(wù)器問題換節(jié)點或稍后重試5.3 重傳與超時比你想象的要耐心STUN規(guī)范里的UDP重傳算法是初始間隔500毫秒之后逐次翻倍分別在0、0.5、1.5、3.5、7.5、15.5、31.5秒這幾個時間點各發(fā)一次總共7次。這意味著一趟完整的重傳序列可能持續(xù)三十多秒。很多客戶端自己設(shè)2秒超時一旦網(wǎng)絡(luò)抖動就直接判定失敗這是典型的配置不合理。正確的做法是讓STUN的重傳邏輯按指數(shù)退避走同時應(yīng)用層另外設(shè)定一個更寬的業(yè)務(wù)超時比如40秒。對ICE連通性檢測反而要激進得多檢測是并行、快速試錯的不能等30秒所以ICE用自己的短超時和重試次數(shù)甚至不等重傳就立刻換下一對候選。兩者目的不同參數(shù)設(shè)計也因此完全不同。我實際開發(fā)時還會注意一點重傳時絕不新建socket或換本地端口。STUN的映射和五元組綁定你換一個源端口NAT就給你開一個新映射重傳等于白傳。固定同一個socket重傳才有意義。6. 服務(wù)器選型與運行經(jīng)驗文檔不會寫的那幾件事6.1 自建還是使用公開服務(wù)器開發(fā)階段用公開STUN服務(wù)器測試很方便但生產(chǎn)環(huán)境強烈建議自建。公開服務(wù)器是別人家的基礎(chǔ)設(shè)施沒有SLA承諾隨時可能限流、變更地址或下線更實際的問題是地理距離離用戶太遠(yuǎn)的服務(wù)器會讓RTT高到幾十甚至上百毫秒而STUN查詢是交互鏈路的一部分每多一次往返都拖慢首屏體驗。自建時最常見的方案是部署成熟的開源TURN/STUN一體服務(wù)監(jiān)聽3478端口同時支持UDP和TCP。服務(wù)器要按地域分點部署有條件就做任播讓用戶就近接入。DNS里配置STUN服務(wù)的SRV記錄客戶端解析到多個IP后輪詢使用這樣可以避免單點故障。STUN服務(wù)器的健康檢查特別簡單周期性發(fā)一個Binding Request確認(rèn)能在預(yù)期RTT內(nèi)收到響應(yīng)即可這個探活腳本應(yīng)該納入監(jiān)控體系。有一個容易被忽略的負(fù)載均衡問題UDP不像TCP那樣有連接會話多臺STUN服務(wù)器前面掛負(fù)載均衡器時必須保證請求和響應(yīng)走同一臺后端否則客戶端會收到來源地址對不上的響應(yīng)某些NAT會直接把這樣的包丟掉。最穩(wěn)妥的策略是按五元組做一致性哈希或者在每臺服務(wù)器上固定出口IP。6.2 并發(fā)處理與安全防護STUN是UDP協(xié)議服務(wù)器面對的是海量短小請求設(shè)計上要按事件驅(qū)動模型走不要在收包路徑里做任何阻塞操作尤其不能做同步DNS解析。每個請求拿出Transaction ID和來源五元組在內(nèi)存里維護一個事務(wù)表響應(yīng)發(fā)出后盡快清理過期記錄。經(jīng)典Nginx式的多進程加SO_REUSEPORT監(jiān)聽實測能頂住非常高的QPS瓶頸更多在網(wǎng)卡和內(nèi)核收包上。安全方面有幾個細(xì)節(jié)。第一對同一來源IP要做限速防止有人拿你的STUN服務(wù)器當(dāng)反射放大器。第二對非STUN報文直接靜默丟棄不要回應(yīng)任何錯誤很多UDP反射攻擊就是靠未知即回放大的。第三響應(yīng)包大小保持克制不要隨意把大屬性塞進響應(yīng)響應(yīng)比請求大太多本身就給了放大攻擊機會。我見過一次線上事故日志里全是未知報文回包后來加上靜默丟棄策略才消停。6.3 ?；?、監(jiān)控與IPv6趨勢NAT映射不是永久的家用路由器常見空閑超時是30秒到2分鐘不等。應(yīng)用拿到STUN映射地址后如果不持續(xù)往同一個目標(biāo)發(fā)UDP包NAT會默默回收這條映射之后對端再發(fā)包就找不到你了。所以ICE規(guī)范里要求周期性發(fā)STUN Binding Indication來續(xù)命這個包帶Transaction ID但不需要響應(yīng)純粹為了讓NAT刷新老化計時器。實踐中每15秒發(fā)一次比較穩(wěn)妥既能?；钣植粫驗樘l繁造成服務(wù)器壓力。運維上重點盯四個指標(biāo)Binding Request成功率、RTT分位數(shù)、超時重傳比例、錯誤碼分布。成功率低于99%就要排查鏈路RTT分位數(shù)突然上抬多半是出口擁堵或目標(biāo)段網(wǎng)絡(luò)問題438比例升高說明NONCE管理出問題了。另外客戶端要處理好DNS解析失敗的情況——很多所謂STUN超時真相是DNS沒解析出來客戶端應(yīng)內(nèi)置多組服務(wù)器IP并支持快速切換。隨著IPv6普及純IPv6環(huán)境里NAT不再是主角但防火墻默認(rèn)仍然丟棄入站流量所以STUN的價值并沒有消失它依然可以用來探測公網(wǎng)可達性配合ICE做路徑發(fā)現(xiàn)。部分IPv6接入場景還會出現(xiàn)運營商級NAT行為跟IPv4時代的CGNAT一模一樣STUN在這些環(huán)境里依然是對抗NAT的主力工具。最后分享一個小習(xí)慣每次改完NAT相關(guān)的邏輯我都會在兩種網(wǎng)絡(luò)環(huán)境下各跑一遍自測腳本——家庭寬帶和手機流量。家庭寬帶大概率是錐形NAT能驗證STUN正常打洞路徑手機流量大概率是對稱NAT或運營商級NAT能驗證降級到TURN中繼的兜底邏輯。兩個環(huán)境交叉驗證一遍線上才敢放心發(fā)版本。