Show HN: USTPS (UDP Speedy Transmission Protocol Secure) 与 USSH 深度解读

背景

在传统的互联网传输层，TCP（传输控制协议）长期占据主导地位，其核心优势在于可靠性与有序性。然而，TCP 的“队头阻塞”（Head-of-Line, HoL）问题在实时媒体流、游戏或高并发场景下成为了性能瓶颈。当 TCP 字节流中丢失一个数据包时，后续的所有数据都必须等待该包重传成功才能交付给应用层，这导致了不必要的延迟。

为了解决这一问题，QUIC 协议（HTTP/3 的基础）通过多路复用和流级有序性进行了改进，但在单个流内部依然存在有序交付的限制。与此同时，UDP 虽然速度快且无队头阻塞，但缺乏可靠性和安全性。

在此背景下，USTPS（UDP Speedy Transmission Protocol Secure）应运而生。这是一个基于 UDP 的可靠传输协议，旨在结合 UDP 的低延迟特性和类似 TCP 的可靠性，同时通过应用层处理有序性来避免传输层的队头阻塞。该项目目前处于 Beta 阶段，由 Codex 基于 GPT-5.4 (Low) 构建，并经过了在巴西至加拿大（约 140ms RTT）路径下 33% 丢包率的验证。

核心内容

USTPS 的核心设计理念是“速度优先”，它保留了 UDP 的无连接特性，但在其之上构建了一层可靠的、加密的传输机制。

协议架构与加密机制

USTPS 并非简单的 UDP 隧道，而是对 UDP 数据包进行了重新封装和加密。其协议栈包含两个主要层次：

1. 内层传输格式 (UST1)：即 UDP Speedy Transmission Protocol version 1，负责处理可靠性逻辑（如序列号、ACK、重传）。
2. 外层安全信封 (USS1)：即 UDP Speedy Secure version 1，负责提供 AEAD（认证加密带关联数据）保护。

在数据发送前，载荷首先被封装为 UST1 格式，然后被 USS1 加密信封包裹。接收端必须先解密 USS1 才能看到内部的 UST1 载荷。

安全特性包括：

• 强制 AEAD 加密：USTPS 不支持明文模式。支持的密码套件包括 chacha20 (ChaCha20-Poly1305)、aes-256-gcm 和 aes-128-gcm。
• 密钥交换：不使用静态预共享密钥 (PSK)。每个客户端在加入时执行 X25519 密钥交换，获得独立的临时 AEAD 会话密钥。
• TOFU (Trust On First Use)：客户端首次连接时信任服务器密钥，并将其存储在 ~/.ustps_known_hosts.json。如果后续连接中服务器密钥发生变化，客户端会报错中止，除非管理员显式使用 --regen-key 更新信任。
• 服务器密钥管理：服务器默认在 ~/.ustps_host_key 中保存持久的 X25519 主机密钥，确保重启后 TOFU 状态稳定。

可靠性与无序传输机制

USTPS 最显著的特征是**“可靠但无序”**（Reliable but Unordered）。

• 双重序列号系统：
  • seq：传输层序列号，用于 ACK、丢包检测和重传。
  • stream_pos：应用层流位置，标识载荷在逻辑字节流中的确切位置。
• 选择性重传 (Selective Retransmission)：不同于 TCP 的 Go-Back-N，USTPS 仅对丢失的特定 seq 发送 RETRANSMIT_REQUEST。发送端维护重传缓冲区，直到收到 ACK。
• 无队头阻塞：接收端不会因等待缺失的包而阻塞后续包的交付。例如，若收到包序列 1, 2, 3, 5, 6 而缺失 4，接收端会立即接受 5 和 6，并请求重传 4。应用层可根据 stream_pos 在内存中重组顺序，或者如果应用不需要严格顺序，可直接处理 5 和 6。
• 无拥塞控制：USTPS 故意不实现拥塞控制。在网络拥塞时，它不会像 TCP 那样主动降速，而是保持“速度优先”的 UDP 行为。这意味着它适合在受控网络环境或应用层自行管理带宽的场景中使用。

与 TCP 和 QUIC 的对比

• TCP：传输层强制有序。一个包丢失会导致整个流停滞（HoL 阻塞）。
• QUIC：解决了多流之间的跨流 HoL 阻塞，但在单个 QUIC 流内部，依然强制有序交付。
• USTPS：在传输层完全放弃有序交付。它只保证数据不丢失、不重复，并通过 stream_pos 提供重组元数据。有序性被推迟到应用层处理，或者对于不需要有序的应用（如某些实时视频流），可以直接消费乱序数据。

使用示例

服务器端 (Server):

python3 server.py \
--peer-port 0 \
--bind-ip 0.0.0.0 \
--bind-port 40001 \
--video "<HLS_URL_OR_LOCAL_FILE>" \
--cipher chacha20

• --loss: 用于测试，模拟服务器出站丢包率（0-100）。例如 --loss 40 模拟 40% 丢包，用于验证重传和恢复行为。
• --video-parameters: 允许自定义 ffmpeg 编码参数，否则默认使用 copy 模式。

客户端 (Client):

python3 client.py \
--peer-ip <SERVER_IP_OR_DOMAIN> \
--peer-port 40001 \
--bind-ip 0.0.0.0 \
--bind-port 0 \
--output-mode tcp \
--tcp-host 127.0.0.1 \
--tcp-port 1238 \
--cipher chacha20

• 客户端默认播放/重排序延迟为 350ms。
• 警告：--udp-unordered-live 模式非常危险，不建议用于普通媒体播放器，因为它会立即转发原始到达顺序的数据，可能导致解码器混淆或画面损坏。

关键要点

• 协议定位：USTPS 是一个基于 UDP 的可靠传输协议，专注于流媒体传输，目前处于 Beta 阶段。
• 安全默认：强制使用 AEAD 加密（ChaCha20-Poly1305 或 AES-GCM），无明文模式；使用 X25519 进行密钥交换，支持 TOFU 机制防止中间人攻击。
• 无序可靠：传输层保证数据不丢不重，但不保证到达顺序。通过 stream_pos 元数据允许应用层灵活处理有序性，从而彻底消除传输层的队头阻塞。
• 无拥塞控制：协议故意不包含拥塞控制逻辑，网络拥塞时不会自动降速，需依赖应用层或网络环境管理。
• 选择性重传：采用选择性重传机制，仅重传丢失包，而非回退重传，提高了高延迟或高丢包率下的效率。
• 测试验证：已在巴西至加拿大（140ms RTT）路径下，通过 33% 丢包率测试，验证了其在不冻结情况下的恢复能力。
• 应用层责任：如果应用需要严格的有序字节流，必须在应用层实现重排序缓冲区；如果应用能容忍或处理无序数据（如实时视频），则可获得更低延迟。

意义与影响

USTPS 的出现反映了互联网传输层技术向“更灵活、更快速”演进的趋势。它针对的是那些对延迟极度敏感、且能够自行处理数据有序性的应用场景，特别是实时音视频流（Streaming）。

1. 突破 TCP 瓶颈：通过剥离传输层的有序