[네트워크] 4. Application Layer (2)

2.4 DNS : Domain Name System

인터넷 호스트에 대한 하나의 식별자 - 호스트 네임 (hostname)

(기억하기 쉬워 사용자가 좋아하지만, 별로 제공되는 정보가 없음)

→ IP주소 사용

DNS

• name 서버들이 계층구조로 구현된 분산 데이터베이스
• 호스트가 분산 데이터베이스로 질의하도록 허락하는 어플리케이션 계층 프로토콜

→ 네트워크 코어가 아닌 네트워크 엣지에서 작동함

 

 

 

2.4.1 DNS가 제공하는 서비스

• 호스트네임을 IP주소로 변환
• 호스트 엘리어싱 (host aliasing) - canonical(정식 호스트네임), alias name제시한 별칭 호스트 네임에 대한 정식 canonical 호스트 네임을 얻기 위해 이용될 수 있음
• 복잡한 호스트 네임을 가진 호스트는 하나 이상의 별명을 가질 수 있음.
• 메일 서버 엘리어싱 (mail server aliasing)
• 전자메일 주소는 기억하기 쉬운 게 좋음.. 실제 서버의 호스트 네임은 훨씬 복잡하고 어려움.
• 부하 분산 (load distribution/ balancing)인기많은 사이트는 여러 서버에 중복되어 있어서, 각 서버가 다른 종단 시스템에서 수행되고 다른 IP주소를 가짐.
• 중복 웹 서버의 경우, 여러 IP 주소가 하나의 정식 호스트 네임과 연관되어 있음.. DNS 데이터베이스는 이 IP 주소의 집합을 가짐
• DNS는 중복 웹 서버와 같은 여러 중속 서버에서 부하를 분산하기 위해서도 사용됨

→ centralized DNS 서버를 사용하지 않는 이유?

1. 서버의 고장 (만약 이 네임 서버가 고장나면 전체 인터넷이 마비됨)
2. 트래픽 양 (단일 DNS 서버가 모든 질의를 처리해야 함)
3. 먼 거리의 중앙 집중 데이터베이스 (느리고 혼잡한 링크를 거치게 되면 심각한 지연을 일으킬 수 있음)
4. 유지관리 (공격에 취약. 호스트를 등록할 수 있도록 사용자에게 허용하는 것과 관련된 인증 문제)

→ 즉, no scale !! (확장성이 전혀 없음)

 

 

분산 계층 데이터베이스 (DNS: a distributed, hierarchical database)

계급이 아닌 계측적인 것

어떠한 단일 DNS 서버도 인터넷에 있는 모든 호스트에 대한 매핑을 갖지 않는다.

[ Root server → TDL. Top Level Domain → Authoritative ]

클라이언트는 루트 서버 중 하나에 접속

루트 서버는 최상위 레벨 도메일 com 을 갖는 TLD 서버 IP 주소를 보냄

클라이언트는 이 TLD 서버 중 하나에 접속하고 서버는 도메인 amazon.com을 가진 authoritative의 IP 보냄

클라이언트는 amazon.com의 authoritave 서버 중 하나로 접속

권한 서버는 호스트네임인 amazon.com의 IP주소를 보냄

 

루트 DNS 서버

대부분 북미 지역에 위치함.. 200개 정도

인터넷에는 400개 이상의 루트 서버가 있는데 13개의 기관에서 관리함 - ICANN (국제 인터넷 주소 관리 기구)

루트 서버 없으면 인터넷 마비됨

 

TLD

상위 레벨 도메인(com, org, net, edu)과 모든 국가의 상위 레벨 도메인(kr, uk,…)에 대한 서버

 

authoritative 서버

인터넷에서 접근하기 쉬운 호스트 (웹, 메일 서버)를 가진 모든 기관은 호스트 네임을 IP 주소로 매핍하는 공개적인 DNS 레코딩을 제공해야 함

서비스 제공자의 책임 DNS 서버에 의해 이 레코드를 저장하도록 비용을 지불할 수 있음

 

Local DNS 서버 ( = default name server)

서버의 계층구조에 엄격하게 속하지는 않지만, DNS 구조의 중심에 있음

