컴퓨터 네트워크 2. 어플리케이션 계층

1. 네트워크 애플리케이션의 원리

💡 네트워크 app을 만드는 방법
(1) 다른 end system에서 동작되는 프로그램을 작성
(2) 네트워크를 통해 서로 communication하도록 작성
e.g., 웹 서버 소프트웨어는 브라우저 소프트웨어와 communication되어야 함
참고로 네트워크 코어 장치를 위한 소프트웨어를 만들필요 전혀 ❌
네트워크-코어 장치는 user application을 작동못시킨다.

1.1 네트워크 애플리케이션 구조
application에서 가능한 구조는 2가지가 있다 :
client-server
peer-to-peer (P2P)
(1) 클라이언트-서버 구조

서버
호스트상에서 동작
영구적인 IP주소
확장을위한 데이터센터 역할을 한다.

클라이언트
서버와 communication을 함
동적 IP주소
간헐적으로 접속
클라이언트간 직접 communication 불가
P2P는 가능!

(2) P2P 구조

항상 켜져있는 서버가 없다.
각각의 개인이 서로서로간에 서버이자 클라이언트로서(peer로서) 동작한다.
self scalability : 새로운 peer가 서비스를 요청할 뿐만 아니라 서비스를 제공한다.
peer는 간헐적으로 접속하면서 IP주소가 바뀐다

1.2 프로세스 간 통신
process : host에서 실행중인 프로그램
inter-process communication: 같은 host내에서 동작하는 다른 프로세스간 통신
message passing : 다른 호스트들 간의 프로세스는 message를 교환하며 통신

(1) client-server모델의 프로세스
client process : communication하기위해서 통신을 시작하는 프로세스
server process : 항상 동작하면서 연결을 기다리는(wait-to-be-contacted) 프로세스
그럼 p2p 모델의 프로세스는??
client process와 server process를 모두 가지고 있는 아키텍쳐

(2) 소켓
그렇다면 프로세스간 통신하기 위해서는 어떻게 해야할까? 👉 소켓
📝 소켓 : 프로세스와 컴퓨터 네트워크 사이의 인터페이스
e.g., 전선꼽는 돼지코 모양의 콘센트가 소켓이다. 데이터 전송을 위해 왔다갔다 할수있는 입출구역할을 한다.
프로세스는 socket을 통해 메시지를 주고받는다.

위 그림에서 애플리케이션 아래 계층은 신경쓸 필요없이 애플리케이션 계층에서 소켓에다가 그냥 집어넣으면 다른 호스트에서도 애플리케이션 계층의 소켓을 통해 데이터를 꺼낸다.
송신 프로세스는 수신 프로세스에 있는 소켓에 메시지를 전달하기 위해 수신자의 소켓의 전송 인프라에 의존

(3) 프로세스 주소 배정
소켓으로 통신을 할 수 있다 치더라도 일단 기본적으로 상대방 소켓의 이름(=주소)을 알아야 소켓을 사용하건 말건 한다.
즉, 프로세스는 통신(메시지를 주고받기위해)을 하기위해 상대 프로세스가 누구인지 식별자가 필요하다. 이 식별자가 바로 IP주소(32-bit)다.
하지만, 프로세스가 실행되고 있는 호스트의 IP주소만으로는 충분치 않다. 왜냐하면 같은 호스트내에서 아주 많은 프로세스들이 실행되고 있기 때문이다.
IP주소 뿐만아니라 반드시 port번호가 필요하다 !! 즉 식별자는 IP주소 + 프로세스와 연관된 port번호이다!!
연관된 포트번호란 HTTP server의 port번호가 80이고, mail server의 port번호가 25인 것 처럼 각 프로세스에는 default port번호가 대부분 정해져있다.

1.3 전송계층이 응용계층에게 제공할 수 있는 서비스
소켓은 응용계층과 전송계층의 인터페이스이므로 전송계층의 프로토콜 중 하나를 선택해야할 필요가 있다. 그럼 전송계층의 어떤 부분을 보고 선택을 해야할까??

