02 Application Layer

1. Network Application의 원리

1.1 Application Architecture

네트워크 애플리케이션을 설계할 때 가장 먼저 결정해야 하는 것은 아키텍처 모델이다. 크게 두 가지가 있다.

Client-Server 모델

Server: 항상 켜져 있는(always-on) 호스트. 고정된 IP 주소를 가진다. Data center에서 확장 가능
Client: Server에 접속하는 호스트. 간헐적으로 연결되며, 동적 IP 주소를 가질 수 있다. Client끼리는 직접 통신하지 않는다

대부분의 전통적인 서비스(Web, Email, FTP)가 이 모델을 따른다.

Peer-to-Peer (P2P) 모델

항상 켜져 있는 서버가 없다
임의의 end system끼리 직접 통신한다
Peer가 다른 peer에게 서비스를 요청하면서, 동시에 다른 peer에게 서비스를 제공한다
Self-scalability: 새로운 peer가 추가되면 서비스 수요도 늘지만, 서비스 용량도 함께 늘어난다
Peer는 간헐적으로 연결되고 IP 주소가 변할 수 있어 관리가 복잡하다
예시: BitTorrent, KanKan (streaming), VoIP (Skype)

1.2 Process와 Socket

네트워크에서 통신의 실제 주체는 호스트가 아니라 호스트 위에서 실행되는 process다.

같은 호스트 내의 process 간 통신은 OS가 관리하는 IPC(Inter-Process Communication)를 사용한다. 다른 호스트의 process 간 통신은 message 교환을 통해 이루어진다.

Socket은 process가 네트워크로 message를 보내고 받는 인터페이스(door)다. Application 개발자는 socket의 application 측은 제어할 수 있지만, transport 계층 아래의 동작은 OS가 관리한다. 개발자가 선택할 수 있는 것은 transport protocol(TCP or UDP)과 일부 parameter 정도다.

Process 주소 지정

다른 호스트의 process에 message를 보내려면 해당 process를 식별해야 한다. 이를 위해 두 가지 정보가 필요하다:

IP 주소: 호스트를 식별하는 32-bit 주소
Port 번호: 해당 호스트 내에서 process를 식별하는 번호

잘 알려진 port 번호로는 HTTP server: 80, HTTPS: 443, Mail server(SMTP): 25 등이 있다.

1.3 Application Layer Protocol의 구성 요소

Application layer protocol은 다음을 정의한다:

교환되는 메시지의 유형: Request, Response 등
메시지 문법(syntax): 메시지 내 필드의 구성과 구분 방식
메시지 의미(semantics): 각 필드에 담긴 정보의 의미
규칙(rules): Process가 언제, 어떻게 메시지를 보내고 응답하는가

Protocol의 종류:

Open protocol: RFC로 정의되어 누구나 접근 가능. 상호 운용성(interoperability)을 보장. 예: HTTP, SMTP
Proprietary protocol: 비공개 프로토콜. 예: Skype, Zoom

1.4 애플리케이션이 필요로 하는 Transport Service

애플리케이션마다 transport 계층에 요구하는 서비스가 다르다:

요구 사항	설명
Data Integrity	File transfer, 웹 등은 100% 신뢰성 있는 전송이 필요. Audio 등은 일부 손실 허용 가능
Throughput	Multimedia는 최소 throughput 보장 필요. 다른 앱(elastic app)은 가용한 만큼 사용
Timing	Internet telephony, 게임 등은 낮은 delay 필요 (수십 ms 이내)
Security	암호화, 데이터 무결성 등

각 애플리케이션별 transport service 요구 사항:

Application	Data Loss	Throughput	Time Sensitive
File transfer	No loss	Elastic	No
E-mail	No loss	Elastic	No
Web documents	No loss	Elastic	No
Real-time audio/video	Loss-tolerant	Audio: 5 Kbps - 1 Mbps, Video: 10 Kbps - 5 Mbps	Yes (~10 ms)
Streaming audio/video	Loss-tolerant	위와 동일	Yes (수 초)
Interactive games	Loss-tolerant	Kbps+	Yes (~10 ms)
Text messaging	No loss	Elastic	Yes and No

1.5 Internet Transport Protocol: TCP vs UDP

Internet은 애플리케이션에 두 가지 transport protocol을 제공한다:

특성	TCP	UDP
데이터 전달	Reliable transport	Unreliable data transfer
Flow control	O (수신자 과부하 방지)	X
Congestion control	O (네트워크 과부하 시 전송 억제)	X
Connection setup	O (connection-oriented)	X
Timing/throughput 보장	X	X
Security	X (기본적으로)	X

TCP와 UDP 모두 timing, minimum throughput, security를 기본적으로 보장하지 않는다.

UDP를 사용하는 이유

