일반으로 클라이언트가 서버로부터 동영상 파일을 받는다고 가정했을 경우, 제일 처음 시점에 높은 Bandwitdh를 차지하면서 파일 전송이 이루어 지고 전송이 완료되고 나면 더이상 네트워크상으로 전송은 없는 것이 보통이죠.




그런데 Youtube에서의 동영상 스트리밍 방식은 조금 다릅니다. 아래 그림은 Youbue에서 4분 약간 넘은 동영상을 스트리밍을 받았을 때의 IOGraph입니다.


youtube_io_graph.png




서버가 while문 돌면서 send를 호출하게 되면(FTP 방식) 위와 같은 그래프 패턴이 나오지가 않고, TCP 스택에서 양 Peer간의 Bandwidth가 자동으로 협상이 되면서 일반적으로 고른 분포로 전송이 이루어 지게 되죠(중간에 Packet Loss가 나게 된다면 잠시동안은 전송량이 떨어 질 수는 있음). Youtube 스트리밍에서는 어떻게 해서 위와 같은 그래프(중간에 틱틱 튀는)가 나올 수 있을까 고민을 해 봤습니다.




다음과 같은 결론을 내리게 되었습니다.


  • Youtube 사이트에서 1시간짜리 동영상을 본다고 가정.
  • 스트리밍은 몇분 안에 다 완료.
  • 그런데 사용자는 앞부분 5분 정도만 보다가 브라우저를 닫았음.
  • 그러면 나머지 55분 스트리밍 받은 것은 허사가 되어 버림.
  • 이렇게 되면 네트워크 자원 낭비가 됨.
  • 따라서, 사용자가 보게 되는 부분만 찔끔찔끔 보내어서 네트워크 낭비을 줄이고자 함.
  • 서버에서 요로콤 해야 함.




그냥 '이럴 것이다'라고 추정하는 것입니다. 이러한 방식을 칭하는 정식 용어가 있는지는 잘 모르겠습니다.



You would..