[네트워크] 응용 프로그램 계층 (Application Layer)

0. 네트워크 어플리케이션의 원칙

네트워크는 계층을 나눠 설계되어 있다고 했다. 구체적으로 데이터가 전송되는 과정을 보면 다음과 같다. 다음 과정이 끝나면 데이터는 5중으로 잘 포장되고 가장 겉에는 물리(physical) 계층의 포장이 존재하게 된다.

 

0. 응용 프로그램 계층에서 해당하는 프로토콜로 데이터를 포장하고, 전송 계층으로 넘긴다.

1. 전송 계층에서 해당하는 프로토콜로 데이터를 포장하고, 네트워크 계층으로 넘긴다.

2. 네트워크 계층에서 해당하는 프로토콜로 데이터를 포장하고, 링크 계층으로 넘긴다.

3. ...

 

포장된 데이터의 정보를 토대로 데이터는 라우터들 사이로 알맞은 경로를 찾아간다. 목적지에 도착하면 한 겹 한 겹 포장을 벗긴다. 데이터를 받으면 물리 계층의 포장이 가장 겉 포장된 상태이다. 따라서 각자 자신 계층의 프로토콜로 포장된 데이터를 받아볼 수 있으며, 포장을 뜯어 필요한 정보를 얻어낸다. 이런 방식은 계층간의 독립성을 보장하여 시스템을 설계할 때 뿐 아니라 유지/보수 할 때도 훨씬 작업이 쉽고 단순하게 만든다.

 

0. 물리 계층에서 가장 겉의 포장을 뜯고, 링크 계층으로 넘긴다.

1. 링크 계층에서 가장 겉의 포장을 뜯고, 네트워크 계층으로 넘긴다. 

2. 네트워크 계층에서 가장 겉의 포장을 뜯고, 전송 계층으로 넘긴다.

3. ...

 

 

네트워크 어플리케이션
  - 이메일, 웹, 메신저, 원격 로그인, P2P 사이트, 유튜브, 넷플릭스, 검색엔진 등
  - 실제로 사용자가 이용하는 네트워크 프로그램은 대부분 어플리케이션 계층

 

네트워크 어플리케이션 개발
  - 각각의 종단 시스템에서 네트워크를 이용해 정보교환을 하는 프로그램
  - 네트워크 코어를 프로그래밍할 필요는 없다(더 쉽고 빠르게 app개발 가능)
  - 어플리케이션 구조(클라이언트-서버, P2P)

 

클라이언트 서버 구조(client-server architecture)
  - 서버 : 항상 켜져있는 호스트, 영구적인 IP를 가지며 응답가능한 데이터센터
  - 클라이언트 : 간헐적으로 켜져있는 호스트, 유동적인 IP를 가지며 정보를 요청
  - 서버와 클라이언트가 직접 소통하진 않음

P2P 구조(peer-to-peer architecture)
  - 항상 켜져있는 서버가 없음
  - 호스트가 직접 연결되어, 요청-응답하는 방식으로 동작
  - 자가 확장성(self-scalability) : 작업 부하를 주지만, 파일을 다른 피어에 분배해 서비스 능력 추가
  - 피어는 간헐적으로 연결되며, IP주소도 바뀔 수 있어 관리가 복잡함

프로세스 커뮤니케이팅(process communication)
  - 프로세스 : 여기서 프로세스는 호스트에서 돌아가는 프로그램을 의미
  - inter-process communication : 같은 호스트 내에서의 통신은 IPC로 (OS에 구현됨)
  - messages : 다른 호스트 간의 통신은 메세지 교환으로
  - 클라이언트(커뮤니케이션을 시작하는 프로세스), 서버(컨택을 기다리고 있는 프로세스)
  - P2P 어플리케이션은 클라이언트, 서버 프로세스를 모두 가지고 있어야함

 

소켓(sockets)
  - 프로세스는 자신의 소켓을 통해 메세지를 보내고 받음
  - 소켓은 프로세스의 문(door)과 같음
  - 메세지를 받는 쪽의 전송 구조에 따라 보내는 방식도 정해진다.

