comnet-05

Chapter 2. Application Layer(3)- DNS, P2P

DNS: Domain Name System

DNS(Domain Name System)이란?
사람들이 사용하는 이름을 컴퓨터가 이해할 수 있는 IP 주소로 변환해 주는 시스템이다.
사람에게도 이름, 학번 등 여러 가지 identifier가 있듯이, 인터넷 호스트도 IP 주소, 도메인 이름 같은 identifier을 가진다.

DNS는 많은 name server가 계층적으로 연결되어 있는 분산 데이터베이스(distributed database) 방식이며, 호스트와 name server가 서로 통신하여 이름을 해석하는 application-layer protocol을 사용한다.

DNS의 주요기능
hostname을 IP 주소로 변환해 준다.
host와 mail server에게 별칭(aliasing)을 지어준다. (canonical name, alias name)
같은 이름에 여러 IP주소를 매핑하여 트래픽을 분산시키는 load distribution(부하 분산)을 해준다.

Name Space
고유한 주소를 고유한 이름으로 매핑하는 구조이다. DNS에서는 계층형(hierarchical) name space를 사용한다.

DNS의 Domain Name Space는 여러 개의 label로 구성된 이름으로 최대 128단계의 트리 구조를 가진다.
각 노드가 label(최대 63자)를 가지며, 루트는 공백 문자열("")로 표시한다. 유일성을 보장하기 위해 각 노드의 자식은 서로 다른 label을 가진다.
ex) www.hongik.ac.kr. - www는 hongik의 자식, hongik은 ac의 자식...

Fully qualified domain name(FQDN): 마지막에 . (+NULL string)까지 포함된 전체 도메인
Partially qualified domain name: www, honigk.ac.kr 등처럼 생략된 이름

name: 개별 host name ex) www.test.com
domain: 이름 집합의 공간(namespace) ex) .com, test.com
zone: 실제로 권한이 있는 DNS 서버가 관리하는 도메인 부분

DNS는 전 세계적으로 분산된 계층형 데이터베이스이다. 루트부터 점점 하위로 내려가며 질의(Query)를 전달한다.

Root Name Servers: contact-of-last-resort, 도메인 이름을 해결하지 못한 다른 name server들이 마지막으로 의존하는 서버이다.
TLD(Top Level Domain): .com, .ord, .edu 등으로 Root DNS 서버가 TLD 서버의 위치를 알려준다. TLD 서버는 해당 도메인들에 대한 질의 처리를 담당한다.
Authoritative DNS server: 특정 도메인에 대한 최종 결정권을 가진 서버로 최종적으로 hostname에 의한 IP 주소를 반환한다.

예시) www.amazon.com
클라이언트가 root server에 .com DNS 서버의 위치를 질의
.com DNS 서버에 amazon.com DNS 서버의 위치를 질의
amazon.com DNS 서버에 질의하여 최종적으로 www.amazon.com의 IP 주소를 받아온다.

이 과정을 Authority delegation(권한 이항)이라고 부르며, 위임의 형태로 점점 구체적인 서버로 내려가며 정보를 얻는다.

Local DNS name servers (default name server)
계층 구조에는 속하지 않지만 DNS 질의의 시작점 역할을 한다. 실제로 트래픽 대부분을 중간에서 처리해 주는 중요한 역할을 한다.
local DNS가 없다면 매 질의마다 Root server까지 요청해서 비효율적이다.

<동작방식>
사용자의 컴퓨터(host)가 DNS 질의를 하면 local DNS server로 요청한다.
local DNS server는 최근이름과 주소 매핑 캐시를 보유하고 있어서 속도가 빠르다. 직접 못 찾으면 상위 DNS 계층 구조로 요청하여 대리인(proxy)처럼 전달해 준다.

<cse.nyu.edu에 있는 호스트가 gaia.cs.umass.edu의 IP주소를 알고 싶은 상황>

1) DNS name resolution: iterated query

