같이 읽어요 - [컴퓨터 네트워크 Top-down approach]-2. 애플리케이션 계층

* 읽는 법:
  큰 목차 - 주황색

  세부 목차 -  녹색 

  주요 흐름 - 노란색

 

2장의 목차

1. 네트워크 애플리케이션의 개념과 구현

• 클라이언트- 서버구조 ,프로토콜이란 무엇인가

2.여러 네트워크 애플리케이션

• HTTP, SMTP, DNS,  | P2P, CDN

3. TCP, UDP에서의 네트워크 애플리케이션 개발

• socket

 

1. 네트워크 애플리케이션의 개념과 구현

<1.1. 네트워크 애플리케이션의 원리>

 

-  네트워크 애플리케이션 개발의 중심

•  다른 위치의 종단 시스템에서 동작하고 네트워크를 통해 서로 통신하는 프로그램을 작성하는 것이다.

이때 라우터나 링크 계층 스위치처럼 네트워크 코어 장비에서 실행되는 소프트웨어까지 작성할 필요가 없다. (계층 구조로 인해)

 

• 네트워크 애플리케이션 구조
  • 클라이언트 - 서버 구조
     애플리케이션을 개발하려고 할 때, 개발자는 두 가지 잘 알려진 구조 중 하나로 작성한다: (클라이언트 - 서버 구조 혹은 P2P)
    
    •  웹 서버가 클라이언트 호스트로부터 객체를 요청받으면, 웹 서버는 요청된 객체를 클라이언트 호스트로 보내면서 응답한다.
    • 서버는 고정 IP 주소를 갖는다.
    • 데이터 센터
      : 많은 요청을 잘 처리하기 위해  1개보다는 많은 수의 호스트를 갖춘 데이터 센터가 강력한 가상 서버를 생성하는 역할로 사용된다. 
      
  • P2P 구조
    특정 서버를 통하지 않고 피어라는 간헐적으로 연결된 호스트 쌍이 직접 통신한다.
    
    • 자가 확장성
      피어가 파일을 다른 피어에게 분배함으로써 서비스.
      

• • • 비용효율적
      많은 서버 인프라스트럭처와 서버 대역폭을 요구하지 않는다.
      

 

• 프로세스간 통신
  다른 호스트(also 다른 운영체제)에서 실행되는 프로세스와의 통신이 관심대상이다.

 

•   클라이언트와 서버 프로세스
  - 서로 메세지를 보내는 두 프로세스
  
  • 클라이언트:  두 프로세스 간의 통신세션에서 통신을 초기화하는 프로세스
  • 서버: 세션을 시작하기 위해 접속을 기다리는 프로세스

 

• 소켓
  호스트의 애플리케이션 계층과 트랜스포트 계층간의 인터페이스.
  개발자는 소켓의 애플리케이션 계층 통제권은 모두 갖고 있지만 트랜스포트 계층의 통제권은 [어떤 프로토콜을 사용할 것인지, 최대 버퍼, 최대 세그먼트 크기 등의 파라미터만]정도만을 결정할 수 있다.

 

• 프로세스 주소 배정
  수신 프로세스가 주소를 갖고 있어야 패킷을 목적지로 보낼 수 있다.
  
  • IP 주소 : 호스트의 주소
  • 포트번호 : 목직지 호스트 내의 수신 프로세스 명시 식별자

 

• 애플리케이션이 이용 가능한 트랜스포트 서비스
  
  • 신뢰적데이터 전송: 데이터를 소켓으로 보내고 그 데이터가 오류없이 수신 프로세스에 도달할 것이다.
  • 처리율 : 특정 처리율 보장 , 시간, 보안

 

 

 

• 인터넷 전송 프토콜이 제공하는 서비스

• TCP 프로토콜 (Transmission Control Protocol)
  
  • 연결지향형  : 핸드셰이크
  • 신뢰적인 데이터 전송 : 오류없이, 순서대로
  • 혼잡 제어방식 : 전체 네트워크의 혼잡도 제어
