本記事は James Kurose, Keith Ross 著 Computer Networking: A Top-Down Approach (6th Edition) の教科書を基にまとめた内容です。

1. メールプロトコル

1.1 インターネットメールシステムの構成要素

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

1. ユーザーエージェント（User Agent）

- メールの読み取り、作成、送信

- 例：Outlook、Gmail Web、Thunderbird

2. メールサーバー（Mail Server）

- メールボックス：受信メッセージの保管

- メッセージキュー：送信メッセージの待ち行列

3. SMTP（Simple Mail Transfer Protocol）

- メールサーバー間のメッセージ転送プロトコル

1.2 SMTPプロトコル

メール送信プロセス：

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でメッセージを読む

SMTPハンドシェイクの例

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

SMTPの特徴

| 特徴 | 説明 |

| -------------------------- | ------------------------------------ |

| TCP使用 | ポート25、信頼性のある転送 |

| プッシュ（Push）プロトコル | 送信者が受信サーバーに押し込む |

| 7ビットASCII | 本文は7ビットASCIIのみ（MIMEで拡張） |

| 持続接続 | 複数のメッセージを同じ接続で送信可能 |

SMTP vs HTTP比較

| 区分 | HTTP | SMTP |

| ---------------- | ---------------------------- | --------------------------------- |

| 方向 | Pull（クライアントが取得） | Push（サーバーが押し込む） |

| エンコーディング | バイナリ可能 | 7ビットASCII |

| オブジェクト処理 | 各オブジェクトが別レスポンス | すべてのオブジェクトが1メッセージ |

1.3 メールアクセスプロトコル

ユーザーがメールサーバーからメールを**読み出す**プロトコルはSMTPではない。

送信 受信

Alice UA ──SMTP──> メールサーバー ──SMTP──> メールサーバー ──POP3/IMAP/HTTP──> Bob UA

(Push) (Push) (Pull)

- **POP3**：シンプル、メールダウンロード後サーバーから削除（または保持）

- **IMAP**：サーバーにメッセージ保持、フォルダ管理可能、より複雑

- **Webベースメール**：HTTPを通じてアクセス（Gmail、Outlook.comなど）

2. DNS（Domain Name System）

2.1 DNSが提供するサービス

DNSは**ホスト名をIPアドレスに変換する**分散データベースシステムである。

ユーザー：www.example.comにアクセスしたい

↓

DNS問い合わせ：www.example.com → ?

↓

DNS応答：93.184.216.34

↓

HTTP接続：93.184.216.34:80

DNSの追加サービス

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順序をローテーション

2.2 DNSを集中化しない理由

集中化されたDNSの問題点：

├── 単一障害点：サーバー故障時にインターネット全体が麻痺

├── トラフィック量：全世界のDNS問い合わせ処理が不可能

├── 遠隔データベース：遅延時間の増加

└── 保守：単一データベースの更新が不可能

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

2.3 DNSの階層的構造

ルートDNSサーバー (.)

/ | \

.com .org .kr

/ \ | |

example google wiki naver

3種類のDNSサーバー

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マッピングを提供

ローカルDNSサーバー（Local DNS Server）

厳密には階層に属さないが、DNS構造で核心的な役割を果たす。

各ISPはローカルDNSサーバー（デフォルトネームサーバー）を持つ

- ホストがDNS問い合わせを送ると、ローカルDNSサーバーが代理問い合わせ

- 近くに設置されているため高速な応答

2.4 DNS問い合わせ方式

再帰的問い合わせ（Recursive Query）

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

|

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

各サーバーが次のサーバーに問い合わせを代行し

結果を受け取って前のサーバーに返す

反復的問い合わせ（Iterative Query）

ホスト → ローカルDNS ──問い合わせ──> ルートDNS

<──応答── 「TLDサーバーに聞いてください」

ローカルDNS ──問い合わせ──> TLD DNS

<──応答── 「権威サーバーに聞いてください」

ローカルDNS ──問い合わせ──> 権威DNS

<──応答── 「IPアドレス：93.184.216.34」

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

> 実際には**ローカルDNSからルート/TLD/権威サーバーへの問い合わせは反復的**、**ホストからローカルDNSへの問い合わせは再帰的**な混合方式が一般的である。

2.5 DNSキャッシング

DNSキャッシングの動作：

1. ローカルDNSサーバーが応答を受け取るとキャッシュに保存

2. 同じ名前の問い合わせ時にキャッシュから直接応答

3. TTL（Time To Live）後にキャッシュ期限切れ

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

3. DNSレコードとメッセージ

3.1 DNSリソースレコード（Resource Record）

DNSデータベースは**リソースレコード（RR）**を保存する。

形式：`(Name, Value, Type, TTL)`

| Type | Name | Value | 例 |

| ----- | -------- | ----------------------- | ------------------------------------- |