TCP가 더 많은 서비스를 제공하는데, 왜 UDP를 사용할까? UDP는 connection setup이 없어 지연이 적고, congestion control이 없어 전송 속도를 자유롭게 조절할 수 있다. 실시간 스트리밍이나 게임처럼 약간의 데이터 손실보다 지연이 더 중요한 경우에 적합하다.

주요 애플리케이션이 사용하는 transport protocol:

Application	Application Protocol	Transport Protocol
File transfer	FTP [RFC 959]	TCP
E-mail	SMTP [RFC 5321]	TCP
Web documents	HTTP [RFC 7230, 9110]	TCP
Internet telephony	SIP, RTP, proprietary	TCP or UDP
Streaming audio/video	HTTP, DASH	TCP
Interactive games	WOW, FPS (proprietary)	UDP or TCP

1.6 TLS로 TCP 보안 강화

기본 TCP/UDP socket은 암호화를 제공하지 않는다. 비밀번호를 포함한 cleartext가 그대로 Internet을 통과한다.

TLS (Transport Layer Security)는 이를 해결한다:

암호화된 TCP 연결을 제공
데이터 무결성(data integrity) 보장
End-point authentication 제공

TLS는 엄밀히 말해 transport 계층이 아니라 application 계층에서 구현된다. 애플리케이션이 TLS 라이브러리를 사용하여 cleartext를 socket에 넣으면, TLS가 이를 암호화하여 TCP를 통해 전송한다.

2. Web과 HTTP

2.1 Web의 구조

Web page는 여러 object로 구성된다. Object란 HTML 파일, JPEG 이미지, JavaScript 파일, 오디오 파일 등 하나의 URL로 주소 지정 가능한 파일을 말한다.

Web page의 구조:

Base HTML file을 중심으로 여러 referenced object를 포함
각 object는 URL (Uniform Resource Locator)로 주소가 지정됨
URL은 host name + path name으로 구성

2.2 HTTP 개요

HTTP (HyperText Transfer Protocol)는 Web의 application layer protocol이다.

Client-server 모델: Client(browser)가 HTTP를 사용하여 web object를 요청, 수신, 표시하고, Server는 HTTP를 사용하여 요청에 응답하여 object를 전송한다
HTTP는 TCP를 사용한다:
1. Client가 server의 port 80으로 TCP 연결을 시작
2. Server가 TCP 연결을 수락
3. HTTP message 교환
4. TCP 연결 종료

HTTP의 중요한 특성은 stateless라는 것이다. Server는 이전 client 요청에 대한 정보를 유지하지 않는다. 이렇게 설계한 이유는 state를 유지하는 프로토콜은 훨씬 복잡하기 때문이다 - server나 client가 crash하면 양쪽의 state가 불일치하게 되어 reconciliation이 필요하다.

2.3 HTTP 연결 방식

Non-persistent HTTP

하나의 TCP 연결을 통해 최대 하나의 object만 전송한다. 여러 object를 다운로드하려면 여러 개의 TCP 연결이 필요하다.

동작 과정 (10개의 JPEG 이미지를 참조하는 Web page 요청):

Client가 server port 80으로 TCP 연결 시작
Client가 TCP 연결 socket으로 HTTP request message 전송
Server가 요청된 object를 포함한 response message를 전송
Server가 TCP 연결을 닫음
Client가 HTML을 파싱하고, 10개의 JPEG 참조를 발견
각 JPEG에 대해 1-4 단계를 반복

Response time 분석:

RTT (Round Trip Time): 작은 packet이 client에서 server로 갔다가 되돌아오는 시간.

Non-persistent HTTP에서 하나의 object를 가져오는 데 걸리는 시간:

Response time = 2 \times RTT + file transmission time

1 RTT: TCP 연결 설정
1 RTT: HTTP 요청 전송 + 응답의 첫 바이트 수신
File transmission time: 파일 전송 시간

Non-persistent HTTP의 문제점:

Object마다 2 RTT가 소요된다
각 TCP 연결마다 OS overhead가 발생한다
브라우저는 이를 완화하기 위해 여러 TCP 연결을 병렬로 열어 referenced object를 동시에 가져온다

Persistent HTTP (HTTP 1.1)

Server가 response를 보낸 후 TCP 연결을 열어 둔다. 같은 client-server 간의 후속 HTTP message는 동일한 연결을 통해 전송된다.

Client는 referenced object를 발견하는 즉시 request를 전송할 수 있다
모든 referenced object에 대해 최소 1 RTT만 필요 (response time이 절반으로 줄어든다)

2.4 HTTP 메시지

HTTP 메시지에는 request와 response 두 가지 유형이 있다.

HTTP Request Message

ASCII(사람이 읽을 수 있는 형식)로 작성된다.

구조:

Request line: method, URL, HTTP version
Header lines: 추가 정보 (Host, User-Agent, Accept-Language 등)
Blank line (CR LF): 헤더의 끝을 표시
Entity body: POST 메서드 사용 시 데이터를 담는 부분

