2011-01-19 26 views

答えて

0

HTTP 1.1に準拠したHTTPサーバーは、パイプライン処理をサポートする予定です。パイプライン処理はクライアント側でもサポートされるはずです。
httpserver

によれば、APIは、(HTTP 1.1) 及びRFC 2818(HTTP TLS以上)RFC 2616の部分 実装を提供します。

com.sun.net.httpserver.HttpServerがHTTP1.1を完全にサポートしていないと思われるようです。
HttpURLConnectionはパイプライン処理をサポートしていないため、com.sun.net.httpserver.HttpServerはパイプライン処理をサポートしていないと考えています。
あなたはいくつかのテストをしたと言います。どのようにこれをテストしましたか?

更新:ノートから
は、そのパイプラインがサポートされているようです。
リクエストをパイプラインで送信すると、リクエストの到着に応じて応答が返されます(リクエストが完了するまでに時間がかかりません)。

+0

2つの要求を処理するサーバー(スリープするサーバーとスリープしないサーバー)とパイプライン化されたクライアントを作成してテストしました。 2つの接続を作成すると、(サーバーによって同時に実行される)お互いをブロックすることはありませんが、遅くて同じ接続で高速な要求が発生すると、遅くなるのを待つ速度が速くなります。ドキュメントには、「このAPIで提供されていないHTTP機能は、APIを使用してアプリケーションコードによって実装できます。あなたがこれに最も近づく方法に関するアイデアがあれば、私はそれらを聞いて感謝します。 – Brian

+0

@Brian:私が正しく理解していれば、あなたはパイプライン型のクライアント(あなたの実装ですか?)を使用していて、同じHTTP接続で2つのリクエストを送信しています.1つ遅い、1つのfast.私はここで、クライアントがReq1、Req2をサーバーに送信すると、サーバーはReq1のResponseを送信し、Req2のResponseを送信することが期待されます。私。サーバは、要求が受信されたのと同じ順序で要求への応答を送信しなければならない(MUST)。あなたの説明から、速い要求が遅い後に送られていたので、これはあなたのケースで実際に起こっているようです。 – Cratylus

+0

開始時刻と終了時刻を示す両方の要求にトレースポイントがあります。私がいつも見るのは、「スタートA;エンドA;スタートB;エンドB」です。もちろん、私が見たいのは、「START A; START B; END A; END B」です。これは、2つの異なる接続がAとBを発行していても同じではない場合に発生します。 – Brian

0

HTTPパイプライニングは、実際には簡単なことを意味します。クライアントは、前の応答を読み取らずに接続に次の要求を書き込むことができます。

httpサーバがパイプライン処理をサポートしていないのは本当に難しいです。先を見なければならず、現在の要求を超えて利用可能なバイトが見つかると、中止する必要があります...しかし、それはばかげていて、誰もそれをしません。

これは、サーバーによって要求がどのように処理されるかとはまったく関係がありません。それを並行して行うことは、もちろん難しく、解決しなければならない質問がいくつかあります。

+0

質問は、HttpServerクラスそのものの中でより多くのものでした。登録されたHttpHandlerは2つのパイプラインリクエストに対してシリアルに呼び出されます。リクエストごとにHttpExchangeオブジェクトが与えられます。サーバーが適切な順序で応答するように注意していても、1つの接続に対して2つのHttpExchangesが未処理になることはありません。 – Brian

+0

@Brian HTTP仕様では、内部要求がシリアル処理されていても、サーバーは引き続きパイプライン処理をサポートしています。 – irreputable

関連する問題