インターネットメールシステムの3つの主要構成要素：

  1. ユーザーエージェント（User Agent）
     - メールの読み取り、作成、送信
     - 例：Outlook、Gmail Web、Thunderbird

  2. メールサーバー（Mail Server）
     - メールボックス：受信メッセージの保管
     - メッセージキュー：送信メッセージの待ち行列

  3. SMTP（Simple Mail Transfer Protocol）
     - メールサーバー間のメッセージ転送プロトコル

メール送信プロセス：

  AliceのUA → Aliceのメールサーバー → Bobのメールサーバー → BobのUA
                   SMTP転送              SMTP転送

  1. Aliceがメッセージ作成 → UAがAliceのメールサーバーに送信
  2. Aliceのメールサーバーがメッセージキューに保存
  3. SMTPクライアントがBobのメールサーバーのSMTPサーバーにTCP接続（ポート25）
  4. SMTPハンドシェイク後にメッセージ転送
  5. Bobのメールサーバーがメールボックスに保存
  6. BobがUAでメッセージを読む

S: 220 mail.example.com SMTP ready
C: HELO mail.alice.com
S: 250 Hello mail.alice.com
C: MAIL FROM: alice@alice.com
S: 250 OK
C: RCPT TO: bob@example.com
S: 250 OK
C: DATA
S: 354 Start mail input
C: From: alice@alice.com
C: To: bob@example.com
C: Subject: Hello
C:
C: Hi Bob, how are you?
C: .
S: 250 OK
C: QUIT
S: 221 Bye

送信                               受信
Alice UA ──SMTP──> メールサーバー ──SMTP──> メールサーバー ──POP3/IMAP/HTTP──> Bob UA
          (Push)                    (Push)                             (Pull)

ユーザー：www.example.comにアクセスしたい
  ↓
DNS問い合わせ：www.example.com → ?
  ↓
DNS応答：93.184.216.34
  ↓
HTTP接続：93.184.216.34:80

1. ホストエイリアシング（Host Aliasing）
   複雑な正式ホスト名にシンプルな別名を付与
   relay1.east.example.com → www.example.com

2. メールサーバーエイリアシング（Mail Server Aliasing）
   MXレコードでメールサーバーを指定
   example.comのメール → mail.example.com

3. 負荷分散（Load Distribution）
   1つの名前に複数のIPアドレスをマッピング
   www.example.com → 93.184.216.34, 93.184.216.35, ...
   DNSが応答時にIP順序をローテーション

集中化されたDNSの問題点：
  ├── 単一障害点：サーバー故障時にインターネット全体が麻痺
  ├── トラフィック量：全世界のDNS問い合わせ処理が不可能
  ├── 遠隔データベース：遅延時間の増加
  └── 保守：単一データベースの更新が不可能

→ DNSは分散階層型データベースとして設計！

                    ルートDNSサーバー (.)
                    /      |      \
               .com      .org     .kr
               /    \      |       |
         example   google  wiki   naver

1. ルートDNSサーバー（Root DNS Server）
   - 全世界13のルートサーバークラスター（A〜M）
   - TLDサーバーのIPアドレスを提供

2. TLDサーバー（Top-Level Domain Server）
   - .com、.org、.net、.kr、.jpなどを担当
   - 権威DNSサーバーのIPアドレスを提供

3. 権威DNSサーバー（Authoritative DNS Server）
   - 組織の公開ホストに対するDNSレコードを維持
   - 最終的なホスト名-IPマッピングを提供

各ISPはローカルDNSサーバー（デフォルトネームサーバー）を持つ
  - ホストがDNS問い合わせを送ると、ローカルDNSサーバーが代理問い合わせ
  - 近くに設置されているため高速な応答

ホスト → ローカルDNS → ルートDNS → TLD DNS → 権威DNS
                                                |
ホスト ← ローカルDNS ← ルートDNS ← TLD DNS ← 権威DNS

各サーバーが次のサーバーに問い合わせを代行し
結果を受け取って前のサーバーに返す

ホスト → ローカルDNS ──問い合わせ──> ルートDNS
                     <──応答── 「TLDサーバーに聞いてください」

         ローカルDNS ──問い合わせ──> TLD DNS
                     <──応答── 「権威サーバーに聞いてください」

         ローカルDNS ──問い合わせ──> 権威DNS
                     <──応答── 「IPアドレス：93.184.216.34」

