HTTP 1.1管道傳輸

Question

我必須在Java中實現HTTP客戶端，並且對於我的需求，似乎最有效的方法是實現HTTP管道（根據RFC2616 ）。

順便說一句，我想管道POST。 （我也不是在談論多路復用。我在談論流水線操作，即在接收任何響應之前通過一個連接的許多請求 - 批量處理HTTP請求）

我找不到明確聲明它支持流水線操作的第三方庫。 但我可以使用例如Apache HTTPCore來構建這樣的客戶端，或者如果必須的話，我自己構建它。

我遇到的問題是它是否是一個好主意。 我沒有找到任何權威的參考資料，HTTP流水線技術不僅僅是理論模型，而是由HTTP服務器正確實現。 此外，所有支持流水線操作的瀏覽器都默認關閉此功能。

所以，我應該嘗試實現這樣的客戶端，否則我將因服務器的實現（或代理）而遇到很多麻煩。 有沒有提供這些指南的參考？

如果不知道什么是效率的替代編程模型？ 單獨的TCP連接？

Answer 1

POST不應該是流水線的

8.1.2.2流水線

支持持久連接的客戶端可以“管道化”其請求（即，在不等待每個響應的情況下發送多個請求）。 服務器必須按照收到請求的順序發送對這些請求的響應。

在連接建立后立即采用持久連接和管道的客戶端應准備好在第一次流水線嘗試失敗時重試其連接。 如果客戶端進行了這樣的重試，它必須在它知道連接是持久的之前才進行管道傳輸。 如果服務器在發送所有相應的響應之前關閉連接，客戶端也必須准備重新發送請求。

客戶端不應該使用非冪等方法或非冪等方法序列來處理請求 （請參閱第9.1.2節）。 否則，過早終止傳輸連接可能導致不確定的結果。 希望發送非冪等請求的客戶端應該等待發送該請求，直到它收到前一個請求的響應狀態。

http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html

Answer 2

我已經實現了一個流水線的HTTP客戶端。 基本概念聽起來很容易，但錯誤處理非常困難。 性能提升是如此微不足道，以至於我們很久以前就放棄了這些概念。

在我看來，它對正常用例沒有意義。 當請求具有邏輯連接時，它只有一些好處。 例如，您有一個3請求事務，您可以批量發送它們。 但通常情況下，如果它們可以流水線化，您可以將它們組合成一個請求。

以下只是我記得的一些障礙，

1. TCP的keepalive不保證持久連接。 如果在連接中有3個管道請求，則服務器會在第一次響應后斷開連接。 您應該重試下兩個請求。

2. 當您有多個連接時，負載平衡也很棘手。 如果沒有空閑連接，您可以使用繁忙連接或創建新連接。

3. 超時也很棘手。 當一個請求超時時，您必須丟棄所有請求，因為它們必須按順序返回。

Answer 3

流水線對http服務器幾乎沒有影響; 他們通常以串行方式處理連接中的請求 - 讀取請求，編寫響應，然后讀取下一個請求......

但客戶很可能通過多路復用來提高吞吐量。 網站通常有多台機器有多個cpus，為什么你想自願將你的請求限制在一行？ 今天它更多的是關於水平可伸縮性（並發請求）。 當然，最好對它進行基准測試。