(1) 데이터 무결성(data integrity)
어떤 앱은 데이터를 주고 받을 때 데이터가 손상되지(바뀌지) 않아야함(은행시스템의 경우)
또 다른 앱은 데이터 손상이 조금있어도 감내가능(손실허용 어플리케이션 : 멀티미디어)

(2) 시간(time)
e-mail같은 경우 시간이 지연되어도 됨
인터넷 전화, 게임같은 경우 효과적인 서비스를 위해 최소한의 지연을 요구

(3) 처리율(throughput)
서비스가 효율적으로 작동시키기 위한 최소한의 처리율이 필요한 앱이 있다.(멀티미디어)(이정도의 처리율은 되야 서비스작동가능한 앱)
일부 애플리케이션은 덜 민감(이메일)(탄력적 애플리케이션)

(4) 보안(security)
암호화(encryption) 및 데이터 무결성 제공

1.4 실제 인터넷 상에서 전송계층 프로토콜이 제공하는 서비스들

(1) 전송계층 프로토콜의 서비스가 다 짜여진 응용계층의 서비스
아래 그림은 1.3의 이용가능한 트랜스포트 서비스가 입맛에 맞게 골라진 실제 인터넷상의 애플리케이션들이다.

(2) 인터넷상에서 실제 서비스가 구현되어진 transport protocol
transport protocol은 2가지가 있다.
(1) TCP(Transmission Control Protocol)
- 연결지향형(데이터 전송전 클라이언트-서버간 연결설정,확인) : Connection-oriented
- 신뢰적인 데이터 전송 : 송/수신 프로세스 간의 데이터의 손실 없이 올바른 순서로 전달, 패킷의 Loss 발생시 tcp는 패킷을 재요청 하여 올바른 순서로 맞춰 응용계층에 올려줌
- 흐름 제어 : 송수신 프로세스가 수신 프로세스의 데이터 수신 속도에 맞추어 송신
- 혼잡 제어 : 네트워크가 혼잡 상태에 이르면 프로세스의 전송 속도를 낮춘다.
❓ 제공하지 않는 서비스? 시간 보장, 최소 처리율 보장, 보안성

(2) UDP(User Datagram Protocol)
- 비연결지향형(그냥 데이터 막 보냄) : Connectionless
- 비신뢰적인 데이터 전송 : 패킷 손실 발생 시 재전송을 요청하지 않음
- 흐름 제어, 혼잡 제어, 시간 보장, 처리율 보장, 보안 등의 서비스도 제공하지 않음 : 아무 것도 하지 않으므로 빠르다, 따라서 실시간 애플리케이션 들이 전송 속도 향상을 위해 udp 사용
- 실시간 애플리케이션들의 전송 속도를 위해 UDP 사용 : tcp의 혼잡 제어와 패킷 오버헤드 문제를 회피, 많은 방화벽들이 udp 트래픽을 차단하도록 설정되어 점차적으로 tcp 상에서 멀티미디어와 실시간 애플리케이션을 수행하도록 선택
각각의 호스트들이 독립적으로 네트워크를 사용하게 됨

(3) 인기있는 응용계층프로토콜 그에 맞는 하위 트랜스포트 프로토콜

UDP를 사용하는 대표적인 응용 프로토콜 : DNS, SNMP, RIP, VoIP
* DNS(Domain Name System, 도메인 네임 시스템)
: 호스트의 도메인 이름을 호스트의 네트워크 주소로 바꾸거나 그 반대의 변환을 수행할 수 있도록 하기 위해 개발되었다. 특정 컴퓨터의 주소를 찾기 위해 사람이 이해하기 쉬운 도메인 이름을 숫자로 된 식별 번호로 변환해준다.

* SNMP(Simple Network Management Protocol, 간이 망 관리 프로토콜)
: 네트워크 상의 각 호스트에서 정기적으로 여러가지 정보를 자동적으로 수집하여 네트워크 관리를 하기 위한 프로토콜로 UDP 상에 정의된 응용 계층 표준 프로토콜이다.

* RIP(Routing Information Protocol, 라우팅 정보 규약)
: UDP/IP 상에서 동작하는 라우팅 규약으로 경유하는 라우터의 대수에 따라 최단 경로를 동적으로 결정하는 거리 벡터 알고리즘을 사용한다.

