可能会搞砸你的面试：你知道一个TCP链接上能发起多少个HTTP请求吗？

本文由原做者松若章原创发布，做者主页：zhihu.com/people/hrsonion/posts，感谢原做者的无私分享。

一、引言

一道经典的面试题是：从 URL 在浏览器被被输入到页面展示的过程当中发生了什么？

大多数回答都是说请求响应以后 DOM 怎么被构建，被绘制出来。可是你有没有想过，收到的 HTML 若是包含几十个图片标签，这些图片是以什么方式、什么顺序、创建了多少链接、使用什么协议被下载下来的呢？

要搞懂这个问题，咱们须要先解决下面五个问题：

1）现代浏览器在与服务器创建了一个 TCP 链接后是否会在一个 HTTP 请求完成后断开？什么状况下会断开？

2）一个 TCP 链接能够对应几个 HTTP 请求？

3）一个 TCP 链接中 HTTP 请求发送能够一块儿发送么（好比一块儿发三个请求，再三个响应一块儿接收）？

4）为何有的时候刷新页面不须要从新创建 SSL 链接？

5）浏览器对同一 Host 创建 TCP 链接到数量有没有限制？

好了，带着上面的问题，我来阅读本文内容。

（本文同步发布于：http://www.52im.net/thread-2680-1-1.html）

二、相关文章

• 《网络编程懒人入门(七)：深刻浅出，全面理解HTTP协议》
• 《从HTTP/0.9到HTTP/2：一文读懂HTTP协议的历史演变和设计思路》
• 《脑残式网络编程入门(三)：HTTP协议必知必会的一些知识》
• 《脑残式网络编程入门(四)：快速理解HTTP/2的服务器推送(Server Push)》

三、第一个问题：与服务器创建的链接是否会在一个HTTP请求后断开？什么状况下断开？

如题所示，先来谈谈第一个问题：现代浏览器在与服务器创建了一个 TCP 链接后是否会在一个 HTTP 请求完成后断开？什么状况下会断开？

在 HTTP/1.0 中，一个服务器在发送完一个 HTTP 响应后，会断开 TCP 连接。可是这样每次请求都会从新创建和断开 TCP 链接，代价过大。因此虽然标准中没有设定，某些服务器对 Connection: keep-alive 的 Header 进行了支持。意思是说，完成这个 HTTP 请求以后，不要断开 HTTP 请求使用的 TCP 链接。这样的好处是链接能够被从新使用，以后发送 HTTP 请求的时候不须要从新创建 TCP 链接，以及若是维持链接，那么 SSL 的开销也能够避免。

下面两张图片是我短期内两次访问 https://www.github.com 的时间统计：

 

▲ 头一次访问，有初始化链接和 SSL 开销

 

▲ 初始化链接和 SSL 开销消失了，说明使用的是同一个 TCP 链接

持久链接：既然维持 TCP 链接好处这么多，HTTP/1.1 就把 Connection 头写进标准，而且默认开启持久链接，除非请求中写明 Connection: close，那么浏览器和服务器之间是会维持一段时间的 TCP 链接，不会一个请求结束就断掉。

因此第一个问题的答案是：默认状况下创建 TCP 链接不会断开，只有在请求报头中声明 Connection: close 才会在请求完成后关闭链接。（详细文档请见：https://tools.ietf.org/html/rfc2616#section-8.1）

四、第二个问题：一个 TCP 链接能够对应几个 HTTP 请求？

了解了第一个问题以后，其实这个问题已经有了答案：若是维持链接，一个 TCP 链接是能够发送多个 HTTP 请求的。

五、第三个问题：一个 TCP 链接中 HTTP 请求发送能够一块儿发送么？

再来看看第三个问题：一个 TCP 链接中 HTTP 请求发送能够一块儿发送么（好比一块儿发三个请求，再三个响应一块儿接收）？

HTTP/1.1 存在一个问题：单个 TCP 链接在同一时刻只能处理一个请求。

意思是说：两个请求的生命周期不能重叠，任意两个 HTTP 请求从开始到结束的时间在同一个 TCP 链接里不能重叠。

虽然 HTTP/1.1 规范中规定了 Pipelining 来试图解决这个问题，可是这个功能在浏览器中默认是关闭的。

先来看一下 Pipelining 是什么，RFC 2616 中规定了：

原文：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 是个文本协议，同时返回的内容也并不能区分对应于哪一个发送的请求，因此顺序必须维持一致。好比你向服务器发送了两个请求 GET /query?q=A 和 GET /query?q=B，服务器返回了两个结果，浏览器是没有办法根据响应结果来判断响应对应于哪个请求的。

Pipelining 这种设想看起来比较美好，可是在实践中会出现许多问题：

1）一些代理服务器不能正确的处理 HTTP Pipelining；

2）正确的流水线实现是复杂的。详见《HTTP/1.x 的链接管理》；

3）Head-of-line Blocking 链接头阻塞：在创建起一个 TCP 链接以后，假设客户端在这个链接连续向服务器发送了几个请求。按照标准，服务器应该按照收到请求的顺序返回结果，假设服务器在处理首个请求时花费了大量时间，那么后面全部的请求都须要等着首个请求结束才能响应。

