1. 先把问题拆开TCP打洞到底在解决什么以及它解决不了什么第一次做内网设备互联时我对TCP打洞这四个字有过一段相当天真的理解——以为只要两端互相知道对方的公网地址直接connect过去就完事了。真跑起来才发现两个都躲在NAT后面的节点谁主动连谁都连不上因为NAT的入站规则默认是没见过的包一律丢。TCP打洞TCP hole punching要干的事就是把没见过变成见过让两端在极短的时间窗内各自向外发一个SYN使各自的NAT先为对方建立出站映射随后对方的SYN才能被这条映射放行最终在两个NAT的夹缝里凑出一条直连通道。这套机制的正当用途很明确同一产品线里两台设备的点对点直传、远程协作工具的文件通道、联机对战的主机直连、IoT设备主动回连到管理端、跨办公网的协作客户端之间传大文件。这些场景的共同点是——两端都能访问一个公共的信令服务但双方之间没有公网入口。打洞成功时流量走最短路径延迟低、带宽不受中转节点限制打洞失败时退回中继功能不受影响只是成本高一点。关键是要早早认清它的定位TCP打洞是一条优化路径不是功能路径。功能必须在中继兜底的前提下设计打洞只是让大部分连接变得更快。我见过不止一个项目把打洞当唯一通路做上线后在某些网络环境下整片用户不可用最后返工重写连接层代价远大于一开始就把中继做进去。还有一个必须提前说清楚的现实TCP打洞的成功率天然低于UDP打洞。原因不在于TCP协议本身不能同时打开RFC 793 从一开始就定义了 simultaneous open而在于TCP的端口分配、连接状态机和NAT的实现细节叠加在一起让时间窗极窄、失败模式极多。理解了这一点后面的代码和参数才有意义。2. NAT的端口分配行为直接决定了这场实验的成败上限2.1 四类NAT的判定方式以及为什么它比代码更值得先搞清楚讨论打洞之前先要能判断自己面对的是哪种NAT。业界沿用的分类还是那四档虽然真实设备经常是混合行为但作为判断基线足够用类型映射行为过滤行为TCP打洞可行性全锥形Full Cone一个内网端点映射到一个固定公网端口对任何目标复用任何外部主机都能入站高几乎必成地址受限锥形Address Restricted同一目标IP复用同一映射只放行已通信过的目标IP中高端口受限锥形Port Restricted同目标IP端口复用同一映射只放行已通信过的目标IP端口中对称型Symmetric每换一个目标就新开一个公网端口严格很低判定方法不复杂就是多端点观测法让待测客户端依次连接同一台服务器的不同端口或不同IP的不同端口服务端记录每次看到的源IP和源端口。如果所有观测到的源端口完全一致基本是全锥形如果同IP不同端口时源端口变化但同IP同端口稳定偏对称型介于中间的看变化规律。这个探测服务在实现上就是信令服务多开几个监听端口客户端每个端口连一次服务端把remoteAddress和remotePort回给客户端自己比对。这里有个容易忽略的细节你观测到的映射是到探测服务器这个目标的映射。对称型NAT下这个映射对你真正想连的对端毫无参考价值——它只会告诉你你拿到的是端口X但你连对端时会拿到端口Y而Y是多少你无从得知。这是对称型NAT下TCP打洞失败的根本原因不是超时设短了也不是重试次数不够。2.2 端口预测这条路为什么在TCP上几乎走不通UDP打洞里有个经典技巧叫端口预测对称型NAT往往按某种规律递增分配端口猜几个相邻端口去撞偶尔能撞上。TCP上这条路要难得多原因是TCP的映射建立和连接状态强绑定。你为了猜端口而发的SYN如果目标NAT上没有对应映射会被直接丢弃或回RST而你没法像UDP那样无成本地往一堆端口上撒包——每个SYN都对应一个socket、一次状态迁移、一次可能要等几秒的超时。撒十个端口就是十次握手尝试时间成本直接把同时这个前提破坏掉了。我在实验里试过按 1、2、3 的步长连发三波预测包在某个运营商的移动网络下命中过一次但在另一个企业网里连发十波全部RST。这种偶尔能成的技巧没法作为产品逻辑只能作为可选的最后一搏而且要严格限制次数和耗时不能让它拖垮整个连接建立流程。2.3 映射老化一个被严重低估的失败来源比NAT类型更隐蔽的坑是映射老化。锥形NAT为一条TCP连接维护的映射在连接关闭后并不会立刻释放通常保留几十秒到几分钟不等但不同厂商差异极大有的收到RST就立刻回收有的保留十几分钟。这个差异直接影响两波次打洞策略能不能用。我的做法是在信令阶段就把双端的时间对齐把两次发包的间隔压缩到毫秒级减少对映射存活的依赖。同时给每条成功建立的直连加心跳保活间隔设在15到25秒之间——太短浪费电量太长在部分NAT上会被判定空闲而回收。心跳不只是为了检测断线更是为了续命让这条来之不易的映射别在中途被悄悄清掉。3. 用Node把最小可跑的实验环境搭起来3.1 信令服务该干什么、不该干什么信令服务的职责只有三件登记身份、交换双方观测到的公网端点、约定一个同时发包的时刻。它不应该参与任何数据转发那是中继的事也不应该保存业务状态。把这三件事混在一起后期排查会非常痛苦——你分不清是信令延迟导致时间没对齐还是转发路径出了问题。传输层我选裸TCP加换行分隔的JSON不引第三方库。理由很实际这个服务要部署在最便宜的机器上依赖越少越好而且JSON行协议在抓包时肉眼可读调试阶段省下大量时间。生产环境可以换二进制帧或加压缩但实验阶段没必要。// signal.js —— 极简信令与端点交换服务 const net require(net); const peers new Map(); // id - { sock, pubIp, pubPort } function deliver(sock, obj) { if (!sock.destroyed) sock.write(JSON.stringify(obj) \n); } net.createServer((sock) { sock.setNoDelay(true); // 信令延迟直接影响时间对齐精度 sock.setEncoding(utf8); sock.setTimeout(30_000, () sock.destroy()); let buffer ; let peerId null; sock.on(data, (chunk) { buffer chunk; let nl; while ((nl buffer.indexOf(\n)) ! -1) { const line buffer.slice(0, nl).trim(); buffer buffer.slice(nl 1); if (!line) continue; let msg; try { msg JSON.parse(line); } catch { continue; } handle(msg); } }); sock.on(close, () { if (peerId peers.get(peerId)?.sock sock) peers.delete(peerId); }); function handle(msg) { if (msg.type hello) { peerId String(msg.id || ).slice(0, 32); if (!peerId) return sock.destroy(); peers.set(peerId, { sock, pubIp: sock.remoteAddress.replace(/^::ffff:/, ), pubPort: sock.remotePort, }); deliver(sock, { type: hello-ok, id: peerId, serverTime: Date.now() }); return; } if (msg.type rendezvous) { const me peers.get(peerId); const other peers.get(String(msg.target)); if (!me || !other || me other) { return deliver(sock, { type: error, reason: peer-not-ready }); } // 留 3 秒给双方做时间校准和准备实际可按 RTT 动态调整 const startAt Date.now() 3000; deliver(me.sock, { type: peer, peerId: msg.target, ip: other.pubIp, port: other.pubPort, startAt, }); deliver(other.sock, { type: peer, peerId, ip: me.pubIp, port: me.pubPort, startAt, }); } } }).listen(9000, 0.0.0.0);注意pubIp的::ffff:前缀处理。Node在双栈监听时IPv4客户端会以IPv4-mapped地址出现不剥掉这个前缀客户端拿到的就是个非法地址connect直接报错。这个坑我在第一次跑通时就踩了日志里看到::ffff:10.0.0.5一度以为是NAT返回了内网地址。3.2 端点采集为什么不能只用信令连接自己的源端口信令连接自身的源端口只能说明我到信令服务器这个目标的映射。对于地址受限锥形以上的NAT这个信息在连对端时依然有效但对对称型NAT就完全失效。所以采集阶段最好做双端点探测让客户端再连一个同IP不同端口的探测监听把两次的源端口记下来做对比。对比结果的处理逻辑是这样两次源端口相同说明是端点无关或地址相关映射可以直接用信令连接观测到的端点去打洞两次源端口不同说明大概率是端口相关或对称型这时候仍然要试但要在策略上把中继的优先级提前不要让用户等太久。这里还有一个隐形变量探测和服务器的部署位置。如果信令服务和用户不在同一个大区观测到的映射可能走了不同的出口得到的端口不具备代表性。工程上的折中是——把信令服务部署在目标用户群的网络中心位置别为了省钱放到离用户很远的地方省下的钱会在连接失败率上加倍还回来。3.3 客户端的双端同时连接骨架客户端要做的事连信令、对齐时间、在约定时刻同时向对端公网端点发起connect、等待握手成功。下面是核心骨架省略了鉴权和指数退避// punch.js const net require(net); const CFG { signal: { host: process.env.SIG_HOST, port: Number(process.env.SIG_PORT) }, id: process.argv[2], target: process.argv[3], basePort: Number(process.argv[4] || 45000), punchTimeout: 4000, rounds: 4, }; let clockOffset 0; // 本地时间 offset ≈ 服务器时间 const sleep (ms) new Promise((r) setTimeout(r, ms)); function connectSignal() { const sock net.connect(CFG.signal); sock.setNoDelay(true); sock.setEncoding(utf8); let buffer ; sock.on(data, (chunk) { buffer chunk; let nl; while ((nl buffer.indexOf(\n)) ! -1) { const line buffer.slice(0, nl).trim(); buffer buffer.slice(nl 1); if (line) onMessage(JSON.parse(line), sock); } }); sock.on(connect, () { const sentAt Date.now(); sock.write(JSON.stringify({ type: hello, id: CFG.id }) \n); sock.once(data, () { // 单程估算offset 服务器时间 - 本地发送时间 - RTT/2 clockOffset 0; // 下面用一次显式握手替换见正文说明 }); void sentAt; }); return sock; } async function onMessage(msg, signalSock) { if (msg.type hello-ok) { clockOffset msg.serverTime - Date.now(); // 仅单程近似 signalSock.write(JSON.stringify({ type: rendezvous, target: CFG.target }) \n); return; } if (msg.type peer) { const result await punch(msg); if (result) { console.log([ok] direct channel established); startApp(result); } else { console.log([fail] fallback to relay); startApp(await connectRelay()); } } } async function punch(peer) { const wait peer.startAt - (Date.now() clockOffset) - 200; if (wait 0) await sleep(wait); for (let round 0; round CFG.rounds; round) { const localPort CFG.basePort round; // 每轮换端口撞不同映射 const sock await tryOnce(peer, localPort); if (sock) return sock; await sleep(300); } return null; } function tryOnce(peer, localPort) { return new Promise((resolve) { let settled false; const sock net.connect({ host: peer.ip, port: peer.port, localPort, // 关键固定本地端口让映射可复用 localAddress: 0.0.0.0, timeout: CFG.punchTimeout, }); const finish (val) { if (settled) return; settled true; if (!val) sock.destroy(); resolve(val); }; sock.on(connect, () { sock.setNoDelay(true); sock.setKeepAlive(true, 20_000); finish(sock); }); sock.on(timeout, () finish(null)); sock.on(error, () finish(null)); // ECONNREFUSED / EHOSTUNREACH 都走这里 }); }localPort是这段代码的灵魂。不指定它操作系统每次给一个随机临时端口NAT为每个新端口分配新映射两端的SYN永远对不上号。指定之后重试才有可能复用已有映射。3.4 参数不是拍脑袋定的每个都要能说出理由参数建议值依据时间窗偏移200ms 提前量抵消信令到客户端的一跳调度抖动单轮超时3000–4000ms小于常见NAT的SYN重传周期避免死等重试轮数4超过4轮成功率提升趋平用户等待已到上限轮间间隔200–500ms给上一轮socket释放和映射回收留出缝隙心跳间隔15–25s低于多数NAT的TCP空闲回收阈值信令总预算≤6s超过这个时间用户体验开始明显下滑这些数字不是标准答案是权衡结果。比如单轮超时设到10秒理论上给SYN多几次重传机会但用户侧感知就是卡住了而且这段时间里用户的退出操作会让整个流程白做。我倾向于快速失败、快速兜底直连晚建立两秒的价值远不如立刻可用。4. 同时打开的实现细节内核、socket选项与那个微妙的时间窗4.1 固定本地端口带来的副作用与处理localPort指定后第一件事是端口占用。同一台机器上如果同时起多个客户端实例或者上一轮socket还在TIME_WAIT绑定就会失败并抛EADDRINUSE。Linux上因为默认带SO_REUSEADDR情况会宽松一些Windows上的语义不同同样的代码在一台机器上能跑、换一台就报错这类问题不写日志根本查不出来。我的处理方式是在tryOnce的error事件里区分错误码EADDRINUSE不当成对端不可达而是立刻换下一个端口重试并且记一条明确的日志。把不同性质的失败混在一个计数器里是排查阶段最大的障碍。另外要清楚一件事localPort固定只对本地有效公网侧看到的是NAT改写后的端口。所以两端都用45000这种做法实际意义是让两端的四元组结构尽可能对称某些NAT的哈希分配在对称输入下更容易落到相邻端口间接提高一点命中率。它不是银弹但在统计上确实有一点帮助成本是零值得保留。4.2 为什么必须几乎同时以及时间同步该做到什么精度同时打开的内核行为大致是这样本地socket处于SYN_SENT状态时如果收到一个源和目的都与自己发出的SYN完全对应的SYN内核不会回RST而是转入SYN_RCVD并回复SYN-ACK双方各自完成握手。这个路径成立的前提是——当对方的SYN到达时本地已经在同一个四元组上发过SYN。如果对方先到而你还没发你这边没有对应socket内核会回RST这个RST还可能被对方的NAT翻译成连接拒绝于是对方立刻判定失败。所以时间窗不是越准越好这种模糊要求而是必须让双方的SYN在各自的NAT映射建立之后、在对方超时判定之前相互抵达。精度上信令服务器与客户端之间的单程延迟通常有几十毫秒的抖动用服务器给一个绝对时刻、客户端按自己估算的偏移去等这种方式误差基本落在几十毫秒级够用。要更准就做一次四时间戳往返客户端发t0服务器回t1收到时刻和t2发出时刻客户端记t3偏移按((t1 - t0) (t2 - t3)) / 2算。这个补偿能把误差压到个位数毫秒代价是多一次往返值不值看你的网络抖动水平。4.3 先发一波再同时发这个土办法为什么有效理论上双方同时发就够了实践里我加了一步在正式对齐发包之前先各自向对方的公网端点发一次短超时的SYN不等结果就丢弃。这一步的目的是让本地NAT提前为本端点到对方公网端点建立出站映射。很多NAT在映射建立的那一刻就已经放行了反向流量哪怕这个SYN本身被对方丢弃了。这个技巧有个前提——本地NAT不会因为这次连接失败立刻回收映射。前面说过不同设备回收策略差异很大有的收到RST后秒回收有的能撑几分钟。所以它属于提高概率的手段不能当成必然成立的步骤。我在日志里统计过加了这一波预热端口受限锥形场景下的成功率大概从三成提到接近六成但对称型依然趴着——这也反过来验证了对称型失败的原因不是没预热而是端口根本不可预测。顺带说一句业界流传的低TTL预热把SYN的TTL设成1或2让它到不了对端只触发本地NAT建映射在纯Node里落不了地net模块没有暴露IP_TTL这类setsockopt接口。要真做得上原生扩展或者系统层面的工具配合。我在实验里用系统工具验证过这个思路确实有效但考虑到引入原生依赖的部署成本最终产品里没有采用而是用上面说的先发一波来近似。4.4 连上了不等于连对了握手校验别省直连建立后第一件事不是发业务数据而是做一次身份校验。原因很实际你连接的地址是信令服务给的如果信令被劫持或者对端ID被冒用你会把数据发给一个陌生节点。更常见的情况是IP复用导致的连接到错误实例——同一台公网NAT后面的多台设备端点可能一样连上的是隔壁那台。做法很简单建连后双方各发一个16字节随机数再各自回一个基于共享密钥的HMAC双向校验通过才算成功。整个过程控制在一次往返内不影响建立速度。这一步不做后面所有数据发给了谁的问题都无从追溯。5. 实测中最常遇到的失败形态与完整排查链5.1 现象一SYN发出去了对端毫无反应最早遇到的就是这个日志显示connect开始了然后一直等到超时对端没有任何入站记录。这种形态基本可以锁定为对方的NAT把SYN丢了原因通常是对方还没建立指向你的映射或者对方的过滤策略比预期更严。排查顺序我固定成三步。第一步确认对方的信令连接是否真的在线——很多打洞失败其实是信令侧对端已经掉线服务器给的端点信息是过期的。第二步在两端同时抓包看SYN是否真的发出了、源端口是多少。第三步对比两端的抓包结果如果A发出了SYN但B的网卡上没看到任何入站说明包死在了B的NAT如果B的网卡上看到了但B回了RST说明B的本机防火墙拦了。这三步里第一步最容易被跳过。我见过一次排查了半天的打洞失败最后发现是对端的进程被系统休眠挂起了信令连接还挂着但根本没在跑打洞逻辑。5.2 现象二连接建立了几百毫秒后被RST这个形态比超时更迷惑因为日志里明明白白写着connected。原因通常是同时打开路径中出现了两个socket抢同一个四元组。比如你在两轮重试之间的间隔太短第一轮的socket还没完全关闭第二轮的socket绑了同一个本地端口连同一个目标内核行为就变得不可预测最终某一方被RST。还有一种情况是应用层校验失败后主动关闭但日志没打出来看起来就像莫名其妙断了。所以校验失败必须记清晰日志别用一个笼统的handshake failed糊过去。处理方式轮间间隔给足至少200毫秒让上一轮socket确实进入关闭流程同时用sock.destroy()而不是sock.end()避免半关闭状态拖时间。我在早期版本里用end()结果FIN_WAIT状态的socket和下一轮的绑定打架现象就是上面说的连上就断。5.3 现象三一端显示成功另一端一直超时这是最典型的非对称NAT场景。A侧是全锥形它的NAT把B发来的SYN顺利放行A的内核完成握手A的connect回调触发但B那一侧的NAT是端口受限型A的SYN源端口和它记录的映射对不上包被丢弃B永远等不到回应。这种单边成功最危险因为如果应用层只等一端就绪就开始传数据会发现数据发出去石沉大海。防御手段是双边确认连接建立后必须走完那次HMAC校验往返只有收到对方的有效响应才算真正成功。A侧即使本地connect成功了在校验超时后也要判定失败并回退中继。这个坑我印象很深——早期版本里A侧先就绪就开始推文件结果推了几十MB全部堆在发送缓冲区最后超时回退用户看到的是卡了很久然后重新开始。5.4 把日志变成能定位问题的证据链排查阶段最有价值的不是日志多而是每条日志都能回答现在到了哪一步。我在打洞流程里固定打这几类事件信令连接建立、端点交换完成、约定的发包时刻、每一轮尝试的开始与结束、本地绑定的端口号、connect的结果与耗时、校验往返的结果、最终决策直连/中继。日志里带上双方ID和每次尝试的端口出问题时把两端日志按时间轴一拼问题基本就现形了。缺了端口号这一项你连是不是端口被NAT改写了都判断不了。6. 让它从实验变成可用兜底、保活与连接生命周期6.1 中继不是退路是必须存在的主干把中继做好比把打洞成功率从60%提到70%更有价值。因为打洞受制于用户所处的网络你再优化也覆盖不了全部而中继是确定性的只要两端能连到中转节点功能就一定能用。最简的中继就是配对转发第一个连上来的连接挂起第二个连上来后把两条socket互相pipe。生产版本还要加房间号、鉴权、流量统计和连接数限制。// relay.js —— 最小配对转发 const net require(net); const waiting []; net.createServer((sock) { sock.setNoDelay(true); if (waiting.length 0) { waiting.push(sock); sock.on(close, () { const i waiting.indexOf(sock); if (i 0) waiting.splice(i, 1); }); return; } const peer waiting.shift(); sock.pipe(peer); peer.pipe(sock); const close () { sock.destroy(); peer.destroy(); }; sock.on(error, close); peer.on(error, close); }).listen(9100, 0.0.0.0);这段代码只适合做压力测试不能直接上线——没有房间概念两个不相关的连接会被配到一起。上线版本至少要带一个roomId的握手帧并且对单IP的连接数做限制。6.2 保活不只是为了探测断线直连成功之后很多人就不管了结果用户传完一个小文件去泡了杯咖啡回来发现连接已经断了。原因是中间的NAT把空闲映射回收了或者运营商侧的会话表清掉了。setKeepAlive(true, 20000)能解决一部分问题它发的是TCP层的探测包对维持NAT映射有效。但应用层心跳还是建议加因为TCP keepalive的探测间隔受系统参数影响跨平台一致性不好而且它探不出连接还在但应用已经卡死的情况。应用层心跳用一个极小的帧就行几字节的内容主要目的是制造流量。有个反直觉的结论心跳间隔不是越小越好。设成1秒移动端功耗会明显上升而且很多NAT对高频小包有自己的限流策略。15到25秒是一个比较稳的区间具体取值靠实测你的目标网络环境定。6.3 重连不是重新打洞而是要重新走完整流程网络切换从Wi-Fi切到蜂窝之后原来的四元组全部失效直连必然断。这时候不能简单地connect原地址了因为公网端点已经变了。正确做法是重新连信令、重新交换端点、重新走一次打洞加兜底的完整流程。为了让上层业务无感需要在应用层做一个会话标识连接重建后用这个标识把上层的数据流续上。TCP本身不支持连接迁移所以这个续接逻辑必须由业务层实现。文件传输场景下就是重新建连后从断点续传消息场景下就是重连后补拉离线消息。6.4 安全边界打洞能力不该对任意目标开放一个能让两端直连的组件如果被滥用就变成了扫描和滥发的工具。所以上线前必须收紧几条信令连接必须带有效凭证未认证的连接不能请求对端端点对同一对端的撮合请求做频率限制防止被用来探测内部网络直连建立后的身份校验不能省防止连接被引导到非预期节点。我在实现里加的一条规则是——对端ID必须来自可信的名册不能由客户端任意指定。这条规则看起来限制了灵活性但避免了绝大部分滥用场景而且实际业务里本来也不需要连接任意ID。最后再分享一个实际体会TCP打洞这个事把它做成能跑通的Demo大概需要一天做成在真实网络里成功率可接受、失败时用户无感需要至少两周而这两周里绝大部分时间花在抓包、对比日志、调整参数上写代码的时间反而很少。如果你的场景里直连带来的收益延迟、带宽成本不足以覆盖这些投入那就老老实实用中继把省下来的时间做到业务上——这不是妥协是算过账之后的选择。 
长河君 · 2026/10/27 20:01:00 · 阅读 1.2k TCP打洞与NAT穿透实战：信令、端口映射与中继兜底
1. 先把问题拆开TCP打洞到底在解决什么以及它解决不了什么第一次做内网设备互联时我对TCP打洞这四个字有过一段相当天真的理解——以为只要两端互相知道对方的公网地址直接connect过去就完事了。真跑起来才发现两个都躲在NAT后面的节点谁主动连谁都连不上因为NAT的入站规则默认是没见过的包一律丢。TCP打洞TCP hole punching要干的事就是把没见过变成见过让两端在极短的时间窗内各自向外发一个SYN使各自的NAT先为对方建立出站映射随后对方的SYN才能被这条映射放行最终在两个NAT的夹缝里凑出一条直连通道。这套机制的正当用途很明确同一产品线里两台设备的点对点直传、远程协作工具的文件通道、联机对战的主机直连、IoT设备主动回连到管理端、跨办公网的协作客户端之间传大文件。这些场景的共同点是——两端都能访问一个公共的信令服务但双方之间没有公网入口。打洞成功时流量走最短路径延迟低、带宽不受中转节点限制打洞失败时退回中继功能不受影响只是成本高一点。关键是要早早认清它的定位TCP打洞是一条优化路径不是功能路径。功能必须在中继兜底的前提下设计打洞只是让大部分连接变得更快。我见过不止一个项目把打洞当唯一通路做上线后在某些网络环境下整片用户不可用最后返工重写连接层代价远大于一开始就把中继做进去。还有一个必须提前说清楚的现实TCP打洞的成功率天然低于UDP打洞。原因不在于TCP协议本身不能同时打开RFC 793 从一开始就定义了 simultaneous open而在于TCP的端口分配、连接状态机和NAT的实现细节叠加在一起让时间窗极窄、失败模式极多。理解了这一点后面的代码和参数才有意义。2. NAT的端口分配行为直接决定了这场实验的成败上限2.1 四类NAT的判定方式以及为什么它比代码更值得先搞清楚讨论打洞之前先要能判断自己面对的是哪种NAT。业界沿用的分类还是那四档虽然真实设备经常是混合行为但作为判断基线足够用类型映射行为过滤行为TCP打洞可行性全锥形Full Cone一个内网端点映射到一个固定公网端口对任何目标复用任何外部主机都能入站高几乎必成地址受限锥形Address Restricted同一目标IP复用同一映射只放行已通信过的目标IP中高端口受限锥形Port Restricted同目标IP端口复用同一映射只放行已通信过的目标IP端口中对称型Symmetric每换一个目标就新开一个公网端口严格很低判定方法不复杂就是多端点观测法让待测客户端依次连接同一台服务器的不同端口或不同IP的不同端口服务端记录每次看到的源IP和源端口。如果所有观测到的源端口完全一致基本是全锥形如果同IP不同端口时源端口变化但同IP同端口稳定偏对称型介于中间的看变化规律。这个探测服务在实现上就是信令服务多开几个监听端口客户端每个端口连一次服务端把remoteAddress和remotePort回给客户端自己比对。这里有个容易忽略的细节你观测到的映射是到探测服务器这个目标的映射。对称型NAT下这个映射对你真正想连的对端毫无参考价值——它只会告诉你你拿到的是端口X但你连对端时会拿到端口Y而Y是多少你无从得知。这是对称型NAT下TCP打洞失败的根本原因不是超时设短了也不是重试次数不够。2.2 端口预测这条路为什么在TCP上几乎走不通UDP打洞里有个经典技巧叫端口预测对称型NAT往往按某种规律递增分配端口猜几个相邻端口去撞偶尔能撞上。TCP上这条路要难得多原因是TCP的映射建立和连接状态强绑定。你为了猜端口而发的SYN如果目标NAT上没有对应映射会被直接丢弃或回RST而你没法像UDP那样无成本地往一堆端口上撒包——每个SYN都对应一个socket、一次状态迁移、一次可能要等几秒的超时。撒十个端口就是十次握手尝试时间成本直接把同时这个前提破坏掉了。我在实验里试过按 1、2、3 的步长连发三波预测包在某个运营商的移动网络下命中过一次但在另一个企业网里连发十波全部RST。这种偶尔能成的技巧没法作为产品逻辑只能作为可选的最后一搏而且要严格限制次数和耗时不能让它拖垮整个连接建立流程。2.3 映射老化一个被严重低估的失败来源比NAT类型更隐蔽的坑是映射老化。锥形NAT为一条TCP连接维护的映射在连接关闭后并不会立刻释放通常保留几十秒到几分钟不等但不同厂商差异极大有的收到RST就立刻回收有的保留十几分钟。这个差异直接影响两波次打洞策略能不能用。我的做法是在信令阶段就把双端的时间对齐把两次发包的间隔压缩到毫秒级减少对映射存活的依赖。同时给每条成功建立的直连加心跳保活间隔设在15到25秒之间——太短浪费电量太长在部分NAT上会被判定空闲而回收。心跳不只是为了检测断线更是为了续命让这条来之不易的映射别在中途被悄悄清掉。3. 用Node把最小可跑的实验环境搭起来3.1 信令服务该干什么、不该干什么信令服务的职责只有三件登记身份、交换双方观测到的公网端点、约定一个同时发包的时刻。它不应该参与任何数据转发那是中继的事也不应该保存业务状态。把这三件事混在一起后期排查会非常痛苦——你分不清是信令延迟导致时间没对齐还是转发路径出了问题。传输层我选裸TCP加换行分隔的JSON不引第三方库。理由很实际这个服务要部署在最便宜的机器上依赖越少越好而且JSON行协议在抓包时肉眼可读调试阶段省下大量时间。生产环境可以换二进制帧或加压缩但实验阶段没必要。// signal.js —— 极简信令与端点交换服务 const net require(net); const peers new Map(); // id - { sock, pubIp, pubPort } function deliver(sock, obj) { if (!sock.destroyed) sock.write(JSON.stringify(obj) \n); } net.createServer((sock) { sock.setNoDelay(true); // 信令延迟直接影响时间对齐精度 sock.setEncoding(utf8); sock.setTimeout(30_000, () sock.destroy()); let buffer ; let peerId null; sock.on(data, (chunk) { buffer chunk; let nl; while ((nl buffer.indexOf(\n)) ! -1) { const line buffer.slice(0, nl).trim(); buffer buffer.slice(nl 1); if (!line) continue; let msg; try { msg JSON.parse(line); } catch { continue; } handle(msg); } }); sock.on(close, () { if (peerId peers.get(peerId)?.sock sock) peers.delete(peerId); }); function handle(msg) { if (msg.type hello) { peerId String(msg.id || ).slice(0, 32); if (!peerId) return sock.destroy(); peers.set(peerId, { sock, pubIp: sock.remoteAddress.replace(/^::ffff:/, ), pubPort: sock.remotePort, }); deliver(sock, { type: hello-ok, id: peerId, serverTime: Date.now() }); return; } if (msg.type rendezvous) { const me peers.get(peerId); const other peers.get(String(msg.target)); if (!me || !other || me other) { return deliver(sock, { type: error, reason: peer-not-ready }); } // 留 3 秒给双方做时间校准和准备实际可按 RTT 动态调整 const startAt Date.now() 3000; deliver(me.sock, { type: peer, peerId: msg.target, ip: other.pubIp, port: other.pubPort, startAt, }); deliver(other.sock, { type: peer, peerId, ip: me.pubIp, port: me.pubPort, startAt, }); } } }).listen(9000, 0.0.0.0);注意pubIp的::ffff:前缀处理。Node在双栈监听时IPv4客户端会以IPv4-mapped地址出现不剥掉这个前缀客户端拿到的就是个非法地址connect直接报错。这个坑我在第一次跑通时就踩了日志里看到::ffff:10.0.0.5一度以为是NAT返回了内网地址。3.2 端点采集为什么不能只用信令连接自己的源端口信令连接自身的源端口只能说明我到信令服务器这个目标的映射。对于地址受限锥形以上的NAT这个信息在连对端时依然有效但对对称型NAT就完全失效。所以采集阶段最好做双端点探测让客户端再连一个同IP不同端口的探测监听把两次的源端口记下来做对比。对比结果的处理逻辑是这样两次源端口相同说明是端点无关或地址相关映射可以直接用信令连接观测到的端点去打洞两次源端口不同说明大概率是端口相关或对称型这时候仍然要试但要在策略上把中继的优先级提前不要让用户等太久。这里还有一个隐形变量探测和服务器的部署位置。如果信令服务和用户不在同一个大区观测到的映射可能走了不同的出口得到的端口不具备代表性。工程上的折中是——把信令服务部署在目标用户群的网络中心位置别为了省钱放到离用户很远的地方省下的钱会在连接失败率上加倍还回来。3.3 客户端的双端同时连接骨架客户端要做的事连信令、对齐时间、在约定时刻同时向对端公网端点发起connect、等待握手成功。下面是核心骨架省略了鉴权和指数退避// punch.js const net require(net); const CFG { signal: { host: process.env.SIG_HOST, port: Number(process.env.SIG_PORT) }, id: process.argv[2], target: process.argv[3], basePort: Number(process.argv[4] || 45000), punchTimeout: 4000, rounds: 4, }; let clockOffset 0; // 本地时间 offset ≈ 服务器时间 const sleep (ms) new Promise((r) setTimeout(r, ms)); function connectSignal() { const sock net.connect(CFG.signal); sock.setNoDelay(true); sock.setEncoding(utf8); let buffer ; sock.on(data, (chunk) { buffer chunk; let nl; while ((nl buffer.indexOf(\n)) ! -1) { const line buffer.slice(0, nl).trim(); buffer buffer.slice(nl 1); if (line) onMessage(JSON.parse(line), sock); } }); sock.on(connect, () { const sentAt Date.now(); sock.write(JSON.stringify({ type: hello, id: CFG.id }) \n); sock.once(data, () { // 单程估算offset 服务器时间 - 本地发送时间 - RTT/2 clockOffset 0; // 下面用一次显式握手替换见正文说明 }); void sentAt; }); return sock; } async function onMessage(msg, signalSock) { if (msg.type hello-ok) { clockOffset msg.serverTime - Date.now(); // 仅单程近似 signalSock.write(JSON.stringify({ type: rendezvous, target: CFG.target }) \n); return; } if (msg.type peer) { const result await punch(msg); if (result) { console.log([ok] direct channel established); startApp(result); } else { console.log([fail] fallback to relay); startApp(await connectRelay()); } } } async function punch(peer) { const wait peer.startAt - (Date.now() clockOffset) - 200; if (wait 0) await sleep(wait); for (let round 0; round CFG.rounds; round) { const localPort CFG.basePort round; // 每轮换端口撞不同映射 const sock await tryOnce(peer, localPort); if (sock) return sock; await sleep(300); } return null; } function tryOnce(peer, localPort) { return new Promise((resolve) { let settled false; const sock net.connect({ host: peer.ip, port: peer.port, localPort, // 关键固定本地端口让映射可复用 localAddress: 0.0.0.0, timeout: CFG.punchTimeout, }); const finish (val) { if (settled) return; settled true; if (!val) sock.destroy(); resolve(val); }; sock.on(connect, () { sock.setNoDelay(true); sock.setKeepAlive(true, 20_000); finish(sock); }); sock.on(timeout, () finish(null)); sock.on(error, () finish(null)); // ECONNREFUSED / EHOSTUNREACH 都走这里 }); }localPort是这段代码的灵魂。不指定它操作系统每次给一个随机临时端口NAT为每个新端口分配新映射两端的SYN永远对不上号。指定之后重试才有可能复用已有映射。3.4 参数不是拍脑袋定的每个都要能说出理由参数建议值依据时间窗偏移200ms 提前量抵消信令到客户端的一跳调度抖动单轮超时3000–4000ms小于常见NAT的SYN重传周期避免死等重试轮数4超过4轮成功率提升趋平用户等待已到上限轮间间隔200–500ms给上一轮socket释放和映射回收留出缝隙心跳间隔15–25s低于多数NAT的TCP空闲回收阈值信令总预算≤6s超过这个时间用户体验开始明显下滑这些数字不是标准答案是权衡结果。比如单轮超时设到10秒理论上给SYN多几次重传机会但用户侧感知就是卡住了而且这段时间里用户的退出操作会让整个流程白做。我倾向于快速失败、快速兜底直连晚建立两秒的价值远不如立刻可用。4. 同时打开的实现细节内核、socket选项与那个微妙的时间窗4.1 固定本地端口带来的副作用与处理localPort指定后第一件事是端口占用。同一台机器上如果同时起多个客户端实例或者上一轮socket还在TIME_WAIT绑定就会失败并抛EADDRINUSE。Linux上因为默认带SO_REUSEADDR情况会宽松一些Windows上的语义不同同样的代码在一台机器上能跑、换一台就报错这类问题不写日志根本查不出来。我的处理方式是在tryOnce的error事件里区分错误码EADDRINUSE不当成对端不可达而是立刻换下一个端口重试并且记一条明确的日志。把不同性质的失败混在一个计数器里是排查阶段最大的障碍。另外要清楚一件事localPort固定只对本地有效公网侧看到的是NAT改写后的端口。所以两端都用45000这种做法实际意义是让两端的四元组结构尽可能对称某些NAT的哈希分配在对称输入下更容易落到相邻端口间接提高一点命中率。它不是银弹但在统计上确实有一点帮助成本是零值得保留。4.2 为什么必须几乎同时以及时间同步该做到什么精度同时打开的内核行为大致是这样本地socket处于SYN_SENT状态时如果收到一个源和目的都与自己发出的SYN完全对应的SYN内核不会回RST而是转入SYN_RCVD并回复SYN-ACK双方各自完成握手。这个路径成立的前提是——当对方的SYN到达时本地已经在同一个四元组上发过SYN。如果对方先到而你还没发你这边没有对应socket内核会回RST这个RST还可能被对方的NAT翻译成连接拒绝于是对方立刻判定失败。所以时间窗不是越准越好这种模糊要求而是必须让双方的SYN在各自的NAT映射建立之后、在对方超时判定之前相互抵达。精度上信令服务器与客户端之间的单程延迟通常有几十毫秒的抖动用服务器给一个绝对时刻、客户端按自己估算的偏移去等这种方式误差基本落在几十毫秒级够用。要更准就做一次四时间戳往返客户端发t0服务器回t1收到时刻和t2发出时刻客户端记t3偏移按((t1 - t0) (t2 - t3)) / 2算。这个补偿能把误差压到个位数毫秒代价是多一次往返值不值看你的网络抖动水平。4.3 先发一波再同时发这个土办法为什么有效理论上双方同时发就够了实践里我加了一步在正式对齐发包之前先各自向对方的公网端点发一次短超时的SYN不等结果就丢弃。这一步的目的是让本地NAT提前为本端点到对方公网端点建立出站映射。很多NAT在映射建立的那一刻就已经放行了反向流量哪怕这个SYN本身被对方丢弃了。这个技巧有个前提——本地NAT不会因为这次连接失败立刻回收映射。前面说过不同设备回收策略差异很大有的收到RST后秒回收有的能撑几分钟。所以它属于提高概率的手段不能当成必然成立的步骤。我在日志里统计过加了这一波预热端口受限锥形场景下的成功率大概从三成提到接近六成但对称型依然趴着——这也反过来验证了对称型失败的原因不是没预热而是端口根本不可预测。顺带说一句业界流传的低TTL预热把SYN的TTL设成1或2让它到不了对端只触发本地NAT建映射在纯Node里落不了地net模块没有暴露IP_TTL这类setsockopt接口。要真做得上原生扩展或者系统层面的工具配合。我在实验里用系统工具验证过这个思路确实有效但考虑到引入原生依赖的部署成本最终产品里没有采用而是用上面说的先发一波来近似。4.4 连上了不等于连对了握手校验别省直连建立后第一件事不是发业务数据而是做一次身份校验。原因很实际你连接的地址是信令服务给的如果信令被劫持或者对端ID被冒用你会把数据发给一个陌生节点。更常见的情况是IP复用导致的连接到错误实例——同一台公网NAT后面的多台设备端点可能一样连上的是隔壁那台。做法很简单建连后双方各发一个16字节随机数再各自回一个基于共享密钥的HMAC双向校验通过才算成功。整个过程控制在一次往返内不影响建立速度。这一步不做后面所有数据发给了谁的问题都无从追溯。5. 实测中最常遇到的失败形态与完整排查链5.1 现象一SYN发出去了对端毫无反应最早遇到的就是这个日志显示connect开始了然后一直等到超时对端没有任何入站记录。这种形态基本可以锁定为对方的NAT把SYN丢了原因通常是对方还没建立指向你的映射或者对方的过滤策略比预期更严。排查顺序我固定成三步。第一步确认对方的信令连接是否真的在线——很多打洞失败其实是信令侧对端已经掉线服务器给的端点信息是过期的。第二步在两端同时抓包看SYN是否真的发出了、源端口是多少。第三步对比两端的抓包结果如果A发出了SYN但B的网卡上没看到任何入站说明包死在了B的NAT如果B的网卡上看到了但B回了RST说明B的本机防火墙拦了。这三步里第一步最容易被跳过。我见过一次排查了半天的打洞失败最后发现是对端的进程被系统休眠挂起了信令连接还挂着但根本没在跑打洞逻辑。5.2 现象二连接建立了几百毫秒后被RST这个形态比超时更迷惑因为日志里明明白白写着connected。原因通常是同时打开路径中出现了两个socket抢同一个四元组。比如你在两轮重试之间的间隔太短第一轮的socket还没完全关闭第二轮的socket绑了同一个本地端口连同一个目标内核行为就变得不可预测最终某一方被RST。还有一种情况是应用层校验失败后主动关闭但日志没打出来看起来就像莫名其妙断了。所以校验失败必须记清晰日志别用一个笼统的handshake failed糊过去。处理方式轮间间隔给足至少200毫秒让上一轮socket确实进入关闭流程同时用sock.destroy()而不是sock.end()避免半关闭状态拖时间。我在早期版本里用end()结果FIN_WAIT状态的socket和下一轮的绑定打架现象就是上面说的连上就断。5.3 现象三一端显示成功另一端一直超时这是最典型的非对称NAT场景。A侧是全锥形它的NAT把B发来的SYN顺利放行A的内核完成握手A的connect回调触发但B那一侧的NAT是端口受限型A的SYN源端口和它记录的映射对不上包被丢弃B永远等不到回应。这种单边成功最危险因为如果应用层只等一端就绪就开始传数据会发现数据发出去石沉大海。防御手段是双边确认连接建立后必须走完那次HMAC校验往返只有收到对方的有效响应才算真正成功。A侧即使本地connect成功了在校验超时后也要判定失败并回退中继。这个坑我印象很深——早期版本里A侧先就绪就开始推文件结果推了几十MB全部堆在发送缓冲区最后超时回退用户看到的是卡了很久然后重新开始。5.4 把日志变成能定位问题的证据链排查阶段最有价值的不是日志多而是每条日志都能回答现在到了哪一步。我在打洞流程里固定打这几类事件信令连接建立、端点交换完成、约定的发包时刻、每一轮尝试的开始与结束、本地绑定的端口号、connect的结果与耗时、校验往返的结果、最终决策直连/中继。日志里带上双方ID和每次尝试的端口出问题时把两端日志按时间轴一拼问题基本就现形了。缺了端口号这一项你连是不是端口被NAT改写了都判断不了。6. 让它从实验变成可用兜底、保活与连接生命周期6.1 中继不是退路是必须存在的主干把中继做好比把打洞成功率从60%提到70%更有价值。因为打洞受制于用户所处的网络你再优化也覆盖不了全部而中继是确定性的只要两端能连到中转节点功能就一定能用。最简的中继就是配对转发第一个连上来的连接挂起第二个连上来后把两条socket互相pipe。生产版本还要加房间号、鉴权、流量统计和连接数限制。// relay.js —— 最小配对转发 const net require(net); const waiting []; net.createServer((sock) { sock.setNoDelay(true); if (waiting.length 0) { waiting.push(sock); sock.on(close, () { const i waiting.indexOf(sock); if (i 0) waiting.splice(i, 1); }); return; } const peer waiting.shift(); sock.pipe(peer); peer.pipe(sock); const close () { sock.destroy(); peer.destroy(); }; sock.on(error, close); peer.on(error, close); }).listen(9100, 0.0.0.0);这段代码只适合做压力测试不能直接上线——没有房间概念两个不相关的连接会被配到一起。上线版本至少要带一个roomId的握手帧并且对单IP的连接数做限制。6.2 保活不只是为了探测断线直连成功之后很多人就不管了结果用户传完一个小文件去泡了杯咖啡回来发现连接已经断了。原因是中间的NAT把空闲映射回收了或者运营商侧的会话表清掉了。setKeepAlive(true, 20000)能解决一部分问题它发的是TCP层的探测包对维持NAT映射有效。但应用层心跳还是建议加因为TCP keepalive的探测间隔受系统参数影响跨平台一致性不好而且它探不出连接还在但应用已经卡死的情况。应用层心跳用一个极小的帧就行几字节的内容主要目的是制造流量。有个反直觉的结论心跳间隔不是越小越好。设成1秒移动端功耗会明显上升而且很多NAT对高频小包有自己的限流策略。15到25秒是一个比较稳的区间具体取值靠实测你的目标网络环境定。6.3 重连不是重新打洞而是要重新走完整流程网络切换从Wi-Fi切到蜂窝之后原来的四元组全部失效直连必然断。这时候不能简单地connect原地址了因为公网端点已经变了。正确做法是重新连信令、重新交换端点、重新走一次打洞加兜底的完整流程。为了让上层业务无感需要在应用层做一个会话标识连接重建后用这个标识把上层的数据流续上。TCP本身不支持连接迁移所以这个续接逻辑必须由业务层实现。文件传输场景下就是重新建连后从断点续传消息场景下就是重连后补拉离线消息。6.4 安全边界打洞能力不该对任意目标开放一个能让两端直连的组件如果被滥用就变成了扫描和滥发的工具。所以上线前必须收紧几条信令连接必须带有效凭证未认证的连接不能请求对端端点对同一对端的撮合请求做频率限制防止被用来探测内部网络直连建立后的身份校验不能省防止连接被引导到非预期节点。我在实现里加的一条规则是——对端ID必须来自可信的名册不能由客户端任意指定。这条规则看起来限制了灵活性但避免了绝大部分滥用场景而且实际业务里本来也不需要连接任意ID。最后再分享一个实际体会TCP打洞这个事把它做成能跑通的Demo大概需要一天做成在真实网络里成功率可接受、失败时用户无感需要至少两周而这两周里绝大部分时间花在抓包、对比日志、调整参数上写代码的时间反而很少。如果你的场景里直连带来的收益延迟、带宽成本不足以覆盖这些投入那就老老实实用中继把省下来的时间做到业务上——这不是妥协是算过账之后的选择。