1. 사용자가 local DNS 서버에 질의 (1)
2. local DNS가 Root DNS 서버에 질의 (2) , Root DNS가 TLD DNS로 권한 이항하여 TLS DNS 주소 제공 (3)
3. local DNS가 TLD(.edu) DNS 서버에 질의 (4) , TLD: authoritative DNS 서버에게 권한 이항 (5)
4. local DNS가 authoritative DNS 서버에 질의 (6)
5. IP 주소 응답을 받아 사용자에게 전달 (7,8)

질의 처리 주체가 local DNS 서버이기 때문에 단계별로 수동 질의해야 하지만 상위 서버나 네트워크의 부하가 적다.

2) DNS name resolution: recursive query

1. 사용자가 local DNS 서버에 질의 (1)
2. local DNS가 Root DNS 서버에 질의 (2)
3. 이후 질의 처리를 Root가 책임지고 아래로 내려가며, Root - TLD - authoritative (3~6)
4. IP 주소를 local DNS에게 반환 (7)
5. local DNS가 사용자에게 전달 (8)

질의 처리 주체가 상위 DNS 서버들이므로 사용자 입장에서는 간단하지만 상위 서버의 부하가 많다는 단점이 있다.

DNS 캐싱(Caching)
어떤 name server든 한 번 name-IP 주소 매핑 정보를 알게 되면 캐시에 저장한다. 이 캐시는 일정 시간 후 만료(timeout)된다. 이 만료시간을 TTL(Time To Live)라고 한다.

반복되는 질의를 빠르게 처리할 수 있어서 Root/TLD 서버 방문을 줄일 수 있다. 하지만, cached entry가 오래되었을 수 있다는(out of date) 점을 주의해야 한다.

DNS Records(DNS 리소스 레코드, RR)
어떤 도메인에 대한 정보(name)와 그에 대한 값(value)을 저장한다. 기본 포맷은 (name, value, type, ttl)이다.

주요 Record Type 종류	이름
type=A	name은 호스트 이름, value는 IP 주소
type=NS	name은 도메인 이름, value는 해당 도메인을 관리하는 권한 있는 DNS 서버의 이름
type=CNAME	name은 별칭(alias), value는 정식 이름(canonical name)
type=MX	value는 메일 서버 이름, name은 메일을 받을 도메인

<DNS protocol messages (query/reply)>

message header
identification: 16bit로 요청과 응답을 연결하기 위한 고유 ID
flags: query/reply, authoritative 여부, recursion 요청/가능 여부 등

body
questions: name, type, class 등 질의 관련 정보
answers: 요청에 대한 응답(RR)
authority: 권한이 있는 서버들 정보
additional info: 캐시 된 정보 등의 추가 관련 정보

예시)

0x0100: flag 필드- 일반적인 query를 나타낸다.
"hongik.ac.kr."의 도메인 이름은 6 hongik, 2 ac, 2 kr, 0(NULL)과 같이 길이-문자열 형식으로 표현된다.

DNS 레코드 등록 과정 예시: networkutopia.com이라는 스타트업 도메인 등록

1. DNS Registrar(등록 대행자)에게 도메인 이름 등록을 요청한다. 등록자는 도메인 이름, authoritative DNS 서버 이름, IP 주소를 함께 제출한다.

2. 등록자(registrar)가 .com TLD 서버에 정보를 등록하고 두 가지 DNS 레코드를 삽입한다.
NS 레코드: (networkutopia.com, dns1.networkutopia.com, NS)
A 레코드: (dns1.networkutopia.com, 212.212.212.1, A)

3. 자기 IP 주소로 동작하는 자체 authoritative DNS 서버 설정
A 레코드: www.networkutopia.com - IP 주소를 통해 웹사이트에 접속 가능
MX 레코드: networkutopia.com - mail 서버 주소를 통해 메일 수신 가능
(networkutopia.com. mail.networkutopia.com, MX)

사용자가 질의하면 Root DNS - .com TLD DNS - 등록된 NS 서버 - 실제 authoritative DNS로 연결해 준다.
해당 DNS 서버는 A 레코드나 MX 레코드를 통해 IP 주소나 메일 주소를 제공한다.

