在传统网站托管架构中，服务器既是内容存储的单一来源，也是请求处理的唯一入口。这种集中式模型带来的问题显而易见：机房故障会导致整站不可用，流量峰值需要昂贵的带宽成本，而内容一旦部署便面临审查风险。PeerWeb 项目尝试从根本上改变这一范式，将网站内容分发至 P2P 网络，让每个访问者同时成为内容的提供者。本文将从工程实现角度解析其核心技术路径。
从集中式到去中心化：架构范式转换
传统托管模式下，网站运营者需要购买服务器或租用云主机，配置 Nginx 或类似反向代理，安装 SSL 证书，监控系统可用性。当流量突增时，运营者被迫临时扩容带宽；当硬件故障时，网站出现停机。这种架构的本质特征是「中心化」—— 所有请求必须经过同一组服务器节点，内容存储也集中在特定位置。
PeerWeb 提出的替代方案是让网站内容通过 WebTorrent 协议在用户浏览器之间直接传输。用户访问一个 PeerWeb 链接时，浏览器首先从_tracker 服务器获取活跃节点列表，然后通过 WebRTC 与这些节点建立 P2P 连接并下载内容片段。一旦某个用户完成了完整下载，他便成为新的「种子」节点，可以向其他访问者提供数据。这种架构中，访问量越大的网站反而越稳定 —— 更多的访问者转化为更多的分发节点，形成正向循环。
从实际运行数据来看，该系统确实能够实现抗审查与高可用目标。由于不存在原始服务器，内容无法被单一实体删除；只要网络中有一个节点在线，网站便可访问。成本方面，运营者无需支付任何托管费用，仅需首次上传时消耗本地带宽。
WebTorrent 协议在浏览器中的工程实现
WebTorrent 是专为浏览器环境设计的 P2P 协议，它复用 BitTorrent 的分片算法与 DHT 机制，但将传输层从 UDP 替换为 WebRTC。这一设计选择使得协议能够穿透浏览器沙箱直接运行，但同时也带来了若干工程约束。
在客户端配置层面，开发者需要关注几个关键参数。maxConns 控制单种子最大连接数，默认值 55 在移动设备上可能过高，建议根据设备性能下调至 20 至 30 之间。tracker 参数可以接受布尔值或配置对象，当需要自定义 tracker 列表时，应传入包含 announce 数组的对象。dht 开关同样支持细粒度配置，包括节点 ID 生成策略与消息超时设置。以下是一个典型的客户端初始化配置示例：
const client = new WebTorrent({
maxConns: 30,
peerId: generateRandomPeerId(),
tracker: {
announce: [
'wss://tracker.btorrent.xyz',
'wss://tracker.fastcast.nz',
'wss://tracker.openwebtorrent.com'
]
},
dht: { enabled: true }
});
文件下载完成后，开发者可通过 torrent.on('done') 事件获知传输完成，并通过 torrent.files 数组访问所有文件对象。每个文件对象提供 streamTo() 方法将内容流式传输至 DOM 元素，这对于视频等大文件尤为重要 —— 用户无需等待完整下载即可开始播放。对于网站托管场景，核心文件通常是 index.html，系统会优先下载该文件并在下载完成后立即渲染页面。
内容托管与分发的工程实践
将传统网站迁移至 PeerWeb 平台需要遵循特定的内容组织规范。根目录必须包含 index.html 文件，所有资源引用应使用相对路径，不支持绝对 URL。允许的资源类型包括 HTML、CSS、JavaScript、图片、字体等静态内容，这意味着纯静态网站可以无缝迁移，而需要服务器端渲染或 API 调用的动态网站则无法直接使用该方案。
上传流程被设计得尽可能简单：用户拖拽网站文件夹至上传区域，系统自动创建种子文件并生成唯一哈希值。该哈希值构成网站的唯一标识符，访问者通过 https://peerweb.lol/?orc={hash} 格式的 URL 加载内容。从技术角度看，上传过程实质上是将整个目录打包为种子文件并开始做种，期间会计算每个文件的 Merkle 树根哈希用于完整性校验。
保持网站在线需要至少一个活跃节点持续做种。浏览器端方案要求用户保持标签页打开，系统会显示「Keep this PeerWeb tab open to host your site」的提示。对于需要长期托管的场景，官方提供桌面客户端，支持后台运行并开机自启动，彻底解放浏览器标签页的约束。
智能缓存机制显著改善了重复访问的加载体验。系统使用 IndexedDB 持久化存储已访问站点的内容，缓存有效期为七天，过期后自动清理以控制存储空间占用。这意味着首次访问某站点需要完整 P2P 下载，后续访问则可直接从本地缓存读取，实现近乎即时的页面渲染。
安全模型与攻击面分析
将任意内容加载至浏览器存在固有的安全风险，PeerWeb 通过多层防护机制构建纵深防御体系。最外层是 iframe 沙箱，网站内容被嵌入至隔离的 frame 中执行，无法访问父页面的 Cookie、Storage 或 DOM。第二层是 DOMPurify 消毒，所有 HTML 内容在渲染前会经过严格过滤，移除危险的标签与属性，如 <script>、<iframe> 的 srcdoc 属性等。第三层是内容类型验证，系统仅接受预设的 MIME 类型，防止攻击者通过伪装的恶意文件绕过检查。
然而，这套防御模型仍存在争议点。Hacker News 讨论中有开发者指出，同时使用 iframe 沙箱与移除所有 JavaScript 可能过度限制了功能。若目标是保留交互性，更合理的方案是利用子域名隔离配合同源策略，将种子哈希作为子域名可天然实现源隔离。当前实现选择统一移除脚本虽更安全，但也使网站退化为纯展示型，限制了复杂交互应用的可能。
技术局限与演进方向
WebRTC 固有的局限性构成了该方案的天花板。浏览器无法像传统 torrent 客户端那样打开大量并发连接，对等发现依赖外部 tracker 服务器，在极端网络环境下可能面临穿透失败的问题。社区讨论中提到的混合 DHT 方案试图解决这一困境：通过引入支持传统 UDP 连接的桌面节点作为桥接层，帮助纯 WebRTC 节点完成 Offer/Answer 交换，从而扩展网络覆盖范围。
从实际部署角度，当前方案最适合的场景是内容相对固定、访问量中等的静态站点。大型媒体文件会显著延长初始下载时间，缺乏活跃节点时冷启动延迟较高。对于任务关键型网站，建议将 PeerWeb 作为 CDN 层而非唯一入口，保留传统服务器作为后备。
落地清单与关键参数
若计划构建类似的去中心化托管系统，以下工程参数可作为初始配置基准。种子连接数建议设置为设备性能与网络带宽的函数，普通桌面浏览器可尝试 30 至 50，移动端应降至 15 至 20。Tracker 服务器列表应包含至少三个不同运营方维护的节点以提高可用性。DHT 协议虽能提升去中心化程度，但会增加初始发现延迟，首次加载时可考虑禁用。缓存策略方面，IndexedDB 存储上限建议控制在 200MB 以内，避免影响浏览器正常使用。
将网站部署至 P2P 网络的成本趋近于零，但工程师需要理解协议行为与限制条件才能正确评估其适用场景。PeerWeb 展示了一种可行的替代方案，尽管距离大规模生产级部署仍有距离，但其核心理念 —— 让用户同时成为内容的消费者与提供者 —— 为构建更具弹性的互联网基础设施提供了值得借鉴的思路。
参考资料：PeerWeb 官方平台 (peerweb.lol)、WebTorrent 官方文档 (webtorrent.io/docs)、GitHub 开源实现 (github.com/Weedshaker/PeerWebSite)。