프로세스 주소 지정(addressing processes)
  - 메세지를 받기 위해서는 프로세스가 메세지를 식별할 수단(identifier)을 가지고 있어야함
  - 호스트 장치는 유일한 32bit IP 주소를 가짐
  - 하지만 IP주소만으로는 프로세스를 구분할 수 없음(같은 호스트 내에서 여러 프로세스 동작 가능)
  - 식별자(identifier)는 IP와 프로세스의 포트번호(port numbers)를 포함해야 함

응용 프로그램 계층 프로토콜(app-layer protocol defines)
  - 메세지의 종류 : 요청, 응답
  - 메세지의 문법 : 어떤 필드의 메세지인지, 어떻게 기술하고 있는지
  - 메세지의 의미 : 필드에서의 정보의 의미
  - 통신주기 규칙 : 언제 어떻게 메세지를 보내고 응답할지에 대한 규칙
  - 오픈 프로토콜 : RFC(Request For Comments, IETF에서 발행한 인터넷 표준)에 정의된 HTTP, SMTP
  - 개인 프로토콜(proprietary protocols) : Skype

응용프로그램이 네트워크 서비스에서 필요한 것
  - 데이터 무결성 : 100% 신뢰할 수 있는 데이터 교환(파일 교환, 웹 트랜젝션 / audio 데이터는 조금은 괜찮)
  - 타이밍 : 효율적인 동작을 위해 어떤 앱들은, 낮은 시간 지연을 요구(인터넷 전화, 온라인 게임)
  - 처리율 : 효율적인 동작을 위해 보장된 전송속도가 필요(비디오 등 / elastic 한 app들은 있는걸로 사용)
  - 보안성 : 암호화, 데이터 무결성  등

TCP(Transmission Control Protocol)
  - 신뢰할 수 있는 전송(reliable transport)
  - 흐름 제어(flow control) : 수신 한도를 넘어 손실(loss)가 일어나지 않도록 양을 조절
  - 혼잡 제어(congestion control) : 흐름 제어가 호스트 간의 트래픽을 조절한다면, 혼잡 제어는 네트워크 차원
  - 연결 기반(connection-oriented) : 클라이언트와 서버 간 사전설정이 필요
  - 미지원항목 : 타이밍, 최소 스루풋 보장, 보안

 

UDP(User Datagram Protocol)
  - 신뢰할 수 없는 데이터 교환(unreliable data transfer)
  - 미지원항목 : 신뢰성, 흐름/혼잡 제어, 타이밍, 스루풋 보장, 보안, 사전설정
  - 그럼 UDP 대체 왜 쓰는거임? : 오버헤드(CPU, 메모리 소요)가 적어서 단방향 빠른 전송 가능

TCP 보안화(securing TCP)
  - TCP와 UDP는 암호화가 안 된채로 인터넷을 횡단해 수신 측에 전송
  - SSL : TCP에 암호화된 연결을 제공, 데이터 무결성, 호스트 증명
  - SSL은 TCP에 이야기할 때 쓰는 라이브러리이므로 app layer에 존재(transprot layer X)
  - SSL 소켓 API는 암호화해서 메세지를 보냄

 

 

1. Web과 HTTP

지금 보고 있는 이 웹(설명 링크)페이지도 인터넷을 거쳐 보여지는 것이다. 먼저 웹 브라우저를 킨다. 웹 브라우저는 웹 문서를 보여주거나 요청하는 역할을 하는 도구(응용 프로그램 계층)이다. 사용자가 주소창에 주소를 입력하면, 웹 브라우저가 해당 주소를 가진 서버에 저장된 웹 문서를 요청한다. 이 과정은 TCP 연결을 기반으로 이루어지며, 요청이 집중되는 것을 막기 위해 전진기지인 캐시를 두기도 한다.

 

 

웹(web)
  - HTML파일이 기본이 되어 많은 객체들을 URL로 '참조'함
  - 객체(HTML파일, JPEG로, JAVA, 오디오파일 등)

