古典的な顔の質問には、かつてありました：ブラウザでURLがプロセスで何が起こったかを表示するページに入力されているから？
私は、学生のほとんどはそれの準備ができて答えることができると信じて、しかし、あなたが依頼し続けた場合：HTMLは、受信したラベルは、写真の数十が含まれている場合、これらの写真は、ダウンロードされたどのようなプロトコル多くの接続が確立方法をどのような方法、どのような順序で、ありますそれは？
この問題を知ってもらうために、私たちは以下の5つの質問を解決する必要があります。
-
切断は、TCP接続の後にHTTPリクエストに完了するかどうかを確立するために、近代的なブラウザとサーバ？どのような状況の下で切断されますか？
-
TCP接続は、複数のHTTPリクエストに対応できますか？
-
HTTPリクエストを送信するTCP接続が（その後、3つの応答を一緒に受信し、そのような3で作られた要求として）それを送信することができますか？
-
なぜ時々ページを更新し、SSL接続を再確立する必要はありませんか？
-
同じブラウザのホストは、数に制限はありませんTCPコネクションを確立しますか？
最初の質問
切断は、TCP接続の後にHTTPリクエストに完了するかどうかを確立するために、近代的なブラウザとサーバ？どのような状況の下で切断されますか？
HTTP / 1.0、HTTPレスポンスを送信した後、サーバーでは、TCPコネクションを切断します。しかし、TCP接続と切断を再確立するには、このすべてのリクエストは、コストが大きすぎます。決まった標準が存在しないもののそのため、一部のサーバー接続：キープアライブは、ヘッダーのサポートでした。これは、HTTP要求の完了後、TCP接続を使用してHTTPリクエストを切断していない、ということを意味します。利点は、再確立TCP接続する必要はありません接続はHTTPリクエストを送信した後の時間を再利用することができるということである、と私たちは、接続を維持した場合、また、SSLのオーバーヘッドを避けるため、私の短い2回の訪問の二つの絵のhttps：/ /www.github.com時間統計：
初めてのアクセス、およびSSL接続の初期化のオーバーヘッド
SSL接続の初期化とオーバーヘッドは同じTCP接続を使用して、離れて行きます
要求接続に記載がない限りTCPコネクションを維持するために非常に多くの利点ので、HTTP / 1.1接続のヘッドは、規格書、およびデフォルトで有効に持続的な接続を置く：永続的な接続がクローズし、ブラウザとサーバーとの間でいくつかの時間のために継続されますTCP接続ではなく、終わりを遮断するための要求。
だから、最初の質問への答えは：デフォルトのTCP接続を確立するために、唯一のリクエストヘッダの宣言接続切断ではありません：クローズ要求が完了した後、接続を閉じます。
2番目の質問
TCP接続は、複数のHTTPリクエストに対応できますか？
最初の質問を知って、実際には、この質問は、我々は、接続を維持する場合、TCP接続は、複数のHTTPリクエストを送信することができ、回答されています。
3番目の質問
HTTPリクエストを送信するTCP接続が（その後、3つの応答を一緒に受信し、そのような3で作られた要求として）それを送信することができますか？
HTTP / 1.1に問題がある、同時に単一のTCP接続があることを意味し、一つだけの要求を処理することができます：2つの要求のライフサイクルは、時間の終わりに、任意の2つのHTTPリクエストをオーバーラップすることはできませんが中に同じTCP接続から起動することはできません。重複。
HTTP / 1.1の仕様は、この問題を解決しようとするパイプラインを定義しますが、一方で、この機能は、ブラウザのデフォルトでオフになっています。
RFC 2616で指定されているものを初めて目をパイプライン化：
持続的接続をサポートするクライアントは、「パイプライン」その要求（すなわち、それぞれの応答を待たずに複数のリクエストを送信）するかもしれません。サーバーが要求を受信したのと同じ順序でこれらの要求への応答を送らなければなりません。顧客のサポート、永続的な接続最後は、（任意の要求に対する応答を待つ必要はありません）接続で複数の要求を送信することができます。サーバは、受信した順序で要求に応答して送信されなければならない要求を受信します。
そのような標準が設定されている理由については、我々は、おそらく一つの理由を推測することができます：HTTP / 1.1プロトコルがテキストで、内容もリクエストを送信するに対応して区別することはできません返すので、順序が同じでなければなりません。たとえば、サーバーへの2つの要求 とサーバが応答結果に基づいて、ブラウザが要求に対応する応答の判別する方法はありません、二つの結果を返します。GET/query?q=AGET/query?q=B
このアイデアをパイプライン化することは良さそうに見えますが、実際には多くの問題が存在します。
-
プロキシサーバーが正しくHTTPパイプラインを処理することはできません。
-
正しいパイプラインの実装は複雑です。
-
ヘッドオブラインコネクタを遮断するブロッキング：TCP接続を確立した後、この接続でサーバに複数のクライアント要求の連続送信を想定し。標準として、サーバーが最初の要求を処理するときに、サーバーが多くの時間を過ごすと仮定して、要求の受信のために結果を返す必要があり、それ以降のすべての要求が最初に応答した要求の終了を待つ必要があります。
だから、現代のブラウザのデフォルトでは、オープンHTTPパイプライン化されていません。
しかし、多重HTTP2多重伝送特性を提供し、HTTP要求を複数のTCP接続を同時に完了させることができます。特定の多重化を達成する方法については別の問題です。私たちは、HTTP2効果の使用を見ることができます。
グリーンは、待ち時間の復帰要求を開始する要求であるダウンロード時間応答が青である、あなたは、並行して行われ、接続中のすべての同じを見ることができます
だから、この質問への答えもされています：ブラウザは、デフォルトではオフになっているので、あなたが、これは実現不可能であることを考えることができるように、HTTP / 1.1パイプライン技術の存在は同時に、これを完了するために複数の要求を送ることができますが。存在によるHTTP2多重特性が、HTTPリクエストの複数の同一のTCPコネクション上で並列に実行されてもよいです。
だから、HTTP / 1.1の時代には、ブラウザがそのページのロード効率を改善する方法ですか？以下の2点があります。
-
そして、維持、サーバのTCP接続は、複数の要求を処理し、同じ接続シーケンスを確立してきました。
-
そして、サーバは、複数のTCP接続を確立します。
第四質問
なぜ時々ページを更新し、SSL接続を再確立する必要はありませんか？
最初の質問、すでに答えを持っているの議論では、TCP接続が時々いくつかの時間、ブラウザとサーバーのために維持することができます。TCPを再確立する必要はありません、SSLは自然に前に使用されます。
第五質問
同じブラウザのホストは、数に制限はありませんTCPコネクションを確立しますか？
ブラウザがそれを行うにはどのようにWebページのいくつかの写真を取得する際に、何を多重化しなかったときに我々は、HTTP / 1.1の時代にまだあると仮定？確かにちょうど、ユーザーが非常に難しい受け入れたいと、オーダーをダウンロードするためにTCP接続を開くことはできませんが、それぞれの画像は、コンピュータやサーバが立つことができなかったHTTPリクエストを送信するためにTCP接続をオープンするかどうかがある場合は、単語の1000枚の絵は開くことができません。 1000年のTCP接続、およびコンピュータが必ずしも同意NATとは一致しません。
だから、答えは：はい。Chromeは、同じホストに最大6つのTCP接続が可能になります。別のブラウザでは、いくつかの違いがあります。
https://developers.google.com/web/tools/chrome-devtools/network/issues#queued-or-stalled-requestsdevelopers.google.com
ラベルは写真の数十が含まれている場合、HTMLを受信だから、戻って最初の質問に、これらの写真は確立接続数をどのような順序で、どのようなプロトコルは、それをどのような方法を、ダウンロードされていますか？
画像はHTTPS接続とドメイン名と同じである場合は、SSLハンドシェイクの後、ブラウザは、サーバーを議論するので、多重化機能は、この接続での多重化を使用することであれば、HTTP2を使用することはできません。しかし、それはすべて取得するためにTCP接続を使用します。このドメインのリソースにぶら下がっではないかもしれないが、多重化が使用される可能性があることは確かです。
あなたはそれがHTTP2を取らないことが判明した場合？またはHTTPS（現実HTTP2をHTTPSに実装されているので、それが唯一のHTTP / 1.1を使用している）を取ることはありません。すべての接続要求を送信されている場合は、ブラウザが複数のTCP接続を確立すること、接続の最大数は、ブラウザの設定に依存して制限し、ブラウザ接続は、ホスト上の彼の空き時間に新たな要求を送信するために使用されますそれは？できるだけなので、他の要求。