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