http connection lifecycle
1.0.0
目次
技術面接などでよく聞かれる質問は、ブラウザに URL を入力するとどうなりますか?というものです。 Web サイトを閲覧するときに舞台裏で何が起こっているのでしょうか?一般的な HTTP 接続のライフサイクルには何が必要ですか?私の知る限りこれらの質問にお答えします。
接続プロセスに入る前に、基本的な OSI モデル (Open Systems Interconnection モデル) について説明します。 OSI モデルは、2 つのシステム間の通信を標準化する概念モデルです。1 つはリクエストを送信するシステム (クライアント) で、もう 1 つはリクエストを処理して応答を返すシステム (サーバー) です。以下の表は、各レイヤーの重要な特性の一部を示しています。
| いいえ | 層 | ハードウェア | 関数 | プロトコル/アプリ | 追加 |
|---|---|---|---|---|---|
| 7 | 応用 | サーバー/PC | アプリケーション、ユーザーインターフェース | HTTP、SMTP、DNS | L7ヘッダー |
| 6 | プレゼンテーション | サーバー/PC | 暗号化と構文の変更を処理します | JPEG、MP3 | L6ヘッダー |
| 5 | セッション | サーバー/PC | 認証、権限、セッション | SCP、OSのスケジューリング | L5ヘッダー |
| 4 | 輸送 | ファイアウォール | エンドツーエンドの配信、エラー制御 | TCP、UDP | L4ヘッダー |
| 3 | ネットワーク | ルーター | ネットワークアドレス指定、ルーティング、スイッチング | IP | L3ヘッダー |
| 2 | データリンク | スイッチ | 物理アドレス、エラー検出、フロー | イーサネット、フレームリレー | L2ヘッダー/トレーラー |
| 1 | 物理的な | ケーブル | 物理ネットワーク経由で転送されるビット | EIA/TIA | L1ヘッダー |
ブラウザに URL を入力して Enter/Return キーを押すとすぐに、ブラウザ (またはさらに言えばクライアント) は URL [1] を解析して重要なコンポーネントを抽出します。 URL の例を以下に示します。
https://www.google.com/search?q=cats
ここでは、Google で猫を検索しています。上記の URL から、 https://はプロトコル、 google.comはwww (インターネット) のホスト、 /searchはパス パラメーター、 ?q=cats Google に猫をクエリしていることを示すクエリ文字列パラメーターです [ 2]。
ブラウザはアクセスしようとしているホスト (この場合はgoogle.comを認識しているため、対応する IP アドレスを取得しようとします。 「 .com 」や「 .org 」などのドメインは、私たちが覚えやすいように作成されました。ただし、ブラウザが実際のリクエストをたとえば google.com に送信するには、ホストの IP アドレスが必要です。 DNS 解決は、特定のドメイン名の IP アドレス情報を取得するのに役立ちます。 DNS は、上の表のアプリケーション層 (L7) に存在します。
DNS 解決の手順:
$ ipconfig /displaydnsまたは Mac/Linux の$ log stream --predicate 'process == "mDNSResponder"' --infoを使用して、DNS キャッシュを確認できます。.com 、 .orgなどはトップレベルのドメイン名です。 TLD 名は、権威ネーム サーバーの IP アドレスを返します。$ dig google.com
; << >> DiG 9.10.6 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 9
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 180 IN A 172.217.164.174
;; AUTHORITY SECTION:
google.com. 60552 IN NS ns1.google.com.
google.com. 60552 IN NS ns2.google.com.
google.com. 60552 IN NS ns3.google.com.
google.com. 60552 IN NS ns4.google.com.
;; ADDITIONAL SECTION:
ns1.google.com. 60438 IN A 216.239.32.10
ns1.google.com. 58273 IN AAAA 2001:4860:4802:32::a
ns2.google.com. 60438 IN A 216.239.34.10
ns2.google.com. 131763 IN AAAA 2001:4860:4802:34::a
ns3.google.com. 163770 IN A 216.239.36.10
ns3.google.com. 60541 IN AAAA 2001:4860:4802:36::a
ns4.google.com. 75597 IN A 216.239.38.10
ns4.google.com. 60541 IN AAAA 2001:4860:4802:38::a
;; Query time: 13 msec
;; SERVER: 10.4.4.10#53(10.4.4.10)
;; WHEN: Mon Jun 24 12:20:50 PDT 2019
;; MSG SIZE rcvd: 303OSI モデルの各層では、情報は PDU (Packet Data Unit) と呼ばれます。したがって、アプリケーション層の情報は L7 PDU と呼ばれ、ネットワーク層の情報は L3 PDU と呼ばれます。各層に、対応する層ヘッダーが追加されます。ヘッダーは本体の前にあり、アドレス指定や、目的の宛先に到達するために必要なその他のデータが含まれています。一方、データは最上位の層から下に渡されます。 L4、L3、および L2 ヘッダーを以下に示します。
パケットがインターネットに送信されて最終的に Google ドメイン サーバーに到達する前に、まずルーターを経由してルーティングされる必要があります。デバイスが別のデバイス (この場合はローカル ルーター) に物理的に接続する必要がある場合は、そのデバイスの MAC アドレス (ハードウェア アドレス) が必要になります。しかし、ローカル マシンはルーターがデフォルト ルートであることをどのようにして知るのでしょうか?この情報は、ローカル マシン内でインターフェイスごとに設定されたデフォルト ルートを通じて取得されます。デフォルトルートは$ ifconfigコマンドで確認できます。
IP アドレスはネットワーク上のデバイスの位置を特定するために使用され、MAC アドレスは実際のデバイスを識別するために使用されます。 ARP プロトコルは、IP アドレスがわかっている場合に、デバイスの MAC アドレスを取得するために使用されます。ここでは、要求側のマシンが既に IP アドレスを (静的に、または DHCP プロトコル経由で) 受信していると仮定します。
ARP は OSI モデルのデータリンク層に存在します。この場合、ローカル マシン上で実行されている Web ブラウザは、インターネットへのゲートウェイであるルーターに接続します。
arp -aコマンドを使用して確認できます。その後、パケットはデフォルト ルートにルーティングされます。デフォルト ルートが設定されていない場合は、ルーターにルーティングされます。コマンドを使用してデフォルトルートを確認できます。
route get default | grep gatewayまたは Mac/Linux の場合はnetstat -rn 、Windows の場合はipconfig 。
たとえば、192.168.10.0/24 ネットワーク上にいて、172.217.164.174/24 の Google ネットワークに到達しようとしている場合、たとえばパケットがルーターに到着すると、ルーターはルーティング テーブルを確認し、トラフィックをルーティングする方法を決定します。宛先ネットワークに到達します。したがって、宛先 172.217.164.174/24 に到達するように指定されたゲートウェイにパケットが送信されます。
クライアントとサーバー間の接続。この場合、ローカルマシンから Google サーバーまでに多くのホップがかかります。各ホップは本質的に、宛先へのパスに沿ったルーターです。ここのルーターは、あるネットワークから別のネットワークにリクエストを送信するのに役立ちます。途中のすべてのデバイスには、世界的に一意の MAC アドレス (ハードウェア アドレス) があります。
ここで、ローカル マシンは、L7 ヘッダー (HTTP)、L4 ヘッダー (TCP)、L3 ヘッダー (IP)、L2 ヘッダー (ARP、MAC アドレス)、L2 トレーラー (フレーム チェック シーケンス) および実際のデータを含むリクエストを作成します。ルーターはパケットを取得すると、カプセル化を解除し、L2 ヘッダー/トレーラーを変更して、パケットを再度カプセル化します。
ルーターはそれを受信し、カプセル化解除を開始します。 L2 ヘッダーを調べて、宛先 Mac が自分自身のものであることを確認します。ここで、L2 ヘッダーが削除され、L3 ヘッダーが調べられ、リクエストが自分自身に対するものではなく Google サーバーに対するものであることがわかります。次に、ルーターは L3 ヘッダー内の TTL 値をデクリメントします。ルーターは、宛先に到達する方法について、他のルーターが (RIP または IGP 経由で) このルーターにアドバタイズした可能性のあるすべてのルートをルーティング テーブルで調べます。次に、あるルータは、キャッシュ内に MAC アドレスがない場合、ARP を実行してネクスト ホップ ルータの MAC アドレスを取得します。
次にルーターは、L2 トレーラーに続く CRC も追加します。これにより、次のルータは、パケットがネットワーク上で破損するような問題がルート上で発生していないことを知ることができます。破損している場合は、フレームがドロップされます。
この場合、ルーターは L2 ヘッダーと L2 トレーラーを変更しましたが、L3 ヘッダーには触れていないため、その上のヘッダーはありません。
送信元ポート番号はエピメラルポート番号になり、宛先ポート番号は 80 になります。
TCP - 信頼性の高い同一注文サービス。ローカル マシンはサーバーへのルートを知っているので、最初に Google サーバーとの 3 ウェイ ハンドシェイクを確立します。接続の確立は、MSS サイズ、初期シーケンス番号、ACK タイプ、バッファ サイズなどのいくつかの状態変数を最終決定するのに役立ちます。
この場合、TCP ヘッダーの送信元ポートと宛先ポートは 16 ビットなので、2^16 は 65535 になります。送信元ポートはクライアント アプリケーションを識別するために使用され、宛先ポートは Web サーバー上で実行されているサービスまたはデーモンを識別するために使用されます。
クライアント (Web ブラウザ) は 49152 ～ 65535 のポートを選択します。これにより、2 つのアプリケーションが同じポートを使用することがなくなります。ポート アドレスは IP アドレスとともに TCP ソケットと呼ばれます。宛先ポートは、IP パケットのポート 80 です。
コミュニケーションを開始します:
上記の 3 つの手順により、クライアントとサーバーの間で TCP ハンドシェイクが成功し、両方がデータ転送の共通ルールに同意しました。
安全な Web サイトに接続している場合は、TCP ハンドシェイクの後、TLS ハンドシェイクが行われます。 TLS ハンドシェイクを使用すると、クライアントとサーバーは安全な通信の共通条件に同意します。
これ以降、TLS セッションは、合意された対称キーで暗号化されたアプリケーション (HTTP) データを送信します。
サーバーはリクエストを処理し、適切な応答を送り返します。リクエストがポート 80 (HTTP) またはポート 443 (HTTPS) でサーバーに届くと、Apache や Nginx などの Web サーバーはポート 443 をリッスンし、リクエストの接続を処理し、Web サービスが存在する別の一時ポートにリクエストをルーティングします。走っている。
どの HTTP クライアント、サーバー、プロキシでも、いつでも TCP トランスポート接続を閉じることができます。たとえば、クライアントは、データ転送が終了し、開いている接続チャネルが不要になったことを検出すると、接続終了要求をサーバーに送信します。次回、クライアントがサーバーと通信したい場合は、2 つのマシン間に新しい接続を確立する必要があります。
| [1] | URL標準 |
| [2] | コンポーネントまたは URL |