주요 HTTP Method:

Method	설명
GET	URL로 지정된 object를 요청. 가장 일반적
POST	Entity body에 사용자 입력 데이터를 담아 전송
HEAD	GET과 유사하지만 header만 반환 (디버깅용)
PUT	지정된 URL에 파일(object)을 업로드

GET으로 데이터 전송

GET 메서드로도 데이터를 전송할 수 있다. URL에 ? 뒤에 데이터를 붙이는 방식이다:
www.somesite.com/animalsearch?monkeys&banana

HTTP Response Message

구조:

Status line: Protocol version, status code, status phrase
Header lines: Date, Server, Content-Type, Content-Length 등
Entity body: 요청된 데이터

주요 HTTP Status Code:

Code	Phrase	의미
200	OK	요청 성공. 요청된 object가 body에 포함
301	Moved Permanently	요청된 object가 이동됨. 새 URL이 Location 헤더에 명시
400	Bad Request	서버가 요청을 이해하지 못함
404	Not Found	요청된 문서가 서버에 없음
505	HTTP Version Not Supported	서버가 해당 HTTP 버전을 지원하지 않음

2.5 Cookie를 이용한 상태 유지

HTTP는 stateless이지만, 많은 웹 서비스는 사용자를 식별해야 한다. Cookie는 이 문제를 해결하는 메커니즘이다.

Cookie 시스템의 네 가지 구성 요소:

HTTP response 메시지의 Set-cookie: 헤더
이후 HTTP request 메시지의 cookie: 헤더
사용자 브라우저에 저장되는 cookie 파일
웹 사이트의 backend database

동작 과정:

사용자가 처음 사이트에 접속하면, 서버는 고유 ID(cookie)를 생성하고 Set-cookie: 1678 헤더와 함께 응답
브라우저는 이 cookie를 저장
이후 같은 사이트에 접속할 때마다 cookie: 1678 헤더를 포함하여 요청
서버는 cookie를 통해 사용자를 식별하고 맞춤형 서비스 제공

Cookie의 용도:

로그인 상태 유지 (authorization)
장바구니 (shopping cart)
추천 시스템 (recommendations)
웹 메일 세션 상태 유지

Cookie와 Privacy

First-party cookie: 사용자가 방문한 사이트가 설정한 cookie
Third-party cookie: 사용자가 방문하지 않은 사이트(광고 네트워크 등)가 설정한 cookie. 여러 웹사이트에 걸쳐 사용자의 브라우징 행동을 추적할 수 있다

Third-party cookie를 통한 추적:

Firefox, Safari 브라우저에서는 기본적으로 차단
Chrome은 third-party cookie 폐기 계획을 한때 추진했으나 2024년에 철회. 현재는 기본 허용
EU의 GDPR (General Data Protection Regulation)에 의해, cookie가 개인을 식별할 수 있는 경우 개인정보로 취급되어 사용자 동의가 필요

2.6 Web Cache (Proxy Server)

Web cache(proxy server)는 origin server를 대신하여 HTTP 요청을 처리하는 네트워크 개체다.

동작 과정:

Browser가 모든 HTTP 요청을 web cache로 보낸다
요청된 object가 cache에 있으면 - cache가 바로 반환
없으면 - cache가 origin server에 요청하여 object를 가져오고, 저장한 후 client에 반환

Web cache는 client에 대해서는 server처럼, origin server에 대해서는 client처럼 동작한다.

Web caching의 이점:

Client의 response time 감소 - cache가 더 가까이 있으므로
기관의 access link 트래픽 감소 - 외부 Internet으로 나가는 트래픽이 줄어든다
Internet 전체적으로 효율적인 content delivery가 가능

Caching 예시

시나리오:

Access link: 1.54 Mbps
Origin server까지 RTT: 2초
Web object 크기: 100K bits
평균 요청률: 15건/초 (평균 데이터율: 1.50 Mbps)

문제: Access link utilization = 1.50/1.54 = 0.97 - 거의 100%에 가까워 queueing delay가 수 분 단위로 발생!

해결 방안:

Option 1: Access link를 154 Mbps로 업그레이드 - 비용이 매우 높다
Option 2: Web cache 설치 - 비용이 저렴

Cache hit rate이 0.4 (40%)인 경우:

40%의 요청은 cache에서 msec 단위로 처리
60%의 요청만 origin server로 전달
Access link를 지나는 데이터율 = 0.6 x 1.50 = 0.9 Mbps
Access link utilization = 0.9/1.54 = 0.58 - 여유 있음
평균 end-to-end delay = 0.6 x (2.01초) + 0.4 x (~msec) ≈ ~1.2초

154 Mbps 링크 업그레이드보다 더 낮은 delay를 훨씬 저렴하게 달성한다.

Conditional GET

Cache에 저장된 object가 최신인지 확인하는 메커니즘이다.

