（转载）一个TCP连接可以发送多少个HTTP请求？
声明一：该博客转载了微信公众号——算法与数学之美的文章，原文链接。（日期：10.11）
转载是因为觉得该文章的内容是我想学的，且为了方便自己查看以及避免以后再要查阅时查不到。
但是我又发现，在5月29日就有其他公众号发了这篇文章，链接在此。
最后，我朋友告诉我，他在上学期就看到不少公众号在发这篇文章了。。。。
声明二：该博客部分转载了简书博主Half_Light的文章——从URL输入到页面展现，过程中发生了什么？
一个经典的面试题：URL在浏览器被输入到页面展现的过程中发生了什么？
大概经历了如下过程：
- 在浏览器地址中输入URL并发送请求；
- 域名解析；
- 服务器处理请求；
- 浏览器处理；
- 网页绘制。
在浏览器地址中输入URL：
URL（Uniform Resource Locator），统一资源定位符，用于定位互联网上的资源。
格式一般为：协议类型://<主机名>:<端口>/<路径>/<文件名>
域名解析：
浏览器具体会从以下几个缓存去查找域名对应的IP：
- 浏览器缓存：浏览器会检查DNS缓存中是否有与该域名对应的IP
- 系统缓存：从Hosts文件查找是否有对应域名和IP
- 路由器缓存：路由器也会缓存DNS，从路由器的DNS中查找对应IP
- IPS DNS：比如到8.8.8.8或者114.114.114.114，也就是谷歌或者互联网的应用提供商的DNS缓存服务器中查找IP。
DNS（Domain Name System），域名系统，是因特网上作为域名和IP地址相遇映射的一个分布式数据库，能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的IP数字串。
服务器处理请求：
服务器中的Web server可以解析接收到的HTTP请求，然后返回一个HTTP响应给用户，或者接收请求后反向代理到其他Web服务器进行别的解析操作。
具体接收到的HTTP请求则是在后台进行处理的，后台处理的主流框架是按照MVC：模型-视图-控制器进行搭建的（对于学过Django的朋友，可能看起来会比较乱，我觉得可以这样理解：MVC的视图类似于Django的模板，控制器类似于Django的视图）。
摘录百度百科的一段MVC的介绍：
- 模型：应用程序中用于处理应用程序数据逻辑的部分，通常模型对象负责在数据库中存取数据。
- 视图：应用程序中处理数据显示的部分，通常视图是依据模型数据创建的。
- 控制器：应用程序中处理用户交互的部分，通常控制器负责从视图读取数据，控制用户输入并向模型发送数据。
浏览器处理：
浏览器会接收到服务器处理返回的HTML字符串然后进行解析，HTML页面经历了加载、解析和渲染的过程。
比如浏览器解析到了link标签则会重新发送请求获取css文件；解析到img标签就会发送请求获取图片资源；解析到script标签就会挂起渲染的线程（因为加载、解析、渲染是同步的），不仅要等待文档中scripts标签代表的js文件加载完毕，还要等待解析执行完毕才可恢复HTML文档的渲染线程。
网页绘制：
浏览器根据HTML和CSS计算得到渲染树，最终绘制到屏幕上。也就是浏览器中我们能看到和进行交互的页面。
那如果浏览器收到的HTML包含了几十张图片标签，那么这些图片是以什么方式、什么顺序、建立了多少连接，用什么协议下载的？
要弄清楚上面的问题，我们需要先了解下面五个问题：
- 现代浏览器在与服务器建立了一个TCP连接后是否会在一个HTTP请求完成后断开？什么情况下会断开？
- 一个TCP连接可以对应几个HTTP请求？
- 一个TCP连接中HTTP请求发送可以一起发送吗？（比如一起发送三个请求，再三个响应一起接收）
- 为什么有的时候刷新页面不需要重新建立SSL连接？
- 浏览器对同一Host建立TCP连接的数量有没有限制？
第一个问题：现代浏览器在与服务器建立了一个TCP连接后是否会在一个HTTP请求完成后断开？什么情况下会断开？
在HTTP/1.0中，一个服务器在发送完一个HTTP响应后会断开TCP连接。但这样每次请求都会重新建立和断开TCP连接，代价过大。所以虽然标准中没有设定，但某些服务器还是对Connection:keep-alive的Header进行支持。
这个Header的意思是说完成这个HTTP请求之后，不要断开HTTP请求使用的TCP连接。这样的好处是连接可以被重新使用，之后发送HTTP请求的时候就不需要重新建立TCP连接，以及如果维持连接，那么SSL的开销也可以避免。
既然维持TCP连接的好处这么多，HTTP/1.1就把Connection头写进标准，并且默认开启持久连接，（除非请求中写明Connection:close），那么浏览器和服务器之间是会维持一段时间的TCP连接，不会一个请求结束就断掉。
因此，默认情况下建立TCP连接不会断开，只有在请求报头中声明Connection:close才会在请求完成后关闭连接。
第二个问题：一个TCP连接可以对应几个HTTP请求？
根据第一个问题的答案，若连接维持，则一个TCP连接是一个发送多个HTTP请求的。
第三个问题：一个TCP连接中HTTP请求发送可以一起发送吗？（比如一起发送三个请求，再三个响应一起接收）
HTTP/1.1存在一个问题，单个TCP连接在同一时刻只能处理一个请求，即：两个请求的生命周期不能重叠，任意两个HTTP请求从开始到结束的时间在同一个TCP连接里不能重叠。（必须等待前一个请求得到响应）
虽然HTTP/1.1规范中规定了Pipelining来视图解决这个问题，但是这个功能在浏览器中默认是关闭的。
Pipelining规定：一个支持持久连接的客户端可以在一个连接中发送多个请求（不需要等待任意请求的响应），收到请求的服务器必须按照请求收到的顺序发送响应。（A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received.）
这么规定的原因，只能说可能是由于HTTP/1.1是一个文本协议，同时返回的内容也并不能区分对应于哪个发送的请求，所以顺序必须维持一致。
Pipelining在实践中会出现许多问题，如：
- 一些代理服务器不能正确的处理HTTP Pipelining；
- 正确的流水线实现是复杂的；
- Head-of-Blocking连接头阻塞：在建立起一个TCP连接后假设客户端在这个连接连续向服务器发送了几个请求。按照标准，服务器应该按照收到请求的顺序返回结果，假设服务器在处理首个请求时花费了大量时间，那么后面所有的请求都需要等待首个请求结束才能响应。
所以现代浏览器默认是不开启HTTP Pipelining的。
但是HTTP2提供了Multiplexing多路传输特性，可以在一个TCP连接中同时完成多个HTTP请求（并行处理）。
所以这个问题的答案是：在HTTP/1.1中存在Pipelining技术可以完成多个请求同时发送，但是由于浏览器默认关闭，所以可以认为这是不可行的。在HTTP2中由于Multiplexing的存在，多个HTTP请求可以在同一个TCP连接中并行进行。
那么在HTTP/1.1时代，浏览器如何提高页面加载效率？主要有下面两点：
- 维持和服务器已经建立的TCP连接，在同一连接上按顺序处理多个请求。
- 和服务器建立多个TCP连接。
第四个问题：为什么有的时候刷新页面不需要重新建立SSL连接？
在第一个问题的讨论中已经有了答案，TCP连接有的时候会被浏览器和服务端维持一段时间，由于TCP不用重新建立连接，SSL也自然使用之前已经建立好的连接，因为SSL是建立在可靠传输协议（如TCP）之上的。
第五个问题：浏览器对同一Host建立TCP连接的数量有没有限制？
在HTTP/1.1时代，还没有多路传输，当浏览器拿到一个有几十张图片的网页时，肯定不能只开一个TCP顺序下载，那样用户肯定等得难受。但是如果每个图片都开一个TCP连接发送HTTP请求，那电脑或者服务器都可能受不了。
所以浏览器对同一Host建立TCP连接的数量是有限制的。如Chrome最多允许对同一个Host建立六个TCP连接。不同的浏览器有一些区别。
现在回到一开始的问题：如果浏览器收到的HTML包含了几十张图片标签，那么这些图片是以什么方式、什么顺序、建立了多少连接，用什么协议下载的？
如果图片都是HTTPS连接并且在同一个域名下，那么浏览器在SSL握手之后会和服务器商量能不能用HTTP2，如果能的话就使用Multiplexing功能在这个连接上进行多路传输。不过也未必会所有挂在这个域名的资源都会使用一个TCP连接去获取，但可以确定的是Multiplexing很可能会被用到。
如果用不了HTTP2或者用不了HTTPS（现实中的HTTP2都是在HTTPS上实现的），那就只能使用HTTP/1.1了。这样的话浏览器会在一个HOST上建立多个TCP连接，连接数量的最大限制取决于浏览器设置，这些连接在空闲时被浏览器用来发送新的请求，如果所有连接都在发送请求，其他请求就只能等待了。