隊頭阻塞
tcp隊頭阻塞
短連線：是在http協議的1.0版本使用的，
短連線的操作步驟是：
建立連線——資料傳輸——關閉連線...建立連線——資料傳輸——關閉連線
結論：http協議是無狀態的。
長連線：在http協議的1.1版本
長連線的操作步驟是：
建立連線——資料傳輸…（保持連線）…資料傳輸——關閉連線
長連線優點：
長連線可以省去較多的tcp建立和關閉的操作，減少浪費，節約時間。對於頻繁請求資源的客戶端適合使用長連線。
缺點即解決辦法
在長連線的應用場景下，client端一般不會主動關閉連線，當client與server之間的連線一直不關閉，隨著客戶端連線越來越多，server會保持過多連線而效能下降。
server端採取策略：
1、關閉一些長時間沒有請求發生的連線，這樣可以避免一些惡意連線導致server端服務受損；
2、如果條件允許，可以限制每個客戶端的最大長連線數，這樣可以完全避免惡意的客戶端拖垮整體後端服務。
短連線優點
短連線對於伺服器來說管理較為簡單，存在的連線都是有用的連線，不需要額外的控制手段。
缺點
但如果客戶請求頻繁，將在tcp的建立和關閉操作上浪費較多時間和頻寬。
需要注意的是：
不管是http短連線還是長連線，它們的請求和響應都有有序的，都是等上一次請求響應後，才接著下乙個請求的，那能不能不等第一次請求回來，我就開始發第二次請求呢？這就引出http管道化了
簡單理解就是需要排隊，隊首的事情沒有處理完的時候，後面的人都要等著。
http「隊頭阻塞」與短連線和長連線無關，而是由http基本的「請求-應答」模型所導致的。
因為http規定報文必須是「一發一收」，這就形成了乙個先進先出的「序列」佇列。
佇列裡的請求沒有輕重緩急的優先順序，只有入隊的先後順序，排在最前面的請求被最優先處理。
1、併發長連線
頁面中如果針對同乙個網域名稱有多個http請求，會針對這個網域名稱建立對個tcp長連線，在每個長連線裡面再去處理http請求，但是這種方案其實對伺服器的挑戰非常大。一般只有6~8個長連線。
想要更多怎麼辦？
2、網域名稱切片
因為長連線是針對的同乙個網域名稱，那麼如果開發人員將資源分布在不同的網域名稱上，那麼長連線的數量也是可以被突破的。
3、http2方式
http2廢棄管道化的方式，引入了幀和資料流等概念。
乙個tcp連線包含多個資料流，每個資料流有乙個資料流id，每個資料流有多個資料報，每個資料報文被拆分成若干個幀進行傳輸，每個幀都分配乙個序號，所有幀到達之後再根據幀的序號組裝成訊息，這樣就可以保證伺服器端的響應無序排隊，等待避免了請求/響應阻塞。
舉例： a處理好的-b-a剩下的
在乙個tcp連線裡面，伺服器同時收到了a請求和b請求，於是先回應a請求，結果發現處理過程非常耗時，於是就傳送a請求已經處理好的部分， 接著回應b請求，完成後，再傳送a請求剩下的部分。
http/2可以在http的角度解決隊頭阻塞的問題，但是http/2是基於tcp的，仍然會在tcp層面造成隊頭阻塞。
如果http/2連線雙方的網路中有乙個資料報丟失，或者任何一方的網路出現中斷，整個tcp連線就會暫停，丟失的資料報需要被重新傳輸。因為tcp是乙個按序傳輸的鏈條，因此如果其中乙個點丟失了，鏈路上之後的內容就都需要等待。造成隊頭阻塞
解決辦法：不用tcp，改用udp=》quic
長連線 短連線
長連線在web中的運用 如果沒有客戶端大量的訪問，可以採用html5的serversocket長連線 例如hudson 執行時會實時的返回當前執行的結果 vmstat 監控 b 長連線 資料庫連線 短連線 http連線 b b 一 長連線與短連線 b 長連線 client方與server方先建立連線...
長連線 短連線
http協議的長連線和短連線，實質上是tcp協議的長連線和短連線。http屬於應用層協議，在傳輸層使用tcp協議，在網路層使用ip協議。ip協議主要解決網路路由和定址問題，tcp協議主要解決如何在ip層之上可靠的傳遞資料報。http是乙個無狀態的面向連線的協議，無狀態不代表http不能保持tcp連線...
長連線 短連線
參考鏈結 怎麼理解tcp的面向連線和udp的無連線 不面向連線 長連線的幾種實現方式 關於長連線和短連線的理解及使用場景 連線其實只是雙方都維護了乙個狀態，通過每一次通訊來維護狀態的變更 在 http 1.0 中 在 http 1.1 中則 可以在一次連線中處理多個請求，並且多個請求可以重疊進行，不...