1. 现代浏览器在与服务器建立了一个 TCP 连接后是否会在一个 HTTP 请求完成后断开？什么情况下会断开？
在 HTTP/1.0 中，一个服务器在发送完一个 HTTP 响应后，会断开 TCP 链接。
HTTP/1.1 就把 Connection: keep-alive 头写进标准，并且默认开启持久连接，除非请求中写明 Connection: close，那么浏览器和服务器之间是会维持一段时间的 TCP 连接，不会一个请求结束就断掉。
2. 一个 TCP 连接可以对应几个 HTTP 请求？
如果维持连接，一个 TCP 连接是可以发送多个 HTTP 请求的。
3. ****一个 TCP 连接中 HTTP 请求发送可以一起发送么（比如一起发三个请求，再三个响应一起接收）？
HTTP/1.1 存在一个问题，单个 TCP 连接在同一时刻只能处理一个请求，意思是说：两个请求的生命周期不能重叠，任意两个 HTTP 请求从开始到结束的时间在同一个 TCP 连接里不能重叠。
HTTP/1.1 规范中规定了 Pipelining 来试图解决这个问题：一个支持持久连接的客户端可以在一个连接中发送多个请求（不需要等待任意请求的响应）。收到请求的服务器必须按照请求收到的顺序发送响应。由于 HTTP/1.1 是个文本协议，同时返回的内容也并不能区分对应于哪个发送的请求，所以顺序必须维持一致。
但是这个功能在浏览器中默认是关闭的。为什么？
一些代理服务器不能正确的处理 HTTP Pipelining。
正确的流水线实现是复杂的。
Head-of-line Blocking 连接头阻塞：在建立起一个 TCP 连接之后，假设客户端在这个连接连续向服务器发送了几个请求。按照标准，服务器应该按照收到请求的顺序返回结果，假设服务器在处理首个请求时花费了大量时间，那么后面所有的请求都需要等着首个请求结束才能响应。
HTTP2 提供了 Multiplexing 多路传输特性，可以在一个 TCP 连接中同时（并发）完成多个 HTTP 请求。
- 为什么有的时候刷新页面不需要重新建立 SSL 连接？
TCP 连接有的时候会被浏览器和服务端维持一段时间。TCP 不需要重新建立，SSL 自然也会用之前的。
- 浏览器对同一 Host 建立 TCP 连接到数量有没有限制？
假设浏览器需要下载服务器很多图片，如果只用一个connection就会很慢；如果连接数量太多，那么可能（客户端和服务器）系统会难以承受。所以连接数量需要限制，Chrome 最多允许对同一个 Host 建立六个 TCP 连接。不同的浏览器有一些区别。
