http隊頭阻塞的示例分析

這篇文章給大家分享的是有關http隊頭阻塞的示例分析的內(nèi)容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

http協(xié)議的1.0版本與1.1版本最大的一個區(qū)別就是http1.1增加了長連接功能，那什么是http的長連接呢？

在了解http的長連接之前，我們來看一下http1.0的請求是如何建立連接的，首先我們要清楚的是，http不論哪個版本，都是建立在tcp協(xié)議上的，而tcp的連接需要經(jīng)歷三次握手，tcp的關閉需要四次揮手，而http1.0協(xié)議中每個http請求都需要經(jīng)歷三次握手和四次揮手，頁面中都多少個http請求，就需要建立多少次握手和揮手，流程如圖：

但是在http1.1中新增了長連接功能，這個長連接功能通常被叫做http長連接，筆者認為這個叫法不太準確，應該叫做tcp長連接，為什么這樣說呢，因為在http1.1中，如果頁面中發(fā)起了多個http請求，此時只需要建立一個tcp連接就可以了，多個http請求響應會共用這一個tcp連接通道。

此時http請求中會攜帶一個Http請求頭：Connection:keep-alive,現(xiàn)在大部分的web服務器都默認支持tcp長連接，也就是網(wǎng)頁中的請求不攜帶Connection：keep-alive請求頭，默認就是長連接請求，如果不想支持長連接的話，需要顯示的添加Connection:closed請求頭。

http1.1請求鏈接過程，如下：

通過對比兩張流程圖，我們發(fā)現(xiàn)，tcp保持長連接大大提高了傳輸效率，但是這里還是有一個問題，那就是http的對頭阻塞問題。

在一般情況下，HTTP遵守“請求-響應”的模式，也就是客戶端每次發(fā)送一個請求到服務端，服務端返回響應，這種模式很簡單，但是有一個致命缺陷那就是頁面中有多個請求，每個請求必須等到前一個請求響應之后才能發(fā)送，并且當前請求的響應返回之后，當前請求的下一個請求才能發(fā)送，流程如下圖：

仔細觀察上圖：在tcp鏈接中，http請求必須等待前一個請求響應之后，才能發(fā)送，后面的依次類推，由此可以看出，如果在一個tcp通道中如果某個http請求的響應因為某個原因沒有及時返回，后面的響應會被阻塞，這就是隊頭阻塞。

為了提高速度和效率，在持久連接的基礎上，HTTP1.1進一步地支持在持久連接上使用管道化（pipelining）特性。管道化允許客戶端在已發(fā)送的請求收到服務端的響應之前發(fā)送下一個請求，借此來減少等待時間提高吞吐，如果多個請求能在同一個TCP分節(jié)發(fā)送的話，還能提高網(wǎng)絡利用率，流程如圖：

仔細觀察上圖，我們發(fā)現(xiàn)，同一個tcp連接中可以同時發(fā)送多個http請求，也就是并發(fā)，但是在響應的時候，必須排隊響應，誰先到達的誰先響應，相比不支持管道化的http請求確實提高了效率，但是還是有局限性，加入其中某個響應因為某種原因延遲了幾秒，后面的響應都會被阻塞，如圖：

觀察上圖紅線標識的響應，因為紅線標識的響應被阻塞了，它后面的所有響應都會被阻塞，這就是隊頭阻塞。

并且使用HTTP管道化還有一些限制:

1、管道化要求服務端按照請求發(fā)送的順序返回響應（FIFO），原因很簡單，HTTP請求和響應并沒有序號標識，無法將亂序的響應與請求關聯(lián)起來。

2、當客戶端在支持管道化時需要保持未收到響應的請求，當連接意外中斷時，需要重新發(fā)送這部分請求。如果這個請求只是從服務器獲取數(shù)據(jù)，那么并不會對資源造成任何影響，而如果是一個提交信息的請求如post請求，那么可能會造成資源多次提交從而改變資源，這是不允許的。而不會對服務器資源產(chǎn)生影響的請求有個專業(yè)名詞叫做冪等請求?？蛻舳嗽谑褂霉艿阑臅r候請求方式必須是冪等請求。

我將http不支持管道化與管道化的圖放在一起，大家比較一下：

因為HTTP管道化本身可能會導致隊頭阻塞的問題，以及上面提到的一些限制，現(xiàn)代瀏覽器默認都關閉了管道化，并且大部分服務器也是默認不支持管道化的。

那么如何解決隊頭阻塞呢？

HTTP 協(xié)議建議客戶端使用并發(fā)長連接，注意這個并發(fā)指的是tcp并發(fā)連接接。RFC2616 里明確限制每個客戶端可以建立兩個長連接，這里著重說明一下，客戶端建立長連接的個數(shù)是針對域名發(fā)起的，舉例說明，當我們訪問a.com網(wǎng)站的時候，客戶端與a.com服務器建立的長鏈接就是2個。

但是一般瀏覽器會把并發(fā)鏈接數(shù)增加到6到8個，谷歌瀏覽器是6個，也就是頁面中如果針對同一個域名有多個http請求，谷歌瀏覽器會針對這個域名建立6個tcp長連接，在每個長連接里面再去處理http請求，但是這種方案其實對服務器的挑戰(zhàn)非常大，有些web優(yōu)化方案中還會突破6到8的限制，那就是域名切片，因為長連接是針對的同一個域名，那么如果開發(fā)人員將資源分布在不同的域名上，那么長連接的數(shù)量也是可以被突破的。

假設頁面中有100張圖片，基于這個案例，咱們用圖示將http1.0到http1.1的變遷用三張圖來表示一下：

http1.0時代：100個http請求建立100個tcp連接。

http1.1時代，tcp支持了長連接，每個tcp可以處理多個http請求。

前面說過了，tcp的并發(fā)數(shù)可以通過域名切片來增大，但這樣做會增大服務器的連接數(shù)，當服務器面對海量請求的話，可能會現(xiàn)問題，那么怎么辦呢，這是就需要使用http2協(xié)議了。我們下期再聊。

下面我給大家總結(jié)一下本篇文章的內(nèi)容：

1、首先我們厘清了一個概念，那就是http長連接其實指的是tcp長連接。

2、隊頭阻塞是一種現(xiàn)象，http因為請求-響應模型會有隊頭阻塞的現(xiàn)象出現(xiàn)，隊頭阻塞指的是在同一個tcp鏈接中，如果先發(fā)送的http請求如果沒有響應的話，后面的http請求也不會響應。

3、解決隊頭阻塞的第一個方案就是并發(fā)長連接，瀏覽器默認是6-8個長連接，我們可以用域名分片的技術突破這個數(shù)值。

4、并發(fā)長連接雖然在一定程度上解決了http的隊頭阻塞，但是會對服務器的性能有較高的要求。

感謝各位的閱讀！關于“http隊頭阻塞的示例分析”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！