ホームページ  >  記事  >  バックエンド開発  >  インタビュアーは、「TCP 接続は HTTP リクエストをいくつ送信できますか?」と尋ねました。

インタビュアーは、「TCP 接続は HTTP リクエストをいくつ送信できますか?」と尋ねました。

藏色散人
藏色散人転載
2023-02-22 12:00:253786ブラウズ

かつて、面接でよくある質問に「ブラウザに URL が入力されてからページが表示されるまでの過程で何が起こっていますか?」というものがありました。

準備をしてきたほとんどの学生は答えられると思いますが、さらに質問すると、「受け取った HTML に数十個の画像タグが含まれている場合、これらの画像はどのような方法で、どのような順序で作成されますか?」 ? ダウンロードされた接続の数と使用されたプロトコルは何ですか?

インタビュアーは、「TCP 接続は HTTP リクエストをいくつ送信できますか?」と尋ねました。

この問題を理解するには、まず次の 5 つの問題を解決する必要があります:

1. 最新のブラウザがサーバーとの TCP 接続を確立した後、 HTTPリクエストが完了すると切断されますか?どのような状況で切断されるのでしょうか?

2. 1 つの TCP 接続はいくつの HTTP リクエストに対応できますか?

3. HTTP リクエストを TCP 接続でまとめて送信できますか (たとえば、3 つのリクエストをまとめて送信し、3 つのレスポンスをまとめて受信します)?

4. ページを更新するときに SSL 接続を再確立する必要がない場合があるのはなぜですか?

5. ブラウザには、同じホストに対して確立できる TCP 接続の数に制限がありますか?

最初の質問

最新のブラウザは、サーバーとの TCP 接続を確立した後、HTTP リクエストが完了すると切断されますか? ?どのような状況で切断されるのでしょうか?

HTTP/1.0 では、サーバーは HTTP 応答を送信した後に TCP 接続を切断します。ただし、リクエストのたびに TCP 接続が再確立され、切断されるため、コストがかかりすぎます。そのため、標準では設定されていませんが、一部のサーバーは Connection: keep-alive ヘッダーをサポートしています。これは、この HTTP リクエストの完了後、HTTP リクエストで使用される TCP 接続を切断しないことを意味します。この利点は、接続を再利用できること、後で HTTP リクエストを送信するときに TCP 接続を再確立する必要がないこと、接続が維持されていれば SSL のオーバーヘッドも回避できることです。短期間に www.github に 2 回アクセスしました。.com の時間統計:

インタビュアーは、「TCP 接続は HTTP リクエストをいくつ送信できますか?」と尋ねました。

最初のアクセスには初期接続と SSL オーバーヘッドが発生します

インタビュアーは、「TCP 接続は HTTP リクエストをいくつ送信できますか?」と尋ねました。

初期化接続と SSL オーバーヘッドがなくなり、同じ TCP 接続が使用されていることを示します

永続的な接続: TCP 接続を維持することには多くの利点があるため、HTTP/1.1 Connection ヘッダーを標準に書き込み、リクエストに書かれていない限り、デフォルトで永続的な接続を有効にします。Connection: close が指定されている場合、ブラウザとサーバー間の TCP 接続は一定期間維持され、時間が経過しても切断されません。リクエストが完了しました。

最初の質問に対する答えは次のとおりです: デフォルトでは、TCP 接続の確立は切断されません。リクエスト ヘッダーで Connection: close を宣言するだけで、リクエストの完了後に接続が閉じられます。

2 番目の質問

TCP 接続はいくつの HTTP リクエストに対応できますか?

最初の質問を理解した後、この質問には実際に答えがあり、接続が維持されている場合、TCP 接続は複数の HTTP リクエストを送信できます。

3 番目の質問

TCP 接続で HTTP リクエストをまとめて送信できますか (たとえば、3 つのリクエストをまとめて送信し、3 つの応答をまとめて受信します)。

HTTP/1.1 問題があります。1 つの TCP 接続で同時に処理できるリクエストは 1 つだけです。つまり、2 つのリクエストのライフ サイクルは重複できません。すべてのリクエストの開始から終了までの時間です。 2 つの HTTP リクエストは、同じ TCP 接続内で重複することはできません。

HTTP/1.1 仕様では、この問題を解決するためにパイプライン処理が指定されていますが、この機能はブラウザーではデフォルトでオフになっています。

まずはパイプラインとは何かを見てみましょう。RFC 2616 では次のように規定されています:

A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received. 一个支持持久连接的客户端可以在一个连接中发送多个请求(不需要等待任意请求的响应)。收到请求的服务器必须按照请求收到的顺序发送响应。

標準がこのように設定されている理由については、大まかに 1 つの理由が推測できます。テキスト プロトコルであると同時に、返されたコンテンツはそれがどのリクエストに対応するかを区別できないため、順序の一貫性を維持する必要があります。たとえば、2 つのリクエスト (GET/query?q=A と GET/query?q=B) をサーバーに送信し、サーバーが 2 つの結果を返した場合、ブラウザは、その応答がどのリクエストに対応するかを判断する方法がありません。応答結果が表示されます。

