Webship：全球最符合 RFC 的網頁伺服器

網路是由精確的協議維繫的。Content-Length 欄位在每一個節點都必須意味著相同的事情。快取不得重複使用需要驗證的回應。格式錯誤的 HTTP/3 欄位區段必須在正確的範圍內失效。安全的方法在通過反向代理後必須保持安全。

Webship 1.3.1 建立在一條規則上：只有當位元組保留其意義時，速度才重要。

這就是為什麼我們將 Webship 描述為世界上與 RFC 最兼容的通用網頁伺服器。這是一個具有明確邊界的工程聲明，而不是聲稱每份 RFC 的每個可選功能都存在。下圖列出了 52 個影響 Webship 主動伺服器行為或其自有協議基礎的 RFC。現行標準優先列出。已被取代的文件則標註為兼容性來源。草案規範不會重新標記為 RFC。

相容性是行為，而不是徽章

Webship 在生產伺服器最常出現模糊的地方應用標準：

• HTTP/1.1 框架拒絕衝突的長度、無效的傳輸編碼、過大的請求目標、格式錯誤的區塊以及請求走私形態。
• HTTP/2 和 HTTP/3 拒絕禁止的連接欄位、驗證偽欄位、限制壓縮欄位區段，並將串流錯誤與連接錯誤分開處理。
• 靜態檔案保留 HEAD 語義、驗證器、前置條件順序、位元組範圍、重新導向和內容類型。
• 反向代理在去除逐跳字段的同時，保留了幀結構、取消、尾隨訊息、升級、安全重試和轉發身份。
• 快取計算年齡、新鮮度、重新驗證、Vary、失效和陳舊使用規則，而不是將快取視為鍵值捷徑。
• TLS、QUIC、ACME、早期資料和 WebTransport 使用有界狀態和明確的失敗策略。

同樣的規則也適用於快速通道。Webship 並未定義一個「正確」的路徑和一個不同的基準路徑。

HTTP 語義、分幀、快取和代理

• RFC 3986 — 統一資源標識符 (URI)：通用語法。Webship 在快取失效決策之前，會對相對的 Location 和 Content-Location 參考，包括點段，進行正規化。
• RFC 6455 — WebSocket 協議。反向代理升級會驗證 WebSocket 金鑰、接受值、子協議、擴展和隧道轉換。
• RFC 6585 — 額外的 HTTP 狀態碼。對於過大的請求欄位，當仍能返回 HTTP 回應時，使用已定義的 431 響應。
• RFC 6797 — HTTP 嚴格傳輸安全。Strict-Transport-Security 僅在安全傳輸上發出，並且絕不會從傳輸中立的快取條目洩漏到明文 HTTP 上。
• RFC 7235 — HTTP/1.1 認證。認證方案標記（tokens）以不區分大小寫的方式解析，包括受保護的 MCP 控制界面。其一般的 HTTP 語意現已存在於 RFC 9110 中。
• RFC 7239 — 轉送 HTTP 擴展。操作員可以選擇使用基於標準的 Forwarded 欄位、舊版的 X-Forwarded 欄位、兩者都使用，或都不使用；不受信任的傳入身份欄位會先被移除。
• RFC 7540 — HTTP/2。這被保留作為 HTTP/2 相容的沿革；現行的 HTTP/2 協定是其後續版本，RFC 9113。
• RFC 7541 — HPACK：HTTP/2 的標頭壓縮。Webship 所擁有的 HTTP/2 堆疊在維護 HPACK 線路格式和哈夫曼編碼的同時，限定了解碼器狀態和編碼器表格。
• RFC 7838 — HTTP 替代服務。Alt-Svc 在不更改 URL 所表示的來源的情況下，廣告 HTTP/3 端點。
• RFC 8441 — 使用 HTTP/2 啟動 WebSockets。Webship 支援下游擴展 CONNECT 協商基礎。它不會假裝 HTTP/1.1 上游實作了 HTTP/2 擴展 CONNECT；不支援的上游組合會明確失敗。
• RFC 8470 — 在 HTTP 中使用早期資料。Webship 不會處理的早期請求會收到 425 Too Early，而不是以不安全重放的假設來處理。
• RFC 8941 — HTTP 的結構化欄位值。HTTP 優先值使用結構化欄位字典解析；格式錯誤的選用欄位將整體被忽略。
• RFC 9110 — HTTP 語義。方法、狀態碼、欄位、驗證器、前置條件、重定向、內容元資料、HEAD、CONNECT、OPTIONS，以及範圍語義在各協議版本之間共用一個現行契約。
• RFC 9111 — HTTP 快取。Webship 實作了修正年齡、明確鮮度、Vary、僅快取、必須重新驗證、代理重新驗證、安全陳舊使用，以及有效和相關 URI 的失效處理。
• RFC 9112 — HTTP/1.1。請求行、欄位、主體長度、傳輸編碼、分塊、尾部、持久連線及關閉界定規則在應用程式分派之前被強制執行。
• RFC 9113 — HTTP/2。偽欄位順序、權限、禁止的連線欄位、TE 限制、資料流生命週期、流量控制、GOAWAY 與錯誤範圍由 Webship 自有的 H2 路徑處理。
• RFC 9114 — HTTP/3。Webship 擁有其 HTTP/3 伺服器所使用的請求、控制流、SETTINGS、關鍵流、取消及流對連線錯誤路徑。
• RFC 9204 — QPACK：HTTP/3 的欄位壓縮。動態表的容量受公告限制約束，即使容量為零，指令串仍可解析，而無效狀態則成為所需的 QPACK 錯誤。
• RFC 9218 — HTTP 可擴展優先順序方案。緊急性與增量傳送指導 HTTP/3 排程，同時未知的優先參數保持可擴展性。
• RFC 9220 — 使用 HTTP/3 啟動 WebSockets。Webship 實作了現代隧道協議使用的 HTTP/3 擴展 CONNECT SETTINGS 基礎；這並不意味著每個可能的 CONNECT 協議都被接受。
• RFC 9297 — HTTP 資料報與封裝協議。WebTransport 會話使用有界封裝解碼與 HTTP 資料報關聯，未知的封裝被視為擴展點處理，而非解析失敗。
• RFC 9421 — HTTP 消息簽名。可選的 Ed25519 回應來源驗證可以涵蓋 Webship 發行版本與配置身份，而不取代 TLS 或應用程式驗證。
• RFC 10008 — HTTP QUERY 方法。Webship 將 QUERY 視為安全且可冪等，通過代理時保留其主體，在快取標識中包含主體和表示元資料，禁止啟發式新鮮度，支持條件和範圍行為，且絕不僅因使用 QUERY 就使快取失效。

