文章系统阐述建立点对点连接的 NAT 穿透基础条件，指出协议必须基于 UDP 并需直接控制网络套接字，才能让额外穿透报文与主协议并行复用同一端口。
协议选型：UDP 为主、QUIC 补流
NAT 穿透的首要前提是采用 UDP。原文指出 TCP 穿透虽可行，但会在本已复杂的问题上再叠加一层复杂度，甚至可能要求内核级定制。若业务需要面向流的可靠传输，应改用 QUIC：它构建在 UDP 之上，既保留了 UDP 穿透的通用性，又在穿透完成后提供流式接口。WebRTC、VoIP 电话及部分游戏均沿用此类技术栈，但成功率因实现细节而异。原文未给出具体成功率数据。
套接字直控与穿透实体分离
第二个硬性要求是直接掌控收发报文的网络套接字。常规网络库无法满足，因为穿透过程需发送、接收不属于“主协议”的额外报文。原文建议将 NAT 穿透视为独立实体，与主协议共享同一套接字并行运行：一个负责打洞、保活，另一个承载业务载荷。这种关注点分离便于在自研协议中复用成熟穿透逻辑，也符合 WebRTC 等标准协议的内部架构。
本地代理作为间接接入方案
若受限于运行环境（如沙箱、托管运行时）无法直接操作原始套接字，可部署本地代理。主程序仅与代理通信，代理负责执行穿透流程并转发业务报文。这种间接层让既有程序零改动即可获得穿透能力，但引入了额外跳数与状态维护开销。原文未给出具体延迟或吞吐损耗数据。
对运维与网络工程师而言，掌握 UDP 套接字直控与穿透逻辑解耦，是自建协议或排查 WebRTC、WireGuard 类应用连通性失败的关键切入点。在无法直控套接字的场景下，本地代理模式提供了一条可落地的退路。
原文: APNIC Blog（2022-04-12）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog