許多（如果不是所有的）現代瀏覽器都沒有使用流水線HTTP請求。理論上流水線應該通過減少獲取網站所需的往返時間來加速請求。爲什麼在現代瀏覽器中禁用了流水線操作？
根據HTTP標準，所有服務器必須處理流水線請求，所以問題不應該在服務器上缺乏支持。
我看到了一些安全問題，例如，如果客戶端將盡可能多的流水線請求推送到服務器性能密集的URL，忽略任何可能收到的答案，則會發生第7層DoS攻擊。
這將是在服務器上關閉流水線支持（違反標準）的原因，但我找不到任何理由在客戶端上關閉它。
但是，它在Android瀏覽器和Chrome移動設備上默認打開。
爲什麼Chrome，Firefox，IE，Opera和Safari不在他們的桌面（有時是移動版）中使用流水線HTTP請求？他們關閉背後的理由是什麼？
流水線被禁用，原因如下：
更大的問題已經得到坦言線端阻塞及其對性能和穩健性的影響頭。天真的管道只會使性能變差。
爲實現流水線的選項已從鉻去除，已知的有崩潰問題和已知前端的隊列阻塞的問題。當啓用流水線時，還有大量的服務器和中間件表現不佳並且不一致。在解決這些問題之前，建議沒有人使用流水線。目前這樣做需要自定義構建Chromium。
一般：
巴吉代理仍然普遍，這些導致Web開發人員不能預見並且容易診斷陌生和古怪的行爲。
流水線執行起來很複雜：正在傳輸的資源的大小，將要使用的有效RTT以及有效帶寬，都直接影響到流水線提供的改進。如果不知道這些，重要的信息可能會被拖延到不重要的信息後面。重要的概念甚至在頁面佈局中發展！因此，HTTP流水線在大多數情況下只會帶來一些改進。
流水線操作受制於HOL problem。
HTTP/2提供了一種替代：
隨着HTTP/1.x中，瀏覽器限制了能夠利用上述優先數據的能力：該協議不支持複用，並且沒有辦法向服務器傳送請求優先級。相反，它必須依賴於並行連接的使用，這可以實現每個來源最多六個請求的有限並行。因此，請求會在客戶端排隊，直到連接可用，這會增加不必要的網絡延遲。理論上，HTTP Pipelining試圖部分解決這個問題，但實際上它未能獲得採用。 HTTP/2解決了這些低效率問題：請求排隊和線頭阻塞被消除，因爲瀏覽器可以在發現它們的時刻發送所有請求，並且瀏覽器可以通過流依賴性和權重傳送其流優先級優選，使服務器能夠進一步優化響應交付。
代理可以作爲很好：
你可以試一下我做的KDE3加快Konqueror中。我不滿意Konqueror沒有HTTP流水線，所以經過一番搜索之後，我將Polipo作爲本地HTTP/HTTPS/FTP代理安裝，並將Konqueror設置爲使用它（如果我沒有記錯的話，在端口8123上使用本地主機）。除了HTTP流水線，Polipo還提供了改進的緩存，由於它是一個代理，我可以設置每個瀏覽器來使用它，緩存將在瀏覽器之間共享。 （這也意味着禁用每個瀏覽器的獨立緩存是一個好主意。）
參考
現在我想知道爲什麼移動瀏覽器傾向於使流水線啓用！他們使用相同的代理和中間盒，並且應該具有相同的HoL問題（但更糟的是，因爲它使用更高的延遲連接）。 HTTP/2當然是未來的解決方案，但在那之前。 –
是否有任何移動瀏覽器記錄這種區別？我看過但沒有發現任何Opera Mini，它使用自己的代理，沒有一個文檔介紹移動與桌面在流水線或HTTP一致性方面的差異。 –
很好的回答！ FWIW，https://bugzilla.mozilla.org/show_bug.cgi?id=264354#c65簡要介紹了移動與桌面的區別。 –
我投票作爲題外話，因爲它不是試圖解決一個實際問題，關閉了這個問題。它**可能更適合[程序員堆棧交換]（http://programmers.stackexchange.com/help/on-topic）。 – Quentin
[使用HTTP流水線的缺點是什麼？]（http://stackoverflow.com/questions/14810890/what-are-the-disadvantages-of-using-http-pipelining） – Joe
I'米投票。 **我想知道答案！** – ieXcept