URLを入力するとき、背景に何が起こったのか

著者：Eve Cole 更新時間：2025-05-25 03:48:01

ソフトウェア開発者として、ネットワークアプリケーションの仕組みを完全かつ階層的に理解することができます。これには、ブラウザー、HTTP、HTML、Webサーバー、要件処理など、これらのアプリケーションで使用されるテクノロジーも含まれます。

この記事では、URLを入力するとバックグラウンドで何が起こるかをさらに詳しく調べます〜

1.まず、ブラウザに目的のURLを入力する必要があります。2。ブラウザはドメイン名のIPアドレスを検索します

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

ブラウザキャッシュ -ブラウザはDNSレコードを一定期間記録します。興味深いことに、オペレーティングシステムはブラウザにDNSレコードを保存する時間を指示しないため、さまざまなブラウザが自己固定時間（2分から30分の範囲）を保存します。システムキャッシュ - 必要なレコードがブラウザキャッシュに表示されていない場合、ブラウザはシステムコール（Windowsのgethostbyname）を作成します。これにより、システムキャッシュ内のレコードを取得できます。ルーターキャッシュ - 次に、以前のクエリリクエストはルーターに送信されます。ルーターには、通常は独自のDNSキャッシュがあります。 ISP DNSキャッシュ - チェックする次のことは、ISPがDNSをキャッシュするサーバーです。これは、対応するキャッシュレコードを一般的に見つけることができる場所です。再帰検索 - ISPのDNSサーバーは、.comトップレベルドメイン名サーバーからFacebookのドメイン名サーバーまで、ドメイン名サーバーから始まります。一般に、DNSサーバーのキャッシュには.comドメイン名サーバーにドメイン名があるため、トップレベルサーバーへの一致するプロセスはそれほど必要ありません。

DNS再帰検索は、下の図に示されています。

DNSは少し心配です。つまり、wikipedia.orgやfacebook.comのようなドメイン名全体が、別のIPアドレスに対応しているように見えます。幸いなことに、このボトルネックを排除する方法はいくつかあります。

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

ほとんどのDNSサーバーは、Anycastを使用して、効率的で低レイテンシDNSルックアップを取得します。

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

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
 Cookie：datr = 1265876274- [...]; locale = en_us; LSD = ww [...]; c_user = 2101 [...]

このリクエストを取得すると、読み取るURLが定義されています：http：//facebook.com/。ブラウザ自体は（ユーザーエージェントヘッダー）を定義し、受け入れたい対応する対応するタイプ（受け入れおよび受け入れヘッダー）を定義します。接続ヘッダーでは、サーバーが後続の要求のためにTCP接続を閉じないように要求します。

リクエストには、ブラウザによって保存されたドメイン名のCookieも含まれています。さまざまなページリクエストでは、CookieがWebサイトのステータスに一致する重要な値であることを既に知っているかもしれません。これにより、Cookieはログインユーザー名、サーバーが割り当てられたパスワード、および一部のユーザー設定を保存します。 Cookieはクライアントにテキストドキュメントとして保存され、リクエストするたびにサーバーに送信されます。

元のHTTP要求とその対応するツールを見るための多くのツールがあります。著者はフィドラーを使用することを好み、もちろんFireBugのような他のツールがあります。これらのソフトウェアは、Webサイトを最適化するときに大きな助けになります。

リクエストの取得に加えて、送信される別のタイプのリクエストがあります。これはフォームを送信するときによく使用されます。 URLを介してパラメーターを渡すリクエストを送信します（例：http：//robozzle.com/puzzle.aspx?id=85）。リクエストの送信リクエストボディヘッダーの後にパラメーターを送信します。

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

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

写真は、Facebookサーバーからブラウザに送信された応答を示しています。

HTTP/1.1 301は永久に移動しました

キャッシュコントロール：プライベート、ストアなし、ノーキャッシュ、必見、再評価、ポストチェック= 0、

プレチェック= 0

期限切れ：土、2000年1月1日00:00:00 GMT

場所：http：//www.facebook.com/

P3P：CP = DSP Law

プラグマ：キャッシュなし

SetCookie：made_write_conn =削除;期限切れ=木、12-FEB-2009 05:09:50 GMT;

path =/; domain = .facebook.com; httponly

コンテンツタイプ：text/html; charset = utf-8

X-nection：閉じます

日付：金曜日、2010年2月12日05:09:51 GMT

コンテンツレングス：0

サーバーは301の永続的なリダイレクト応答に応答します。そのため、ブラウザはhttp://facebook.com/の代わりにhttp://www.facebook.com/にアクセスします。

ユーザーが表示したいWebコンテンツを直接送信する代わりに、サーバーがリダイレクトする必要があるのはなぜですか？この質問には多くの興味深い答えがあります。

理由の1つは、検索エンジンのランキングに関連しています。 http://www.igoro.com/やhttp://igoro.com/などのページに2つのアドレスがある場合、検索エンジンはそれらを2つのWebサイトと見なし、それぞれの検索リンクが減少し、ランキングが低下します。検索エンジンは、301永久リダイレクトが何を意味するかを知っているため、同じWebサイトランキングの下でwwwを使用してwwwを使用してアドレスへのアクセスを分類します。

