저의 velog에 작성된 글은 모두 저의 주관적인 생각 및 이해를 바탕으로 작성된 글이므로
정확하지 않은 내용을 있을 수 있음을 알립니다.
[교재] Computer Networking : A Top-Down Approach 8th
오늘은 오늘날 흔히 사용하는 Youtube, Netflix가 어떻게 작동하는지 알아보겠습니다.
Video streaming은 2가지의 main challenge가 있습니다.
이질성 문제는 각기 다른 장소와 다른 네트워크 환경에 있는 client에게 어떻게 하면 각각의 환경에 맞춰 서비스를 제공할 것인가에 대한 문제이고, 확장성에 대한 문제는 사람들의 수요가 늘면서 그게 맞는 공급을 해야하는데, 어떻게 하면 많은 사람들을 수용할 수 있을 것인가에 대한 문제입니다.
Video는 image의 constant rate displayed 입니다. 일정한 속도로 image를 보여주는 것이 바로 영상이죠. 여기에서의 image는 digital image를 말하는데, digital image는 bit, 즉 pixel로 구성되어 있습니다.
영상은 텍스트나 이미지에 비해 엄청나게 많은 데이터를 가지고 있는 만큼, 최대한 효율적인 structure가 필요합니다. 이를 위해 encoding 과정을 거칩니다.
encoding은 2가지의 과정을 거칩니다.
Spatial은 같은 색을 가진 여러 pixel이 있을 때 각각 값을 주지 않고, 그 색상에 대한 값과 몇 번 반복하면 되는지에 대한 정보를 주는 것입니다. 우리가 코드를 짤 때 반복되는 현상에 대해서 각각 coding 하는 것이 아니라, for, while을 이용해 반복문을 사용하는 것과 같습니다.
Temporal은 i+1 번째의 frame을 보여줄 때 i번 째 frame에서 값을 all change 하는 것이 아니라 달라진 부분만 값을 주는 것입니다.
그런데 한 가지의 문제가 있습니다. 어떤 영상은 frame이 나올 때마다 큰 변화없이 단조롭게 흘러가는 영상이 있는 반면에, 어떤 영상은 굉장히 dynamic한 영상이 있을 수 있습니다. 이렇게 되면 dynamic한 영상은 encoding 하는 것이 굉장히 힘든 일일 것 입니다.
따라서 encoding 방식을 두 가지로 나눕니다.
CBR은 계속 같은 bit rate로 encoding 하기 때문에 dynamic 한 영상에서는 무리가 갈 수 있습니다. 반면에 VBR은 위에서 살펴본 spatial, temporal의 양에 따라 다른 bit rate를 사용하기 때문에 무리 없이 encoding 할 수 있습니다.
Heterogeneity(이질성) 문제는 각기 다른 장소와 다른 네트워크 환경에 있는 client에게 어떻게 하면 각각의 환경에 맞춰 서비스를 제공할 것인가에 대한 문제라고 말씀드렸습니다.
또한 같은 환경에 있더라도 network congestion에 따라 bandwidth가 계속 바뀌게 되고 이로 인해 packet loss, delay가 생기면서 영상의 quality 안좋아 질 수 있습니다.
위의 사진은 이상적인 video streaming을 보여줍니다. network에서 보내는대로 일정하게 video streaming이 이뤄지는 것을 볼 수 있죠.
하지만 실상은 이렇습니다. 보내준 대로 바로 streaming 하지 못하고, 제각기 다른 속도로 streaming 합니다. 이 문제를 해결하기 위한 방법은 buffer를 사용하는 것입니다.
frame이 빨리 들어올 때 buffer에 두고 있다가, 늦게 들어올 때는 buffer에 들어와 있는 frame을 보여주면서 비교적 일정한 streaming이 가능해집니다.
Heterogeneity를 해결하기 위한 방법이 하나 더 있습니다. DASH라는 방식인데요. 쉽게 생각해서 Youtube에서 각 user들의 네트워크 상태를 체크해서 화질을 다르게 제공하는 것이라고 생각하시면 됩니다.
동작 방식은 이렇습니다. server는 영상을 여러 개의 chunks로 쪼개서 각각의 다른 rate로 encoding하고 이 결과를 URL에 저장합니다. 여기서 URL에 넣을 수 있는 이유는 DASH는 HTTP를 사용하기 때문입니다.
이렇게 URL이 들어간 file을 manifest file이라고 하는데 user는 이 manifest file을 보고 선택하여 streaming 함으로써 문제를 해결할 수 있습니다.
DASH에서는 user가 chunk를 request 하면 가까운 server와 연결해주거나 더 높은 bandwidth를 가진 server를 연결해주기도 합니다.
이렇게 해서 Streaming Video는 encoding, DASH, buffer를 통해서 잘 작동할 수 있게 됩니다.
확장성에 대한 문제는 사람들의 수요가 늘면서 그게 맞는 공급을 해야하는데, 어떻게 하면 많은 사람들을 수용할 수 있을 것인가에 대한 문제라고 말씀드렸습니다.
엄청나게 많은 user를 수용할 수 있는 단일 server의 경우 해당 server에 문제가 생기면 엄청난 피해를 유발하므로 적절한 해결책이 될 수 없습니다.
이 문제는 CDN를 이용하여 해결할 수 있습니다. CDN은 Content Distribution Networks의 약자로 server를 여러 곳에 두는 방식입니다.
CDN은 server를 어디에 두느냐에 따라 두 가지 방식으로 나뉩니다.
enter deep 방식은 server를 user에 가깝게 두는 방식입니다. 이 방식은 매우 빠르지만 user에 가깝게 두는 만큼 많은 server가 필요하므로 큰 비용을 요구합니다.
bring home 방식은 root server와 가까운 위치에 server를 두는 방식입니다. enter deep 방식보다는 server를 덜 두는 만큼 속도가 느리지만, 비교적 비용이 적게 듭니다.
MADMEN 이라는 video를 streaming 한다고 가정해봅시다. 각 node에는 이미 video의 복사본이 저장되어 있습니다. user가 video를 요청하면 manifest file에서는 해당 video가 있는 URL을 찾아 보내줍니다. 그러면 user와 가까운 위치에 있는 server가 그 URL을 받아 영상을 streaming합니다. 여기에서 해당 server의 네트워크 상태가 좋지 않으면 다른 server로 교체합니다.
다음은 Bob이 CDN server로부터 video를 streaming하는 과정입니다.
Bob이 webpage에서 video에 대한 URL을 요청합니다.(video를 클릭합니다.)
webpage에서 받은 URL을 찾기 위해서 Bob의 local DNS server에 전달합니다.
Bob의 local DNS server는 URL을 찾기 위해 netcinema's authoratative DNS에 물어봅니다. 이때 KingCDN authoritative DNS가 알고 있으니 거기 가서 물어보라는 답변을 합니다.
Bob의 local DNS server는 KingCDN authoritative DNS로 가서 물어보고 얻은 답변을 Bob에게 보내면 Bob은 진짜 그 video를 가지고 있던 KingCDN으로부터 영상을 streaming 할 수 있게 됩니다.
마지막으로 DASH를 이용한 Netflix 예제를 보도록 하겠습니다.
그림에 보이는 것 처럼 Bob은 Netflix로부터 영상을 보려고 합니다. CDN server는 Amazon cloud server를 root server로 하는 sub server입니다.
Bob이 netflix에서 영상을 보려면 우선 회원가입/로그인을 해야겠죠. 권한을 얻은 Bob는 video를 켭니다. 그럼 이때 amazon cloud로 video를 요청하게 되고, 각 영상에 대해 다양한 bit rate로 encoding 된 URL을 받게 됩니다. 그럼 Bob는 이 URL을 가지고 가까운 CDN server로 요청하여 영상을 볼 수 있게 되는 것이죠.
오늘은 video streaming과 CDN에 대해 알아봤는데요. 양이 좀 많네요.. 공부를 하다보면 사람은 정말 똑똑한 동물이구나를 절실히 깨닫게 됩니다. Netflix나 Youtube 영상 하나 보는데 이렇게 복잡한 것도 첨 알았네요..다음 시간에는 Application layer의 마지막 부분인 UDP와 TCP를 이용한 socket programming을 알아보도록 하겠습니다. 오늘도 수고 많으셨습니다 :)