Client가 If-Modified-Since: <date> 헤더를 포함하여 요청
Server의 object가 해당 날짜 이후 수정되지 않았다면: 304 Not Modified (body 없음)
수정되었다면: 200 OK와 함께 새 object 반환

이를 통해 불필요한 object 전송을 방지하여 네트워크 자원을 절약한다.

2.7 HTTP/2와 HTTP/3

HTTP/2

HTTP/2 [RFC 7540, 2015]의 핵심 목표는 multi-object HTTP 요청의 delay를 줄이는 것이다.

HTTP/1.1의 문제점:

Pipelined GET을 도입했지만, server는 FCFS(First-Come-First-Served) 순서로 응답
큰 object 뒤에 작은 object가 대기하는 HOL (Head-of-Line) blocking 발생

HTTP/1.1에서는 큰 object $O_{1}$ 이 전송되는 동안 작은 object $O_{2}, O_{3}, O_{4}$ 가 뒤에서 대기한다.

HTTP/2의 해결:

Object를 frame 단위로 분할하고, frame 전송을 interleave(교차)한다
Client-specified priority에 따라 전송 순서를 결정 (반드시 FCFS일 필요 없음)
요청하지 않은 object를 server가 미리 전송하는 server push 기능
결과: 작은 object $O_{2}, O_{3}, O_{4}$ 가 훨씬 빨리 전달되고, $O_{1}$ 은 약간 지연됨

HTTP/3

HTTP/2도 여전히 단일 TCP 연결 위에서 동작하므로, packet loss가 발생하면 해당 TCP 연결의 모든 object 전송이 stall된다.

HTTP/3는 이를 해결한다:

TCP 대신 UDP 위에서 동작 (QUIC 프로토콜 사용)
각 object(stream)별로 독립적인 error recovery (한 stream의 packet loss가 다른 stream을 block하지 않음)
보안(TLS)이 기본 내장

3. E-mail: SMTP, IMAP

3.1 E-mail 시스템의 구성 요소

E-mail 시스템은 세 가지 핵심 구성 요소로 이루어진다:

User Agent (UA): 이메일을 작성, 편집, 읽는 프로그램. Outlook, Gmail 웹 인터페이스 등
Mail Server: 사용자의 mailbox(수신 메일 저장)와 message queue(발신 대기 메일)를 관리
SMTP (Simple Mail Transfer Protocol): Mail server 간에 이메일을 전송하는 프로토콜

3.2 SMTP [RFC 5321]

SMTP는 TCP를 사용하여 이메일을 전달하며, port 25를 사용한다.

SMTP의 세 단계:

Handshaking (greeting): 연결 설정 및 인사
Transfer: 메시지 전송
Closure: 연결 종료

SMTP는 HTTP와 마찬가지로 ASCII 기반의 command/response 방식이다:

Command: ASCII text (HELO, MAIL FROM, RCPT TO, DATA, QUIT)
Response: status code와 phrase (220, 250 Hello, 354, 등)

이메일 전송 시나리오

Alice가 Bob에게 이메일을 보내는 과정:

Alice가 User Agent로 이메일 작성 (To: bob@someschool.edu)
Alice의 UA가 SMTP로 Alice의 mail server에 메시지 전송 - message queue에 추가
Alice의 mail server의 SMTP client가 Bob의 mail server로 TCP 연결을 열고
TCP 연결을 통해 Alice의 메시지를 전송
Bob의 mail server가 메시지를 Bob의 mailbox에 저장
Bob이 User Agent로 메시지를 읽음

SMTP vs HTTP 비교

비교 항목	HTTP	SMTP
통신 방향	Pull (client가 server에서 가져옴)	Push (client가 server에 밀어넣음)
Object 전송	각 object가 별도 response message	여러 object가 하나의 multipart message
인코딩	바이너리 데이터 허용	Header와 body 모두 7-bit ASCII만 허용
연결 유지	HTTP/1.0: non-persistent, HTTP/1.1: persistent	Persistent connection 사용
메시지 종결	Content-Length 헤더 사용	`CRLF.CRLF`로 메시지 끝을 표시

3.3 Mail Message Format [RFC 2822]

SMTP 프로토콜의 command(MAIL FROM, RCPT TO)와 이메일 메시지 자체의 header(From:, To:, Subject:)는 다른 것이다. SMTP가 HTTP에 해당한다면, 메일 메시지 포맷은 HTML에 해당한다.

메일 메시지의 구조:

Header lines: To:, From:, Subject: 등
Blank line: 헤더와 body 구분
Body: 메시지 본문 (ASCII 문자만)

3.4 Mail Access Protocol

SMTP는 메일을 보내는(push) 프로토콜이다. 수신자가 자신의 mail server에서 메일을 가져오는(pull) 데는 별도의 프로토콜이 필요하다:

IMAP (Internet Mail Access Protocol) [RFC 3501]: 메시지를 서버에 저장하고, 서버에서 검색, 삭제, 폴더 관리 등을 수행
HTTP: Gmail, Hotmail 등 웹 기반 메일은 SMTP(발신)와 IMAP 또는 HTTP(수신)를 결합하여 웹 인터페이스를 제공

4. DNS (Domain Name System)

4.1 DNS의 필요성

사람은 이름(www.google.com)으로 호스트를 기억하지만, 네트워크 장비는 IP 주소(32-bit)를 사용한다. DNS는 이 둘을 변환해주는 시스템이다.

DNS의 본질:

수많은 name server의 계층으로 구현된 분산 데이터베이스(distributed database)
Host, DNS server 간 이름을 resolve(변환)하기 위한 application layer protocol

DNS는 Core Internet 기능이지만 Application Layer에 구현되어 있다

DNS는 Internet이 동작하는 데 필수적인 기능이지만, network core(router)가 아닌 network edge에서 application layer protocol로 구현되어 있다. 이는 Internet의 설계 철학 - 복잡성을 edge에 두는 것 - 을 반영한다.

4.2 DNS가 제공하는 서비스

Hostname-to-IP address translation: 가장 기본적인 기능
Host aliasing: 복잡한 canonical name에 대해 간단한 alias name 제공
Mail server aliasing: 도메인 이름에 대한 mail server 주소 제공
Load distribution: 하나의 이름에 여러 IP 주소를 매핑하여 replicated web server 간 부하 분산

4.3 왜 DNS를 중앙 집중화하지 않는가?

단일 중앙 DNS 서버를 사용하지 않는 이유:

Single point of failure: 하나의 서버가 다운되면 전체 Internet이 마비
Traffic volume: 모든 DNS 쿼리가 한 곳으로 집중 (Comcast만 하루 6,000억 쿼리)
Distant centralized database: 멀리 있는 사용자는 높은 지연
Maintenance: 모든 레코드를 한 곳에서 관리하는 것은 불가능

4.4 DNS의 계층 구조

DNS는 세 계층의 name server로 구성된다:

Root DNS Server

DNS 계층의 최상위. 이름을 resolve할 수 없는 name server가 마지막으로 접촉하는 곳
전 세계에 13개의 logical root server (A~M)가 있으며, 각각 수백 개의 복제본(replica)으로 구성
ICANN (Internet Corporation for Assigned Names and Numbers)이 관리
DNSSEC를 통해 authentication과 message integrity를 제공

TLD (Top-Level Domain) Server

.com, .org, .net, .edu, .gov 등의 도메인과 모든 국가 코드 도메인(.kr, .jp, .uk 등)을 담당
예: Verisign이 .com, .net TLD를 관리, Educause가 .edu를 관리

Authoritative DNS Server

조직이 소유한 호스트에 대한 공식적인 hostname-to-IP 매핑을 제공
조직 자체가 관리하거나, service provider에게 위탁 가능

Local DNS Server

엄밀히 DNS 계층에 속하지는 않지만, DNS에서 핵심적인 역할
각 ISP(가정 ISP, 대학, 기업)가 하나씩 운영
Host가 DNS 쿼리를 보내면 먼저 local DNS server로 전달
Local DNS server가 캐시에서 답을 찾거나, DNS 계층으로 쿼리를 전달

4.5 DNS Name Resolution

Iterated Query

engineering.nyu.edu의 호스트가 gaia.cs.umass.edu의 IP 주소를 알고 싶은 경우:

호스트가 local DNS server(dns.nyu.edu)에 쿼리
Local DNS가 root DNS server에 쿼리
Root가 .edu TLD server 주소를 반환
Local DNS가 TLD server에 쿼리
TLD가 umass.edu의 authoritative DNS server 주소를 반환
Local DNS가 authoritative server에 쿼리
Authoritative server가 최종 IP 주소를 반환
Local DNS가 호스트에 IP 주소를 반환

Iterated query에서는 접촉된 server가 “나는 모르겠지만, 이 server에 물어봐”라고 다음 server의 주소를 알려준다.

Recursive Query

Recursive query에서는 접촉된 server가 직접 쿼리를 해결한 뒤 결과를 반환한다. 상위 계층 server에 부하가 집중되는 단점이 있다.

4.6 DNS Caching

DNS server가 어떤 매핑을 학습하면, 이를 캐시에 저장하고 이후 같은 쿼리에 대해 즉시 응답한다.

캐시 항목은 일정 시간(TTL) 후 만료된다
TLD server 주소는 일반적으로 local DNS server에 캐시되어 있어, root server에 대한 쿼리 빈도가 실제로는 매우 낮다
캐시된 항목이 out-of-date일 수 있다 - 호스트의 IP 주소가 변경되면 모든 TTL이 만료될 때까지 전파되지 않는다
따라서 DNS는 best-effort name-to-address translation이다