(4) 보안 TCP
TCP와 UDP
- 암호화 제공 ❌
- 즉, 소켓을 통해 평문이 그대로 전송됨
💡 해결방안?
SSL(Secure Socket Layer)
- 암호화 된 TCP 연결을 제공
- 데이터 무결성
- 종단 인증
SSL은 응용계층에 있다.!
- 애플리케이션은 SSL 라이브러리를 사용하여 암호화 된 데이터를 TCP 소켓에 전달

 

1.5 애플리케이션 계층 프로토콜

1 애플리케이션 프로토콜이 정의하는 내용
(1). 교환되는 메시지 타입 :
request
response
(2). 메시지 문법 :
필드와 필드간의 구별법(아래 두가지를 사용해서 구별)
메시지의 필드가 무엇인지
그 필드가 어떻게 기술되고있는지
(3). 메시지 의미 :
필드내 존재하는 정보의 의미
(4). 규칙 :
언제 / 어떻게 프로세스가 메시지를 송/수신해야 하는지에 대한 규칙

2. 표준/비표준 application 프로토콜
위 4가지를 모두 이용하여 만들어지는 프로토콜 :

개방 프로토콜(open protocols):
- RFCs에서 정의된 표준프로토콜
- 상호작용(interoperability) 허용
e.g., HTTP, SMTP

독점 프로토콜(proprietary protocols):
- 표준이 아닌 자체적으로 만든 프로토콜
- e.g., Skype

2. 웹과 HTTP

(1) 웹 페이지는 객체들로 구성
- 객체는 HTML 파일, JPEG이미지, 자바 애플릿, 오디오 파일 등
(2) 웹 페이지는 기본 HTML 파일과 여러 참조 객체들로 구성
- HTML 파일은 사이사이에 link들이 존재하며, link들이 객체 참조 주소를 가짐
(3) 각 객체는 URL로 지정
- URL은 객체를 가지고 있는 서버의 호스트 이름과 객체의 경로 이름으로 구성
- 인터넷의 모든 객체는 URL보유

📌 HTTP 개요
HTTP(HyperText Transfer Protocol) : 웹 애플리케이션 계층 프로토콜

 

(1) HTTP는 TCP를 사용
①클라이언트는 80번 포트로 서버에게 TCP연결(소켓 생성)을 시작
②서버는 클라이언트의 TCP연결 요청 수랑
③웹 브라우저와 웹서버 사이에 HTTP 메시지를 교환
(2) HTTP는 비상태 프로토콜(Stateless Protocol)
- 서버는 클라이언트의 과거 요청들에 대한 정보를 유지 하지 않음
👉 서버가 client의 state를 저장 하지 않음

참고 : "상태"를 유지하는 프로토콜은 복잡함.
과거의 기록(상태)들을 유지, 관리해야 하기 때문
서버나 클라이언트 중 하나가 깨진 경우 각각의 "상태"가 불일치하게 되어 조정 필요

1.1 비지속/지속 연결

HTTP는 비지속 연결과 지속 연결 2가지 방식 존재 :

(1) 비지속 연결(non-persistent HTTP)
요구/응답 쌍이 분리된 tcp연결을 통해 송/수신 👉 객체 1개를 받기 위해 연결 요청 해야 함
하나의 tcp 연결로 하나의 객체만 전송 : 시간이 많이 걸려 비효율적임
단점 : 각 객체 당 2RTT 필요 (각 TCP 연결에 대한 OS 오버헤드가 필요하다.)
웹 브라우저는 참조 객체들을 가져오기 위해 종종 병렬 TCP 연결을 시도

RTT(Round-Trip Time)
: 클라이언트에서 송신된 패킷이 서버까지 간 후 응답이 다시 되돌아 오는데 걸리는 시간

HTML 파일 요청 응답 시간
TCP 연결을 초기화하는 1RTT
HTTP 요청 후 HTTP 응답으로 처음 몇 바이트를 받는데 필요한 1RTT
파일 전송 시간
따라서, 비지속 HTTP의 응답 시간 = 2RTT + 파일 전송 시간