ISP들은 로컬 DNS 서버를 가짐.. 대학이나 회사 주거지역과 같은…

호스트가 DNS 질의를 보내면 → 프록시로 동작하는 Local DNS 서버로 감

local cache 있음.. 호스트 네임과 IP 주소 쌍이 DNS 서버에 저장됨.. 영구적 x

질의를 계층적 구조로 넘김

 

반복적 질의 (iterative query)

하나의 호스트 네임 매핑을 얻기 위해 질의 메시지 네 번 + 응답 메시지 네 번

 

재귀적 질의 (recursive query)

루트 서버에서 질문을 던지고 응답 받기까지 자원이 소비되므로 보통은 iterated로 동작함

 

caching, updating DNS records

질의사슬에서 TDL 서버가 DNS 응답을 받으면 (호스트네임을 IP 주소로 매핑하기와 같은…) 그것을 로컬 name server에 저장함… >> 따라서 루트 서버를 우회함

대신 유효기간 TTL이 있음 … best-effort service model.. (DNS는 UDP 사용함

캐싱으로 인해 로컬 서버는 두 번째로 질의한 호스트에게 다른 DNS 서버로의 질의 없이 즉시 cnn.com의 IP 주소를 보낼 수 있음

다른 호스트 네임으로부터 같은 질의가 dns 서버에 도착하면 호스트 네임에 대한 책임이 없을 때조차 원하는 IP 주소를 제공할 수 있음

 

 

2.4.3 DNS 레코드와 메시지

DNS 분산 데이터베이스를 구현한 DNS 서버들은 호스트 네임을 IP 주소로 매핑하기 위한 자원레코드를 저장함

→ RR, Resource record

4-tuple로 구성됨

(Name, Value, Type, TTL)

Type = ‘A’

→ name : 호스트 네임

→ value : 호스트 네임에 대한 IP 주소

Type = ‘NS’

→ name : 도메인

→ value : authoritative 서버의 호스트 네임 (도메인 내부의 호스트네임에 대한 IP주소를 알려줄 서버)

Type = ‘CNAME’

→ name : 별칭 호스트 네임

→ value : 정식 호스트 네임

Type = ‘MX’

→ name :

→ value : 메일 서버의 정식 이름

 

 

 

DNS 프로토콜 메시지

질의와 응답 메시지의 포맷

첫 12 바이트 = 헤더 영역

→ 식별자 (identification)

16비트… 질의 식별 용도

질의에 대한 응답 메시지에 복사되어 클라이언트가 보낸 질의와 수신된 응답 간의 일치를 식별함

→ flag

• 질의응답 플래그 query / reply
• 메시지가 질의인지 응답인지 구분… 0이면 질의 1이면 응답
• 책임 플래그
• 서버가 질의 이름에 대해 책임 서버일 때 응답 메시지에 설정됨
• 재귀 요구 플래그
• 재귀 가능 플래그

→ 4개의 개수 필드

• 질문 영역 - 질문의 이름과 타입
• 답변 영역 - 여러 RR 포함
• 책임 영역 - 다른 책임 서버의 레코드 포함
• 추가 영역 - 다른 도움이 되는 레코드 포함‘

 

 

DNS 보안

• DDOS 공격→ 트래픽 필터링을 통해 지킴…TDL 서버를 폭격하는 건 잠정적으로 더 위험함… 국가 차원에서 발전도상국과 같은 나라는 인프라가 부족하기 때문에…
• → TDL 서버의 IP를 로컬 DNS 서버에서 캐시하고 있어서 … 루트 서버 우회 가능
• 트래픽을 통한 루트 서버 폭파
• Redirect 공격
  • 중간자 공격 - dns 질의를 가로챔
  • DDOS poisoning - 가짜 응답을 dns 서버로 보내서 캐시되도록 함..순진한 웹 사용자들을 공격자의 웹 사이트로 유도하는데 사용될 수 있음.. 그러나 구현이 어려움
• DDOS 공격을 위한 DNS 기반구조 이용만약 응답이 질의보다 훨씬 크게 증폭 !! 되도록 질의를 조작한다면 공격자는 자신의 트래픽을 많이 발생시키지 않고서도 목표 호스트를 공격할 수 있음
• 타겟 IP를 상대로 위장된(spoofed) 소스 어드레스.. 출발지 주소를 가진 질의를 보냄.. 그러면 그 서버가 응답 메시지를 타겟 호스트로 보냄..

→ 그러나 아직까지 DNS 공격이 성공한 적은 없었다.

 

 

 

2.5 P2P 파일 분배

 

클라이언트-서버 구조

D ≥ max {NF/Us, F/dmin}

• 서버의 파일 전송 시간
• N개의 F크기 파일을 Us의 업로드 속도로 .. 전송
• 클라이언트의 파일 다운 시간
• F크기의 파일을 d_min 가장 낮은 다운로드 속도로…

→ 피어의 수 N에 따라 선형적으로 증가한다.

 

P2P 구조

D ≥ max { F/Us, F/d_min, NF/…}

• 최소 분배 시간 F/Us

서버가 한 번 보낸 비트는 서버가 재전송할 필요 없음. 피어들끼리 재분배하면 됨

• 피어의 가장 낮은 다운로드 속도 F/dmin
• 시스템의 전체 업로드 용량… 전체적으로 서버의 업로드 속도와 각 피어들의 업로드 속도를 더한 것

마지막 시스템의 전체 업로드 용량에서 분모에도 N이 있기 때문에 분모도 같이 증가해서 선형적인 것보다 작게 증가한다…. 완만한 증가의 형태 ( 파일 공유에 유리하다는 장점)

 

비트토렌트 (BitTorrent)

비트토렌트 - 파일 분배를 위한 인기 있는 P2P 프로토콜

토렌트 - 특정 파일에 참여하는 모든 피어들의 모임

파일은 256킬로바이트 크기의 청크(chunk)로 나눔

일단 한 피어가 전체 파일을 얻으면, 토렌트를 이기적으로 떠나거나 / 이타적으로 토렌트에 남아서 다른 피어들에게 청크를 계속 업로드할 수 있음

트랙커 tracker : 한 피어가 가입할 때 트랙커에 자신을 등록하고 주기적으로 자신이 아직 토렌트에 있음을 알림. > 이런 방식으로 트랙커는 토렌트에 참여하는 피어들을 추적함

새로운 피어 앨리스가 토렌트에 가입할 때 트랙커는 참여하고 있는 피어의 집합에서 의의의 부분 집합을 선택하여 이 피어들의 IP 주소를 앨리스에게 보냄

피어들의 리스트를 얻고 앨리스는 이 리스트의 모든 피어들과 동시에 tcp 연결을 설정함

앨리스가 성공적으로 tcp 연결을 설정한 피어들 = 이웃 피어

시간이 지나면 일부는 떠나고 초기 피어들 외의 다른 피어들이 앨리스와 tcp 연결을 시도함.. 그래서 이웃 피어의 수는 일정하지 않음

피어들은 서로 다른 파일의 청크를 갖고 있을 것임…/ 주기적으로 앨리스는 피어들에게 청크리스트를 요구함

어느 이웃에게 어느 청크를 요청할 것인지 고르기 위해 “가장 드문 것 먼저 rarest first” 기술 사용함

 

 

2.6 비디오 스트리밍과 CDN (컨텐츠 분배 네트워크)

 

스트림 비디오 트래픽 문제

과제 → 1B 유저에게 어떻게 도달할 것인가? 하드웨어 리소스의 한정적 요인으로 인해 많은 사용자의 요청 처이가 어려움… 병목현상.. 네트워크 지연 등등…

근데 단일 메가 비디오 서버로는 왜 안 되는가? 한 번의 장애로 전체 서비스 중단 위험…

과제 → 이질성… 다양한 인터넷 환경에서 최적의 서비스 제공을 위해…

솔루션 # 분배된 어플리케이션 계층의 인프라

 

비디오

영상 = 1초에 수십개의 이미지를 연속적으로 보여주는 것 (1초에 24이미지,.,)

디지털 이미지 : 픽셀 단위 구성.. 비트로 이루어짐…

(비디오 품질과 비트 전송률은 서로 반비례함)

→ 공간적 압축 방법

화질에 대한 손실 감수.. 비슷한 색은 다 같은 값으로 처리함

→ 시간적 압축 방법

프레임 단위에서 프레임과 프레임의 갭 차이는 별로 없음… 유사한 사진

그렇다면 새 프레임을 다운받지 말고 변화값을 저장하자.. 움직임 백터만 추가

CBR (constant bit-rate) → VBR (variable bit-rate).. 속도의 유동성 적용 방법

MPEG4를 주로 사용함

 

스트리밍 저장 비디오

 

대역폭은 계속 변화하고 네트워크 혼잡도도 변동적인데 그런 상황에서 어떻게 안정적으로 비디오를 끊김 없이 보여줄 것인가?

 

1) 비디오 녹화

