fwrite

ネットワーク知識#

UDP#

メッセージ指向

UDP はメッセージ指向（メッセージはデータの断片と理解できます）のプロトコルです。つまり、UDP はメッセージの運搬人であり、メッセージの分割や結合を行いません。

• 送信側では、アプリケーション層がデータを伝送層の UDP プロトコルに渡し、UDP はデータに UDP ヘッダーを追加するだけで、ネットワーク層に渡します。
• 受信側では、ネットワーク層がデータを伝送層に渡し、UDP は IP メッセージヘッダーを削除してアプリケーション層に渡します。結合操作は行いません。

信頼性がない

1. UDP は接続指向ではなく、通信のために接続を確立したり切断したりする必要はありません。
2. UDP も信頼性がありません。プロトコルは受信したデータをそのまま伝送し、データのバックアップも行わず、相手が受信できるかどうかは気にしません。
3. UDP には輻輳制御がなく、常に一定の速度でデータを送信します。ネットワーク条件が悪くても送信速度を調整しません。この実装の欠点は、ネットワーク条件が悪い場合にパケットロスが発生する可能性があることですが、利点も明らかであり、リアルタイム性が高いシーン（例えば、電話会議）では UDP を使用する必要があります。

効率的

UDP は TCP ほど複雑ではなく、データが失われず順序通りに到着することを保証する必要がありません。そのため、UDP のヘッダーオーバーヘッドは小さく、わずか 8 バイトで、TCP の少なくとも 20 バイトに比べてはるかに少なく、データメッセージの伝送時に非常に効率的です。

ヘッダーには以下のデータが含まれています。

• 2 つの 16 ビットポート番号、ソースポート（オプションフィールド）とターゲットポート
• 全体のデータメッセージの長さ
• 全体のデータメッセージのチェックサム（IPv4 オプションフィールド）、このフィールドはヘッダー情報とデータ内のエラーを検出するために使用されます。

伝送方式

UDP は一対一の伝送方式だけでなく、一対多、多対多、多対一の方式もサポートしています。つまり、UDP はユニキャスト、マルチキャスト、ブロードキャストの機能を提供しています。

TCP#

TCP ヘッダーにとって、以下のフィールドは非常に重要です。

• シーケンス番号、この番号は TCP 伝送のメッセージが順序通りであることを保証し、相手はシーケンス番号を使ってメッセージを順番に結合できます。
• 確認番号、この番号はデータ受信側が期待する次のバイトの番号を示し、同時に前のシーケンス番号のデータが受信されたことを示します。
• ウィンドウサイズ、ウィンドウサイズはまだ受信できるバイト数を示し、フロー制御に使用されます。
• 識別子
• URG=1：このフィールドが 1 の場合、データメッセージのデータ部分には緊急情報が含まれており、高優先度のデータメッセージです。この場合、緊急ポインタが有効です。緊急データは常に現在のデータパケットのデータ部分の最前面に位置し、緊急ポインタは緊急データの末尾を示します。
• ACK=1：このフィールドが 1 の場合、確認番号フィールドが有効です。さらに、TCP は接続が確立された後に送信されるすべてのメッセージセグメントで ACK を 1 に設定する必要があります。
• PSH=1：このフィールドが 1 の場合、受信側はデータをアプリケーション層に即座にプッシュすべきであり、バッファが満杯になるのを待ってから提出するべきではありません。
• RST=1：このフィールドが 1 の場合、現在の TCP 接続に深刻な問題が発生しており、TCP 接続を再構築する必要があるか、違法なメッセージセグメントや接続要求を拒否するために使用できます。
• SYN=1：SYN=1、ACK=0 の場合、現在のメッセージセグメントは接続要求メッセージです。SYN=1、ACK=1 の場合、現在のメッセージセグメントは接続を確立することに同意する応答メッセージです。
• FIN=1：このフィールドが 1 の場合、このメッセージセグメントは接続を解放するための要求メッセージです。

状態機械

HTTP は接続指向ではないため、下層の TCP プロトコルも接続指向ではありません。一見すると TCP は両端を接続しているように見えますが、実際には両端が共に状態を維持しています。

TCP の状態機械は非常に複雑であり、接続の確立と切断時のハンドシェイクに密接に関連しています。次に、2 つのハンドシェイクを詳細に説明します。

その前に、重要な性能指標 RTT を理解する必要があります。この指標は、送信側がデータを送信してから受信側のデータを受信するまでの往復時間を示します。

