cyj893

저장소

컴퓨터 네트워크 - 멀티미디어 응용: Streaming Stored Video, Voice-over-IP

4 분 소요


K-MOOC에서 부산대학교 유영환 교수님의 “컴퓨터 네트워킹” 강의를 수강하며 적은 노트


Multimedia Applications

멀티미디어 데이터

  • 비디오
    • bit rate이 굉장히 높음(데이터 사이즈가 큼)
    • 압축률이 높음
      • 압축: 데이터 내에 있는 redundant한 정보를 줄여서 데이터의 양을 줄이는 것
      • 공간적 특성: 주변의 픽셀들끼리는 색이 거의 동일하므로 모아서 저장
      • 시간적 특성: 붙어 있는 프레임들끼리는 거의 비슷하므로 달라진 부분만 기록
    • 같은 비디오로 bit rate에 따라 다양한 품질 제작 가능
  • 오디오
    • 음성, 음악 등 아날로그 데이터를 디지털화
    • PCM(Pulse Code Modulation): 일정 주기마다 진폭 크기를 샘플링
      • ex) 샘플링 값을 8 bit로 표현하려면 진폭을 2^8=256 구간으로 나누어 일정 주기로 어느 구간인지 측정함
      • quantized value: 샘플링한 값
      • quantization error: 실제 아날로그 진폭 값에서 잃어버린 값, 양자화 오차
    • 초창기 공중 전화망의 경우 초 당 8000개 샘플링으로 8 bit로 표현하여 전송 용량은 총 64 Kbps
      • 각 8 bit마다 1 bit는 parity bit로 써서 실제 데이터 전달 최대 속도는 56 Kbps
    • CD 음악은 전화망보다 초당 5.5배 샘플링으로 고음질
    • 수신자는 디지털 방식으로 온 데이터를 복원, quantization error는 복원할 수 없음

멀티미디어를 서비스하는 네트워크 응용 종류

  • Streaming stored audio and video: 데이터가 서버에 다 저장되어 스트리밍으로 서비스
    • 스트리밍(streaming): 전체 파일을 다운 받지 않은 상태에서 클라이언트가 이미 받은 앞부분을 플레이 할 수 있는 서비스
    • prerecorded: 서버에 이미 다 녹화나 녹음된 것을 video-on-demand에 따라 서비스
    • interactivity: 멈춤, 다시 재생, forward, backward 가능
    • continuous playout: 레코딩 된 오리지널 타이밍에 맞춰서 각 데이터들은 똑같은 시간 간격으로 플레이 되어야 함
    • 성능 지표: average throughput
    • ex) youtube, netflix, amazon
  • Conversational voice-over-IP: 계속 실시간으로 interaction이 일어나는 서비스
    • 매우 delay-sensitive함
    • Loss-tolerant함
    • 성능 지표: low delay(150 ms)
    • ex) skype
  • Streaming live audio and video: 실시간으로 촬영해서 사용자에게 전달
    • Streaming stored audio and video와 거의 유사



Streaming Stored Video

streaming stored video

  • 클라이언트 응용이 많은 데이터를 버퍼링
    • fluctuation: End-to-end delay(소스에서 목적지까지의 시간)이 일정하지 않음
    • 따라서 클라이언트가 대량의 버퍼를 두고 안정적으로 데이터를 모은 후 서비스
    • CBR(constant bit rate): 데이터가 빠져나가는 시간
    • 초기 playout delay를 길게 주면 buffer starvation 확률이 적어 안정적인 서비스 가능
    • 그러나 사용자가 오래 기다려야 하므로 보통 5~10초 딜레이
  • UDP 사용
    • 장점
      • TCP는 congestion control이나 재전송 딜레이가 있어 대신 UDP 사용
      • loss 보다는 delay가 중요
      • slow start가 없으므로 원하는 data rate으로 전송
      • 매우 간단하여 처리 속도 빠름
    • 단점
      • UDP를 쓰더라도 bandwidth 자체는 변동적임
        • HTTP에 비해 playout delay가 짧기 때문에 숨기기 힘듦
        • 에러 복원이 없으므로 화면이 멈추거나 프레임 스킵
      • TCP와 달리 커넥션이 없음
        • TCP 커넥션은 양방향으로, 비디오 서비스를 하면서 컨트롤 서비스도 가능
        • UDP는 연결이 없으므로 별도의 컨트롤 서버를 따로 두고 매치해야 함
      • UDP는 방화벽, IDS를 통과하지 못하는 경우가 많음
        • stateful packet filter: TCP 커넥션에 대해 커넥션을 유지하는 패킷들만 수용
        • 따라서 보통 공격들은 UDP 패킷 형태
  • HTTP(TCP 기반) 사용
    • HTTP의 GET 명령어: TCP 연결 후 사용자가 GET 명령어로 해당 데이터를 가져옴
    • 에러 재전송, 혼잡 제어 등 때문에 data rate이 낮아질 수 있으므로 prefetching이 빠른 시간 전에 되어야 함
      • UDP보다 훨씬 큰 playout delay
      • 클라이언트 쪽 어플리케이션 버퍼도 더 커야 함
    • HTTP byte-range header: GET 메시지의 필드 중 하나
      • 어느 파일의 특정 range를 요청할 수 있음
      • 앞이나 뒤로 넘길 때도 해당 필드로 요청
    • 사용자가 미리 받아 놓은 데이터를 보지 않는다면 인터넷 리소스 낭비가 크게 됨
      • 따라서 버퍼를 적당히 유지
      • ex) 영상 시청 중 pause를 하면 계속 다음을 다운 받지 않고, 적정 버퍼만큼만 유지
    • 단점
      • 클라이언트가 다양하여 데이터 소비 능력이 다름
  • adaptive HTTP streaming(DASH, Dynamic Adaptive Streaming over HTTP)
    • 사용자의 인터넷 환경 또는 장치의 수준에 따라서 데이터 품질이 변할 수 있음
    • 클라이언트가 결정하는 요소
      • 원하는 비디오 품질
      • 인코딩 rate
      • 여러 서버 중 어디서 데이터를 가져올 지: 보통 가장 가까운 곳
    • 서버가 할 일
      • 파일을 멀티플 청크로 나눔
        • 전체 데이터를 시간 간격으로 나누고, 품질도 여러 가지로 준비
      • Manifest file에 여러 청크들의 URL 정리
    • ex) 유튜브를 시청할 때 초반은 화질이 낮았다가 환경에 따라 이후 고화질 제공