HTTP(HyperText Transfer Protocol)
  - 웹의 응용 프로그램 계층(application layer)의 프로토콜
  - 클라이언트-서버 모델 사용
  - 클라이언트 : HTTP 프로토콜을 이용하여, 서버로 부터 데이터를 요청하고, 받고, 보여줌
  - 서버 : HTTP 프로토콜을 이용하여, 클라이언트에 요청에 맞게 객체들을 보내줌
  - TCP 사용
   1. 클라이언트가 서버와의 TCP 연결을 시작(소켓을 생성)한다.
   2. 서버는 클라이언트의 TCP 연결을 승인한다.
   3. HTTP 메세지(응용프로그램 계층의 프로토콜 메세지)가 HTTP서버-HTTP클라이언트 간에 교환된다.
   4. TCP 연결이 종료된다.

  - HTTP는 stateless : 서버는 상태 정보(과거)를 이용하지 않고 새로 도착한(현재) 정보만을 이용
  - 반면에 state가 있는 프로토콜들은 복잡(이전 기록 유지, 연결이 터졌을 때의 상태 정보등)

HTTP 연결
  - 비영구적 HTTP : TCP연결 위로 한 개의 객체가 전송되고 TCP연결을 종료. 여러개의 객체→여러개의 연결 필요
  - 영구적 HTTP : 여러개의 객체가 하나의 TCP 연결 위로 전송됨

비영구적 HTTP(non-persistent HTTP)
  0. HTTP 클라이언트가 TCP 연결을 시작한다. (hhlab.tistory.com, 포트 80)
  1. HTTP 서버가 연결을 기다리고 있다가 80번 포트 연결을 승인하고 클라이언트에게 알려준다.
  2. HTTP 클라이언트가 TCP 소켓으로 HTTP요청 메세지를 보낸다.  (hhlab.tistory.com에 있는 post56을 갖고 싶어)
  3. HTTP 서버는 요청을 받아 객체와 응답 메세지를 소켓으로 보낸다.
  4. HTTP 서버가 TCP 연결을 종료한다.
  5. HTTP 클라이언트는 객체(HTML 파일 등)를 받고 참조된 객체(이미지, 동영상 등)들을 파싱한다.
  6. 참조된 객체들을 위 과정을 한 번 씩 다시 거친다(한 번에 하나만 오니까)

  - RTT : 작은 패킷이 클라이언트에서 서버를 찍고 돌아오는데 걸리는 시간
  - HTTP 응답시간( TCP 연결시작(1 RTT) + 요청한 객체를 받는데 걸리는 시간(1 RTT + 파일 전송시간))
  - 한 객체당 2 RTT 이상 걸리지만, 객체가 추가로 여러개 와야하므로(참조된 파일들) 여러개 병렬로 연결해야함
  - 병렬로 연결을 여러개 하면, 그만큼 오버헤드 필요

영구적 HTTP(persistent HTTP)
  - 서버가 응답을 보내고도 연결을 열어놓음
  - 다음 메세지도 그 연결을 통해 전달(TCP 연결하는 1 RTT 절약가능)
  - 클라이언트도 참조된 객체를 바로 요청함
  - 모든 객체를 받는데 1 RTT 정도 안에 가능(파이프라이닝, 병렬연결 활용)

HTTP 메세지
  - 종류 : 요청, 응답
  - 형식 : ASCII(인간이 읽을 수 있는 형식)

HTTP 요청 메세지(HTTP request message)
  1. request line (GET, POST, HEAD : 메소드(method)) (URL : 객체주소) (HTTP 버전) /r(줄바꿈) /n (코드 라인 끝)
  2. header line (Host, User-Agent, Accept-Language, Connection 등 속성 헤더) (속성값-헤더값)
  3. entity body (정보 본체)

  - 클라이언트가 사용자의 입력을 업로드 하는 방식 : POST 함수 / GET 함수(URL에 업로드할 ?경로를 적는다)
  - HTTP 1.0 메소드(Method) GET, POST, HEAD(실제 문서가 아닌 문서정보를 요청)
  - HTTP 1.1 메소드(Method) GET, POST, HEAD, PUT, DELETE(URL에 있는 파일을 삭제)

HTTP 응답 메세지(HTTP response message)
  1. status line (HTTP 버전)
       (상태: 1xx 처리중, 2xx 성공, 3xx 위치바뀌었음(redirect), 4xx 클라이언트 에러, 5xx 서버에러)
  2. header lines
  3. entity body(데이터, HTML 본체 등)

