STUN服务器选择需优先考虑低延迟（<200ms）、高可用（>99.5%）及RFC 5389兼容性；本地UDP socket须设为非阻塞、绑定INADDR_ANY与端口0，避免固定端口干扰NAT对称性判断。
STUN服务器怎么选，本地UDP socket要怎么初始化
STUN本身不负责打洞，只帮你确认NAT类型和获取公网映射地址。想P2P直连，必须先让双方都向对方“打一枪”，触发NAT设备建立双向映射。所以第一步不是写STUN逻辑，而是确保本地UDP socket能发出去、收得回：socket(AF_INET, SOCK_DGRAM, 0)必须非阻塞（fcntl(fd, F_SETFL, O_NONBLOCK)），且绑定到INADDR_ANY和端口0（让系统自动分配，避免端口冲突）。别用bind()固定端口——很多NAT对固定端口有特殊策略，反而破坏对称性判断。
STUN Binding Request怎么发，响应里哪些字段真正有用
发STUN请求不是为了“连接成功”，而是为了拿到XOR-MAPPED-ADDRESS（或MAPPED-ADDRESS）里的IP和端口——这才是对方要连的地址。注意三点：
- 必须用UDP发，不能用TCP；
- STUN包必须带
MESSAGE-INTEGRITY（哪怕没认证，也得填空哈希占位，否则某些STUN服务器直接丢弃）； - 响应里的
RESPONSE-ORIGIN和OTHER-ADDRESS基本不用，纯干扰项，只取XOR-MAPPED-ADDRESS解码后的sin_addr和sin_port。
stun_parse_attr类工具函数（如libnice或pjnath）比手撕安全得多。
双方交换公网地址后，为什么UDP包还是收不到
地址交换只是前提，真正卡点在“打洞时机”和“NAT保活”。典型问题：
- 双方同时发包但时间差>100ms，后发的一方NAT还没建好映射，包被丢；
- 用
sendto()发完就等recvfrom()，但Linux UDP socket默认不接收“非本端主动connect过的地址”的包（即使绑定了INADDR_ANY）； - NAT映射超时（常见30–60秒），中间没心跳就断了。
sendto()向对方地址发1字节垃圾数据（比如"x"），连续发3次，间隔50ms；然后调用connect()绑定对方地址（让内核允许收该地址的包）；最后每20秒用send()（不是sendto）发一个保活包。
C++有没有轻量级STUN库可用，要不要自己解析
别手写STUN解析。RFC 5389结构看着简单，但XOR-MAPPED-ADDRESS的异或密钥是事务ID前4字节，MESSAGE-INTEGRITY要算HMAC-SHA1再截10字节，边界条件极多。推荐两个方案：
- 用
libnice（GNOME项目，C接口，C++可直接extern "C"调用），它内置STUN/TURN/ICE全流程，nice_agent_new()+nice_agent_gather_candidates()就能跑通； - 若只要STUN部分，用
pjnath（PJSIP子库），pj_stun_sock_create()封装了全部细节，且支持IPv6和自定义DNS。
立即学习“C++免费学习笔记（深入）”；
真正难的不是STUN请求发不发得出去，而是NAT类型判断不准导致误用“中继”策略，或者保活节奏没跟上NAT超时窗口。很多看似“打洞失败”的case，抓包一看，其实是第一包到达时NAT映射还没建立，第二包才开始通——这需要客户端主动制造“预热流量”，而不是干等。
