HTTP持续链接和管道化链接

持续链接

重用已对目标服务器打开的空闲链接,就能够避开缓慢的链接创建阶段。并且,已经打开的链接还能够避免慢启动的拥塞适应阶段,以便更快速地进行数据的传输。浏览器

创建持续链接keep-alive

HTTP/1.0 keep-alive链接的客户端能够经过包含Connection: Keep-Alive首部请求将一条链接保持在打开状态。
HTTP/1.1客户端默认Keep-Alive是打开的安全

keep-alive参数

1. 参数timeout是在Keep-Alive响应首部发送的。它估计了服务器但愿将链接保持在活跃状态的时间。这并非一个承诺值。
2. 参数max是在Keep-Alive响应首部发送的。它估计了服务器还但愿为多少个事务保持此链接的活跃状态。这并非一个承诺值。

Keep-Alive链接的限制和规则

1. 发送了Connection: close请求首部以后,客户端就没法在那条链接上发送更多的请求了。
2. 只有响应报文的主体长度(Content-Length)肯定或者能够肯定响应报文何时能发送完(Transfer-Encoding),这样才能创建持续链接,不然不能
3. 每一个持久链接都只适用于一跳传输。
4. 除非请求有反作用,不然若是请求在完成以前链接关闭了,浏览器会自动从新发送该请求
5. 一个用户客户端对任何服务器或代理最多只能维护两条持久链接,以防服务器过载

管道化链接

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

管道化的限制

  1. 若是HTTP客户端没法确认链接是持久的,就不该该使用管道。
  2. 必须按照与请求相同的顺序回送HTTP响应
  3. HTTP客户端必须作好链接会在任意时刻关闭的准备,还要准备好重发全部未完成的管道化请求。若是客户端打开了一条持久链接,并当即发出了10条请求,服务器可能在只处理了,比方说,5条请求以后关闭链接。剩下的5条请求会失败,客户端必须可以应对这些过早关闭链接的状况,从新发出这些请求。
  4. HTTP客户端不该该用管道化的方式发送会产生反作用的请求(好比POST)。出错的时候,管道化方式会阻碍客户端了解服务器执行的是一系列管道化请求中的哪一些。因为没法安全地重试POST这样的非幂等请求,因此出错时,就存在某些方法永远不会被执行的风险。

注意点和一些名词解释

http持续链接关闭时的一些问题

HTTP应用程序要作好正确处理非预期关闭的准备。若是在客户端执行事务的过程当中,传输链接关闭了,那么,除非事务处理会带来一些反作用,不然客户端就应该从新打开链接,并重试一次。对管道化链接来讲,这种状况更加严重一些。客户端能够将大量请求放入队列中排队,但源端服务器能够关闭链接,这样就会留下大量未处理的请求,须要从新调度。服务器

事务反作用

反作用是很重要的问题。若是在发送出一些请求数据以后,收到返回结果以前,链接关闭了,客户端就没法百分之百地肯定服务器端实际激活了多少事务。有些事务,好比GET一个静态的HTML页面,能够反复执行屡次,也不会有什么变化。而其余一些事务,好比向一个在线书店POST一张订单,就不能重复执行,否则会有下多张订单的危险。网络

事务幂等性

若是一个事务,不论是执行一次仍是不少次,获得的结果都相同,这个事务就是幂等的。实现者们能够认为GET、HEAD、PUT、DELETE、TRACE和OPTIONS方法都共享这一特性。客户端不该该以管道化方式传送非幂等请求(好比POST)。不然,传输链接的过早终止就会形成一些不肯定的后果。性能

相关文章
相关标签/搜索