Webship 工程

使用 Webship 的流式处理：高吞吐量而不牺牲正确性

了解 Webship 如何通过 HTTP/1.1、HTTP/2 和 HTTP/3 使用自适应 kTLS、BBR 节奏控制、有界缓冲区和零错误完整性门来服务和代理大型媒体文件。

发表于 2026年9月10日

流媒体性能不仅仅是视频播放器的问题。软件制品、模型权重、备份、音频库和大型 API 导出都依赖于相同的基本原则：快速传输字节、保留精确的负载、尊重背压，并在客户断开连接时干净地停止。

Webship 将这些需求视为一个跨越 HTTP/1.1、HTTP/2、HTTP/3、直接文件传输、反向代理和 WebTransport 的传输问题。快速路径只有在保留帧结构、取消操作、尾部信息、安全检查和受限内存时才有用。

测得100 MB流媒体容量

Webship 1.3.1 Debian 容量运行通过固定的 100 MB 配置测量了中位负载吞吐量。每个被接受的样本都要求精确的 99,943,778 字节响应体，并且没有客户端、协议、代理、主要页面错误和 HTTP/3 数据包丢失错误。

| Webship 模式 | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | 直接文件传输 | 4,194.8 MiB/s | 3,574.3 MiB/s | 2,096.9 MiB/s | | 带 TLS 终止的反向代理 | 3,585.7 MiB/s | 3,355.0 MiB/s | 1,938.6 MiB/s | | 带 TLS 透传的反向代理 | 2,783.2 MiB/s | 2,135.0 MiB/s | 1,748.5 MiB/s |

在记录的比较中，Webship 在每个测量的协议中都产生了最高的直接和 TLS 终止中位数。完整矩阵包括 Nginx、Lighttpd、Caddy、HAProxy、Envoy、Pingora 和 Bun，详见[基准页面](/benchmarks)。

这些数字衡量的是基准主机的容量。它们并不意味着任意互联网路径的承诺。存储延迟、网络带宽、往返时间、数据包丢失、TLS策略、并发性和源行为仍然决定实际的传输速度。

一个二进制，三种传输策略

大型响应无法从与小型 HTML 文档相同的策略中受益。Webship 保持普通请求路径的保守性，并仅推广经过验证的批量响应。

HTTP/1.1: 文件周围的过渡更少

在 Linux 上，Webship 会将响应头和文件有效载荷保存在一个尽力而为的 TCP cork 间隔内。一旦大型 TLS 响应符合批量路径，直接文件传输可以从 Rustls 记录移动到经过审计的单向内核 TLS，并且可以使用 sendfile 而无需通过应用程序缓冲区复制有效载荷。

连接仍然从用户空间 TLS 开始。小的响应仍然保持在用户空间。Webship 仅在响应主体至少达到 1 MiB，证明连接正在传输大数据时，才请求 kTLS 转换。

HTTP/2：在不打断流控制的情况下进行批处理

HTTP/2 多路复用使得不受控制的缓冲代价高昂。Webship 批量写入，同时保持流和连接的流量控制限制。对于高并发流式传输，128 KiB 的 TLS 写缓冲区可以容纳两个 64 KiB 的 DATA 帧，而连接发送预算仍然是明确且有限的。

一个已经准备好的上游主体框架可以在不绕过超帧、尾部、取消、检查或背压的情况下预取。这在保持协议契约完整的同时减少了一次可以避免的调度器轮回。

HTTP/3: 使用 QUIC 节奏而不是 kTLS

HTTP/3 从不使用 TCP kTLS 路径。Webship 应用传输感知的 QUIC 调度、有限的数据报分组、DPLPMTUD，以及每个反应器的定时器驱动微批处理。大型 HTTP/3 响应和已接受的 WebTransport 会话可以选择 BBR，而不会改变普通流量使用的 CUBIC 策略。

集中式HTTP/3稳定性资格使用了七个已接受的样本。TLS终止流传输提供了1,938.6 MiB/s的中位数，变异系数为2.12%。TLS直通传输提供了1,748.5 MiB/s的速度，变异系数为1.65%。两组测试中均未出现主体完整性、客户端、协议和数据包丢失错误。

