ネットワークの基本

DNS、TCP/IP、HTTP、IPアドレスなど、Web開発者が知っておくべきインターネットの仕組みを学びます。

学習をスタートする

ロードマップ

1

TCP/IP階層モデルとデータ送信の仕組み

私たちが日常的に利用しているWebサイトやアプリは、コンピュータ同士が複雑な仕組みを介して通信することで動作しています。本章では、ネットワーク通信の土台である TCP/IP階層モデル の概念と、データがどのように送信されるかについて解説します。 1. TCP/IP 4階層モデルとは? インターネットは、異なる機器やOS同士でも通信できるよう、通信手順をルール化した「プロトコル」の集まりで構成されています。このプロトコル群を4つの役割(階層)に分類した設計モデルを TCP/IPモデル と呼びます。 階層構造とプロトコル(図解) 2. 各階層の役割 1. アプリケーション層 (Application Layer): ユーザーが操作するソフトウェア(ブラウザやメールクライアントなど)と直接やり取りする層です。 - 主なプロトコル: HTTP(Webデータ転送)、HTTPS(暗号化Web転送)、DNS(ドメイン名前解決)。 2. トランスポート層 (Transport Layer): 接続された機器間で「信頼性のあるデータ転送」または「高速なデータ転送」を制御する層です。 - TCP (Transmission Control Protocol): 相手にデータが正しく届いたか確認(3ウェイハンドシェイク)しながら通信する、信頼性の高いプロトコル。Web閲覧やメールで使用。 - UDP (User Datagram Protocol): 確認を行わず、一方的にデータを送り続ける高速なプロトコル。動画ストリーミングやオンラインゲームで使用。 3. インターネット層 (Internet Layer): データを最終目的地までルーティング(経路制御)し、届ける役割を持ちます。 - 主なプロトコル: IP (Internet Protocol)。各機器には「IPアドレス」が割り当てられ、これがネット上の住所になります。 4. ネットワークインターフェース層 (Network Interface Layer): 同一ネットワーク内の隣接する物理機器(LANケーブル、Wi-Fiルーターなど)間で電気信号や電波を流し、データを物理的に伝送する層です。 3. カプセル化と非カプセル化 送信側コンピュータがデータを送信する際、上位層から下位層へデータが渡る過程で、各層に必要な制御情報(ヘッダー)が追加されていきます。これを カプセル化 (Encapsulation) と呼びます。 受信側コンピュータでは逆に、下位層から上位層へ渡る過程でヘッダーが取り除かれ、最終的に元のデータのみがアプリケーションに届きます。これを 非カプセル化 (Decapsulation) と呼びます。 まとめ * インターネットの通信は、役割が異なる TCP/IP 4階層モデル に基づいて行われる。 * TCP は接続の信頼性を担保し、IP は住所(IPアドレス)を元にデータを届ける。 * データ送信時はヘッダーを包み込む カプセル化 を行い、受信時はヘッダーを剥ぎ取る 非カプセル化 を行う。

2

DNSの名前解決とレコードの役割

