HTTP2特性概览|HTTP协议篇
# HTTP2特性概览
30 秒速记
HTTP/2保留方法、URI、状态码和头字段等 HTTP 语义，主要重构报文的编码与传输方式。- 报文改为二进制帧，头部和正文分别由
HEADERS、DATA等帧承载，解析规则更明确。 HPACK通过两端字典、索引和哈夫曼编码压缩重复头部，降低大量请求中的头部带宽开销。- 一个
TCP连接可承载多个虚拟流，各流的帧交错传输，实现多路复用、流量控制和优先级管理。 - 流级多路复用消除了 HTTP 请求按顺序排队的问题，但该方案仍运行在单条
TCP连接上；原文所述主流浏览器场景通常使用h2和TLS 1.2以上。 - 服务器推送允许服务端主动发送预计会使用的资源，但它改变了传统请求响应模式，也需要客户端和部署环境支持。
HTTP/2 没有改变 HTTP 的业务语义，核心升级集中在二进制分帧、头部压缩和多路复用。 请求会拆成 HEADERS、DATA 等帧，HPACK 用字典和索引减少重复头部，一个 TCP 连接也能交错承载多个流。这样可以避免多个请求按顺序排队，并支持流量控制和优先级管理，但底层仍受单条 TCP 连接约束。服务器推送能主动发送可能需要的资源，不过它改变了传统请求响应方式，还要考虑客户端和部署环境是否支持。
面试官追问
追问 1页面并发加载几十个 JS 和 CSS，开发仍为每个资源主动建立独立连接，并称这样才能避免请求排队，你会如何评审？
应先验证是否已协商使用 HTTP/2，再考虑让多个请求通过不同流复用同一连接并交错传输。独立建连会增加连接管理成本；但现有材料只有概览标题，不能据此承诺具体性能收益或忽略底层传输约束。
追问 2接口正文只有几十字节，却反复携带很长的 Cookie 和 User-Agent，后端只给正文启用 gzip，为什么还不能直接认定带宽问题已解决？
正文压缩与请求头重复开销不是同一个问题，启用 gzip 并不能自动证明头部也得到有效压缩。可结合 HTTP/2 的头部压缩机制检查实际编码与复用情况；由于详细材料未展开，不能凭标题断言具体字典状态或压缩比例。
追问 3线上抓包看到地址是 https://，测试负责人据此断言连接一定使用 HTTP/2，你会要求他补充什么证据？
应补充协议协商结果或抓包中的实际应用层协议，https 只能说明使用了安全的 HTTP 访问方式，不能单独证明版本。当前详细来源没有提供协商细节，因此结论必须限定在可观测证据内，不能只靠 URL 外观判断。
追问 4网关升级后部分请求仍显示旧协议，值班人员准备直接归因于浏览器不支持 HTTP/2，你会怎样收敛排查范围？
先核对客户端与服务端的协议协商结果、代理链路和最终连接所用版本，再判断能力缺失发生在哪一段。详细来源仅给出“特性概览”标题，无法支持更具体的故障结论；在拿到配置和抓包前，不应锁定浏览器。
追问 5架构评审要在 HTTP/1.1 与 HTTP/2 之间二选一，却只拿“新版本一定更快”作为依据，你会接受这个选型结论吗？
不会，选型至少要结合资源并发形态、头部重复程度、协议协商和现有基础设施兼容性，并用真实链路验证。现有详细材料没有列出具体特性与边界，因此只能提出验证维度，不能虚构性能数字或版本结论。
# 为什么不是 HTTP/2.0
30 秒速记
- 正式名称是
HTTP/2，不是HTTP/2.0。 - 从这一代开始，HTTP 版本标识只保留主版本，不再沿用
1.0、1.1式的小版本命名。 - 版本号变化用于表达协议层面的显著升级，而不是连续的小幅修订。
- 不能据此推导出
HTTP/2.1等名称；按原文口径，后续大版本直接使用HTTP/3这类命名。
正式名称是 HTTP/2，不是 HTTP/2.0，因为这一代开始只使用大版本号。 过去 1.0、1.1 的命名容易让人误解差异程度，所以工作组取消了小版本号，用代际名称表达协议的本质变化。名称不带 .0，不代表规范不能继续修订，只是不会用 HTTP/2.1 表示这些演进。工程上还要区分文档名称与协商标识：协议写作 HTTP/2，加密连接通常通过 TLS ALPN 协商 h2。
你一定很想知道，为什么 HTTP/2 不像之前的“1.0”“1.1”那样叫“2.0”呢？
这个也是很多初次接触 HTTP/2 的人问的最多的一个问题，对此 HTTP/2 工作组特别给出了解释。
他们认为以前的“1.0”“1.1”造成了很多的混乱和误解，让人在实际的使用中难以区分差异，所以就决定 HTTP 协议不再使用小版本号（minor version），只使用大版本号（major version），从今往后 HTTP 协议不会出现 HTTP/2.0、2.1，只会有“HTTP/2”“HTTP/3”……
这样就可以明确无误地辨别出协议版本的“跃进程度”，让协议在一段较长的时期内保持稳定，每当发布新版本的 HTTP 协议都会有本质的不同，绝不会有“零敲碎打”的小改良
原理拆解： HTTP/2 是协议的正式名称，数字表示协议代际，而不是“主版本加小版本”的十进制数。它与 HTTP/1.1 的差异涉及二进制分帧、多路复用和头部压缩等线格式变化，通信双方必须明确协商，不能把名称写成 2.0 后期待兼容解释。在线路上也不发送字符串 HTTP/2：加密连接通常通过 TLS ALPN 协商标识 h2，明文连接则可能使用事先约定或升级机制。
最小验证： 输入一个支持现代 HTTPS 的地址，让 curl 发起请求并输出最终协商到的协议版本，验证展示名称与协商标识的区别。
curl --http2 --silent --show-error \
--output /dev/null \
--write-out 'HTTP version: %{http_version}\n' \
https://www.cloudflare.com/
若客户端和服务端成功协商 h2，预期输出为 HTTP version: 2；--http2 允许协商使用 HTTP/2，但在无法协商时可能回退，因此输出 1.1 也是有效诊断结果。若 curl --version 的特性列表没有 HTTP2，则应先更换带相应库支持的构建。
边界与排查： 名称中没有 .0，不代表协议发布后不可修订。勘误、扩展和替代性规范可以持续演进，只是不通过 HTTP/2.1 这种名称表达。还应区分协议名称、ALPN 标识和工具输出：文档写 HTTP/2，握手使用 h2，某些客户端统计字段只显示 2。面试中把三者混为一个线格式字符串，或声称每次规范修订都必须升级到 HTTP/3，都不准确。
面试官追问
追问 1接口评审时，后端把网关能力写成“支持 HTTP/2.0，并兼容未来的 HTTP/2.1”，你会要求怎样修改？
应改成正式协议名称 HTTP/2，并删除对 HTTP/2.1 的预期。这里的数字表示协议代际，不是可继续递增的小版本号；勘误和扩展仍可演进，但不会借助 2.0、2.1 这类名称表达。
追问 2运维把站点从 HTTP/1.1 升级后，要求前端在请求代码里显式填写版本字符串 HTTP/2，这个落地方案成立吗？
通常不应由前端业务代码在线路上填写 HTTP/2 字符串。加密连接一般通过 TLS ALPN 使用标识 h2 完成协商，文档名称、握手标识和工具显示值属于不同层次；具体是否启用还取决于客户端、服务端及中间链路。
追问 3协议维护者只修订了一处规范细节，产品坚持发布为 HTTP/2.1，理由是“不升到 HTTP/3 就只能加小版本”，你怎么判断？
两种命名推断都不成立，小幅修订不应命名为 HTTP/2.1，也不意味着必须升级为 HTTP/3。新的 HTTP 代际应体现本质变化，而勘误、扩展或替代性规范可以独立演进；仅凭一次细节修订不足以确定新的协议代际。
追问 4线上文档写的是 HTTP/2，抓包握手却只看到 h2，监控面板又显示版本 2，值班同学怀疑三处配置不一致，你会怎么排查？
这三个值可以同时正确：HTTP/2 是正式名称，h2 是常见的 ALPN 协商标识，2 可能只是客户端统计字段的展示形式。应继续核对握手协商结果和实际连接，而不是比较字符串是否完全相同；若协商失败，连接仍可能回退到 HTTP/1.1。
追问 5测试用 curl --http2 请求站点后得到 HTTP version: 1.1，开发据此认定服务器虚假宣传，你会接受这个结论吗？
不能仅凭该结果直接定性，--http2 允许协商 HTTP/2，但在无法协商时可能回退。应先用 curl --version 确认构建包含 HTTP2，再检查服务端、TLS ALPN 与中间代理；最终输出 1.1 只能证明这次链路没有协商到 h2。
# 兼容 HTTP/1
30 秒速记
HTTP/2的兼容策略是保持 HTTP 语义稳定，只替换底层报文表达与传输格式。- 请求方法、URI、状态码和头字段等概念继续有效，上层应用无需因协议升级重新定义业务接口。
- URI 仍使用
http或https，没有为HTTP/2增加新的协议名。 - 相同语义和 URI 体系使浏览器与服务器能够进行协议升级或降级，减少用户和业务代码对版本切换的感知。
- 兼容不代表报文字节格式相同：
HTTP/2的语法层已经改为全新的传输格式，旧式文本报文解析方式不能直接套用。
HTTP/2 对 HTTP/1 的兼容，指的是保留原有语义，而不是继续使用相同的报文字节格式。 方法、URI、状态码和头字段仍然有效，上层路由、鉴权和业务处理通常可以复用；变化主要发生在编解码层，请求会转换成头部块和二进制帧。URI 也继续使用 http 或 https，因此客户端和服务端可以协商升级或降级。边界是依赖头字段顺序、大小写或手工拼接文本请求的程序，迁移时仍可能需要调整。
