跳到主要内容

13. 公平性

通常, HTTP 实现依赖底层传输在竞争带宽的连接之间维持 fairness (公平性). 当 intermediary (中介) 在客户端连接上收到 HTTP 请求时, 它会将这些请求转发到后端连接. 根据中介如何在不同后端连接之间合并或拆分请求, 不同客户端可能体验到不同性能. 如果中介在转发请求时也使用优先级信号, 这种差异可能被放大. Section 13.1 和 Section 13.2 讨论缓解这种不公平性放大的措施.

相反, Section 13.3 讨论服务器如何基于优先级信号, 有意向某些连接分配不等量的带宽.

13.1. 合并连接的中介​

当中介将来自多个客户端的 HTTP 请求合并到一条通向后端服务器的 HTTP/2 或 HTTP/3 连接中时, 来自某个客户端的请求可能携带比其他客户端请求更高优先级的信号.

对于在中介后方运行的服务器, 遵循 Priority header field 值有时是有益的. 例如, 资源受限的服务器可能会推迟传输具有后台 urgency 级别 (7) 的软件更新文件. 然而, 在最坏情况下, 多个客户端声明的优先级之间的不对称, 可能导致发往某个 user agent 的所有响应都被延迟, 直到发往另一个 user agent 的所有响应已完整发送.

为缓解这种公平性问题, 服务器可以将关于中介的知识作为其优先级决策的另一项输入. 例如, 如果服务器知道该中介正在合并请求, 那么它可以避免一次性完整服务响应, 而改为分配带宽 (例如采用 round-robin (轮询) 方式). 如果受限资源是中介与 user agent 之间的网络容量, 这种做法可以生效, 因为中介会缓冲响应, 并根据其实现的优先级方案转发分块.

服务器可以通过配置确定某个请求来自中介, 也可以检查该请求是否包含以下 header field 之一:

  • Forwarded [FORWARDED], X-Forwarded-For

  • Via (参见 [HTTP] 的 Section 7.6.3)

13.2. HTTP/1.x 后端​

Content Delivery Network (CDN) 基础设施通常会在前端和后端支持不同 HTTP 版本. 例如, 面向客户端的 edge (边缘节点) 可能支持 HTTP/2 和 HTTP/3, 而与后端服务器通信时使用 HTTP/1.1. 与连接合并不同, CDN 会将请求 "demultiplexes" (解复用) 到通向后端的离散连接. HTTP/1.1 (或更早版本) 不支持在单个连接内进行 response multiplexing (响应复用), 因此不存在公平性问题. 然而, 后端服务器 MAY 仍使用客户端 header 进行请求调度. 只有当客户端优先级信息可以限定到单个终端客户端范围内时, 后端服务器才 SHOULD 基于该信息进行调度. 身份认证和其他会话信息可能提供这种可关联性.

13.3. 有意引入不公平性​

有时, 相对于其他连接降低某个连接的传输优先级是有益的, 即使知道这样做会在连接之间, 进而在这些连接上服务的请求之间, 引入一定程度的不公平性.

例如, 服务器可以在只承载后台优先级响应 (例如软件更新镜像) 的连接上使用 scavenger congestion controller (拾荒式拥塞控制器). 这样做以延迟更新交付为代价, 提升其他连接的响应性.

最后于 更新