• UDP 프로토콜 (User Datagram Protocol)
  
  • 비연결지향형
  • 비신뢰적인 데이터 전송
  • 혼잡 제어 하지 않음.

 

 

• 애플리케이션 계층 프로토콜
  다른 종단시스템에서 실행되는 애플리케이션의 프로세스가 서로 메시지를 보내는 방법을 정의한다.
  
  • 웹
    HTTP : 웹 애플리케이션 계층 프로코토콜
    - 브라우저와 웹 서버 사이에서 교환되는 메시지의 포맷과 순서를 정의한다. 
    
  • 비디오 서비스
    DASH 프로토콜
    
    

 

2.여러 네트워크 애플리케이션

배울 것
- 웹 :HTTP

- 전자메일 : 여러 애플리케이션 계층 프로토콜을 사용.

- DNS : 코어 네트워크 기능이 인터넷 애플리케이션 계층에 어떻게 구현되나.

- P2P 파일 공유 애플리케이션

- 비디오 스트리밍 온디맨드 : CDN과 넷플릭스, 유튜브 실례

 

<웹과 HTTP>

웹은 사용자가 원할 때, 원하는 것을 제공하는 장점이 있다. (라디오와 다르게)

 

• HTTP 개요
  용어
  - HTTP : HyperText Transfer Protocol
  메시지의 구조 및 클라이언트와 서버가 메시지를 어떻게 교환하는지에 대해 정의하고 있다.
   - 객체 : 웹 페이지를 구성. 단순한 단일 URL로 지정할 수 있는 파일(JPEG, HTML ..)
   - 웹 브라우저: HTTP의 클라이언트 측 구현
  -  웹 서버 : HTTP의 서버 측 구현.
      URL로 각각을 지정할 수 있는 웹 객체를 갖고 있다.
  
  - stateless Protocol (비상태 프로토콜)
    : 서버 측에서 클라이언트에 대한 정보를 유지하지 않는다.
  - Persistent Protocol, Non-persistent Protocol
   : 하나의 TCP 연결에서 하나의 객체를 보내느냐, 아니면 여러 개의 객체를 보내는가.
  - HTTP 1.1은 non-persistent protocol을 사용한다.
  - nonpersistent protocol에서는 (2RTT + 서버 파일 전송시간)동안 한 객체가 전송된다.
     nonpersistent 에서 여러 연결을 동시에 사용해서 요청 응답 받을 수 있긴 하다.
  - persistent protocol 에서는 파이프라이닝이 디폴트이다. (응답을 기다리지 않고 연속으로 요청)
  

 

<HTTP 메시지 포맷>

HTTP 요청메시지

 

첫 줄 : 요청 라인(method/ URL / http 버전)

Method : GET , POST, HEAD, PUT, DELETE

헤더라인  : Host(www.school.edu), Connection (close), User agent(Moziala/5..0)..

Entity body  :  POST 메서드일 때

 

HTTP 응답 메시지

첫 줄 : 상태 라인(htttp 버전/ 상태 코드/ 해당 상태 메시지)

헤더라인 : Connection(close), Server(Apache.2,2.3),Date(서버가 메시지작성한) Last-Modified(객체수정)..

Entity body  : 요청 객체

 

-> HTTP 명세서는 브라우저, 웹 서버, 네트워크 캐시 서버에 의해 삽입될 수 있는 많은 헤더 라인을 정의하고 있다.

 

Stateless HTTP 가 사용자를 식별하는 방식

쿠키

쿠키는 비상태 HTTP위에서 사용자 세션 계층을 생성하는 데 이용될 수 있다.

서버: set-cookie : 쿠키 번호를 추가해서 응답메시지 전송

브라우저 : 받은 쿠키 번호와 서버의 호스트 이름을 브라우저 쿠키 관리 파일에 저장한 후,

