浏览器发送的 http 请求是复用一个 tcp 连接么

答案

不一定。

发的不同域名，肯定不复用。

发的同域名。若第一个请求与第二个请求并行发送，不复用。

发的同域名，并且是第一个请求完事了才发第二个请求。则看是否有 connection: keep-alive 请求头，没有则不复用。

发的同域名，第一个请求完了后发第二个请求，有 connection: keep-alive 请求头。则复用同一个 TCP 连接。

补充说明

HTTP 1.1 里大概规范了几项提高性能的手段：

1. 持久连接 （keep-alive/persistent connection）
2. 并行连接
3. Pipelining

持久连接

每一个请求都会重新建立一个 TCP 连接，一旦响应返回，就关闭连接。 而建立一个连接，则需要进行三次握手。HTTP 1.1 出了一个请求头 connection，默认 keep-alive，告诉服务器不关闭 TCP 连接。

并行连接

由于现代网页通常包含了复数个（>=10）资源，而按照默认设定，一个连接中的每一个请求必须等待收到响应后才能发送下一个请求，所以如果复数的资源请求全部在一个连接 one by one 发送给服务器显然会很慢，而为了弥补这一缺陷，浏览器通常会默认开启多个 TCP 连接，然后再根据每个连接的状态在其中依次发送数据请求，而且客户端有权任意关闭超发的连接。各个浏览器允许的并行连接数大致是这样的（From SO）：

Firefox 2:  2
Firefox 3+: 6
Opera 9.26: 4
Opera 12:   6
Safari 3:   4
Safari 5:   6
IE 7:       2
IE 8:       6
IE 10:      8
Chrome:     6

由于 TCP 协议本身有慢启动的特征，会随着时间调谐连接的最大速度，因此在现代浏览器中持久连接和并行连接通常是搭配在一起使用的—— 一方面由于持久连接的存在，每个 TCP 连接已经处于调谐后的状态，另一方面持久连接可以避免重新三次握手的开销。

在 Chrome 中，页面初始并行加载一堆静态资源是会最大开 6 个 TCP 连接去并行运作，其后发 Ajax 请求则是复用之前的 TCP 连接。

Pipelining

按照 HTTP 1.1 的描述，还有种可以提升性能的方案是管道化，可以在一个 TCP 连接中并行执行多个请求并返回。

因为这项技术比较复杂，如何能在一个 TCP 中有序的处理所接收到的包，并且不会乱序返回，这在早期没有规范，所以各大浏览器都没有支持此功能，形同鸡肋。

关于 HTTP 2

HTTP 2 为了性能做了不少努力，比如提供了规范以支持连接的多路复用。

如前文所说，在同一个 TCP 连接里面同时发生两个请求响应就不是那么简单。而 HTTP 2 正是提供了这样的规范，可以给数据拆成包，并打上包的顺序标签以供 TCP 能正确认知接收的包的顺序。

所以很多网络优化的知识已经过时

• 因为“所有的 HTTP 2.0 的请求都在一个 TCP 链接上”，“资源合并减少请求”，比如 CSS Sprites ,多个 JS 文件、CSS 文件合并等手段没有效果，或者说没有必要。
• 因为“多路复用”，采用“cdn1.cn,cdn2.cn,cdn3.cn，打开多个 TCP 会话，突破浏览器对同一域名的链接数的限制”的手段是没有必要的。因为因为资源都是并行交错发送，且没有限制，不需要额外的多域名并行下载。
• 因为“服务器推送”，内嵌资源（如base64的图片）的优化手段也变得没有意义了。而且使用服务器推送的资源的方式更加高效，因为客户端还可以缓存起来，甚至可以由不同的页面共享（依旧遵循同源策略）

参考

你猜一个TCP链接上面能发多少个HTTP请求权

HTTP/2.0 简单总结

浏览器向同一域名同时发送两个 HTTP (ajax)请求，究竟是共用了一个 TCP 连接还是两个？