三回のハンドシェイク

TCP プロトコルでは、リクエストを積極的に発起する側をクライアントと呼び、受動的に接続される側をサーバーと呼びます。クライアントとサーバーのどちらも、TCP 接続が確立された後はデータを送受信できますので、TCP は全二重プロトコルでもあります。

最初は、両端は CLOSED 状態です。通信が始まる前に、両者は TCB を作成します。サーバーが TCB を作成した後、LISTEN 状態に入り、クライアントからのデータ送信を待ち始めます。

• 最初のハンドシェイク

クライアントはサーバーに接続要求メッセージセグメントを送信します。このメッセージセグメントには、自身のデータ通信初期シーケンス番号が含まれています。リクエストを送信した後、クライアントは SYN-SENT 状態に入ります。x はクライアントのデータ通信初期シーケンス番号を示します。

• 二回目のハンドシェイク

サーバーは接続要求メッセージセグメントを受信した後、接続に同意する場合は応答を送信します。この応答にも自身のデータ通信初期シーケンス番号が含まれ、送信が完了すると SYN-RECEIVED 状態に入ります。

• 三回目のハンドシェイク

クライアントは接続同意の応答を受信した後、サーバーに確認メッセージを送信します。クライアントがこのメッセージセグメントを送信した後、ESTABLISHED 状態に入ります。サーバーがこの応答を受信すると、同様に ESTABLISHED 状態に入ります。この時点で接続が確立されます。

PS：三回目のハンドシェイクにはデータを含めることができ、TCP の迅速なオープン（TFO）技術を使用できます。実際、ハンドシェイクに関わるプロトコルはすべて、TFO のような方法を使用できます。クライアントとサーバーは同じクッキーを保存し、次回のハンドシェイク時にクッキーを送信して RTT を減少させることができます。

四回のハンドシェイク

TCP は全二重であり、接続を切断する際には両端が FIN と ACK を送信する必要があります。

• 最初のハンドシェイク

クライアント A がデータ送信を完了したと考える場合、サーバー B に接続解放要求を送信する必要があります。

• 二回目のハンドシェイク

B は接続解放要求を受信した後、アプリケーション層に TCP リンクを解放するように指示します。その後、ACK パケットを送信し、CLOSE_WAIT 状態に入ります。これは A から B への接続が解放され、A からのデータを受信しないことを示します。しかし、TCP 接続は双方向であるため、B は引き続き A にデータを送信できます。

• 三回目のハンドシェイク

B がまだ送信していないデータがある場合は、引き続き送信し、完了後に A に接続解放要求を送信します。その後、B は LAST-ACK 状態に入ります。

PS：遅延確認技術（通常は時間制限があります。さもなければ、相手は再送信が必要だと誤解します）を使用することで、二回目と三回目のハンドシェイクを統合し、遅延 ACK パケットの送信を行うことができます。

• 四回目のハンドシェイク

A は解放要求を受信した後、B に確認応答を送信し、この時 A は TIME-WAIT 状態に入ります。この状態は 2MSL（最大セグメント生存期間、メッセージセグメントがネットワーク内で生存する時間、タイムアウトすると破棄される）時間続きます。この時間内に B からの再送信要求がなければ、CLOSED 状態に入ります。B が確認応答を受信すると、B も CLOSED 状態に入ります。

なぜ A は TIME-WAIT 状態に入り、2MSL の時間を待ってから CLOSED 状態に入るのでしょうか？

B が A の確認応答を受信できることを保証するためです。A が確認応答を送信した後、直接 CLOSED 状態に入ると、確認応答がネットワークの問題で到達しなかった場合、B が正常に終了できなくなります。

ARQ プロトコル#

ARQ プロトコルはタイムアウト再送信メカニズムです。確認とタイムアウトメカニズムを通じてデータの正しい配信を保証します。ARQ プロトコルには停止待機 ARQ と連続 ARQ が含まれます。

正常な伝送プロセス

A が B にメッセージを送信する場合、送信を停止し、タイマーを起動し、相手の応答を待ちます。タイマーの時間内に相手の応答を受信すると、タイマーをキャンセルし、次のメッセージを送信します。

メッセージのロスまたはエラー

メッセージの伝送中にパケットロスが発生する可能性があります。この場合、タイマー設定の時間を超えると、ロストしたデータを再送信します。相手が応答するまで、毎回送信したデータをバックアップする必要があります。

