跨网浏览器端P2P直连可行性问询：无服务器/仅初始服务器

嘿，我来帮你理清楚这些问题——刚好我对WebRTC这块挺熟的，咱们一步步拆解：

1. 仅交换IP，无第三方服务器能否直接在不同局域网浏览器间用JS传字节？ #

答案是不行，核心原因有两个：

• NAT限制：绝大多数家用路由器采用的是「对称NAT」，这种情况下，即使你拿到对方的公网IP和端口，你的出站请求端口和对方路由器预期的端口不匹配，连接会被直接拒绝。你提到的chownat是在操作系统层面做NAT穿透，但浏览器里的JavaScript受限于安全沙箱，没有权限直接操作网络层的穿透逻辑，没法模拟这类工具的行为。
• 浏览器安全限制：本地加载的HTML（file://协议）本身存在严格的网络权限限制，连发起常规跨域请求都受限，更别说直接建立跨局域网的点对点连接了。

2. 仅初始化阶段用服务器，后续点对点通信可行吗？ #

完全可行！这正是WebRTC的核心设计目标，而且Chrome、Firefox等主流浏览器都完美支持，完全不需要手动配置路由器端口。

你提到的RTCDataChannel就是干这个的，之前试的Simple_RTCDataChannel_sample应该是同局域网内的演示，要改成跨互联网的连接，关键是加一个信令服务器完成初始的对等体发现和连接信息交换，具体改造步骤如下：

• 第一步：搭建一个极简的信令服务器（用Node.js + WebSocket就能快速实现，不需要复杂框架），它的作用只是传递两个对等体之间的连接元数据，不会转发实际业务数据。
• 第二步：双方都连接到信令服务器后，一方发起创建offer（包含自身媒体/网络能力的SDP描述），通过信令服务器发给另一方。
• 第三步：另一方收到offer后，生成answer（自己的SDP描述），再通过信令服务器回传给发起方。
• 第四步：双方同时收集ICE候选（这些候选包含自身公网/内网IP和端口，由STUN服务器协助获取），并通过信令服务器互相交换这些候选。
• 第五步：当双方交换完所有必要信息后，WebRTC底层会自动尝试建立点对点连接，成功后RTCDataChannel就可以直接传输字节数据了——这时候信令服务器可以完全断开，后续通信全程点对点，不经过第三方。

补充几个关键细节：

• STUN服务器：不用自己搭建，很多公共STUN服务器可以直接用（比如stun.l.google.com:19302），它的作用是帮WebRTC获取你的公网IP和端口，实现NAT穿透。
• TURN服务器：如果双方的NAT类型过于严格（比如对称NAT互碰），STUN穿透失败，就需要TURN服务器作为中继转发数据，这种场景比较少见，也有公共TURN服务器可选。
• 本地HTML运行建议：如果是file://协议加载的本地HTML，浏览器可能限制WebSocket连接到信令服务器，建议把HTML放到简单的HTTP服务器上运行（比如用python -m http.server或Node.js的http-server），权限会更宽松。

内容的提问来源于stack exchange，提问作者Basj