浏览器发送的 http 请求是复用一个 tcp 连接么
答案
不一定。
发的不同域名，肯定不复用。
发的同域名。若第一个请求与第二个请求并行发送，不复用。
发的同域名，并且是第一个请求完事了才发第二个请求。则看是否有 connection: keep-alive 请求头，没有则不复用。
发的同域名，第一个请求完了后发第二个请求，有 connection: keep-alive 请求头。则复用同一个 TCP 连接。
补充说明
HTTP 1.1 里大概规范了几项提高性能的手段：
- 持久连接 （keep-alive/persistent connection）
- 并行连接
- 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的图片）的优化手段也变得没有意义了。而且使用服务器推送的资源的方式更加高效，因为客户端还可以缓存起来，甚至可以由不同的页面共享（依旧遵循同源策略）