Voice-over-IP

voice-over-IP

  • 딜레이가 가장 중요
    • 150에서 400 ms면 사용자들이 감내하며 사용 가능한 수준, 넘으면 대화 어려움
  • UDP 사용
    • TCP의 재전송, congestion control은 end-to-end 딜레이가 크게 증가
    • 전체 패킷 중에 최대 20% 정도는 잃어버려도 사용은 가능
  • Jilter: 어떤 패킷이 소스에서 발생해서 전송되어 receiver에 도착할 때까지의 시간인 딜레이가 들쭉날쭉한 현상
    • 따라서 비디오와 비슷하게 플레이아웃 딜레이가 있음
    • 그러나 지연 시간이 중요하므로 짧음
  • timestamp: sender가 데이터를 만들 때 시간을 기록
  • playout delay
    • fixed playout delay
      • t에 샘플링 된 데이터가 도착했다면, 고정된 값 q ms가 더해진 t+q에 플레이 되어야 함
      • 만약 지연 시간이 길어져 t+q보다 뒤에 도착한다면, 버림
      • q가 크면 패킷 로스율이 낮아지지만 지연 시간이 길어 대화가 부자연스러움
    • adaptive playout delay: q 값을 인터넷 상황에 따라서 자연스럽게 바꿈

loss 해결

  • forward error correction: 부가 정보를 같이 담아 에러가 발생했을 때 해당 데이터를 복원
    • exclusive OR-ing of every n chunk
      • n개의 청크마다 그 청크들을 XOR해서 redundant한 청크 제작
      • 청크들이 모두 잘 왔다면 n+1번째 청크는 그냥 버리면 됨
      • 만약 하나가 없다면 나머지 n-1개와 n+1번째 청크를 XOR해서 해당 청크 복원
    • lower-resolution audio stream
      • 고화질의 청크를 보내고, 저화질 버전을 만들어 그 다음 청크를 보낼 때 덧붙여 보냄
      • 만약 데이터가 없어지면 다음 프레임에서 저화질 버전이 붙어 있으므로 그 데이터를 사용
  • interleaving: 에러 감추기
    • 청크에 연속된 데이터들을 모으면 해당 청크를 잃어버리면 그 부분이 아예 다 사라짐
    • 따라서 청크를 n분의 1로 나눠 그 조각들을 모아 한 청크로 전달
    • 청크 하나가 사라져도 크게 문제가 되지 않음

ex) 스카이프

  • 다양한 형태의 서비스
    • Host-to-phone: 컴퓨터에서 전화
    • 전화기에서 컴퓨터, 여러 사용자가 화상 회의 등
  • 프로토콜이 개방되어 있지 않음
    • 스카이프 응용을 깔아야만 스카이프 응용들끼리 통신 가능
    • reverse engineering 필요
  • P2P(peer-to-peer) 방식이 많이 사용됨으로 추정
  • UDP: 오디오, 비디오 패킷, TCP: 컨트롤 패킷 추정
  • 계층화된 아키텍쳐
    1. 로그인 서버에 사용자 이름, 현재 IP 주소, 포트 넘버를 등록
    2. 해당 인덱스는 각 그룹의 super peer에게 전달됨
    3. 클라이언트는 서버에게서 받은 적합한 super peer와 TCP 연결 수립
    4. super peer에 연결하고 싶은 유저의 IP 주소와 포트 번호 요청
      • 만약 해당 super peer가 해당 정보를 모르는 경우 다른 super peer에게서 알아옴
    5. 노드 간 직접적으로 통신
  • NAT(network address translation) traversal problem
    • 사설 IP 주소를 가진 디바이스가 외부에 먼저 연결을 수립할 수는 있지만 외부에서는 사설 IP 디바이스를 찾아올 수 없음
    • 만약 Alice나 Bob 중 한 명이 퍼블릭 IP를 사용한다면 사설 IP가 퍼블릭 IP에게 요청하면 됨
    • 그러나 둘 다 NAT일 경우 서로에게 요청 불가: super peer들의 릴레이로 해결
      • Alice는 super peer에게 Bob의 super peer와 연결을 만들어 달라고 요청


태그:

카테고리:

업데이트:

댓글남기기

참고