URLを入力するページをロードするから全体のプロセス

シンプルな発言から：

1. DNS名前解決;
2. TCP接続が確立され;
3.送信するHTTPリクエスト、
4を返す応答結果;
5.閉じるTCPコネクション;
6.ブラウザがHTMLを解析し、
7レンダリングブラウザのレイアウト。

私たちは、基本的にはこのことを知っているが、詳細は内側に、ほとんどの人はまだ非常に明確ではない、我々は、この上で詳しく説明します：

なぜ、DNSの名前解決を行いますか？
ほとんどのネットワーク通信は、TCP / IPに基づいており、およびTCP / IPはIPアドレスに基づいて、IPアドレスは、ネットワーク上で通信し、ドメイン名を認識できないために、コンピュータのような「202.96.134.133」として識別することができます。私たちは、サイトに10個の以上のIPアドレスを思い出すことができないので、私たちは、ドメイン名を入力して、ブラウザのアドレスバーでより多くのように、サイトなどを訪問した際、「DNSサーバ」と呼ばれるものがあるので、あなたは、目的のページを見ることができますコンピュータは自動的に私たちのドメイン名「翻訳」は、対応するIPアドレスとなり、その後、ウェブページに対応するIPアドレスを持ち出します。
*
インターネット・プロトコル（インターネットプロトコルスイート）は、ネットワーク通信モデルだけでなく、全体のネットワークトランスポートプロトコルファミリ、インターネットの基本的な通信インフラです。これは、多くの場合、TCP / IPプロトコルスイートとして知られている（英語：TCP / IPプロトコルスイート、またはTCP / IPプロトコル）、TCP / IPと呼ばれます。そのためのプロトコルの2つのコアプロトコルファミリ：TCP（伝送制御プロトコル）とIP（インターネット・プロトコル）、採用基準の最初の家族のために。

、DNSの名前解決
ドメイン名がサーバーに対応したところ、我々は実際には、ブラウザにURLを入力するには、私たちが望むページのコンテンツサーバに要求したいと思い、私たちは、最初にすべてのブラウザを確認する必要があります。この作業に対応するDNSサーバのIPアドレスがDNSサーバーによって行われます。
クライアントが入力したドメインのアドレスを受信した後に、それは最初にローカルのhostsファイルに行って、対応するドメイン名がファイルに存在しているかどうかを確認、IPとの対応もしそうならない場合は、その後、そのIPアドレスに要求を送信DNSサーバーにアクセスしてください。平均的なユーザーはほとんどhostsファイルを変更編集しません。

DNSサーバーの階層

ブラウザのクライアントは、ローカルのDNSサーバがドメイン名www.cnblogs.com DNSクエリーメッセージが含まれているに送信します。ローカルDNSサーバーがルートDNSサーバへの問い合わせメッセージを転送し、ルートDNSサーバーは、comサフィックスは、ローカルDNSサーバにIPアドレスcomDNSサーバーを返すことに気づきました。ローカルDNSサーバは、comDNSサーバに再びcomDNSサーバ通知www.cnblogs.comサフィックスをクエリ要求を送信し、権威DNSサーバーの応答のIPアドレスとドメイン名の責任です。最後に、www.cnblogs.comメッセージのIPアドレスを含むローカルDNSサーバの応答がクライアントに送信されます。
地元の再帰クエリに属するサーバーへのクライアント、およびDNSサーバ間の相互作用からの反復クエリの一部です。
通常の状況下では、ローカルキャッシュDNSサーバーは、すでにサーバのアドレスをcomDNSので、この手順は必要ありませんルートネームサーバを要求します。

DNSキャッシュ：

ブラウザのキャッシュ、システムキャッシュ（hostsファイル）、ルータキャッシュ、IPSサーバ：次されていることから、ブラウザを注文からの距離、（侵入防止システム（IPS：侵入防止システム）は、コンピュータネットワークのセキュリティ機能である）キャッシュ、根ドメインネームサーバのキャッシュ、トップレベルドメイン・サーバ・キャッシュ、プライマリドメインネームサーバのキャッシュ。