이후 HTTP 요청 메시지에 쿠키를 포함시켜서 전송.

 

웹 캐시 (프록시 서버)

클라이언트가 기점 서버(origin server) 대신에 웹 캐시에게 먼저 요청

적중률 : 요청한 객체가 웹 캐시에게 있을 확률

웹 캐시에 요청한 객체가 없다면, 기점 서버에게 객체를 요청한 뒤 사본을 클라이언트에게 보낸다.

기점 서버에게 TCP 연결한 후 기존 클라이언트와의 TCP 연결을 통해서 객체 사본을 응답

웹 캐싱 사용 이유 : 1. 응답시간의 단축 2. 트래픽 감소

(1: 특히 클라이언트와 기점서버보다 클라이언트와 웹 캐시와의 연결이 매우 빠를때 유용)

더욱 더 중요한 역할 : CDN사용과 함께. (Content Distribution Network)

• 조건부 GET: 서버에게 이후에 변경되었다면 객체를 보낼 것을 요청하는 메시지를 보낸다.

 변경되었다면 받고 아니라면 빈 entity body를 받는다.

GET 메서드이고 If-Modified-Since : 헤더가 존재하는 경우.

 

<HTTP2>

HTTP2 버전의 목표

http 1.1버전이 HOL(head of line) 문제를 병렬 TCP 연결로 해결하는 데에 있어 다른 방식으로 해결해서 TCP 연결 수를 줄이고 그에 필요한 소켓 수도 줄이고, TCP의 혼잡제어 방식에 도움을 주기 위함

 

 

프레이밍

각 메시지를 작은 프레임으로 나누고, 같은 TCP 연결에서의 요청과 응답메시지를 인터리빙한다.

• HTTP2 프로토콜의 프레임으로 구현된 다른 프레이밍 서브 계층에 의해 이루어진다.

 

메시지 우선순위화와 서버 푸싱

서버로 오는 요청을 우선순위를 정하여 처리한다/ 필요한 객체가 무엇인지를 알고 요청이 오기도 전에 여러 객체들을 보내준다.

 

<HTTP3>

QUIC위에서 작동하도록 설계된 새로운 HTTP 프로토콜.

QUIC : UDP위에서 동작하는 것으로 설계된 새로운 트랜스포트 프로토콜, 애플리케이션 계층에 구현되어있다.

RTT : Round Trip Time

패킷이 클라이언트에서 서버에 도착했다가,

다시 클라이언트로 돌아올때까지의 시간

HOL 문제:

앞의 전송 패킷이 너무 오래 걸려서 뒤의 전송 패킷이 계속 대기하는 문제.

Http1.1 버전에서는 병렬 TCP 연결로 이를 해결한다.

 

<인터넷 전자메일>

웹과 다르게 원할 때 보내놓고, 원할 때 읽는 방식이다. (client push 방식)

• 인터넷 메일 시스템 상위 개념(user agent, mail server , SMTP)
• SMTP개념 (statefull, persistent, tcp)
• IMAP 혹은 HTTP 이용하기 (서버에서 메시지 pull)

 

인터넷 메일 시스템 상위 개념

• 사용자 에이전트 (user agent) : 사용자 에이전트에서 메일 서버로 메시지를 보낸다.
• 메일 서버 (mail server) : 사용자 에이전트가 보낸 메시지가 송신자 서버에 도착하고, 메시지 큐에 저장했다가 가능할 때 SMTP를 통해 수신자 서버에 메시지가 도착한다.
• SMTP(simple Mail Transfer Protocol) : 사용자 에이전트-> 메일서버로,  송신자 메일 서버로부터 수신자 메일 서버로 전송한다. TCP 사용

 

 

SMTP

HTTP보다 훨씬 오래된 기술. 메시지 몸체가 모두 7비트 아스키코드여야 한다는 단점.