쿠키(cookies)
  - 다음 4가지 컴포넌트
  - HTTP 응답 메세지의 쿠키 헤더라인
  - HTTP 요청 메세지의 쿠키 헤더라인
  - 웹 브라우저가 관리하는, 호스트에 저장된 쿠키파일
  - 웹 사이트의 백엔드 데이터베이스

  1. 클라이언트 : 나 이 페이지 접근하고 싶어
  2. 서버 : 야 잠깐만 너 내가 준 쿠키 가지고 있을래? (클라이언트 주고, 서버 자신의 데이터베이스에도 목록 생성)
  3. 클라이언트 : ㅇㅋ
  4. 클라이언트 : 야 또 난데 나 또 뭐 필요해. 지난번에 준 쿠키번호는 1678이야
  5. 서버 : 아 너 걔구나 내가 기억하지! 너는 그 때 이거 갖고 싶다 했으니까, 요렇게 해서 줘볼께

  - 쿠키의 활용(권한 확인, 사용자 맞춤 광고, 장바구니, 유저 세션상태 등)
  - 쿠키는 결국 상태 정보를 가지고 있는 http 메세지

캐시(web caches-proxy server)
  : 원래 서버를 거치지 않고도 클라이언트의 요청에 응답, 컴퓨터의 캐시메모리 / 전진 기지
  - 호스트가 요청을 보낼 때, 캐시에 존재하면 캐시가 클라이언트에 전송, 없으면 본 서버에서 받아옴(클라이언트&서버)
  - 캐시는 통상적으로 ISP가 설치
  - 응답 시간을 줄이고, 본 서버에 트래픽을 줄이고 분산 시킴. 상대적으로 영세한 컨텐츠 제공자가 효율적인 제공가능

캐시 예제 https://blog.naver.com/you_maybe/222120496954

  - 캐시가 내용이 최신이라면 요청을 보내도 서버에서 객체를 주지 않음(전송 지연, 링크 활용률 낮춤)
  - 클라이언트는 HTTP 요청에 캐시된 복사본의 날짜를 넣어보냄(서버는 if-modified-since : <data> 필드를 확인)

 

 

2. 전자 메일(electronic mail)

전자 메일(Electronic mail)
  - 3개의 주요 컴포넌트
  - 메일 리더(user agentㅡmail reader) : 메세지를 구성, 편집, 검색 등. 받은/보낸 메세지를 서버에 저장
  - 메일 서버(mail servers) : 메일박스(사용자에게 온 메세지를 저장), 메세지큐(보내는 메세지들 저장)
  - SMTP : 메일 서버 간의 프로토콜

SMTP(Simple Mail Transfer Protocol)
  - 신뢰성을 위해 TCP 사용(port 25)
  - 직접 전송(direct transfer) : 보내는 메일서버(서버)에서 받는 메일서버(클라이언트)로
  - 보내는 3단계
    1. 악수(안녕^^)
    2. 메세지 교환
    3. 종료
  - 명령/응답 상호작용(HTTP와 비슷), 명령은 ASCII로 응답은 status code, phrase로. 메세지는 7-bit ASCI

 

메일 보내는 과정
  1. A가 B에게 메세지를 보내려고 메일리더를 사용
  2. A의 응용프로그램이 A의 메일서버로 메세지를 보냄 >>메일서버 메세지큐에 저장됨
  3. A의 메일서버가 B의 메일서버에 TCP연결을 시작함
  4. A의 메일서버가 A의 메일을 TCP 연결위로 보냄
  5. B의 메일서버가 A의 메세지를 메일박스에 보관
  6. B가 그의 메일리더로 메세지를 확인

SMTP의 특징
  - 영구 연결(persistent connection)을 사용
  - 7-bit ASCII 메세지를 요구
  - CRLF.CRLF로 메세지의 끝을 구별
  - HTTP는 받아옴, SMTP는 보냄, 둘다 ASCII 명령/응답, 상태코드를 받는다.
  - HTTP는 각각의 객체가 각각의 응답메세지 안에 있다면, SMTP는 여러개의 객체가 여러부분에 나뉘어 전송

메일 메세지 형식(SMTP, RFC822)
  - 1. header (To:, From:, Subject:)
  - 2. blank line
  - 3. body("message"ㅡASCII)