(2) 지속 연결(persistent HTTP)
모든 요구 / 응답 쌍이 같은 tcp 연결 상에서 송수신 : 1번 요청으로 서버에게 여러번의 data 요청 가능
하나의 tcp 연결로 다수의 객체들이 전송
서버는 응답을 보낸 후에 TCP 연결을 유지(일정 시간이 지나면 terminated)
클라이언트 / 서버 간의 이후 HTTP 메시지들은 같은 연결을 통해 송수신 : 연달아서 연결 요청 전송 가능
클라이언트는 객체를 참조하자마자 요청을 송신(응답대기X)
모든 참조 객체들에 대해 1RTT만 필요

1.2 HTTP 메시지 포맷
HTTP 메시지 포맷에는 2가지 유형이 있다: HTTP request, HTTP response
(1) HTTP request message 포맷

📝 <input> form태그로 업로드
POST Method
- 입력은 url 필드가 아닌 개체 몸체(entity body)로 서버에 업로드
- 크기 제한이 없고 보안성 뛰어남

GET Method(= URL Method)
- 입력은 요청 라인의 URL 필드로 서버에 업로드
- 입력 받을 수 있는 크기에 제한이 있으며, 입력 data가 그대로 들어가므로 보안 취약

📝Method type
HTTP/1.0
GET
POST
HEAD : GET 방식과 유사하나 서버가 응답 시 요청된 객체 전송 안함. 즉, HTTP Header 정보만 수신

HTTP / 1.1
GET, POST, HEAD
PUT : URL 필드에 명시된 경로로 개체 몸체 안에 파일 업로드
DELETE : URL 필드에 명시된 파일을 삭제

(2) HTTP response message 포맷

📝 HTTP response status code
웹 서버에서 반환하는 상태값으로, 상태코드는 서버가 클라이언트에게 response message를 돌려줄 때 가장 1번째 라인에 표시됨

200 OK : 요청 성공되었고, 요청된 객체가 이 메시지로 보내짐
301 Moved Permanently : 요청된 객체가 이동되었고, 새로운 URL은 메시지의 "Location:" 헤더로 표시(redirection)
302는 Moved Temporarily
400 Bad Request : 서버가 요청을 이해할 수 없다는 일반 오류 코드
401 Unauthorized: 인증실패
403 Forbidden : 접근금지
404 Not Found : 요청된 문서가 서버에 존재하지 않음
500 Internal Server Error: 서버에러
505 HTTP Version Not Supported : 요청된 HTTP 프로토콜 버전을 서버가 지원 안 함

1.3 사용자와 서버간 상호작용: 쿠키

4가지 요소

(1) HTTP 응답 메시지 쿠키 헤더라인

(2) HTTP 요청 메시지 쿠키 헤더라인

(3) 사용자의 브라우저에 사용자 종단 시스템과 관리를 지속시키는 쿠키파일

(4) 웹사이트의 백엔드 데이터베이스

 

Authorization / 장바구니 / 추천 / user session state 등에 사용될 수 있다.

BUT

사생활의 침해가 될 수 있다.

1.4 웹 캐싱(Web caching)=proxy server

목표 : 클라이언트 request를 origin 서버의 개입없이 만족시키는것

- 자체의 저장 디스크를 갖고 있어 최근 호출된 객체의 사본을 저장 및 보존

- 브라우저가 설정되면 객체에 대한 각각의 브라우저 요청은 웹캐시에 가장 먼저 보내진다.

- 웹캐시가 객체를 가지고 있으면, 캐시에서 전송 / 없으면, origin 서버에 요청해서 받아온 후 객체의 사본을 보낸다.

- 캐시는 서버이면서 클라이언트

 

장점

(1) 클라이언트의 요구에 대한 응답시간을 줄일 수 있다

(2) 한 기관에서 인터넷으로 접속하는 링크상의 웹트래픽을 대폭으로 줄일 수 있다

(3) 인터넷 전체의 웹 트래픽을 실질적으로 줄임으로써 모든 애플리케이션을 위한 성능을 개선한다.

 