2つのTCP接続、
料金、食事が最終的にサーバーのIPを得たターン、次のステップは当然、サーバにリンクされています。TCP接続の場合、クライアントとサーバは、と言うことはバインドされている「スリーウェイハンドシェイク。」

最初のハンドシェイク：接続が確立されます

　　クライアントは、接続要求セグメント、SYN（）シーケンス番号を同期する（シーケンス番号を同期化）の値が1に設定され、xのシーケンス番号を送信します。クライアントは、サーバーの確認を待って、SYN_SEND状態になります。

第二のハンドシェイク：サーバはSYNセグメントを受信します

　　サーバは、肯定応答番号（確認応答番号）にX + 1（シーケンス番号は、+ 1）を設け、クライアントは、このSYNセグメントを検証する必要がSYNセグメントを受信します。それと同時に、彼はまた、SYN要求情報を送信したいと思い、SYN値が1に設定され、シーケンス番号がyに設定します。セグメント（即ち、セグメントSYN + ACKパケット）に上記サーバ側情報の全てを、クライアントに送信され、サーバは、状態SYN_RECVに入ります。

サードハンドシェイク：クライアントは、SYN + ACKセグメントを受け取ります

　　SYN + ACKパケットクライアントは、TCPを完了し、セグメントが送信された後ESTABLISHED状態に、サーバーへのクライアント側とサーバー側のACKセグメントY + 1を送信するために、サーバーのセグメント確認番号が提供されて受信した後、 3ウェイハンドシェイク。

完全な3ウェイハンドシェイク、クライアントとサーバがデータの送信を開始し、その過程で、いくつかの重要な概念があります。

接続なしキュー：スリーウェイハンドシェイクプロトコルは、サーバは、各クライアントがサーバーのSYNパケットを受信したことを示しているエントリを開くためのキューがあり、キューに接続されていない顧客に確認をSYNパケット（SYN = j）を維持していません、確認のパッケージの顧客を待っています。これらのエントリはESTABLISHED（確立）状態にサーバー、エントリを削除し、サーバーがクライアントの確認パッケージを受信したとき、SYN_RECV状態で識別されるサーバーに接続されています。バックログパラメータ：受信キューの最大数が接続されていない表します。
SYN-ACKの再送回数：再送信すると、サーバーは、クライアントが確認パケット、サーバー最初の再送信を受信していない場合には、顧客の確認パック、第二の再送信を受信するためにはまだいくつかの時間を待って、SYN-ACKパケットの送信を完了しました再送信の最大数が、所定のシステムの数を超えると、システムは接続キューの接続情報を削除したことはありません。各再送待ち時間は必ずしも同じではないことに注意してください。
：生存時間が接続されていません接続キューエントリを参照するには、最も実行可能な時間ではありません、すなわち、サービスはメッセージが無効の最大時間であることを確認するために、SYNパケットから受信され、すべての再送要求パケットの時間値が最も長い待ち時間です時間の合計。時には、我々はまた、SYN_RECV生存時間、生存時間がタイムアウト時間を接続されていなかったと呼ばれます。

なぜスリーウェイハンドシェイクである
第四版では「コンピュータネットワーク」は「3ウェイハンドシェイク」を強調する目的は、突然のサーバーに転送期限切れの接続要求セグメントを防ぐためである謝Xirenで、エラーとなったが
、「接続要求に失敗しましたこのような場合にセグメント」を生成する：最初のクライアントが接続要求メッセージセグメントが失われていない送信するが、いくつかのネットワーク内での滞留時間をノード、後続の接続の遅延放出をもたらしますサーバーに到達するまでの時間。これ自体は、すでにセグメントの障害です。サーバが接続セグメントの障害が発生した後、この要求を受けた。しかし、それは再びクライアントによって発行された新しい接続要求のために間違っています。だから、クライアントへの確認メッセージのセグメントで、接続を確立することに合意しました。「スリーウェイハンドシェイク」は、限り、サーバーの確認として、新しい接続が確立されていることを前提としないでください。今は、クライアントが接続の確立を要求していないこと、したがって、確認サーバを無視しないだろう、それがサーバーにデータを送信しません。しかし、サーバーは、新しいトランスポート接続が確立されており、クライアントデータを待つために送信されたことを考えました。このように、サーバー上のリソースの多くが無駄に。「スリーウェイハンドシェイク」のアプローチは、この現象を防ぐことができます。例えば、状況のその種は、クライアントがサーバーを確認する確認を送信しません。サーバが確認を受信しないので、私たちは、クライアントが接続を確立するために必要されていないことを知っています。"

