征收问题关于 HTTP2，你有什么想了解的吗？

Posted 2021-04-18 山尽写东西的cache

因为工作刚好被问起，最近几周有空在看 HTTP2 的资料，整理了很多笔记与个人思考。

尽管很多年过去了，目前互联网上关于 HTTP2 原理介绍还是非常缺乏，非常不全面，包括英文世界。

如：

HTTP2 的 data 帧 是怎么样传送与收的，是否有分帧？

帧与流具体是怎么样区分的？

等等。

你有什么想了解的？欢迎留言。

之后会考虑整合到新文章中。

我先放部分笔记：

HTTP 的不足

在阅读此章时，读者可以给自己一个思考时间，锻炼设计与思考能力—— 目前在用的 HTTP 协议，你认为有哪些不足呢？你可以重新设计一个替代它并且尽可能兼容的协议，你会怎么做呢？

可尝试自己写下设计，定会受益甚多。

TCP连接数过多

HTTP1.0 只允许一条 tcp 链接上处理一个 request，尽管后来的 HTTP1.1(现在常用的版本）允许 pipelining， 管道，通过这个管道，浏览器的多个请求可以同时发到服务器，但是服务器的响应只能够一个接着一个的返回 (但各大浏览器有些不支持 / 默认关闭，因此这功能可以说是鸡肋)。

HTTP 头部过多重复

Host、Accept-Encoding、Connection、origin、content-type 等等一堆头部，都在不同的请求中重复出现。

除了浪费大量流量，还会导致 TCP 的初始拥塞窗口(initcwnd)快速满了，当多个请求准备在同一个tcp 连接上发送时，会导致大量延迟——当 initcwnd >= ssthresh（slow start threshold） 时，tcp就会进入 “拥塞避免算法”，把发送的速度调慢，避免增长过快导致网络拥塞，慢慢的增加调整到网络的最佳值。

当然初始拥塞窗口(initcwnd)也不能调太大来避免。

If the initcwnd values is large, then there will be fewer RTTs required to download the same file. But we cannot set initcwnd to a huge value as the network environment and the routers also has the limitation of having limited buffers. If exceedingly large values are set, it may lead to router buffer overflows, packet loss, packet re-transmissions. So, we need to set an optimal value for the initcwnd which is directly proportional to the network bandwidth.

使用文本协议

文本协议尽管带来了可读性以及方便程序员 debug，但这是高性能网络程序要竭力避免的——君不见每个公司内部都要搞一个自己的二进制协议吗？二进制，每个在网络上交流的 bit 的意义都被发挥得淋漓尽致。

而说到 可读与debug 的问题，自然浏览器（客户端），服务器（框架）可以帮你解决，套上一层中间层就好。

HTTP2 概览

HTTP2， 为解决以上问题而生。

•允许多个 request/response在同一个 tcp 链接上发送•高效压缩头部（http header）•二进制协议，真正的多路复用•支持请求分优先级发送，优先级越高如核心 css、html，优先发给客户端•支持服务器预测并推送客户端可能需要的资源，让客户端先做缓存（server push），榨干服务器•兼容 HTTP1.1 的语义，尽可能一致。

帧（frame）

HTTP2中二进制协议的基本单元叫 frame（帧），不同frame 有不同作用，如：

•HEADERS 帧发送http 的 request 或者response•DATA 帧发送body数据•PUSH_PROMISE 帧用来告知对端初始化哪些数据，就是以上说到的 server push 功能•WINDOW_UPDATE 用来做流量控制

等。

帧的格式如下，熟悉二进制协议的你对此想必很清晰：

+-----------------------------------------------+| Length (24) |+---------------+---------------+---------------+| Type (8) | Flags (8) |+-+-------------+---------------+-------------------------------+|R| Stream Identifier (31) |+=+=============================================================+| Frame Payload (0...) ...+---------------------------------------------------------------+

•length：frame payload 的长度•type：frame 的类型•flag：保留给 frame 的类型用•R：保留的一位•Stream Identifier：unsigned 31 位整数，用来区分 stream•Frame Payload: frame 携带的可变长数据，可为空

以上 6 种东西，Frame Payload可以没有，但是其他必须有。

所以所有 frame 必定会有至少 24 + 8 + 8 + 1 + 31 + (0…) = 72 位的数据。