HTTP/1的问题

包括HTTP/1.0(RFC 1945) and HTTP/1.1 (RFC 2616)。

Head of line blocking

浏览器很少希望得到一个简单对象，往往想同时得到很多对象。想象一个有很多图片的服务器。HTTP/1没有提供同时请求这些对象的机制。一个连接需要发送一个请求然后等待响应，响应完成才能发送下一个请求。HTTP/1有一个特性叫pipelining，允许一次发送一束请求。但是，仍然需要以发送顺序，一个一个地接收响应。pipelining受到互操作和部署的各种问题的困扰，使其使用不切实际。
如果任何请求或者响应出了问题，之后的请求/响应就全被阻塞了。这就是head of line blocking。为了不被阻塞，有的现代浏览器甚至可以打开六个连接访问特定主机，每个连接发送一个请求。这样实现的并行，还要面对head of line blocking问题。

Inefficient use of TCP

TCP是保守的，也是公平的。它的拥塞避免机制是建立在较差的网络环境上的，存在竞争时，尽量公平对待。
它之所以成功，不是因为最快，而是因为可靠。中心概念是拥塞窗口（congestion window），拥塞窗口是发送方在接收方确认之前可以发送的TCP数据包的数量。比如，如果拥塞窗口设置为1,发送方将发送一个包，接收方确认之后，才可以接着发送。
一次发一个包，效率不高。TCP的一个概念叫Slow Start，来决定当前连接的正确的拥塞窗口。慢启动的设计目标是让新连接感受网络状况，避免是拥挤的网络变得更糟。它允许发送方为每个接收到的acknowledgment消息发送一个附加的unacknowledged包。这意味着新连接在第一次确认以后，可以发送两个包，当他们被确认以后，它可以发送四个，等等。不久达到协议的上限，此时，连接进入拥堵避免阶段（congestion avoidance phase）。

在这里插入图片描述

需要几次往返才能达到最佳拥塞窗口大小。现代操作系统的初始拥塞窗口的大小是4-10个包。一个包的最大值一般是1,460字节，在发送方需要等待确认之前，只能发送5,840个字节。而现代网页一般有2M大小。理想的情况下，9次往返才能打开一个网页。如果打开六个连接，每个连接都要重复这些操作。

Fat message headers

HTTP/1支持压缩，但是不能压缩消息头。消息头也越来越庞大，甚至能达到几千字节。
2016年后，请求头的中位数达到460字节。一般来说，一个网页上有140个对象，这意味着要请求的头超过63KB。
不能压缩头，也可能导致客户端达到带宽限制。

Limited priorities

浏览器请求的对象，有些重要，有些不重要。但是HTTP/1没有考虑优先级问题。

扫描二维码关注公众号，回复： 4076224 查看本文章

Third-party objects

经常需要访问第三方对象。虽然有很多技巧可以减少第三方对象对浏览器性能的影响，但是web开发人员能控制的地方却很少。
也许它们会影响页面渲染的性能。（其实，HTTP/2也做不了更多）

HTTP2-缘起