[ 네트워크 ] 9. 비디오 스트리밍

비디오 전송과 관련해서 고려해야할 점이 있다.

: 각기 다른 유저는 모두 각각의 Capabilities가 있을텐데, 어떻게 맞춰서 보내줘야 할까?

 

➡️ 해결법은 분배 방식과 Application-Level Infra에 있다.

 

 

📌 비디오

= 이미지를 특정한 속도로 연속적으로 나타낸 것 

 

+ 디지털 이미지는 픽셀의 배열이다. 그리고 각각의 픽셀은 비트로 나타난다.

 

➡️ 이미지 인코딩에 쓰이는 비트 수를 최대한 줄이기 위해

       이미지 내부 + 다음 이미지 간의 중복성을 이용한다.

 

- Spatial : 색상A N개를 보내는 대신 어떤 색상이 몇 번 반복되는지만 보낸다 (하나의 이미지 내부)

- Temporal  : 연속된 프레임에서 이전 이미지(프레임)와의 차이점만 보낸다. (다음 이미지)  

 

 

📌 보내는 방식

1. CBR (Constant Bit Rate) : 고정비트율             

: 인코딩 rate(속도)가 고정되어 있다.

 

 

 

2. VBR (Variable Bit Rate) : 가변비트율             

: 인코딩 rate가  Spatial , Temporal 에 따라 변한다.

 

 

다시 돌아가서, 주요 Challenge

➡️ Server-to-Client Bandwidth가 시간에 따라 다양할 것이다. (원인 : 네트워크, 비디오 인코딩 ... )

➡️ Bandwidth가 감당을 못하는 경우에는 Packet loss , Delay가 생길 것이고,

      이는 영상 재생에 Delay를 발생시키거나 화질이 낮아지게 할 것이다.

 

---

영상 스트리밍

 

정상적으로 작동하는 경우에는

 

1. 서버에서 비디오를 보내주고 (초당 30프레임 비디오)

2. 일정 시간 delay ( 로딩이라고 생각해도 됨 )를 거쳐 영상을 받는다.

3. 그 시간이 지나고 나서는 들어온 대로 영상을 보낸다.( 초당 30프레임)

 

➡️ 클라이언트는 영상 초반부를 재생하면서

      (현재 서버가 보내주고 있는)후반부를 받고 있다.

 

하지만 재생 속도와 받는 속도가 맞지 않는다면?

원인1) 네트워크 지연 변동(Jitter) 때문에 Client측에서 버퍼를 사용하여 Playout을 매치시킨다.

          * Jitter : 지연 시간이 일정하지 않고 계속 왔다갔다 하는 거.

 

원인2) 클라이언트가 정지,빨리감기,되감기,건너뛰기 등을 해서

원인3) 비디오 패킷 손실/재전송 문제

 

그런 문제가 생겼을 땐 아래와 같은 모양이 된다.

 

 

- 빨간선 : 일정한 속도로 파일 전송

- 검은선 : 변동적으로 데이터를 받는 버퍼

- 파란선 : 재생하는 곳

 

영상을 보냄

➡️ 네트워크에 문제가 있든 이런저런 이유로 받는 게 불안정함

➡️ 대신 어느 정도 데이터를 받을 시간을 확보한 후에 영상 재생

➡️ 재생하는 속도 > 받는 속도 

➡️ ' 재생한 데이터의 양 = 받은 데이터의 양 '이 되는 순간이 온다.

➡️ 그 구간 다음에 있는 비디오의 데이터가 쌓일 때까지 기다린다.

 

 

---

DASH

: Dynamic Adaptive Streaming over HTTP

= HTTP 를 통해 스트리밍하는데, 유도리있게 정보 받아온다는 느낌으로 이해해도 됨

 

= 비디오가 여러가지 버전으로 인코딩된다. 각 버전은 비트율과 품질 수준으로 나뉨.

   따라서, clnt는 자신의 환경에 맞는 버전을 요청한다.

 

