HTTP：HTTP/1.x中的连接管理

￡神魔★判官ぃ 2022-09-03 05:10 225阅读 0赞

连接管理是HTTP中的一个关键主题：打开和保持连接在很大程度上影响着网站和 Web 应用程序的性能。在HTTP/1.x中，有几种模型：短期连接、持久连接和HTTP管道。

HTTP 的传输协议主要依赖于 TCP 来提供从客户端到服务器端之间的连接。在早期，HTTP 使用一个简单的模型来处理这样的连接。这些连接的生命周期是短暂的：每发起一个请求时都会创建一个新的连接，并在收到应答时立即关闭。

这个简单的模型对性能有先天的限制：**打开每个TCP连接都是一个消耗资源的操作。通常客户端和服务器之间必须交换多条消息。当请求需要发送时，网络延迟和带宽会影响性能。现代浏览器往往要发起很多次请求(十几个或者更多)才能拿到所需的完整信息**，这证明了早期的模型效率低下。

有两个新的模型在 HTTP/1.1 诞生了：

*  持久连接模型使连续请求之间的连接保持打开状态，从而减少了打开新连接所需的时间。
 *  HTTP管道模型更进一步，它发送多个连续的请求，甚至不需要等待应答，从而大大减少了网络中的延迟。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70]  
需要注意的是，HTTP中的连接管理应用于两个连续节点之间的连接，即**逐跳**而不是**端到端**。

*  客户机与其第一个代理之间的连接所使用的模型可能与代理和目标服务器（或任何中间代理）之间的模型不同。
 *  定义连接模型所涉及的HTTP头，比如Connection和Keep-Alive，是逐跳中间节点可以更改其值的标头。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 1]  
    一个相关的话题是HTTP连接升级，在这里，一个HTTP/1.1 连接升级为一个不同的协议，比如TLS/1.0，Websocket，甚至明文形式的HTTP/2。具体参见[协议升级机制][Link 1]

# 短期连接 #

HTTP 最早期的模型，也是 HTTP/1.0 的默认模型，是短连接。每一个 HTTP 请求都由它自己独立的连接完成；这意味着发起每一个 HTTP 请求之前都会有一次 TCP 握手，而且是连续不断的。

TCP握手本身是非常耗时的，所以TCP可以保持更多的热连接来适应负载。短连接破坏了TCP具备的能力，新的冷连接降低了其性能。

在 HTTP/1.1 中，只有当`Connection` 被设置为 close 时才会用到这个模型。

> 除非是要兼容一个非常古老的，不支持长连接的系统，没有一个令人信服的理由继续使用这个模型。

# 持久连接 #

短连接有两个比较大的问题：创建新连接耗费的时间尤为明显，另外TCP连接的性能只有在该连接被使用一段时间后(热连接)才能得到改善。为了缓解这些问题， 持久连接 的概念便被设计出来了

一个 持久连接会保持一段时间，重复用于发送一系列请求，节省了新建TCP连接握手的时间，还可以利用TCP的性能增强能力。当然，这个连接也不会一直保留这：连接在空闲一段时间后会被关闭(服务器可以使用 Keep-Alive 协议头来指定一个最小的连接保持时间)。

持久连接的缺点：就算是在空闲状态，它还是会消耗服务器资源，而且在重负载时，还有可能遭受`Dos attacks`攻击。此时，可以使用非长连接，即尽快关闭那些空闲的连接，也能对性能有所提升。

HTTP/1.0 里默认并不使用长连接。把 Connection 设置成 close 以外的其它参数都可以让其保持长连接，通常会设置为 `retry-after`。

在 HTTP/1.1 里，默认就是长连接的，协议头都不用再去声明它(但我们还是会把它加上，万一某个时候因为某种原因要退回到 HTTP/1.0 呢)。

# HTTP管道 #

也就是HTTP流水线。

HTTP 流水线在现代浏览器中并不是默认被启用的：

*  Web 开发者并不能轻易的遇见和判断那些搞怪的代理服务器的各种莫名其妙的行为。
 *  正确的实现流水线是复杂的：传输中的资源大小，多少有效的 RTT 会被用到，还有有效带宽，流水线带来的改善有多大的影响范围。不知道这些的话，重要的消息可能被延迟到不重要的消息后面。这个重要性的概念甚至会演变为影响到页面布局！因此 HTTP 流水线在大多数情况下带来的改善并不明显。
 *  流水线受制于 HOL 问题。

由于这些原因，流水线已经被更好的算法给代替，如 multiplexing，已经用在 HTTP/2。

默认情况下，HTTP请求是按照顺序发出的。下一个请求只有在当前请求收到应答之后才会被发出。由于会受到网络延迟和带宽的限制，在下一个请求被发送到服务器之前，可能需要等待很长时间。

流水线是在同一条长连接上发出连续的请求，而不用等待应答返回。这样可以避免连接延迟。理论上讲，性能还会因为两个 HTTP 请求有可能被打包到一个 TCP 消息包中而得到提升。就算 HTTP 请求不断的继续，尺寸会增加，但设置 TCP 的 MSS(Maximum Segment Size) 选项，仍然足够包含一系列简单的请求。

并不是所有类型的 HTTP 请求都能用到流水线：只有 idempotent 方式，比如 GET、HEAD、PUT 和 DELETE 能够被安全的重试：如果有故障发生时，流水线的内容要能被轻易的重试。

今天，所有遵循 HTTP/1.1 的代理和服务器都应该支持流水线，虽然实际情况中还是有很多限制：一个很重要的原因是，目前没有现代浏览器默认启用这个特性。

# 域名分片 #

> 除非你有紧急而迫切的需求，不要使用这一过时的技术，升级到 HTTP/2 就好了。在 HTTP/2 里，做域名分片就没必要了：HTTP/2 的连接可以很好的处理并发的无优先级的请求。域名分片甚至会影响性能。大多数 HTTP/2 的实现还会使用一种称作连接凝聚的技术去尝试合并被分片的域名。

# 结论 #

改进后的连接管理极大的提升了 HTTP 的性能。不管是 HTTP/1.1 还是 HTTP/1.0，使用长连接 – 直到进入空闲状态 – 都能达到最佳的性能。然而，解决流水线故障需要设计更先进的连接管理模型，HTTP/2 已经在尝试了。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70]: /images/20220829/e7c2d05b4c164271bd3a4adf37ccfeb3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 1]: /images/20220829/47b8286fd2014f549afb466fad5d8cb2.png
[Link 1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Protocol_upgrade_mechanism