从 RustDesk 到 BT 下载：理解 P2P 网络技术

最近自己部署了一套 RustDesk 远程服务，实现了笔记本远程控制家里电脑，以及家里电脑反向控制放在公司的笔记本电脑

在实际使用中，我发现客户端显示的是「加密直连（TCP）」。这让我产生了一个疑问：

家里和公司的电脑都没有独立公网 IP，为什么还能直接建立连接？既然能够直连，自己部署的 VPS 又起到了什么作用？

顺着这个问题，我逐渐了解到了 P2P（Peer-to-Peer，点对点网络）技术，也把它与直播、BT 下载等常见应用联系了起来

一、什么是 P2P？

P2P，中文通常称为点对点网络

传统的 Client-Server（客户端-服务器）架构中，客户端通常需要向服务器请求数据，再由服务器返回结果

而 P2P 的核心思想是：网络中的节点可以直接与其他节点交换数据，不必始终依赖中心服务器完成数据传输

简单来说：

传统架构：用户向服务器请求数据，服务器向用户提供数据
P2P 架构：用户既可以是数据的接收者，也可以是数据的提供者

服务器并不一定消失，而是可以从数据传输者转变为负责协调、发现和管理节点的角色

二、为什么没有公网 IP，也能实现直连？

这是我在部署 RustDesk 时最感兴趣的部分

假设：

公司电脑：192.168.1.100
家里电脑：192.168.0.100
VPS：xxx.xxx.xxx.xx

公司和家里的电脑都处于各自的局域网中，内网 IP 无法直接被互联网中的其他设备访问

这里涉及一个重要的网络技术：NAT（网络地址转换）

当内网设备主动访问互联网时，路由器会将内网地址和端口映射到外部网络地址和端口。这样，设备虽然没有独立公网 IP，仍然能够正常访问互联网

P2P 技术可以利用这种机制，通过 NAT 穿透（NAT Traversal）尝试建立两个内网设备之间的直接通信

以 RustDesk 为例，整个过程可以简单理解为：

公司电脑和家里电脑分别连接 VPS 上的 hbbs 服务
hbbs 获取双方连接过来的公网出口地址、端口等网络信息
当一方请求连接另一方时，hbbs 协调双方交换连接信息
两台电脑按照协商结果尝试建立直接连接
如果 NAT 穿透成功，双方就可以直接传输数据

这里需要强调：公网 IP 并不是 VPS 分配给两台电脑的，而是从双方主动建立的网络连接中观察到的外部网络地址

这种技术并不是百分之百成功。如果网络环境限制较严格，例如某些对称型 NAT 或企业防火墙，就可能无法建立直连

三、RustDesk 中 VPS 到底起到了什么作用？

这次自建 RustDesk 服务端，我使用 Docker 部署了两个核心组件：

组件	主要作用
hbbs	设备注册、在线状态维护、连接协商和 NAT 穿透辅助
hbbr	直连失败时提供中继通信

它们承担的职责并不相同。

hbbs：负责帮助设备找到彼此

公司电脑和家里电脑都连接到 hbbs。需要建立远程连接时，hbbs 帮助双方交换必要的网络信息，协调连接建立

hbbr：负责在直连失败时传输数据

如果两台设备无法建立 P2P 连接，就可以通过 hbbr 转发远程桌面数据

这也解释了为什么客户端显示「加密直连（TCP）」时，远程桌面画面不需要经过 VPS

可以将整个过程分成三个阶段：

设备上线：VPS 负责设备注册和在线状态维护
建立连接：VPS 负责协调双方、辅助 NAT 穿透
数据传输：直连成功后，双方直接通信；直连失败则使用中继

因此，P2P 并不是不需要服务器，而是让服务器不必始终参与实际数据传输

四、P2P 在直播领域的应用

理解 RustDesk 后，我又想到一个问题：

现在大型直播平台同时有成千上万甚至上百万观众，难道主播真的需要把实时视频数据直接传输给每一个观众吗？

当然不是。

查阅了资料后发现，目前主流直播平台通常采用 CDN（内容分发网络）进行视频分发

基本流程：