第三に、HTTPリクエストを開始

HTTP -ハイパーテキスト転送プロトコル、ハイパーテキスト転送プロトコルは、TCPコネクションの確立に状態であり、全体の基本的なワークフロークライアントは、HTTPリクエストを送信し、リソースと要求しているクライアントの操作は、アクセスしたいですサーバがリクエストを受信した後、サーバはリクエストの処理を開始し、サーバリソースへの要求のアクセスに応じて適切な処置を行い、最終的には結果をクライアントにHTTPレスポンスを送信することもできます。要求の一つは、最後には、サーバー上のログエントリを追加する事になりますと、トランザクションと呼ばれる応答を完了するために開始します。
要求ライン（リクエストライン）、リクエストヘッダ（ヘッダ）、これらの四つの部分の空白行と要求データ：httpリクエストは、リクエストメッセージを、開始します。

1.リクエストライン
スペースで区切られた3つのフィールド、の要求フィールド、URL HTTPプロトコルバージョンフィールド、及びフィールドの方法によって要求ライン。たとえば、GET /index.htmlがHTTP / 1.1。
POST /手がかり/ get_clues_detail HTTP / 1.1
GET、POST、HEAD、PUTとHTTPプロトコルの要求方法 DELETE、OPTIONS、TRACE、CONNECT。

一般的には、次のとおりです。

GET：コンプリート要求リソース（共通）
HEADを：のみ応答ヘッダを要求する
形式（共通）提出：POST
PUT：ファイルをアップロードする（WebDAVを）（ただし、ブラウザがこのメソッドをサポートしていません）
DELETE：（WebDAVは）削除
オプション：要求されたリソースを返します。サポートされるメソッドの
TRACE：（ブラウザによって発行することはできません）プロキシの中央を通るリソース要求の追求

2.リクエストヘッダ

要求キー/値のペアからのヘッダ、1行につき1つの対、及びキー値コロン「：」分離しました。リクエストヘッダはクライアントの要求に関するサーバ情報を通知し、典型的なリクエストヘッダがある:,

受け入れ：コンテンツタイプリストクライアントが認識しています。
受け入れエンコード：文のブラウザは、符号化タイプをサポートしています。
Cache-Control：キャッシュメカニズムの要求を指定し、応答が続きます。
接続：決定現在のトランザクションが完了した後、ネットワーク接続を閉じます。値が「キープアライブ」である場合は、サーバーに同じ要求が接続に進めることができるように、永続的なネットワーク接続は、閉じられていません。
ホスト：同じIPアドレスで複数のドメイン名を許可する要求のホスト名、仮想ホストという。
リファラー：処理のためKeyihuodeに情報の一部を取るために、サーバからのリンク先のページのサーバーに伝えます。
アップグレード・安全でない-要求：ブラウザが自動的にエラーが発生せず、HTTP、HTTPSに直接アップグレードするためのリソースを大量に含まれているHTTPS、HTTPのWebページへのHTTPからの要求をアップグレードすることができます。
User-Agent：リクエストを生成し、ブラウザの種類。

3.空行

最後のリクエストヘッダは空白行、キャリッジリターンおよび改行を送信した後、通知サーバは、もはや次のリクエストヘッダを有していません。

前記要求データ
要求メソッドGETデータを使用するが、POST処理の使用されません。POSTメソッドは、フォームに必要事項を記入し、顧客を必要とするアプリケーションに適しています。要求データに関連付けられた、リクエストヘッダは、最も一般的にContent-TypeとContent-Lengthを使用しています。

