?HTTP管線化 （HTTP pipelining ）是將多個(gè)HTTP請(qǐng)求（request）整批送出的技術(shù)，而在傳送過程中不需先等待服務(wù)器的回應(yīng)。

請(qǐng)求結(jié)果管線化使得 HTML 網(wǎng)頁載入時(shí)間動(dòng)態(tài)提升，特別是在具體有高延遲的連接環(huán)境下，如衛(wèi)星上網(wǎng)。在寬帶連接中，加速不是那么顯著的，因?yàn)樾枰欧鞫藨?yīng)用 HTTP/1.1 協(xié)議，同時(shí)伺服器端必須按照客戶端的請(qǐng)求順序回復(fù)請(qǐng)求，這樣整個(gè)連接還是先進(jìn)先出的， 隊(duì)頭阻塞（HOL blocking）可能會(huì)發(fā)生，造成延遲。未來的 HTTP/2.0 或者SPDY中的異步操作將會(huì)解決這個(gè)問題。因?yàn)樗赡軐⒍鄠€(gè) HTTP 請(qǐng)求填充在一個(gè)TCP數(shù)據(jù)包內(nèi)，HTTP 管線化需要在網(wǎng)絡(luò)上傳輸較少的 TCP 數(shù)據(jù)包，減少了網(wǎng)絡(luò)負(fù)載。

管線化機(jī)制須透過永久連線（persistent connection）完成，并且只有 GET 和 HEAD 等要求可以進(jìn)行管線化，非冪等的方法，例如POST將不會(huì)被管線化。連續(xù)的 GET 和 HEAD 請(qǐng)求總可以管線化的。一個(gè)連續(xù)的冪等請(qǐng)求，如 GET，HEAD，PUT，DELETE，是否可以被管線化取決于一連串請(qǐng)求是否依賴于其他的。此外，初次建立連線時(shí)也不應(yīng)啟動(dòng)管線機(jī)制，因?yàn)閷?duì)方（伺服器）不一定支援 HTTP/1.1 版本的協(xié)定。

HTTP 管線化同時(shí)依賴于客戶端和服務(wù)器的支持。遵守 HTTP/1.1 的服務(wù)器支持管線化。這并不是意味著服務(wù)器需要提供管線化的回復(fù)，而只是要求在收到管線化的請(qǐng)求時(shí)候不會(huì)失敗。

什么是http管道化

通常，http請(qǐng)求總是順序發(fā)送的，下一個(gè)請(qǐng)求只有在當(dāng)前請(qǐng)求的響應(yīng)被完全接受的時(shí)候才會(huì)被發(fā)送。由于網(wǎng)絡(luò)延遲和帶寬的限制，這樣會(huì)導(dǎo)致在服務(wù)器發(fā)送下一個(gè)響應(yīng)的時(shí)候中間有很大的延遲。

HTTP/1.1允許多個(gè)http請(qǐng)求通過一個(gè)套接字同時(shí)被輸出 ，而不用等待相應(yīng)的響應(yīng)。然后請(qǐng)求者就會(huì)等待各自的響應(yīng)，這些響應(yīng)是按照之前請(qǐng)求的順序依次到達(dá)。（me：所有請(qǐng)求保持一個(gè)FIFO的隊(duì)列，一個(gè)請(qǐng)求發(fā)送完之后，不必等待這個(gè)請(qǐng)求的響應(yīng)被接受到，下一個(gè)請(qǐng)求就可以被再次發(fā)出；同時(shí)，服務(wù)器端返回這些請(qǐng)求的響應(yīng)時(shí)也是按照FIFO的順序）。管道化的表現(xiàn)可以大大提高頁面加載的速度，尤其是在高延遲連接中。