조건부 GET (웹 캐시 내부에 있는 객체의 복사본이 새것이 아닐 수 있다.)

캐시서버는 HTTP 요청에 복사본이 언제 캐시에 복사되었는지를 나타낸다 (If-modified-since:<date>)

서버는 복사본이 최신인 경우에 데이터를 보내지 않고, 변경사항이 있는경우 변경된 파일을 함깨 보낸다.

3. 인터넷 전자메일

3가지 주요 요소

(1) User agents : 메일 메시지의 구성, 편집, 읽기를 수행. Outlook, iPhone mail client, 들어오고 나가는 메시지들은 서버에 저장된다.

(2) mail servers : 

- mailbox는 유저에게 들어온 메세지들을 보관한다.

- message queue 에는 보내질 메세지들이 보관된다.

- 메일서버들간의 SMTP protocol 은 이메일 메세지를 전달하는 역할을 한다. (Client : 메일을 보내는 서버/ Server : 메일을 받는 서버)

(3) simple mail transfer protocol(SMTP) :

신뢰있는 전송을 위해 TCP를 사용하고, 포트 25번을 사용한다.

direct transfer : 전송서버에서 수신서버로 직접 전송한다

전송의 3가지 단계

(1) 핸드셰이킹 : 

(2) 메세지들의 전송 : 

(3) 종료 : 

HTTP처럼 command / response interaction을 한다.

commands : ASCII text

response : status code and phrase

SMTP는 지속적인 커넥션을 사용한다.

메세지(header & body)가 7비트 아스키여야 한다.

CRLF.CRLF를 메세지의 끝에 사용한다.

 

HTTP와의 비교:

HTTP : Pull

SMTP : Push

둘다 아스키 command/ response interaction과 status codes를 가진다.

HTTP : 각각의 오브젝트들은 그들의 response message안에 캡슐화된다

SMTP : 다수의 오브젝트가 Multipart message안에 담겨 전송된다.

 

메일 메세지 포멧

메일 접속 프로토콜

SMTP : 수신자의 서버까지 전송 / 저장

POP : Post Office Protocol : 인증 / 다운로드

- 다운로드후 삭제 모드에서는 클라이언트를 바꾼경우(pc로 읽고 모바일로 접속하면) email 을 다시 읽을 수 없다.

- 다운로드후 유지 모드에서는 각각의 클라이언트에 메세지를 복사해서 읽는다.

- POP3 세션 사이에 상태정보를 가지지 않는다.

IMAP : Internet Mail Access Protocol :

- 모든 메세지를 서버에 보관

- 유저에게 폴더안에 메시지를 정리할 수 있게 함

- 세션사이의 상태정보를 유지함

HTTP : gmail. Hotmail, Yahoo! Mail

4. DNS-인터넷의 디렉터리 서비스

인터넷 호스트 / 라우터들:

- IP 주소(32 BIT) : datagram들을 식별하기위해 사용 

- 호스트 네임 : www.facebook.com 

이들을 연결하는 방법이 DNS

- DNS 서버들의 계층구조로 구현된 분산 데이터베이스

- 호스트가 분산 데이터베이스로 질의하도록 허락하는 어플리케이션 계층 프로토콜

dns 는 다른 애플리케이션 프로토콜들이 HTTP,SMTP, FTP 등 사용자가 제공한 호스트네임을 IP 주소로 변환하기 위해 주로 이용

 

제공하는 서비스

(1) 호스트 엘리어싱 : 복잡한 호스트네임(정식호스트 네임:Canonical hostname))을 가진 호스트는 하나이상의 별명(별칭 호스트네임 : alias names)을 가질 수 있다. (relay1.west-coast.enterprise.com => enterprise.com) 이때 원본 호스트네임을 이라고 한다.

(2) 메일서버 엘리어싱 : 전자메일 회사 서버의 주소가 개인의 주소에 포함되는데, 전자메일회사 서버의 주소의 별칭을 만들어 간단하게 만든다.

(3) 부하 분산 : cnn.com 같은 인기있는 사이트는 여러 서버에 중복되어 있어서, 각 서버가 다른 종단 시스템에서 수행되고 다른 IP 주소를 갖는다.