第四に、結果はに応答して返さ

ステータスライン、各ヘッド、応答体：また、HTTPレスポンスは、3つの部分、すなわち、から構成されています。
HTTP / 1.1 200 OKです
。1.ステータス行
HTTP-バージョンステータスコード妥当フレーズCRLF

ここで、HTTP-バージョンHTTPプロトコルサーバのバージョンを示し、理由-フレーズステータスコードのテキスト説明を表すステータスコードは、サーバが応答ステータスコードを送り返す表します。3桁のステータスコード、定義されたカテゴリに応じて、第1の数、及び5つの可能な値があります。

1XX：指示情報は、 -要求が受信されたことを示し、処理は継続します。
2xx：成功-受け入れ、理解し、要求が正常に受信されたことを示します。
300番台：リダイレクション-要求を満たすためには、さらなるステップを行かなければなりません。
4XX：クライアントエラー-リクエストに構文エラーが含まれているかの要求を達成することができません。
5xxの：サーバー側のエラー-サーバーが正当な要求を達成するために失敗しました。
一般的なステータスコードは、ステータスは、以下の説明に記載しました。

200 OK：クライアント要求が成功しました。
301：永久リダイレクトは、ロケーション応答ヘッダーの値がまだ現在のURL、従って隠されたリダイレクトです。
302：一時的なリダイレクト、明示的なリダイレクトは、場所のレスポンスヘッダが新しいURLです。
304：ローカルキャッシュサーバのリソースファイルを比較すると、何も変更を発見した、サーバがブラウザに指示304ステータスコードを返すときのように、そのまま変更されていない、あなたは、ローカルリソースを直接使用することができ、リソースを要求しません。
400不正な要求：クライアントは、構文エラーを要求し、それがサーバーによって理解することはできません。
401不正：不正な要求、ステータスコードは、WWW-Authenticateヘッダ・フィールドで使用されなければなりません。
403は、禁止：サーバーは要求を受信しますが、サービスを提供することを拒否しました。
404が見つかりません：要求されたリソースは、たとえば、存在しません：間違ったURLを入力してください。
500内部サーバーエラー：予期しないサーバーエラーが発生しました。
502：不正なゲートウェイは、プロキシサーバーの前にバックエンドサーバーに接続できない表示されます
503サーバーを使用できません：サーバーは現在、クライアントの要求を処理できない、それは例えば、一定期間後に正常に戻ることがあります。HTTP / 1.1 200 OK（CRLF ）。
504：ゲートウェイタイムアウトこれは、エージェントがバックエンドサーバにリンクすることができますが、指定された時間内にバックエンドサーバーがプロキシサーバーに応答しません

2頭の応答
としては、Chromeブラウザのヘッドの応答です。

キープアライブ特性使用して接続
のContent-Length：2284のContent-Length WEBサーバは、次のような長さやオブジェクトブラウザ自身の応答の大きさ、伝え
コンテンツエンコードリソース圧縮のgzipの方法使用して
コンテンツタイプのMIMEタイプをされたhtmlの種類、文字セットをUTF-8は、ある
日の日付応答
Webサーバーのサーバーが使用する
転送エンコード：チャンクチャンク転送エンコードは、クライアントアプリケーション（通常はWebブラウザ）を許可するようにHTTP Webサーバーによって送信されたHTTPでのデータ転送メカニズムであり、データが複数の部分に分割されてもよい、1.1（HTTP / 1.1）でのみHTTPプロトコルバージョン転送エンコードをチャンク
：HTTPレスポンスヘッダと要求ヘッダテーブルhttp://tools.jb51.net/table/http_headerは
リンクを維持
完全にHTTP要求の後、サーバーはすぐにクライアントとの接続を切断しません。接続にHTTP / 1.1の場合：キープアライブがデフォルトで有効になって、それが再確立接続が上昇するスロースタートコストを必要とせずに、すぐに到着後、新たな要求を処理し、ネットワークのスループットを向上させるために持続的な接続を表します。nginxのリバースプロキシソフトウェアは、デフォルトの持続的な接続時間が75秒以内に新たに到着した要求が存在しない場合、クライアントとの接続を切断、75秒です。同時に、ブラウザは、サーバーのTCPキープアライブプローブに送信する45秒ごとに受信された無ACK応答がない場合は、サーバーへのアクティブな接続が切断され、TCP接続の状態を判断します。HTTPキープアライブ、ということと、TCPキープアライブキープアライブメカニズムは親切ですが、彼らは完全に異なっている、アプリケーション層、トランスポート層の演技の役割が注意してください。