| A | ホスト名 | IPアドレス | (example.com, 93.184.216.34, A) |

| NS | ドメイン | 権威DNSサーバーホスト名 | (example.com, dns.example.com, NS) |

| CNAME | 別名 | 正式（canonical）名 | (www.ibm.com, east.us.ibm.com, CNAME) |

| MX | 別名 | メールサーバー正式名 | (example.com, mail.example.com, MX) |

3.2 DNSメッセージ形式

┌──────────────────────┐

│ ヘッダ（12 bytes） │

│ ID、フラグ、カウント │

├──────────────────────┤

│ 質問セクション │

│ 問い合わせ名、タイプ │

├──────────────────────┤

│ 回答セクション │

│ リソースレコード（RR） │

├──────────────────────┤

│ 権威セクション │

│ 権威サーバーRR │

├──────────────────────┤

│ 追加情報セクション │

│ 追加RR │

└──────────────────────┘

`nslookup` コマンドでDNS問い合わせを直接実行できる：

nslookup www.example.com

4. P2Pファイル配信

4.1 クライアント-サーバー vs P2P配信時間

`N` 人のピアにサイズ `F` のファイルを配信する時間を比較してみよう。

クライアント-サーバー方式

サーバーがN個のコピーを送信しなければならない：

D_cs >= max(NF/u_s, F/d_min)

u_s：サーバーのアップロード速度

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

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

P2P方式

すべてのピアがアップロードに貢献：

D_p2p >= max(F/u_s, F/d_min, NF/(u_s + sum(u_i)))

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

Nが増加すると → 総アップロード容量も増加！

→ 配信時間は対数的にのみ増加

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

時間

^

│ / クライアント-サーバー（線形増加）

│ /

│ / ___

│ / ____/ P2P（サブリニア）

│ / ___/

│//

└──────────────────> N（ピア数）

4.2 BitTorrent

最も広く使用されるP2Pファイル配信プロトコルである。

BitTorrent用語：

- トレント（Torrent）：ファイル配信に参加するピアの集合

- トラッカー（Tracker）：トレント参加ピアを追跡するサーバー

- チャンク（Chunk）：ファイルを分割した断片（通常256KB）

核心メカニズム

1. 最も希少なものを優先（Rarest First）：

ピアが隣接ピアから最も希少なチャンクを優先要求

→ 希少チャンクのコピー増加 → 可用性向上

2. Tit-for-Tat（報復戦略）：

自分に最も速くデータを送ってくれる4つのピアに優先送信

→ フリーライディング防止

3. 楽観的アンチョーキング（Optimistic Unchoking）：

30秒ごとにランダムなピアを1つ追加でアンチョーク

→ 新しいピアが参加する機会を提供

5. 分散ハッシュテーブル（DHT）

5.1 DHTの概念

P2Pシステムで**キー-バリューペア**を分散保存するデータベースである。

通常のハッシュテーブル：

key → hash(key) → バケット → value

分散ハッシュテーブル：

key → hash(key) → 担当ピア → value

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

5.2 循環DHT（Circular DHT）

ピアを円形に配列（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)メッセージに削減可能

6. まとめ

メールシステム：

├── SMTP：メールサーバー間Push転送（ポート25）

├── POP3/IMAP/HTTP：ユーザーがメールを読む（Pull）

└── 7ビットASCII、MIMEで拡張

DNS：

├── ホスト名 → IPアドレス変換

├── 階層的分散データベース

├── ルート → TLD → 権威DNSサーバー

├── 反復的/再帰的問い合わせ

└── キャッシングで性能向上

P2P：

├── 自己拡張性（ピア増加 → 容量増加）

├── BitTorrent：チャンクベース、Tit-for-Tat

└── DHT：分散キー-バリューストア

7. 確認問題

- **ルートDNSサーバー**：DNS階層の最上位。TLDサーバーのIPアドレスを提供する。

- **TLD（Top-Level Domain）サーバー**：.com、.org、.krなどのトップレベルドメインを担当。権威DNSサーバーのIPアドレスを提供する。

- **権威（Authoritative）DNSサーバー**：特定の組織のホスト名-IPマッピングを直接保有し、最終応答を提供する。

- **HTTP**：Pullプロトコル。クライアントがサーバーからデータを取得する。

- **SMTP**：Pushプロトコル。送信メールサーバーが受信メールサーバーにデータを押し込む。

- HTTPはバイナリデータを直接送信できるが、SMTPは7ビットASCIIのみ許可する。

- HTTPは各オブジェクトを別々のレスポンスで送るが、SMTPはすべてのオブジェクトを1つのメッセージに含める。

P2Pでは、ファイルをダウンロードするピアが同時に他のピアに**アップロード**も行う。ピア数が増加すると全体システムのアップロード容量も共に増加するため、配信時間は線形ではなく**サブリニア（sub-linear）**に増加する。