• 특징: 두 메일 서버가 먼 거리에 떨어져 있더라도 중간 메일 서버를 사용하지 않는다.
• 전송 방식 :
• 메일 메시지 포맷
• 메일 접속 프로토콜

송신자의 사용자 에이전트는 메시지를 메일 서버로 HTTP 혹은 SMTP를 이용해서  보낸다.

그리고 메일 서버에서 수신자의 메일서버로 전자메일 메시지를 보내려고 한다. : 30분마다, 상대 서버가 동작할 때까지 보내려는 시도를 반복한다. (SMTP 'push')

이후에 수신자는 메일서버에서 메시지를 'pull'하려는 시도를 한다. :

• 스마트폰 앱을 사용 중이라면 HTTP 사용
• 메일 클라이언트 사용 (IMAP - 인터넷 메일 접근 프로토콜, Internet Mail Access Protocol)

<인터넷 디렉터리 서비스 - DNS>

DNS : domain name system

- 호스트의 식별자 (hostname, IP 주소)를 사용자에게는 쉬운 호스트이름으로, 라우터에게는 쉬운 IP주소로 변환할 수 있도록 한다.

 

• DNS가 제공하는 서비스 (IP주소 <-> 도메인이름 변환하기, 호스트 aliasing, 메일 서버 aliasing, 부하 분산)
• DNS 동작 원리 개요 (분산 계층 데이터 베이스 |  루트 DNS 서버 ->  최상위 레벨 DNS 서버 -> 책임 서버(authoritative) | 로컬 DNS 서버)
• DNS 레코드와 메시지 (DNS 서버가 저장하는 정보 RR, 4가지 필드, 제공하는 메시지 포맷- 헤더영역, 개수 필드, 질의 답변 책임 추가 영역)

 

1 DNS가 제공하는 서비스

<ip주소 변환하기>

- DNS : Domain name system :

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

UDP상에서 수행되고 포트번호 53을 이용한다.

 

- 수행방식

1. 브라우저가 url에서 호스트 이름을 추출한 다음, DNS 애플리케이션의 클라이언트 측에 넘긴다.

2. DNS 클라이언트가 DNS 서버에게 호스트 이름을 포함하는 질의를 보낸다.

3. DNS 클라이언트가 IP주소를 받고, 브라우저가 받은 뒤 해당 IP주소와 그 주소의 80포트에 위치하는 http 서버 프로세스로 tcp 연결을 초기화한다.

 

- 특징 : DNS로 인해서 다른 DNS 지연이 추가로 생길 것 같지만, 원하는 IP 주소는 '가까운 DNS 서버'에 캐싱되어 있어, 트래픽 및 지연에 도움을 준다.

 

<추가 서비스>

1. 호스트 에일리어싱(host aliasing) : 정식 호스트 이름에 대해 별칭을 갖고 있을 수 있다. 이 별칭에 대해 정식호스트 이름을 찾아준다.

2. 메일 서버 에일리어싱(mail server aliasing) : 전자 메일 주소도 메일 애플리케이션에서 DNS 에 의해서 변환된다.

3. 부하 분산 (load balancing) : 하나의 도메인이름이 여러 IP주소를 갖고 있는 중복 웹 서버에 대해, 순환적으로 IP주소를 응답한다.

 

2 DNS 동작 원리 개요

- 사용자의 호스트에서 호출한 애플리케이션 관점에서 DNS는 간단하고 직접적인 변환 서비스를 제공하는 블랙박스다.

 

- 실제로는 전세계적으로 분산된 DNS 서버와 호스트 사이에서 통신하는 방식에 대해 애플리케이션 프로토콜로 구현되어 있다.

- 왜 분산된 서버를 이용하는가?

단일 서버라면 서버 고장 문제, 트래픽 양 문제, 먼거리의 중앙 집중 데이터베이스 문제, 유지관리 문제가 뒤따른다.

 

분산 계층 데이터베이스

세 가지 유형의 DNS 서버 : 