ファイブは、TCP接続を閉じます

最初の波：クライアントは別れたいです

　　クライアントが接続を閉じたいと仮定し、クライアントはFINフラグが1つのパッケージで送信する（FIN = 1、SEQ = X）、彼は何もデータが送信されないことができなかったが、それでもデータを受け取ることができると述べました。

　　送信が完了すると、クライアントはFIN_WAIT_1状態になります。

第二波：サーバもばらばらにしたいです

　　クライアントサーバーの確認FINパケットは、確認応答パケットを送信する（ACK = 1を、ACKnum = X + 1）は、彼らの要求は、クライアントが接続を閉じる受け取っ示しますが、接続を閉じる準備ができていません。

　　送信が完了すると、クライアントはサーバーが接続を閉じるのを待っている、確認応答パケットがFIN_WAIT_2状態になっ受け取った後、サーバは、CLOSE_WAIT状態になります。

第三の波：サーバが解散する準備ができています

　　サーバが接続を閉じるために準備ができたときにクライアント側に接続要求を送信し、FINを1（FIN = 1、SEQ = Y）に設定されています。

　　送信が完了すると、サーバはクライアントからの最終のACKをLAST_ACK状態、待機に入ります。

第四の波：別れます

　　クライアントがサーバからの要求を受信閉じ、確認応答パケット（ACK = 1、ACKnum = Y送る + 1）、及びパケット再送が発生することが必要とACKを待って、TIME_WAIT状態に入ります。
　　サーバは、確認応答パケットを受信した後、接続が閉じられ、CLOSED状態に入ります。
　　クライアントが2MSL（2MSL、2最大セグメント有効期間を待機した後）、 CLOSED状態に入り、クライアントは接続を閉じ、サーバーが実際に閉じていることを確認し、応答を受信しませんでした。

第六に、ブラウザは、HTMLを解析し、

サーバがHTTPプロトコルによって送信されたブラウザのHTTPレスポンスを受信した後、次のように、処理エンティティの受信部分のHTTPレスポンスのHTMLテキスト、すなわち、分析手順は以下のとおりです。

ドキュメントオブジェクトモデル（DOM）
DOMツリーを生成するページタグを解析するには、
DOMツリーの手順を生成：
　　バイト文字→→→→ノードタグDOMツリー
　　バイト→文字→トークン→は→ノードオブジェクトモデルの
　　生成規則DOMツリーの
　　構築プロセスのDOMツリーがあります深いトラバーサル：現在のノードのすべての子ノードが唯一の良い後の現在のノードの次の兄弟を構築するために構築されています。

CSSオブジェクトモデル（CSSOM）
のstyle.css：ブラウザDOMプロセスでは、この単純なページを構築するためには、数字は、外部CSSスタイルシートを参照して、文書の頭の中でリンクタグに会いました。ページをレンダリングするためにリソースを使用する必要性を見越し、それは資源のための即時の要求を送信し、次を返します。

本体 { フォントサイズ：16pxに } 
、P { フォント重量：太字 } 
スパン { 色：赤 } 
Pスパン { 表示：なし } 
IMG { フロート：右 }

その上に集中するためにCSS、HTMLの開発者に対処し、責任デザイナーを：私たちは、直接HTMLマークアップ宣言のスタイル（インライン）内が、CSSは私たちが別の懸念として設計し、処理するのに役立ちますHTMLコンテンツとは独立してみましょうことができます。
HTMLを扱うときと同じように、我々はいくつかのブラウザが理解し、物事に対処することができます受信するCSSルールを変換する必要があります。したがって、我々は、プロセスのHTML、CSSとHTMLだけではなくてを繰り返します。

