HTTP/1.1 持久链接 persistent connection

 

首先：HTTP的长链接和短链接本质上是TCP长链接和短链接。

 

1. 在HTTP1.0中，默认的是短链接，没有正式规定 Connection:Keep-alive 操做；在HTTP1.1中全部链接都是Keep-alive的，也就是默认都是持续链接的（Persistent Connection）。

2. 两种的链接方式的区别以下图所示

3. 从上图能够看出，客户端与服务器创建持续链接后，在链接期间能够处理多个请求/响应（Request/Response）

 

HTTP权威指南：

HTTP/1.1 容许HTTP设备在事务处理结束之后将TCP链接保持在打开状态，后面的HTTP Request/Response 依然能够经过这个TCP链接继续传送。

在事务结束以后仍然保持在打开状态的TCP链接成为持久连接。非持久链接会在每一个事务结束后关闭，持久链接会在不一样事务（Request/Response）之间保持打开状态，知道客户端或服务器决定将其关闭为止。

 

能够提升HTTP链接性能的方法：

并行链接

经过多条链接发起并发的HTTP请求。并行链接能够提升复合页面的传输速度，但其链接也有一些缺点

每一个事务都会打开/关闭一条新的链接，会耗费时间和带宽。因为TCP慢启动特性存在，每条链接的性能都会有所下降。可打开的并行链接数量其实是有限的

持久化链接

Web客户端常常会打开到同一个站点的链接。好比，一个Web页面上的大部份内嵌图片一般来自同一个Web站点，并且至关一部分指向其余对象的超链一般都指向同一个站点。初始化了对某服务器HTTP请求的应用程序极可能会不久的未来对那台服务器发起更多的请求，这种性质称为站点局部性。

 

所以，HTTP/1.1容许HTTP设备在事务处理结束以后将TCP链接保持在打开状态，以便为将来的HTTP请求重用现存的链接。在事务处理结束以后仍然保持在打开状态的TCP链接称之为持久链接。持久链接会在不一样事务之间保持打开状态，直到客户端或服务器决定其关闭为之。重用已对目标服务器打开的空闲持久链接，就能够避开缓慢的链接创建阶段。并且，已经打开的链接还能够避免慢启动的拥塞适应阶段，以便更快速地进行数据传输。因此，持久链接下降了时延和链接创建的开销，将链接保持在已调谐状态，并且减小了打开链接的潜在数量。

持久链接和并行链接配合使用多是最高效的方式。不少Web应用程序都会打开少许的并行链接，其中每一个都是持久链接。持久链接有两种类型

1）HTTP/1.0 + keep-alive 链接

2) HTTP/1.1 + persistent 链接

 

 

HTTP/1.0  keep-alive链接

如今不少客户端和服务器仍然在使用这些早期的keep-live链接。

实现HTTP/1.0 keep-live链接的客户端能够经过包含Connection:Keep-Alive 首部请求将一条链接保持在打开状态。

若是服务器愿意为下一条请求将链接保持在打开状态，就在响应中包含相同的首部，若是响应中没有Connection:Keep-Alive 首部，客户端就认为服务器不支持keep-live，会在发回响应报文后关闭链接。

 

响应中Keep-Alive首部是可选的，但只有在提供Connection：Keep-Alive时才能使用它。

Connection:Keep-Alive

Keep-Alive:max=5,timeout=120

这个例子说明了服务器最多还会为另外5个事务保持链接的打开状态，或者将打开状态保持到链接空闲了2分钟之后。

 

注意：

1 在HTTP/1.0中，keep-alive并非默认使用的。客户端必需发送一个Connection：Keep-Alive 请求首部来激活keep-alive链接。

2 若是服务器愿意为下一条请求将链接保持在打开状态，就在响应中包含相同的首部，若是响应中没有Connection:Keep-Alive 首部，客户端就认为服务器不支持keep-live，会在发回响应报文后关闭链接。

3 只有在无需检测到链接的关闭就能够肯定报文实体主体部分长度的状况下，才能将链接保持在打开状态--也就是说实体的主体部分必需有正确的Content-Length，

有多部件媒体类型（multipart/form-data ?  有boundary）或者用分块传输编码的方式进行了编码。在一条keep-live信道中回送错误的Content-Length是很糟糕的事情，这样的话，事务处理的另外一端就没法精确地检测出一条报文的结束和另外一条报文的开始了。

 

HTTP/1.1  持久链接 Persistent Connection 

HTTP/1.1逐渐中止了对keep-alive链接的支持，用一种名为持久链接的改进型设计取代了它。持久链接的目的与keep-alive链接的目的相同，可是工做机制更优些。HTTP/1.1就吃链接在默认状况下是激活的，除非特别指明，不然HTTP/1.1假定全部的链接都是持久的，要在事务处理结束以后将链接关闭，HTTP/1.1应用程序必须向报文中显示地添加一个Connection：close首部。

HTTP1.1客户端加载在收到响应后，除非响应中包含了Connection：close首部，否则HTTP/1.1链接就仍然维持在打开状态。可是，客户端和服务器仍然能够随时关闭空闲的链接。不发送Connection：close并不意味这服务器承诺永远将链接保持在打开状态。

注意：

1 只有当链接全部的报文都有正确的、自定义报文长度时，也就是说，实体主体部分的长度都和相应的Content-Length一致，或者用分块传输编码方式编码的，链接诶才能持久保持。

2 若是客户端不想在链接上发送其余请求了，就应该在最后一条请求中发送一个Connection：close请求首部

 

 

管道化链接

HTTP/1.1容许在持久链接上可选的使用请求管道。是相对于keep-alive链接的又一性能优化。在响应到达以前，能够将多条请求放入队列，当第一条请求经过网络流向服务器时，第二条和第三条请求也能够开始发送了。在高时延网络条件下，这样作能够下降网络的环回时间，提升性能。

对管道链接的说明：

1）若是HTTP客户端没法确认链接是持久的，就不该该使用管道

2）必须按照与请求相同的顺序回送HTTP响应。

3）HTTP客户端必须作好链接会在任意时刻关闭的准备，还要准备好重发全部未完成管道化的请求。

4）出错的时候，管道链接会阻碍客户端了解服务器执行的是一些列管道化请求中的哪一些。因为没法安全地重试POST这样的非幂请求，因此出错时，就存在某些方法永远不会被执行的风险。