阅读笔记 - 合并HTTP请求 vs 并行 HTTP 请求

原创 乘风逐月 随笔 http 153阅读 2018-07-23 11:53:16 举报

原文地址合并HTTP请求 vs 并行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计量,收益可以忽略。如果网络延迟很大,服务器响应速度又慢,则可以带来一定收益,但高延迟的网络场景下,又要注意合并资源后可能带来网络往返次数的增加,进而影响到加载时间。

评论 ( 0 )
最新评论
暂无评论

赶紧努力消灭 0 回复