1. 先从一个真实痛点说起STUN到底解决了什么做音视频通话、远程控制、联机游戏这类实时通信的人几乎都会撞上同一个问题两台设备明明都在同一个互联网上却因为两边各自身处内网谁也找不到谁。STUN协议Session Traversal Utilities for NAT就是为这个场景设计的它的核心价值很单纯——帮一个身处NAT后面的设备搞清楚“从公网视角看我自己长什么样”也就是被NAT映射之后的那一对公网IP和端口。这话听起来不难但几乎所有P2P连接的第一步都得靠它。STUN协议不是传输隧道也不负责把媒体数据“偷偷送出去”它更像一个问路工具设备向公网上的STUN服务发送UDP请求服务端看到请求的来源地址后再原样告诉设备“我刚才看到你来自XX公网IP:端口”。设备拿到这个地址可以作为候选地址交给上层协商机制继续尝试与对端建立直接链路。所以搞WebRTC、自研音视频SDK、做智能设备互联的人都值得把STUN机制摸透。无论是想看穿NAT类型还是排查“双方明明在线却连不上”的问题底层都绕不开它。1.1 NAT给网络带来的双面性先补一点背景。IPv4地址资源有限绝大多数设备不会直接拥有公网地址而是通过NAT设备上网。NAT设备在内部维护一张映射表把内网地址端口转换成公网上的一个地址端口。可以把它想象成公司前台的电话转接外面拨进来打到总机总机再转给某个分机如果外部不知道内部分机号就只能说“请帮我转一下某某”至于这个号码存不存在前台说了算。NAT设备也一样它对外部请求是否回应、回给谁完全取决于映射表里是否已有对应条目。好处显而易见一台只有1个公网IP的家庭网关可以让几十台设备同时上网。但坏处也很要命——如果外部没有先收到来自内部的包NAT设备通常不会向内部转发任何主动请求。这就是常说的“外网无法主动访问内网设备”。对浏览网页影响不大因为浏览器总是先向网站发起请求。但对P2P场景就麻烦了两边都是内网双方都等对方先来结果谁也等不到。更麻烦的是NAT映射规则并不完全相同。有的NAT比较宽容有的比较严苛直接影响P2P成功率。所以我们会经常听到“完全锥形”“对称NAT”这些名词它们描述的就是不同NAT对外部数据包的过滤策略。STUN协议恰好能帮我们判断当前处在哪种NAT环境下这也是我推荐先搞清楚NAT类型、再谈穿越的原因。1.2 四种常见NAT类型的分水岭根据外部数据包能否顺利穿过NAT通常把NAT分成4种。为了好记我习惯用“来者不拒”“认IP不认端口”“认IP也认端口”“每次换一张脸”来概括。NAT类型外部回包放行规则P2P友好程度完全锥形NAT只要内网设备主动向外发过包之后任意外部主机都能往映射地址发数据最友好几乎不用额外处理受限锥形NAT只放行“内网设备曾主动通信过的外部IP”发来的包需要先打洞成功率较高端口受限锥形NAT外部IP和端口必须都曾是内网设备主动通信的目标更严格需要精确打洞对称NAT每次向不同目标地址发起连接都会分配新的公网端口最不友好STUN单独撑不住为什么要区分因为P2P连接中A要发给B的公网地址不仅要知道B的映射地址还要保证A曾经向“B的公网地址”发过包B的NAT才会放行回包。如果双方落在端口受限或对称NAT上仅靠STUN发现地址仍然不够最终多半要交给中继转发服务。这个结论先放在这里后面会展开。1.3 STUN协议处在哪个位置STUN协议在整套NAT穿越方案里的角色很像“侦察兵”它不负责冲锋但能给后续决策提供情报。标准定义在RFC 5389中后续RFC 8489做了更新与勘误。它本身非常轻量运行在UDP之上一次请求响应的开销只有几十字节适合在建立连接初期频繁使用。不过STUN的探测结果只是“候选地址”真正决定能否打通的是上层ICE机制。ICE会把主机候选地址、STUN发现的公网地址、中继转发服务提供的地址全部收集起来然后通过一系列连通性检查选出实际可用的路径。这也是为什么很多场景里STUN服务与TURN服务常常被部署在一起——前者用来发现地址后者在直接连接失败时兜底。需要强调一点这里说的中继兜底就是单纯的数据转发代价是明显增加的带宽成本和单位数据耗时。可以这样理解STUN解决的是“找到对方大门”ICE解决的是“确认大门能走通”TURN解决的是“大门走不通时改走配送中心”。三者配合才能覆盖绝大多数网络环境。只部署STUN、没有中继兜底在对称NAT环境下大概率还是会失败。2. 拆开STUN协议一次绑定请求背后的完整机制2.1 一次典型的STUN事务流程最常见的场景是这样的客户端向公网STUN服务器发送Binding Request。服务器收到请求后把请求数据包的源IP和源端口记录下来——这个源地址就是NAT分配出来的公网映射——然后通过Binding Response返回给客户端。客户端收到响应后将它缓存为候选地址。这个过程叫“Binding”可以理解为一次“绑定查询”。为什么说一次成功的Binding Response顺带验证了UDP连通性因为客户端能收到响应说明NAT允许来自STUN服务器的回包进入内网至少当前路径是通的。这层含义在ICE的连通性检查里会被继续放大。整个流程中客户端与服务端能对上号靠的是报文里的Transaction ID。请求和响应携带相同的Transaction ID客户端收到一个响应后先比对ID确认是不是自己刚才那个请求的回复避免旧响应或乱序响应造成误判。2.2 报文头部类型、长度、魔术字与事务IDSTUN报文有固定20字节头部。前两字节是消息类型Binding Request类型值是0x0001Binding Response成功响应是0x0101Error Response是0x0111。紧跟着的长度字段表示头部之后所有属性加起来的字节数。然后是4字节的Magic Cookie固定为0x2112A442用来快速识别STUN报文再往后是12字节的Transaction ID。这个Magic Cookie值得单独说一句。它除了用于协议识别还参与地址属性的异或编码让报文在穿越NAT时减少被误解的可能。Transaction ID则是随机生成的同一个Binding事务里请求与响应必须一致。头部之后是零到多个属性常见的有XOR-MAPPED-ADDRESS、ERROR-CODE、SOFTWARE、FINGERPRINT等。每个属性都遵循统一的TLV结构2字节类型、2字节长度接着是变长的属性值。解析一个STUN报文核心就是把头部读出来然后依次遍历属性。2.3 从XOR-MAPPED-ADDRESS解析出公网地址在早期版本中服务器返回的映射地址写在MAPPED-ADDRESS属性里地址原样保存。后来协议更新推荐优先使用XOR-MAPPED-ADDRESS也就是需要对地址做异或还原。这样设计的原因也不复杂有些NAT设备会错误地改写或处理包含公网地址的数据负载异或处理后报文负载里的地址不再是“明文公网地址”能在一定程度上避免中间设备自作主张地修改内容。XOR-MAPPED-ADDRESS属性值结构是第1个字节保留第2个字节是地址族IPv4为0x01IPv6为0x02接着是2字节的X-Port也就是映射端口与Magic Cookie高16位异或后的结果后面跟着X-AddressIPv4时是4字节IP与Magic Cookie逐字节异或。举一个具体例子。映射端口是40000十六进制为0x9C40Magic Cookie是0x2112A442高16位是0x2112两者异或后得到0xBD52。解析端拿到0xBD52后再异或0x2112就能还原出0x9C40也就是40000。IP的还原类似IPv4的4字节分别和Magic Cookie的4字节逐个异或。下面这段Python代码可以处理最简单的IPv4场景import socket import struct MAGIC_COOKIE 0x2112A442 def parse_xor_mapped_address(attr_value): data bytes.fromhex(attr_value) if len(data) 8: raise ValueError(attribute too short) family data[1] xor_port struct.unpack(!H, data[2:4])[0] port xor_port ^ ((MAGIC_COOKIE 16) 0xFFFF) if family 0x01: # IPv4 ip_bytes bytes(b ^ x for b, x in zip(data[4:8], MAGIC_COOKIE.to_bytes(4, big))) return socket.inet_ntop(socket.AF_INET, ip_bytes), port raise ValueError(only IPv4 is handled in this snippet)实际开发中主流语言一般都有成熟的STUN库不必手写解析。但理解这段异或逻辑很重要因为排障时一旦看到XOR-MAPPED-ADDRESS里的值“面目全非”你要知道这是协议的正常编码不是报文损坏。2.4 一个STUN请求的完整生命周期完整流程并不复杂。客户端构建一个Binding Request填充随机Transaction ID如果启用了长期凭证鉴权还会附带用户名和Message-Integrity属性随后通过UDP套接字发送到STUN服务器。因为UDP不保证可靠交付请求发送后客户端会启动重传计时器。协议默认初始RTO约500毫秒超时未收到响应就重发每次超时时间翻倍最多重试7次。如果超过最大重试次数仍无响应这次Binding事务宣告失败客户端需要切换备用服务器。服务器端收到请求后先解析头部检查长度、Magic Cookie和Transaction ID是否合法。若启用鉴权就验证Message-Integrity验证失败时返回401错误响应。验证通过后服务器从IP层取出源地址与源端口写入响应属性并带着相同的Transaction ID返回。客户端校验Transaction ID解析XOR-MAPPED-ADDRESS最终得到公网候选地址。整个过程是典型的“请求-响应”模型没有服务端主动推送因此实现起来相当直白调试也容易。3. 动手自建一个STUN探测服务环境、代码与验证3.1 自建STUN服务与使用公共服务的选型先说明一点公共STUN服务适合做连通性测试和临时调试生产环境不建议长期依赖。一是你不知道运维策略什么时候会变二是公共服务的负载和可用性不在你的控制范围。更合理的做法是在离业务近的机房部署自己的STUN服务或者在已有TURN服务上直接启用STUN能力。目前开源社区里TURN和STUN通常由同一套服务端程序提供部署一个实例就能同时覆盖“地址发现”和“中继转发”两个需求。选择这种组合的逻辑很简单STUN和TURN共用报文格式和鉴权机制放在一起部署运维成本更低。搭建时需要确认一件事STUN服务监听在UDP端口上常见端口是3478如果启用TLS/DTLS则常用5349。防火墙必须放行对应端口的UDP入站流量。这里我专门多写一句很多人都在这一步踩过坑部署完成后自我测试UDP包发出去没有回包第一反应是代码写错了最后排查半天才发现是云主机上的安全组没有放行UDP端口。UDP不像TCP有明显连接状态没有放行时请求往往被静默丢弃客户端只能一遍遍超时重试。3.2 用Python写一个最小STUN服务端如果只是想验证网络环境自己写一个几十行的STUN服务端也足够。下面这段代码实现了“收到Binding Request后返回XOR-MAPPED-ADDRESS”的核心逻辑只处理IPv4适合学习和调试import socket import struct MAGIC_COOKIE 0x2112A442 def make_binding_response(request, source_ip, source_port): tx_id request[8:20] binding_response_type 0x0101 addr_type 0x01 # IPv4 xor_port source_port ^ ((MAGIC_COOKIE 16) 0xFFFF) ip_bytes socket.inet_aton(source_ip) xor_ip bytes(b ^ x for b, x in zip(ip_bytes, MAGIC_COOKIE.to_bytes(4, big))) attr_type_xor_mapped 0x0020 attr_value struct.pack(!BBH, 0, addr_type, xor_port) xor_ip attr_payload struct.pack(!HH, attr_type_xor_mapped, len(attr_value)) attr_value msg_len len(attr_payload) header struct.pack(!HHI12s, binding_response_type, msg_len, MAGIC_COOKIE, tx_id) return header attr_payload def start_stun_server(host0.0.0.0, port3478): sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.bind((host, port)) print(fSTUN server listening on {host}:{port}) while True: data, addr sock.recvfrom(2048) if len(data) 20: continue msg_type struct.unpack(!H, data[0:2])[0] if msg_type 0x0001: # Binding Request response make_binding_response(data, addr[0], addr[1]) sock.sendto(response, addr) if __name__ __main__: start_stun_server()这里的关键点是UDP socket返回的addr正好就是请求经过NAT映射后的公网源地址和端口。如果服务端部署在公网主机上那么这个addr就是客户端在公网视角下的映射地址。把这段信息放进响应返回给客户端就完成了基本探测。代码中没有处理属性奇偶补位、IPv6、鉴权等细节生产级实现需要按标准逐项补全。3.3 用命令行客户端完成一轮自测在服务端运行起来之后可以让一台内网机器安装一个STUN命令行客户端执行类似下面的命令完成完整探测stunprobe --mode full --localaddr 0.0.0.0:0 --server 你的STUN服务器地址 --port 3478命令里的server地址要替换成实际公网IP或域名。完整探测模式通常会输出两类关键信息一是本机通过STUN服务器看到的公网地址端口二是当前NAT类型判断比如完全锥形、端口受限锥形还是对称NAT。如果输出里的公网端口与内网端口相同不表示没经过NAT只是NAT恰好保留了内网端口这种误读在生产环境里很容易让人白忙一场最终还是要以实际连通性检查为准。如果不想额外安装工具用上一节那段Python服务端配合一个简单的Python客户端也完全可以。客户端构造Binding Request通过UDP发出收到响应后解析XOR-MAPPED-ADDRESS并打印。整个过程十几行代码就能跑通。自建环境的好处是可以抓包看报文细节也可以用不同地域的多台服务器做对比观察映射结果是否随目标服务器改变。3.4 把STUN结果接入WebRTC链路里自建STUN服务后最常见的接入场景是WebRTC音视频。ICE配置里的iceServers数组可以只填STUN服务器也可以同时填中继转发服务器。STUN服务器地址使用stun:前缀后面跟域名和端口const config { iceServers: [ { urls: stun:stun.example.com:3478 } ] }; const pc new RTCPeerConnection(config);浏览器或客户端在创建RTCPeerConnection时会异步向这些服务器发起Binding请求收集“服务器反射候选地址”。随后协商阶段会看到三类candidatehost是内网网卡地址srflx是STUN发现的公网映射地址relay是中继转发服务提供的地址。ICE协商会按优先级排序连通性检查通过后优先选择延迟最低的路径。看到srflx类型的candidate出现说明STUN探测已经生效。但这里必须强调光有srflx不保证能连上完整链路还需要双方交换candidate并完成连通性检查。这也是为什么很多项目同时配置中继服务作为后备——当srflx路径连通性检查一直失败时媒体会自动降级到relay路径至少保证通话不中断。4. 实战中常见问题与排查心得4.1 拿到的公网映射地址经常变化怎么办用STUN服务时很多人会发现同一台设备连续多次查询返回的映射端口可能不同或者过一段时间就失效。这通常不是STUN本身的问题而是NAT映射有老化时间。NAT设备会为每条映射设置空闲超时比如60秒超过这个时间没有数据包经过映射就被回收。下次再发起请求NAT会分配一个新的公网端口甚至换了公网IP。解决办法是“心跳保活”。因为底层是UDP应用程序可以每隔20到25秒向STUN服务器发送一个轻量Binding请求让NAT映射保持活跃。这个间隔要明显小于NAT老化时间又不能太频繁否则白白消耗带宽。我习惯把间隔设为NAT老化时间的一半左右具体值可以通过测试调整。如果发现即使频繁发送请求、映射端口还是每次变更那很可能不是老化问题而是NAT启用了随机端口分配策略这时候要高度怀疑对称NAT。4.2 对称NAT下为什么STUN也不管用复现一个场景A和B各自通过STUN服务器拿到了自己的公网映射地址。现在A向B的映射地址发起连接A的NAT会为“到B这个目标”创建一条新映射并分配一个新公网端口。但B之前从STUN服务器拿到的地址只包含B到STUN服务器的映射不包含B到A的映射。如果B是端口受限锥形A用B的STUN映射地址发数据B的NAT大概率不放行如果B是对称NAT情况更糟A根本不知道B为“自己这个目标”分配了哪个端口。遇到这种情况STUN的地址发现能力就失效了必须在ICE协商里引入TURN中继。客户端把数据先发给中继转发服务器由服务器转给对端绕开两个NAT互不兼容的问题。代价是单跳变成多跳延迟和带宽成本明显上升。实际开发中如果客户端通过多次STUN查询发现映射端口每次变化ICE策略里就应该主动降低对直接P2P的期望尽早准备中继路径。把TURN服务配置进ICE候选不是可选优化而是保证连接成功率的关键兜底。4.3 几类典型错误码与排查思路STUN的Error Response里有三个错误码值得牢记。错误码含义常见排查方向401未授权请求缺少或填错了Message-Integrity确认用户名和共享密钥是否正确438Stale NonceNonce过期用响应中的新Nonce重试并校准机器时间500服务端内部错误查看服务端日志确认端口绑定和鉴权模块状态401和438经常成对出现。第一次发送请求没带鉴权信息服务器返回401并携带一个Nonce客户端用这个Nonce重新构建请求又因为服务端和客户端时间误差过大或Nonce有效期设置得太短收到438。这时先校准服务器时间再把Nonce有效期调长一点覆盖客户端重试周期。500类错误则重点排查服务端状态。建议在客户端里增加“失败后自动降级到中继路径”的逻辑不要因为一次STUN失败就让整条链路崩溃。4.4 安全与合规方面的细节STUN服务默认无鉴权因为Binding请求本身很轻量公开服务也不会造成严重的隐私泄露。但如果部署在公网至少要限制并发和来源防止被扫描器当成UDP反射放大器。这里说的“反射放大”并不是STUN特有的问题而是所有公网UDP服务都可能被滥用。建议在云主机安全组里限制只允许业务IP段访问3478端口。配合TURN服务时更要用长期凭证机制至少在服务端配置用户名与共享密钥避免开放转发能力后被人钻空子。另外不要在STUN报文里暴露不必要的内网细节。SOFTWARE属性用来标识实现版本但如果日志不做脱敏外部用户可能通过它判断底层软件版本进而尝试定向攻击。我通常会把日志里的用户IP、端口、Transaction ID等字段做哈希处理只保留排障必要的信息。还可以考虑给STUN叠加DTLS提供加密与校验能力部署成本略高但能换来更可靠的安全性。4.5 几条补充的踩坑心得最后分享几个实际遇到比较多的问题。第一云主机上明明开了UDP端口却忘了配安全组这是最常见的“假故障”。用TCP工具反复测、把代码看了一遍又一遍最后发现流量在安全组层面被丢掉了。所以自建STUN服务第一件事就是从外网另一台机器发一个UDP包到3478端口确认有回包再开始怀疑代码。第二测试NAT类型时尽量找多个不同位置的STUN服务器同时探测只用一个服务器很容易被某条路径上的特殊策略误导。第三做实时通信时我总是把STUN保活和候选刷新周期控制在25秒以内同时在中继路径可用的情况下保留两类候选这样即使NAT映射突然变化也不会长时间断流。STUN协议从原理上看很轻核心就是一个“查询映射地址”的小工具但它撬动了整个P2P通信链条。把NAT类型识别、地址发现、保活刷新、错误处理这四件事串起来实时链路的成功率就会有明显提升。以后再遇到“连不上但也不报错”的怪问题不妨先从NAT映射和STUN响应这两个基础环节查起多数答案都在里面。
