| 리포트 | 기술문서 | 테크-블로그 | 원샷 갤러리 | 링크드인 | 스폰서 컨텐츠 | 네트워크/통신 뉴스 | 인터넷자료실 | 자유게시판    한국 ICT 기업 총람 |

제품 검색

|

통신 방송 통계

 
 
 
섹션 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/UHD IoT SDN/NFV Wi-Fi Video Streaming KT SK Telecom LG U+ OTT Network Protocol CDN YouTube Data Center
 

2023

5G 특화망

포탈

Private 5G/이음 5G

 포탈홈

  넷매니아즈 5G 특화망 분석글 (128)   5G 특화망 4가지 구축모델   산업계 5G 응용   산업분야별 5G 특화망 활용사례  [5G 특화망 벤더Samsung | HFR | Nokia | more
 

해외

  국가별 사설5G 주파수 [국가별 구축현황] 일본 | 독일 | 미국 | 프랑스 | 영국  [사설5G 사업자] Verizon | AT&T | DT | Telefonica | AWS | Microsoft | NTT동일본 | NTT Com    
 

국내

  5G 특화망 뉴스 | 국내 5G 특화망 구축 현황 | 국내 5G 특화망사업자 현황 (19개사) | 국내 자가구축사례 일람 | 국내 특화망 실증사업사례 일람 | 5G 특화망 정책
 
 

[5G 특화망 구축 사례] 한국식품산업클러스터 | 반월시화산단 삼성서울병원 | 롯데월드 | 한국수력원자력 | 해군본부 | 한국전력공사 | more  [이통사] KT

 
 
스폰서채널 |

 HFR의 5G 특화망 솔루션 (my5G)  Updated   | HFR 5G 특화망 뉴스HFR my5G 자료

  스폰서채널 서비스란?
YouTube의 비디오 전달 방식 변경 (1): Progressive Download의 종말
YouTube switched to Chunking and Adaptive Streaming
August 13, 2013 | By 양수열, 손장우 (tech@netmanias.com)
코멘트 (10)
18

최근 들어 YouTube가 비디오 전달 방식을 지속적으로 변경/진화시키고 있다. 작년까지는 HTTP Progressive Download 방식(마치 데이타 파일을 다운로드하듯이 하나의 비디오 파일을 한 번의 요청으로 다운로드함)의 대명사가 YouTube였는 데 올해 들어 다양한 변화 (Chunk 방식으로 전환, Adaptive Streaming 적용)를 꾀하고 있다. 

 

이 블로그글에서는 그 중에서 "Chunk 방식으로 전환"에 관해 살펴보도록 한다.  

 

1. 기존의 YouTube 비디오 전달 방식

 

기존 (2013년 4월 이전)의 YouTube의 단말 유형별/해상도별 비디오 파일 요청 및 전달 방식은 아래 표와 같다.

  

 

이번 블로그 글에서는 단말이 PC인 경우를 살펴본다. 

 

기존 방식에서는 PC에서 시청할 수 있는 비디오 파일의 해상도는 1080p, 720p, 480p, 360p, 240p, 144p이며 이중에서 360p만 Chunk 단위로 비디오 파일을 요청하고 받아간다. 나머지 해상도의 파일은 한번의 요청 (HTTP GET)으로 전체 파일을 한번에 다운로드 받아 간다.

 

 

이에 대한 자세한 내용은 넷매니아즈 기술 문서 "YouTube 비디오 요청 및 전달 방식 분석 (360p, 720p)"를 참조하면 된다. 

 

2. 무엇이 어떻게 변경되었나? (Progressive Download의 종말)

 

작년까지는 각 해상도(1080p~144p)의 파일들이 모두 비디오와 오디오가 믹싱된 파일로 하나의 파일만 전달받으면 영상과 음성의 재생이 가능한 데, 올해4월부터는 비디오 파일과 오디오 파일이 분리되어 두 개의 파일을 다운로드 받아야 한다는 점이 우선 눈에 뜨인다. 

 

보다 중요한 변화는 HTTP Progressive Download 방식에서 Chunk 방식으로 변경되었다는 점이다. 여기서 Chunk는 HLS (Apple사의 HTTP Live Streaming) 방식처럼 하나의 동영상 파일을 서버에서 미리 여러 개의 조각으로 잘라 놓고 각 조각을 별도의 파일(1.ts, 2.ts, 3.ts,...)로 저장해놓는 (Real) Chunk가 아니라, 단말이 그때 그때 필요한 동영상 파일의 부분을 Range Request (range=0-4227071, range=4227072-8454143,...)를 통해 받아 오며 이 요청된 조각이 (Virtual) Chunk이다. 따라서 YouTube 서버에서 해상도당 하나의 파일만 저장하고 있으면 되므로 파일의 관리가 매우 용이하다.   

 

아래 그림은 해상도가 720p인 동영상을 시청할 때 비디오 파일의 다운로드 패턴의 변화를 보여주고 있다. 변경 전 [BEFORE]에는 한번의 요청 (HTTP GET)을 통해 88.8MB의 전체 파일을 다운로드 받는다. 실측한 그림에서는 재생시간이 4분 12초인 강남스타일 720p 파일을 40초만에 모두 다운로드 받음을 볼 수 있다. 만약 이용자가 40초쯤 보다가 나가도 전체 분량이 PC에 들어와 있는 것이고 (1) YouTube 서버는 이용자가 보지 않는 4분12초 - 40초어치의 동영상 부분을 열심히 PC로 밀어 넣어 준것이다. (2) 또한 YouTube 서버는 비디오 파일 전달시 적절한 Pacing(Throttling)을 걸어 초기 분량만 최대 속도로 전달해주고 일정 분량이 PC로 전달되고 난 후에는 전달율을 낮게 조정함을 볼 수 있다.  (1), (2) 모두 YouTube 서버의 부하로 작용한다. 

 

변경 후 [AFTER]의 컨텐츠 요청 및 전달 패턴을 보면 초기에 3~4개 정도의 Chunk를 Back-to-Back으로 요청해서 받아 수신 버퍼를 채우고 이 후 약 20초에 한 번꼴로 나머지 Chunk들을 요청하여 받아 감을 볼 수 있다. 시청 중 나가면 단말은 추가적인 Chunk 요청을 하지 않고 이로 인해 실제 시청한 분량 정도만 다운로드 받게 된다. YouTube 서버는 변경 전보다 널널해진다. Streaming (RTSP)과 비슷해진 것이다. 

 

 

 

 

YouTube 스트리밍 방식의 변화 (이용자가 해당 해상도를 선택했을 때)

 

 

 

 

왜 이렇게 바꾸었을 까?

 

기존의 파일 단위의 HTTP Progressive Download 방식은 모바일 환경뿐만 아니라 유선 PC 환경에서도 다양한 문제점들을 발생시키는 데, 위 그림에서 보듯이 4분 12초짜리 동영상을 40초만에 다운로드하므로 1분 정도 보고 나가는 이용자의 경우에도 4분 12초어치의 동영상 파일이 YouTube 서버를 통해 전달된다. 

 

이용자가 시청하지 않은 분량에 대해서도 YouTube 서버는 PC로 전달해준다. 그러나, 변경 후의 스트리밍 패턴을 보면 단말 (PC)가 이용자가 시청을 하면 지속적으로 Chunk를 요청하고 시청하지 않으면 추가적인 Chunk 요청을 하지 않는다. 따라서 YouTube 서버의 부하는 대폭 줄어들게 되며 이는 더 적은 수의 서버로도 더 많은 이용자들에게 스트리밍 서비스를 해줄 수 있게 된다. 

 

또한 통신사업자의 YouTube 무임 승차 트래픽의 폭증에 대한 불만도 어느 정도 달래줄 수 있을 것이다.   

 

요약하면 YouTube는 기존에 YouTube 서버에 있던 Intelligence를 단말에 주고 YouTube 서버는 Dummy해지게 만들어 저가의 비용으로 YouTube CDN을 확장할 수 있게 비디어 전달 로직을 전환한 것이다. 

 

 

 

 

Progressive Download의 종말.....Video Optimization (Video Pacing, etc.) 장비 존재 가치가 민망해짐....Transparent Cache 벤더별 YouTube 캐싱 히트율 변화......통신사업자망내 YouTube 트래픽 감소....

만일 Progressive Download 방식을 쓰던 다른 OTT (기존 상용 CDN이용)도 Chunk 방식으로 바꾸면, 상용 CDN 업체의 수익 감소, OTT는 CDN 이용료 절감.... 

 

이상흔 2013-08-16 23:05:43
YouTube 비디오 전달방식이 기존의 PDL(Progress DownLoad) 방식에서 Chunk 방식으로 변경되었다는 소식은 분명 Network Operator 입장에서는 매우 기쁘고 반가운 소식이 될 것입니다.

그러나, 이러한 비디오 전달방식의 변화는 Youtube 비디오와 같은 Online Video Caching 기술을 제공하는 제조사 입장에서는 결코 쉽지만은 않은 큰 도전 과제가 될 것입니다.

현재에도 상당부분 선도적인 온라인 비디오 제공 업체들이 ABR 방식의 비디오 전달방식을 주도적으로 이용하는 것을 고려하면 앞으로 "Chunk 또는 ABR 기반의 비디오 캐싱 효율"이 비디오 캐싱 제품을 구매하려는 고객 입장에서 우선적으로 고려하여야 할 부분이 될 것입니다.

앞으로 온라인 비디오 트래픽이 지속적으로 증가함으로 인해 그 어느 때 보다 인터넷 기반 비디오(Online Video) 캐싱의 중요성이 강조될 것으로 예상 되는 바, Youtube 비디오의 이러한 전달방식 변화는 비디오 캐싱에 관심을 가진 많은 이들에게 분명히 시사하는 바가 크다고 생각합니다.
최종오 2013-08-19 16:35:47
정말 좋은 자료 먼저 감사합니다.
현재 제 Notebook의 audio driver가 문제가 있어 audio가 나오지 않습니다.
기존에 잘 플레이되던 youtube가 갑자기 play 안되는 현상이 있었는데 본문을 읽어보니 audio를 처리하지 못하면 이런 문제가 발생할 수 있을 것 같군요.
제가 pcap으로 이상해서 분석해보려 보고 있습니다.

혹시 client에서 RST을 계속적으로 보내주는 부분과 TCP window size가 -2(no window scaling used) 되는 부분이 문제가 되는 것일까요?

2668 2013-08-16 13:55:46.338161 10.174.27.40 173.194.51.18 TCP 54 netop-school > http [RST] Seq=3276 Win=0 Len=0

비슷한 RST이 Seq가 동일하게 계속적으로 보내지는 것이 보입니다.

저같이 audio 디바이스가 문제가 있는 케이스일 경우는 위와 같은 구조로 바뀌었을 때 영향을 주는 케이스 같아 글 남깁니다.

언제나 좋은 내용 감사합니다.~~
박근백 2013-08-22 12:43:55
자료 감사합니다!
상반기에 유튜브 비주류영상부터 전달방식 변경을 확인했었고요. 6월경에는 젠틀맨까지 바뀌었었는데요.
브라우져에 따라 기존방식 사용하던게 있었는데, 크롬까지 변경이 다 되었네요.
Dash 적용되면서 유튜브도 adaptive streaming을 준비하나보나 했는데,,,다음편이 기대가 큽니다.
그리고 저의 경우 근래들어 유튜브 재생중 멈추는 현상이 자주 발생하는데요...이게 전송방식 변경과
관련이 있지 않을까 막연히 추측하고 있는데요. 혹시 유사한 경험 있으신 분이 계신가요?
매번 좋은 자료 고맙습니다^^
감사드 2013-09-03 06:30:52
자세하고 실제적인 비교 평가 자료에 감사 드립니다.
향후 거의 모든 Video over IP 서비스가 Chunk(Segment) 방식의 ABR 를 이용한 CDN 서비스 방식으로 변할 예정입니다.
이는 기존의 모든 VOD 서비스와 심지어 Broadcasting 서비스까지 이방식으로 바뀌어 나갈 예정입니다.
 2013-10-28 19:24:31
이거 (2)편은 언제 나오는지 궁금합니다!!

항상 감사드립니다^^
넷매니아즈 2013-10-30 15:09:26
10월 30일자 블로그,
모바일 단말에서 YouTube Live TV 스트리밍 방식 분석 - HLS & Adaptive
(https://www.netmanias.com/bbs/view.php?id=blog&no=397)
를 참고하세요.
이희규 2013-10-31 15:38:55
좋은 내용 감사드립니다.
그런데 예전에 통신사업자들이 서버?를 구축해서 실제 데이터는 유튜브가 아니라 국내 통신사업자가 구축해 놓은 서버에서 데이터를 가져온다고 본것 같거든요
그럼 이런 경우도 전달 방신이 변경되는 건가요?
제가 잘 몰라서 제대로 질문한건지 모르겠네요 ^^;;
넷매니아즈 2013-10-31 17:10:47
Google의 데이터센터가 국내에는 없습니다.

2012년초까지는 KT, SK, LG U+의 모든 가입자 단말들은 홍콩이나 미국에 있는 Google 데이터센터내의 YouTube 서버에서 비디오 파일을 다운로드 받았고요.

그래서 이때는 버퍼링이 많이 발생했습니다.

2012년 2월에 국내에 LG U+, SK, KINX에 Google Global Cache (GGC)가 도입되어 졌고

이 때부터 YouTube 재생에 버퍼링이 거의 없어졌습니다.

다만 KT는 아직도 Google Global Cache를 도입하지 않고 있어 여전히 버퍼링이 많이 발생합니다.

Google Global Cache는 YouTube 캐시 서버라고 보시면 됩니다. 통신 사업자 꺼가 아니고 Google이 무상으로 제공해주는 서버입니다.

국내 통신 사업자의 데이터센터 (IDC)에 Google 서버가 들어 왔지만 국내 통신 사업자가 건들일 수 없습니다.

그냥 Google 서버입니다.

운영, 소프트웨어 업그레이드...모두 Google이 하며 통신사업자는 IDC내 상면, 전원, 네트워크 연결만 해줍니다.

전달 방식의 변경도 Google이 하는 것이고요, 국내에 Google 서버가 있든 없는 국내 사업자하고는 아무 관계가 없습니다.
박근백 2013-12-06 21:09:06
안녕하세요. 질문이 있는데요
좀전에 유튜브앱에서 나인스 뮤비 글루 720p 패킷을 잡아봤는데요. 전체 다운로드 하네요. (wifi)
720p도 파일에 따라 전체인 것도 있고, 부분인것도 있는지요?
감사합니다.
차세환 2014-03-31 15:10:32
언제나 좋은 글 감사합니다!
Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
View All (1195)
5G (127) 5G 특화망 (40) AI (16) ALTO (1) AR (2) ARP (6) AT&T (1) Akamai (5) Authentication (5) BT (1) Backhaul (2) Big Data (2) Bridging (5) C-RAN/Fronthaul (19) CDN (20) CIoT (2) CPRI (6) Carrier Aggregation (5) Charging (2) China Mobile (2) Cisco (6) CoMP (3) Comcast (1) DHCP (6) DNS (15) Data Center (15) EDGE (14) EMM (1) EPS Bearer (7) Ethernet (3) FTTH (8) GSLB (5) Gigabit Internet (17) Google (17) Google Global Cache (8) Google TV (1) HLS (5) HTTP (5) HTTP Adaptive Streaming (7) HTTP Progressive Download (2) Handover (5) Huawei (1) IGMP (3) IP (6) IP Allocation (8) IP Routing (20) IPSec (4) IPTV (25) IoST (2) IoT (63) KT (46) Korea (8) Korea ICT Vendor (1) L3 Switch (5) LG U+ (24) LTE (99) LTE-A (10) LTE-A Pro (1) LTE-M (1) LTE-U (3) LoRa (5) MEC (15) MPLS (3) MWC 2013 (1) MWC 2015 (3) MWC 2016 (2) MWC 2017 (1) Mobile IPTV (1) Multi-Screen (1) Multicast (2) NAT (9) NB-IoT (6) NTT Docomo (1) Netflix (5) Network Protocol (49) Network Slicing (3) O-RAN (2) OSPF (3) OTT (20) Operator CDN (1) P2P (3) PS-LTE (3) Pooq (2) Private 5G (51) QoS (5) RCS (1) RRH (1) Request Routing (3) SD-WAN (8) SDN/NFV (42) SK Broadband (1) SK Telecom (38) Samsung (2) Security (8) Self-Driving (3) Shortest Path Tree (2) Small Cell (3) Spectrum Sharing (1) TAU (2) Transparent Caching (9) UHD (7) VLAN (2) VPN (3) VR (3) Video Streaming (22) VoLTE (1) VoWiFi (1) WAN Optimization (1) Wi-Fi (30) WiBro(WiMAX) (2) YouTube (16) eICIC (1) eMBMS (1) ePDG (6) u+ tv G (4) 로컬 5G (3) 이음 5G (21)

 

 

     
         
     

 

     
     

넷매니아즈 회원 가입 하기

2023년 6월 현재 넷매니아즈 회원은 55,000+분입니다.

 

넷매니아즈 회원 가입을 하시면,

► 넷매니아즈 신규 컨텐츠 발행 소식 등의 정보를

   이메일 뉴스레터로 발송해드립니다.

► 넷매니아즈의 모든 컨텐츠를 pdf 파일로 다운로드

   받으실 수 있습니다. 

     
     

 

     
         
     

 

 

비밀번호 확인
코멘트 작성시 등록하신 비밀번호를 입력하여주세요.
비밀번호