Server

- 비디오 파일을 수십 개의 Chunks로 쪼갠다.

- Chunks를 저장하고, 각기 다른 Rate로 여러 번 인코딩한다.

 

* Manifest file : 각기 다른 비트율을 가진 버전의 URL을 제공함.

 

 

Client

- 주기적으로 Server-to-Client Bandwidth를 측정한다.

- Manifest file을 받아서, 자신의 상황에 맞는 Chunk를 요청한다.

    > 현재 Bandwidth에서 유지 가능하되, 가장 큰 rate걸 고른다.

    > 또 상황이 변하면 다시 바꿀 수 있음. 

 

따라서 Client는 

- 언제 Chunk를 요청할지.

- 어느 Rate로 요청할지

- 어디 URL에 요청할지

를 정한다.

 

 

 

---

CDNs
Content Distribution Networks

- 어떻게 수 천만명에게 Content를 동시에 나눠줄 것인가?

 

Option 1) 엄청 크고 거대한 서버 하나 구축

- '하나'라서 거기에서 Fail이나 맛이 가면 서비스 중단

- 유저 수가 늘어나면 작동 X

- 멀리 있는 유저에겐 '동시에' 라고 하기엔 힘들다. 

 

➡️ 확장성도 없고, 문제를 해결하지 못할 수도 있다.

 

 

 

Option 2) 여러 개의 (지역적으로 분산된)서버를 만들고,
                        Content를 각 서버에 배포해둔다. 

비유) 폰 들고 학교가는 거 까먹어서, 집에도 폰 두고, 학교에도 폰을 하나 사 둔다.

 

전 세계에 여러 서버를 만들고, 각 서버에 파일의 복사본을 다 저장해둔다.

Client가 요청을 하면, Client와 가장 가까운 위치에 있는 서버에서 컨텐츠를 보내준다.

 

구현 방법은 2개가 있다.

1) Enter Deep

: CDN 서버를 많은 액세스 네트워크로 밀어넣는다.

  ISP Network에 들어감 ( 하늘색 )

 

- 사용자와 가까이

- CDN Server들 사이에 Link와 Router의 수를 줄인다. ➡️ Delay + Rate 향상

 

= 클라이언트와 가까운 곳으로 수많은 서버를 둔다.

 

 

2) Bring home

: 갯수는 적지만 매우 크게 만드는 방법!

 

 

 

 

= 10개 정도의 서버를 둔다. 

 

---

 

여기 CDN에서 DSN이 작동하면서 서비스를 연결해준다.

 

📌 How CDN works

1. Bob이 비디오가 있는 페이지에서 영상을 얻기 위해 Cinema 페이지 URL을 받음

2. Local DNS 에서 영상이 있는 주소를 받는다.

3. Local DNS ➡️ Cinema DNS 책임 서버로 해당 주소를 보내고, CNAME ( 해당 컨텐츠가 있는 IP 주소) 를 반환한다. 

4. Local DNS를 이전에 받은 응답을 통해 CDN 서버의 책임 DNS에 보내고. 

5. Local DNS는 호스트에게 CDN 서버의 책임 DNS로부터 받은 IP주소를 보낸다.

6. 해당 IP주소를 통해 적절한 프로토콜을 사용하여 비디오를 받아온다.

 

---

📌 How NETFLIX works

 

1,2 : 로그인해서 영상보려고 들어간다.

 

3: 아마존 클라우드에 있는 넷플릭스 소프트웨어를 통해서

    영상 사본을 이미 CDN 서버에 뿌려 뒀고

Bob에게 해당 비디오 영상에 대한 Manifest file을 보내준다. 

 

4: Manifest 파일을 통해 가까운 CDN 서버에서 영상을 다운받는다.

 

 

 

(출처)

한동대학교 고윤민교수님 - 네트워크

 

 

(참고)

https://heo-seongil.tistory.com/118

 

https://velog.io/@tonyhan18/기초컴퓨터네트워크-08