Peer-to-peer (P2P) architecture

항상 켜져 있는 중앙 서버가 없으며 임의의 end system들끼리 직접 통신이 가능하다. 클라이언트가 요청도 하고, 다른 peer에게 서비스를 제공할 수도 있다.
self-scalability(자체 확장성): peer가 늘어나면 네트워크 용량도 같이 증가한다.
peer는 접속 상태가 유동적이고, IP 주소도 자주 바뀌기 때문에 관리가 복잡하다.
ex) P2P file sharing(BitTorrent), streaming(KanKan), VoIP(Skype)

<client-server vs P2P>
한 서버가 파일 F를 N명의 클라이언트에게 배포하는 데 걸리는 시간은?
클라이언트-서버 모델은 모든 데이터를 서버 혼자 제공해야 하지만, P2P는 클라이언트도 데이터를 분배하는 데 참여한다.

(F: 파일 전체 크기, u_s: 서버 업로드 속도, u_i: 피어 i의 업로드 속도, d_i: 피어 i의 다운로드 속도)

1) client-server의 파일 분배 시간
클라이언트 N명에게 각각 F 크기의 파일을 보내는 총 서버(데이터) 전송 시간은 NF/u_s
클라이언트가 최소 다운로드 속도 d_min을 가질 때, 가장 느린 클라이언트가 파일 1개를 받는 데 걸리는 시간은 F/d_min

두 수식 중 더 큰 값이 전체 분배 시간(D_CS)을 결정한다. 즉, 더 오래 걸리는 쪽이 병목(bottleneck)이 되는 것이다.
N이 커질수록 성능이 급격히 떨어지며, 서버 혼자서 모든 걸 해야 하므로 확장성이 낮다.

2) P2P의 파일 분배 시간
서버는 최소 한 번만 전체 파일을 업로드하면 되므로, 서버 전송 시간은 F/u_s
마찬가지로 클라이언트의 다운로드 시간은 F/d_min
전체 피어가 파일을 공동 분배해야 하므로 NF / (u_s + Σu_i) (NF: 총 전송량, u_s+Σu_i: 총 업로드 용량)

N이 증가해도 성능이 급격히 나빠지지 않으며, 클라이언트가 많아질수록 오히려 성능 향상이 가능하다. (self-scalability)

Client-Server는 직선적으로 계속 증가하고, P2P는 점점 완만하게 증가한다.

<P2P 파일 분배: BitTorrent 기본구조>
전체 파일은 256KB 크기의 청크(chunks)로 나눈다. 모든 피어가 전체 파일을 조금씩 저장하고 교환한다.
torrents란, 하나의 파일을 공유 중인 피어들의 집합이다.
peer는 각 사용자를 의미하고 tracker는 토렌트에 참여한 피어들의 리스트를 관리하는 서버이다.

Alice가 새로운 피어로 접속하면 tracker로부터 이웃 피어 목록을 받고 이들과 연결하여 chunk를 주고받기 시작한다.
피어는 다운로드 중에도 자신이 받은 chunk는 다른 피어에게 업로드한다. 피어는 자유롭게 연결된 피어를 바꾸거나 네트워크에서 떠날 수도 있다. (churn)

청크 요청(requesting chunks)
피어들은 서로 다른 조각을 가지고 있기 때문에 Alice는 주기적으로 이웃 피어들에게 어떤 chunk를 가지고 있는지 물어보고, 본인이 없는 chunk 중 가장 희귀한 것(rarest first)부터 요청한다.

청크 천송(sending chunks)
tit-for-tat(주는 만큼 받는다)
Alice는 현재 자신에게 가장 빠르게 업로드해주는 4명에게만 chunk를 제공하며 그 외의 피어들은 choke 상태이다. 10초마다 top4를 재평가한다. 추가로 30초마다 임의의 피어 1명을 unchoke 해서 chunk를 제공한다.(optimistic unchoking)

Video streaming

