HTTP中的连接管理是一个关键性话题，持久的打开连接极大的影响着网站和web应用的性能，在HTTP/1.x中，有这么几种模型：short-lived 连接，persistent 连接和HTTP pipelining。
HTTP 极大的依赖于TCP协议，HTTP 初期只使用short-lived模式处理连接：每次请求创建一个连接，响应结束则关闭连接。
这种简陋的模式在性能上天生就有缺陷：每打开一个TCP连接都是一个耗费资源的操作，网络延迟和带宽限制都会影响性能；而现在的许多web页面获取完整的信息需要发送十几个请求，这证明早期的模型是无效的。
在HTTP/1.1有两种新模型；持久连接（persistent-connection）模式可以保持请求成功了的连接一直处于打开状态，从而减少了建立连接的开销。管道连接（pipelining）模式更进一步，可以连续发送几个请求，这些请求甚至不需要等待服务器的响应，可参考下图：
- image.png
HTTP/2 使用特有的连接管理模式
需要指出的是：http的连接管理是针对两个连续的逐跳（hop-by-hop）节点，非端到端（end-to-end）；客户端和第一代理之间使用的连接模式可能取决于第二或第三代理和目标服务器之间的连接模式。HTTP headers可以定义使用哪种连接模式，比如Connection 和Keep-Alive，它们属于hop-by-hop headers ，同时可以被中间节点改变。
另一个相关的话题是HTTP连接的升级，在HTTP/1.1中使用的是如TLS/1.0、WebSocket、甚至协议进行升级，更多可参考 协议升级机制；
短连接 Short-lived connections
HTTP的最初模型，甚至HTTP/1.0都是短连接模式，每个HTTP请求都是在它自己的连接上完成的，这意味着每个请求都需要三次握手，并且它们都是窜行（非并行）的。三次握手本身就需要耗费时间，但是TCP连接适应了这种负载，并且变得越来越高效和持久。TCP的特性本身不适用于短连接，当建立新的连接来持久传输会降低性能。
在HTTP/1.0中默认使用这种模式（如果没有指定Connection header，或没有设定为close）. 在HTTP/1.1中，只有当Connectionheader设置为close才会启用短连接。
除非处理一个不支持持久连接的旧系统，否则没有可以令人信服的理由使用这个模型。
持久连接 Persistent connections
短连接有两个主要的障碍：花费在建立新连接的时间巨多；只有当TCP连接被用于暖连接时性能才会变得更好。为了解决这两个问题，持久连接诞生了，甚至在HTTP/1.1之前就有这个概念，持戒连接也被称为keep-alive连接。
持久连接可以被重复利用很多次，可以节省重复建立TCP的时间，最大化的优化其性能。但是持久连接并不是说永远都处于打开的状态：服务端可以利用 Keep-Alive 请求头指定一个最小打开时间；
但持久连接也是有缺陷的，甚至当空转的时候，也消耗服务端的资源于负荷，DoS attacks攻击能够利用这个缺陷。在这种情况下，非持久连接就更高效了，一旦连接是空闲的，就立刻关闭。
HTTP/1.0中使用的并非持久连接，将Connection 设置为非 close, 然后使用retry-after, 可以达到持久的目的；在HTTP/1.1中，默认使用持久连接，并且不用请求头指定（but it is often added as a defensive measure against cases requiring a fallback to HTTP/1.0）；
流水线 HTTP pipelining
流水线模式在现在的浏览器中是没有被激活的：
- 小车代理（Buggy proxies）仍然很常见并且导致web开发者不能预见很诊断一些奇奇怪怪的问题。
- 流水线模式要正确应用起来是很复杂的：大量的资源需要传输，RTT要高效实用，还有极速的带宽，这些因素对该模式有直接的影响。不了解这些，恐怕使会得重要的消息被丢失。因此该模式在大多数情况下只带来了微小的改进；
- 该模式是 HOL 难题的主题。
基于以上理由，该模式被HTTP/2中更好的算法和方案所取代。
所以默认情况下，HTTP请求是有序的发送，下一个HTTP请求的发送要基于上一个请求已被响应。由于网络延迟和带宽限制，这将导致请求的重大延迟。
HTTP Pipelining 是在持久连接的基础上可异步的发送请求，这避免了连接的延迟，理论上，如果两个HTTP请求包裹在同一个TCP消息管道中，性能将会得到很大的提升。典型的MSS (Maximum Segment Size)，可以携带若干个简单的HTTP请求，尽管HTTP请求数量的需求在不断的增长。
并非所有类型的HTTP请求都可以使用该模式：只有idempotent方法，如 GET, HEAD, PUT and DELETE方法，可以安全的被处理。
如今，尽管现在大多数浏览器默认不启用该模式，但每一个HTTP/1.1-compliant代理和服务端都支持该模式；
域分片 Domain sharding
注意：除非你有一个非常急迫的需求，不要使用这种技术，不如使用HTTP/2协议。在In HTTP/2中域分片更有效：HTTP/2的连接可以很好的处理并行请求，域分片甚至对性能是有害的。大部分的HTTP / 2的实现使用了一种叫做connection coalescing 的技术使用域分片。
在HTTP/1.x协议中，请求是串行化的，甚至是无序的，其性能很大程度上依赖于带宽；为了解决这个问题，浏览器为每个域名打开几个连接，发送并行的请求。默认情况下一次是2到3个连接，但是现在增加到了6个并行的连接。如果超过这个数字，就会触发服务端对DoS防御保护；
为了提升网站的性能，服务器有可能强制打开更多连接. 比如分离出多个域名， www1.example.com, www2.example.com, www3.example.com，而不是将所有资源都放在一个域名下www.example.com；每个域名解析同一个服务器，然后浏览器为每个域名打开6个连接（在我们的例子中，将连接数提升到了18）。这种技术就叫做域分片。
