我々はHTTPを介してリソースを要求する場合、以下のように、私たちは応答を取得したとしますブラウザーはどの応答がどの要求に属しているかをどのように知っていますか?
GET/HTTP/1.1
Host: www.google.co.in
HTTP/1.1 200 OK
Date: Thu, 20 Apr 2017 10:03:16 GMT
...
しかし、ブラウザは一度に多くのリソースを要求したとき、どのようにそれは応答を得た要求を識別することができますか?
我々はHTTPを介してリソースを要求する場合、以下のように、私たちは応答を取得したとしますブラウザーはどの応答がどの要求に属しているかをどのように知っていますか?
GET/HTTP/1.1
Host: www.google.co.in
HTTP/1.1 200 OK
Date: Thu, 20 Apr 2017 10:03:16 GMT
...
しかし、ブラウザは一度に多くのリソースを要求したとき、どのようにそれは応答を得た要求を識別することができますか?
あなたは本当にここにHTTP Pipeliningを求めていると思います。これは、HTTP/1.1で導入された技術で、すべての要求がクライアントによって順番に送信され、同じ順序でサーバによって応答されます。すべての詳細についてはRFC 7230, sec. 6.3.2にあります。
HTTP/1.0には、Keep Aliveとして知られている同等のメソッドがありました(または持っています)。これにより、クライアントは前回の応答があった直後に新しい要求を発行することができます。このアプローチの利点は、クライアントとサーバーが新しい要求/応答サイクルのために別のTCPハンドシェイクを介して交渉する必要がなくなったことです。
重要な点は、両方の方法で応答の順序が1つの接続で発行された要求の順序と一致することです。したがって、レスポンスは、クライアントが受信している順番に発行要求に一意にマッピングできます。最初の応答は最初の要求と一致し、2番目の応答は2番目の要求と一致します。
HTTP/1.1のパイプライン化(KeepAliveに依存します)とHTTP/1.0との違いは、前者の場合、クライアントは応答を受け取る前に複数の要求を発行できますが、HTTP/1.0では、新しい要求を発行する。 – symcbean
@symcbean Nope。 HTTP/1.1のパイプライン処理はKeep Aliveに依存しません。上のリンクを参照してください。 HTTPは、単に接続が閉じられるまで開いたままであることを前提としています。リクエスト/レスポンスの注文にwrt:これは私が書いたものですね。 – DaSourcerer
"Keep Aliveに依存していない" - 私はこれで完全に混乱しています。 1つのリクエストとレスポンスしか許さないチャンネルで複数のリクエストを送信するにはどうすればよいですか? – symcbean
ブラウザが一度に多くのリソースをリクエストすると、どのリクエストがどのレスポンスを受け取ったのかをどのように識別できますか?
ブラウザは、リソースを要求するためにWebサーバーへの1つ以上の接続を開くことができます。これらの接続のそれぞれについてHTTP keep-aliveに関する規則は同じであり、両方のHTTP 1.0および1.1に適用されます:HTTPキープアライブオフになって、要求がクライアントによって送信され、応答がによって送信された場合
サーバは、接続が閉じている:
Connection 1: [Open][Request1][Response1][Close]
HTTPキープアライブである場合には、一つの「永続的」な接続が要求を、後続のために再利用することができます。要求は、まだそう、同じ接続でシリアルに発行されていますHTTP Pipeliningで
Connection 1: [Open][Request1][Response1][Request3][Response3][Close]
Connection 2: [Open][Request2][Response2][Request4][Response4][Close]
を、HTTP 1.1で導入され、それが有効になっている場合(ほとんどのブラウザ上で、それが原因でバギーサーバーで、無効になってデフォルトです)ブラウザーは、応答を待たずにお互いに要求を出すことができますが、応答は要求されたのと同じ順序で返されます。これは、複数の上で同時に発生する可能性が
(永続的な)接続:
Connection 1: [Open][Request1][Request2][Response1][Response2][Close]
Connection 2: [Open][Request3][Request4][Response3][Response4][Close]
両方のアプローチ(キープアライブとパイプライン)まだHTTPのデフォルトの「要求 - 応答」メカニズムを利用:各応答は同じ接続上の要求の順番で到着します。彼らはまた、"head of line blocking" problemを持っています:[Response1]
が遅くて/または大きい場合、それはその接続に続くすべての応答を保持します。
HTTP 2多重化:What is the difference between HTTP/1.1 pipelining and HTTP/2 multiplexing?と入力します。ここで、応答は、単一のTCP接続が混在異なる要求と応答の断片を送信することができ、断片化することができる:
Connection 1: [Open][Rq1][Rq2][Resp1P1][Resp2P1][Rep2P2][Resp1P2][Close]
それを示すために、これは、各フラグメントに識別子を付与しないためにどの要求 - 応答対それは属しているので、受信者はメッセージを再構成することができます。
お返事ありがとうございます。大きな説明 –
上記の説明に加えて、ブラウザは多くの並列接続を開くことができます。通常、最大6台のサーバーを同じサーバーに開くことができます。接続ごとに異なるソケットが使用されます。各ソケットの各要求 - 応答について、相関を判断することは容易である。
リクエストとレスポンスが自動的に一緒に「所属」することを「識別する」必要はありません。 – CBroe
サーバはシリアルに応答し、ブラウザに通知されますか?これは、HTTPに優先順位がないことを意味します。 –
いいえ、リクエストは並行して発生する可能性があります。クライアントは複数の接続を開き、それぞれに1つのHTTP要求を送信し、応答が同じ接続を介して到着するようにします。 http://blog.catchpoint.com/2010/09/17/anatomyhttp/では基本について説明しています。 – CBroe