擁有好奇心，我想知道爲什麼HTTP，通過設計，只能處理每插槽一個待處理的請求。爲什麼HTTP只能處理每個套接字的一個未決請求？
我知道這個限制是因爲沒有'Id'將請求與其響應相關聯，所以將響應與其請求進行匹配的唯一方法是在發送請求的相同套接字上發送響應。如果套接字上存在多個掛起的請求，將無法匹配對其請求的響應，因爲我們可能無法以相同順序接收到請求發送的響應。
如果該協議被設計爲與請求和響應具有匹配的「Id」，則在一個套接字上可能會有多個掛起的請求。這可以大大減少互聯網瀏覽器和使用Web服務的應用程序使用的套接字數量。
當時HTTP這樣設計爲簡單起見，即使是低效率的還是我失去了一些東西，這是最好的方法？
謝謝。
它基本上是爲了簡單;多年來，在相同連接（例如SPDY）上進行多路複用的各種提案已經被提出，但是還沒有提出。
事實並非如此。閱讀關於HTTP1.1流水線。 Apache實現它並且Firefox實現它。雖然Firefox默認禁用它。
要在Firefox中打開它，請使用about:config並在過濾器中寫入「流水線」。
看到：http://www.mozilla.org/projects/netlib/http/pipelining-faq.html與一個套接字發送多個請求
謝謝我會閱讀有關。 – 2010-01-04 21:51:45
從我剛纔讀到的POST請求不能被流水線化。大多數Web服務請求都是POST。請求和響應的匹配ID是否允許更好的流水線？ – 2010-01-04 21:54:15
鏈接：http：//en.wikipedia.org/wiki/HTTP_pipelining – David 2010-01-04 21:56:19
的一個問題是，它會導致效率低下排隊。
例如，假設你在一家商店，並且有2個收銀員，並且有10個人在等待被檢出。製作產品線的理想方式是擁有一個10人的單一隊列，並且排隊的下一個人在可用時會出現在收銀臺上。但是，如果您一次發送所有請求，您可能會將5個人發送至收銀員A，並將5個人發送至收銀員B.但是，如果您將擁有最大購物車的5個人發送至同一個收銀員，該怎麼辦？這是不好的排隊，如果你在一個套接字上排隊了一堆請求，會發生什麼。
注意：我並不是說你不能很好地使用排隊，但是如果在單個套接字上沒有排隊，它可以很容易地做到這一點。
我同意處理請求在套接字池中排隊的請求更爲複雜。但是，你認爲它不值得複雜嗎？它可能會對可擴展性產生嚴重影響？ – 2010-01-04 23:23:17
是的。 （更多字符） – tster 2010-01-05 03:01:57
也意識到HTTP並不一定要求Content-Length標頭爲數據提供服務。即使每個HTTP響應都是ID'd，您將如何管理沒有內容長度（HTTP/1.0樣式）的流式二進制內容？或者如果客戶端發送Connection: close頭讓客戶端由於未知長度而關閉？
要管理這個，你必須在Multiplex中有HTTP塊（已經存在）（我不認爲任何人實現了這個），併爲許多程序添加一些非平凡的工作。
有幾個concidertaions我會檢討。
首先是涉及到TCP本身的性質。 TCP在「飛行頭部」阻塞問題中只能有一個未完成的（未確認）請求（連接/ TCP級別）。考慮到傳統的延遲時間，與加載時間用戶體驗角度相比，這與瀏覽器今天使用的並行連接方案的結果相比可能是一個問題。鏈路的等待時間越長，這種限制的影響就越大。
還有一個併發問題，有時你真的想要增量/並行地加載多個資源。當天，Mozilla推出的最大功能之一是可以逐漸加載圖像和對象，以便您可以開始查看正在發生的事情並使用資源，而無需等待加載。由於連接數量較少，存在風險，例如在樣式表從樣式表經驗的角度來看可能是災難性的之前，在頁面上加載大圖像。期待某種緩解智能或明確配置以優化訂購請求可能不是現實或理想的解決方案。
有一些提議，比如HTTP over SCTP，它將或多或少地完全糾正您在傳輸級別引發的問題。
+1 SPEEDY，這個鏈接（http://dev.chromium.org/spdy/spdy-whitepaper）很好地回答我的問題，謝謝。 – 2010-01-05 06:42:22