直接传输还是反向代理？

当Webship拥有已部署的文件树时，使用直接传送。它会移除源跳转，并实现最有效的静态文件路径。

一个最小的多协议网站看起来像这样：

listen = "0.0.0.0:443"
workers = 8
root = "/srv/media"

[[sites]]
domain = "media.example.com"
root = "/srv/media"

[sites.protocols]
h1 = true
h2 = true
h3 = true

[sites.tls]
cert = "/etc/webship/media-cert.pem"
key = "/etc/webship/media-key.pem"

当 Webship 必须按路径路由、应用 WAF 或 API Shield 检查、执行正文限制、添加转发头或观察 HTTP 字段时，使用反向代理 TLS 终止：

[reverse_proxy]
enabled = true
tls_termination = true

[reverse_proxy.protocols]
h1 = true
h2 = true
h3 = true

[reverse_proxy.tls]
cert = "/etc/webship/proxy-cert.pem"
key = "/etc/webship/proxy-key.pem"

[[reverse_proxy.routes]]
domain = "media.example.com"
path_prefix = "/"
upstreams = ["10.0.0.20:8080"]

当源端必须保留应用程序明文和活动会话密钥时，设置 tls_termination = false。直通无法检查加密的 HTTP 字段。因此，TCP 直通通过 ClientHello SNI 路由，而 HTTP/3 直通需要一个共享的 UDP 源端。

明确调整批量流

对于高并发 HTTP/2 TLS 流式传输，Webship 记录了这些与进程绑定的设置：

[runtime.settings]
h2_tls_write_buffer_bytes = "131072"
proxy_h2_tls_max_send_buffer_bytes = "131072"
proxy_h2_tls_connection_send_buffer_bytes = "33554432"

上面的连接预算为 256 个活动流提供了 128 KiB 的额度。将其视为容量决策，而不是通用默认值。在增加之前，请根据预期的并发情况测量内存、延迟和吞吐量。

在 Linux 上，加载内核 TLS 和 BBR 模块，并允许 Webship 服务账户选择 BBR。Webship 在所需的内核功能不可用时会在绑定之前失败，因此部署在未启用该功能时不能默默地使用优化路径。其他操作系统保留了为其平台记录的可移植 Rustls 和拥塞控制路径。

WebTransport 是一种不同的流式形态

WebTransport 在安全会话上结合了可靠流和不可靠数据报。它不使用 TCP kTLS。Webship 的有界诊断端点验证来源并强制执行会话、流、胶囊、数据报、字节和空闲时间限制。

在 1.3.1 容量测试中，直接 WebTransport 对可靠流的速度达到 1,018.1 MiB/s，对数据报的速度达到 1,038.9 MiB/s。TLS 直通的速度分别达到 548.6 MiB/s 和 629.7 MiB/s。两种模式在所有五个样本中均通过，零拒绝样本、零丢失数据报以及零客户端重大错误。

对于新的 WebTransport 客户，优先使用 HTTP/3。HTTP/2 路径存在是为了与旧的已过期草稿设置兼容。

在生产流量之前要验证什么

测试你将提供的确切媒体或工件大小，而不仅仅是一个微小的合成响应。
在客户端验证响应长度和内容摘要。
练习取消、范围请求、阅读缓慢者以及起源半关闭行为。
测量持续吞吐量，同时监控 CPU、内存、套接字错误、重传和尾延迟。
分别验证直接、TLS终止和直通模式；它们具有不同的安全性和路由边界。
在正常的生产流量中保持关闭监控，然后在调查时有意识地启用有限的诊断。
在内核、容器或 systemd 沙箱更改后，重新检查 Linux kTLS 和 BBR 预检。

当整个路径协同时，流媒体非常快。Webship 的设计使大容量数据优化保持特定于协议，同时保留一个操作模型和一个正确性标准。

阅读完整的[Webship 1.3.1 文档](/docs/1.3.1)，查看[基准方法和竞争者矩阵](/benchmarks)，或从[下载](/downloads)获取已签名的版本。