• 루트 DNS 서버 : 13개의 다른 루트 서버 복사체. TLD 서버의 IP 주소들을 제공.
• 최상위 레벨 도메인 네임 서버 (top-level domain, TLD) DNS 서버 : com, org 같은 것, kr, uk 같은 것(국가 상위레벨 도메인) 에 대해 책임 DNS 서버IP 주소 제공
• 책임(authoritative) DNS 서버 :  호스트 이름을 IP 주소로 매핑하는 공개적인 DNS 레코드를 가지고 있다. (기관이 보통 돈을 내고 저장.)

 

   * 로컬 DNS 서버

DNS 서버 계층에 속하지는 않으나 중심이 됨.

대학이나 주거지역 ISP는 로컬 DNS 서버를 갖는데, 호스트가 ISP에 연결될 때 로컬 DNS 서버로부터 IP주소를 호스트에게 제공한다. (DHCP 방식 - 4장)

 

-> 클라이언트가 DNS 서버에게 직접 묻는 것이 아니라, 로컬 DNS에게 물어보면 로컬 DNS 서버가 각각 루트 DNS서버에게 물어보고 응답을 받고, 그다음 TLD 서버에게 물어보고 응답을 받고, 그 다음 책임 DNS 서버에게 물어봐서 응답을 받은 다음 호스트가 원하는 IP주소로 응답한다.

 

* 오개념 방지 : TLD는 책임서버를 안다고 했으나, 사실 TLD 서버는 호스트 이름에 대한 책임 DNS를 아는 중간 DNS 서버만 알고 있다.

 

DNS 캐싱

: 로컬 DNS 서버는 임의의 DNS 서버로부터 응답을 받을 때마다 응답에 포함된 정보를 저장할 수 있다.

 

 

 

3 DNS 레코드와 메시지

 

DNS 서버들은 호스트 이름을 IP주소로 매핑하기 위한 자원 레코드(resource record, RR)를 저장한다.

: (Name, Value, Type, TTL)

 

DNS 메시지

• 헤더영역 : 처음 12 바이트, 질의 식별자, 플래그(질의/응답 플래그, 책임 플래그, 재귀 요구 플래그)
• 개수 필드 4개 : 질문, 답변 RR, 추가 RR의 수 * 2
• 질문 영역
• 답변 영역
• 책임영역, 추가영역

 

DNS 데이터베이스에 레코드 삽입

등록기관은 도메인 네임의 유일성을 확인하고, 그 도메인 이름을 DNS 데이터베이스에 넣고 그 서비스에 대한 약간의 요금을 받는 상업기관이다.

ICANN

 

정리 : 웹에서 www.google.com 페이지를 보고 싶다면, 해당 도메인 이름에 대한 IP주소를 로컬 DNS에 질의한다.

로컬 DNS는 해당 도메인 이름 관련 TLD 서버에 대한 정보가 있다면(없으면 루트 DNS로 가서 얻어옴), TLD 서버로 곧장가서 책임서버를 물어보고,

[원하는 도메인 이름, 알고 있는 책임서버 도메인이름]

[책임서버 도메인 이름, 그에 해당하는 IP 주소] 를 포함해 응답을 보낸다.

그러면 로컬 DNS 서버는 책임 DNS IP 주소로 질의를 해서 마지막으로 응답을 호스트에게 주고,

그 받은 IP 주소에 (google.com) 대해서 호스트는 TCP 연결을 초기화하고 그 연결로 HTTP 요청을 보낸다.

 

*이 과정은 로컬 DNS에 있어 재귀적, 반복적 질의과정이다.

 

 

<P2P 파일 분배>

Peer to peer : 서버에 최소한으로 의존하여, 간헐적으로 연결되는 호스트 쌍이 직접 서로 통신하는 방식.

