已知http的請求響應是一對一的. 就是一個請求跟着接下來的響應即是與之配對了.ios
而另外一種方式, 能夠依靠順序, 即發送多個http請求, 而後返回對個http響應. 嚴格按照順序將他們對應起來, 稱爲管道化連接.git
可是因爲有不少問題, 支持的都很差. 實際應用應該也是比較少的.github
轉發一篇以下:瀏覽器
原文地址: 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
鏈接的又一性能優化。在相應到達以前,能夠將多條請求放入隊列,當第一條請求發往服務器的時候,第二第三條請求也能夠開始發送了,在高延時網絡條件下,這樣作能夠下降網絡的環回時間,提升性能。服務器
POST
請求。在WWDC 2012 session 706 - Networking Best Practices中,Apple的工程師介紹了管線化的概念,咱們知道了在NSMutableRequest
有個屬性叫作HTTPShouldUsePipelining
,標示是否開啓管線化鏈接,可是奇怪的是,這個值默認是NO
,按說如此強勢的功能爲何要設置爲NO
呢,下面咱們來看看。session
經過上面的介紹咱們會發現,客戶端接收響應的順序必須和發出的請求順序相同,也就是說這依賴於服務器對於相應的排序,那麼問題來了,若是服務器不支持管線化的話,那麼響應就會亂序,形成意想不到的問題,有幾個很出名的bug:app
可是有件事情是很讓我困惑的,我在閱讀SDWebImage
源碼的時候,在SDWebImageDownloader
類中將HTTPShouldUsePipelining
設置爲了YES
,不知道爲何沒有問題,但願有了解的大神能夠給個解答。
除了上述的問題以外,管線化鏈接仍是有性能問題的:
- 這篇文章從安全角度指出了管線化鏈接的問題,而且談到了一些特定狀況下的性能損失。
- 這篇文章測試了幾個主流的瀏覽器,給出了管線化鏈接的性能並非一直都是取勝的。
- WWDC 2015 - Networking with NSURLSession詳細解釋了一種叫作
Head of line blocking
的問題,是管線化鏈接的巨大瓶頸
來解釋下這個概念,翻譯成中文是線頭阻塞
。咱們知道,管線化是把多個HTTP請求放到一個TCP鏈接中一一發送,而在發送過程當中不須要等待服務器對前一個請求的響應,只不過,客戶端仍是要按照發送請求的順序來接收響應,也就是說,若是第一個請求耗費了服務器不少的處理時間,那麼後面的請求都要等待第一個處理完,也就出現了線頭阻塞。
目前,直到HTTP/1.0都沒有好的方法來解決這個問題,將來的HTTP/2.0或者SPDY中的異步操做才能解決這個問題
以上三篇,是關於HTTP鏈接的管理。