{"componentChunkName":"component---src-templates-blog-post-js","path":"/Computer-Network/2020-10-12-네트워크-비디오스트리밍-CDN/","result":{"data":{"site":{"siteMetadata":{"title":"Hun's Footsteps 🥷","author":"전여훈","siteUrl":"https://jeonyeohun.netlify.app","comment":{"disqusShortName":"","utterances":"jeonyeohun/jeonyeohun.github.io"},"sponsor":{"buyMeACoffeeId":"jeonyeohun"}}},"markdownRemark":{"id":"e2c75fe1-dbe3-5595-9257-a887f5780006","excerpt":"참고도서: 컴퓨터 네트워킹 : 하향식 접근. 7판. James F. Kurose , Keith W.Ross 지음 인터넷 비디오 비디오 데이터는 결국 여러장의 이미지를 가지고 있는 데이터이다. 일반적으로는 초당 24~2…","html":"<p><em><strong>참고도서: 컴퓨터 네트워킹 : 하향식 접근. 7판. James F. Kurose , Keith W.Ross 지음</strong></em></p>\n<h2 id=\"인터넷-비디오\" style=\"position:relative;\"><a href=\"#%EC%9D%B8%ED%84%B0%EB%84%B7-%EB%B9%84%EB%94%94%EC%98%A4\" aria-label=\"인터넷 비디오 permalink\" class=\"anchor before\"><svg aria-hidden=\"true\" focusable=\"false\" height=\"16\" version=\"1.1\" viewBox=\"0 0 16 16\" width=\"16\"><path fill-rule=\"evenodd\" d=\"M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z\"></path></svg></a>인터넷 비디오</h2>\n<ul>\n<li>비디오 데이터는 결국 여러장의 이미지를 가지고 있는 데이터이다. 일반적으로는 초당 24~25장의 프레임(이미지)를 가지고 있다.</li>\n<li>이런 비디오는 용량이 크기 때문에 여러 방법으로 이미지들을 압축해서 비디오의 용량을 줄이는 인코딩이 존재한다. 일반적으로 비슷한 지역의 픽셀들이 다시 등장하는 <code class=\"language-text\">spatial</code> 한 특성과 현 프레임에서 다음 프레임으로 갈 때 비슷한 색의 값을 가진 픽셀이 다시 사용되는 <code class=\"language-text\">temporal</code> 한 특성을 사용해서 비디오를 인코딩한다.</li>\n<li>비디오를 인코딩하는 방식을 고정적으로 사용하는 것을 <code class=\"language-text\">CBR(Constant Bit Rate)</code> 라고 하고, <code class=\"language-text\">spatial</code>, <code class=\"language-text\">temporal</code> 한 정보를 이용해서 상황에 맞게 인코딩하는 방식을 <code class=\"language-text\">VBR(Variable Bit Rate)</code> 라고 한다.</li>\n</ul>\n<h2 id=\"http-스트리밍\" style=\"position:relative;\"><a href=\"#http-%EC%8A%A4%ED%8A%B8%EB%A6%AC%EB%B0%8D\" aria-label=\"http 스트리밍 permalink\" class=\"anchor before\"><svg aria-hidden=\"true\" focusable=\"false\" height=\"16\" version=\"1.1\" viewBox=\"0 0 16 16\" width=\"16\"><path fill-rule=\"evenodd\" d=\"M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z\"></path></svg></a>HTTP 스트리밍</h2>\n<ul>\n<li>전통적인 스트리밍 서비스는 <code class=\"language-text\">RTSP(Real-Time Streaming Protocol)</code>으로 실시간으로 데이터를 서버에서 받아와 사용자에게 바로바로 보내주는 형태였다. 그러나 이런 방식은 한 서버에 여러 사용자가 몰리게 되는 문제가 있고 사용자도 서버에 부하가 걸리면서 영상을 제대로 시청하지 못하게되는 현상이 발생했다.</li>\n<li>그래서 최근에는 HTTP 방식으로 비디오 데이터를 송수신하는 방법이 고안되었다.</li>\n<li>HTTP 방식은 일반적으로 사용자가 비디오를 요청하면 사용자는 서버와 <code class=\"language-text\">TCP 연결</code>을 설정하고 비디오 데이터를 받기 시작한다.</li>\n<li>클라이언트는 어플리케이션 버퍼에 전달된 데이터의 바이트들을 저장하고 일정 바이트 이상 데이터가 모이면 화면을 재생하기 시작한다.</li>\n<li>초기에는 TCP로 연결했을 때, 클리이언트의 한 번의 요청으로 전체 파일을 다운로드 하는 방법으로 구현되었으나 이런 방식은 사용자가 비디오를 다 시청하지 않고 종료할 경우에 TCP 연결이 끊어지게 되므로 처음부터 데이터를 다시 받아와야하는 문제가 있다.</li>\n<li>이런 문제를 해결하기 위해 고안된 <code class=\"language-text\">Progressive Downloading</code> 방법은 파일을 <code class=\"language-text\">Chunk</code> 단위로 나누어두고 사용자가 비디오를 시청하는 중에 지속적으로 이 chunk를 다운로드 하는 방식으로 구현되어 있다.</li>\n<li>여러가지 방법론이 제시됨에도 불구하고 HTTP 방식이 해결하지 못하는 문제는 모든 클라이언트들이 각각의 가용 대역폭의 차이와 상관없이 똑같이 인코딩된 파일을 제공받는 것이다.</li>\n</ul>\n<h2 id=\"dynamic-adaptive-streaming-over-httpdash\" style=\"position:relative;\"><a href=\"#dynamic-adaptive-streaming-over-httpdash\" aria-label=\"dynamic adaptive streaming over httpdash permalink\" class=\"anchor before\"><svg aria-hidden=\"true\" focusable=\"false\" height=\"16\" version=\"1.1\" viewBox=\"0 0 16 16\" width=\"16\"><path fill-rule=\"evenodd\" d=\"M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z\"></path></svg></a>Dynamic Adaptive Streaming over HTTP(DASH)</h2>\n<ul>\n<li>DASH 는 HTTP 스트리밍 방식의 문제점을 해결하기 위해 개발 되었다.</li>\n<li>DASH는 서버가 <code class=\"language-text\">한 비디오 파일이 여러 버전으로 인코딩된 파일을 준비</code>해 둔다. 클라이언트는 자신의 가용 대역폭에 맞는 인코딩 비트율을 요청하고 서버는 해당 요청에 맞는 인코딩된 비디오를 송신해주는 방법이다.</li>\n<li>이때 클라이언트는 파일을 자신의 가용 대역폭에 맞게 <code class=\"language-text\">chunk 단위로 요청</code>하므로 대역폭 상황에 맞게 동적으로 비디오의 비트율을 결정할 수 있다는 장점이 있다.</li>\n<li>서버에는 여러 비트율로 인코딩된 파일이 존재하기 떄문에 이 비트율에 따른 각 비디오 버전의 URL 정보를 보관하고 있어야 할 필요가 있다. 이 맵핑정보를 가진 파일이 <code class=\"language-text\">매니패스트(manifest) 파일</code>이다.</li>\n<li>클라이언트는 <code class=\"language-text\">먼저 서버에 매니페스트 파일을 요청</code>하고 받은 뒤에 자신이 원하는 버전의 비디오를 선택해서 HTTP GET 요청을 서버로 보내게 된다.</li>\n<li>따라서 DASH는 클라이언트에게 많은 결정을 맡기게 되는 방식이다.</li>\n</ul>\n<h2 id=\"content-distribution-networkscdns\" style=\"position:relative;\"><a href=\"#content-distribution-networkscdns\" aria-label=\"content distribution networkscdns permalink\" class=\"anchor before\"><svg aria-hidden=\"true\" focusable=\"false\" height=\"16\" version=\"1.1\" viewBox=\"0 0 16 16\" width=\"16\"><path fill-rule=\"evenodd\" d=\"M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z\"></path></svg></a>Content Distribution Networks(CDNs)</h2>\n<ul>\n<li>스트리밍 서비스를 운영하는 가장 쉬운 방법은 하나의 데이터 센터를 만들어서 모든 비디오를 보관한 뒤에 사용자에게 데이터를 보내주는 방식이다.</li>\n<li>\n<p>그러나 오늘날에는 수 많은 사용자가 비디오 데이터를 요청하면서 몇 가지 문제점들이 발생하게 된다.</p>\n<ul>\n<li>클라이언트가 데이터 센터로부터 물리적으로 먼 위치에 있는 경우에는 많은 수의 링크와 라우터를 거치게 되는데 이 때 하나의 링크라도 낮은 전송용량을 가지면 사용자가 비디오를 시청하기 어려운 환경이 된다.</li>\n<li>사용자가 직접 데이터센터로 데이터를 요청하기 때문에 인기있는 비디오의 경우에는 데이터센터가 동일한 데이터를 계속해서 전송하게 된다.</li>\n<li>데이터 센터에 장애가 생기면 모든 사용자가 비디오에 접근할 수 없게 된다.</li>\n</ul>\n</li>\n<li>CDN은 <code class=\"language-text\">다수의 위치에 분산된 서버들을 운영</code>하고 데이터들의 복사본을 분산된 서버에 저장해둔다.</li>\n<li>\n<p>CDN은 두 가지 운영철학 중 하나를 선택해서 운영하게 된다.</p>\n<ul>\n<li><code class=\"language-text\">Enter Deep</code> : 서버 클러스터를 전세계 곳곳의 access network 안에 구축해서 서버를 최대한 사용자에 가까이에 위치시키려는 방법이다. 하지만 분산된 서버의 설계로 인해 유지관리 비용이 크게 발생한다는 단점이 있다.</li>\n<li><code class=\"language-text\">Bring Home</code> : 서버 클러스터를 access network 주변에 구축해서 유지 및 관리가 용이하면서도 비용을 줄이는 방법이다. 그러나 Enter Deep 방식만큼 사용자에게 빠른 전송률을 제공하지는 않는다.</li>\n</ul>\n</li>\n<li>CDN에는 모든 데이터의 복사본이 있을 필요는 없다. 어떤 비디오는 특정 지역에서만 인기가 있고 다른 지역에서는 잘 요청받지 않는 비디오라면, 인기가 없는 지역의 CDN에는 해당 비디오가 필요가 없다.</li>\n</ul>\n<h3 id=\"cdn-동작원리\" style=\"position:relative;\"><a href=\"#cdn-%EB%8F%99%EC%9E%91%EC%9B%90%EB%A6%AC\" aria-label=\"cdn 동작원리 permalink\" class=\"anchor before\"><svg aria-hidden=\"true\" focusable=\"false\" height=\"16\" version=\"1.1\" viewBox=\"0 0 16 16\" width=\"16\"><path fill-rule=\"evenodd\" d=\"M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z\"></path></svg></a>CDN 동작원리</h3>\n<ul>\n<li>\n<p>CDN은 다음과 같은 과정을 통해 비디오를 요청하고 송수신한다.</p>\n<ul>\n<li>사용자 호스트가 웹 브라우저에서 URL을 입력하여 비디오의 재생을 요청한다.</li>\n<li>CDN은 해당 요청을 가로챈다.</li>\n<li>CDN은 지금 시점에서 클라이언트에게 가장 잘 맞는 CDN 클러스터를 선택하고 클라이언트의 요청을 해당 클러스터의 서버로 연결시킨다.</li>\n</ul>\n</li>\n</ul>\n<h3 id=\"ottover-the-top-challenges\" style=\"position:relative;\"><a href=\"#ottover-the-top-challenges\" aria-label=\"ottover the top challenges permalink\" class=\"anchor before\"><svg aria-hidden=\"true\" focusable=\"false\" height=\"16\" version=\"1.1\" viewBox=\"0 0 16 16\" width=\"16\"><path fill-rule=\"evenodd\" d=\"M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z\"></path></svg></a>OTT(Over The Top) Challenges</h3>\n<ul>\n<li>OTT는 주로 스트리밍 데이터를 요청한 클라이언트에 직접적으로 제공하는 컨텐츠 제공 사업자를 의미한다.</li>\n<li>CDN에서 가장 중요한 부분은 OTT가 어떤 서버 클러스터에 데이터를 요청할 것인지에 대한 부분이다.</li>\n<li>\n<p>가장 단순하고 확실한 방법은 클라이언트와 <code class=\"language-text\">물리적으로 가장 가까이에 있는 클러스터</code>를 할당하는 것이다.</p>\n<ul>\n<li>하지만 일부 클라이언트에서는 자신의 로컬 DNS서버를 자신과 멀리 떨어진 DNS서버로 지정할 수도 있고, 지리적으로 가까운 DNS서버가 네트워크 hop 상에서도 가장 가깝다는 보장이 없다.</li>\n</ul>\n</li>\n</ul>\n<h3 id=\"cdn-content-access\" style=\"position:relative;\"><a href=\"#cdn-content-access\" aria-label=\"cdn content access permalink\" class=\"anchor before\"><svg aria-hidden=\"true\" focusable=\"false\" height=\"16\" version=\"1.1\" viewBox=\"0 0 16 16\" width=\"16\"><path fill-rule=\"evenodd\" d=\"M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z\"></path></svg></a>CDN Content Access</h3>\n<ul>\n<li>\n<p><code class=\"language-text\">Netflix</code> 는 기본적으로 CDN을 사용하지만 동시에 manifest 파일을 사용하는 구조로 작동한다. Netflix는 다음과 같은 과정을 거쳐 비디오를 송수신한다.</p>\n<ul>\n<li>넷플릭스의 사용자가 넷플릭스의 아마존 클라우드에 비디오에 대하 요청을 보낸다.</li>\n<li>넷플리스의 아마존 클라우드는 manifest 파일을 응답으로 보내준다.</li>\n<li>넷플릭스는 여러개의 CDN 서버에 비디오에 대한 사본을 저장해두고 manifest 파일에는 이 주소가 저장되어있다.</li>\n<li>클라이언트는 manifest 파일에서 얻은 CDN 서버로 접근해서 데이터를 가져와 사용자에게 스트리밍해준다.</li>\n<li>넷플릭스는 <code class=\"language-text\">DNS redirection</code> 을 사용하지 않고, 국가마다 사용자들이 선호하는 데이터들의 사본을 우선적으로 저장하는 <code class=\"language-text\">push caching</code> 정책을 사용한다.</li>\n</ul>\n</li>\n<li>\n<p><code class=\"language-text\">Youtube</code> 는 private CDN을 사용해서 사용자에게 비디오를 스트리밍한다.</p>\n<ul>\n<li>유투브는 <code class=\"language-text\">DNS redirection</code> 과 <code class=\"language-text\">pull caching</code> 정책을 사용한다.</li>\n<li>유투브는 load balancing 을 위해서 <code class=\"language-text\">RTT가 가장 짧은</code> 클러스터 서버를 선택하는 정책을 사용한다.</li>\n</ul>\n</li>\n<li><code class=\"language-text\">Kankan</code> 은 p2p를 기반으로 하지만 p2p의 네트워크가 사용자를 모두 감당하기 어려우면 CDN을 함께 사용하는 정책을 사용한다.</li>\n</ul>","frontmatter":{"title":"[네트워크] 비디오 스트리밍과 컨텐츠 분배 네트워크","date":"October 12, 2020"}}},"pageContext":{"slug":"/Computer-Network/2020-10-12-네트워크-비디오스트리밍-CDN/","previous":{"fields":{"slug":"/Computer-Network/2020-10-01-네트워크-DNS/"},"frontmatter":{"title":"[네트워크] DNS","category":"Computer-Network","draft":false}},"next":{"fields":{"slug":"/Computer-Network/2020-10-13-네트워크-신뢰성 있는 데이터 전송/"},"frontmatter":{"title":"[네트워크] 신뢰성 있는 데이터 전송의 원리","category":"Computer-Network","draft":false}}}},"staticQueryHashes":["2486386679","3128451518"]}