중복 웹서버의 경우, 여러 IP 주소가 하나의 정식 호스트네임과 연관되어 있다.

 

DNS를 중앙화 하지 않는 이유?

(1) 서버의 고장 : 서버가 고장나면 전체 인터넷 작동 X

(2) 트래픽 양 : 단일 dns 서버가 모든 dns 질의를 처리해야 한다.

(3) 먼 거리의 중앙 집중 데이터베이스 : 단일 DNS 서버가 모든 질의 클라이언트로 부터 가깝지 않다.

(4) 유지 관리 : 단일 네임 서버는 모든 인터넷 호스트에 대한 레코드를 유지해야 한다.

=> 단일 DNS 서버에 있는 중앙 집중 데이터베이스는 확장성이 전혀 없다.(사용자가 늘어나면 문제가 생김)

 

분산 계층 데이터베이스(Distributed Hierarchieal database)

세 유형의 DNS 서버 :

(1) 루트 DNS 서버 :

- mapping을 모를 경우 책임 dns 서버에 연락한다.

- 매핑 정보를 받아온다

- 지역 네임 서버에 매핑 정보를 반환한다.

(2) 최상위 레벨 DNS 서버(TLD 서버) : com, org, net, edu, aero, jobs, uk, fr, ca ...

(3) 책임 DNS 서버 : 기관이나 서비스 제공자에의해 지속적으로 제공되는 자체 DNS 서버들로 호스트네임을 ip 주소로 매핑하는 공개적인 DNS 레코드를 제공

 

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

=> 루트 서버는 최상위 레벨 도메인 com을 갖는 TLD 서버 IP 주소를 보낸다.

=> 클라이언트는 이 TLD 서버중 하나에 접속하고, 서버는 도메인 amazon.com을 가진 책임 서버의 IP주소를 보낸다.

=> 클라이언트는 amazon.com의 책임 서버중에서 하나로 접속한다. 서버는 www.amazon.com의  의 IP 주소를 보낸다.

로컬 DNS 서버 :

- 서버들의 계층구조에 엄격하게 속하지 않지만, DNS 구조의 중심에 있다.

- 각각의 ISP 들은 하나씩 가지고 있다. (디폴트 네임 서버)

- 호스트가 DNS 쿼리를 만들때, 쿼리는 로컬 DNS 서버로 보내진다.

- 최근의 name-to-address translation pair들의 로컬 캐시를 가지고 있다.

- 프록시로 작동하며, 쿼리를 계층구조로 보낸다.

 

반복적 질의

재귀적 질의

DNS : 캐싱, 레코드 업데이트

- 한번 어떤 네임서버가 매핑 정보를 학습하면, 해당 정보를 캐시한다

-- 캐시 항목은 일정 시간이 지난 후에(TTL) 사라진다.

-- 최상위 도메인(TLD) 서버는 일반적으로 지역 네임 서버에 캐시됨

--- 따라서 루트 네임 서버는 자주 방문되지 않음

-  캐시된 항목은 시간이 지난 후에 더 이상 유효하지 않을 수 있음 (최선의 노력을 기반으로 하는 이름을 주소로 변환)

-- 호스트 이름이 IP 주소를 변경하면, 모든 TTL이 만료될 때까지 전체 인터넷에서 알려지지 않을 수 있음

- 업데이트/통지 메커니즘은 IETF 표준으로 제안됨

 

DNS 레코드

DNS 분산 데이터베이스를 구현한 dns 서버들은 호스트네임을 IP 주소로 매핑하기 위한 자원 레코드(Resource Record : RR)를 저장한다.

DNS 메시지

DNS 에 RECORD를 삽입하는법

예시: 신생 기업 "네트워크 유토피아"

(1) DNS 등록기관 (예: 네트워크 솔루션)에서 networkuptopia.com 이름을 등록
권한 있는 네임 서버의 이름과 IP 주소를 제공함 (주 서버 및 보조 서버)
(2) 등록기관은 .com 최상위 도메인(TLD) 서버에 두 개의 레코드를 삽입함:
(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)
(3) www.networkuptopia.com을 위한 권한 있는 서버에서 A 레코드를 생성함.
(4) networkutopia.com에 대한 MX 레코드를 생성함.