コンピュータは 192.0.2.1 のような「IPアドレス」で通信相手を識別しますが、人間にとって数字の羅列は覚えにくいため、example.com のような「ドメイン名」を使用します。このドメイン名をIPアドレスに翻訳するシステムが DNS (Domain Name System) です。本章では、DNSの仕組みとレコードの役割について解説します。 1. DNSの基本概念と構成 DNSは、世界中に分散されたサーバーが連携して動作する、ツリー状の巨大な階層型データベースシステムです。 DNS名前解決のプロセス(図解) ブラウザが www.example.com のIPアドレスを問い合わせる際、以下のプロセス(反復問い合わせ)が行われます。 1. キャッシュDNSサーバー: クライアントからの問い合わせを受け、代わりに名前解決を代行します。一度解決した情報は一定期間(TTL)キャッシュします。 2. 権威DNSサーバー(ネームサーバー): 自身が管理するドメインの正しいIPアドレス情報を保持しており、問い合わせに対して直接回答を返します。 2. 主要なDNSレコードの種類 DNSサーバーには、ドメインに関する様々な情報が「リソースレコード」と呼ばれる形式で登録されています。 * A レコード (Address): ドメイン名を IPv4 アドレスに対応付けます。 * AAAA レコード (Quad-A): ドメイン名を IPv6 アドレスに対応付けます。 * CNAME レコード (Canonical Name): ドメイン名のエイリアス(別名)を設定します。別のドメイン名に向けて転送したい場合に使用します。 * MX レコード (Mail Exchange): そのドメイン宛てのメールを受信するメールサーバー(SMTPサーバー)を指定します。 * TXT レコード (Text): ドメインに紐付ける任意の文字列を登録します。主に、ドメインの所有権確認や、スパムメール対策の SPF や DKIM 設定に使用されます。 まとめ * DNS はドメイン名(人間用)とIPアドレス(機械用)を変換するシステム。 * 名前解決は、キャッシュDNSサーバー が ルートサーバー から順に辿って 権威サーバー に問い合わせることで完了する。 * Aレコード、CNAMEレコード、TXTレコード などのリソースレコードをDNSサーバーに登録することでドメインの振る舞いを制御する。

3

HTTPプロトコルの進化(HTTP/1.1からHTTP/3)

Webの基幹プロトコルである HTTP(Hypertext Transfer Protocol) は、Webコンテンツの巨大化や高速化の要求に伴い、劇的な進化を遂げてきました。本章では、HTTP/1.1から現在のHTTP/3に至るまでのプロトコルの変遷と、それぞれの仕組みの違いについて解説します。 1. HTTP/1.1 の仕組みと課題 1997年に標準化された HTTP/1.1 は、長い間Webの標準として使われてきました。 主な特徴 * Keep-Alive: 一度のTCP接続を確立したあと、複数のリクエスト/レスポンスで使い回せるように接続を維持する仕組み。 課題:ヘッドオブラインブロッキング (Head-of-Line Blocking) HTTP/1.1では、同一の接続上では「リクエストを送信したら、そのレスポンスが返ってくるまで次のリクエストの処理を待たなければならない」という制限がありました。そのため、時間のかかるリソースの読み込みがあると、後ろにある他のリソースの読み込みがすべてストップしてしまいます。 これを回避するため、ブラウザはドメインごとに最大6本程度のTCP接続を同時に張って並列処理していましたが、通信オーバーヘッドが大きく限界がありました。 2. HTTP/2 による高速化(多重化) 2015年に登場した HTTP/2 では、通信速度を飛躍的に向上させるため、HTTP/1.1の根本的なデータ転送方式が見直されました。 主な特徴 * ストリームの多重化: 単一のTCP接続の中でデータを「フレーム」と呼ばれる細かい単位に分割し、複数のリクエストとレスポンスを同時に並行して送信できるようにしました。これにより、HTTPレイヤーでのヘッドオブラインブロッキングが完全に解消されました。 * ヘッダー圧縮 (HPACK): 重複するヘッダー情報をハッシュ化して圧縮送信することで、無駄な通信量を削減しました。 3. HTTP/3 と QUIC(TCPからUDPへ) HTTP/2でHTTPレイヤーの詰まりは解消されましたが、今度は 「TCPレイヤー」でのヘッドオブラインブロッキング が問題になりました。TCP接続ではパケットロスが発生すると、そのパケットが再送されて順序が揃うまで、カーネルレベルで他のすべてのデータの処理が一時停止してしまうためです。 2022年に標準化された HTTP/3 では、信頼性を保証する従来の TCP を捨て、速度重視の UDP の上に新しい信頼性制御レイヤー QUIC(クイック) を重ねたプロトコルを採用しました。 主な特徴 * TCPのヘッドオブラインブロッキング解消: QUIC接続下では、個々のストリームが独立して処理されるため、あるパケットがロスしても、他の無関係なストリームのデータ転送は一切止まりません。 * 接続確立の高速化 (0-RTT): TCPの3ウェイハンドシェイクとTLSのハンドシェイクを統合し、通信開始時に必要な往復回数(Round Trip)を劇的に減らすことで、通信開始を高速化しました。 まとめ * HTTP/1.1: レスポンスを順番に待つ必要があり、ヘッドオブラインブロッキング が発生しやすい。 * HTTP/2: 単一のTCP接続で複数のデータを並行送信する 多重化 とヘッダー圧縮を導入。 * HTTP/3: 信頼性の保証をTCPから UDP/QUIC に移行し、パケットロス時の停止を回避して接続を高速化。

