UDP

メッセージ指向

UDPはメッセージ指向のプロトコルです。つまり、UDPは単なるメッセージの移動者であり、メッセージの分割やスプライシングは行いません。

要するに

• 送信側では、アプリケーション層はデータをトランスポート層のUDPプロトコルに渡し、UDPプロトコルは単にUDPであることを示すUDPヘッダーをデータに追加し、それをネットワーク層に渡します。
• 受信側では、ネットワーク・レイヤがデータをトランスポート・レイヤに渡し、UDPはスプライシング操作なしにIPヘッダだけを取り除いてアプリケーション・レイヤに渡します。

信頼性の欠如

1. UDPはコネクションレスなので、通信にコネクションの確立や切断は必要ありません。
2. UDPも信頼できません。このプロトコルは受信したデータは何でも配信し、データのバックアップはしません。
3. UDPには輻輳制御がなく、常に一定のレートでデータを送信します。ネットワークの状態が悪くても、送信レートは調整されません。この実装の欠点は、ネットワーク状態が悪いとパケットロスにつながる可能性があることですが、利点もはっきりしています。

効率的

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

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

• 送信元ポートと宛先ポートに16桁の2つのポート番号
• データ・メッセージ全体の長さ
• データ・メッセージ全体の検査合計。このフィールドは、ヘッダー情報とデータのエラーを見つけるために使用されます。

送信方法

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

TCP

ヘッダー

TCPヘッダーはUDPヘッダーよりもはるかに複雑です。

TCPヘッダーでは、以下のフィールドが重要です。

• シーケンス番号は、TCPによって送信されるメッセージの順序を保証するもので、相手側はシーケンス番号によってメッセージを分割することができます。
• 確認応答番号（Acknowledgement Number）：この番号は、データ受信者が受信を期待する次のバイトの番号を示し、また前の番号のデータを受信したことを示します。
• ウィンドウ・サイズ（Window Size）：受信可能なデータのバイト数を示すウィンドウのサイズ。
• 識別子
  • URG=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のステートマシンは非常に複雑で、切断を確立するために使用されるハンドシェイクと密接に関係しています。

ここで理解すべき重要なパフォーマンス指標はRTTで、これは送信側がデータを送信してから相手側からデータを受信するまでの往復時間を表します。

接続を確立するための3つのハンドシェイク

TCPプロトコルでは、能動的にリクエストを開始する側をクライアント、受動的に接続する側をサーバーと呼びます。クライアントであれサーバであれ、TCPは接続が確立した後もデータの送受信が可能なので、TCPは全二重プロトコルでもあります。

最初は両端ともCLOSEDです。サーバはTCBを作成した後、LISTEN状態になり、クライアントからのデータ送信を待ちます。

最初の握手。

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

2度目の握手。

接続要求メッセージセグメントを受信したサーバーは、接続に同意した場合、自身のデータ通信初期シリアル番号も含むアンサーを送信し、送信後にSYN-RECEIVED状態になります。

3度目の握手。

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

PSは：3番目のハンドシェイクは、TCPの高速オープン技術を介してデータを含めることができます。実際には、限り、ハンドシェイクに関与するプロトコルは、TFOは、クライアントとサーバー側は、同じクッキーを格納するために、次のハンドシェイクは、RTTを削減する目的を達成するためにクッキーを発行するために同様の方法で使用することができます。

2回のハンドシェイクで接続が確立できるのに、なぜ3回目の応答が必要なのか不思議に思ったことはありませんか？

これは、無効な接続要求メッセージセグメントがサーバーに受信され、エラーが発生するのを防ぐためです。

次のようなシナリオを想像してみてください。クライアントは接続要求Aを送信しますが、タイムアウトによるネットワーク上の理由で、TCPは接続要求Bを送信するためにタイムアウト再送機構を開始します。両端が閉じた後、ようやく接続要求Aがサーバに到着すると、サーバはクライアントが再びTCP接続を確立する必要があると考え、要求に答えてESTABLISHED状態になります。この時点では、クライアントは実際にはCLOSEDであり、サーバを待たせることになり、リソースの浪費を招きます。

追記: 接続を確立する際、どちらかの端が脱落すると、TCPはSYNパケットを通常5回再送します。この場合、再試行回数を少なくするか、リクエストを処理できない場合は単に拒否するかを選択できます。