因此现代浏览器默认是不开启 HTTP Pipelining 的。

可是，HTTP2 提供了 Multiplexing 多路传输特性，能够在一个 TCP 链接中同时完成多个 HTTP 请求。至于 Multiplexing 具体怎么实现的就是另外一个问题了。咱们能够看一下使用 HTTP2 的效果。

 

▲ 绿色是发起请求到请求返回的等待时间，蓝色是响应的下载时间，能够看到都是在同一个 Connection，并行完成的

因此这个问题也有了答案：在 HTTP/1.1 存在 Pipelining 技术能够完成这个多个请求同时发送，可是因为浏览器默认关闭，因此能够认为这是不可行的。在 HTTP2 中因为 Multiplexing 特色的存在，多个 HTTP 请求能够在同一个 TCP 链接中并行进行。

那么在 HTTP/1.1 时代，浏览器是如何提升页面加载效率的呢？

主要有下面两点：

1）维持和服务器已经创建的 TCP 链接，在同一链接上顺序处理多个请求；

2）和服务器创建多个 TCP 链接。

六、第四个问题：为何有的时候刷新页面不须要从新创建 SSL 链接？

在第一个问题的讨论中已经有答案了：TCP 链接有的时候会被浏览器和服务端维持一段时间。TCP 不须要从新创建，SSL 天然也会用以前的。

七、第五个问题：浏览器对同一 Host 创建 TCP 链接到数量有没有限制？

假设咱们还处在 HTTP/1.1 时代，那个时候没有多路传输，当浏览器拿到一个有几十张图片的网页该怎么办呢？

确定不能只开一个 TCP 链接顺序下载，那样用户确定等的很难受，可是若是每一个图片都开一个 TCP 链接发 HTTP 请求，那电脑或者服务器均可能受不了，要是有 1000 张图片的话总不能开 1000 个TCP 链接吧，你的电脑赞成 NAT 也不必定会赞成。

因此答案是：有。Chrome 最多容许对同一个 Host 创建六个 TCP 链接。不一样的浏览器有一些区别，详见：https://developers.google.com/web/tools/chrome-devtools/network/issues#queued-or-stalled-requests。

那么回到最开始的问题：收到的 HTML 若是包含几十个图片标签，这些图片是以什么方式、什么顺序、创建了多少链接、使用什么协议被下载下来的呢？

若是图片都是 HTTPS 链接而且在同一个域名下，那么浏览器在 SSL 握手以后会和服务器商量能不能用 HTTP2，若是能的话就使用 Multiplexing 功能在这个链接上进行多路传输。不过也未必会全部挂在这个域名的资源都会使用一个 TCP 链接去获取，可是能够肯定的是 Multiplexing 极可能会被用到。

若是发现用不了 HTTP2 呢？或者用不了 HTTPS（现实中的 HTTP2 都是在 HTTPS 上实现的，因此也就是只能使用 HTTP/1.1）。那浏览器就会在一个 HOST 上创建多个 TCP 链接，链接数量的最大限制取决于浏览器设置，这些链接会在空闲的时候被浏览器用来发送新的请求，若是全部的链接都正在发送请求呢？那其余的请求就只能等等了。

（原文连接：点此进入）

附录：更多网络编程基础资料