その後、CSSの文字にバイト、そして最後と呼ばれる「CSSオブジェクトモデル」（CSSOM）ツリー構造にトークンをノード、リンクに変換されます。

ブラウザは、CSSルールツリーを生成し、DOM HTMLのDOMツリー、CSSOMのツリーデータ構造に解析され、ブラウザのCSSコードを生成したツリー構造にデータを解析します。

DOMツリーとCSSルールツリーは、ツリーをレンダリング生成するために組み合わせます。

表示：ノードのどれもツリーをレンダリングするために追加されませんし、可視性：隠された意志。
•表示：隠された要素は、元の空間に対応するが、要素を圧迫しません。
•可視性：元の空間と要素を占めるように対応する隠された要素
がどれも良くありません：ノードがショーの始まり、ディスプレイに設定がされていない場合ので。

七、ブラウザのレイアウトのレンダリング

DOMを構築するために、HTMLの構文解析ツリー - ツリーをレンダリング描く> - >レイアウトツリーをレンダリング - >建設ツリーがレンダリング

ここでは理解を容易にするために、いくつかの概念を説明します：

DOMツリー：ブラウザは、ツリーデータ構造にHTMLを解析します。
CSSルールツリー：CSSブラウザはツリー構造にデータを解析します。
ツリーをレンダリング：組み合わせたDOMツリーとCSSOMをレンダリング生成します。
レイアウト（レイアウト）：レンダーツリーを使用すると、ブラウザは、画面内の各ノードの位置を計算するために、それによって、各ノードならびにそれらの所属のCSS定義をノードページを知っていなければなりません。
塗装（図面）：コンテンツが画面上に描画され、グラフィックスカードによって規則に従って計算しました。
リフロー（リフロー）：ブラウザがビットの変更があった部分を見つけるのレイアウトに影響を与え、あなたは戻ってレンダリングを再する必要があり、専門家は、ロールバックプロセスは、リフローと呼ばれていると言います。このルートフレームから再帰が停止して開始し、すべてのノードが順次算出形状および位置をリフローします。リフローはほとんど避けられません。画面このようなツリーを折るなどの効果、いくつかの、拡大（本質的要素を表示し、隠された）、などで今人気の、リフローブラウザの原因となります。マウスオーバー、限りこれらの行為は、フットプリントの特定の要素の特性の変化、位置決め方法、余白や他のページを引き起こしたとして、それは内部の原因となり、さらには、ページ全体を再レンダリングを中心に......上をクリックします。通常、我々は、彼らのすべてがお互いに影響を与え、リフローするコードのどの部分最後にブラウザを推定することはできません。
リペイント（再描画）：要素、テキストの色、境界線の色の背景色を変更し、それが周囲または内部のプロパティのレイアウトに影響を与えていない場合、画面の一部が再描画されるが、構成要素の形状が変更されていません。

注意：

表示：ノードが表示に設定され、ショーの始まりでない場合、したがって、隠されます：どれも優れていないノードのいずれもツリーをレンダリングするために添加されず、視認されません。
表示：どれもリフローをトリガしません、と可視性：位置に変化が見られないので、隠されただけで、再描画をトリガーします。
いくつかのケースでは、このようなスタイル要素を修正するよう、ブラウザがすぐにリフローまたは一度再描画が、そのような操作の数を蓄積し、その後も非同期リフローまたは増分非同期リフローと呼ばれるリフローを行いません。しかし、いくつかのケースでは、ウィンドウのサイズを変更するなど、フォントのデフォルトページを変更します。これらの操作のために、ブラウザは、すぐにリフローになります。