リンクの切断 4回のハンドシェイク

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

最初の握手。

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

2度目の握手。

Bはコネクション解放要求を受信すると、TCPリンクを解放するようアプリケーション層に伝えます。B への接続は解放されませんが、TCP 接続は双方向なので、B はまだ A にデータを送信できます。ただし、TCP 接続は双方向なので、B はまだ A にデータを送信できます。

3度目の握手。

Bはまだ終了していなければデータの送信を続け、終了するとAにコネクション解放要求を送り、BはLAST-ACK状態に入ります。

追記：遅延確認応答のテクニックを使えば、2回目と3回目のハンドシェイクを組み合わせ、ACKパケットの送信を遅らせることが可能です。

4度目の握手

Aがリリース要求を受信し、Bに確認応答を送信すると、AはTIME-WAIT状態に入ります。AはTIME-WAIT状態に入り、2MSL継続し、この期間内にBからの再送要求がなければCLOSED状態に入ります。この期間内にBからの再送要求がなければCLOSED状態に入ります。

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

BがAからの確認応答を確実に受信できるようにするため。A が確認応答を送信した後に直接 CLOSED 状態になった場合、ネットワークの問題で確認応答が届かなければ、B は正常にシャットダウンできません。

ARQ

ARQプロトコルはタイムアウト再送メカニズムとしても知られています。ARQプロトコルはStop Waiting ARQとContinuous ARQで構成されています。

ARQ待ちの停止

常道

AはBにメッセージを送信するたびに送信を停止してタイマーをスタートさせ、相手からの応答を待ち、タイマー時間内に相手からの応答を受信するとタイマーをキャンセルして次のメッセージを送信します。

メッセージの欠落または誤り

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

相手側には正常に伝わっていても、途中でエラーになることがあります。相手側はそのメッセージを破棄し、Aの再送を待ちます。

追記：通常、タイマーはRTTの平均時間よりも長い時間に設定されます。

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

相手側から送信されたアンサーも失われるか、タイムアウトが発生する可能性があります。タイマーを超えても、Aはメッセージを再送します。端末Bは同じ通し番号のメッセージを受信すると、そのメッセージを破棄し、端末Aが次の通し番号を送信するまでアンサーを再送します。

この場合、端末Aはシリアル番号がすでに受信されているかどうかを判断し、受信されている場合は単にその回答を破棄します。

このプロトコルの欠点は効率が悪いことで、良いネットワーク環境ではメッセージを送信するたびに相手側からのACKを待たなければなりません。

連続ARQ

連続ARQでは、送信者は送信ウィンドウを持ち、応答を受信しなくてもウィンドウ内のデータを送信し続けることができます。

累積確認

連続 ARQ では、受信者は連続してメッセージを受信します。stop-wait ARQ のように、受信したメッセー ジごとに応答を送信するのはリソースの無駄です。確認応答を蓄積することで、複数のメッセージを受信し、1 つの応答で返信することができます。メッセージ中のACKは、シーケンス番号のデータをすべて受信したことを送信側に伝え、次回はシーケンス番号＋1のデータを送信するために使用できます。

しかし、累積確認応答には欠点があります。連続したメッセージを受信する場合、通し番号 5 のメッセージを受信した後、通し番号 6 のメッセージを受信せず、通し番号 7 以降のメッセージは既に受信済みである場合があります。この場合、ACKは6にしか返信できず、送信者は繰り返しデータを送信することになりますが、この場合は後述するSackで解決できます。

スライドウィンドウ

上記のサブセクションでは、送信側ウィンドウについて説明しました。TCPでは、ウィンドウは送信側ウィンドウと受信側ウィンドウの両方で保持されます。

送信者ウィンドウには、送信されたにもかかわらず応答がなかったデータや、送信された可能性があるにもかかわらず送信されなかったデータが含まれます。

送信側のウィンドウは受信ウィンドウの残りサイズによって決まります。受信者は現在の受信ウィンドウの残りサイズをアンサーメッセージに書き込み、送信者はアンサーを受信して、この値と現在のネットワークの混雑状況に応じて送信ウィンドウのサイズを設定するため、送信ウィンドウのサイズは常に変化します。

