HTTPクライアントは、HTTP応答をどのように要求（ネットで）または一般的に関連付けますか？

Question

HTTPエンドポイントは、受信するために特定のクライアントからのリクエストに応答すると想定していますか？

プロキシの背後にあるクラスターによって処理されたリクエストの場合、または1つのリクエストが他のリクエストよりも速く終了するNIOで処理されたリクエストでそれが意味をなさない場合はどうでしょうか。

一意のIDを各HTTP要求に関連付けて応答に関連付ける標準的な方法はありますか？これは、http componenets httpclientやcurlなどのクライアントでどのように処理されますか？

質問は次のケースに帰着します。

サーバーからファイルをダウンロードしていて、リクエストが終了していないとします。クライアントは、同じキープアライブ接続で他のリクエストを完了することができますか？

Answer 1

Codecasterの答えは非常によく表現されているため、書き直しません。

編集に応じて - いいえ。そうではない。単一の永続的なHTTP接続は、一度に1つのリクエストにのみ使用できます。または、非常に混乱します。 HTTPは、どのような形式の要求/応答追跡メカニズムを定義していないため、単に不可能です。

同様のメッセージ形式を使用する他のプロトコルがあることに注意する必要があります（ RFC822）、これはこれを許可します（などのメカニズムを使用して SIPのCSEQヘッダー）、そしてこれをカスタムHTTPアプリに実装することは可能ですが、HTTPはこれを行うための標準メカニズムを定義していないため、どこでも動作すると想定できるものは何もできません。また、2番目のメッセージの応答に問題が発生します。2番目の応答を送信する前に最初の応答が終了するのを待っていますか、それとも2番目の応答を送信している間に最初の応答を一時停止しますか？メッセージが破損しないことを保証する方法でこれをどのように伝えますか？

また、SIPは（通常）UDPを介して動作することに注意してください。これはパケットの順序付けを保証しないため、CSEQシステムの必要性を高めます。

別のトランザクションがまだ進行中にサーバーにリクエストを送信する場合は、サーバーへの新しい接続、したがって新しいTCPストリームを作成する必要があります。

FacebookはCDNを構築している間にこれについていくつかの調査を行い、いつでも2つまたは3つのオープンHTTPストリームを効率的に使用できると結論付けましたが、追加のパケットオーバーヘッドコストのために全体的な転送時間を短縮します。リンクを見つけることができたら、ブログエントリにリンクします...

Answer 2

TCP接続が開かれると、接続はソースと宛先ポートとIPアドレスによって認識されます。したがって、宛先ポート80（HTTPのデフォルト）でwww.google.comに接続する場合、OSが生成する無料のソースポートが必要です。

Webサーバーの返信は、ソースポート（およびIP）に送信されます。これは、NATの仕組みでもあり、どのソースポートがどの内部IPアドレスに属しているかを思い出します（および着信接続の場合はその逆）。

編集については、いいえ、単一のHTTP接続は1つのコマンド（Get/Post/etc）を同時に実行できます。以前に発行されたコマンドからデータを取得している間に別のコマンドを送信すると、結果はクライアントとサーバーの実装ごとに異なる場合があります。たとえば、Apacheは、最初の要求のデータが送信された後、2番目の要求の結果を送信すると思います。