메일서버로 부터 메일을 받아오는 프로토콜
  - POP : Post Office Protocol [RFC 1939] : 권한, 다운로드
    - POP3 프로토콜
      1. autorization phase : client commands(userㅡ이름, passㅡ암호), server responses(+OK, -ERR)
      2. transaction phase : (list : 메세지 번호 나열, retr : 메세지번호로 선택, del : 삭제,  quit)
    - "download and delete, download and keep" 모드 존재
    - POP3는 stateless(상태 정보 따로 저장X, 현재 정보만 이용)

  - IMAP : Internet Mail Access Protocol [RFC 1730] : 더 많은 기능, 서버의 저장된 메세지 조작
    - 모든 메세지를 서버 한 곳에 저장
    - 폴더에 정리할 수 있는 기능
    - stateful, 메세지 ID를 받으면 대응하는 폴더에 저장 가능

  - HTTP : Gmail, Hotmail 등

 

3. DNS (Domain Name System)

사람은 주민번호, 이름, 여권 등으로 다양하게 식별이 가능하다. 인터넷 상에서도 호스트나 라우터 등은 각자의 고유한 IP 주소를 가지고 있다. 하지만 우리가 이에 접근할 때 IP 주소보다는 'hhlab.tistory.com'과 같은 호스트 네임을 사용하여 접근한다. 그렇다면 호스트 네임을 내가 찾고자 하는 호스트의 IP주소와 매칭시키는 작업이 필요하다. 이것이 DNS 서버가 하는 일이다.

 

 

DNS란?
  - DNS는 호스트 네임을 IP주소로 만들어줌
  - 분배된 데이터베이스(많은 이름 서버들의 계층구조에서 실행)
  - 응용프로그램 계층 프로토콜(ㅡ네트워크 코어와 아무 상관없음) port 53

DNS 서비스
  - 호스트 네임을 IP주소로 바꿔준다. 
  - 호스트 앨리어싱(host aliasing) : IP 뿐아니라 정식 호스트 네임(ex. fb.com)을 얻기 위해서도 사용
  - 메일 서버 앨리어싱 : 메일주소의 정식 호스트 네임을 얻기 위해 사용
  - 부하 분산(load distribution) : 중복 서버 사이에 부하를 분산(하나의 이름에 여러 IP가 반응)

DNS 구조
  - 분배된 계층구조(com DNS 서버, org DNS 서버, edu DNS 서버 등)
  1. 'www.hhlab.co.kr IP주소가 궁금해요' 클라이언트가 루트 서버에 요청한다
  2. .kr DNS서버로 가자
  3. .kr 하위에 있는 .co DNS 서버로 가자
  4. .co에서 hhlab.co.kr을 찾는다
  5. www는 웹이라는 서브 도메인이다.

TLD(Top Level Domain), 책임 DNS 서버(authoritative servers)
  - TLD : 일반 최상위 도메인(com, net, org 등)과 국가코드 최상위 도메인(kr, jp, uk 등)
  - 책임 DNS 서버 : 조직이 그들의 DNS 서버를 가지면서, 그 안의 호스트들의 IP를 연결해줄 수 있다. 

로컬 DNS 네임 서버
  - 계층구조에 완벽히 들어가진 않는다
  - 각 ISP는 하나씩 가지고 있다.
  - 호스트가 DNS 요청을 하면, 로컬 DNS 서버에 먼저 가서 있으면 바로 제공 받고, 없으면 루트로 가야된다
  - 반복적 질문(iterated query) 로컬 DNS에 없으면 로컬 DNS가 루트, 최상위, 책임을 차례차례 물어봄
  - 재귀적 질문(recursive query) 로컬 DNS에 없으면, 루트가 밑에 묻고 재귀적으로 돌아온 답변을 로컬에 돌려준다.

DNS 캐싱, 업데이트(caching, updating records)
  - 네임 서버가 이름과 IP 대응을 한 번 배우면, 그것을 캐시에 저장(TLD는 보통 로컬에 캐시되어 있어서 루트 갈일↓)
  - 캐시된 목록은 최신이 아닐 수도 있음. TTL(Time To Live)가 끝나야 사라지고 최신 업데이트
  - 수정, 공지 과정도 IETF 표준 존재