送信者が応答メッセージを受信すると、ウィンドウをスライドさせます。

スライディング・ウィンドウはフロー制御を可能にします。受信側は送信側に、あとどれだけデータを送信できるかをメッセージで通知し、受信側が時間内にデータを受信できるようにします。

Zero

メッセージの送信中に、相手側のウィンドウがゼロになることがあります。その場合、送信者はデータの送信を停止し、持続タイマーを開始します。このタイマーは、反対側の端がウィンドウ・サイズを通知するように、一定の間隔で反対側の端にリクエストを送信します。一定回数の再試行後、TCPリンクは切断される可能性があります。

輻輳処理

輻輳処理がフロー制御と異なるのは、後者が受信機に作用して、受信機がデータを受信する時間を確保する点です。前者はネットワークに作用して、データが多すぎてネットワークが輻輳するのを防ぎ、ネットワークが過負荷にならないようにします。

輻輳処理は、スロースタート、輻輳回避、高速再送、高速回復の4つのアルゴリズムで構成されています。

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

スロースタート・アルゴリズムは、その名の通り、送信開始時に送信ウィンドウを指数関数的にゆっくりと拡大することで、最初に大量のデータを送信することによるネットワークの輻輳を回避します。

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

1. この接続では、最初に輻輳ウィンドウが1MSSに設定されます。
2. RTTごとにウィンドウサイズを2倍。
3. 指数関数的な成長は確かに無制限にはできないので、ウィンドウ・サイズが閾値より大きい場合に輻輳回避アルゴリズムを開始する閾値制限があります。

輻輳回避アルゴリズム

輻輳回避アルゴリズムはそれよりも少し単純で、RTTウィンドウのサイズは、ネットワークの輻輳につながる指数関数的な成長を避けることができる各RTTウィンドウごとに1つずつ増加するだけであり、サイズは最適値にゆっくりと調整されます。

送信中にタイマータイムアウトが発生した場合、TCPはネットワークが混雑しているとみなし、直ちに以下の処理を行います：

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

高速再送信

高速再送信は通常、高速リカバリーと一緒に行われます。受信機がシーケンス外のメッセージを受信すると、受信機は正しい順序にある最後のメッセージシーケンス番号でのみ返信します。3つの重複したACKを受信した場合、再送する前にタイマーのタイムアウトを待つ代わりに、高速再送が開始されます。特定のアルゴリズムは2つあります：

TCP Tahoは以下のように実装されています。

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

TCP Renoは次のように実装されています。

• 混雑ウィンドウが半分に
• 閾値を現在の輻輳ウィンドウに設定
• 高速回復フェーズへの移行
• 輻輳回避アルゴリズムの使用

TCP New Ren 改善された高速リカバリ

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との違い

まず、副作用とべき乗の概念を紹介します。

副作用とは、サーバー上のリソースに変更を加えることで、検索は副作用がなく、登録は副作用があります。

例えば、10個と11個のアカウントを登録することはidempotentではなく、10回と11回記事を変更することはidempotentです。

典型的なアプリケーションのシナリオとしては、Getはキーワードの検索など、副作用のない、べき等なシナリオで主に使用され、Postは登録など、副作用のない、べき等でないシナリオで主に使用されます。

技術的に言えば：

• Get リクエストはキャッシュされますが、Post リクエストはキャッシュされません。
• GetリクエストはURLに含まれ、ブラウザの履歴に保存されるのに対し、Postは保存されないため、GetよりもPostの方が少し安全ですが、パケットキャプチャの場合はすべて同じです。
• Postはリクエストボディを通してGetよりも多くのデータを転送できますが、Getにはこの技術がありません。
• URLには、Getリクエストに影響する長さの制限がありますが、この長さの制限は、RFCによってではなく、ブラウザによって課されます。
• Postはより多くのエンコーディング・タイプをサポートし、データ型に限定されません。

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

2XXの成功

• クライアントからのリクエストがサーバー側で正しく処理されたことを示す200 OK
• 204 No content リクエストは成功したが、応答メッセージにエンティティの主要部分が含まれ ていないことを示します。
• 205 Reset Content（コンテンツのリセット） リクエストが成功したことを示しますが、応答メッセージはエンティティの 主要部分を含んでいません。
• Partial Content，範囲要求