그래프는 시간에 따라 선형적으로 증가하는 것으로 보이며, 이는 비디오가 일정한 비율로 녹화되고 있음을 의미

 

2) 비디오 전송

서버에서 비디오가 전송되기 시작하는 시점부터 클라이언트가 비디오를 수신하기 시작하는 시점까지의 네트워크 지연(network delay) 포함

 

3) 비디오 수신 및 클라이언트의 재생

스트리밍 중인 특정 시점에 클라이언트가 비디오의 초기 부분을 재생하고 있지만, 서버는 여전히 비디오의 뒷부분을 전송하고 있음을 나타냅니다. 이는 전형적인 스트리밍 시나리오를 보여줍니다. 클라이언트는 전체 파일을 다운로드 받기 전에 비디오를 보기 시작할 수 있으며, 이러한 방식으로 사용자는 다운로드가 완료되기를 기다리지 않고 즉시 비디오를 시청할 수 있습니다.

 

문제 고려

→ 연속적 재생 제한.. 지연없는 재생..

네트워크 딜레이는 변동적이라서 클라이언트 측의 버퍼 필요

→ 클라이언트의 상호작용

중단, 빨리감기, 뒤로가기, 스킵…

비디오 패킷이 손실되거나 재전송될 수 있음;

 

재생 버퍼링

