ブラウザのアドレスの URL を入力して Enter キーを押す手順は、次の手順に分かれています。
1. URL を解析して URL が正当かどうかを判断し、ブラウザは現在の URL のキャッシュがあるかどうかを確認し、キャッシュの有効期限が切れているかどうかを比較します。
2. DNS は URL に対応する IP を解決します。
3. IP に基づいて TCP 接続を確立します。（三者握手）
4. HTTP がリクエストを開始します。
5. サーバーはリクエストを処理し、ブラウザは HTTP レスポンスを受信します。
6. ページをレンダリングし、DOM ツリーを構築します。
7. TCP 接続を閉じます。(4回手を振る)
URL (Uniform Resource Locator) は、一般に「URL」として知られる、インターネット上のリソースを見つけるために使用されます。
URL は次の構文規則に従います: scheme://host.domain:port/path/filename
スキーム- インターネット サービスのタイプを定義します。一般的なプロトコルは http、https、ftp、file で、その中で最も一般的なタイプは http で、https は暗号化されたネットワーク送信用です。
host - ドメイン ホストを定義します (http のデフォルトのホストは www)。
ドメイン- w3school.com.cn などのインターネット ドメイン名を定義します。
port - ホスト上のポート番号を定義します (http のデフォルトのポート番号は 80)。
path - サーバー上のパスを定義します (省略した場合、ドキュメントは Web サイトのルート ディレクトリに存在する必要があります)。
filename - ドキュメント/リソースの名前を定義します。
1. URL を分析し、現在の URLDNS キャッシュ レコードを見つけて、キャッシュの有効期限が切れているかどうかを比較します。
まず、URL が解析され、使用される送信プロトコルと要求されたリソースのパスが分析されます。入力された URL のプロトコルまたはホスト名が無効な場合、アドレス バーに入力された内容が検索エンジンに渡されます。問題がなければ、ブラウザは URL 内に不正な文字がないかチェックし、不正な文字がある場合は不正な文字をエスケープしてから次の処理に進みます。
/ ? : のような文字は URL によって特別な意味として理解されるため、これらの文字がランダムに表示されることはありません。
たとえば、パラメータでこれらの特殊文字が必要な場合は、最初に特殊文字をエスケープする必要があります。
エスケープ規則: トランスコードする文字を 16 進数に変換し、右から左に 4 桁 (4 桁未満は直接処理) を取得し、2 桁ごとに 1 桁にし、前に % を追加して、% としてエンコードします。 XY形式。
HSTSは、HTTP Strict Transport Security（HTTP Strict Transport Security）の略称です。これは、Web サイトが安全な接続 (HTTPS) を使用してのみアクセスできることを宣言するために使用される方法です。Web サイトが HSTS ポリシーを宣言する場合、ブラウザはすべての HTTP 接続を拒否し、ユーザーが安全でない SSL 証明書を受け入れないようにする必要があります。現在、ほとんどの主要なブラウザが HSTS をサポートしています。
ブラウザは、セキュリティ チェックやアクセス制限などの追加の操作も実行します。
ブラウザのキャッシュチェック:
2. DNS ドメイン名を分析して、対応する IP を取得します。
入力された URL にドメイン名が含まれていると仮定すると、DNS 解決が必ず必要になります。もちろん、URL が単なる IP の場合は、DNS は関与しません。ドメイン名は IP よりも覚えやすいため、ドメイン名が表示されるのは記憶を容易にするためです。ここでは、URL にドメイン名が含まれていると仮定します。DNS ドメイン名解決では、再帰的なクエリ方式が使用されます。
- ブラウザのキャッシュ:
まず、ブラウザのキャッシュ内にドメイン名に対応する IP アドレスがあるかどうかを確認します (ドメイン名に以前アクセスしたことがあり、キャッシュがクリアされていない場合)。
- システムキャッシュ:
ブラウザのキャッシュにドメイン名に対応する IP がない場合、ユーザーのコンピュータ システムの hosts ファイルの DNS キャッシュにドメイン名に対応する IP があるかどうかが自動的にチェックされますが、このオペレーティング システム レベルのドメイン名はこの解決手順は、多くのハッカーによっても使用されており、hosts ファイルを変更することにより、ドメイン名の内容によって特定のドメイン名が指定された IP アドレスに解決され、いわゆるドメイン名ハイジャックが発生します。したがって、悪意のある改ざんを防ぐために、Windows7ではhostsファイルを読み取り専用に設定します。
- ルーターキャッシュ:
ブラウザもシステム キャッシュもそれを見つけられない場合、ルータ キャッシュに入ってチェックします。上記の 3 つのステップは、顧客サービス側の DNS キャッシュです。
- ISP (インターネット サービス プロバイダー) DNS キャッシュ:
ドメイン名に対応する IP アドレスがユーザー カスタマー サービス側で見つからない場合、クエリのために ISP DNS キャッシュに入ります。たとえば、テレコム ネットワークを使用している場合は、テレコムの DNS キャッシュ サーバーを入力して検索します。
- ルートネームサーバー
上記のいずれも完了していない場合は、クエリ用のルート サーバーを入力します。ルート ドメイン ネーム サーバーは世界中に 13 台しかなく、メイン ルート ドメイン ネーム サーバーは 1 台、残りの 12 台は補助ルート ドメイン ネーム サーバーです。ルート ドメイン名はリクエストを受信すると、ゾーン ファイル レコードを確認し、レコードがない場合は、管轄内のトップレベル ドメイン名 (.com など) のサーバー IP をローカル DNS サーバーに通知します。 ;
- TLDサーバー
要求を受信した後、トップレベル ドメイン ネーム サーバーはゾーン ファイル レコードを確認し、レコードがない場合は、管轄内のプライマリ ドメイン ネーム サーバーの IP アドレスをローカル DNS サーバーに通知します。
- プライマリネームサーバー
要求を受信した後、プライマリ ドメイン ネーム サーバーは自身のキャッシュを照会し、キャッシュがない場合は次のレベルのドメイン ネーム サーバーを入力して検索し、正しいレコードが見つかるまでこの手順を繰り返します。
- 結果をキャッシュに保存する
ローカル ドメイン ネーム サーバーは、返された結果を次回の使用のためにキャッシュに保存し、その結果をクライアントにフィードバックします。クライアントはこの IP アドレスを介して Web サーバーと通信します。
最後に、見つかった IP をユーザーに返し、次回使用するためにローカルにキャッシュします。また、DNS の解決を知るには時間がかかります。そのため、解決するドメイン名が多すぎると、最初の IP アドレスの読み込み速度が遅くなります。非常に遅くなります (最初のバッチの速度を最適化するポイント)、DNS プリフェッチの最適化を検討してください
3. IP に基づいて TCP 接続を確立します。（三者握手）
TCP は信頼性の高いリンク指向プロトコルです
。いわゆる 3 ウェイ ハンドシェイク (スリーウェイ ハンドシェイク) とは、TCP 接続を確立するときに、クライアントとサーバーが合計 3 つのパケットを送信する必要があることを意味します。
スリーウェイ ハンドシェイクの目的は、サーバーの指定されたポートに接続して TCP 接続を確立し、双方のシリアル番号と確認番号を同期し、TCP ウィンドウ サイズ情報を交換することです。ソケット プログラミングでは、クライアントが connect() を実行するとき。スリーウェイ ハンドシェイクがトリガーされます。
最初のハンドシェイクでは、クライアントは、接続先サーバーのポートを示す TCP SYN=1 (同期接続確立) パケットを送信し、シーケンス番号 = 1234567 のデータ パケットをサーバーにランダムに生成します。送信すると、クライアントは SYN_SEND 状態に入ります。
2回目のハンドシェイク：リクエストを受信した後、サーバーはオンライン情報を確認し、syn=1、ack=1（確認応答確認）、ack番号=（ホストAのseq+1）をAに送信し、ランダムにパケットを生成する必要があります。 of seq=7654321; 送信後、サーバーは SYN_RCVD 状態になります。
3回目のハンドシェイクを受信した後、クライアントはack番号が正しいか、つまり初めて送信したseq番号+1とビットコードackが1であるかどうかを確認します。正しい場合、ホストAはack番号を送信します。 =(ホスト B の seq +1)、ack=1、ホスト B は seq 値を確認し、受信後に ack=1 を返すと、接続が正常に確立されます。
クライアントが送信すると ESTABLISHED 状態になり、サーバーがパケット確認を受信すると ESTABLISHED 状態になり、TCP ハンドシェイクが終了します。
2 回のハンドシェイクで接続できないのはなぜですか?
3 ウェイ ハンドシェイクは 2 つの重要な機能を完了します。これにより、双方がデータ送信の準備をする必要があるだけでなく、両方の当事者が最初のシリアル番号についてネゴシエートすることもでき、ハンドシェイク プロセス中に送信および確認されます。
3 ウェイ ハンドシェイクが 2 つのハンドシェイクのみに変更されると、デッドロックが発生する可能性があります。下図のように、コンピュータクライアントとサーバー間で通信が行われる場合、クライアントがサーバーに接続要求パケットを送信し、サーバーがそれを受信して確認応答パケットを送信するものとします。2 つのハンドシェイクの合意に従って、サーバーは接続が正常に確立され、データ パケットの送信を開始できると信じます。ただし、サーバーの応答パケットが送信中に失われた場合、クライアントはサーバーの準備ができているかどうか、サーバーが確立したシリアル番号がわかりません。また、クライアントは、サーバーが独自の接続要求パケットを受信したかどうかさえ疑います。 。この場合、クライアントは接続が正常に確立されていないと考え、サーバーから送信されたデータ パケットを無視し、接続確認応答パケットのみを待ちます。ただし、サーバーによって送信されたデータ パケットがタイムアウトになると、サーバーは同じデータ パケットを繰り返し送信します。これによりデッドロックが発生します。
他の 3 つのハンドシェイクにより、無効な接続要求セグメントがサーバーに突然送信され、エラーが発生するのを防ぐことができます。異常な状況が発生したとします。つまり、クライアントによって送信された最初の接続要求セグメントは失われませんが、一部のネットワーク ノードに長時間留まり、接続が解放されてから到達するまでに一定時間遅延することがあります。これはすでに有効期限が切れたセグメントであることが判明しました。ただし、サーバーがこの無効な接続要求セグメントを受信すると、クライアントが新しい接続要求を送信したと誤って認識し、接続の確立に同意する確認セグメントをクライアントに送信します。3 ウェイ ハンドシェイクが使用されないと仮定すると、サーバーが確認を送信する限り、新しい接続が確立され、クライアントがデータを送信するのを待機するため、サーバーの多くのリソースが無駄に浪費されます。
TCP/IP の階層化管理
TCP/IP プロトコル スイートには多くのプロトコルが含まれており、アプリケーション層、トランスポート層、ネットワーク層、およびデータリンク層の 4 つの層に分かれています。
アプリケーション層: FTP (File Transfer Protocol、ファイル転送プロトコル)、DNS、HTTP などのさまざまな一般的なアプリケーション サービスが含まれます。
トランスポート層: TCP や UDP など、ネットワーク内の 2 台のコンピュータ間のデータ伝送を提供します。
ネットワーク層：ネットワーク上を流れるデータパケットを扱い、データパケットが相手のコンピュータに送信される際の伝送経路や経路を指定します。IPなど。
データリンク層: ネットワークカード、光ファイバーなどのハードウェアデバイスを含む、ネットワークのハードウェア部分を接続します。
4. 接続が確立された後、HTTP リクエストが開始されます。
完全な HTTP リクエストは、リクエスト開始行、リクエスト ヘッダー、リクエスト本文の 3 つの部分で構成されます。
5. サーバーは HTTP リクエストに応答し、ブラウザは応答を受け取ります。
ブラウザから送信されたHTTPリクエストを受信したサーバーは、受信したHTTPメッセージをHTTP Requestオブジェクトにカプセル化し、別のWebサーバーを通じて処理し、処理結果は主にステータスを含むHTTP Responseオブジェクトとして返されます。部分: コード、応答ヘッダー、および応答メッセージ。
ステータスコードは主に以下の部分で構成されます
1xx: 指示 – リクエストが受信され、処理が継続されていることを示します。
2xx: 成功 – リクエストが正常に受信、理解、受け入れられたことを示します。
3xx: リダイレクト – リクエストを完了するにはさらなるアクションが必要です。
4xx: クライアント エラー – リクエストに構文エラーがあるか、リクエストを実行できません。
5xx: サーバー側エラー – サーバーは正当なリクエストを実行できませんでした。
レスポンスヘッダーは主にCache-Control、Connection、Date、Pragmaなどで構成されます。
レスポンスボディはサーバーからブラウザに返される情報で、主にHTML、css、js、画像ファイルで構成されます。
6. ブラウザは HTML コードを解析し、ページを表示します。
js、css、画像の解析とダウンロード
1. HTML タグを解析して DOM ツリーを作成する
2. CSS を解析して CSSOM ツリーを作成する
3. DOM と CSSOM を結合してリアンダー ツリーを生成する
4. リーダー ツリーをレイアウトし、各ノードの位置とサイズを計算する
5. レンダリング、プレゼンテーションページ
このプロセスにより、ページの再描画またはリフローがトリガーされる場合があります。ここには、リフローと再ペイントという 2 つの重要な概念が関係しています。
リフロー (レイアウトとも呼ばれます) は中国語でリフローと呼ばれ、一般に要素の内容、構造、位置、サイズが変更され、スタイルとレンダリング ツリーを再計算する必要があることを意味します。このプロセスはリフローと呼ばれます。
再描画、再描画とは、要素の変更が要素の一部の外観 (背景色、境界線の色、テキストの色など) にのみ影響することを意味します。
再描画とリフローのコストは、カードの速度が低下することですが、ブラウザには独自の最適化機能があります。ブラウザはキューを維持し、再描画とリフローを引き起こすすべての操作をこのキューに入れます。キューが特定の数に達するか、キューに達すると、ある時点で、ブラウザはキューをフラッシュしてバッチ処理を実行します。これにより、複数の再描画リフローが 1 つの再描画リフローになります。
最適化：
- classNameを直接変更する
- 表示: なし 最初に要素を表示: なしに設定し、次に要素を操作し、操作の完了後に要素を表示: ブロックに設定します。これにより、2 回の再描画とリフローのみがトリガーされます。
- replaceChild を使用して、変更する必要がある dom を直接置き換え、フローを 1 回だけ再描画します
- 複数のリフローが必要な要素をposition:absolute/fixedに設定して、ドキュメントフローから除外します。
- createDocumentFragment、仮想ノードを作成し、一度に追加します
7. サーバーは TCP 接続を閉じます。
TCP は TCP 接続を閉じるために 4 回手を振った
最初の波 (FIN=1、seq=x): クライアントが接続を閉じたいと仮定すると、クライアントは FIN=1 パケットを送信します。これは、送信するデータがないが、データはまだ受け入れることができることを示します。送信後、クライアントは FIN_WAIT_1 状態に入ります。(最初の波: ブラウザによって開始され、サーバーに送信され、リクエスト メッセージが送信され、閉じる準備ができました)
第 2 の波 (ACK=1、ACKnum=x+1): サーバーはクライアントの FIN パケットを確認し、クライアントの接続を閉じる要求を受け入れたが、接続を閉じる準備ができていないことを示す確認パケットを送信します。まだ。送信後、サーバーは CLOSE_WAIT
状態に入り、確認パケットを受信した後、クライアントは FIN_WAIT_2 状態になり、サーバーが接続を閉じるのを待ちます。(2 番目の手を振る: サーバーによって開始され、リクエスト メッセージの受け入れが完了したことをブラウザに伝えます。私はリクエスト メッセージを閉じるつもりなので、あなたもそうする必要があります)
3 番目のウェーブ (FIN=1、seq=y): サーバーは接続を閉じる準備ができると、クライアントに接続終了要求を送信し、FIN が 1 に設定されます。送信後、サーバーは LAST_ACK 状態に入り、クライアントからの最後の ACK を待ちます。(第 3 の波: サーバーによって開始され、応答メッセージの送信が完了したので閉じる準備ができていることをブラウザーに伝えます)
4 番目の波 (ACK=1、ACKnum=y+1): クライアントはサーバーからクローズ要求を受信し、確認パケットを送信し、TIME_WAIT 状態に入り、再送信が必要な ACK パケットの可能性を待ちます。確認パケットを受信した後、サーバーは接続を閉じ、CLOSED 状態に入ります。一定の固定時間（2 つの最大セグメント ライフ サイクル、2MSL、2 最大セグメント ライフタイム）待機した後、クライアントはサーバーから ACK を受信せず、サーバーが正常に接続を閉じたと考え、接続自体を閉じます。そしてCLOSED状態に入ります。(第 4 の波: ブラウザによって開始され、応答メッセージの受信が完了したことをサーバーに伝えます。私は応答メッセージを閉じるつもりなので、あなたもそうする必要があります)
3 方向のハンドシェイクがあるのに、接続するときに 4 つの手が振られるのはなぜですか?
接続を確立する場合: サーバー側は、クライアント側から SYN 接続要求メッセージを受信した後、SYN+ACK メッセージを直接送信できます。このうち、ACKメッセージは応答に使用され、SYNメッセージは同期に使用されます。
接続を閉じるとき: サーバーが FIN メッセージを受信すると、TCP がシステム カーネルに実装されている場合、サーバーは自動的に ACK で応答します。FIN を再度送信すると、アプリケーション プログラムは手動で close() を呼び出して接続を閉じます。プログラムは接続を閉じる前に、リソースの解放などの事前操作を実行する必要がある場合があるため、マージを 2 回実行することはできず、接続が切断されたときに 4 回手を振る必要があります。