3XXリダイレクション

• 301は永続的に移動しました。リソースに新しいURLが割り当てられたことを示す永続的なリダイレクトです。
• リソースに一時的に新しいURLが割り当てられたことを示す一時的なリダイレクト。
• 303 の other は、そのリソースに別の URL が存在することを示しており、リソースを取得するには GET メソッドを使う必要があります。
• 304 not modifiedは、サーバーがリソースへのアクセスを許可したが、条件を満たさないリクエストの発生により
• 307一時的なリダイレクト、一時的なリダイレクト、302は似たような意味ですが、新しいアドレスにリクエストを送るために、クライアントがリクエストメソッドを変更しないことを期待します。

4XX クライアントエラー

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

5XXサーバーエラー

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

HTTP

追記 : キャッシュは別のモジュールに書かれています。

HTTPS

HTTPSはHTTPで情報を送信することに変わりはありませんが、情報はTLSプロトコルを使って暗号化されます。

TLS

TLSプロトコルはトランスポートレイヤーの上、アプリケーションレイヤーの下に位置します。最初のTLSプロトコルの転送には2RTTが必要ですが、セッション再開を使えば1RTTに減らすことができます。

TLSには対称暗号と非対称暗号という2つの暗号化技術があります。

対称暗号化：

対称暗号化とは、双方が同じ秘密鍵を持ち、双方が暗号文の暗号化と復号化の方法を知っている場合です。

非対称暗号化：

公開鍵と秘密鍵があり、公開鍵はすべての人に知られることができ、公開鍵でデータを暗号化することができますが、データの復号化は秘密鍵を使用して復号化する必要があります。

TLSハンドシェイクを以下に示します：

1. クライアントがランダムな値を送信、プロトコルと暗号化が必要
2. サーバは、クライアントから乱数値を受け取り、自ら乱数値を生成し、クライアントが要求するプロトコルや暗号化方式に応じて対応する方式で、自己の証明書を送信します。
3. クライアントはサーバーの証明書を受け取り、それが有効かどうかを検証した後、ランダムな値を生成し、サーバーの証明書の公開鍵でランダムな値を暗号化してサーバーに送信し、サーバーがクライアントの証明書を検証する必要がある場合は、証明書を添付します。
4. 暗号化された乱数値を受け取ったサーバは、それを秘密鍵で復号して3つ目の乱数値を得ます。このとき、両端は3つの乱数値を持ち、これを用いて合意した暗号化に従った鍵を生成し、次の通信はこの鍵で暗号化・復号すればよいのです。

上記のステップからわかるように、TLSのハンドシェーク・フェーズでは、両端が非対称暗号化を使用して通信を行いますが、非対称暗号化は対称暗号化よりもパフォーマンスが低下するため、正式にデータを送信する場合は、両端が対称暗号化を使用して通信を行います。

追記: 上記の説明はTLS 1.2プロトコルのハンドシェイクですが、1.3プロトコルでは、最初に接続を確立するときだけRTTが必要で、後で接続を再開するときはRTTは必要ありません。

HTTP 2.0

HTTP 2.0は、HTTP 1.Xに比べてウェブのパフォーマンスを劇的に向上させたと言えます。

HTTP 1.X では、スプライトチャート、小さなチャートのインライン化、複数ドメインの使用などがパフォーマンス上の理由から導入されました。これはすべて、ブラウザが同一ドメイン名でのリクエスト数を制限しているためで、ページ内で多くのリソースをリクエストする必要がある場合、キューヘッドブロッキングによってリクエストの最大数に達してしまい、残りのリソースはリクエストが開始される前に他のリソースがリクエストされるのを待つ必要があります。

HTTP 2.0がHTTP 1.Xと比較してどれだけ高速であるかは、 リンク 体感できます。

HTTP 1.Xでは、キューヘッダがブロックされるため、リクエストは次のようになります。

HTTP 2.0では、多重化が導入されたため、リクエストは次のようになります。

バイナリ転送

これがHTTP 2.0におけるパフォーマンス向上の核心です。以前のバージョンの HTTP では、データはテキストとして送信されました。HTTP 2.0 で導入された新しい符号化機構では、すべての送信データは分割され、バイナリ形式で符号化されます。

