????????為什么談HTTP1.1 Pipelining呢？主要問題根源還是來源于Beetlex參加了techempower的測試。先看一下以下兩項測試的結果：

以上分別是.net平臺的Json和Plaintext的測試結果，其實Plaintext最高能跑700多萬RPS已經完全超了對網絡IO讀寫損耗的認知，即使10G的光卡也不可能每秒承載1400萬的IO R/W。Beetlex在其他測試結果都非常不錯，但在最基礎的Plaintext得到了最差的結果！為了解決這一問題我看了N次aspcore的框架代碼看有沒有細小的差異引起問題，結果經過N次的嘗試一年后還是無法解決。。。

發現問題

????????最近我翻看了techempower針對20輪的測試說明，其中有一條說是要廢棄Plaintext項，說這一個項并不符合實際應用需求。后來看了一下評論的一項

在這里我才看到了HTTP/1.1的pipelining描述。。。后來查了一下資源才發現techempower好像在2015年單獨為Plaintext測試項引入pipelining模式，主要用于測試框架在帶寬上的吐吞能力，而beetlex在實現HTTP1.1里并沒去實現它！看到這信息后心里瞬間無數的草尼馬飄過。。。，原因這一年針對這一問題的解決方法完全是姿勢不對！

Pipelining模式有什么好？

????????在這里先說一下HTTP/1.1的基礎通訊模式，就是發起一個請求后等待響應后再發起下一個請求；這樣每個請求響應最少占用一個網絡讀和網絡寫的操作。在pipelining模式下的操作則是可以同時發起多個請求，然后等待多請求同時響應，這就意味著多請求響應可以合并到一個網絡讀寫上，這樣的性能提供是巨大的.由于pipelining模式的使用是非常有限，只允許GET和HEAD請求，所以很多語言的HttpClient組件并不支持這種方式。

從上圖可以了解到，非pipelining模式下，三個請求最少占用3次IO讀寫，而使用pipelining后則可以縮減成1次IO讀寫,這樣有多少性能提升可以查看《評估服務基礎性能應該參考那些指標？》。對http1.1的pipelining了解 發現techempower的Plaintext測試之所以有這么高的響應能力并不是為了反映服務器的網絡IO高效，而是通過pipelining模式實現的一個高帶寬吞吐的技巧測試，由于不具備實用性所以才在討論中提議廢棄它。

總結

????????由于沒有了解techempower的細節導致一直踩在這坑上，整整浪費了大量的時間去查看實現問題；由于姿勢不對未能解決問題，但在調整過程中也嘗試各種線程隊列調整和測試收獲還是有的，更重要的一點是BeetleX不再為這一問題而煩惱。

總結

以上是生活随笔為你收集整理的了解一下HTTP1.1 Pipelining技术的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。