题干与适用场景
你的代理希望在 HTTP/1.1 协议升级确认前就发送后续数据以降低延迟。请说明风险、适用边界，以及如何修改客户端和代理实现。
面试官考察点
- 是否理解 HTTP/1.1 升级在收到确认前仍可能被拒绝，不能把历史成功当作安全保证。
- 是否能解释攻击者控制的数据如何在拒绝分支被重新解析为 HTTP 请求。
- 是否区分 Upgrade、CONNECT、WebSocket 与 HTTP/2/3 的不同约束。
- 是否给出等待 2xx、关闭连接、禁用乐观发送和可观测回退等工程措施。
回答前需要澄清的问题
- 使用的是 Upgrade 还是 CONNECT，升级目标协议和 HTTP 版本是什么？
- 后续字节是否可能由不可信应用、用户或第三方 origin 控制？
- 连接是否带有客户端证书、代理认证或其他连接级信任？
- 目标是降低握手延迟，还是必须保持 HTTP/1.1 兼容和连接复用？
30 秒回答框架
我会默认禁止 HTTP/1.1 在确认前发送不可信后续数据。客户端等待升级响应；CONNECT 代理至少等待 2xx，或发送 Connection: close 并在失败后关闭连接。拒绝时不能复用已经混入未知协议字节的连接。对 HTTP/2/3 单独验证多路复用语义，记录升级结果和回退原因，先在测试代理中做请求走私和解析差异测试。
分步骤深入解答
1. 识别乐观发送的前提
HTTP/1.1 客户端可用 Upgrade 或 CONNECT 请求切换协议，但服务器可能拒绝。客户端若在收到状态码前发送新协议字节，实际上同时面对两种解析：接受时按新协议处理，拒绝时按 HTTP/1.1 处理。不能用“上次成功”推断本次一定接受。
2. 解释请求走私路径
当后续数据由不可信来源控制时，拒绝分支可能把这些字节解释为额外 HTTP 请求。若连接级认证已通过，代理可能把攻击者构造的请求误认为客户端已认证请求。代理和客户端解析边界不一致，还可能触发请求解析器漏洞。
3. 选择安全实现策略
最稳妥的策略是收到确认后再发送后续数据。RFC 9931 对 HTTP/1.1 CONNECT 要求代理客户端等待 2xx，或带 Connection: close；代理在拒绝未满足安全条件的 CONNECT 时应关闭底层连接。若确实需要低延迟，优先使用 HTTP/2 或更高版本的明确流语义，并验证目标协议自己的握手规则。
4. 做回退、监控与测试
升级失败时把连接标记为不可复用，重新建立 HTTP/1.1 请求；不能把已发送的未知字节当作可重试请求。指标记录升级接受率、拒绝原因、连接关闭和重试次数，日志不记录凭据和请求正文。测试覆盖不可信 payload、代理认证、401/407、重定向、超时、解析差异和 HTTP/2/3 回退。
高质量示范回答
我不会把乐观发送当成普遍优化。HTTP/1.1 的 Upgrade 或 CONNECT 在确认前仍可能被拒绝；如果后续字节受攻击者控制，拒绝分支可能按 HTTP/1.1 把它们解析为额外请求，形成请求走私，连接级认证会放大影响。因此默认等待服务器确认。CONNECT 代理至少等待 2xx，或使用 Connection: close 并在拒绝后关闭连接；Upgrade 失败的连接不复用。需要更低延迟时评估 HTTP/2/3 的流语义和目标协议约束。通过不可信 payload、认证代理、错误状态、重定向和重试测试验证，监控接受率与关闭原因，保证回退不会泄露请求或凭据。
常见错误
- 看到近期升级成功就提前发送任意后续字节。
- 只验证服务器端，忽略客户端、代理和第三方数据源的解析边界。
- CONNECT 被拒绝后继续复用连接或转发已缓冲 payload。
- 把 WebSocket 的握手规则套用到所有 Upgrade token。
- 只用 HTTP/1.1 测性能，未区分 HTTP/2/3 的流和连接语义。
- 重试时复用含有未知字节的请求，或把正文写入诊断日志。
追问及应对
为什么 Connection: close 能降低风险？
它要求连接在请求处理后关闭，拒绝升级时不会继续在同一连接解析可能混入的后续字节。它牺牲连接复用，应结合等待 2xx 的策略选择。
WebSocket 可以乐观发送吗？
WebSocket 握手规则要求客户端等待服务器响应后再发送后续数据，不能把其他协议的经验直接泛化。每个 Upgrade token 都应遵守自身规范。
如何兼顾延迟与安全？
先测量等待确认的真实成本，再优先使用 HTTP/2 或 HTTP/3；若必须支持 HTTP/1.1，就等待确认并做连接关闭回退。任何优化都不能让不可信数据跨越未确认的解析边界。