パイプライン このアイデアは良さそうに見えますが、実際には多くの問題があります。

  • 一部のプロキシ サーバーは HTTP パイプラインを正しく処理できません。

  • #正しいパイプラインの実装は複雑です。

  • Head-of-line Blocking 接続ヘッダーのブロック: TCP 接続を確立した後、この接続中にクライアントが複数のリクエストを連続してサーバーに送信すると仮定します。標準によれば、サーバーはリクエストを受信した順序で結果を返す必要があります。サーバーが最初のリクエストの処理に多くの時間を費やすと仮定すると、後続のリクエストはすべて、応答する前に最初のリクエストが完了するまで待機する必要があります。 。

そのため、最新のブラウザでは、デフォルトでは HTTP パイプラインが有効になっていません。

ただし、HTTP2 は、TCP 接続で複数の HTTP リクエストを同時に完了できる多重化機能を提供します。多重化がどのように正確に実装されるかは別の問題です。 HTTP2 を使用する効果を見てみましょう。

インタビュアーは、「TCP 接続は HTTP リクエストをいくつ送信できますか?」と尋ねました。

緑はリクエストの開始からリクエストの戻りまでの待ち時間、青はレスポンスのダウンロード時間です。これらはすべて同じプロセスで並行して完了していることがわかります。 Connection

したがって、この質問にも答えがあります。HTTP/1.1 には複数のリクエストの送信を同時に完了できるパイプライン技術がありますが、ブラウザはデフォルトで閉じられているため、そうではないと考えられます。実現可能。 HTTP2 では、多重化機能により、複数の HTTP リクエストを同じ TCP 接続上で並行して処理できます。

では、HTTP/1.1 時代、ブラウザはどのようにしてページの読み込み効率を向上させているのでしょうか?主なポイントは 2 つあります。

  • サーバーと確立された TCP 接続を維持し、同じ接続上で複数のリクエストを順次処理します。

  • #サーバーとの複数の TCP 接続を確立します。

4 番目の質問

ページを更新するときに SSL 接続を再確立する必要がない場合があるのはなぜですか?

答えは最初の質問の説明ですでに示されていますが、TCP 接続はブラウザとサーバーによって一定期間維持されることがあります。 TCP を再確立する必要はなく、SSL は当然以前のものを使用します。

5 番目の質問

ブラウザには、同じホストに対して確立できる TCP 接続の数に制限がありますか?

現在はまだ HTTP/1.1 の時代で、当時は多重化がなかったと仮定すると、数十枚の画像が含まれる Web ページをブラウザが取得した場合、ブラウザは何をすべきでしょうか?順次ダウンロードするために TCP 接続を開くことは絶対に不可能で、そうでない場合、ユーザーは確実に待たされることになりますが、画像ごとに TCP 接続を開いて HTTP リクエストを送信すると、コンピューターまたはサーバーが耐えられなくなる可能性があります。写真が 1,000 枚ある場合は、開くことができません。TCP 接続が 1,000 回ある場合、コンピュータが NAT に同意していても、同意していない可能性があります。

したがって、答えは「はい」です。 Chrome では、同じホストへの TCP 接続を最大 6 つまで許可します。ブラウザごとにいくつかの違いがあります。

developers.google.com/web/tools/ch...

元の質問に戻りますが、受信した HTML に数十の画像タグが含まれている場合、これらの写真をダウンロードするために、どのような方法で、どのような順序で、いくつの接続が確立され、どのようなプロトコルが使用されたのでしょうか?

画像がすべて HTTPS 接続で同じドメイン名にある場合、ブラウザは SSL ハンドシェイク後にサーバーと HTTP2 を使用できるかどうかを検討します。その場合は、多重化機能を使用してこの接続で多重化を実行します。 . .ただし、このドメイン名にリンクされているすべてのリソースが TCP 接続を使用して取得されるわけではありませんが、多重化が使用される可能性が高いことは確かです。

HTTP2 が使用できないことがわかった場合はどうすればよいですか?もしくはHTTPSが使えない(実際にはHTTPS上にHTTP2が実装されているのでHTTP/1.1しか使えない)。ブラウザは、ホスト上で複数の TCP 接続を確立します。接続数の最大制限は、ブラウザの設定によって異なります。これらの接続は、アイドル時に新しいリクエストを送信するためにブラウザによって使用されます。すべての接続がリクエストを送信している場合、毛織物?その場合、他のリクエストは待機する必要があります。

## 推奨学習: 「PHP ビデオチュートリアル

以上がインタビュアーは、「TCP 接続は HTTP リクエストをいくつ送信できますか?」と尋ねました。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明:
この記事はlearnku.comで複製されています。侵害がある場合は、admin@php.cn までご連絡ください。