我们需要知道，在 http1.1 的版本中 Chrome 浏览器对于同域名下的并发请求限制在 6 个，并且这样的限制不能修改，而是在源码里写死的。那么问题来了，如果同时发起多个请求，浏览器会如何处理呢？另外，为什么 http1.1 会有这样的情况? http2.0 是不是也有同样的问题呢？

其实，在 http 的不同版本过程中，一直在优化接口的传输可靠性和速度的及时性。 http 是建立在 tcp 之上的协议，我们没有很好的办法优化 tcp，只能想办法优化自己。这里不过多说这个，下面的思考都基于 http1.1 的基础上，http 2.0 有多路复用，不会有 6 个 tcp 链接的情况，是复用一个 tcp 连接。

本文的目录结构如下:

在这里，我们模拟了 17 个接口几乎同时请求的情况，如下图：

上图可以发现，浏览器会几乎同时发起这些请求，全部处于 pending 状态。

但是从上面这张图我们又可以发现，接口真的开始请求响应之后，第六个接口之后的请求会被阻塞。直到前面的请求被完成的时候，才会依次执行后续的接口。前面有很长一段的等待时间。

这似乎是一个非常好的解决大量接口请求，可能导致的 tcp 链接过多或者服务器扛不住的情况。

但是这里也会遇到一个问题: 如果实际的接口响应时间很慢，同时请求大量接口，对于处于后面pending的接口而言，有没有超时的风险呢？

其实肯定是有的，那么我们还有什么可以优化的方法吗？

我的想法是，既然浏览器可以控制接口的阻塞，使其一直等待。那我们也可以控制接口的请求数量，我们在最大限制量内，分批次处理请求，请求结束后，再去请求后续的接口。

我们从下面的几个方案来大概讲解一下，遇见这种情况，前端如何更好的处理。

我们先创建一个含有多请求 url 的数组，和最大并发量的限制变量，作为后面代码的前提条件。

http 的请求限制很简单，做到以下三个点即可：

代码如下:

我们一起看一下结果，如下图：当点击按钮的时候，会同时发起 5 个请求。并不会把所有的接口全部都发出。而这5个限制是由变量控制的，我们可以按情况更改最大并发的量。

那么当请求到后期，我们可以看见下图的加载顺序，在前面的 5 个接口请求中，任意一个接口结束后，就会马上发起下一个请求。在任意的时间段，请求数量都一定小于等于最大并发量：5。

关于上面的代码，我们还可以升级一下代码，使用更简便的 api 来实现。

虽然是http方法的升级版本，但其实和http一样的方法，只是减少了代码量，更干净而已。

这里可以注意，下一次执行不是绑定在 onload 的方法上，而是在有返回值的时候。

接口的最后完成时间会更短，因为不用等待资源下载的时间，如下图所示:

fetch 方法，其实也并不能完全满足目前项目的需求和编码习惯，我们可以尝试更高级的用法 - promise。

这里实现的功能和上面的需求不太一样，这里的需求是：现有大量的接口，使用 pomise 执行这些接口，保证每个时间的最大请求数在 5 个，并在接口全部成功或者失败的时候返回结果。

这个需求有 3 个重点:

在接口全部成功或者失败的时候，告知成功或者失败。

此时，我们肯定会首先想到使用 promise.all，这个api会返回请求数组全部请求成功或者失败的结果。

但是我们如何对请求的数组进行最大并发量的限制呢？

如果最大限制为 5，那么 promise.all 的数组长度只能是 5。

在长度被限制的情况下，我们如果保真所有的接口被一个接一个请求呢？

我们可以使用 Promise.race 监控当前 Promise.all 的接口数组的请求情况，返回第一个请求成功的接口。

具体代码如下:

我们一起来看一下结果：也是非常完美的串行+并行执行的效果。

我们再来看看响应的log输出，注意每一个log的输出顺序，第几个被执行，第几个请求结束，所有请求执行结束。

关于使用promise的控制并发量的方法，网上已经有很多现成的demo和库。这里demo的实现是完全自己的思路去完成的，大家可以多多参考，找一个自己最能理解的方式去实现。

到这里，本文就结束了。最后，给出两个问题让大家来思考一下:

1.浏览器为什么要对接口的请求量做限制？

2.为什么要使用reduce，reduce处理异步的问题有什么优势吗？

如果有想法，可以直接在评论区回复哦。