メッセージが正常に相手に伝送されても、伝送中にメッセージがエラーになる可能性があります。この場合、相手はそのメッセージを破棄し、A に再送信を待ちます。

PS：一般的に、タイマー設定の時間は RTT の平均時間よりも長くなります。

ACK のタイムアウトまたはロス

相手の伝送応答もロスまたはタイムアウトする可能性があります。この場合、タイマーの時間を超えると、A はメッセージを再送信します。この時、B は同じシーケンス番号のメッセージを受信すると、そのメッセージを破棄し、応答を再送信します。A が次のシーケンス番号のメッセージを送信するまで続きます。

タイムアウトの状況でも、応答が遅れて到達することがあります。この時、A はそのシーケンス番号がすでに受信されたかどうかを判断し、受信されていれば応答を破棄するだけで済みます。

このプロトコルの欠点は、伝送効率が低く、良好なネットワーク環境下では毎回メッセージを送信するたびに相手の ACK を待つ必要があることです。

連続 ARQ#

連続 ARQ では、送信側は送信ウィンドウを持ち、応答を受信していない状態でウィンドウ内のデータを継続的に送信できます。これにより、停止待機 ARQ プロトコルに比べて待機時間が短縮され、効率が向上します。

累積確認

連続 ARQ では、受信側はメッセージを継続的に受信します。停止待機 ARQ のように、1 つのメッセージを受信するたびに応答を送信するのはリソースの無駄です。累積確認を使用することで、複数のメッセージを受信した後に 1 つの応答メッセージを統一して返信できます。メッセージ内の ACK は、送信側にこのシーケンス番号以前のデータがすべて受信されたことを知らせ、次回はこのシーケンス番号 + 1 のデータを送信するように指示します。

しかし、累積確認にも欠点があります。連続してメッセージを受信しているとき、シーケンス番号 5 のメッセージを受信した後、シーケンス番号 6 のメッセージを受信していない場合、シーケンス番号 7 以降のメッセージはすでに受信されています。このような場合、ACK は 6 を返すしかなく、送信側はデータを重複して送信することになります。この状況は Sack を使用して解決できます。これは後で説明します。

輻輳処理

輻輳処理はフロー制御とは異なり、後者は受信側に作用し、受信側がデータを受け取るのに間に合うようにします。一方、前者はネットワークに作用し、過剰なデータがネットワークを混雑させるのを防ぎ、ネットワークの負荷が過大になるのを避けます。

輻輳処理には 4 つのアルゴリズムが含まれます：スロースタート、輻輳回避、迅速再送、迅速回復。

スロースタートアルゴリズム

スロースタートアルゴリズムは、伝送開始時に送信ウィンドウを徐々に指数関数的に拡大し、最初から大量のデータを送信してネットワークが混雑するのを避けることを目的としています。

スロースタートアルゴリズムの具体的な手順は以下の通りです。

1. 接続初期に輻輳ウィンドウ（Congestion Window）を 1MSS（1 セグメントの最大データ量）に設定します。
2. 1 つの RTT ごとにウィンドウサイズを 2 倍にします。
3. 指数関数的成長には制限が必要ですので、閾値制限があります。ウィンドウサイズが閾値を超えると、輻輳回避アルゴリズムが起動します。

輻輳回避アルゴリズム

輻輳回避アルゴリズムは比較的単純で、1 つの RTT ごとにウィンドウサイズを 1 増加させ、指数関数的成長によるネットワークの混雑を避け、サイズを最適値に調整します。

伝送中にタイマーがタイムアウトする可能性があります。この場合、TCP はネットワークが混雑していると判断し、すぐに以下の手順を実行します。

• 閾値を現在の輻輳ウィンドウの半分に設定します。
• 輻輳ウィンドウを 1MSS に設定します。
• 輻輳回避アルゴリズムを起動します。

迅速再送

迅速再送は通常、迅速回復と一緒に発生します。受信側が受信したメッセージに順序の問題がある場合、受信側は最後の順序が正しいメッセージのシーケンス番号のみを返信します（Sack がない場合）。3 つの重複 ACK を受信した場合、タイマーのタイムアウトを待たずに迅速再送を起動します。具体的なアルゴリズムは 2 つに分かれます。

TCP Taho の実装は以下の通りです。

• 閾値を現在の輻輳ウィンドウの半分に設定します。
• 輻輳ウィンドウを 1MSS に設定します。
• スロースタートアルゴリズムを再開します。

