2.6 Video streaming and content distribution networks(CDNs)
문제 상황: 서버의 storage, network. 클라마다 다른 환경.
해결법:
1. CDN(직접 네트워크 만들자)
2. application level infrastructure (똑똑한 클라가 자기 환경에 맞춰서 대응)
Streaming stored video
1. progressive
옛날 방식, 클라가 스트리밍 도중 화질 전환하면 서버에서 다시 다운로드. 가져왔는데 재생 안한 부분에 대해 bw 낭비
2. Adaptive: (DASH)
영상을 chunk로 쪼갬. 똑같은 chunk가 화질별로 여러 개 있음. → 갑자기 화질 바꿔도 서버에서 다시 가져올 필요 없음.
streaming multmedia: DASH
Dynamic, Adaptive Streaming over HTTP
server
비디오 파일을 여러개 chunk로 저장. 각 chunk는 다른 인코딩 bit rate(다른 화질)로 저장됨
manifest file:provide urls for different chunks. 이걸 주면 클라가 알아서 가져옴(어떤 경로, 어떤 rate, 언제 가져오는지..알아서)
client
measure server to client bw(e2e 딜레이)
request one chunk at a time.
maximun coding rate에 맞춰 가능한 bit rate으로 가져옴. 버퍼 상황 보고 언제 가져올지 잘 계산...똑똑한 클라!😊
CDN
option1: single, large 메가서버
single point of failure(서버 다운시 망함)
point of network congestion(서버 주위가 너무 혼잡)
long path to distant client(멀면 느려)
option2: store/serve multiple copies of videos at
지리적으로 떨어진 여러개 사이트(CDN)
- enter deep: push CND server deep into many access network. e2e 딜레이 줄어듬
- bring home: access network까지 들어가진 않고, 좀 더 윗단(IXP,POP)에. 관리는 쉽지만 딜레이 있음
→ CDN 노드에 컨텐츠 카피해둔 걸 저장. 구독자가 CDN에 컨텐츠 요청.
2.7 Socket programming with UDP and TCP
TCP는 byte stream oriented(바이트 단위로 잘 왔는지 확인)
Socket programming wiht TCP
서버는 welcome door socket를 열어놓고 wait. 클라가 접속해오면, 새 소켓을 만들어서 해당 클라에게 할당(dedicated to 특정 클라) → 서버가 multiple 클라와 소통 가능! 전용 소켓들은 볼일 끝나면 닫아도 ok!
UDP는 one time transaction. 유저는 보내고 싶은 속도로 보낼수 있다. 소켓하나가 다 처리하기 때문에 어느 클라에서 온 건지 명시해줘야 함. 대신 UDP는 멀티 태스킹에 유리!
