SPDY是HTTP比任何複用在不同的保持活動連接

HTTP 1.1支持保持活動連接，連接不會關閉，直到「連接：關閉」被髮送。SPDY是HTTP比任何複用在不同的保持活動連接

那麼，如果瀏覽器，在這種情況下firefox有network.http.pipelining啓用和network.http.pipelining.maxrequests增加不一樣的效果到底是什麼？

我知道，這些設置是禁用的，因爲一些網站，這可能增加負載，但我認爲一個簡單的HTTP頭標誌可以告訴大家是確定的TU使用複用瀏覽器，這個問題是可以解決的更容易。

那豈不是更容易在瀏覽器中更改默認設置比發明一個新的協議，增加了複雜性特別是在HTTP服務器？

來源

2012-04-28 codeassembly

SPDY對請求和響應頭使用有狀態壓縮。 – 2012-04-28 09:15:52

這是否會產生很大的差異（尤其是對於SSL中已有的正常壓縮）？ – Thilo 2012-04-28 09:17:07

http也可以使用gzip進行壓縮，幾乎所有瀏覽器都支持它，並且標頭通常太小無關 – codeassembly 2012-04-28 09:32:25

SPDY有許多超越什麼HTTP管道可以提供的優勢，這在SPDY whitepaper描述：

隨着流水線，服務器仍然具有在時間順序返回響應中的一個他們被要求。如果客戶端請求一個在靜態之前動態生成的資源，則這可能會成爲問題：服務器無法發送任何「簡單」靜態響應，直到生成併發送動態生成的靜態響應。通過SPDY，響應可以在產生時不按順序或平行地返回，從而縮短接收所有資源的總時間。
正如你在你的問題指出，並非所有的服務器都能夠處理流水線：它不只是加載，一些服務器的實際行爲不當，當客戶端請求流水線作業。使用頭來表明可以執行流水線操作已經太遲了，以至於無法獲得最大的好處：您已經在此時接收到第一個響應，因此雖然您可以在將來的連接中使用它，但對於此連接已經太晚了。
SPDY使用的算法是特定於該任務（狀態和與什麼是正常的HTTP頭知識）壓縮頭;雖然是的，SSL已經包含了壓縮，但是用deflate壓縮它們並不是那麼高效。大多數HTTP請求都沒有主體，只有一個簡短的GET行，所以頭幾乎構成了整個請求：任何壓縮都可以得到改進。與他們的標題相比，許多回應也很小。
SPDY允許服務器發回補充答覆沒有客戶詢問他們。例如，服務器可能會在客戶端有機會接收並解析HTML以確定樣式表網址之前，開始將CSS的原始HTML發回。這可以進一步加速頁面加載，因爲在請求顯示頁面所需的其他資源之前，無需客戶端實際解析HTML。它還支持此功能的帶寬較小的版本，它可以「暗示」可能需要的資源，並允許客戶端決定：例如，這允許不關心圖像的客戶端不打擾請求它們，但想要顯示圖像的客戶端仍然可以使用給定的URL請求圖像，而無需等待HTML。
其他東西：請參閱William Chan的答案。

來源

2012-04-28 09:57:03 Torne

是不是服務器推動你在＃4中描述的相同功能？ – 2013-04-16 09:39:31

是的。編輯。 :) – Torne 2013-06-13 10:18:12

數字2不正確，因爲第一個連接需要內容（HTML）才能知道接下來要接收的內容。在解析HTML的過程中，流水線已經生效。 – Lothar 2014-03-29 19:42:16

HTTP流水線易受在HTTP事務級別而SPDY線阻塞（http://en.wikipedia.org/wiki/Head-of-line_blocking）的頭部僅具有阻擋線的頭由於使用了多路複用，因此傳輸級別。
HTTP流水線有可部署性問題。請參閱http://tools.ietf.org/html/draft-nottingham-http-pipeline-01，其中描述了許多不同的解決方法和啓發式方法來緩解此問題。在野外部署的SPDY不存在此問題，因爲它通常使用NPN（http://technotes.googlecode.com/git/nextprotoneg.html）通過SSL（端口443）進行部署來協商SPDY支持。 SSL是關鍵，因爲它可以防止中介干擾。
SPDY具有標題壓縮。請參閱http://dev.chromium.org/spdy/spdy-whitepaper，其中討論了頭壓縮的好處的一些基準測試結果。現在，有必要指出帶寬問題越來越小（請參閱http://www.belshe.com/2010/05/24/more-bandwidth-doesnt-matter-much/），但記住帶寬對移動設備仍然至關重要。檢查出https://developers.google.com/speed/articles/spdy-for-mobile這表明SPDY對手機有多大益處。
SPDY支持服務器推送等功能。請參閱http://dev.chromium.org/spdy/spdy-best-practices瞭解如何使用服務器推送來改善內容的緩存能力，並仍然減少往返。
HTTP流水線具有不明確的故障語義。當服務器關閉連接時，您如何知道哪些請求已被成功處理？這是爲什麼通過流水線連接不允許POST和其他非冪等請求的主要原因。 SPDY提供語義來取消同一連接上的各個流，並且還有一個GOAWAY幀，它指示要成功處理的最後一個流。
對於允許深層流水線而言，HTTP流水線在中介方面很困難。這（除了諸如HoL阻塞之類的許多其他原因之外）意味着您仍然需要利用多個TCP連接來實現最大限度的並行化。使用多個TCP連接意味着無法共享擁塞控制信息，無法共享壓縮上下文（如SPDY與標頭一樣），對於互聯網來說更糟（對於中介和服務器來說成本更高）。