→ 비디오 전송

선형적 증가는 데이터가 지속적으로 일정한 속도로 네트워크를 통해 전송되고 있음을 의미

→ 네트워크 지연

네트워크의 지연은 항상 일정하지 않으며(지터 현상), 이로 인해 데이터가 클라이언트에 도착하는 시간에 차이가 발생할 수 있습니다.

→ 수신 후 클라이언트 측 버퍼링 이는 클라이언트가 비디오 데이터를 일정 시간 동안 저장하는 과정입니다. 이 버퍼링은 네트워크 지연의 변동성(지터)을 보상하고, 연속적인 비디오 재생을 가능하게 합니다.

→ 재생 지연 (Playout Delay): 버퍼링으로 인해 클라이언트는 비디오 재생을 시작하기 전에 약간의 지연이 생깁니다. 이 지연은 충분한 데이터가 버퍼에 축적되어 네트워크 지연이나 데이터의 변동성으로부터 발생할 수 있는 재생 중단을 방지하기 위해 필요합니다

 

네트워크 추가 지연 및 지연 변동 보상 (Compensate for Network-Added Delay, Delay Jitter):

클라이언트의 버퍼는 네트워크에서 발생할 수 있는 지연과 지연 변동(지터)을 효과적으로 관리하여, 사용자에게 끊김 없는 스트리밍 경험을 제공하기 위한 목적으로 사용됩니다.

 

스트리밍 멀티미디어 : DASH

Dynamic Adaptive Streaming over HTTP

사용자의 네트워크 환경에 따라 비디오의 품질을 동적으로 조절함으로써 최적의 스트리밍 경험을 제공하는 것이 핵심입니다.

 

 

서버 >>

비디오 파일을 여러 청크로 쪼갬 → 청크 저장하고 다른 속도로 인코딩함

manifest file : http 서버는 비트율에 따른 각 버전의 url을 제공하는 매니페스트 파일을 가짐

 

클라이언트 >>

주기적으로 서버~클라이언트의 대역폭 측정 …. 현재의 네트워크 상황 파악을 위해

