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) 下載已簽名的版本。