URL を入力すると、バックグラウンドでは具体的に何が起こるのでしょうか?

ソフトウェア開発者は、ネットワークアプリケーションがどのように動作するかを階層的に完全に理解している必要があります。これには、ブラウザー、HTTP、HTML、ネットワークサーバー、要求処理など、これらのアプリケーションで使用されるテクノロジも含まれます。

この記事では、URL を入力したときにバックグラウンドで何が起こるかを詳しく見ていきます。

1. まず、ブラウザにURLを入力する必要があります:

2. ブラウザはドメイン名のIPアドレスを検索します

ナビゲーションの最初のステップは、アクセスしているドメイン名の IP アドレスを見つけることです。 DNS ルックアッププロセスは次のとおりです。

ブラウザのキャッシュ –ブラウザは DNS レコードを一定期間キャッシュします。興味深いことに、オペレーティングシステムはブラウザーに DNS レコードを保存する期間を指示しないため、ブラウザーによって DNS レコードが一定期間 (2 分から 30 分の範囲) 保存されます。システムキャッシュ - 必要なレコードがブラウザーキャッシュに見つからない場合、ブラウザーはシステムコール (Windows では gethostbyname) を実行します。これにより、システムキャッシュ内のレコードが取得されます。ルーターキャッシュ – 次に、以前のクエリ要求がルーターに送信されます。ルーターには通常、独自の DNS キャッシュがあります。 ISP DNS キャッシュ – 次に確認するのは、ISP の DNS キャッシュサーバーです。対応するキャッシュレコードは通常、ここにあります。再帰検索 - ISP の DNS サーバーは、ルートネームサーバーから始まり、.com のトップレベルネームサーバーから Facebook のネームサーバーまで再帰検索を実行します。通常、DNS サーバーキャッシュには .com ドメインネームサーバーのドメイン名が含まれているため、最上位サーバーとのマッチングプロセスはそれほど必要ありません。

DNS 再帰ルックアップを次の図に示します。

500px-An_example_of_theoretical_DNS_recursion_svg

DNS に関して懸念される点の 1 つは、wikipedia.org や facebook.com などのドメイン全体が、単一の IP アドレスに対応しているように見えることです。幸いなことに、このボトルネックを解消する方法はいくつかあります。

ラウンドロビン DNS は、 DNS ルックアップ中に複数の IP が返される場合のソリューションです。たとえば、Facebook.com は実際には 4 つの IP アドレスに対応しています。ロードバランサは、特定の IP アドレスをリッスンし、ネットワーク要求をクラスター内のサーバーに転送するハードウェアデバイスです。一部の大規模サイトでは、通常、この高価で高性能なロードバランサが使用されます。地理DNS は、ユーザーの地理的な場所に基づいてドメイン名を複数の異なる IP アドレスにマッピングすることで、スケーラビリティを向上させます。この方法では、異なるサーバーを同期して更新することはできませんが、静的コンテンツをマッピングするには最適です。エニーキャストは、IP アドレスを複数の物理ホストにマッピングするルーティングテクノロジーです。唯一の欠点は、Anycast が TCP プロトコルにうまく適応しないため、これらのソリューションではほとんど使用されないことです。

ほとんどの DNS サーバーは、効率的で低遅延の DNS ルックアップを実現するために Anycast を使用します。

3. ブラウザはウェブサーバーにHTTPリクエストを送信します。

Facebook ホームページのような動的ページは、開いた後すぐにブラウザキャッシュで期限切れになるか、あるいはすぐに期限切れになるため、そこから読み取ることはできません。