管道化同樣也可以減少tcp/ip的數(shù)據(jù)包。通常MSS的大小是在536-1460字節(jié)，所以將許多個(gè)http請(qǐng)求放在一個(gè)tcp/ip包 里也是有可能的。減少加載一個(gè)網(wǎng)頁所需數(shù)據(jù)包的數(shù)量可以在整體上對(duì)網(wǎng)絡(luò)有益處，因?yàn)閿?shù)據(jù)包越少，路由器和網(wǎng)絡(luò)帶來的負(fù)擔(dān)就越少。

HTTP/1.1需要服務(wù)器也支持管道化。但這并不意味著服務(wù)器需要管道化響應(yīng)，而是當(dāng)客戶端發(fā)出管道化請(qǐng)求時(shí)，服務(wù)器不會(huì)響應(yīng)失敗。This obviously has the potential to introduce a new category of evangelism bugs（不會(huì)翻。。），因?yàn)閮H有現(xiàn)代瀏覽器支持管道化。

什么時(shí)候我們應(yīng)該管道化請(qǐng)求

只有冪等的請(qǐng)求（見注1）才可以被管道化，比如GET和HEAD。POST和PUT不應(yīng)該被管道化。我們同樣也不應(yīng)該在建立新連接的時(shí)候發(fā)出管道化的請(qǐng)求 ，因?yàn)椴荒艽_源服務(wù)或代理是否支持HTTP/1.1。因此，管道化只能利用已存在的keep-alive連接。

多少個(gè)請(qǐng)求應(yīng)該被管道化

如果連接過早的關(guān)閉，管道化許多請(qǐng)求是劃不來的，因?yàn)槲覀儠?huì)花費(fèi)很多時(shí)間用來向網(wǎng)絡(luò)里寫請(qǐng)求，然后還不得不在新連接中重寫一遍。而且，如果較早到達(dá)的請(qǐng)求需要花費(fèi)很長(zhǎng)的時(shí)間完成，一個(gè)過長(zhǎng)的管道實(shí)際上會(huì)讓用戶感知到更長(zhǎng)的延遲。HTTP/1.1標(biāo)準(zhǔn)也沒有提供關(guān)于管道化請(qǐng)求理想數(shù)目的任何指導(dǎo)。實(shí)際上，我們建議每個(gè)服務(wù)器不超過2個(gè)keep-alive連接。顯然，這個(gè)還得依賴于應(yīng)用本身。鑒于上述的原因，瀏覽器可能不需要一個(gè)持續(xù)時(shí)間特別長(zhǎng)的管道。2個(gè)可能是比較合適的值，但是還有待測(cè)試。

如果一個(gè)請(qǐng)求被取消了，會(huì)發(fā)生什么？

如果一請(qǐng)求被取消了，是不是意味著整個(gè)管道都被取消了呢？或者，是不是意味著這個(gè)被取消請(qǐng)求的響應(yīng)應(yīng)該被簡(jiǎn)單的丟棄，以便這個(gè)管道中的其他請(qǐng)求不會(huì)被強(qiáng)制重發(fā)？這個(gè)答案依賴于很多因素，包括，這個(gè)被取消請(qǐng)求的響應(yīng)還有多少?zèng)]有被收到。最原始的辦法可能是簡(jiǎn)單的取消管道，然后重發(fā)所有的請(qǐng)求。僅僅當(dāng)請(qǐng)求是冪等的時(shí)候才可以。這樣原始的方法也可以產(chǎn)生好的影響，因?yàn)檎诠艿乐斜话l(fā)送的請(qǐng)求可能屬于同一個(gè)正在被取消的頁面載入組。

如果連接失敗會(huì)發(fā)生什么？

如果連接失敗了或服務(wù)器在下載一個(gè)管道中的響應(yīng)時(shí)中斷了，瀏覽器必須有能力重新開始發(fā)送被丟失的請(qǐng)求。這種情況可以等同于上面討論的被取消的例子。

注