4

CDNとキャッシュ制御

Webサイトやアプリケーションの読み込み速度を圧倒的に高速化し、サーバー(オリジン)の負荷を下げるために欠かせない技術が 「CDN (Content Delivery Network)」 です。CDNを正しく動かすためには、HTTPヘッダーを使用した正確な「キャッシュ制御」の知識が必要になります。 第4章では、CDNの仕組みと、ブラウザやエッジサーバーでのキャッシュ制御方法について学びます。 1. CDNの仕組み(オリジンとエッジ) 通常、ユーザーがWebサーバーにリクエストを送ると、1つの本番サーバー(オリジンサーバー)がすべてを処理します。しかし、アクセスが集中するとサーバーがダウンしてしまいます。 CDNを導入すると、世界中に配置された複数のキャッシュサーバー 「エッジサーバー(POP: Point of Presence)」 がユーザーに最も近い位置でリクエストを肩代わりします。 1. キャッシュヒット: エッジサーバーに要求されたファイル(画像、CSS、JS、HTML等)がある場合、オリジンまで通信せずエッジから超高速に返します。 2. キャッシュミス: エッジサーバーにファイルがない場合のみ、オリジンにファイルを取りに行き(フェッチ)、自身に保存(キャッシュ)した上でユーザーに返却します。 2. HTTPヘッダーによるキャッシュ制御 サーバーは、レスポンスの Cache-Control ヘッダー を通じて、ブラウザやCDNに対して「このファイルはどのくらいの間、誰がキャッシュして良いか」を指示します。 主要なディレクティブ(指示子) * public: ブラウザだけでなく、CDNなどの共有キャッシュサーバーにもキャッシュして良いことを示します。 * private: ログイン後のユーザーページなど、個人向けのレスポンスであるため、ブラウザにのみキャッシュし、CDNにはキャッシュさせないことを指定します。 * max-age=: ブラウザ(クライアント)でのキャッシュ有効期限(秒数)を設定します。 * s-maxage=: CDN(共有キャッシュ)専用の有効期限を設定します。 * no-cache: キャッシュ自体は作成しても良いですが、利用する前に必ずサーバーへ「ファイルが更新されていないか(If-None-Match 等)」を問い合わせる(バリデーションする)ことを強制します。 * no-store: 個人情報や決済情報など、セキュリティ上一切のキャッシュ(ブラウザ・CDN両方)を禁止します。 3. キャッシュの破棄(無効化) 一度エッジサーバーやブラウザにキャッシュされたファイルは、有効期限が切れるまでオリジンへの確認なしで表示され続けます。そのため、プログラムを修正してデプロイしても、古いキャッシュのせいでユーザーに反映されない問題(キャッシュスタック)が発生します。 解決策 1. ファイル名にハッシュ値を付与する( Cache Busting ): * アプリケーションビルド時に、ファイル名にコンテンツのハッシュ値を埋め込みます(例: main.a8f9c2.js)。ファイル内容が変わると名前も変わるため、キャッシュを無視して新しいファイルが必ず読み込まれます(推奨)。 2. キャッシュパージ(Cache Purging): * CDNの管理画面やAPIから、エッジサーバーにある特定のキャッシュデータを明示的に削除(パージ)します。 キャッシュ設定を誤ると、全ユーザーの画面に他人の個人情報が表示されてしまうような重大なセキュリティ事故に繋がることがあります。そのため、動的データには private や no-store を徹底し、静的ファイル(Assets)には長期間の public キャッシュを設定するなど、データの性質を見極めた設計が重要です。