したがって、ブラウザは Facebook サーバーに次のリクエストを送信します。

 http://facebook.com/ HTTP/1.1 を取得します
 受け入れる: application/x-ms-application、image/jpeg、application/xaml+xml、[...]
 ユーザーエージェント: Mozilla/4.0 (互換; MSIE 8.0; Windows NT 6.1; WOW64; [...]
 Accept-Encoding: gzip、deflate
 接続: キープアライブ
 ホスト: facebook.com
 クッキー: datr=1265876274-[...]; locale=en_US; lsd=WW[...]; c_user=2101[...]

GET このリクエストは、読み取るURLを定義します: "http://facebook.com/"。ブラウザは、ブラウザ自体 ( User-Agentヘッダー) と、受信する応答の種類 (Accept ヘッダーと Accept -Encodingヘッダー) を定義します。Connectionヘッダーは、後続の要求に対して TCP 接続を閉じないようにサーバーに要求します。

リクエストには、ドメインのブラウザに保存されているCookieも含まれます。すでにご存知かもしれませんが、Cookie はさまざまなページリクエストにわたって Web サイトの状態を追跡するキーと値のペアです。このようにして、Cookie にはログインユーザー名、サーバーによって割り当てられたパスワード、および一部のユーザー設定が保存されます。クッキーはテキストファイルとしてクライアントに保存され、リクエストが行われるたびにサーバーに送信されます。

生の HTTP リクエストとその応答を表示するためのツールは多数あります。著者は fiddler を使用することを好みますが、もちろん FireBug のような他のツールもあります。これらのソフトウェアは、Web サイトの最適化に非常に役立ちます。

取得リクエストに加えて、フォームを送信するときによく使用される送信リクエストもあります。 URL 経由でパラメータを渡すリクエストを送信します (例: http://robozzle.com/puzzle.aspx?id=85)。送信リクエストは、リクエスト本文ヘッダーの後にパラメータを送信します。

「http://facebook.com/」のように、スラッシュは重要です。この場合、ブラウザは安全にスラッシュを追加できます。「http://example.com/folderOrFile」のようなアドレスの場合、ブラウザは folderOrFile がフォルダかファイルか分からないため、自動的にスラッシュを追加できません。この時点で、ブラウザはスラッシュなしでアドレスに直接アクセスし、サーバーはリダイレクトで応答し、不要なハンドシェイクが発生します。

4. Facebookサービスからの永続的なリダイレクト応答

次の画像は、Facebook サーバーからブラウザに返された応答を示しています。

 HTTP/1.1 301 永久に移動
 キャッシュ制御: プライベート、保存なし、キャッシュなし、再検証必須、事後チェック=0、
 事前チェック=0
 有効期限: 2000 年 1 月 1 日 (土) 00:00:00 GMT
 所在地: http://www.facebook.com/
 P3P: CP="DSP 法"
 プラグマ: キャッシュなし
 Set-Cookie: made_write_conn=削除済み; 有効期限=Thu, 12-Feb-2009 05:09:50 GMT;
 パス=/; ドメイン=.facebook.com; httponly
 コンテンツタイプ: text/html; 文字セット=utf-8
 X-接続: 閉じる
 日付: 2010 年 2 月 12 日 (金) 05:09:51 GMT
 コンテンツの長さ: 0

サーバーは 301 Permanent Redirect 応答でブラウザに応答し、ブラウザは「http://facebook.com/」ではなく「http://www.facebook.com/」にアクセスすることになります。

ユーザーが見たい Web ページのコンテンツを直接送信するのではなく、サーバーがリダイレクトする必要があるのはなぜですか?この質問には興味深い答えがたくさんあります。

その理由の 1 つは、検索エンジンのランキングに関係しています。ページに http://www.igoro.com/ と http://igoro.com/ のように 2 つのアドレスがある場合、検索エンジンはそれらを 2 つの Web サイトと認識し、その結果、それぞれの検索リンクが少なくなり、ランキングが低くなります。検索エンジンは 301 永続リダイレクトの意味を認識しているため、同じ Web サイト内の www があるアドレスと www がないアドレスへのアクセスをランク付けします。

もう 1 つは、異なるアドレスを使用するとキャッシュに適さなくなることです。ページに複数の名前がある場合、キャッシュ内に複数回表示されることがあります。

5. ブラウザトラッキングリダイレクトアドレス

これでブラウザは「http://www.facebook.com/」がアクセスすべき正しいアドレスであると認識したので、別の GET リクエストを送信します。

 GET http://www.facebook.com/ HTTP/1.1
 受け入れる: application/x-ms-application、image/jpeg、application/xaml+xml、[...]
 受け入れ言語: en-US
 ユーザーエージェント: Mozilla/4.0 (互換; MSIE 8.0; Windows NT 6.1; WOW64; [...]
 Accept-Encoding: gzip、deflate
 接続: キープアライブ
 クッキー: lsd=XW[...]; c_user=21[...]; x-referer=[...]
 ホスト: www.facebook.com

ヘッダー情報は、前のリクエストと同じ意味を持ちます。

6. サーバーはリクエストを「処理」します

サーバーは GET リクエストを受信し、処理して、応答を返します。

表面的には、これは簡単な作業のように見えるかもしれませんが、実際には、著者のブログのようなシンプルな Web サイトはもちろん、Facebook のように多数の訪問者がいる Web サイトでも、プロセス中に多くの興味深いことが起こります。

Web サーバーソフトウェア
Web サーバーソフトウェア (IIS や Apache など) は、HTTP 要求を受信し、それを処理するために実行する要求処理を決定します。リクエストハンドラーは、リクエストを理解し、それに応じて HTML を生成するプログラムです (ASP.NET、PHP、RUBY など)。

最も単純な例では、需要処理は、Web サイトのアドレスの構造をマップするファイル階層に保存できます。たとえば、アドレス http://example.com/folder1/page1.aspx はファイル /httpdocs/folder1/page1.aspx にマップされます。 Web サーバーソフトウェアは、アドレスの要求を手動で処理するように構成できるため、page1.aspx の公開アドレスは http://example.com/folder1/page1 になります。

リクエスト処理
リクエストハンドラーは、リクエストとそのパラメーターおよび Cookie を読み取ります。一部のデータを読み取り、場合によっては更新してサーバーに保存します。リクエスト処理により HTML 応答が生成されます。

すべての動的 Web サイトは、データをどのように保存するかという興味深い難題に直面しています。ほとんどの小規模な Web サイトには、データを保存するための SQL データベースがあり、大量のデータを保存したり、トラフィックが多い Web サイトでは、複数のマシンにデータベースを分散する方法を見つける必要があります。ソリューションには、シャーディング (主キー値に基づいてデータテーブルを複数のデータベースに分散する)、レプリケーション、弱いセマンティック一貫性を使用した簡素化されたデータベースなどがあります。

作業をバッチ処理に委任することは、データを最新の状態に保つための安価な手法です。たとえば、Facebook はニュースフィードをタイムリーに更新する必要がありますが、データでサポートされている「知り合いかも」機能は毎晩更新するだけで済みます (これは著者の推測であり、この機能がどのように改善されるかは不明です)。バッチジョブの更新により、重要度の低いデータが古くなる可能性がありますが、データ更新作業がより高速かつ簡潔になります。

7. サーバーはHTMLレスポンスを返す

次の図は、サーバーによって生成され返された応答を示しています。

 HTTP/1.1 200 OK
 キャッシュ制御: プライベート、保存なし、キャッシュなし、再検証必須、事後チェック=0、
 事前チェック=0
 有効期限: 2000 年 1 月 1 日 (土) 00:00:00 GMT
 P3P: CP="DSP 法"
 プラグマ: キャッシュなし
 コンテンツエンコーディング: gzip
 コンテンツタイプ: text/html; 文字セット=utf-8
 X-接続: 閉じる
 転送エンコーディング: チャンク
 日付: 2010 年 2 月 12 日金曜日 09:05:55 GMT

 2b3Tn@[...]

応答全体のサイズは 35kB で、その大部分はトリミングされた後に BLOB として転送されます。

Content-Encodingヘッダーは、レスポンス本文全体を gzip アルゴリズムを使用して圧縮する必要があることをブラウザに伝えます。 BLOB を解凍すると、期待どおりの HTML が表示されます。

 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"
 lang="ja" id="facebook" class="no_js">
 <ヘッド>
 <meta http-equiv="コンテンツタイプ" content="text/html; charset=utf-8" />
 <meta http-equiv="コンテンツの言語" content="en" />
 ...

圧縮に関しては、ヘッダー情報には、ページをキャッシュするかどうか、キャッシュする場合の方法、設定する Cookie (前の応答には含まれません)、プライバシー情報などが示されます。

Content-typeヘッダーが「 text/html 」に設定されていることに注意してください。ヘッダーは、応答コンテンツをファイルとしてダウンロードするのではなく、HTML としてレンダリングするようにブラウザに指示します。ブラウザはヘッダー情報に基づいて応答を解釈する方法を決定しますが、URL 拡張子などの他の要素も考慮します。

8. ブラウザがHTMLを表示し始める

ブラウザが HTML ドキュメント全体の読み取りを完了する前に、このページの表示を開始します。

9. ブラウザはHTMLに埋め込まれたオブジェクトを取得するリクエストを送信する

ブラウザは HTML を表示するときに、他のアドレスのコンテンツを取得する必要があるタグを認識します。この時点で、ブラウザはファイルを取得するための GET リクエストを送信します。

facebook.com にアクセスしたときに再取得する必要がある URL をいくつか示します。

写真
http://static.ak.fbcdn.net/rsrc.php/z12E0/hash/8q2anwu7.gif
http://static.ak.fbcdn.net/rsrc.php/zBS5C/hash/7hwy7at6.gif
… CSS スタイルシート
http://static.ak.fbcdn.net/rsrc.php/z448Z/hash/2plh8s4n.css
http://static.ak.fbcdn.net/rsrc.php/zANE1/hash/cvtutcee.css
… JavaScript ファイル
http://static.ak.fbcdn.net/rsrc.php/zEMOA/hash/c8yzb6ub.js
http://static.ak.fbcdn.net/rsrc.php/z6R9L/hash/cq2lgbs8.js
…

これらのアドレスは、HTML の読み取りに似たプロセスを経ます。そのため、ブラウザは DNS でそれらのドメインを検索し、リクエストを送信し、リダイレクトなどを行います。

しかし、動的ページとは異なり、静的ファイルはブラウザでキャッシュできます。一部のファイルはサーバーと通信する必要がなく、キャッシュから直接読み取ることができます。サーバーの応答には、静的ファイルを保持する期間に関する情報が含まれているため、ブラウザは静的ファイルをキャッシュする期間を把握できます。さらに、各レスポンスには、バージョン番号のように機能する ETag ヘッダー (要求された変数のエンティティ値) が含まれる場合があります。ブラウザは、ファイルのバージョン ETag 情報がすでに存在することを認識すると、直ちにファイルの送信を停止します。

アドレスの「 fbcdn.net 」が何の略か推測してみてください。賢い答えは「Facebook コンテンツ配信ネットワーク」です。 Facebook は、コンテンツ配信ネットワーク (CDN) を使用して、画像、CSS シート、JavaScript ファイルなどの静的ファイルを配信します。したがって、これらのファイルは世界中の多くの CDN データセンターにバックアップされます。

静的コンテンツは多くの場合、サイトの帯域幅のサイズを表し、CDN を通じて簡単に複製できます。通常、Web サイトはサードパーティの CDN を使用します。たとえば、Facebook の静的ファイルは、最大の CDN プロバイダーである Akamai によってホストされています。

たとえば、static.ak.fbcdn.net に ping を実行しようとすると、akamai.net サーバーから応答が返される場合があります。興味深いことに、再度 ping を実行すると、応答するサーバーが異なる場合があり、これは舞台裏で負荷分散が機能し始めたことを意味します。

10. ブラウザは非同期（AJAX）リクエストを送信します

Web 2.0 の精神に従い、ページが表示された後もクライアントはサーバーに接続されたままになります。

Facebook のチャット機能を例に挙げると、サーバーと通信して、明るい友達と灰色の友達のステータスを適時に更新します。アバターが点灯している友達のステータスを更新するために、ブラウザで実行される JavaScript コードはサーバーに非同期リクエストを送信します。この非同期要求は特定のアドレスに送信され、プログラムによって構築された取得要求または送信要求です。 Facebook の例では、クライアントは http://www.facebook.com/ajax/chat/buddy_list.php に公開要求を送信し、どの友達がオンラインであるかのオンラインステータス情報を取得します。

このパターンについて話すとき、「AJAX」、つまり「非同期 JavaScript と XML」について話す必要がありますが、サーバーが XML 形式で応答する明確な理由はありません。別の例として、非同期リクエストの場合、Facebook はいくつかの JavaScript コードスニペットを返します。

とりわけ、Fiddler はブラウザから送信された非同期リクエストを確認できるツールです。実際、これらのリクエストを受動的に監視できるだけでなく、自発的にリクエストを変更して再送信することもできます。 AJAX リクエストが簡単に騙される可能性があるという事実は、スコアを記録するオンラインゲームの開発者にとってはイライラするものです。（もちろん、そんな嘘はつけないでね～）

Facebook のチャット機能は、サーバーからクライアントにデータをプッシュするという AJAX の問題の興味深い例を示しています。 HTTP は要求応答プロトコルであるため、チャットサーバーはクライアントに新しいメッセージを送信できません。代わりに、クライアントは数秒ごとにサーバーをポーリングして、新しいメッセージがあるかどうかを確認する必要があります。

ロングポーリングは、このような状況が発生したときにサーバーの負荷を軽減するための興味深い手法です。ポーリング時にサーバーに新しいメッセージがない場合、クライアントは無視されます。タイムアウト前にクライアントから新しいメッセージを受信すると、サーバーは未完了の要求を見つけ、新しいメッセージを応答としてクライアントに返します。

<<: Nginx 構成の実装 HTTPS セキュリティ認証

>>: Vueカスタムディレクティブの詳細