什么是合并HTTP请求和并行 HTTP 请求

什么是合并HTTP请求和并行 HTTP 请求。

一、HTTP请求过程

一个HTTP请求的主要过程是：

DNS解析(T1) -> 建立TCP连接(T2) -> 发送请求(T3) -> 等待服务器返回首字节(T4) -> 接受数据(T5)

查看一个 HTTP 完整请求时间可以在 chrome 控制台 network waterfall 上查看。

注： Queueing 阶段是请求在浏览器队列中的排队时间，不计入 HTTP 请求时间。

二、实验过程分析

1.资源体积大的情况

理想情况，随着资源体积变大，两种加载方式所需时间趋于相同。从理论上解释，因为HTTP的传输通道是基于TCP链接的，而TCP链接具有慢启动的特性，刚开始时并没有充分利用网络带宽，经过慢启动过程后，逐渐占满可利用的带宽。对于大资源，带宽是瓶颈，即使使用更多的TCP连接，也不能带来速度的提升。资源越大，慢启动所占的下载时间的比例就越小，绝大部分时间，带宽都是被充分利用的，总数据量相同，带宽相同，传输时间当然也相同。(拆分资源导致的额外Header在这种情况下完全可以忽略)

2.资源体积小的情况

当资源体积很小的时候，数据的下载时间占用的比例很小，这个时候影响资源加载时间的关键就是DNS解析(T1)、TCP连接建立(T2)、发送请求(T3)和等待服务器返回首字节(TTFB)(T4)。同时建立多个HTTP连接本身就存在额外的资源消耗，每个HTTP的DNS查询时间、TCP连接的建立时间也存在一定的随机性，这就导致并发资源请求时，出现某个HTTP耗时明显增加的可能性变大。这种情况下，并发HTTP请求就会导致更大的时间不均匀性和不确定性，表现结果就往往比使用一个HTTP请求加载合并后的资源慢。
但是小资源文件不一定是合并后加载更快。因为如果文件合并后不能在1次网络往返中传输完成，网络延时又长，那么合并后耗时就不如并发加载了。

三、资源大小影响拆分还是合并

对于大资源，是否合并对于加载时间没有明显影响，但拆分资源可以更好的利用浏览器缓存，不会因为某个资源的更新导致所有缓存资源失效。另外可以利用域名分片技术，将资源拆分部署到不用域名下，既可以分散服务器压力，有可以降低网络抖动带来的影响。
对于小资源，合并资源往往具有更快的加载速度，但在网络状况良好的情况下，因为提升的时间单位以ms计量，收益可以忽略。如果网络延迟很大，服务器响应速度又慢，则可以带来一定收益，但高延迟的网络场景下，又要注意合并资源后可能带来网络往返次数的增加，进而影响到加载时间。