主播通过 OBS 等软件采集、编码视频
视频上传到平台的直播接入服务器
平台进行转码、封装和处理
视频被分发到多个 CDN 边缘节点
观众从距离自己较近的 CDN 节点获取视频

这种架构能够将主播的一份直播流分发给大量观众，避免所有观众直接访问同一台源服务器

不过，P2P 也可以应用于直播

例如 CDN + P2P 混合分发模式：

CDN 提供稳定的视频数据源
观众获取视频片段后，可以继续分享给其他观众
其他观众既可以从 CDN 下载，也可以从附近的节点获取视频片段

这样能够分担 CDN 的带宽压力

但纯 P2P 直播存在上传带宽不足、节点不稳定、延迟控制困难等问题，所以大型直播平台通常不会完全依赖纯 P2P

五、BT 下载：最经典的 P2P 应用之一

这也是我最熟悉的一种 P2P 应用

平时下载大型游戏、电影时，经常会接触到 BT 种子

BT（BitTorrent）是一种典型的 P2P 文件分发协议

与传统 HTTP 下载不同，BT 并不要求你从单一服务器获取完整文件，而是将文件拆分成许多片段，由多个节点共同提供

例如，一个 100 GB 的游戏安装包：

A 节点拥有文件的前几个片段
B 节点拥有另外几个片段
C 节点拥有其他片段

下载者可以同时从多个节点获取不同的数据片段

更有意思的是：下载者在获得部分文件片段后，也可以将这些片段上传给其他用户

也就是说，BT 下载中的用户往往同时承担下载者和上传者两个角色。

为什么下载人数越多，速度可能越快？

因为参与下载的人越多，网络中可能出现越多拥有不同文件片段的节点

如果这些节点具有充足的上传带宽，整个资源群（Swarm）的数据供应能力就会提高

这也是为什么一些热门游戏资源的 BT 下载速度可能非常快

但下载人数并不等于有效上传者数量

如果一个资源有 1000 个下载者，却只有一个上传带宽很低的做种者，那么下载速度仍然可能很慢。

BT 中有两个重要概念：

名称	含义
Seeder	已经拥有完整文件，并向其他节点上传数据的人
Leecher	正在下载文件，同时也可能上传已获得的数据的人

如果一个冷门资源没有任何节点持有你缺少的文件片段，即使能够找到 Tracker，也无法完成下载。

Tracker 和 DHT

那么 BT 节点如何找到彼此？

这里涉及两个重要机制：

Tracker：帮助下载者发现同一个资源群中的其他节点
DHT：分布式哈希表，可以在没有中心 Tracker 的情况下帮助节点发现其他节点

它们解决的是节点发现问题，而不是实际文件传输问题

这与 RustDesk 的 hbbs 有一定相似之处：都承担了帮助节点发现彼此、建立通信的职责，但实现方式和协议并不相同。

六、几种应用背后的共同思想

通过这次学习，我把几个看似不同的应用放在一起进行了对比：

应用	主要技术	核心作用
RustDesk	P2P、NAT 穿透	两台设备直接远程通信
BT 下载	BitTorrent、DHT	多个节点共同分发文件
大型直播	CDN、部分场景使用 P2P	大规模分发实时视频
视频会议	WebRTC、P2P、SFU	低延迟实时音视频通信

它们并不一定采用完全相同的网络架构，但有一个共同的设计思想：

尽可能让网络中的节点参与数据交换，而不是让所有数据都必须经过一个中心服务器。

七、总结

这次 RustDesk 自建服务让我从一个实际问题出发，逐渐理解了 P2P 网络技术

最初我以为，两台没有公网 IP 的电脑不可能直接通信；后来才了解到，借助 NAT 穿透，两台设备可以尝试建立直接连接

也明白了 VPS 并不是一定要负责传输所有数据，它还可以承担设备发现、连接协商和备用中继等职责

再联系到直播和 BT 下载，就能发现 P2P 的应用其实非常广泛

它不仅解决了设备之间如何直接通信的问题，还让普通用户的设备成为网络资源的一部分

从某种意义上说：

传统网络更强调服务器向用户提供资源，而 P2P 让用户之间也能够直接提供资源、交换资源

这就是我对 P2P 技术最直观的理解