4.7 DNS Record와 Message

Resource Record (RR)

DNS 데이터베이스의 기본 단위는 Resource Record (RR)다. 형식: (name, value, type, ttl)

Type	name	value	설명
A	hostname	IP address	호스트의 IP 주소
NS	domain	authoritative server hostname	도메인의 authoritative DNS server
CNAME	alias name	canonical name	별명에 대한 실제 이름
MX	domain	mail server name	도메인의 메일 서버

DNS Message Format

DNS query와 reply 메시지는 동일한 형식을 사용한다:

Header (12 bytes):
- Identification: 16-bit 쿼리 ID (reply가 같은 ID를 사용하여 매칭)
- Flags: query/reply, recursion desired/available, authoritative answer 등
- 각 섹션의 record 개수
Questions: 질의할 name, type
Answers: 질의에 대한 RR들
Authority: Authoritative server에 대한 RR들
Additional info: 부가적으로 유용한 RR들

4.8 DNS에 도메인 등록하기

새로운 도메인(예: networkutopia.com)을 등록하는 과정:

DNS registrar (예: Network Solutions)에 도메인 등록
Registrar에 authoritative name server의 이름과 IP 주소를 제공
Registrar가 .com TLD server에 NS record와 A record를 삽입:
- (networkutopia.com, dns1.networkutopia.com, NS)
- (dns1.networkutopia.com, 212.212.212.1, A)
Authoritative server에 해당 도메인의 A record, MX record 등을 설정

4.9 DNS Security

DDoS 공격: Root server나 TLD server에 대량 트래픽을 보내는 공격
- Root server 공격: 현재까지 성공한 사례 없음 (트래픽 필터링 + local DNS가 TLD server IP를 캐시하여 root server를 우회)
- TLD server 공격: 더 위험할 수 있음
Spoofing 공격: DNS 쿼리를 가로채고 위조된 응답을 반환 (DNS cache poisoning)
- 대응: DNSSEC [RFC 4033] - authentication service를 통해 DNS 응답의 진위를 검증

5. P2P File Distribution

5.1 Client-Server vs P2P: File Distribution Time

크기 $F$ 의 파일을 1개의 server에서 $N$ 개의 peer에게 배포하는 데 걸리는 최소 시간을 비교한다.

변수:

$u_{s}$ : Server upload 속도
$d_{i}$ : Peer $i$ 의 download 속도, $d_{min}$ : 최소 download 속도
$u_{i}$ : Peer $i$ 의 upload 속도

Client-Server 모델

D_{cs} \geq max {\frac{NF}{u _{s}}, \frac{F}{d _{min}}}

Server가 $N$ 개의 복사본을 순차적으로 upload: $NF / u_{s}$
가장 느린 client의 download 시간: $F / d_{min}$
$N$ 에 비례하여 선형 증가 - 확장성 문제

P2P 모델

D_{P 2 P} \geq max {\frac{F}{u _{s}}, \frac{F}{d _{min}}, \frac{NF}{u _{s} + \sum u _{i}}}

Server가 최소 1개의 복사본만 upload: $F / u_{s}$
가장 느린 client의 download 시간: $F / d_{min}$
전체 시스템의 총 upload 용량: $u_{s} + \sum u_{i}$
$N$ 이 증가해도, 각 peer가 upload 용량을 기여하므로 분모도 함께 증가

그래프에서 볼 수 있듯이, Client-Server 모델은 $N$ 에 비례하여 distribution time이 선형 증가하지만, P2P 모델은 peer 수가 늘어나도 distribution time이 크게 증가하지 않는다. 이것이 P2P의 self-scalability다.

5.2 BitTorrent

BitTorrent는 가장 널리 사용되는 P2P file distribution 프로토콜이다.

핵심 개념:

파일을 256KB chunk 단위로 분할
Torrent: 하나의 파일 chunk를 교환하는 peer들의 그룹
Tracker: Torrent에 참여 중인 peer를 추적하는 서버

Peer의 동작

새 peer가 torrent에 참여하면 tracker에서 peer 목록을 받아 일부 peer(neighbor)에 연결
다운로드하면서 동시에 다른 peer에게 chunk를 upload
Churn: Peer는 언제든 참여하거나 떠날 수 있다
파일을 전부 받은 peer는 떠나거나(selfish) 남아서 계속 upload(altruistic)

Chunk 요청과 전송 전략

Requesting: Rarest first - 가장 희귀한(가장 적은 peer가 보유한) chunk를 우선 요청. 이렇게 하면 희귀 chunk의 복사본이 빠르게 퍼져 availability가 균등해진다.

Sending: Tit-for-tat - 자신에게 가장 빠른 속도로 chunk를 보내주는 top 4 peer에게 chunk를 전송한다 (10초마다 재평가). 나머지 peer는 choke(전송 차단)한다.

