网络是通过精确的协议维系的。Content-Length 字段在每一个节点必须具有相同的意义。缓存不得重用需要验证的响应。格式错误的 HTTP/3 字段部分必须在正确的范围内失败。安全方法在通过反向代理后必须保持安全。
Webship 1.3.1 的核心原则是：速度只有在字节保持其意义时才算数。
这就是为什么我们将 Webship 描述为世界上与 RFC 最兼容的通用 Web 服务器。这是一个具有可见边界的工程声明，而不是声称每个 RFC 中的每个可选功能都存在。下图列出了影响 Webship 的活动服务器行为或其自有协议基础的 52 个 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 状态码。对于超大的请求字段，使用定义的 431 响应，当 HTTP 响应仍然可能时。
- RFC 6797 — HTTP 严格传输安全。Strict-Transport-Security 仅在安全传输中发送，并且绝不会从传输中立的缓存条目泄露到明文 HTTP。
- RFC 7235 — HTTP/1.1 身份验证。身份验证方案令牌是大小写不敏感解析的，包括受保护的 MCP 控制面。其通用 HTTP 语义现在位于 RFC 9110 中。
- [RFC 7239 — 转发的 HTTP 扩展]（https://www.rfc-editor.org/rfc/rfc7239.html）。操作员可以选择基于标准的转发字段、遗留的 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 宣告一个 HTTP/3 端点而不改变 URL 所表示的源。
- 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、only-if-cached、must-revalidate、proxy-revalidate、安全过期使用，以及有效和相关 URI 的失效处理。
- RFC 9112 — HTTP/1.1。请求行、字段、主体长度、传输编码、块、尾部、持续连接和关闭定界规则在应用分发之前执行。
- RFC 9113 — HTTP/2。伪字段顺序、authority、禁止的连接字段、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 拥塞控制。适当字节计数逻辑是 NewReno 拥塞控制系列的一部分，被 Webship 的 QUIC 实现使用。
- 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 数据报帧承载不可靠的 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 公钥基础设施证书和 CRL 配置文件。证书解析和生成的挑战证书使用正确的 DNS 和二进制 IP subjectAltName 形式。
- 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 Web Key 指纹。ACME 账户密钥指纹是以规范的 JWK 形式派生的。
- RFC 7807 — HTTP API 的问题详情。Webship 使用 RFC 8555 ACME 服务器所要求的问题文档格式。更新的“问题详情”规范取代了它用于新的通用 API，但 ACME 的规范性依赖仍然明确存在。
- RFC 8446 — TLS 1.3。Webship 使用 TLS 1.3 进行公共 TLS，包括会话票据、密钥更新、警报、早期数据策略和 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) 并测试对你的系统重要的边缘情况。