TCP Reno の実装は以下の通りです。

• 輻輳ウィンドウを半分にします。
• 閾値を現在の輻輳ウィンドウに設定します。
• 迅速回復段階に入ります（相手が必要とするパケットを再送信し、新しい ACK 応答を受信したらこの段階を終了します）。
• 輻輳回避アルゴリズムを使用します。

TCP New Reno の改善された迅速回復

TCP New Reno アルゴリズムは、以前の TCP Reno アルゴリズムの欠陥を改善しました。以前は、迅速回復中に新しい ACK パケットを受信すると、迅速回復を終了しました。

TCP New Reno では、TCP 送信側は 3 つの重複 ACK のセグメントの最大シーケンス番号を記録します。

例えば、1〜10 の 10 個のシーケンス番号のメッセージがあり、その中でシーケンス番号 3 と 7 のメッセージが失われた場合、そのセグメントの最大シーケンス番号は 10 です。送信側は ACK シーケンス番号 3 の応答のみを受け取ります。この時、シーケンス番号 3 のメッセージを再送信し、受信側は順調に受信し、ACK シーケンス番号 7 の応答を送信します。この時、TCP は相手が複数のパケットを受信していないことを知り、シーケンス番号 7 のメッセージを再送信します。受信側は順調に受信し、ACK シーケンス番号 11 の応答を送信します。この時、送信側はこのセグメントが受信側によって順調に受信されたと考え、迅速回復段階を終了します。

HTTP#

HTTP プロトコルは無状態プロトコルであり、状態を保存しません。

Post と Get の違い

副作用と冪等性の概念を導入します。

副作用は、サーバー上のリソースを変更することを指し、検索は副作用がありませんが、登録は副作用があります。

冪等性は、M 回と N 回のリクエストを送信した場合（両者は異なり、どちらも 1 より大きい）、サーバー上のリソースの状態が一致することを指します。例えば、10 個と 11 個のアカウントを登録することは冪等性がありませんが、記事を 10 回と 11 回変更することは冪等性があります。

規範的な適用シーンでは、Get は無副作用で冪等性のあるシーン、例えばキーワード検索に多く使用されます。Post は副作用があり、冪等性がないシーン、例えば登録に多く使用されます。

技術的には：

• Get リクエストはキャッシュ可能ですが、Post はキャッシュできません。
• Post は Get よりも若干安全です。なぜなら、Get リクエストはすべて URL に含まれ、ブラウザに履歴が保存されますが、Post は保存されません。しかし、パケットキャプチャの状況ではどちらも同じです。
• Post はリクエストボディを通じて Get よりも多くのデータを送信できますが、Get にはこの技術がありません。
• URL には長さ制限があり、Get リクエストに影響を与えますが、この長さ制限はブラウザによって規定されており、RFC によって規定されているわけではありません。
• Post はより多くのエンコーディングタイプをサポートし、データタイプに制限をかけません。

一般的なステータスコード

2XX 成功

• 200 OK、クライアントからのリクエストがサーバーで正しく処理されたことを示します。
• 204 No content、リクエストが成功したが、応答メッセージには実体の主体部分が含まれていないことを示します。
• 205 Reset Content、リクエストが成功したが、応答メッセージには実体の主体部分が含まれていない。ただし、204 応答とは異なり、リクエスト側に内容をリセットするように要求します。
• 206 Partial Content、範囲リクエストを行います。

3XX リダイレクト

• 301 moved permanently、永久リダイレクト、リソースが新しい URL に割り当てられたことを示します。
• 302 found、一時的リダイレクト、リソースが一時的に新しい URL に割り当てられたことを示します。
• 303 see other、リソースが別の URL に存在し、GET メソッドを使用してリソースを取得する必要があることを示します。
• 304 not modified、サーバーがリソースへのアクセスを許可するが、リクエストが条件を満たさなかったことを示します。
• 307 temporary redirect、一時的リダイレクト、302 と同様の意味ですが、クライアントがリクエストメソッドを変更せずに新しいアドレスにリクエストを送信することを期待します。

4XX クライアントエラー

• 400 bad request、リクエストメッセージに構文エラーが存在します。
• 401 unauthorized、送信されたリクエストには HTTP 認証の認証情報が必要であることを示します。
• 403 forbidden、リクエストリソースへのアクセスがサーバーによって拒否されたことを示します。
• 404 not found、サーバー上でリクエストされたリソースが見つからなかったことを示します。