• P2P구조의 확장성 (항상 클라이언트- 서버 구조의 분배시간보다 작은 건 아니지만 N에 대해서는 작고 자가확장성을 갖는다:  피어가 소비자이자 재분배자)
• 비트토렌트 (특정 피어를 선택해서 교역 리스트에 추가한다. 이를 위해 트래커가 피어 관리를 한다. )

1 P2P구조의 확장성

<분배 시간 계산하기>

- 클라이언트 - 서버 구조가 요청한 호스트의 수 N에 대해 데이터 분배 시간이 선형으로 증가함을 확인

-P2P 구조에서는 데이터 분배시간이 N과 관련이 없음을 확인.

 

 

2 비트토렌트

: 파일 분배를 위한 인기있는 P2P 프로토콜.

- 토렌트 : 특정 파일의 분배에 참여하는 모든 피어의 모임.

- 트래커 : 인프라스트럭처 노드, 한 피어가 가입할 때 트래커에 자신을 등록 후, 주기적으로 토렌트 내에 존재함을 알리면 트래커는 이 피어들을 추적한다.

피어에게 다른 피어들의 IP 주소를 주면, 이 들에게 모두 동시에 TCP 연결을 설정한다. (성공 -> 이웃피어가 됨)

재 분배 방식 : 가장 드문것 부터/ 가장 빠른 속도로 응답해오는 피어에게. / 보내는 속도가 충분히 크면 새롭게 교역 파트로 등록 후 교역을 한다.

<비디오 스트리밍과 콘텐츠 분배 네트워크>

• 인터넷 비디오 (압축되는 특징, 이미지의 연속적인 표시, 비트율과 품질 상관관계)
• HTTP 스트리밍 및 DASH (http에서 비디오 전송 시 대역폭에 따라 비디오 인코딩 방식이 달라질 수 없다는 점 : DASH에서는 http 서버가 인코딩별로 각 동영상을 갖고 있고 이를 manifest file이 갖고 있으며, 클라이언트가 이를 요청한 후에 매번 http GET 메시지에 원하는 비트율의 동영상을 chunck 단위로 요청한다.)
• 콘텐츠 분배 네트워크 (CDN) (보통 분산 클러스터에서 캐싱하면서 pull 방식으로 비디오를 가져와서 응답한다. DNS 요청에서 채간다  : 책임서버가 CDN 이름을 줌 )
• 사례 연구 (넷플릭스 : DNS 리다이렉션 필요없이 AWS에 있는 소프트웨어가 CDN 서버를 결정해서 연결해준다. 자체 CDN 서버를 구축했다.)

(유튜브 : DNS 리다이렉션 샤용, 비디오 스트리밍 및 업로드에 모두 HTTP 스트리밍 사용.)

 

 

 

 

1 인터넷 비디오

비디오 매체의 특징:

- 이미지의 연속으로 초당 여러개의 이미지로 표시된다. 각각은 픽셀단위로, 휘도와 색상을 나타내는 비트들로 인코딩 (압축되지 않았을 때)

- 압축이 가능하다.

- 네트워크적인 특징 : 높은 비트 전송률

• 비트 전송률 : 연속 재생을 위해서 네트워크는 압축된 비디오의 전송률 이상의 스트리밍 애플리케이션에 대한 평균 처리량을 제공해야 한다.

 

2 HTTP 스트리밍 및 DASH

 

HTTP : http에서 동영상을 가져오는 방법 : 한 객체로써 url로 파일을 받으면, 특정 임계값의 바이트수가 넘으면 비디오 프레임을 가져와서 압축 해제한다음 사용자 화면에

표시한다. 이후 데이터를 또 가져오는 버퍼링 과정 동안 화면이 재생된다.

• 문제점 : 모든 클라이언트가 같은 인코딩된 비디오를 받는다. (대역폭은 모두 달라서 잘 전송될 지 모르는데도.)

 

DASH ; (Dynamic Adaptive Streaming over HTTP)http 기반 스트리밍 : 비디오가 여러가지 버전으로 인코딩 되어있다. (다른 비트율과 품질 수준)

