1.ドメイン名解決のプロセス全体を理解する
解決プロセス：
（1）ローカルコンピューターネットワークに設定されたISPDNSまたはDNSサーバーに対してドメイン名www.baidu.comのクエリを開始します
（2）ISPDNSが要求を受信したら、キャッシュにドメイン名に対応するアドレスレコードがあるかどうかを確認します。レコードがある場合、IPアドレスは直接返されますが、このレコードは権限のないサーバーからの応答としてマークされます。
（3）DNSサーバーにこのドメイン名のレコードがない場合、ISPDNSは構成ファイル（[AM] .root-servers.net）から13のルートドメインネームサーバーのアドレスを読み取ります
（4）場所、負荷、ISPDNSに従ってルートドメインネームサーバーの1つのミラーサーバーへの要求を開始します
（5）ルートドメインネームサーバーが要求を受信すると、要求のトップレベルドメイン名がcomであることを解決し、comドメインにNSレコードを返します（通常は13ホスト）名前とIP（非表示）
（6）返された結果を受け取った後、ISPDNSは別の要求を
サーバーの1つに送信します（7）comドメインのサーバーは、要求を受け取った後でこの要求を解析します。第2レベルのドメインはbaidu.comなので、これを取得しますNSレコード、結果を返す
（8）返された結果を受け取った後、ISPDNS
はbaidu.comドメインの権限のあるサーバーへの要求を開始します（9）要求を受け取った後、baidu.comドメインの権限のあるサーバーはwwwがあることを検出しますこのホスト、およびISPDNSに戻って、このホストのIP
（10）は、それをクライアントに返し、リターン結果の受領後ISPDNS、このレコードは、そのキャッシュに格納されている
解決イラストに：
2. Webページ要求のプロセス全体を理解し、フローチャートを描く（nginxが処理する11のプロセス）
リクエストプロセス：
（1）DNS解決
-
・ブラウザのキャッシュを表示する
-
・hostsファイルキャッシュを表示する
-
・ルーターキャッシュの表示
-
・ISP解決サーバーキャッシュの表示
-
・ISP-DNSを使用して再帰的なクエリ要求を開始する
-
・クライアントは、URLに対応するIPアドレスを取得します
（2）TCPソケットを確立し、TCP接続を開始する
- ・3つのハンドシェイク
（3）サーバーの永続的なリダイレクト応答
（4）ブラウザはリダイレクトアドレスを追跡し、httpリクエストをWebサーバーに送信します
（5）サーバーはリクエストを受け入れます
（6）サーバー処理要求（Nginx）
-
・NGX_HTTP_POST_READ_PHASE完全なHTTPヘッダー後処理ステージを受信した後
-
・NGX_HTTP_SERVER_REWRITE_PHASE URI変更ステージ、リダイレクトに使用
-
・URIに応じたNGX_HTTP_FIND_CONFIG_PHASEにより、一致する前にロケーションブロック構成項目を検索します
-
・NGX_HTTP_REWRITE_PHASEは、前のステージでロケーションブロックを見つけた後にURIを変更します
-
・NGX_HTTP_POST_REWRITE_PHASEは、URLの書き換えによって引き起こされる無限ループを防止します
-
・NGX_HTTP_PREACCESS_PHASE次のステージの前の準備
-
NGX_HTTP_ACCESS_PHASEにより、HTTPモジュールは、このリクエストがNginxサーバーに入ることを許可するかどうかを決定できます
-
・NGX_HTTP_POST_ACCESS_PHASEは、サービス拒否のエラーコードをユーザーに送信します
-
・静的ファイルリソースにアクセスするためのNGX_HTTP_TRY_FILES_PHASEセット
-
・NGX_HTTP_CONTENT_PHASE HTTPリクエストコンテンツの処理の段階
-
・NGX_HTTP_LOG_PHASE要求の処理後のログフェーズ
（7）サーバーはHTML応答を返します
（8）ブラウザーは応答を受信した後、解析とレンダリングを開始します
-
・ディープトラバーサルメソッドを使用して、domツリーを構築する
-
・CSSをCSSルールツリーに解析
-
・DOMツリーとCSSOMに従ってレンダーツリーを構築する
-
・レイアウトレンダーツリー
-
・レンダーツリーの描画
3. httpプロトコルのフィールドと意味を調べる
HTTP要求/応答メッセージの構造：
・要求行・応答行
・要求ヘッダー・応答ヘッダー
・要求本文・空白行
・応答本体
要求メッセージの例
：応答メッセージの例：
（1）要求メソッド：POST、GET、PUT 、DELETE
（2）リクエストURL：http：//chapter17/user.html
（3）HTTPプロトコルとバージョン：HTTP1.1
（4）Accept：クライアントがサーバーから返されたメディアフォーマットを期待していることを示しますが、サーバーが予想されるリソースタイプ。Acceptは複数のタイプを設定し、優先度を設定します
（5）Accept-Charset：クライアントがサーバーに返すことを期待するコンテンツのエンコード形式を示します。複数のコードを指定できます。
（6）Accept-Language：クライアントが返すことを期待するコンテンツ言語を示します。
（7）Content-Type：コンテンツのメディアタイプとエンコード形式を示します。GETメソッドは通常text / html形式を使用し、POSTメソッドは通常application / x-www-form-urlencodedを使用します。
（8）Content-Language：このフィールドはAccept-Languageへの応答です。このフィールドを介して、サーバーは返された本文情報の言語をクライアントに通知します
（9）Content-Length：送信された要求/応答の本文の長さを示します。ボディがないため、GETにはこのボディがありません。本文が大きすぎる場合、このフィールドはブロック送信には必要ありません。
（10）Content-Location：サーバーが要求されたリソースの他のオプションのアドレスをクライアントに通知することを示します
（11）Content-MD5：このフィールドは、本文のコンテンツを検証するために使用されます。
（12）日付：サーバーにキャッシュがない場合は、応答メッセージの即時生成時刻を示し、サーバーにキャッシュがある場合は、応答コンテンツがキャッシュされた時刻を示します。
（13）エージ：リソースがキャッシュされた時間を秒単位で
示します。（14）期限：リソースが無効であるときにサーバーがクライアントに通知することを示します。
（15）ETag：リソースタグを示します。各リソースは、リソースの有効性を判断するために一般的に使用される複数のタグ情報を提供できます。
（16）許可：リソースがアクセスをサポートするHTTPメソッドタイプを示します。
（17）接続：接続をネゴシエートするクライアントとサーバーのプロパティを示します。一般的な値はcloseで、現在の要求が終了した後に相手に接続を閉じるように指示します。
（18）例外：要求を送信する前にサーバーに許可を求めるために使用されます。
（19）差出人：通常、要求元の電子メールアドレスをマークするために使用されます。これは、要求に責任者を割り当てることと同じです。
（20）ホスト：RFCプロトコルは、すべてのHTTP要求がホストヘッダーを運ぶ必要があることを規定しています。値がない場合でも、空の文字列を追加する必要があります。要求を開始したホストのアドレスを示します。
（21）最終変更日：リソースの最終変更時刻をマークします。
（22）IF-Modified-Since：ブラウザーがサーバーに静的リソースを要求するとき、ブラウザーがローカルにキャッシュを持っている場合、このヘッダーを運び、値はリソースのLast-Modified時間であり、サーバーにそれがあったかどうかを尋ねます変更。
（23）範囲：クライアントがリソースの一部を要求するときに指定される要求バイト範囲を示します。
（24）Content-Range：サーバーがリクエストに応答したときに、全体的なリソースブロック内の送信された本文データのバイト範囲を示します。
（25）場所：サーバーがクライアントに応答メッセージ302を送信するときに、ターゲットURLをポイントする
ことを示します（26）Max-Forwards：ゲートウェイまたはプロキシの数が制限されていること、つまり、転送の最大数を示します。
（27）リファラー：リクエストの起点、つまり現在のページリソースの親ページのURIを表す、同一生成元制限戦略で一般的に使用されます。リファラーをトレースすることで、リソースページ間に複雑なジャンプチェーンを描画できます。
（28）サーバー：サーバー関連のソフトウェア情報を返し、現在のHTTPサービスがXYZソフトウェアによって提供されていることをクライアントに通知するために使用されます。
（29）User-Agent：現在のユーザーエージェント情報を保持します。通常、ブラウザー、ブラウザーカーネル、オペレーティングシステムのバージョンとモデル情報が含まれます。
（30）Transfer-Encoding：パケットによって送信されたBody情報に応答するときに、Bodyデータにどのような変換を採用する必要があるかを示します。
（31）アップグレード：サーバーがクライアントに伝送プロトコルのアップグレードを推奨することを示します
（32）変更：このフィールドはキャッシュ制御に使用され、このヘッダーを要求パケットに追加すると、異なるキャッシュユニットを使用して異なる変更パラメーターへの応答をキャッシュサーバーに指示できます。
（33）Via：このフィールドは、要求が通過するゲートウェイルーティングノードをマークするために使用され、ゲートウェイ情報を示します。
（34）警告：エラーコードやエラーの説明など、追加の警告情報を応答に追加するために使用されます。
（35）WWW-Authenticate：401 Unauthorizedエラーコードが返されたときに運ばれる必要があるヘッダーです。このヘッダーはクライアントにチャレンジを伝え、クライアントがこの質問への回答を運んでサーバーにターゲットリソースへのアクセスを継続するよう要求する必要があることをクライアントに通知します。
（36）許可：アクセスに特別な許可が必要な一部のリソースでは、クライアントはリクエストでユーザー名とパスワードの認証情報を提供する必要があります。WWW-Authenticateへの応答です
（37）cache-control：このフィールドは、要求と応答の両方に使用できます。
フィールドの値がno-cacheの場合、キャッシュは許可されません。リクエストの場合、サーバーはキャッシュコンテンツを使用して直接返さないでください。レスポンスの場合、クライアントはレスポンスのリソースコンテンツをキャッシュしないでください。
フィールドの値がストア以外の場合は、リクエスト/レスポンスデータを他の場所に保持しないことを意味します。この種の情報は機密情報であり、揮発性に保つ必要があります。
フィールドの値が変換されていない場合、それは相手がデータを変換してはならないことを意味します。
フィールドの値がonly-if-cachedの場合、それはリクエストヘッダーでのみ使用され、コンテンツがキャッシュされている限りリロードしないようサーバーに指示します。
フィールドの値がmax-staleの場合、それはリクエストヘッダーでのみ使用され、クライアントがサーバーに有効期限が切れたキャッシュのリソースコンテンツを返すことを許可しますが、最大有効期限は制限されます。
フィールドの値がmin-freshである場合、それはリクエストヘッダーでのみ使用され、クライアントがサーバーの期限切れが近づいているリソースコンテンツを制限することを示します。
フィールドの値がpublicの場合、それは応答ヘッダーでのみ使用され、クライアントが応答情報のキャッシュを許可され、他のユーザーが使用できることを示します。
フィールドの値がプライベートの場合、それは応答ヘッダーでのみ使用されます。つまり、クライアントは自身の使用のために応答情報をキャッシュすることのみが許可され、他のユーザーと共有することはできません。
4. HTTPリクエストメソッドと、返されたステータスコードのタイプと意味を学ぶ
1xx：メッセージ
100続行サーバーはリクエストの一部のみを受信しましたが、サーバーがリクエストを拒否しなかった場合、クライアントは残りのリクエストを送信し続ける必要があります
101スイッチングプロトコルサーバースイッチングプロトコル、サーバーはクライアントのリクエストに従って別のプロトコルに切り替えます
2xx：成功した
200 OKリクエストが成功した
201作成されたリクエストが作成され、新しいリソースが作成された
202 Accepted処理のリクエストは受け入れられたが、処理は完了していない
203非信頼できる情報
ドキュメントが正常に返されたが、一部の応答ヘッダーが不正解です。ドキュメントのコピーが使用されているため、
204コンテンツがありません新しいドキュメントがないため、ブラウザは引き続き元のドキュメントを表示する必要があります。ユーザーが定期的にページを更新し、サーバーがユーザーのドキュメントが十分に新しいと判断できる場合、このステータスコードは役立ちます
。205コンテンツのリセット新しいドキュメントはありませんが、ブラウザはフォームをクリアするようにブラウザに強制的に表示させるために、表示するコンテンツをリセットする必要があります。入力コンテンツ
206部分コンテンツクライアントがRangeヘッダーを含むGETリクエストを送信し、サーバーがそれを完了しました
3xx：リダイレクト
300複数の選択肢複数の選択肢、リンクリスト、ユーザーは宛先に到達するための接続を選択でき、最大5つのアドレスを許可
301永久に移動要求されたページは新しいURLに転送されました
302見つかりました要求されたページは一時的に転送されました新しいURL
303 See Otherリクエストされたページは別のURLの下にあります。
304 Not Modifiedドキュメントは期待どおりに変更されませんでした。クライアントのバッファされたドキュメントは条件付きリクエストを開発しました（通常、顧客が指定した日付より新しいドキュメントのみを必要とすることを示すIF-Modified-Sinceヘッダーを提供します）。バッファリングされたドキュメントは引き続き使用できます。
305プロキシの使用クライアントから要求されたドキュメントは、Locationヘッダーで指定されたプロキシサーバーから抽出
され、以前のバージョンで使用される必要がありますこのコードは現在使用されていませんが、コードは残っています。
307一時リダイレクト要求されたページは一時的に新しいURLに転送されました
4xx：クライアントエラー
400 Bad Requestサーバーはリクエストを理解できませんでした
401 Unauthorizedリクエストされたページにはユーザー名とパスワードが必要です
402支払いが必要ですこのコードはまだ利用できません
403 Forbiddenリクエストされたページにはユーザー名とパスワードが必要です
404 Not Foundサーバーはリクエストされたものを見つけることができませんページ
405方法は許可されていない要求で指定されたメソッドを許可されていない
サーバー406は許容できないクライアントで受け入れることができないことにより、生成された応答で
リクエストが処理されるように、407プロキシ認証が必要ユーザーが最初に認証用のプロキシサーバーを使用しなければならない
408要求のタイムアウト要求サーバーの待機時間を超えています
409競合競合のため、要求を完了できません
410 完了要求されたページを利用できません
411長さが必要です "コンテンツの長さ"が定義されていません。そのようなコンテンツサーバーが要求を受け入れない場合は
412前提条件が要求で失敗しました前提条件はサーバーによって失敗として評価されます
413リクエストエントリが大き
すぎますリクエストのサイズが大きいため、リクエストは受け入れられません414 Request-url Too Longリクエストは長いURLのために受け入れられません
415 U nsupported Media Typeメディアタイプがサポートされていないため、サーバーはリクエストを受け入れません
416サーバーはリクエストでクライアントによって指定された範囲
417予期された失敗を満足できません
5xx：サーバーエラー
500内部サーバーエラー要求が完了していない、サーバーで予期しない状況が発生した
501実装されていない要求が完了していない、サーバーが要求された機能をサポートしていない
502不正なゲートウェイ要求が完了していない、サーバーが上流サーバーから無効な応答を受信した
503 Service Unavaliableリクエストが完了しない、サーバーが一時的に過負荷またはダウンしている
504ゲートウェイタイムアウトゲートウェイタイムアウト
505 HTTPバージョンがサポートされていないサーバーは、リクエストで指定されたHTTPプロトコルバージョンをサポートしていません
