2011-01-19 120 views

回答

0

HTTP服務器符合HTTP 1.1預計支持流水線。請注意,流水線應該也被客戶端支持。
根據httpserver

API提供一個局部 執行RFC 2616的(HTTP 1.1) 和RFC 2818(HTTP超過TLS)。

它似乎意味着com.sun.net.httpserver.HttpServer不完全支持HTTP1.1。
HttpURLConnection不支持流水線操作,所以我傾向於認爲com.sun.net.httpserver.HttpServer不支持流水線操作。
你說你做了一些測試。你是怎麼測試這個的?

更新
從音符似乎流水線支持。
如你所說你發送流水線請求,響應應該根據請求的到達而回來(與完成每個請求所用的時間無關,即有些比其他請求快)。

+0

我通過創建一個處理兩個請求的服務器來測試它,一個睡眠,一個不睡,一個流水線客戶端。創建兩個連接不會彼此阻塞(由服務器併發執行),但在同一個連接上執行一個緩慢的跟隨快速請求會導致快速等待緩慢完成。該文檔還補充道,「API不提供的任何HTTP功能都可以通過使用API​​的應用程序代碼實現。」如果你對如何最好地解決這個問題有任何想法,我會很感激聽到他們。 – Brian 2011-01-19 21:50:21

+0

@Brian:如果我理解正確:您使用的是流水線客戶端(您的實現?),並且您通過相同的HTTP連接發送了2個請求。一個很慢,然後是一個fast.I不知道您的意思,但在如果客戶端將Req1,Req2發送到服務器,那麼服務器需要發送Req1響應,然後響應Req2。即服務器必須按照收到請求的順序發送響應到請求。所以從你的描述來看,這似乎確實發生在你的案例中,因爲快速請求是在緩慢後發送的。 – Cratylus 2011-01-20 07:57:08

0

HTTP流水線意味着一件非常簡單的事情:客戶端可以在未讀取先前響應的情況下將下一個請求寫入連接。

任何http服務器都不支持流水線操作確實很困難。它必須向前看,如果它發現超出當前請求的可用字節,則需要中止......但這很荒謬,而且沒有人這麼做。

這與服務器處理請求的方式無關 - 串行或並行處理。平行進行當然更困難,而且還有一些問題必須解決。