5

HTTPS暗号化とTLSハンドシェイク

インターネット上でクレジットカード番号やパスワードなどを安全に送受信するために欠かせないのが 「HTTPS(HTTP over TLS/SSL)」 です。HTTPSは「盗聴」「改ざん」「なりすまし」の3つのリスクを防ぐ技術です。 第5章では、HTTPS通信を支える暗号化の仕組みと、接続時に行われる 「TLSハンドシェイク」 の具体的な流れについて学びます。 1. ハイブリッド暗号方式の仕組み HTTPSでは、安全にデータを届けるために 「公開鍵暗号」 と 「共通鍵暗号」 の両方のメリットを組み合わせた 「ハイブリッド暗号方式」 を採用しています。 * 共通鍵暗号方式(対称鍵): 暗号化と復号に同じ鍵を使う。処理が非常に高速だが、鍵を相手にどうやって安全に渡すか(鍵配送問題)という弱点がある。 * 公開鍵暗号方式(非対称鍵): 誰でも使える「公開鍵」で暗号化し、自分だけが持つ「秘密鍵」でしか復号できない。鍵の受け渡しは安全だが、処理が非常に重い。 ハイブリッド方式の回答 最初に「公開鍵暗号」を使って、その後の通信で使う「共通鍵(セッションキー)」を安全に相手に渡します。鍵が共有された後は、処理が圧倒的に軽い「共通鍵暗号」でデータを暗号化して通信します。 2. TLSハンドシェイクのステップ ブラウザとサーバーがHTTPS接続を確立する際、データの送受信を開始する前にお互いの合意をとる儀式が 「TLSハンドシェイク」 です。以下は一般的な TLS 1.2 / 1.3 の基本的な流れを簡略化したものです。 1. Client Hello: ブラウザからサーバーへ、サポートしている暗号の種類(暗号スイート)やランダムな数値を送ります。 2. Server Hello + 証明書送信: サーバーからブラウザへ、使用する暗号の決定通知、サーバーの公開鍵が含まれた「SSL/TLSデジタル証明書」を送ります。 3. 証明書の検証: ブラウザは、証明書が信頼できる第三者機関(認証局: CA)によって署名されたものか、ドメイン名が一致しているかを検証します。 4. 鍵共有: サーバーの公開鍵を使って、共通鍵の元となるデータ(プレマスタシークレット)を暗号化してサーバーへ送ります(サーバーは秘密鍵で復号)。 5. 完了通知 (Finished): 互いに同じ共通鍵を算出し、以降の通信を暗号化して完了します。 3. TLS 1.3 による高速化 2018年に正式策定された TLS 1.3 は、セキュリティ強度の向上だけでなく、パフォーマンスが劇的に改善されました。 * 1-RTTの実現: TLS 1.2 ではハンドシェイクに往復(2-RTT)の通信が必要でしたが、TLS 1.3 では鍵交換のプロセスを効率化し、最初の往復(1-RTT)だけで安全な接続を確立できます。 * 0-RTT(Resumption): 過去に一度接続したことのあるサーバーに対しては、ハンドシェイクの往復なし(0-RTT)で、最初の最初から暗号化データを送信できる仕組み(Session Resumption)が導入されています。 HTTPSの裏側で行われているこれらの精密なステップにより、私たちは日常的にクレジットカードや個人情報を漏洩の不安なくWebサイトに入力することができています。