为啥要减少http请求

说到前端性能优化，都说要减少http请求，但是我有一个疑问，一个请求拆分成两个并发请求不是应该更快么，经过查资料，去了解一下为啥都说要减少http请求

http请求头的数据量

每次请求除了要传输得资源，都会带上一些额外的信息进行，当请求的资源很小，可能请求头带的数据比实际的数传输据量还大，所以当请求特别多的时候，累计传输的额外信息就很多，总的传输速度就慢了。

http连接的开销

从用户输入1个URL到下载内容到客户端需要经过哪些阶段：

1. 域名解析
2. 开启TCP连接
3. 发送请求
4. 等待(主要包括网络延迟和服务器处理时间)
5. 下载资源
6. 文件解析执行时间

我的疑问就在这里产生： 在http1.1，默认开启长连接keep-alive，而且现代浏览器都有DNS缓存，这两种方案来说有什么区别：

• DNS寻址由于有DNS缓存–无差别；
• 3次握手由于有keep-alive，一条和一百条都只需一次TCP握手–无差别；
• 服务器解析–无差别；

其实不是这样的：

• 即使有DNS缓存，浏览器也需要查找缓存，多个请求就需要查找多次，而且缓存有可能被无故清空，这样多个请求的DNS查询有可能花费更多时间。

• TCP握手时间确实没差别，但时间性能上差别非常大。HTTP1.1协议规定请求只能串行发送，这也是HTTP性能最差和最让人诟病的地方，也就是说一百个请求必须依次逐个发送，这样就平白无故多出了99个网络RTT（网络延迟）。

• head of line blocking（队头阻塞）。设想这样一个场景，一个页面有100个请求，第99个请求时，TCP丢了一个包，TCP自然会重传，在此之前，用户没有得到任何内容。但如果建立了100个TCP连接呢？第99个请求出现丢包，那也只影响了第99个资源的展现，前面接收到的98个资源依然能正常加载，不会导致整个页面无法加载。

• 浏览器的静态的策略是在自己可承受的范围内尽可能地用多的链接来解决，大部分浏览器似乎是6-8个链接，这就导致握手也是6-8次。