PairDrop vs Send：本地还是基于链接的共享？

Source: Dev.to

快速判断

PairDrop 和 Send 解决不同的问题。

• PairDrop：即时的本地文件传输，适用于附近的设备（类似 AirDrop）。
• Send：通过加密的、会过期的链接与任何人共享文件（类似 WeTransfer）。

根据你的使用场景选择，而不是看哪个“更好”。

功能比较

自托管

PairDrop（单容器）

# docker-compose.yml
services:
  pairdrop:
    image: ghcr.io/schlagmichdoch/pairdrop:v1.11.2
    ports:
      - "3000:3000"
    restart: unless-stopped

• 单个容器，无数据库，无持久存储。
• 服务器仅处理 WebRTC 信令；文件从不经过服务器。

Send（app + Redis + storage）

# docker-compose.yml
services:
  send:
    image: registry.gitlab.com/timvisee/send:v3.4.27
    ports:
      - "1443:1443"
    volumes:
      - ./uploads:/uploads
    environment:
      - REDIS_HOST=redis
    depends_on:
      - redis
  redis:
    image: redis:7-alpine

• 需要两个容器（app + Redis）以及用于上传文件的持久卷。
• 配置包括 BASE_URL、上传限制和过期默认值。

资源使用

社区与维护

• PairDrop：约 4.5 k GitHub 星标，活跃开发，Snapdrop 的分支，具备房间、持久配对和文本共享功能。文档包括 Docker 部署和可选的 TURN 服务器设置。
• Send：约 4.8 k GitHub 星标，维护中止的 Firefox Send 的分支。维护者（timvisee）提供定期更新，并有单独的 Docker‑Compose 仓库提供部署示例。

结果： 两者的社区规模相似，且都有积极的维护。

Source: …

选择合适的工具

• 在以下情况下使用 PairDrop：

  • 您需要跨所有平台的类似 AirDrop 的功能。
  • 隐私至关重要（文件从不经过服务器）。
  • 传输发生在同一网络内的设备之间（办公室、家庭）。
  • 您希望实现零维护部署。

• 在以下情况下使用 Send：

  • 您需要与网络外的人共享文件。
  • 需要带有过期时间和密码保护的下载链接。
  • 存储文件的端到端加密很重要。
  • 您正在替代 WeTransfer 或类似服务。
  • 您需要控制下载次数。

• 两者一起使用： 它们是互补的。PairDrop 负责本地、快速、私密的传输；Send 负责远程、基于链接的共享。

• 如果只能选择其一：

  • PairDrop 适用于个人/家庭使用（大多数文件共享发生在您自己的设备之间）。
  • Send 适用于团队/商务使用（与客户、合作伙伴或网络外的任何人共享）。

常见问题

问：PairDrop 在没有 TURN 服务器的情况下能工作吗？
A: 可以，但仅限于同一局域网或 VPN 内的设备之间。要在 NAT 或互联网之间转发连接，需要 TURN 服务器（例如 coturn）。

问：Send 中的加密是真正的端到端加密吗？
A: 是的。加密在浏览器中完成后再上传。服务器只存储加密的二进制块；解密密钥位于 URL 片段（#…）中，永不发送到服务器。

问：Send 中的文件在过期后会怎样？
A: 加密文件会自动从服务器删除。文件及其元数据均不可恢复。

问：每个服务消耗多少内存？
A: PairDrop 仅使用约 30 MB RAM（仅信令）。Send 使用约 80‑110 MB RAM（应用 + Redis），并且还需要磁盘空间来存放已上传的文件。

相关主题

• 自托管 PairDrop
• 自托管 Send
• Send 与 WeTransfer 对比
• 自托管的 AirDrop 替代方案
• 自托管的 WeTransfer 替代方案
• 最佳自托管文件共享工具
• Docker Compose 基础