ホスト ← ローカルDNS（最終応答）

DNSキャッシングの動作：
  1. ローカルDNSサーバーが応答を受け取るとキャッシュに保存
  2. 同じ名前の問い合わせ時にキャッシュから直接応答
  3. TTL（Time To Live）後にキャッシュ期限切れ

効果：ほとんどの問い合わせをルート/TLDサーバーなしで解決可能

┌──────────────────────┐
│   ヘッダ（12 bytes）   │
│  ID、フラグ、カウント   │
├──────────────────────┤
│     質問セクション     │
│  問い合わせ名、タイプ   │
├──────────────────────┤
│     回答セクション     │
│  リソースレコード（RR）  │
├──────────────────────┤
│     権威セクション     │
│  権威サーバーRR        │
├──────────────────────┤
│     追加情報セクション  │
│  追加RR               │
└──────────────────────┘

nslookup www.example.com

サーバーがN個のコピーを送信しなければならない：
  D_cs >= max(NF/u_s, F/d_min)

  u_s：サーバーのアップロード速度
  d_min：最も遅いクライアントのダウンロード速度

  Nが増加すると → 配信時間が線形に増加！

すべてのピアがアップロードに貢献：
  D_p2p >= max(F/u_s, F/d_min, NF/(u_s + sum(u_i)))

  sum(u_i)：すべてのピアのアップロード容量の合計

  Nが増加すると → 総アップロード容量も増加！
  → 配信時間は対数的にのみ増加

配信時間の比較（Nが増加する時）：

時間
  ^
  │     / クライアント-サーバー（線形増加）
  │    /
  │   /        ___
  │  /    ____/    P2P（サブリニア）
  │ / ___/
  │//
  └──────────────────> N（ピア数）

BitTorrent用語：
  - トレント（Torrent）：ファイル配信に参加するピアの集合
  - トラッカー（Tracker）：トレント参加ピアを追跡するサーバー
  - チャンク（Chunk）：ファイルを分割した断片（通常256KB）

1. 最も希少なものを優先（Rarest First）：
   ピアが隣接ピアから最も希少なチャンクを優先要求
   → 希少チャンクのコピー増加 → 可用性向上

2. Tit-for-Tat（報復戦略）：
   自分に最も速くデータを送ってくれる4つのピアに優先送信
   → フリーライディング防止

3. 楽観的アンチョーキング（Optimistic Unchoking）：
   30秒ごとにランダムなピアを1つ追加でアンチョーク
   → 新しいピアが参加する機会を提供

通常のハッシュテーブル：
  key → hash(key) → バケット → value

分散ハッシュテーブル：
  key → hash(key) → 担当ピア → value

  各ピアがキー空間の一部を担当

ピアを円形に配列（0 〜 2^n - 1）：

         0
       /   \
     15      1
    /          \
  14            2
  |              |
  13            3
  |              |
  12            4
    \          /
     11      5
       \   /
    10--9--8--7--6

キーkはk以上の最も近いピアが担当
例：キー11 → ピア12が担当

ピア3がキー11の値を探す場合：

  ピア3 → ピア4 → ピア5 → ... → ピア12

  順次的に後続ピアに問い合わせを転送
  → O(N)メッセージが必要（非効率的）

各ピアがいくつかのショートカットを維持：

  ピア3のショートカット：ピア4、ピア8、ピア14

  ピア3 → ピア8 → ピア12（3段階）

  → O(log N)メッセージに削減可能

メールシステム：
  ├── SMTP：メールサーバー間Push転送（ポート25）
  ├── POP3/IMAP/HTTP：ユーザーがメールを読む（Pull）
  └── 7ビットASCII、MIMEで拡張

DNS：
  ├── ホスト名 → IPアドレス変換
  ├── 階層的分散データベース
  ├── ルート → TLD → 権威DNSサーバー
  ├── 反復的/再帰的問い合わせ
  └── キャッシングで性能向上

P2P：
  ├── 自己拡張性（ピア増加 → 容量増加）
  ├── BitTorrent：チャンクベース、Tit-for-Tat
  └── DHT：分散キー-バリューストア