ブラウザがURLを入力してEnterキーを押した後に何が起こるか

ブラウザがURLを入力してEnterキーを押した後に何が起こるか
### 1。ブラウザがURLを入力してEnterキーを押した後に何が起こるか

ソフトウェア開発者は、Webアプリの全体的なワークフローと、関連するテクノロジー（ブラウザー、HTTP、HTML、Webサーバー、要求など）を知っている必要があります。

1）まず、ブラウザから次のようにアドレスを入力します。

[外部リンク画像の転送に失敗しました。ソースサイトにヒル防止リンクメカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします（img-3JLhfGFl-1605454959578）（http://igoro.com/wordpress/wp- content / uploads / 2010/02 /image4.png）]

2）ブラウザはこのドメイン名に対応するIPアドレスを検索します。

[外部リンク画像の転送に失敗しました。元のサイトにヒル防止リンクメカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします（img-r2nth1ly-1605454959580）（http://igoro.com/wordpress/wp- content / uploads / 2010/02 /image13.png）]

アクセス解決速度を向上させるために、設計者は次のようなキャッシュのいくつかのレイヤーを設計しました。

[1]ブラウザキャッシュ-ブラウザキャッシュは一定期間DNSレコードを記録します。この時間はオペレーティングシステムによって制御されませんが、通常2〜30分の間ブラウザに組み込まれます。このキャッシュはCookieです。ドメイン名Cookieは、現在のドメイン名またはトップレベルドメイン名にのみ設定でき、その他は生成されません。

[2] OSキャッシュ-ブラウザキャッシュが対応するDNSレコードを見つけられない場合、ブラウザはシステムコールを使用してIPを取得し、オペレーティングシステムには独自のキャッシュがあります。このキャッシュは実際にはhostsファイルです。Windowsシステムではc：/ windows / system32 / drivers / etc / hostsに、Linuxシステムでは/ etc / hostsにあります。以下に対応するキーと値のペアがある場合は、gethostbyname（「www.facebook.com」）で10.110.110.120を取得します。

10.110.110.120 www.facebook.com

[3]ルーターキャッシュ-LANでのインターネットアクセスは通常ルーターに基づいています。このルーターにはドメイン名キャッシュがあります。具体的なキャッシュ方法や時間などについては、具体的な調査はありません。

[4] ISP（インターネットサービスプロバイダー）キャッシュ-DNSをキャッシュするサーバーを検索します。これは、一般的に見られるセカンダリDNSサーバーに相当します。

[5]再帰検索---- ISPのドメインネームサーバーが対応するレコードを見つけられない場合、ISPはドメインネームサーバーから再帰的に検索します。検索方向は、最上位のドメインネームサーバーからFacebookのドメインネームサーバーへと始まります。（ドメインネームサーバーとISPドメインネームサーバーの関係は、父と子の関係であると理解しています。子が父を見つけられない場合は、父が見つかります。それ以外の場合は、保持されません。さらに、このドメインネームサーバーはクラスターの形式であることが多いため、再帰が必要です。検索）

再帰検索プロセスは次のとおりです。

[外部リンク画像の転送に失敗しました。ソースサイトにヒル防止リンクメカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします（img-G4sK8eaG-1605454959582）（http://igoro.com/wordpress/wp- content / uploads / 2010/02 /500pxAn_example_of_theoretical_DNS_recursion_svg.png）]

注意すべき点の1つは、一部のFacebookまたは組織はIPアドレスのみをマップしているように見えるため、ボトルネックの問題を解決するために一般的に次の方法が使用されることです。

ラウンドロビンDNS - DNSを読み取るためのポーリング、これを理解する方法、Facebookには5つのサーバーがあると想定され、上記のリソースは同じであり、ハードウェアのパフォーマンスも同じです。カスタマーサービスがFacebookのリソースにアクセスすると、次のことができます。サーバーで十分なので、非常に簡単な方法が設計されています。各ユーザーが順番にドメイン名にアクセスして、ドメイン名を異なるIPに解決し、各サーバーが受信するアクセス数がバランスをとるようにします。もちろん、、それは数だけです。要求されたリソースは間違いなく違います。

ロードバランサー-負荷分散。上記の方法に基づいて重みを追加し、サーバーの処理能力に応じて、リクエストが対応するサーバーIPに解決されるようにします。

地理的DNS—地理的に分割されたDNSサーバー。顧客の地理的な場所に応じて、ドメイン名を近くのサーバーまたはより適切なサーバーに解決します。この方法は主に静的コンテンツに適用されますが、動的コンテンツには同期の更新やその他の問題が含まれます。効果はそれほど明白ではありません。

エニーキャスト—使用されることはめったになく、TCPプロトコルにうまく適合しません。これは、IPアドレスを複数のホストにマップするルーティングテクノロジーです。ほとんどのDNSサーバーは、エニーキャストを使用して、効率的で低遅延のDNSルックアップを取得します。

3）ブラウザがHTTPリクエストをWebサーバーに送信します

[外部リンク画像の転送に失敗しました。ソースサイトにヒル防止リンクメカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします（img-reVXwJ5q-1605454959583）（http://igoro.com/wordpress/wp- content / uploads / 2010/02 /image22.png）]

Facebookホームページなどの動的ページの場合、ブラウザのキャッシュは一度アクセスするとすぐに期限切れになるため、Facebookサーバーにリクエストを再送信する必要があります。リクエストには次の3つの部分があります。

（1）GETリクエストは、読み取るURL「http://facebook.com/」を定義します。

（2）ブラウザ自体の定義（User-Agent）

（3）受信する予定の応答のタイプ（AcceptおよびAccept-Encoding）。

GET http://facebook.com/ HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: facebook.com
Cookie: datr=1265876274-[...]; locale=en_US; lsd=WW[...]; c_user=2101[...]

Connectionヘッダーは、tcpスリーウェイハンドシェイク後に維持される状態です。この状態により、接続が一時的に切断されないことが保証されます。さらに、このドメイン名を要求するCookieが含まれます。ご存知のとおり、Cookieの役割は、さまざまなWebサイト要求のステータスを記録および追跡することです。これらのステータスには、ログイン名またはパスワード、特定の認証トークン、および一部のユーザー設定が含まれます。これらのCookieはに保存されます。同じドメイン名が要求されるたびに、クライアントが持ち込まれます。

Fiddler、httpwatch、firebug、wiresharkなど、アクセス要求を表示するための多くのツールがあります。jsファイル、Cookie、その他の任意の構造を含むhttpリクエストを模倣できます。

もちろん、ソフトウェア開発を行う人は、フォームフォームの送信に使用される投稿リクエストに精通している必要があります。

小さなヒントがあります。これは終了スラッシュhttp://facebook.com/とhttp://example.com/folderOrFileです。後者は、終了スラッシュがないため、ファイルかファイルかが明確でないため、もう1つのリクエストが発生します。フォルダー、およびファイルが最初になりますアクセスするには、正しくない場合は、フォルダーにリダイレクトします。

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

[外部リンク画像の転送に失敗しました。ソースサイトにヒル防止リンクメカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします（img-edkDJDFq-1605454959584）（http://igoro.com/wordpress/wp- content / uploads / 2010/02 /image8.png）]

以下は、Facebookサーバーからブラウザーに送信されるリクエストです。

HTTP/1.1 301 Moved Permanently
Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,
      pre-check=0
Expires: Sat, 01 Jan 2000 00:00:00 GMT
Location: http://www.facebook.com/
P3P: CP="DSP LAW"
Pragma: no-cache
Set-Cookie: made_write_conn=deleted; expires=Thu, 12-Feb-2009 05:09:50 GMT;
      path=/; domain=.facebook.com; httponly
Content-Type: text/html; charset=utf-8
X-Cnection: close
Date: Fri, 12 Feb 2010 05:09:51 GMT
Content-Length: 0

このリクエストの目的は、ブラウザがhttp://facebook.com/ではなくhttp://www.facebook.com/にアクセスできるようにすることです。なぜこれが発生する必要があるのですか？コンテンツをユーザーに直接送信しないのはなぜですか？説明は次のとおりです。

[1]国内の百度などのブラウザの検索ランキングでは、上記の2つのドメイン名を異なるドメイン名と見なします。形式化のため、アプリケーション会社は以前のドメイン名をランク付けに使用します。2つのドメイン名が使用されている場合を想像してみてください。同じ数のユーザーリクエストでは、アプリケーションプロバイダーのドメイン名検索ほど良くはありません。たとえば、1つのドメイン名で1,000人のユーザーリクエストにすべてアクセスした場合、最初のドメイン名のウェイトは500ユーザーを超えます。、および別のドメインの500ユーザー。ドメイン名。

[2] 2つのドメイン名がキャッシュされている場合、これは実際には友好的ではなく、千のハムレットではなく、諸葛亮です。あなたはそれについて考えた後に真実を理解することができます。

5）ブラウザは実際のリクエストをサーバーに送信します

この時点で、ブラウザは正しいアドレスがhttp://www.facebook.com/であることを認識しているため、サーバーによって発生した次のリダイレクト要求を送信します。

GET http://www.facebook.com/ HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Cookie: lsd=XW[...]; c_user=21[...]; x-referer=[...]
Host: www.facebook.com

リクエストのURLを除いて、ヘッダーは最初のリクエストと同じであることに注意してください。

#### 6）サーバーがリクエストを解決します

Webサーバーソフトウェア

サーバーはリクエストを受信した後、GETリクエストでそれを処理することを判断して決定します。ハンドラーは、実際には、クライアントに送信するHTMLを生成するプログラムです。上記のように、訪問はhttp://www.facebook.com/です。サーバー側の構成またはプログラムによると、http：//www.facebook.com/index.htmlやhttp://www.facebook.com/indexなどの特定のページにサフィックスなしで配置されます。もちろん、uriとして、最終的には、独自のサフィックス一致ルールに従って、サーバーがアクセスする特定のファイルに一致します。後者の場合、.htmlが追加されます。

リクエストハンドラ

パラメータとCookieを読み取るための処理を要求し、データを読み取って操作または表示し、特定のニーズに応じてhtml応答を生成する場合があります。動的なWebサイトの場合、データベースが含まれることが多く、データベースはさまざまな場所に配布されることもあり、rpc呼び出しが含まれることもあります。

7）サーバーはHTML応答を送り返します

[外部リンク画像の転送に失敗しました。ソースサイトにヒル防止リンクメカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします（img-nemeu2YR-1605454959585）（http://igoro.com/wordpress/wp- content / uploads / 2010/02 /image10.png）]

応答は次のとおりです。

HTTP/1.1 200 OK
Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,
    pre-check=0
Expires: Sat, 01 Jan 2000 00:00:00 GMT
P3P: CP="DSP LAW"
Pragma: no-cache
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
X-Cnection: close
Transfer-Encoding: chunked
Date: Fri, 12 Feb 2010 09:05:55 GMT

応答のサイズは35KBです。これは主にblobタイプで送信され、クライアントが必要とする応答本文（gzip）に従って圧縮されます。解凍後、次の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>
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-language" content="en" />
...

ヘッダー情報は、圧縮方法を提供するだけでなく、キャッシュのCache-Controlと有効期限の有効期限も説明します。同時に、HTMLのhttp-equiv = "Content-type" content = "text / html; charset = utf-8"に対応して、Content-Type：text / html; charset = utf-8が設定されていることに注意してください。、ファイルやその他の形式の代わりにhtmlを使用して解析するようにブラウザに指示します。

8）ブラウザがHTMLの表示を開始します

ブラウザにhtmlが表示されるので、完全な分析を待つ必要はありません。そのため、Webページの半分しか表示されないことがよくあります。

[外部リンク画像の転送に失敗しました。ソースサイトにヒル防止リンクメカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします（img-nCVGHixS-1605454959586）（http://igoro.com/wordpress/wp- content / uploads / 2010/02 /image6.png）]

9）ブラウザは、ブラウザに埋め込まれている他のコンテンツを解析する要求を送信します

たとえば、ブラウザにcssファイル、画像、jsコードなどが含まれている場合、次のように、対応するリソースに分析を続行するように要求します。

画像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
...

各URLは以前と同様に独自のリクエストを送信しますが、これらのリソースのほとんどは静的であるため、ブラウザは最初のアクセス後にそれらをキャッシュします。最初のアクセスを除いて、他のすべては基本的にキャッシュからのものです。もちろん、サーバーの応答これらの静的ファイルの保持期間が含まれ、それらをキャッシュする期間をブラウザに指示します。

もう1つのポイントは、Facebookがコンテンツ配信ネットワークであるCDNを使用し、CDNを使用してこれらの静的ファイルを配信することです。CDNは多くの場合、多くのCDNデータセンターにバックアップを残します。これらの静的コンテンツは、AlibabaCloudやQiniuなどの専用画像処理サーバーなどの個別のサーバーによって処理されることがよくあります。

10）ブラウザがAJAXリクエストを送信します

web2.0では、クライアントがhtmlを解析した後も、jsコードを使用して、部分的な更新、コンテンツの部分的な戻り、リアルタイムの監視などのリクエストを作成し、AJAXを介してサーバーと通信できます。

[外部リンク画像の転送に失敗しました。ソースサイトにヒル防止リンクメカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします（img-OUDeJHZ1-1605454959587）（http://igoro.com/wordpress/wp- content / uploads / 2010/02 /image12.png）]

Webサーバーの動作原理に興味がある場合は、私の作業を見て、Webサーバーの機能を簡単に実装できます。原則は、http要求を受け入れ、サーバー上で応答要求を作成することです。この応答要求は、httpに厳密に従う必要があります。プロトコル。たとえば、ヘッダーコンテンツなどは、最終的にhtmlファイルを生成してクライアントに送信します。特定のコードは、hulichao_frameworkの下のmyWebServerプロジェクトで確認できます。