1. HTTP/方法的冪等性：是指一次和多次請(qǐng)求某一個(gè)資源應(yīng)該具有同樣的副作用。
   冪等性的請(qǐng)求，實(shí)際上就是多次操作都不會(huì)改變結(jié)果的請(qǐng)求，比如GET，我可以多次從同一個(gè)地方獲取資源，但是對(duì)于資源本身來說并不會(huì)發(fā)生什么變化，我GET10次和GET100次，資源都沒有發(fā)生任何變化。而post則不同了，我提交表單10次，和100次，造成的結(jié)果是不同的，至少數(shù)據(jù)庫里新增的數(shù)據(jù)有不同。

解釋

1. 其實(shí)HTTP管道化就是將客戶端的FIFO隊(duì)列移到了服務(wù)端。在客戶端可以依次發(fā)送所有要發(fā)送的請(qǐng)求（當(dāng)然這些請(qǐng)求是在同一個(gè)域下的），一個(gè)請(qǐng)求發(fā)送完之后，不必等待這個(gè)請(qǐng)求的響應(yīng)被接受到，下一個(gè)請(qǐng)求就可以被再次發(fā)出。在服務(wù)器端維持的FIFO隊(duì)列，這個(gè)隊(duì)列是按照資源的重要程度排列的。比如HTML比CSS要先返回，JS,CSS比圖片先返回。
2. 在服務(wù)器端會(huì)有一個(gè)緩沖區(qū)，來存放那些已經(jīng)被處理好了但是還沒輪到被發(fā)送的響應(yīng)。比如服務(wù)器先后收到了A,B兩個(gè)請(qǐng)求，A資源比B資源優(yōu)先級(jí)要高，處理A需要10ms，處理B需要1ms，假設(shè)服務(wù)器可以并行處理請(qǐng)求，那么B的響應(yīng)肯定是最先處理好了的，但是B響應(yīng)不能先發(fā)出去，必須待在緩沖區(qū)里，等待A響應(yīng)處理好了之后，先把A的響應(yīng)發(fā)出去，B的響應(yīng)才能夠被發(fā)出去。因?yàn)榉?wù)端必須要遵循FIFO這個(gè)原則。
3. HTTP管道化不是HTTP2的內(nèi)容，是對(duì)HTTP1.1協(xié)議下，服務(wù)器不能很好處理并行請(qǐng)求的一個(gè)改進(jìn)。
4. 管道化的有序和TCP的有序是本質(zhì)上的不同，管道化的有序，是消息與消息之間的有序。TCP中的有序，組成一個(gè)消息的多個(gè)報(bào)文段之間的有序。打個(gè)不太恰當(dāng)?shù)谋确剑秃帽仁茿同學(xué)吃午餐和B同學(xué)吃午餐哪個(gè)先吃完飯可以去玩電腦一樣，假設(shè)是A同學(xué)先進(jìn)食堂，B同學(xué)再進(jìn)食堂，他倆的吃飯速度相同，那么按照FIFO原則，不論是A同學(xué)是吃了蘋果，梨，米飯，菜，還是B同學(xué)只吃了蘋果和米飯。雖然B同學(xué)是先吃完，他吃的少，但是在管道化中，也還一定是A同學(xué)先去玩電腦，B同學(xué)跟著。而在TCP中，就好像是在形容，這頓飯，A同學(xué)是先吃了蘋果，梨，米飯，菜還是先吃了菜，米飯，梨，這樣的內(nèi)部順序。
5. 管道做了哪些事，我的理解是創(chuàng)造了一個(gè)可以不用等待前一個(gè)請(qǐng)求的響應(yīng)即可發(fā)送下一個(gè)請(qǐng)求的場(chǎng)所。至于注意些什么，除了知道有些設(shè)備不支持，其他的我也沒實(shí)際經(jīng)驗(yàn)

文章出自：??前端餐廳??，如有轉(zhuǎn)載本文請(qǐng)聯(lián)系前端餐廳ReTech今日頭條號(hào)。

github：??https://github.com/zuopf769??