비디오 스트리밍의 네트워크 관점으로 비디오 트래픽은 인터넷 트래픽의 대부분을 차지한다.
ex) Netflix, YouTube 등에서 오는 트래픽이 전체 인터넷 트래픽의 80%를 차지한다. (2020 기준)
전 세계 수십억 명의 사용자에게 비디오를 제공하려면 단일 서버로는 불가능하다는 확장성 문제와 사용자마다 접속 환경이 다르다는 이질성(heterogeneity)의 어려움이 있다. 해결 방법으로는 CDN 같은 분산형 인프라나 application-level에서 분산된 인프라 설계 등이 있다.

비디오는 일련의 이미지들의 집합(sequence of images)이다. 각 디지털 이미지는 픽셀들의 배열이며, 픽셀은 비트로 표현된다. 매초 24~30장 정도의 이미지를 보여주는데 그 모든 프레임을 그대로 다 보내면 용량이 엄청 커진다. 용량을 줄이기 위해 중복(redundancy)을 제거하는 방식으로 압축(coding)한다.

1) Spatial Redundancy(공간적 중복 제거)
하나의 이미지 안에서 반복되는 패턴을 줄인다.
ex) 한 화면에 보라색이 4번 등장하면 '보라색, 보라색, 보라색, 보라색' 대신에 '보라색 4번'이라고만 저장한다.

2) Temporal Redundancy(시간적 중복 제거)
연속된 이미지(프레임) 간의 차이만 저장한다.
ex) frame i와 frame i+1이 거의 동일한데 인물의 손만 살짝 움직였다고 했을 때, frame i+1 전체를 다시 보내는 대신에 frame i와 차이점만 전송하는 것이다.

비디오 인코딩 방식
CBR(Constant Bit Rate): 비디오를 일정학 속도(bit rate)로 인코딩한다. 초당 몇 비트로 데이터를 전송할지 고정하고 항상 동일한 양의 데이터를 사용한다.
VBR(Variable Bit Rate): 장면 복잡도에 따라 비트레이트가 변한다. 복잡한 장면에는 더 많은 비트를 사용하고 단순한 장면에는 덜 사용한다.

Streaming stored video

저장된 영상을 서버에서 전송한다. 클라이언트는 데이터를 받고, 일정한 속도로 재생을 시작한다.
서버에서 비디오를 전송할 때, 전송 간 지연이 발생한다. 네트워크 지연이 일정하지 않기 때문에 지연(delay), 지터(jitter) 등의 문제가 발생한다.
서버는 여전히 데이터를 보내고 있지만, 클라이언트는 이미 앞부분 재생을 시작했다. 이것이 스트리밍(streaming)의 개념이다.

클라이언트가 재생을 시작하면, 원래의 타이밍대로 끊김 없이 재생되어야 한다. 하지만 패킷 전송 지연이 일정하지 않기 때문에, 클라이언트는 재생 타이밍을 맞추기 어렵다.
패킷들이 도착하는 시간 간격이 들쭉날쭉하게 변동되는 현상인 jitter가 발생한다. 따라서 client-side-buffer가 필요하다. 클라이언트는 미리 일정량의 데이터를 버퍼에 저장해 놓고 네트워크 지연이 생겨도 재생이 끊기지 않게 해야 한다.

playout delay: 재생 시작을 약간 늦춰서 버퍼를 채운 뒤 시작하는 지연 시간이다.

Streaming multimedia: DASH
DASH(Dynamic Adaptive Streaming over HTTP)
클라이언트의 네트워크 상황(bandwidth)에 따라 실시간으로 화질(비트레이트)을 조절하면서 스트리밍 하는 방식이다.

<서버 측>
비디오를 여러 개의 chunk(2~10초짜리 비디오 조각)로 나눈다. 각 chunk는 여러 화질 버전으로 인코딩 되어 있다. manifest file에는 각 화질 버전에 chunk URL이 다 담겨 있고, 클라이언트가 이 파일을 읽고 필요한 것을 고른다.
<클라이언트 측>
서버와의 대역폭 측정을 주기적으로 수행한다. 매번 chunk를 받을 때 언제 받을지 어떤 화질로 받을지 어디서 받을지 클라이언트가 스스로 판단한다.(intelligence at client)

