思考路径：为什么要实现批量调用？->减少网络中的传输损耗->如何减少？->通过合并HTTP请求->合并HTTP请求如何减少网络丢失？本文将解决这个问题。让我们看一下携带大量信息的单个请求与携带少量信息的多个请求的总体时间影响。客户端发送请求1HTTP1.1可以保持长连接，但是在每个不同的请求之间，客户端都要向服务器发送一个请求头。请求不能并行执行。在一个连接中，如果不合并需要N个连接，那么Combining可以节省(N-1)*RTT的时间，RTT是指网络延迟（在传输介质中传输所花费的时间，即，即消息开始进入网络到开始离开网络的时间）。2、TCP丢包问题是慢启动，拥塞控制窗口TCP包乱序到达。合并后的文件可以让领导者弥补团队中丢失的数据包。但是，当资源分离时，前面的资源还没有加载，后面的资源也没有加载。无法加载，会出现比较严重的队头阻塞问题，丢包率会严重影响Keepalive情况下多个文件的传输速率。3浏览器线程数限制为最多2-6个线程，每个连接上会串行发送多个请求。太多的TCP连接会给服务器带来很大的压力。4DNS缓存问题每个请求都需要查找DNS缓存，多个请求需要多次查找，可能会无故清空缓存。服务器处理请求。每个请求都需要使用一个连接，建立一个线程，分配一部分CPU。对于CPU来说一般来说是一种负担，尤其是在连接建立之后，即使请求被发回，在超时前连接也会保持一段时间。这时候保持连接是对服务器资源的巨大浪费。以上所有对HTTP2.0的描述都是基于HTTP/1.1的一些特点，或者缺点，比如长连接但无法并行处理请求，TCP的慢启动和拥塞控制，以及队头阻塞问题都带来整体性能的许多缺点。所以我们有HTTP2.0来做有针对性的改进。很有意思的东西，看图就知道了：HTTP/1.1网络请求图HTTP/2网络请求图太爽了，HTTP/2多了很多特性，解决了HTTP/1.1的很多问题1全复用解决组长阻塞问题.对于同一个TCP连接，现在可以发送多个请求并接收多个响应！在HTTP/1.1中，如果一个连接中前一个请求发生丢包，那么之后的所有请求都必须等待第一个请求补好包，收到响应后才能继续执行。在HTTP/2中，可以直接并行处理。2HeaderCompression所有的HTTP请求和响应都有header，但是header很可能包含缓存信息，导致它们的大小迅速增加。但是在一次连接中，大部分请求的请求头其实都携带了相似的信息，所以HTTP/2使用了一个索引表来存储第一个请求的请求头，之后后续的类似请求只需要携带这个索引号就可以了.标头压缩将标头大小平均减少30%，从而加快整体网络传输速度。这两点与本文最相关。有了这两点，HTTP/2协议下合并HTTP请求的好处就基本消失了。合并或不合并请求更多取决于业务需求和一些后端配置。总结这是一个权衡。其实最重要的是看你传输的是什么，因为合并HTTP请求本质上是减少了网络延迟，但是如果你在服务器上的处理时间远大于网络延迟时间，那么合并HTTP请求给你的意义不大性能增益。而且大量数据的传输肯定会降低浏览器的缓存命中率，缓存的利用率也会大大降低。但是对于HTTP请求携带的数据量比较少的情况，合并请求带来的性能提升会很明显。