QUIC 傳輸與擁塞控制

• RFC 3465 — 使用適當位元組計數的 TCP 擁塞控制。適當位元組計數邏輯是 Webship 的 QUIC 實現所使用的 NewReno 擁塞控制家族的一部分。
• RFC 4303 — IP 封裝安全負載。Webship 並未實現 IPsec ESP；其 QUIC 封包去重器僅以該 RFC 的滑動視窗防重放技術作為實作來源。
• RFC 5681 — TCP 擁塞控制。當 QUIC 在 TCP 實務上建立時，丟包和重新排序的閾值繼承已建立的擁塞控制約束。
• RFC 6298 — 計算 TCP 的重傳計時器。平滑的往返時間和方差計算有助於 QUIC 的恢復模型。
• RFC 8312 — 用於快速長距離網路的 CUBIC。這是保留作為演算法沿革的早期 CUBIC 規範；RFC 9438 是當前標準。
• RFC 8899 — 封包化層路徑 MTU 探測用於資料報傳輸。可配置的 DPLPMTUD 在不依賴脆弱的網路層訊號的情況下，發現可用的 QUIC 資料報大小。
• RFC 8999 — QUIC 的版本獨立屬性。在版本特定的解碼器運行之前，長標頭、連接 ID、版本協商和不變解析仍然是安全的。
• RFC 9000 — QUIC: 基於 UDP 的多路復用和安全傳輸。連接 ID、流、流量控制、遷移、地址驗證、重試、無狀態重置、傳輸參數以及關閉行為構成了 Webship 的 HTTP/3 傳輸基礎。
• RFC 9001 — 使用 TLS 保護 QUIC。初始密鑰、封包保護、標頭保護、重試完整性、密鑰階段和 TLS 整合遵循 QUIC-TLS 規則。
• RFC 9002 — QUIC 丟包偵測與擁塞控制。封包編號空間、回覆確認、PTO、丟包偵測、恢復與擁塞計數推動傳輸可靠性。
• RFC 9221 — 對 QUIC 的不可靠資料報擴展。協商的 QUIC DATAGRAM 幀攜帶不可靠的 WebTransport 流量，而不將其轉換為流內容。
• RFC 9287 — 對 QUIC 位元進行潤滑。QUIC 位元潤滑在保持協商安全的同時減少了僵化現象。
• RFC 9308 — QUIC 傳輸協定的適用性。操作上的預設值，例如有限的閒置時間和部署指南，會影響 Webship 的生產傳輸政策。
• RFC 9369 — QUIC 版本 2。版本 2 封包類型、初始金鑰、重試完整性、金鑰更新以及版本協商均與 QUIC v1 一併實作。
• RFC 9438 — 用於快速且長距離網路的 CUBIC。目前的 CUBIC 標準管理 Webship 的 CUBIC 擁塞控制器；在工作負載需要時，仍可選擇 BBR 和 NewReno。