5. P2P 파일 분배

순수한 P2P 구조

- 항상 켜져있는 서버가 없다

- 임의의 종단시스템들이 직접 소통한다.

- peer들은 간헐적으로 연결되며 IP 주소를 바꾼다

 

파일 분배 문제 : Client-server VS P2P

클라이언트 - 서버

P2P

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

토렌트 : 파일 분배에 참여하는 모든 피어들의 모임

피어들은 서로에게서 같은 크기의 청크를 다운로드한다.(일반적으로 256KB)

트래커 : 각 토렌트가 가지는 기반구조 노드 / 한 피어가 토렌트에 가입할때 트랙커에 자신을 등록하고 주기적으로 자신이 아직 토렌트에 있음을 알린다.

6. 비디오 스트리밍과 컨텐츠 분배 네트워크

비디오 트래픽: 인터넷 대역폭의 주된 소비자

 

비디오 : 이미지들의 연속으로서 일반적으로 초당 24개또는 30개의 이미지로 일정한 속도로 표시된다.

디지털 이미지 : 픽셀 단위로 구성되며 각 픽셀은 휘도와 색상을나타내는 여러 비트들로 인코딩 된다.

비디오의 중요한 특징은 압축될 수 있다는 것.

coding : 이미지들 사이의 불필요한 중복들을 이용해 비트수를 줄이는것

- spatial : 같은색인 경우 N같은 비트를 보내지 않고, 비트수와 색정보 2개만 보낸다

- temporal : 바로 직후 프레임과 현 프레임의 차이만 전송

CBR : 일정한 비트레이트

VBR : 보내는 양 조절 coding으로 인해

 

멀티미디어 스트리밍 : DASH

Dynamic, Adaptive Streaming over HTTP

서버 : 

- 비디오 파일은 서로다른 버전으로 인코딩되며, 각 버전은 서로다른 비트율과 품질수준을 갖고있다

- 각각의 청크들은 다른 rate로 저장되고 인코딩 된다

- HTTP 서버는 비트율에 따른 각 버전의 URL을 제공하는 manifest 파일을 가지고있다.

클라이언트 : 

- 동적으로 서로다른 버전의 비디오를 몇초 분량의 길이를 가지는 비디오 조각 단위로 요청한다.

- 클라이언트는 HTTP GET 요청을 이용해 다른 버전의 비디오 조각을 매번 선택한다.

- 언제 / 어떤 인코딩 rate로 / 어느 주소의 청크를 요청할 지 결정한다.

 

콘텐츠 분배 네트워크 : CDN

다수의 지점에 분산된 서버들을 운영하며, 비디오 및 다른 형태의 웹 콘텐츠 데이터의 복사본을 이들 분산 서버에 저장한다.

사용자는 최고의 서비스와 사용자 경험을 제공할 수 있는 지점의 cdn 서버로 연결된다.

 

서버의 위치에 대한 두 가지 철학

- Enter Deep : 세계 곳곳의 접속 네트워크에 서버 클러스터를 구축

- Bring Home : 적은 수의 핵심지점에 큰규모의 서버 클러스터를 구축

 

OTT (Over The Top)

1. 사용자 호스트의 웹 브라우저가 url을 지정함으로써 특정 비디오의 재생을 요청함녀 CDN은 그 요청을 가로채 그시점에서 클라이언트에게 가장 적당한 CDN 클러스터를 선택하고, 클라이언트의 요청을 해당 클러스터의 서버로 연결한다.

7. 소켓 프로그래밍 : 네트워크 애플리케이션 생성

TCP는 연결지향형 서비스이고 신뢰적 바이트 스트림 채널을 제공하는데, 이 채널을 통해 데이터가 두 종단 시스템 사이를 흐르게 된다.(바이트 단위)

UDP는 비연결형이고 한 종단 시스템에서 다른 곳으로 데이터를 독립적인 패킷으로 만들어서 보내는데, 전송에 대한 보장은 하지 않는다.(패킷단위)