YouTube on TV: TV에서 YouTube 동영상 시청

u+ tv G 서비스를 이용하여 YouTube 동영상을 시청할 수 있는 방법은 아래 그림과 같이 2가지입니다.

    ① STB에 설치된 YouTube App을 이용하여 동영상 시청

    ② 크롬 브라우저로 YouTube 사이트에 접속하여 동영상 시청

 

오늘은 이 2가지에 방법으로 동영상 시청시에 YouTube 비디오 전달 특성에 대해 설명 드리도록 하겠습니다.

 

 

 

1. YouTube App으로 동영상 시청

 

■ YouTube App 전달 로직

STB App 화면에서 "PSY 강남 스타일"을 선택하면 STB에서 HTTP GET 메시지가 YouTube 다운로드 서버(LG U+ IDC에 위치한 GGC: Google Global Cache)로 전달되고 그 응답으로 HTTP 200 OK 메시지 후에 93MB 크기의 동영상 파일이 다운로드 됩니다.

일반 브라우저에서 YouTube 동영상 재생시 360p, 720p, 1080p 등을 선택할 수 있으나 App에서는 화질 변경 메뉴가 존재하지 않고 아래 그림과 같이 항상 720p(itag = 22 in Requested URI)를 요청하게 됩니다.

 

 

■ YouTube App 전달 특성

재생 시간이 253초인 동영상 파일을 다운로드 하는데 걸린 시간은 214초입니다. 초기 약 8초동안 최대 42Mbps 대역폭으로 빨리 동영상 파일을 전달해 주어 STB 재생 버퍼에 일정량의 데이터가 저장될 수 있도록 하고, 이후 대역폭을 확 낮추어 대략 인코딩율(3Mbps) 정도로 지속적으로 다운로드 해줍니다. 따라서 동영상 재생 시 화면 하단에 붉은색 바(현재 다운로드 진행율을 보여 주는)가 빠르게 진행되지 않고 재생시간 보다 조금 앞서 점진적으로 움직입니다.

 

이 전달 특성은 PC 웹브라우저로 다운로드 받을때와 좀 다른 결과입니다. PC 웹브라우저의 경우 다운로드 시작 시점부터 현재 가용 대역폭으로 동영상 파일 끝까지 한번에 다운로드 시켜 주는 반면, YouTube App의 경우 YouTube 다운로드 서버에서 동영상 전달 시에 throttling을 하고 있다(대역폭을 조절해서 보내고 있다)는 느낌이 듭니다.

 

 

 

 

 

2. Web(크롬 브라우저)으로 YouTube 사이트에 접속하여 동영상 시청 

 

■ YouTube Web 전달 로직

STB에 설치된 크롬 브라우저에서 YouTube 사이트(www.youtube.com)에 접속하여 위와 동일한 동영상 파일(720p)를 선택하여 재생하였습니다. 전달 로직은 YouTube App과 유사합니다. 

 

■ YouTube Web 전달 특성

동영상 다운로드 소요 시간은 215초로 YouTube App과 거의 동일합니다.

다만 주의깊에 봐야 할 부분(YouTube App과 다른 부분)은 동영상 다운로드 그래프(아래 그림에 파란색)가 지속적으로 바닥(0 bps)을 쳤다 올라옵니다. 즉, 다운로드하다 말다를 반복하고 있음을 볼 수 있습니다. 왜 그럴까요?

 

 

QoS는 YouTube App과 동일하게 Best Effort(No QoS)입니다. YouTube 다운로드 서버의 IP 주소 역시 LG U+ 대역이며 RTT도 2ms로 LG U+ IDC에 있는 GGC를 통해 다운로드 받고 있음을 알 수 있습니다. 

 

 

자. 그럼 왜 STB Web으로 YouTube 동영상 재생시 다운로드 그래프가 자꾸 바닥을 찍었다 올라오는지 그 원인을 분석을 해보도록 하겠습니다.

이와 같은 현상을 유발시킨 주범은 단말 즉, STB(YouTube Web)입니다.

아래 그림에 붉은색 화살표 표시에서 다운로드를 잠시 중지하게 되는데, 그 때의 Wireshark 패킷을 확인 해 본 결과 STB에서 TCP Window Size를 0byte로 해서(TCP Zero Winow) YouTube 다운로드 서버로 보내고(②), 이를 수신한 YouTube 서버는 다운로드를 중단합니다. 그리고 얼마 후(1.6초 후) STB에서 다시 TCP Window Size를 일정 크기로 해서(29Kbyte) YouTube 서버로 보내 (③) 다시 다운로드를 재개합니다(④).

 

그럼 왜 STB Web은 TCP Zero Window 패킷을 보낼까요?

그건 STB Web이 사용하는 수신 버퍼가 full이 되서(꽉 차서) 더 이상 데이터를 수신 할 수 없었기 때문으로 추측됩니다. 즉, 수신 버퍼에 저장되어 있는 영상을 재생하는 시간 보다 다운로드 속도가 더 빨라 수신 버퍼가 점점 차 올라가다 결국 full이 난 것이죠. (Wireshark으로 STB이 YouTube 서버로 보내는 TCP Window Size 변화를 관찰한 결과, 그 값이 점점 감소하다가 결국 0이 됨)

 

▶ TCP Window Size에 대해서: TCP Sender(YouTube 서버)가 TCP Receiver(STB)에게 TCP ACK 수신 없이 한번에 전송할 수 있는 데이터양(# of bytes)을 Congestion Window(cwnd)라 하며, 이 크기는 Receiver가 Sender에게 알려주는(advertise) Window Size 크기 (TCP 헤더에 포함) 보다 클 수 없습니다. 따라서 Receiver가 Window Size를 0으로 해서 Sender로 보내면 Sender는 더 이상 패킷을 Receiver에게 전송 할 수 없습니다.

 

 

 

3. PC Web으로 YouTube 사이트에 접속하여 동영상 시청 

 

혹시나 하는 마음에 PC Web에서도 시험을 해 보았습니다. 이를 위해 STB과 연결된 LG U+ 회선에 PC를 연결하고 동일 720p 파일을 다운로드 해 보았습니다. 그 결과 아래 그림과 같이 PC는 여전히 초기에 가용 대역폭을 전부 사용해서 파일 끝까지 다운로드 받는 우리가 알고 있던 방식을 사용하고 있습니다.

PC Web은 가용한 수신 버퍼 크기가 STB Web 보다 커서 빨리 다운로드 받아도 buffer full이 발생하지 않나 봅니다.

 

 

Wireshark에서 제공하는 TCP Windows Size 통계 기능(Statistics/TCP StreamGraph/Window Scaling Graph)을 이용해서 STB과 PC에서 YouTube 서버로 전달하는 TCP Window Size의 분포도를 비교해 보았습니다. 좌측의 u+ tv STB의 경우 TCP Window Size가 다운로드 시간 동안 오르락 내리락을 반복하는 반면 PC에서는 대부분이 위쪽에 분포되어 있음을 확인할 수 있었습니다.

 

 

 

4. 정리 

 

이번 시간을 통해 u+ tv G에 YouTube 서비스는 LG U+에 설치된 GGC(Google Global Cache)를 통해 동영상을 다운로드 받고, Google TV App과 Web에 대해서 YouTube 서버(GGC)가 서로 다른 다운로드 방식을 적용하고 있음을 설명드렸습니다.

 

Mobile 단말의 경우, 디바이스 타입(Phone, Pad), OS(Android, iOS), 응용 프로그램(Web, App)에 따라 또또 다른 다운로드 패턴이 관찰됩니다. 구글 형님은 무슨 생각으로 이렇게 하였을까요???