《TCP/IP详解 - 第11章·UDP：用户数据报协议》
《TCP/IP详解 - 第17章·TCP：传输控制协议》
《TCP/IP详解 - 第18章·TCP链接的创建与终止》
《TCP/IP详解 - 第21章·TCP的超时与重传》
《技术往事：改变世界的TCP/IP协议（珍贵多图、手机慎点）》
《通俗易懂-深刻理解TCP协议（上）：理论基础》
《通俗易懂-深刻理解TCP协议（下）：RTT、滑动窗口、拥塞处理》
《理论经典：TCP协议的3次握手与4次挥手过程详解》
《理论联系实际：Wireshark抓包分析TCP 3次握手、4次挥手过程》
《计算机网络通信协议关系图（中文珍藏版）》
《UDP中一个包的大小最大能多大？》
《P2P技术详解(一)：NAT详解——详细原理、P2P简介》
《P2P技术详解(二)：P2P中的NAT穿越(打洞)方案详解》
《P2P技术详解(三)：P2P技术之STUN、TURN、ICE详解》
《通俗易懂：快速理解P2P技术中的NAT穿透原理》
《高性能网络编程(一)：单台服务器并发TCP链接数到底能够有多少》
《高性能网络编程(二)：上一个10年，著名的C10K并发链接问题》
《高性能网络编程(三)：下一个10年，是时候考虑C10M并发问题了》
《高性能网络编程(四)：从C10K到C10M高性能网络应用的理论探索》
《高性能网络编程(五)：一文读懂高性能网络编程中的I/O模型》
《高性能网络编程(六)：一文读懂高性能网络编程中的线程模型》
《鲜为人知的网络编程(一)：浅析TCP协议中的疑难杂症(上篇)》
《鲜为人知的网络编程(二)：浅析TCP协议中的疑难杂症(下篇)》
《鲜为人知的网络编程(三)：关闭TCP链接时为何会TIME_WAIT、CLOSE_WAIT》
《鲜为人知的网络编程(四)：深刻研究分析TCP的异常关闭》
《鲜为人知的网络编程(五)：UDP的链接性和负载均衡》
《鲜为人知的网络编程(六)：深刻地理解UDP协议并用好它》
《鲜为人知的网络编程(七)：如何让不可靠的UDP变的可靠？》
《鲜为人知的网络编程(八)：从数据传输层深度解密HTTP》
《网络编程懒人入门(一)：快速理解网络通讯协议（上篇）》
《网络编程懒人入门(二)：快速理解网络通讯协议（下篇）》
《网络编程懒人入门(三)：快速理解TCP协议一篇就够》
《网络编程懒人入门(四)：快速理解TCP和UDP的差别》
《网络编程懒人入门(五)：快速理解为何说UDP有时比TCP更有优点》
《网络编程懒人入门(六)：史上最通俗的集线器、交换机、路由器功能原理入门》
《网络编程懒人入门(七)：深刻浅出，全面理解HTTP协议》
《网络编程懒人入门(八)：手把手教你写基于TCP的Socket长链接》
《网络编程懒人入门(九)：通俗讲解，有了IP地址，为什么还要用MAC地址？》
《技术扫盲：新一代基于UDP的低延时网络传输层协议——QUIC详解》
《让互联网更快：新一代QUIC协议在腾讯的技术实践分享》
《现代移动端网络短链接的优化手段总结：请求速度、弱网适应、安全保障》
《聊聊iOS中网络编程长链接的那些事》
《移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》
《移动端IM开发者必读(二)：史上最全移动弱网络优化方法总结》
《IPv6技术详解：基本概念、应用现状、技术实践（上篇）》
《IPv6技术详解：基本概念、应用现状、技术实践（下篇）》
《从HTTP/0.9到HTTP/2：一文读懂HTTP协议的历史演变和设计思路》
《脑残式网络编程入门(一)：跟着动画来学TCP三次握手和四次挥手》
《脑残式网络编程入门(二)：咱们在读写Socket时，究竟在读写什么？》
《脑残式网络编程入门(三)：HTTP协议必知必会的一些知识》
《脑残式网络编程入门(四)：快速理解HTTP/2的服务器推送(Server Push)》
《脑残式网络编程入门(五)：天天都在用的Ping命令，它究竟是什么？》
《脑残式网络编程入门(六)：什么是公网IP和内网IP？NAT转换又是什么鬼？》
《以网游服务端的网络接入层设计为例，理解实时通讯的技术挑战》
《迈向高阶：优秀Android程序员必知必会的网络基础》
《全面了解移动端DNS域名劫持等杂症：技术原理、问题根源、解决方案等》
《美图App的移动端DNS优化实践：HTTPS请求耗时减少近半》
《Android程序员必知必会的网络通讯传输层协议——UDP和TCP》
《IM开发者的零基础通讯技术入门(一)：通讯交换技术的百年发展史(上)》
《IM开发者的零基础通讯技术入门(二)：通讯交换技术的百年发展史(下)》
《IM开发者的零基础通讯技术入门(三)：国人通讯方式的百年变迁》
《IM开发者的零基础通讯技术入门(四)：手机的演进，史上最全移动终端发展史》
《IM开发者的零基础通讯技术入门(五)：1G到5G，30年移动通讯技术演进史》
《IM开发者的零基础通讯技术入门(六)：移动终端的接头人——“基站”技术》
《IM开发者的零基础通讯技术入门(七)：移动终端的千里马——“电磁波”》
《IM开发者的零基础通讯技术入门(八)：零基础，史上最强“天线”原理扫盲》
《IM开发者的零基础通讯技术入门(九)：无线通讯网络的中枢——“核心网”》
《IM开发者的零基础通讯技术入门(十)：零基础，史上最强5G技术扫盲》
《IM开发者的零基础通讯技术入门(十一)：为何WiFi信号差？一文即懂！》
《IM开发者的零基础通讯技术入门(十二)：上网卡顿？网络掉线？一文即懂！》
《IM开发者的零基础通讯技术入门(十三)：为何手机信号差？一文即懂！》
《IM开发者的零基础通讯技术入门(十四)：高铁上无线上网有多难？一文即懂！》
《IM开发者的零基础通讯技术入门(十五)：理解定位技术，一篇就够》
《百度APP移动端网络深度优化实践分享(一)：DNS优化篇》
《百度APP移动端网络深度优化实践分享(二)：网络链接优化篇》
《百度APP移动端网络深度优化实践分享(三)：移动端弱网优化篇》
《技术大牛陈硕的分享：由浅入深，网络编程学习经验干货总结》
《可能会搞砸你的面试：你知道一个TCP链接上能发起多少个HTTP请求吗？》
>> 更多同类文章 ……

（本文同步发布于：http://www.52im.net/thread-2680-1-1.html）