インターネットの仕組み

ブラウザ → DNS → TCP → HTTP → サーバー → データベース → レスポンス → レンダリング

高いレベルで見ると、Webリクエストは単一の操作ではなく、複数のシステムが連携するチェーンです。各ステップは、宛先の特定、通信の確立、リクエストの定義、ロジックの処理、データの取得、結果の返却といった、1つの特定の問題を解決するために存在します。

DNSは 「このサービスはどこにあるのか？」 に答え、TCPは 「どうすれば信頼性高く通信できるのか？」 に答え、HTTPは 「何が正確に要求されているのか？」 に答えます。サーバーとデータベースは 「システムは何を計算して返すべきか？」 に答えます。

これらのレイヤーは独立して動作しますが、順番に協調して動きます。システム全体を理解している単一のコンポーネントはなく、それぞれが自分の役割を果たして次へ制御を渡します。

ユーザーには一瞬で起きているように見えることも、実際にはミリ秒単位で実行される抽象化の構造化されたパイプラインです。

ユーザーがURLを入力すると、ブラウザは単に「ページを開く」だけではありません。まず入力を解析して、プロトコル（HTTPSなど）、ドメイン名、要求されたパスを特定します。

コンピュータは example.com のようなドメイン名を使ってトラフィックをルーティングできません。ネットワークは、数値の識別子であるIPアドレスで動作します。

ブラウザはローカルキャッシュを確認し、そのドメインのIPアドレスをすでに知っているかどうかを調べます。知らない場合は、名前をルーティング可能なIPアドレスに解決するためにDNSルックアップ処理を開始します。

この変換ステップが完了して初めて、システムは接続の確立に進めます。

DNSは、インターネット向けの分散ディレクトリとして設計されています。1つの中央データベースに依存するのではなく、責任を複数のサーバーレイヤーに分散することで、世界規模の利用を支えています。

ドメインがローカルでまだ知られていない場合、再帰リゾルバが検索を開始します。まずルートサーバーに問い合わせ、そこから .com や .org などの正しいトップレベルドメイン（TLD）サーバーの場所を案内されます。次にTLDサーバーが、その特定ドメインの権威ネームサーバーへリゾルバを誘導します。

権威サーバーが最終的なIPアドレスを返します。そのアドレスはクライアントに返され、ブラウザは次に進んで正しい宛先へのネットワーク接続を確立できます。

この階層的な設計により、DNSは整理され、拡張性が高く、毎日何十億もの検索を支えられるようになっています。

TCPは、すぐにアプリケーションデータの送信を開始するわけではありません。まず、SYN → SYN-ACK → ACK という3段階のプロセスで接続を確立します。

クライアントはまず、接続を要求するためにSYN（synchronize）メッセージを送信します。サーバーはSYN-ACKで応答し、要求を確認するとともに、自身の開始シーケンス番号を共有します。その後、クライアントはACKを送信して受信を確認します。この時点で、両者は初期シーケンス番号に合意し、相手側が準備完了であることを認識しています。

このやり取りによって、信頼性の高い配信の基盤が整います。TCPはシーケンス番号を追跡し、失われたパケットを検出し、不足しているデータを再送し、ネットワーク状況に応じて送信速度を調整します。

この調整のステップが完了して初めて、実際のアプリケーションデータが流れ始めます。

TCP はバイトの信頼性の高い配送を保証しますが、それらのバイトが何を意味するかは定義しません。HTTP は TCP の上位にあり、通信に構造と意味を与えます。クライアントが何かを要求する方法と、サーバーがどのように応答するかを定義します。

HTTP request には、GET や POST などの method、メタデータを記述する headers、そして必要に応じてデータを含む body が含まれます。サーバーは status code、headers、そして要求された content を返します。両者が同じルールに従うため、メッセージを一貫して解釈できます。

インターネットは共有システムであるため、HTTP は不可欠です。メッセージの構造と意図を定義する共通プロトコルがなければ、ブラウザとサーバーは互いを理解できません。HTTP は Web のための共通言語を作ります。

