已知http的请求响应是一对一的. 就是一个请求跟着接下来的响应便是与之配对了.
而另一种方式, 可以依靠顺序, 即发送多个http请求, 然后返回对个http响应. 严格按照顺序将他们对应起来, 称为管道化链接.
但是由于有很多问题, 支持的都不好. 实际应用应该也是比较少的.
转发一篇如下:
原文地址: http://www.yanglicalm.com/2017/02/12/%E7%AE%A1%E9%81%93%E5%8C%96%E8%BF%9E%E6%8E%A5/
其实一切都是由管道化连接而起,这是一个比较有意思的连接方式。
HTTP/1.1 允许在持久连接上可选的使用请求管道
。这是相对于keep-alive
连接的又一性能优化。在相应到达之前,可以将多条请求放入队列,当第一条请求发往服务器的时候,第二第三条请求也可以开始发送了,在高延时网络条件下,这样做可以降低网络的环回时间,提高性能。
- 如果客户端无法确认连接是持久的,就不应该使用管道
- 必须按照与请求相同的顺序回送HTTP响应,因为HTTP报文中是没有序列号的,所以如果收到的响应失序了,就没办法将其与请求匹配起来
- HTTP客户端必须做好连接会在任意时刻关闭的准备,还要准备好重发所有未完成的管道化请求
- HTTP客户端不应该用管道化的方式发送回产生副作用的请求,比如
POST
请求。
管线化在iOS中的应用
在WWDC 2012 session 706 - Networking Best Practices中,Apple的工程师介绍了管线化的概念,我们知道了在NSMutableRequest
有个属性叫做HTTPShouldUsePipelining
,标示是否开启管线化连接,但是奇怪的是,这个值默认是NO
,按说如此强势的功能为什么要设置为NO
呢,下面我们来看看。
通过上面的介绍我们会发现,客户端接收响应的顺序必须和发出的请求顺序相同,也就是说这依赖于服务器对于相应的排序,那么问题来了,如果服务器不支持管线化的话,那么响应就会乱序,造成意想不到的问题,有几个很出名的bug:
但是有件事情是很让我困惑的,我在阅读SDWebImage
源码的时候,在SDWebImageDownloader
类中将HTTPShouldUsePipelining
设置为了YES
,不知道为什么没有问题,希望有了解的大神可以给个解答。
除了上述的问题之外,管线化连接还是有性能问题的:
- 这篇文章从安全角度指出了管线化连接的问题,并且谈到了一些特定情况下的性能损失。
- 这篇文章测试了几个主流的浏览器,给出了管线化连接的性能并不是一直都是取胜的。
- WWDC 2015 - Networking with NSURLSession详细解释了一种叫做
Head of line blocking
的问题,是管线化连接的巨大瓶颈
Head of line blocking
来解释下这个概念,翻译成中文是线头阻塞
。我们知道,管线化是把多个HTTP请求放到一个TCP连接中一一发送,而在发送过程中不需要等待服务器对前一个请求的响应,只不过,客户端还是要按照发送请求的顺序来接收响应,也就是说,如果第一个请求耗费了服务器很多的处理时间,那么后面的请求都要等待第一个处理完,也就出现了线头阻塞。
目前,直到HTTP/1.0都没有好的方法来解决这个问题,未来的HTTP/2.0或者SPDY中的异步操作才能解决这个问题
以上三篇,是关于HTTP连接的管理。