!! Streaming video = encoding + DASH + playout buffering!!

Content distribution networks (CDNs)
수백만 개의 콘텐츠 중에서 수만 명의 사용자에게 실시간으로 스트리밍 하는 것은 엄청난 부하가 발생하므로 단일 서버로는 감당이 불가능하다.

해결책
1) Mega-server(단일 대형 서버)
서버 하나가 죽으면 전체 서비스가 중단되고 먼 지역 사용자에게 느린 응답을 주며 동일한 비디오가 수십 번 반복 전송되므로 비효율적이다. 사용자가 늘어날수록 비효율은 심각해지고 확장성이 없다.(doesn't scale)

2) CDN (Content Distribution Network)
동일한 콘텐츠의 복사본을 전 세계 여러 곳에 미리 저장해 두고 가까운 곳에서 사용자에게 제공하는 방식이다.

구현 방식은 2가지가 있다.
Enter deep: 각 지역 ISP, 모바일 망 안까지 깊게 CDN 서버를 배치한다.(사용자와 가까이)
Bring home: 인터넷 중심부(IXP, PoP)에 대형 CDN 서버를 두고 여러 사용자 그룹에게 서비스를 제공한다.(네트워크 중심)

CDN은 콘텐츠의 복사본을 여러 지점(CDN 노드)에 저장하고, 사용자가 콘텐츠를 요청하면 가까운 CDN 노드로 라우팅 하여 빠르게 콘텐츠를 제공한다.
CDN 노드는 전 세계 곳곳에 분산된 서버들이고, Manifest file은 어떤 CDN 노드에 어떤 화질의 영상이 있는지 알려주는 정보 파일이다.

OTT(Over The Top)란?
인터넷망을 통해 사용자에게 직접 콘텐츠를 제공하는 서비스이다. ex) Netflix, YouTube, Disney+

어떤 CDN 노드에서 콘텐츠를 가져올까? 위치나 혼잡도를 고려해야 한다.
네트워크 혼잡 시 사용자의 행동은? 끊기면 서비스를 이탈할 수도 있다.
어떤 콘텐츠를 어떤 CDN 노드에 배치할까? 인기 콘텐츠는 더 많은 노드에 복제가 필요하다.

CDN content access- a closer look

시나리오) Bob이 http://video.netcinema.com/6Y7B23V 주소의 영상을 재생하려고 할 때, 이 영상은 CDN 서버(a1105.KingCDN/com/6 Y7 B23 V)에 저장되어 있다.

1. Bob이 netcinema 웹사이트에서 비디오 URL을 얻는다.
2. Bob의 local DNS 서버에게 video.netcinema.com의 IP를 요청한다.
3. netcinema의 authoritative DNS가 CNAME(별칭)을 반환한다. a1105.KingCDN.com으로 연결시켜 주고 이때부터 요청 대상이 KingCDN 쪽으로 넘어간다.
4. Bob의 local DNS가 KingCDN.com의 IP를 요청
5. KingCDN의 authoritative DNS가 실제 CDN 서버 IP를 반환
6. Bob이 CDN 서버에 HTTP 요청하면 비디오 스트리밍이 시작된다.

Case study: Netflix

Netflix는 자체 CDN 네트워크 Open Connect를 가지고 있다. 콘텐츠(비디오)를 여러 화질 버전으로 Amazon Cloud에 업로드한 후, 이 파일들을 전 세계 CDN 서버들에 미리 배포한다.

1. Bob이 Netflix에 로그인하여 계정을 관리한다.
2. Netflix에서 비디오 목록을 탐색한다.
3. 특정 영상을 선택하고 Manifest file을 요청한다. DASH 기반으로 여러 화질 버전 중 선택이 가능하게 구성된다.
4. Manifest 파일을 보고 적절한 DASH 서버를 선택하고 스트리밍을 시작한다.