본 포스팅은 James Kurose, Keith Ross의 Computer Networking: A Top-Down Approach (6th Edition) 교재를 기반으로 정리한 내용입니다.

1. 이메일 프로토콜

1.1 인터넷 이메일 시스템의 구성 요소

인터넷 이메일 시스템의 3가지 주요 구성 요소:

1. 사용자 에이전트 (User Agent)

- 이메일 읽기, 작성, 전송

- 예: Outlook, Gmail 웹, 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 메일 서버가 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.3 메일 접근 프로토콜

사용자가 메일 서버에서 이메일을 **읽어오는** 프로토콜은 SMTP가 아니다.

송신 수신

Alice UA ──SMTP──> 메일서버 ──SMTP──> 메일서버 ──POP3/IMAP/HTTP──> Bob UA

(Push) (Push) (Pull)

- **POP3**: 간단, 메일 다운로드 후 서버에서 삭제 (또는 보관)

- **IMAP**: 서버에 메시지 유지, 폴더 관리 가능, 더 복잡

- **웹 기반 이메일**: 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)

하나의 이름에 여러 IP 주소를 매핑

www.example.com → 93.184.216.34, 93.184.216.35, ...

DNS가 응답 시 IP 순서를 순환(rotate)

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개 피어에게 우선 전송

→ 무임승차(free-riding) 방지

3. 낙관적 언초킹 (Optimistic Unchoking):

30초마다 랜덤 피어 하나를 추가로 언초킹

→ 새로운 피어가 참여할 기회 제공

5. 분산 해시 테이블 (DHT)

5.1 DHT의 개념

P2P 시스템에서 **키-값 쌍**을 분산 저장하는 데이터베이스다.

일반 해시 테이블:

key → hash(key) → bucket → 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) 메시지 필요 (비효율적)

숏컷을 이용한 개선

각 피어가 몇 개의 바로가기(shortcut) 유지:

피어 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는 모든 객체를 하나의 메시지에 포함한다.

P2P에서는 파일을 다운로드하는 피어가 동시에 다른 피어에게 **업로드**도 한다. 피어 수가 증가하면 전체 시스템의 업로드 용량도 함께 증가하므로, 분배 시간이 선형이 아닌 **서브 선형(sub-linear)** 으로 증가한다.