HTTP が定義するのは、何が要求され、何が返されるか であり、データがネットワーク上を物理的にどのように移動するかではありません。

データがマシンに届いても、自動的に「実行」されるわけではありません。オペレーティングシステムはネットワークデータを受け取り、ソケットを使って正しいプロセスへ振り分けます。これが、リクエストがサーバープログラムに届く仕組みです。

その後、OS が必要なリソースを管理します。サーバーが実行できるように CPU 時間をスケジューリングし、処理用のメモリを割り当て、ファイルやデータベースへのアクセスを制御します。オペレーティングシステムがこれらのリソースを調整しなければ、複数のリクエストを安全かつ効率的に処理することはできません。

リクエストがサーバープロセスに入ると、アプリケーションロジックが処理を引き継ぎます。HTTP メッセージを解釈し、必要な計算やデータベース検索を行い、レスポンスを構築します。

オペレーティングシステムは実行を可能にします。サーバーアプリケーションは振る舞いを定義します。

アプリケーションは、ユーザーアカウント、投稿、トランザクション、ログ、設定などのデータを常に生成します。このデータがメモリ上にしか存在しない場合、プログラムが再起動するたびに消えてしまいます。データベースは、ディスクや分散システム上に永続的な保存領域を提供することで、この問題を解決します。

しかし、保存するだけでは十分ではありません。データは構造化され、クエリ可能である必要があります。データベースは情報をテーブルやコレクションに整理し、アプリケーションがすべてを手動で走査しなくても特定のレコードを取得できるクエリ言語を提供します。

パフォーマンスを向上させるために、データベースはインデックスを使用します。インデックスは、検索用のマップのように機能する特殊なデータ構造です。すべての行を確認する代わりに、エンジンは関連するエントリへ直接移動できます。

データベースが重要なのは、現代のアプリケーションには永続的な状態が必要だからです。データベースがなければ、すべてのリクエストは独立して処理され、過去の操作を記憶できません。

ユーザーが同じリソースを複数回要求する場合、毎回ゼロから再計算するのは非効率です。キャッシュはレスポンスのコピーを保存することでこれを解決し、以後のリクエストをデータベースやアプリケーションロジックに再度アクセスせずに即座に返せるようにします。

キャッシュは複数の層に存在します。ブラウザ内、サーバー上、そしてネットワークのエッジです。Content Delivery Network (CDN) は、この考え方を世界規模に拡張し、コンテンツを地理的に分散したデータセンターへ配信します。常にオリジンサーバーへ問い合わせる代わりに、ユーザーは最も近いエッジロケーションへルーティングされます。

物理的な距離を短くするとネットワークレイテンシが下がり、繰り返しの計算を減らすとサーバー負荷が下がります。これらの最適化を組み合わせることで、スケール時のレスポンスタイムは大幅に改善されます。

ただし、キャッシュされたデータは古くなる可能性があるため、システムは速度とデータの新しさのバランスを取る必要があります。

インターネットのリクエストライフサイクルは、DNS、トランスポート、サーバー、データベースにまたがるため、どの段階でも問題が発生する可能性があります。DNS がドメインを解決できなければ、接続は始まりません。ネットワークがパケットを落としたり、TCP 接続が切断されたりすると、通信は中断されます。

リクエストがサーバーに届いた後でも、障害は起こりえます。サーバープロセスがクラッシュしたり、メモリ不足になったり、データベースへの接続に失敗したりすることがあります。遅い、または応答しないデータベースは、レスポンス全体を遅延させる可能性があります。

分散システムが一度にすべて失敗することはめったにありません。代わりに、1つのリージョン、1つのインスタンス、または1つの依存先が一度に部分的に失敗します。レジリエントなシステムを設計するには、複数のレイヤーにわたって冗長性、ヘルスチェック、リトライ、フォールバック機構を追加する必要があります。

障害がどこで発生しうるかを理解することは、実際のシステムがどのように動作するかを理解するうえで不可欠です。