原文：知乎文章
众所周知，我这一阵子都在维护 https://github.com/liguobao/ds-harness-remote 这个DeepSeek Harness的插件，它的功能有点类似于Harness Agent上的“Windows远程桌面”、向日葵远程、QQ远程协助诸如此类，只是这个工具是给DeepSeek Harness 使用的。它能做到的是，让用户在任何一个有网络的地方，远程访问自己电脑上的DeepSeek Harness实例，随时随地继续工作。
那么，可能会有些朋友会好奇，它是怎么做到的呢？功能实现上的介绍，可以参考： DeepSeek Harness Remote 开发实录。jpg 这个文章。今天我主要想讲一下ds-harness-remote的网络端对端通讯是怎么实现的。
跨公网困难在哪？
首先，如果大家的电脑都拥有公网IP，那其实整个事情都是很简单的了。然而基于种种历史原因，我们大多数人的电脑、手机、其他的联网设备，都是没有公网IP的。一般大家的设备都在自己家里的一个局域网内，用比较简单的说法就是，大家都在一个WiFi网络下，然后，通过本地WLAN到附近基站出口，再到外面其他的服务器上。就如朋友们现在看到这个回答，从网络层来说，就是手机 -> 运营商出口设备 -> 知乎服务器。
从单向链路来说，知乎服务器并不需要知道手机在哪，它只需要把内容照着来的路扔回去就可以了，一切看起来是很简单的。
但是，如果是对于我们的场景上来说，从当前设备Client 端 想去和对着对面的Host端（另一台运行了DSH的电脑），中间是隔着无数种网络设备（藏着各种各样的地方），彼此也没有公网IP可以直接访问通讯，那这个时候需要做的事情就有点多了。
于是我们就进入了今天的话题所在：
如何让天各一方的两端设备，用最合适的方式来通讯？
P2P是什么？
P2P（Peer-to-Peer，点对点）技术是一种网络通信模型，
它允许网络中的参与者（节点）直接相互通信和共享资源，而无需依赖中央服务器作为中介。
在P2P网络中，每个节点既可以是资源的提供者（服务器），也可以是资源的消费者（客户端）。
概念上其实很简单，如果在大家都有公网IP的情况下，其实什么都不需要做就可以拥有P2P通讯了。但是，如果在没有自己的公网IP情况下，有办法也实现类似的逻辑吗？
有，使用 NAT 穿透（俗称 NAT打洞）。它的实现逻辑大概如下：
设备 A / 设备 B
↓
连接协调服务器(Remote Server)
↓
通过 STUN 获取公网 IP + 映射端口
↓
交换双方 Candidate / 地址信息
↓
同时向对方地址发送探测包
↓
NAT 建立临时映射
↓
尝试建立 P2P 直连
↓
直连成功 → 直接通信但是，很多时候 NAT 打洞并不能成功，常见的情况如下：
对称型 NAT（Symmetric NAT）：设备访问不同目标时，会分配不同的公网端口，另一端很难预测正确映射。
双方都在严格 NAT / CGNAT 后面：尤其运营商级 NAT，多层 NAT 会明显降低打洞成功率。
防火墙直接拦截 UDP：很多 NAT 打洞主要依赖 UDP，如果企业网、校园网、酒店 Wi-Fi 禁止或严格限制 UDP，基本就很难直连。
网络切换：例如手机从 Wi-Fi 切到 5G，公网 IP 和 NAT 映射都会变化，需要重新 ICE / 打洞。
多层 NAT：例如“家庭路由器 NAT + 运营商 CGNAT”，路径更复杂。
IPv4/IPv6 路径不兼容：一端只有 IPv6，另一端只有 IPv4，且中间没有合适的转换机制时，也无法直接连接。
用大多数人能理解的场景来说，在校园、严格管控网络的公司环境，酒店WiFi，公共WiFi下，一些神奇小区，这类的打洞可能都会失败。
但是，总不能失败了就不继续干活吧？生活还是要继续的。
于是，我们又有了 TURN中转 服务器。
TURN中转
顾名思义，就是中转站，如同联航的中转，火车票的中转。
流程如下：
设备 A / 设备 B
↓
连接 TURN 服务器
↓
向 TURN 申请中继地址（Relay Candidate）
↓
双方交换这个中继地址
↓
A 把数据发给 TURN
↓
TURN 转发给 B
↓
B 的数据同样经过 TURN 返回 A
↓
形成 A ↔ TURN ↔ B 的中继通信中转服务，典型实现可以直接用 coturn 开源方案，服务器一般需要开放类似：
3478/UDP STUN/TURN
3478/TCP TURN over TCP
5349/TCP TURN over TLS
49152-65535 Relay 数据端口范围然后，这玩意嘛，对服务器带宽要求比较高，毕竟逻辑上如下：
A 上传 10 Mbps
↓
TURN 收到 10 Mbps
↓
TURN 再发送 10 Mbps 给 B
10 Mbps 入站 + 10 Mbps 出站。
对于服务器来说，≈ 20 Mbps 网络吞吐
PS：eepSeek Harness Remote - 随时随地继续你的工作 使用了三台TURN服务器，分别位于上海、北京、北美，道理来说全球可用，就是这么神奇。jpg
这看起来很完美了吧？然而，TURN中转也不是100%成功的。UDP被封，连不上TURN服务器，网络到中继服务器太差等等，总是会有各种问题出现的。
这种时候，最终的兜底方案是：Server Relay。
Server Relay
万般不可用，总要顶着上。
它的逻辑如下：
客户端 A
→ 连接业务服务器
客户端 B
→ 连接业务服务器
→ Server 维护双方会话
→ A 的数据发到 Server
→ Server 转发给 B
→ B 的数据同样经 Server 返回 A
→ A ↔ Server ↔ B这个的好处是，Remote Server 的 WebSocket 总是能连得上的，能打开Remote 页面去尝试连接其他的设备，至少当前电脑的网络是正常的。网络正常，Relay 这个逻辑肯定是能跑通的，只是它需要的服务器资源和带宽，都是不小的一个东西了。
写到这里，基本是简要讲一下 ds-harness-remote 在网络是怎么实现的。逻辑上其他的点对点通讯方案，大差不差也是这些东西，仅供大家参考娱乐了~
扩展阅读：DeepSeek Harness Remote 网络原理：不开放公网端口，Client 怎么连上 Host？