说一下请求是异步的为什么会造成阻塞?

HTTP 协议的队首阻塞

队首阻塞：队首的事情没有处理完的时候，后面的都要等着。

HTTP1.1 的队首阻塞

HTTP1.1 版本上使用了一种 Pipelining 管道技术来并行发送和处理多个请求。让客户端能够并行发送多个请求，服务器端也可以并行处理多个来自客户端的请求。在一个 TCP 连接中，发送多个 HTTP 请求，不需要等待服务器端对前一个请求的响应之后，再发送下一个请求。但是使用了管道技术的 HTTP/1.1，根据 HTTP/1.1 的规则，服务器端在响应时，要严格按照接收请求的顺序发送，即先接收到的请求，需要先发送其响应，客户端浏览器也是如此，接收响应的顺序要按照自己发送请求的顺序来。这样造成的问题是，如果最先收到的请求的处理时间长的话，响应生成也慢，就会阻塞已经生成了的响应的发送，也会造成队首阻塞。

总的来说，管道技术允许客户端和服务器端并行发送多个请求和响应，但是客户端接收响应的顺序要和自己发送请求的顺序对应，服务器端发送响应的顺序要和自己接收到的请求的顺序对应，这样做似乎没什么问题，看起来是不是“FIFO"先来先服务的方式，如果前面收到的一个请求，在服务器端处理的时间很长，生成响应需要很多时间，那么对于后面的已经处理完生成响应的请求来说，它们只能阻塞等待，等待前面的响应发送完后，自己才能被发送出去(即使该请求的响应已经生成)造成了“队首阻塞”问题。可见队首阻塞发生在服务器端，虽然服务器端并行接收了多个请求，也并行处理生成多个响应，但由于要遵守 HTTP/1.1 的规则，先接收到的请求需要先发送响应，造成了阻塞问题。

另外需要注意的是，虽然 HTTP/1.1 规范中规定了 Pipelining 管道技术来并行发送和处理多个请求，但是这个功能在浏览器中默认是关闭的。

看一下 Pipelining 是什么，RFC 2616 中的规定：一个支持持久连接的客户端可以在一个连接中发送多个请求(不需要等待任意请求的响应)。收到请求的服务器必须按照请求收到的顺序发送响应。 至于标准为什么这么设定，我们可以大概推测一个原因：由于 HTTP/1.1 是个文本协议，同时返回的内容也并不能区分对应于哪个发送的请求，所以顺序必须维持一致。比如你向服务器发送了两个请求GET/query?q=A和GET /query?q=B，服务器返回了两个结果，浏览器是没有办法根据响应结果来判断响应是对应于哪一个请求的。

Pipelining 这种设想看起来比较美好，但是在实践中会出现许多问题：

• 一些代理服务器不能正确的处理 HTTP Pipelining。

• 正确的流水线实现是复杂的

• Head-of-line Blocking 连接头阻塞：在建立起一个 TCP 连接之后，假设客户端在这个连接连续向服务器发送了几个请求。按照标准，服务器应该按照收到请求的顺序返回结果，假设服务器在处理首个请求时花费了大量时间，那么后面所有的请求都需要等着首个请求结束才能响应。

所以现代浏览器默认是不开启 HTTP Pipelining 的。

HTTP2 队首阻塞

对于 HTTP1.1 中管道化导致的请求/响应级别的队头阻塞，可以使用 HTTP2 解决。HTTP2 不使用管道化的方式，而是引入了帧、消息和数据流等概念，每个请求/响应被称为消息，每个消息都被拆分成若干个帧进行传输，每个帧都分配一个序号。每个帧在传输是属于一个数据流，而一个连接上可以存在多个流，各个帧在流和连接上独立传输，到达之后在组装成消息，这样就避免了请求/响应阻塞。

当然，即使使用 HTTP2，如果 HTTP2 底层使用的是 TCP 协议，仍可能出现 TCP 队头阻塞。因为 HTTP/2 并没有解决 TCP 的队首阻塞问题，它仅仅是通过多路复用解决了以前 HTTP1.1 管线化请求时的队首阻塞。比如 HTTP/1.1 时代建立一个 TCP 连接，三个请求组成一个队列发出去，服务器接收到这个队列之后会依次响应，一旦前面的请求阻塞，后面的请求就会无法响应。HTTP/2 是通过分帧并且给每个帧打上流的 ID 去避免依次响应的问题，对方接收到帧之后根据 ID 拼接出流，

这样就可以做到乱序响应从而避免请求时的队首阻塞问题。但是 TCP 层面的队首阻塞是 HTTP/2 无法解决的(HTTP 只是应用层协议，TCP 是传输层协议)，TCP 的阻塞问题是因为传输阶段可能会丢包，一旦包就会等待重新发包，阻塞后续传输，这个问题虽然有滑动窗口(Sliding Window)这个方案，但是只能增强抗干扰，并没有彻底解决。

TCP 队首阻塞

队首阻塞(head-of-line blocking)发生在一个 TCP 分节丢失，导致其后续分节不按序到达接收端的时候。该后续分节将被接收端一直保持直到丢失的第一个分节被发送端重传并到达接收端为止。该后续分节的延迟递送确保接收应用进程能够按照发送端的发送顺序接收数据。这种为了达到完全有序而引入的延迟机制非常有用，但也有不利之处。

假设在单个 TCP 连接上发送语义独立的消息，比如说服务器可能发送 3 幅不同的图像供 Web 浏览器显示。为了营造这几幅图像在用户屏幕上并行显示的效果，服务器先发送第一幅图像的一个断片，再发送第二幅图像的一个断片，然后再发送第三幅图像的一个断片；服务器重复这个过程，直到这 3 幅图像全部成功地发送到浏览器为止。要是第一幅图像的某个断片内容的 TCP 分节丢失了，客户端将保持已到达的不按序的所有数据，直到丢失的分节重传成功。这样不仅延缓了第一幅图像数据的递送，也延缓了第二幅和第三幅图像数据的递送。

如何解决 TCP 队头阻塞

TCP 中的队头阻塞的产生是由 TCP 自身的实现机制决定的，无法避免。想要在应用程序当中避免 TCP 队头阻塞带来的影响，只有舍弃 TCP 协议。比如 google 推出的 quic 协议，在某种程度上可以说避免了 TCP 中的队头阻塞，因为它根本不使用 TCP 协议，而是在 UDP 协议的基础上实现了可靠传输。而 UDP 是面向数据报的协议，数据报之间不会有阻塞约束。

此外还有一个 SCTP(流控制传输协议)，它是和 TCP、UDP 在同一层次的传输协议。SCTP 的多流特性也可以尽可能的避免队头阻塞的情况。

总结

从 TCP 队头阻塞和 HTTP 队头阻塞的原因我们可以看到，出现队头阻塞的原因有两个：

• 独立的消息数据都在一个链路上传输，也就是有一个“队列”。比如 TCP 只有一个流，多个 HTTP 请求共用一个 TCP 连接

• 队列上传输的数据有严格的顺序约束。比如 TCP 要求数据严格按照序号顺序，HTTP 管道化要求响应严格按照请求顺序返回

所以要避免队头阻塞，就需要从以上两个方面出发，比如 quic 协议不使用 TCP 协议而是使用 UDP 协议，SCTP 协议支持一个连接上存在多个数据流等等。