为什么HTTP/2要使用Pseudo-Header Fields（伪首部字段）？

来自RFC7540规范：HTTP/1.x使用message start-line（消息起始行）传递目标URI、请求方法、响应状态码，HTTP/2则使用以':'字符（ASCII 0x3a）开头的特殊pseudo-header fields实现该功能。

HTTP/1.x 消息起始行的核心缺陷 #

• 格式完全固化，扩展性极差：请求行固定为方法 请求URI HTTP版本结构，响应行固定为HTTP版本 状态码 原因短语结构，核心请求/响应元数据没有任何扩展空间，类似HTTP/1.1新增的请求域名标识只能塞到普通Host头部里，不属于原生起始行的一部分，很容易出现实现遗漏、解析异常的问题。
• 解析逻辑冗余易出错：起始行的语法规则和后续Key: Value格式的普通头部完全不同，客户端、服务端必须单独开发一套起始行解析逻辑，不同实现对边界场景的处理差异很容易引发兼容、安全问题，比如请求URI携带特殊字符、换行异常的场景下，不同服务的解析结果可能完全不同。
• 无法适配传输优化：HTTP/2的核心优化点之一就是HPACK头部压缩，单独存在的起始行无法和其他头部一起参与压缩，高频发送的小请求场景下，起始行的重复内容会产生很多不必要的传输开销。
• 不支持HTTP/2新特性：服务器推送、多路代理转发等HTTP/2新增特性需要传递额外的核心上下文，比如推送请求的关联标识、请求对应的权威域名等，固定结构的起始行完全无法承载这些新增信息。

HTTP/2 采用伪头字段的核心原因 #

伪头字段以:开头，格式和普通头部完全一致，完美解决了起始行的所有问题：

• 统一解析逻辑：所有请求、响应的核心元数据都和普通头部一起放在HEADERS帧中传输，不需要单独处理起始行，解析逻辑完全复用，大幅降低了协议实现的复杂度和出错概率。
• 彻底避免命名冲突：:开头的命名规则和普通头部的命名规范天然隔离，后续协议迭代新增核心元数据时，完全不需要担心和用户自定义的头部重名。
• 更高的传输效率：伪头可以和普通头部一起参与HPACK压缩，:method、:path这类重复度极高的字段，压缩后只需要几个字节就能传输，小请求的传输效率提升非常明显。
• 扩展灵活性更强：后续如果需要新增和请求/响应核心相关的属性，直接新增伪头即可，不需要修改底层的消息帧结构，向下兼容性更好。

内容的提问来源于stack exchange，提问作者Chor