매 30초마다 랜덤으로 하나의 peer를 선택하여 전송 시작 (optimistically unchoke)
이 peer가 높은 upload 속도를 가진다면 top 4에 진입할 수 있다
결과: upload 속도가 빠른 peer가 더 좋은 trading partner를 찾아 파일을 더 빨리 받는다

6. Video Streaming과 CDN

6.1 Video의 특성

Video는 Internet 트래픽의 대부분을 차지한다 (Netflix, YouTube, Amazon Prime 등이 가정 ISP 트래픽의 ~80%).

Video는 일정한 속도로 표시되는 이미지의 연속이다 (예: 24 frames/sec). 각 이미지(frame)는 pixel 배열이며, 압축(coding)을 통해 데이터 크기를 줄인다:

Spatial coding: 이미지 내 중복 활용 (같은 색상의 연속된 pixel → 색상값 + 반복 횟수)
Temporal coding: 연속 프레임 간 유사성 활용 (이전 프레임과의 차이만 전송)

인코딩 방식:

CBR (Constant Bit Rate): 고정된 인코딩 속도
VBR (Variable Bit Rate): 장면 복잡도에 따라 인코딩 속도가 변동

6.2 Streaming Stored Video

Video streaming의 주요 과제:

Server-to-client 대역폭이 시간에 따라 변동 (네트워크 혼잡)
Packet loss와 delay로 인한 video quality 저하 또는 buffering

핵심 개념:

Continuous playout constraint: 재생이 시작되면 원래 타이밍에 맞춰 연속적으로 재생되어야 한다
Network delay는 가변적(jitter)이므로, client-side buffer를 사용하여 네트워크 지연 변동을 흡수
Client는 일정량의 데이터가 buffer에 쌓일 때까지 기다린 후 재생을 시작한다 (playout delay)

6.3 DASH (Dynamic, Adaptive Streaming over HTTP)

DASH (Dynamic Adaptive Streaming over HTTP)는 현대 video streaming의 표준 방식이다.

Server 측:

Video 파일을 여러 chunk로 분할
각 chunk를 여러 다른 bit rate로 인코딩하여 별도 파일로 저장
이 파일들을 여러 CDN 노드에 복제
Manifest file: 각 chunk의 URL과 가용한 bit rate 목록을 제공

Client 측 (“intelligence”가 client에 있다):

주기적으로 server-to-client 대역폭을 추정
Manifest를 참조하여 한 번에 하나의 chunk를 요청:
- When: Buffer starvation이나 overflow가 발생하지 않도록 적절한 타이밍에
- What encoding rate: 현재 대역폭에서 유지 가능한 최대 화질로
- Where: 가장 가까운 또는 가용 대역폭이 높은 CDN 서버에서

핵심: Streaming video = encoding + DASH + playout buffering

6.4 CDN (Content Distribution Network)

수백만 개의 비디오 중 사용자가 선택한 것을 수십만 명의 동시 사용자에게 스트리밍하는 것은 단일 서버로는 불가능하다 (single point of failure, 혼잡, 먼 거리).

CDN은 컨텐츠 복사본을 지리적으로 분산된 여러 서버에 배치하여 해결한다:

전략	설명	예시
Enter deep	CDN 서버를 access network 깊숙이 배치. 사용자에게 가장 가까움	Akamai (240,000+ 서버, 120+ 국가)
Bring home	소수의 대형 cluster를 ISP의 POP(Point of Presence) 근처에 배치	Limelight Networks

OTT (Over The Top) 서비스 (Netflix 등)의 과제:

어떤 CDN 노드에 어떤 컨텐츠를 배치할 것인가?
어떤 CDN 노드에서 컨텐츠를 가져올 것인가? 어떤 bit rate로?

Netflix 예시:

Netflix는 자체 CDN인 OpenConnect를 전 세계에 운영
사용자가 컨텐츠를 요청하면 manifest file을 반환
Client는 manifest를 참조하여 가장 적합한 CDN 서버에서 최적의 bit rate로 chunk를 가져옴

7. Socket Programming

7.1 개요

Socket은 application process와 transport protocol 사이의 인터페이스다. Application 개발자는 socket의 application 측을 제어하고, transport 측 아래는 OS가 관리한다.

두 가지 socket 유형:

UDP socket: Unreliable datagram
TCP socket: Reliable, byte stream-oriented

7.2 UDP Socket Programming

UDP의 특징:

Client-server 간 사전 연결 설정이 없다 (no handshaking)
Sender가 각 packet에 목적지 IP 주소와 port 번호를 명시적으로 첨부
Receiver는 수신된 packet에서 sender의 IP 주소와 port 번호를 추출
전송된 데이터가 손실되거나 순서가 뒤바뀔 수 있다

UDP socket 통신 흐름:

