熟悉我的小伙伴都知道，我之前肝了本《 都是你需要知道的重点。
所以我们假定在做的各位对 HTTP 有一定的了解和认识。
下面开始我们这篇文章。
搭载 ）报文，服务器对服务器的请求报文做出响应，等到不需要交换报文时，客户端会关闭连接，下面我用图很好的说明了这个过程。
上面这幅图很好的说明了 建立连接的过程。
TCP 建立连接需要经过三次握手，交换三个报文，我相信大家都对这个过程了然于胸了，如果你还不清楚 TCP 建立连接的过程，可以先阅读 cxuan 的这篇文章 TCP 连接管理。
由于 应用程序。
我们通常把一次完整的请求 – 相应过程称之为 HTTP 事务。
所以我后面一般会写为 HTTP 事务，你理解怎么回事就好。
我们接下来的重点要先从 TCP 的性能入手。
事务时延呢？如下图所示
从图中可以看出，主要是有下面这几个因素影响 HTTP 事务的时延
客户端会根据 URL 确定服务器的 IP 和端口号，这里主要是 DNS 把域名转换为 IP 地址的时延，DNS 会发起 DNS 查询，查询服务器的 IP 地址。第二个时延是 TCP 建立连接时会由客户端向服务器发送连接请求报文，并等待服务器回送响应报文的时延。每条新的 TCP 连接建立都会有建立时延。一旦连接建立后，客户端就会向服务器请求数据，这个时延主要是服务器从 TCP 连接中读取请求报文，并对请求进行处理的时延。服务器会向客户端传输响应报文的时延。最后一个时延是 TCP 连接关闭的时延。其中最后一点的优化也是本文想要讨论的一个重点。
连接、获取资源、断开连接，而且每个连接都是串行打开的，如下图所示：
串行的意思就是，这五个连接必须是有先后顺序，不会出现同时有两个以上的连接同时打开的情况。
上面五个资源就需要打开五条连接，资源少还好说，CPU 能够处理，如果页面资源达到上百或者更多的时候呢？每个资源还需要单独再打开一条连接吗？这样显然会急剧增加 CPU 的处理压力，造成大量的时延，显然是没有必要的。
串行还有一个缺点就是，有些浏览器在对象加载完毕之前是无法知道对象的尺寸（size）的，并且浏览器需要对象尺寸信息来将他们放在屏幕中合理的位置上，所以在加载了足够多的对象之前，屏幕是不会显示任何内容的，这就回造成，其实对象一直在加载，但是我们以为浏览器卡住了。
所以，有没有能够优化 HTTP 性能的方式呢？这个问题问得好，当然是有的。
并行连接这是一种最常见的，也是最容易想到的一种连接方式， 事务的请求过程是这样的。
采用并行连接这种方式会克服单条连接的空载时间和带宽限制，因为每个事务都有连接，因此时延能够重叠起来，会提高页面的加载速度。
但是并行连接并不一定快，如果带宽不够的情况下，甚至页面响应速度还不如串行连接，因为在并行连接中，每个连接都会去竞争使用有效的带宽，每个对象都会以较慢的速度加载，有可能连接 1 加载了 95% ，连接 2 占用带宽加载了 80%，连接 3 ，连接 4 。。。。。。 虽然每个对象都在加载，但是页面上却没有任何响应。
而且，打开大量连接会消耗很多内存资源，从而出现性能问题，上面讨论的就五个连接，这个还比较少，复杂的 web 页面有可能会有数十甚至数百个内嵌对象，也就是说，客户端可以打开数百个连接，而且有许多的客户端同时发出申请，这样很容易会成为性能瓶颈。
这样看来，并行连接并不一定"快"，实际上并行连接并没有加快页面的传输速度，并行连接也只是造成了一种假象，这是一切并行的通病。
持久连接Web 客户端通常会打开到同一个站点的连接，而且初始化了对某服务器请求的应用程序很可能会在不久的将来对这台服务器发起更多的请求，比如获取更多的图片。这种特性被称为站点局部性(site locality)。
因此， 事务能够复用这条连接。
在一次 连接被称为持久连接。
非持久连接会在每个事务结束之后关闭，相对的，持久连接会在每个事务结束之后继续保持打开状态。持久连接会在不同事务之间保持打开状态，直到客户端或者服务器决定将其关闭为止。
长连接也是有缺点的，如果单一客户端发起请求数量不是很频繁，但是连接的客户端却有很多的话，服务器早晚会有崩溃的时候。
持久连接一般有两种选型方式，一种是 。
。
，这也是我们上面说的两种选型方式的版本因素。
下面是使用了持久连接之后的 事务连接的对比图
这张图对比了 连接关闭的时间，所以在时间损耗上有所缩减。
在持久性连接中，还有一个非常有意思的地方，就是 Connection 选项，Connection 是一个通用选项，也就是客户端和服务端都具有的一个标头，下面是一个具有持久性连接的客户端和服务端的请求-响应图
从这张图可以看出，持久连接主要使用的就是 Connection 标头，这也就意味着，Connection 就是持久性连接的实现方式。所以下面我们主要讨论一下 Connection 这个大佬。
Connection 标头Connection 标头具有两种作用
和 Upgrade 一起使用进行协议升级管理持久连接和 Upgrade 一起使用进行协议升级
HTTP 提供了一种特殊的机制，这一机制允许将一个已建立的连接升级成新的协议，一般写法如下
GET /index.html
也就是说，客户端发起 Connection:upgrade 就表明这是一个连接升级的请求，如果服务器决定升级这次连接，就会返回一个 101 Switching Protocols 响应状态码，和一个要切换到的协议的头部字段 Upgrade。 如果服务器没有（或者不能）升级这次连接，它会忽略客户端发送的 Upgrade 头部字段，返回一个常规的响应：例如返回 200。
管理持久连接
我们上面说持久连接有两种方式，一种是 。
Connection: Keep-AliveKeep-Alive: timeout=10,max=500在 首部请求将一条连接保持在打开状态。
这里需要注意⚠️一点：Keep-Alive 首部只是将请求保持在活跃状态，发出 Keep-Alive 请求之后，客户端和服务器不一定会同意进行 Keep-Alive 会话。它们可以在任何时刻关闭空闲的 Keep-Alive 连接，并且客户端和服务器可以限制 Keep-Alive 连接所处理事务的数量。
Keep-Alive 这个标头有下面几种选项：
timeout：这个参数估计了服务器希望将连接保持在活跃状态的时间。max ：这个参数是跟在 timeout 参数后面的，它表示的是服务器还能够为多少个事务打开持久连接。Keep-Alive 这个首部是可选的，但是只有在提供 Connection：Keep-Alive 时才能使用它。
Keep-Alive 的使用有一定限制，下面我们就来讨论一下 Keep-Alive 的使用限制问题。
Keep-Alive 使用限制和规则在 和哑代理问题这里我先解释一下什么是代理服务器，然后再说哑代理问题。
什么是代理服务器？
代理服务器就是代替客户端去获取网络信息的一种媒介，通俗一点就是网络信息的中转站。
为什么我们需要代理服务器？
最广泛的一种用处是我们需要使用代理服务器来替我们访问一些我们客户端无法直接访问的网站。除此之外，代理服务器还有很多功能，比如缓存功能，可以降低费用，节省带宽；对信息的实时监控和过滤，代理服务器相对于目标服务器（最终获取信息的服务器）来说，也是一个客户端，它能够获取服务器提供的信息，代理服务器相对于客户端来说，它是一个服务器，由它来决定提供哪些信息给客户端，以此来达到监控和过滤的功能。
哑代理问题出现就出现在代理服务器上，再细致一点就是出现在不能识别 Connection 首部的代理服务器，而且不知道在发出请求之后会删除 Connection 首部的代理服务器。
假设一个 Web 客户端正在通过一个哑代理服务器与 Web 服务器进行对话，如下图所示
来解释一下上面这幅图
首先，Web 客户端向代理发送了一条报文，其中包含了 Connection: Keep-Alive 首部，希望在这次 的哑代理。
那么如何解决这个问题呢？用 Proxy-Connection
Proxy-Connection 解决哑代理网景公司提出了一种使用 Proxy-Connection 标头的办法，首先浏览器会向代理发送 Proxy-Connection 扩展首部，而不是官方支持的 Connection 首部。如果代理服务器是哑代理的话，它会直接将 Proxy-Connection 发送给服务器，而服务器收到 Proxy-Connection 的话，就会忽略这个首部，这样不会带来任何问题。如果是一个聪明的代理服务器，在收到 Proxy-Connection 的时候，就会直接将 Connection 替换掉 Proxy-Connection ，再发送给服务器。
的工作机制更优。
与 协议版本很重要的区别。
使用 persistent connection 也会有一些限制和规则
首先，发送了 Connection: close 请求后，客户端就无法在这条连接上发送更多的请求。这同时也可以说，如果客户端不想发送其他请求，就可以使用 Connection：close 关闭连接。 请求放入管道，这样能够降低网络的环回时间，提升性能。下图是使用串行连接、并行连接、管道化连接的示意图：
使用管道化的连接也有几处限制：
如果 事务的过程中出现。
但是，服务器无法确定在关闭的那一刻，客户端有没有数据要发送，如果出现这种情况，客户端就会在进行数据传输的过程中发生了写入错误。
即使在不出错的情况下，连接也可以在任意时刻关闭。如果在事务传输的过程中出现了连接关闭情况，就需要重新打开连接进行重试。如果是单条连接还好说，如果是管道化连接，就比较糟糕，因为管道化连接会把大量的连接丢在管道中，此时如果服务器关闭，就会造成大量的连接未响应，需要重新调度。
如果一个 ，否则就会造成不确定的后果。
由于 关闭连接的过程。
HTTP 关闭连接一共分为三种情况：完全关闭、半关闭和正常关闭。
应用程序可以关闭 TCP 输入和输出信道中的任何一个，或者将二者同时关闭。调用套接字 close() 方法会讲输入和输出同时关闭，这就被称为完全关闭。还可以调用套接字的 shutdown 方法单独关闭输入或者输出信道，这被称为半关闭。HTTP 规范建议当客户端和服务器突然需要关闭连接的时候，应该正常关闭，但是它没有说如何去做。