http長鏈結處理不當引發的問題

最近專案中遇到了問題，會偶然出現服務端返回不是客戶端請求報文的情況

經過排查後發現，是客戶端的http長鏈結網路庫，在第一次傳送超時的情況下，沒有斷開連線，而是用此長鏈結繼續傳送，

a包傳送但超時未響應，然後傳送b包，這時收到了a包的響應，則就會認為a包的響應為b包的響應內容，這就導致了此後的http請求和響應都不對應的情況。

關於http長鏈結，也是很有學問的

只有上一次的請求的回應資料完全接收後（根據 content-length 頭部），才能進行下一次的請求。也就是說，長連線實際上是乙個阻塞 loop，所以才需要有「連線池」的存在，不斷的建立新的 tcp鏈結，來實現請求的併發

服務端使用「隊首阻塞」的概念，確實解決了請求排隊等待的問題！

由這個問題，也想到了為什麼網路上有那麼多「tcp 粘包」的問題了。

因為http1.0/1.1 協議使用了簡單的純文本來通訊，而不是二進位制，導致了很多人就認為http就是 "tcp + 純文字"，進而想到需要如何解決邊界定位問題，也就是所謂的「粘包」

由此可見，http2.0 才是正常的 iso 七層協議的實現，增加了第六層表示層

如果一開始就接觸http2.0，也就不會有所謂的「粘包」問題了，因為tcp傳送資料時，資料本身就是結構化資料，實現了自我的邊界定位！

http 1.1的長鏈結，除增加連線池技術，服務端多次接收請求fifo技術外，還可以使用報文頭部加rrid技術，來標識請求和對應的關係