5XX サーバーエラー

• 500 internal server error、サーバー側でリクエストを実行中にエラーが発生したことを示します。
• 501 Not Implemented、サーバーが現在のリクエストに必要な機能をサポートしていないことを示します。
• 503 service unavailable、サーバーが一時的に過負荷またはメンテナンス中で、リクエストを処理できないことを示します。

HTTP ヘッダー

HTTPS#

HTTPS は HTTP を通じて情報を伝送しますが、情報は TLS プロトコルによって暗号化されています。

TLS#

TLS プロトコルは伝送層の上、アプリケーション層の下に位置しています。最初に TLS プロトコルを伝送するには 2 つの RTT が必要で、その後はセッション再開を通じて 1 つの RTT に減少できます。

TLS では、対称暗号と非対称暗号の 2 つの暗号技術が使用されています。

対称暗号：

対称暗号は、両側が同じ鍵を持ち、両側が暗号文を暗号化および復号化する方法を知っていることを指します。

非対称暗号：

公開鍵と秘密鍵があり、公開鍵は誰でも知ることができ、データを公開鍵で暗号化できますが、データを復号化するには秘密鍵が必要で、秘密鍵は公開鍵を配布する側だけが知っています。

TLS ハンドシェイクプロセスは以下の図の通りです：

1. クライアントはランダム値、必要なプロトコルと暗号方式を送信します。
2. サーバーはクライアントのランダム値を受信し、自身もランダム値を生成し、クライアントが要求したプロトコルと暗号方式に基づいて対応する方式を使用し、自身の証明書を送信します（クライアント証明書の検証が必要な場合は明示します）。
3. クライアントはサーバーの証明書を受信し、有効性を検証し、検証が通過すると新しいランダム値を生成し、サーバー証明書の公開鍵を使用してこのランダム値を暗号化し、サーバーに送信します。サーバーがクライアント証明書の検証を必要とする場合は、証明書を添付します。
4. サーバーは暗号化されたランダム値を受信し、秘密鍵を使用して復号化し、3 つ目のランダム値を取得します。この時点で両側は 3 つのランダム値を持ち、これらのランダム値を使用して事前に合意された暗号方式に従って鍵を生成できます。以降の通信はこの鍵を使用して暗号化および復号化されます。

以上の手順から、TLS ハンドシェイク段階では、両側が非対称暗号方式を使用して通信しますが、非対称暗号は対称暗号に比べて性能の損失が大きいため、正式なデータ伝送時には両側が対称暗号方式を使用して通信します。

PS：以上の説明は TLS 1.2 プロトコルのハンドシェイク状況です。1.3 プロトコルでは、最初の接続を確立するのに 1 つの RTT が必要で、その後の接続再開には RTT が必要ありません。

HTTP 2.0#

HTTP 2.0 は HTTP 1.X に比べて Web の性能を大幅に向上させました。

HTTP 1.X では、性能を考慮して、スプライト画像を導入したり、小さな画像をインラインにしたり、複数のドメインを使用したりする方法がありました。これらはすべて、ブラウザが同じドメインでのリクエスト数を制限しているため、ページ内で多くのリソースをリクエストする必要がある場合、先頭ブロッキング（Head of line blocking）が発生し、最大リクエスト数に達すると、残りのリソースは他のリソースリクエストが完了するのを待つ必要があります。

バイナリ伝送

HTTP 2.0 のすべての性能向上の核心はここにあります。以前の HTTP バージョンでは、テキスト形式でデータを伝送していましたが、HTTP 2.0 では新しいエンコーディングメカニズムが導入され、すべての伝送データが分割され、バイナリ形式でエンコードされます。

マルチプレクシング

HTTP 2.0 では、フレーム（frame）とストリーム（stream）の 2 つの非常に重要な概念があります。

フレームは最小のデータ単位を表し、各フレームはそのフレームがどのストリームに属するかを識別します。ストリームは複数のフレームで構成されるデータストリームです。

マルチプレクシングは、1 つの TCP 接続内に複数のストリームが存在できることを意味します。言い換えれば、複数のリクエストを送信でき、相手はフレーム内の識別子を通じてどのリクエストに属するかを知ることができます。この技術により、HTTP の旧バージョンにおける先頭ブロッキング問題を回避し、伝送性能を大幅に向上させることができます。