최근 대역폭에 따라서 … 상황이 좋으면 맥시멈 코딩레이트를 택하거나 / 상황 안 좋으면 다른 코딩 레이트를 택함

 

- 클라이언트의 ”인텔리전스“
    클라이언트는 언제 청크를 요청할 것인지 (버퍼의 상황에 따라.. 오버플로우 없도록..)
    어느 정도의 인코딩 속도를 요청할 것인지 (대역폭의 상황에 따라.,..화질,….)
    어디로 청크를 요청할 것인지 (가까운 url 서버에게 요청…?)
    정한다.

 

스트리밍 비디오 = encoding + dash + playout buffering

인코딩 : 데이터량을 압축하고, 다양한 네트워크 속도에 적합한 다른 품질 수준으로 비디오 제공

대쉬 : 동적 적응형 스트리밍 기술을 통해 클라이언트는 현재의 네트워크 조건에 맞게 비디오의 품질을 동적으로 조정하며 청크를 요청

재생 버퍼링 : 클라이언트는 버퍼를 사용하여 네트워크 지연 및 지연 변동(지터)을 관리하고, 사용자에게 원활한 비디오 재생 경험을 제공

 

 

 

2.6.3 콘텐츠 분배 네트워크 (CDNs)

 

앞에서 고려한 건 한 명의 유저.. 그러나 무수히 많은 유저들에게 … 어떻게 동시에…

 

op1) single large, 메가 서버

> 실패 가능성, 네트워크 혼잡, 멀리있는 클라이언트는 느린 서비스 받음, 반복적 전송 (낭비…)

확장성 없음!

 

op2) 다수의 지점에 분산된 서버들을 운영.. 사용자에게 최선의 서비스와 사용자 경험을 제공할 수 있는 지점의 CDN서버로 연결됨 (CDN)

→ enter deep (CDN 서버를 최대한 사용자 가까이에 위치시켜 사용자와 CDN 서버 사이의 링크 및 라우터 수를 줄이고 사용자의 지연시간 및 처리율 향상… 서버 클러스터의 유지관리비용 증가

→ bring home

적은 수의 핵심 지점에 큰 규모의 서버 클러스터를 구축하여 ISP를 홈으로 가져오는 개념

Limelight

사용자의 지연시간 및 처리율 악화… 유지관리비용 감소

 

> cdn 콘텐츠의 복사본을 이들 클러스터에 저장

> 모든 비디오의 복사본을 전부 유지할 필요는 없음.. 주로 인기있는 비디오 위주로,,

> 사용자가 지역 클러스터에 없는 비디오를 요청하면? 중앙 서버나 다른 클러스터로부터 전송받아 사용자에게 서비스하는 동시에~ 복사본을 만들어 저장함

> 캐시와 마찬가지로 클러스터의 저장공간이 가득 차면 자주 사용되지 않는 비디오 데이터는 삭제됨

 

OTT = Over The Top

혼잡이 발생하면 다른 서버에서 다운받기 위한 프로토콜?

 

 

CDN 동작

넷플릭스 비디오 라이브러리를 탐색하는 웹 페이지는 아마존 클라우드 서버에서 제공

사용자가 재생할 영화를 선택하면 아마존 클라우드에서 실행 중인 넷플릭스 소프트웨어가 먼저 해당 영화 사본을 가지고 있는 CDN 서버를 선택함

( 영화가 있는 서버 중 소프트웨어는 클라이언트 요청에 ‘최적의’ 서버를 결정함)

((넷플릭스가 콘텐츠를 전달할 CDN 서버 결정하고 나면))

 

클라이언트는 요청된 영화의 다른 버전에 댜한 url을 가진 매니페스트 파일과 특정 서버의 IP 주소를 직접 보냄

클라이언트와 해당 CDN 서버는 독점 버전의 DASH를 이용하여 직접 상호작용함

(( 클라이언트는 http get 요청 메시지의 헤더를 이용해 서로 다른 버전의 비디오 조각 단위 데이터를 요청할 수 있음. 클라이언트는 비디오 조각 단위 데이터를 다운로드 하는 동안 수신 처리율을 측정하고 전송률 결정 알고리즘을 이용해 다음에 요청할 비디오 조각 단위 데이터의 품질을 결정함))