別のことは、異なるアドレスを使用すると、キャッシュの親しみやすさが悪化するということです。ページにいくつかの名前がある場合、キャッシュに数回表示される場合があります。

5.ブラウザはリダイレクトアドレスを追跡します

これで、ブラウザは、http：//www.facebook.com/がアクセスする正しいアドレスであることを知っているため、別のgetリクエストが送信されます。

 http://www.facebook.com/ http/1.1を入手してください
受け入れ：Application/X-MS-Application、Image/JPEG、Application/XAML+XML、[...]
 Accept-Language：en-us
ユーザーエージェント：Mozilla/4.0（互換性、MSIE 8.0; Windows NT 6.1; Wow64; [...]
 Accept-Encoding：gzip、deflate
接続：キープアライブ
Cookie：LSD = XW [...]; c_user = 21 [...]; x-referer = [...]
ホスト：www.facebook.com

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

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

サーバーはフェッチ要求を受信し、応答を処理して返します。

これは表面上の将来のタスクのようですが、実際、著者のブログのような簡単なウェブサイトであるFacebookのようなWebサイトは言うまでもなく、真ん中に多くの興味深いことが起こっています。

Webサーバーソフトウェア

Webサーバーソフトウェア（IISやApacheなど）は、HTTP要求を受信し、それを処理するために実行されるリクエスト処理を決定します。リクエスト処理は、リクエストを読み取り、応答するHTMLを生成できるプログラムです（ASP.NET、PHP、Rubyなど）。

最も簡単な例を示すために、要件処理は、サイトアドレス構造をマップするファイル階層に保存できます。 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 Law

プラグマ：キャッシュなし

コンテンツエンコード：GZIP

コンテンツタイプ：text/html; charset = utf-8

X-nection：閉じます

転送エンコード：チャンク

日付：金曜日、2010年2月12日09:05:55 GMT

2b3tn@[...]

応答サイズ全体は35kbで、そのほとんどはソート後にブロブタイプとして転送されます。

コンテンツエンコード端子は、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 = en id = facebook class = no_js>
 <head>
 <メタhttp-equiv = content-type content = text/html; charset = utf-8 />
 <メタhttp-equiv = content-language content = en />
 ...

圧縮に関して、ヘッダー情報は、このページがキャッシュされているかどうか、キャッシュされた場合の方法、どのクッキーを設定するか（このポイントは以前の応答ではありません）、プライバシー情報などを説明します。

コンテンツタイプは、ヘッダーのテキスト/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を介して簡単にコピーすることもできます。通常、ウェブサイトはサードパーティのCDNを使用します。たとえば、Facebookの静的ファイルは、最大のCDNプロバイダーであるAkamaiがホストしています。

たとえば、static.ak.fbcdn.netをpingしようとすると、特定のakamai.netサーバーから応答が得られる場合があります。興味深いことに、再びpingをすると、応答サーバーが異なる場合があります。つまり、舞台裏のバランスが取れていることを意味します。

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

Great Spirit of Web 2.0に導かれ、ページ表示が完了した後、クライアントはサーバーと連絡を取り合ったままです。

Facebookチャット機能を例にとると、サーバーと連絡を取り合って、明るい灰色の友人のステータスをタイムリーに更新します。これらのアバターの友人ステータスを更新するために、ブラウザで実行されたJavaScriptコードは、サーバーに非同期リクエストを送信します。この非同期リクエストは、プログラムが構築されたフェッチまたは送信リクエストである特定のアドレスに送信されます。または、Facebookの例では、クライアントはhttp://www.facebook.com/ajax/chat/buddy_list.phpにリクエストを送信して、友人のオンラインのステータス情報を取得します。

このパターンに関しては、ajax - asynchronous javascriptとxmlについて話さなければなりません。サーバーがXML形式で応答する明確な理由はありませんが。別の例を挙げましょう。非同期リクエストの場合、FacebookはJavaScriptコードスニペットを返します。

とりわけ、Fiddlerツールを使用すると、ブラウザから送信された非同期リクエストを確認できます。実際、あなたはこれらの要求の観客として受動的に役立つだけでなく、積極的に攻撃してそれらを変更して再送信することもできます。 Ajaxのリクエストは非常に簡単にだまされますが、スコアスコアを獲得したオンラインゲーム開発者を本当に落ち込ませています。（もちろん、そのような他の人に嘘をつかないでください〜）

Facebookチャット関数は、Ajaxの興味深いケースを提供します。サーバーからクライアントにデータをプッシュします。 HTTPはリクエスト応答プロトコルであるため、チャットサーバーはクライアントに新しいメッセージを送信できません。代わりに、クライアントは数秒ごとにサーバー側を投票して、新しいニュースがあるかどうかを確認する必要があります。

これらの状況のポーリングは、サーバーの負荷を減らすための興味深い手法です。投票時にサーバーに新しいメッセージがない場合、クライアントは無視します。クライアントからの新しいメッセージがまだタイムアウトしていない場合、サーバーは未完成のリクエストを見つけて、応答として新しいメッセージをクライアントに返します。