클라이언트가 동적인 요청을 수행: 서로 다른 버전의 비디오를 몇 초 분량의 길이를 갖는 비디오 조각 (chunk)으로 요청 - 가용 대역폭에 따라 다르게 요청한다.

 

각 비디오 버전은 HTTP 서버에 서로 다른 URL을 가지고 저장된다. HTTP 서버는 비트율에 따른 각 버전의 URL을 제공하는 manifest file을 갖고 있다.

클라이언트가 이 파일을 요청해서 http GET 메시지에 URL과 byte-range를 지정하여 요청한다.

-> DASH는 클라이언트가 서로 다른 품질 수준을 자유롭게 변화시킬 수 있도록 허용한다.

 

 

3 콘텐츠 분배 네트워크 (CDN)

엄청난 스트리밍 트래픽을 전세계에 걸친 지점에 끊김 없이 안정적으로 제공하는 방법.

 

- CDN (Content Distribution Network, CDN) : 비디오 스트리밍 회사들이 이용한다.

• 다수의 지점에 분산된 서버들을 운영. 비디오 등의 웹 콘텐츠 데이터의 복사본을 이 서버에 저장한다.

CDN은 콘텐츠 제공자가 소유한 private CDN 일수도 있고, 제 3자가 운영하는 third-party CDN 일수도 있다.

 

- 서버의 위치에 대한 철학 :

• Enter Deep : 최대한 ISP 접속 네트워크로 깊숙히 들어가라.  (비용이 많이 든다. )
• Bring Home : IXP(Internet Exchange Point) 근처에 소수의 큰 서버 클러스터를 구축한다.

 

• 저장 방식 : pull 방식으로 지역 클러스터에 없는 비디오를 요청받으면, 다른 서버에 요청하고 복사본을 저장하되 안쓰이면 삭제한다.

 

CDN 동작

- [DNS 리다이렉션], [서버 클러스터 결정 방식]

1. 웹 브라우저가 URL을 지정하여 특정 비디오 재생 요청 -> 그 요청을 가로챔

호스트이름에 대해 LDNS가 DNS 요청 -> .. 책임 DNS 가 CDN 이름으로 응답해서 결국 질의받은 CDN이 DNS 응답을 할 때, 서버 클러스터를 결정해서 그 IP주소를 준다.

2. 클라이언트의 요청을 CDN 클러스터 서버로 연결.

지리적으로 가장 가까운 클러스터 혹은 트래픽 상황 반영을 위한 실시간 측정 수행.

 

4 사례 연구

넷플릭스

1 ) 아마존 클라우드의 기능 : (웹사이트의 백엔드, 데이터 베이스가 여기서 실행됨)

• 콘텐츠 수집 : 비디오를 분배하기 전에 비디오를 아마존 클라우드 시스템의 호스트에 업로드.
• 콘텐츠 처리 : 여러 형식, 여러 비트율의 비디오 생성 (기기 사양에 맞게, DASH 요청에 맞게)
• CDN으로의 버전 업로드 : 콘텐츠들을 처리한 후 CDN으로 업로드한다.

2) 자체 CDN 구축  : IXP 및 거주용 ISP 자체에서 서버 렉을 설치.     

흐름 : 비디오를 선택하면 AWS위의 넷플릭스 소프트웨어가 CDN 클러스터 서버를 선택한다. 그러면 클라이언트와  CDN 서버는 독점 버전의 DASH로 상호작용한다.

 

유튜브

1) DNS 리다이렉션 사용 (클러스터 결정 정책 : 클라이언트와 서버간의 RTT 가 낮은 곳,  + 균형 분산)

2) HTTP 스트리밍 사용, 사용자에게 스스로 버전을 선택하게 함.

3) 비디오 업로드에도 HTTP 스트리밍 사용

 

 

 

 

 

 

<Socket Programming>

-> 코드 분석