多重化

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

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

多重化、つまり、1つのTCPコネクションに複数のストリームを存在させる ことができます。言い換えると、複数のリクエストを送信することができ、相手側はフレーム内の識別によってどのリクエストがどれに属するかを知ることができます。このテクニックを使うことで、古いバージョンの HTTP におけるキューヘッダのブロッキング問題を回避することができ、転送のパフォーマンスを大幅に向上させることができます。

Header

HTTP 1.Xでは、ヘッダはテキストとして送信され、ヘッダがクッキーを運ぶ場合、数百または数千バイトを毎回再送する必要があるかもしれません。

HTTP 2.0 では、転送されるヘッダを符号化するために HPACK 圧縮形式が使われ、ヘッダのサイズが小さくなっています。両端には出現したヘッダを記録するためのインデックステーブルが保持され、記録されたヘッダのキー名は転送プロセスの後半で送信され、相手側はデータを受信したときにキー名から対応する値を見つけることができます。

サーバー側のプッシュ

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

次のような状況を想像することができます。クライアントからいくつかのリソースが要求された場合、サーバーサイドのプッシュ技術を利用して、必要なリソースを事前にクライアントにプッシュすることで、相対的に遅延時間を少し短縮することができます。もちろん、ブラウザの互換性の場合には、プリフェッチを使用することもできます。

QUIC

これはグーグルが提供する同じトランスポート層プロトコルのUDPベースの実装で、TCPを置き換えるという野心的な目標を掲げています。

• HTTP2.0も多重化をサポートしていますが、下位レイヤはTCPのままです。TCPは再送の仕組みがあるため、パケットが失われる限り、失われたパケットを判断して再送しなければならず、結果としてキューヘッダのブロッキング問題が発生しますが、UDPにはそのような仕組みがありません。
• TLS1.3はすでに0-RTTを実装していますが、TCPのようなTFOメカニズムによって0-RTTを実装することができます。
• 再送信とエラー訂正機構をサポートし、唯一のパケット損失の場合には再送信する必要はありません、失われたパケットを復元するためにエラー訂正機構を使用します。
  • エラー訂正メカニズム：非類似度によって、送信データの非類似値を計算し、別のパケットを発行し、サーバーは、パケットが失われたパケットを計算するために、他のパケットと非類似値のパケットを介して、失われていることがわかります。
  • それはカウントアウトすることはできませんので、2つのパケット以上の損失の場合には、再送信メカニズムを使用します。

DNS

DNSの目的は、ドメイン名を通して特定のIPを検索することです。

ドメイン名が生まれたのは、IPが数字と英語の組み合わせとして存在していたためで、これは人間の記憶には不都合です。ドメイン名はIPの別名と考えることができ、DNSはその別名の本当の名前を調べるために存在します。

DNSクエリはTCPハンドシェイクですでに実行されており、このクエリはオペレーティング・システム自体によって行われます。ブラウザでwww.google.com：

1. オペレーティング・システムは、まずローカル・キャッシュに
2. そうでない場合は、システムに設定されているDNSサーバーを検索します。
3. もし取得できなければ、DNSルートサーバーに直接照会に行き、この照会でcomの第1レベルドメイン名を担当するサーバーを調べます。
4. 次に、そのサーバーに行き、Googleのセカンドレベルドメイン名を調べます。
5. 次のサードレベルドメイン名のクエリが実際に設定されている場合、wwwドメイン名用のIPを設定し、さらに他のサードレベルドメイン名用のIPを設定することができます。

上記は、反復的なDNSクエリであり、また、再帰的なクエリがあり、違いは、前者はリクエストを行うには、クライアントであることです、後者はリクエストを行うには、システムのDNSサーバーによって構成され、データの結果がクライアントに返される取得します。

追記：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. DOMContentLoadedイベントは、最初のHTMLが完全に読み込まれ、解析されたときに発生します。
8. CSSOMツリーとDOMツリーが構築されると、レンダー・ツリーの生成が開始されます。レンダー・ツリーは、ページ要素のレイアウトやスタイル、その他多くのことを決定するステップです。
9. レンダー・ツリーを生成する過程で、ブラウザはGPUを呼び出して描画、レイヤーの合成、画面上のコンテンツの表示を開始します。