TLS、證書與自動證書管理

• RFC 3339 — 網際網路上的日期與時間：時間戳記。ACME 續期窗口使用可互操作的網際網路時間戳記。
• RFC 4648 — Base16、Base32 和 Base64 數據編碼。ACME JOSE 值和 WebSocket 握手資料使用所需的 Base64 和 Base64url 字母表及填充規則。
• RFC 5280 — 網際網路 X.509 PKI 憑證與 CRL 配置文件。憑證解析與生成的挑戰憑證使用正確的 DNS 和二進位 IP 主體替代名稱格式。
• RFC 5869 — 基於 HMAC 的提取和擴展密鑰導出函數。HKDF-SHA-256 和 HKDF-SHA-384 導出，包括輸出範圍，支撐 TLS 和 QUIC 密鑰。
• RFC 6066 — TLS 擴展。SNI 選擇 DNS 身份，而字面上的 IP 地址則正確地從普通的主機名稱形式中排除。
• RFC 7301 — TLS 應用層協議協商。ALPN 在 TLS 邊界選擇 HTTP/1.1、HTTP/2、HTTP/3 以及獨立的 ACME 挑戰協議。
• RFC 7638 — JSON 網路金鑰指紋。ACME 帳戶金鑰指紋是以標準 JWK 形式衍生而來。
• RFC 7807 — HTTP API 的問題詳情。Webship 使用 RFC 8555 ACME 伺服器所要求的問題文件格式。更新的問題詳情規範對新的通用 API 已取代它，但 ACME 的規範性依賴仍然明確存在。
• RFC 8446 — TLS 1.3。Webship 對公共 TLS 使用 TLS 1.3，包括會話票證、金鑰更新、警報、提前資料政策以及 QUIC 金鑰推導。
• RFC 8555 — 自動化證書管理環境。帳戶、訂單、授權、挑戰、完成、證書下載及續期流程均已自動化，並具有有限的輸入處理能力。
• RFC 8737 — ACME TLS-ALPN-01 挑戰。僅挑戰的 TLS 路徑僅協商 acme-tls/1 並提供所需的關鍵 acmeIdentifier 證書擴展。
• RFC 8738 — ACME IP 識別碼驗證擴展。Webship 支援 IPv4 和 IPv6 證書訂單、二進位 IP SAN 以及用於 IP TLS-ALPN-01 驗證的反向位址 SNI。
• RFC 9525 — TLS 中的服務身份。在現行的服務身份規則下，比對 DNS 名稱和 IP 身份，不對 IP 地址使用萬用字元或通用名稱的捷徑。
• RFC 9773 — ACME 更新資訊擴充。更新窗口可以由 CA 提供，允許 Webship 安全地分散更新，而不是使用單一僵硬的本地計劃。

WebTransport：關於標準化的精確說明

HTTP/3 上的 WebTransport 並未被計為第五十三號 RFC。截至 Webship 1.3.1，其傳輸映射仍為 draft-ietf-webtrans-http3-16。Webship 在標準化的 HTTP/3、擴展 CONNECT、QUIC DATAGRAM、HTTP Datagram 以及上述命名的 Capsule 層之上實現了該草案。它還實現了協商的 RESET_STREAM_AT 擴展，以在 WebTransport 流被重置時保留可靠的會話識別前綴。

這個區別很重要。僅僅將草案稱為 RFC 並不能提升標準的相容性。相容性是通過明確追蹤草案、將其與普通 HTTP 路徑隔離、協商每一個擴展、界定每一個會話資源，以及測試取消和失敗行為來提升的。

為什麼這種廣度在生產中很重要

標準的漏洞很少是孤立的。HSTS 處理不當可能會跨越快取邊界。格式錯誤的 QPACK 指令可能終止無關的請求。危險的早期資料假設可能會重放操作。省略請求主體的 QUERY 快取鍵可能返回不同查詢的結果。刪除尾部或處理取消錯誤的代理可能會悄悄改變應用協議。

Webship 的架構將這些視為互相關聯的問題。解析器限制、安全檢查、快取、反向代理、傳輸狀態和儀表化共享明確的契約。其結果是一個伺服器可以在 HTTP/1.1、HTTP/2、HTTP/3、靜態傳遞、反向代理、串流和 WebTransport 之間切換，而不需要為每種模式定義不同的正確性標準。

驗證該聲明

不要單純相信任何絕對的說法。請閱讀 [Webship 1.3.1 文件](/docs/1.3.1)、檢查配置和協議邊界，並重現已發佈的行為。然後 [下載 Webship](/downloads) 並測試對您的系統重要的邊緣情況。