一、队头堵塞

1、非管线化

如图，http 请求必须等到上一个请求响应后才能发送，后面的以此类推，由此可以看出，在一个 tcp 通道中，如果某个 http 请求的响应因为某种原因没能及时返回，那后面的请求都会被阻塞

2、管线化

管线化限制服务器端需按照请求的发送顺序返回响应，如果其中某个响应因为某种原因延迟了几秒，那后面的响应都会被阻塞

HTTP/1.1 管线化解决了请求的队头阻塞，但没有解决响应的队头阻塞

二、如何解决？

HTTP/1.1 建议客户端使用并发长连接，RFC2616 明确限制每个客户端对同一个域名可以建立两个长连接，但是一般浏览器会增加到 6 ~ 8 个，其中，谷歌浏览器是 6 个，也就是页面中如果对同一个域名有多个 http 请求，谷歌浏览器会对这个域名建立 6 个 tcp 长连接，在每个长连接里面再去处理 http 请求，但是这种方案对服务器的挑战非常大，甚至有些 web 优化方案中还会突破 6 ~ 8 的限制，那就是域名切片，因为长连接针对的是同一个域名，如果开发人员将资源分布在不同的域名上，那么长连接的数量是可以被突破的，但这样做无疑会增大服务器的连接数，当服务器面对海量请求的话，可能会出现问题，那怎么办呢？HTTP/2.0