DNS 레코드(records)
  - DNS의 분산 데이터베이스를 구현한 DNS 서버들은 호스트 네임을 IP주소로 매핑하기 위한 자원 레코드를 저장
  - RRㅡResource Records -> (Name, Value, Type, TTL)
  - type=A : (호스트 이름, IP주소)
  - type=NS : (호스트 도메인, 도메인 내부 호스트의 IP) ㅡ 책임 DNS서버의 호스트 네임을 알 수 있음
  - type=CNAME : (별명, 정식명칭)
  - type=MX : (이름, 메일서버)

DNS 프로토콜, 메세지
  - 질문과 응답 메세지가 같은 형식
  - 식별자(16bit, #질문의 수, #책임 RR의 수)
  - 플래그(#응답 RR의 수, #추가 RR의 수)
  - 질문(가변 질문 수)
  - 답변(가변 RR 수)
  - 책임(가변 RR 수)
  - 추가 정보(가변 RR 수)

DNS 등록
  - DNS registrar에 등록하고 싶은 이름, 책임 이름 서버의 IP 등 정보 제공
  - registrar가 TLD 서버에 RR 용도에 맞게 타입 결정해 등록

DNS 공격
  - DDoS 루트보단 의외로 TLD가 더 치명적
  - man-in-middle : 질문을 가로챈다
  - DNS poisoning : 캐시해도 되는 것을 DNS서버에 엄청난 부하를 줌
  - 거짓 주소를 사용해 요청함

 

 

4. P2P 프로그램 (Peer-to-Perr Application)

P2P
  - 임의의 호스트(피어, Peer)가 직접 통신
  - 피어는 간헐적으로 연결되고, IP가 유동적임
  - 서버-클라이언트 구조는 직접 통신하지는 않으며, 서버가 항상 켜져있고 고정 IP를 가짐

하나의 서버로 N명의 Peer에게 크기 F의 파일을 뿌리는데 걸리는 시간?
  - 서버가 크기 F의 파일을 N개 전송하는 시간 = N * F / 서버 업로드 능력
  - 클라이언트가 보내준 파일을 받는 시간 = F / 분당 클라이언트 다운로드 속도
  - 둘 중, 더 오래 걸리는 시간 : max(NF/u.s, F/d.min)
  - 하지만 서버 전송시간이 피어의 숫자의 비례해서 늘어남

P2P 방식으로 N명의 Peer에게 크기 F의 파일을 뿌리는데 걸리는 시간?
  - 서버가 크기 F의 파일을 (최소) 1개 전송하는 시간 = F / 서버 업로드 능력
  - 클라이언트가 보내준 파일을 받는 시간 = F / 분당 클라이언트 다운로드 속도
  - 어찌됐든 F크기 파일이 N번 전송되야 함 = N * F / 서버 업로드 능력 + 모든 클라이언트 업로드 능력
  - 이 역시 피어의 숫자에 비례해 늘어나지만, 클라이언트 업로드 능력역시 같이 늘어남

토렌트(BitTorrent)
  - 토렌트 : 256Kb 단위로 나눠진 파일 조각들
  - 트래커 : 토렌트를 주고 받고 있는 피어들
  1. 트래커로 등록 후, 피어(다른 트래커)들의 리스트를 받는다.
  2. 리스트 중 몇 명의 피어와 연결한다.
  3. 다운로드 하면서, 피어는 다른 피어들에게 파일 조각을 전송한다.
  4. 다운로드가 끝나면 피어는 전송을 끝낼지, 네트워크에 남아있을지 선택할 수 있다.

토렌트에서의 요청
  - 다른 피어들은 다른 파일 조각들을 가지고 있음
  - 주기적으로 다른 피어들에게 각자가 가진 파일 조각의 리스트들을 물어봄
  - 자신이 없는 파일 조각 중 희귀한 것을 우선으로 요청

토렌트에서의 전송(tit-for-tat)
  - 자신에게 가장 빠른 속도로 파일 조각을 보내고 있는 4명의 사용자에게 자신의 파일 조각을 보냄
  - 10초 마다 자신이 보낼 4명의 리스트를 갱신함
  - 30초 마다 랜덤으로 다른 피어를 선택해 자신의 파일 조각을 보냄
  - 만약, 내가 랜덤으로 A를 골라 내가 A의 리스트 중 TOP4 안에 들었다면, A도 내게 파일 조각 전송
  - 그렇다면 A가 내 TOP4 안에 들 가능성도 有
  - 반복할 수록 자신에게 가장 빠르게 보낼 수 있는 파트너를 찾게됨

 

 

5. 콘텐츠 전송 네트워크 (Contents Delivery Network)

비디오 스트리밍
  - 비디오 트래픽은 인터넷 대역폭을 주요하게 차지하는 것 중 하나(넷플릭스는 가정용 ISP의 37% 차지)
  - 문제 : 1B users, 각자 다른 대역폭은 어떻게 해결해야할까?
  - 해결 : 분산, 응용프로그램 계층의 구조

영상, 이미지
  - 영상은 일정한 주기로 보여지는 연속의 이미지
  - 이미지는 각 픽셀이 비트로 표현되는 배열
  - 영상은 연속의 이미지 중 겹치는 것을 압축(temporal) : (겹치는 것은 색상, 겹치는 갯수)로 전송
  - 이미지는 겹치는 픽셀 값들을 압축(spatial) : (픽셀 값, 주변 픽셀값들과의 차이)로 전송
  - CBR(constant bit rate) : 영상 인코딩 속도를 고정
  - VBR(variable bit rate) : 영상의 temporal, spatial 압축 정도에 따라 인코딩 속도 가변, ex) MPEG

DASH(Dynamic Adaptive Streaming over HTTP) 서버
  - 비디오 파일을 여러개의 조각으로 쪼갬
  - 각 조각으로 저장되어 있고, 각기 다른 속도로 인코딩 되어있음
  - 각 조각의 URL 주소를 담고 있는 메타데이터 파일(manifest file) 존재

DASH 클라이언트
  - 주기적으로 서버-클라이언트 대역폭을 측정
  - 받아야하는 파일목록의 큰그림을 그린 후, 한 번에 한 파일 조각씩 요청함
  - 현재 대역폭에서 유지할 수 있는 최대 인코딩속도를 선택
  - 인코딩 속도는 언제든 설정 가능(단, 대역폭이 뒷받침이 되어야함) 
  - 똑똑한 클라이언트가 필요
  - '언제' 파일 조각을 요청할지(너무 적게 혹은 너무 많이 받지 않게)
  - '어떤' 인코딩 속도로 요청할지(대역폭이 크면 더 좋은 품질의 영상)
  - '어디'로 요청할지(최대 대역폭을 받을 수 있는 가장 가까운 서버로, URL

CDN의 문제점
  - CDN : 전진기지에 컨텐츠의 복사본을 저장해놓은 것.
  - 수백만 개의 동영상이 저장된 서버에서 특정 동영상을 찾아서,
  - 어떻게 동시에 수백 수천명의 유저에게 동시에 데이터를 줄것인가?
  1. 하나의 큰 '메가-서버' : 안됨 ㅅㄱ
  2-1. CDN을 설치(enter deep) : CDN을 클라이언트와 가까운 곳에 여러개 설치
  2-2. CDN을 설치(bring home) : 본 네트워크 근처에 큰 CDN을 몇개만 설치 

OTT(Over The Top)
  - '셋톱(Top)박스를 넘어!'
  - 다양한 플랫폼으로 인터넷을 통해 언제 어디서든 미디어 컨텐츠를 소비할 수 있는 서비스
  - 해결과제 1 : 어떤 CDN에 접근해서 컨텐츠를 받아야하는가?
  - 해결과제 2 : 네트워크가 혼잡할 때, 시청자는 어떻게 해야하는가?
  - 해결과제 3 : 어떤 CDN 노드에 어떤 콘텐츠를 저장해야하는가?

넷플릭스 동영상 시청 과정
  1. 근남이가 넷플릭스 계정을 등록한다.
  2. 근남이가 넷플릭스 비디오를 킨다.
  3. 서버에서 해당 비디오의 매니페스트 파일(이 비디오의 파일 조각들의 URL 주소가 담긴 파일)을 받는다.
  4. 해당 주소로 접근해 동영상 파일 조각들을 받아오며 DASH 스트리밍 한다.