ヘッダー圧縮

HTTP 1.X では、ヘッダーをテキスト形式で伝送していましたが、ヘッダーにクッキーが含まれる場合、毎回数百から数千バイトを繰り返し伝送する必要がありました。

HTTP 2.0 では、HPACK 圧縮形式を使用して伝送されるヘッダーをエンコードし、ヘッダーのサイズを削減しました。さらに、両側でインデックステーブルを維持し、過去に出現したヘッダーを記録し、後の伝送中に記録されたヘッダーのキー名を伝送することができます。相手はデータを受信した後、キー名を通じて対応する値を見つけることができます。

サーバープッシュ

HTTP 2.0 では、サーバーはクライアントの特定のリクエストの後に、他のリソースを積極的にプッシュすることができます。

以下の状況を想像できます。特定のリソースはクライアントが必ずリクエストするため、サーバープッシュ技術を使用して、必要なリソースを事前にクライアントにプッシュすることができます。これにより、遅延時間を相対的に減少させることができます。もちろん、ブラウザの互換性がある場合は、prefetch を使用することもできます。

DNS#

DNS の役割は、ドメイン名を通じて具体的な IP を照会することです。

IP は数字と英字の組み合わせ（IPv6）が存在し、人間の記憶には不利であるため、ドメイン名が登場しました。ドメイン名は特定の IP の別名と見なすことができ、DNS はこの別名の本当の名前を照会するものです。

TCP ハンドシェイクの前に DNS 照会が行われます。この照会はオペレーティングシステム自身が行います。ブラウザでwww.google.comにアクセスしようとすると、以下の操作が行われます。

1. オペレーティングシステムはまずローカルキャッシュを照会します。
2. ない場合は、システム設定の DNS サーバーを照会します。
3. それでも見つからない場合は、DNS ルートサーバーに直接照会します。このステップでは、com というトップレベルドメインを担当するサーバーを見つけます。
4. 次に、そのサーバーに google というセカンドレベルドメインを照会します。
5. 次に、サードレベルドメインの照会は実際には私たちが設定したものであり、www というドメインに IP を設定したり、他のサードレベルドメインに IP を設定したりできます。

以上は DNS の反復照会についての説明ですが、再帰的照会もあり、前者はクライアントがリクエストを行うのに対し、後者はシステム設定の DNS サーバーがリクエストを行い、結果をクライアントに返します。

PS：DNS は UDP に基づいて照会を行います。

URL を入力してからページが完全に読み込まれるまでのプロセス

1. まず DNS 照会を行います。このステップでインテリジェント DNS 解析を行った場合、最もアクセス速度の速い IP アドレスが返されます。
2. 次に TCP ハンドシェイクが行われ、アプリケーション層がデータを伝送層に送信します。ここで TCP プロトコルは両端のポート番号を指定し、ネットワーク層に送信します。ネットワーク層の IP プロトコルは IP アドレスを決定し、データ伝送中にどのようにルーターをジャンプするかを指示します。その後、パケットはデータリンク層のデータフレーム構造に再封装され、最終的に物理層で伝送されます。
3. TCP ハンドシェイクが終了した後、TLS ハンドシェイクが行われ、正式なデータ伝送が開始されます。
4. データがサーバーに到達する前に、負荷分散を担当するサーバーを経由する場合があります。負荷分散サーバーの役割は、リクエストを複数のサーバーに合理的に分配することです。この時、サーバーが HTML ファイルに応答すると仮定します。
5. まずブラウザはステータスコードが何であるかを判断します。200 であれば解析を続け、400 または 500 であればエラーが発生し、300 であればリダイレクトが行われます。ここにはリダイレクトカウンターがあり、過度のリダイレクトを避けるために、回数を超えるとエラーが発生します。
6. ブラウザはファイルの解析を開始します。gzip 形式の場合は、最初に解凍し、ファイルのエンコーディング形式に基づいてファイルをどのようにデコードするかを知ります。
7. 初期の HTML が完全に読み込まれ解析されると、DOMContentLoaded イベントがトリガーされます。
8. CSSOM ツリーと DOM ツリーが構築されると、Render ツリーの生成が開始されます。このステップでは、ページ要素のレイアウト、スタイルなどの多くの側面が決定されます。
9. Render ツリーの生成中に、ブラウザは GPU を呼び出して描画し、合成レイヤーを作成し、内容を画面に表示します。