HTMLブラウザは、DOMツリーDOMツリーの構築プロセスに解析される深いトラバーサルです：現在のノードのすべての子ノードは、唯一の良い後に現在のノードの次の兄弟を構築するために構築されています。
CSSはCSSのルールツリーに解析されます。
DOMツリーを構築し、CSSOMレンダリングツリーです。注意：レンダリングツリーで物事を置くなし必要はありません：レンダリングツリーは、ツリーは同じDOMツリーではない、またはヘッダー表示のようないくつかのようにレンダリングされます。
ツリーをレンダリングすると、ブラウザはノードページのCSSの定義がある知っている必要があり、各ノード並びにその所属。定義により、レイアウトと呼ばれ、次のステップは、画面内の各ノードの計算された位置です。
次のステップ、すなわち描画ツリートラバーサルをレンダリングし、各ノードのUIバックエンド層を使用して描かれたことです。

　注意：

　　このプロセスは、より優れたユーザー体験するためには、レンダリングエンジンは、画面上のコンテンツを提示し、すべてのHTMLを解析された後にレンダリングツリーの構築やレイアウトに行くのを待つしないように可能な限り早期になり、上記の緩やか完了です。残りはまた、ネットワーク経由でコンテンツをダウンロードすることができる一方でそれは、コンテンツの表示部に完全な分析内容の一部です。

パフォーマンスの最適化は、再編成を再描画します：

（1）Reflow（回流/重排）：当它发现了某个部分发生了变化影响了布局，渲染树需要重新计算。

（2）Repaint（重绘）：改变了某个元素的背景颜色，文字颜色等，不影响元素周围或内部布局的属性，将只会引起浏览器的repaint，根据元素的新属性重新绘制，使元素呈现新的外观。重绘不会带来重新布局，并不一定伴随重排；
Reflow要比Repaint更花费时间，也就更影响性能。所以在写代码的时候，要尽量避免过多的Reflow。

reflow的原因：

（1）页面初始化的时候；

（2）操作DOM时；

（3）某些元素的尺寸变了；
（4）如果 CSS 的属性发生变化了。

减少 reflow/repaint

（1）不要一条一条地修改 DOM 的样式。与其这样，还不如预先定义好 css 的 class，然后修改 DOM 的 className。

（2）不要把 DOM 结点的属性值放在一个循环里当成循环里的变量。

（3）为动画的 HTML 元件使用position： fixed 或 absoult 的，那么修改他们的 CSS 是不会 reflow 的。
（4）尽量不要使用 table 布局。因为可能很小的一个小改动会造成整个 table 的重新布局。

其他

一。根据HTTP标准，HTTP请求可以使用多种请求方法。
HTTP1.0定义了三种请求方法： GET, POST 和 HEAD方法。
HTTP1.1新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。
1.GET
请求指定的页面信息，并返回实体主体。
2.HEAD
类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头
3.POST
向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
4.PUT
从客户端向服务器传送的数据取代指定的文档的内容。
5.DELETE
请求服务器删除指定的页面。
6.CONNECT
HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
7.OPTIONS
允许客户端查看服务器的性能。
8.TRACE
回显服务器收到的请求，主要用于测试或诊断。

二。dsn缓存失效问题:

https://blog.csdn.net/lock_xuanqing/article/details/80334579

三。DNS递归查询与迭代查询:
1.递归查询:
一般客户机和服务器之间属递归查询，即当客户机向DNS服务器发出请求后,若DNS服务器本身不能解析,则会向另外的DNS服务器发出查询请求，得到结果后转交给客户机；
2.迭代查询(反复查询):
一般DNS服务器之间属迭代查询，如：若DNS2不能响应DNS1的请求，则它会将DNS3的IP给DNS2，以便其再向DNS3发出请求；

举例：比如学生问老师一个问题，王老师告诉他答案这之间的叫递归查询。这期间也许王老师也不会，这时王老师问张老师，这之间的查询叫迭代查询！

递归是用户只向本地DNS服务器发出请求，然后等待肯定或否定答案。而迭代是本地服务器向根DNS服务器发出请求，而根DNS服务器只是给出下一级DNS服务器的地址，然后本地DNS服务器再向下一级DNS发送查询请求直至得到最终答案。

URLを入力するページをロードするから全体のプロセス

おすすめ