#はじめに
ブラウザにexample.comと入力すると、どのようにして正しいサーバーに接続されるのでしょうか？
DNSとCDNは、Webパフォーマンスの基盤となる技術です。これらを理解することで、サイトの読み込み速度を改善するための選択肢が広がります。
この記事を読むと、以下のことができるようになります：
- DNSによる名前解決の仕組みを理解できる
- CDNがパフォーマンスを向上させる原理がわかる
- DNS設定やCDN選定の基本的な判断ができる
#DNSとは
DNS（Domain Name System）とは、ドメイン名をIPアドレスに変換する仕組みです。
人間が覚えやすい名前（example.com）を、コンピューターが通信に使うIPアドレス（93.184.216.34）に変換します。
example.com → DNS → 93.184.216.34電話帳に例えると、「山田太郎」という名前から電話番号を調べるようなものです。
#DNS解決の流れ
ブラウザがドメイン名を解決する際の流れを見てみましょう。
1. ブラウザキャッシュを確認
↓ キャッシュになければ
2. OSのキャッシュ（hostsファイル含む）を確認
↓ なければ
3. リゾルバ（ISPのDNSサーバー等）に問い合わせ
↓ キャッシュになければ
4. ルートDNSサーバー → .com DNSサーバー → example.com DNSサーバー
↓
5. IPアドレスを取得#各段階の詳細
#1-2. ローカルキャッシュ
ブラウザとOSには、以前解決したドメインのキャッシュがあります。
# hostsファイルの例
127.0.0.1 localhost
192.168.1.10 myserver.local#3. リゾルバ
ユーザーに代わって名前解決を行うサーバーです。ISPやGoogleのPublic DNS（8.8.8.8）などが提供しています。
#4. 階層的な問い合わせ
リゾルバ → ルートサーバー
← ".comはこのサーバーに聞いて"
リゾルバ → .comサーバー
← "example.comはこのサーバーに聞いて"
リゾルバ → example.comの権威サーバー
← "93.184.216.34です"#DNSレコードの種類
| レコード | 用途 | 例 |
|---|---|---|
| A | IPv4アドレス | example.com → 93.184.216.34 |
| AAAA | IPv6アドレス | example.com → 2001:db8::1 |
| CNAME | 別名（エイリアス） | www.example.com → example.com |
| MX | メールサーバー | example.com → mail.example.com |
| TXT | テキスト情報 | SPF、ドメイン認証など |
#CDN利用時の設定例
# Aレコード（直接IPを指定）
example.com. A 93.184.216.34
# CNAME（CDNのホスト名を指定）
www.example.com. CNAME d1234.cloudfront.net.#TTL（Time To Live）
TTLは、DNSレコードをキャッシュしてよい時間（秒）です。
example.com. 300 A 93.184.216.34
^^^
TTL: 300秒（5分）#TTLの設定指針
| TTL | 用途 |
|---|---|
| 60-300 | IPを頻繁に変更する可能性がある場合 |
| 3600 | 一般的な設定 |
| 86400+ | ほぼ変更しないレコード |
短いTTLは変更が早く反映されますが、DNSサーバーへの問い合わせが増えます。
#DNSがパフォーマンスに与える影響
#DNS解決時間
DNS解決には20-120ms程度かかることがあります。
[DNS解決: 50ms] → [TCP接続: 30ms] → [リクエスト/レスポンス: 100ms]ページ内で多くのドメインにリクエストする場合、DNS解決の時間が積み重なります。
#改善策
- 外部ドメインの数を減らす
dns-prefetchでDNS解決を事前に行う（後の記事で詳しく）- 高速なDNSリゾルバを使用
#CDNとは
CDN（Content Delivery Network）とは、コンテンツを世界中のサーバーに分散配置し、ユーザーに近い場所から配信するネットワークです。
[オリジンサーバー: 東京]
↓ コンテンツを配信
┌─────────┼─────────┐
↓ ↓ ↓
[東京POP] [大阪POP] [福岡POP] ← POP: Point of Presence
↓ ↓ ↓
[東京の [大阪の [福岡の
ユーザー] ユーザー] ユーザー]#CDNが高速な理由
#1. 物理的な距離の短縮
データが伝わる速度には限界があります（光速でも地球の裏側まで約130ms）。ユーザーに近いサーバーから配信することで、ネットワークレイテンシーを削減できます。
東京→サンフランシスコ: 100ms
東京→東京エッジ: 5ms#2. キャッシュ
同じコンテンツを何度もオリジンから取得する必要がなくなります。
1回目: エッジ → オリジン → エッジ → ユーザー
2回目: エッジ → ユーザー（オリジンへのアクセス不要）#3. 最適化されたネットワーク
CDNは専用のネットワークインフラを持ち、一般的なインターネット経路より高速に通信できます。
#4. オリジンの負荷軽減
多くのリクエストをエッジで処理するため、オリジンサーバーの負荷が大幅に減少します。
#CDNの機能
現代のCDNは単なるキャッシュ以上の機能を持っています。
| 機能 | 説明 |
|---|---|
| キャッシュ | 静的コンテンツのエッジ配信 |
| 圧縮 | gzip/Brotli圧縮 |
| 画像最適化 | リサイズ、フォーマット変換 |
| SSL/TLS | 無料のHTTPS証明書 |
| DDoS対策 | 大規模攻撃からの保護 |
| WAF | Webアプリケーションファイアウォール |
| エッジコンピューティング | エッジでのスクリプト実行 |
#CDNの設定方法
#方法1: DNS変更
CNAMEでCDNを指すように設定します。
www.example.com. CNAME d1234.cloudfront.net.#方法2: リバースプロキシ
CDNがすべてのトラフィックを受け取り、必要に応じてオリジンに転送します。
[ユーザー] → [CDN] → [オリジン]
↓
キャッシュあれば返す#方法3: プルオリジン
CDNがオリジンからコンテンツを自動的に取得（プル）します。初回アクセス時にオリジンからフェッチし、以降はキャッシュを使用。
#主要なCDNサービス
| サービス | 特徴 |
|---|---|
| Cloudflare | 無料プランあり、幅広い機能 |
| Fastly | リアルタイムパージ、高度な設定 |
| AWS CloudFront | AWS連携、Lambda@Edge |
| Akamai | 最大規模のネットワーク |
| Vercel / Netlify | Jamstack向け、開発者体験 |
#DevToolsでの確認
#DNS解決時間
- NetworkタブでリクエストをクリックNLINE 2. Timingタブを確認
- 「DNS Lookup」の時間を確認
#CDNヘッダー
CDNはレスポンスに独自のヘッダーを追加することがあります。
# Cloudflare
cf-cache-status: HIT
cf-ray: 12345abcde
# CloudFront
x-cache: Hit from cloudfront#まとめ
- DNSはドメイン名をIPアドレスに変換する仕組み
- DNS解決には20-120ms程度かかる
- TTLでキャッシュ時間を制御
- CDNはコンテンツをユーザーに近い場所から配信
- CDNのメリット: 低レイテンシー、キャッシュ、オリジン負荷軽減
- 現代のCDNは圧縮、画像最適化、セキュリティ機能も提供
#次のステップ
DNSとCDNの基本がわかったところで、次は圧縮について学びましょう。gzipやBrotliを使ってデータサイズを削減し、転送時間を短縮する方法を紹介します。