Server: DatagramSocket()을 생성하고 특정 port에 바인딩, datagram 수신 대기
Client: DatagramSocket()을 생성, 서버 IP와 port를 지정하여 datagram 전송
Server: Datagram 수신, 처리(예: 대문자 변환), 응답 datagram 전송
Client: 응답 datagram 수신, 처리 후 socket 닫기

7.3 TCP Socket Programming

TCP의 특징:

Client가 server에 TCP 연결을 먼저 설정 (3-way handshake)
Server가 welcome socket으로 client의 연결 요청을 수락
연결이 수립되면 server는 해당 client 전용의 connection socket을 생성
이후 데이터는 이 connection socket을 통해 byte stream으로 교환
연결이 끝나면 socket을 닫음

TCP socket 통신 흐름:

Server: ServerSocket()을 생성하고 port에 바인딩, 연결 요청 대기 (accept())
Client: Socket()을 생성하며 서버 IP와 port를 지정 - TCP 연결 시작
Server: accept()가 반환되며 해당 client를 위한 connectionSocket 생성
양쪽이 socket의 input/output stream을 통해 데이터 교환
통신 완료 후 socket 닫기

UDP와의 핵심 차이:

TCP에서는 client가 데이터를 보낼 때 목적지 IP/port를 매번 지정할 필요가 없다 - 연결이 이미 수립되어 있으므로
TCP는 reliable 전송을 보장한다 - byte가 손실 없이, 순서대로 전달됨

8. Chapter 2 정리

주제	핵심 내용
Application Architecture	Client-server vs P2P. Socket이 process와 transport 간의 인터페이스
HTTP	Stateless, TCP 사용. Non-persistent(2 RTT) vs Persistent(1 RTT). Request/Response 메시지
Cookie	Stateless HTTP 위에서 사용자 식별. First-party vs Third-party. Privacy 이슈
Web Cache	Proxy server로 response time 감소, access link 트래픽 감소. Conditional GET
HTTP/2, HTTP/3	Frame interleaving으로 HOL blocking 완화. HTTP/3은 QUIC(UDP) 사용
E-mail	SMTP(push, port 25, TCP), IMAP(pull). 7-bit ASCII 인코딩
DNS	분산 계층 DB. Root → TLD → Authoritative. Iterated/Recursive query. RR type: A, NS, CNAME, MX
P2P	Self-scalability. BitTorrent: rarest first + tit-for-tat
Video/CDN	DASH (adaptive streaming). CDN: enter deep vs bring home
Socket Programming	UDP: connectionless, datagram. TCP: connection-oriented, byte stream

탐색기

회고

일상

정원

02 Application Layer

1. Network Application의 원리

1.1 Application Architecture

Client-Server 모델

Peer-to-Peer (P2P) 모델

1.2 Process와 Socket

Process 주소 지정

1.3 Application Layer Protocol의 구성 요소

1.4 애플리케이션이 필요로 하는 Transport Service

1.5 Internet Transport Protocol: TCP vs UDP

1.6 TLS로 TCP 보안 강화

2. Web과 HTTP

2.1 Web의 구조

2.2 HTTP 개요

2.3 HTTP 연결 방식

Non-persistent HTTP

Persistent HTTP (HTTP 1.1)

2.4 HTTP 메시지

HTTP Request Message

HTTP Response Message

2.5 Cookie를 이용한 상태 유지

Cookie와 Privacy

2.6 Web Cache (Proxy Server)

Caching 예시

Conditional GET

2.7 HTTP/2와 HTTP/3

HTTP/2

HTTP/3

3. E-mail: SMTP, IMAP

3.1 E-mail 시스템의 구성 요소

3.2 SMTP [RFC 5321]

이메일 전송 시나리오

SMTP vs HTTP 비교

3.3 Mail Message Format [RFC 2822]

3.4 Mail Access Protocol

4. DNS (Domain Name System)

4.1 DNS의 필요성

4.2 DNS가 제공하는 서비스

4.3 왜 DNS를 중앙 집중화하지 않는가?

4.4 DNS의 계층 구조

Root DNS Server

TLD (Top-Level Domain) Server

Authoritative DNS Server

Local DNS Server

4.5 DNS Name Resolution

Iterated Query

Recursive Query

4.6 DNS Caching

4.7 DNS Record와 Message

Resource Record (RR)

DNS Message Format

4.8 DNS에 도메인 등록하기

4.9 DNS Security

5. P2P File Distribution

5.1 Client-Server vs P2P: File Distribution Time

Client-Server 모델

P2P 모델

5.2 BitTorrent

Peer의 동작

Chunk 요청과 전송 전략

6. Video Streaming과 CDN

6.1 Video의 특성

6.2 Streaming Stored Video

6.3 DASH (Dynamic, Adaptive Streaming over HTTP)

6.4 CDN (Content Distribution Network)

7. Socket Programming

7.1 개요

7.2 UDP Socket Programming

7.3 TCP Socket Programming

8. Chapter 2 정리

목차

백링크

그래프 뷰