CHAPTER 09 멀티미디어 네트워킹

이것도 공부한 지는 좀 됐는데, 지금 풀고 있는 HTB 문제를 당장 풀 자신이 없어서,, 일단 오늘은 이거라도 업로드해보겠다.

 

날씨가 좋길래 한강에서 러닝했다. 경치 좋음

 

멀티미디어 네트워킹 애플리케이션

밀티미디어 네트워크 애플리케이션 - 오디오나 비디오를 포함하는 네트워크 애플리케이션

비디오의 특성

• 높은 비트 전송률
• 공간적 중복: 주어진 이미지 내에서의 중복 현상
• 시간적 중복: 연속되는 이미지 사이의 반복 현상

오디오의 특성

비디오에 비해 훨씬 적은 대역폭 요구

멀티미디어 네트워크 애플리케이션의 종류

저장 오디오와 비디오 스트리밍

• 사용자가 서버에게 비디오 시청을 온디맨드로 요청
• 스트리밍: 재생하면서 동시에 서버에서 파일의 뒷부분 수신
• 상호작용성: 콘텐츠를 정지, 되감기, 빨리 감기 또는 인덱싱
• 연속적인 재생: 재생을 위해 서버에서 데이터를 적합한 시점에 수신해야 함

IP에서의 대화형 오디오와 비디오

• 인터넷 전화, VoIP로 불림
• 지연시간에 매우 민감
• 손실에 민감하진 않음

저장 비디오 스트리밍

클라이언트 버퍼링 - 애플리케이션 버퍼에 수 초 분량 이상의 비디오 데이터가 축적된 이후 재생 시작

• 서버와 클라이언트 사이의 지연 시간 변화의 영향을 감출 수 있음
• 버퍼에 축적된 비디오 데이터가 남아 있는 한 연속적인 비디오 재생 가능

UDP 스트리밍

• 서버와 클라이언트 간의 예측하기 어려운 가용 대역폭 변화로 인해 연속적인 재생 제공에 실패할 수 있음
• 클라이언트와 서버 간의 대화식 요구 및 상태 추적을 위해 RTSP 서버와 같은 미디어 제어 서버를 필요로 함
• 많은 방화벽 시스템이 UDP 트래픽을 차단하도록 설정되어, 방화벽 안쪽의 사용자가 UDP 비디오를 수신하지 못함

HTTP 스트리밍

• 비디오가 방화벽이나 주소변환기를 쉽게 통과 가능
• RTSP 서버와 같은 미디어 제어 서버를 생략하게 함으로써 비용 절감 가능

선인출 비디오(prefetching video)

선인출 - 클라이언트가 비디오를 소비되는 비율보다 더 빠르게 다운로드

클라이언트 애플리케이션 버퍼와 TCP 버퍼

HTTP 스트리밍에서는 클라이언트 애플리케이션 버퍼의 가용 공간이 간접적으로 서버의 비디오 전송률에 대한 제한을 가하게 됨

Voice-over-IP

IP 최선형 서비스의 한계

• 패킷 지연시간이나 패킷 손실의 정도에 대해선 어떠한 약속도 하지 않음
• 수신자는 단위데이터를 재생하는 시점을 결정하는 것과 손실된 단위데이터를 어떻게 할지 고려해야 함

패킷 손실

패킷 손실이 10~20%가 넘게 되면, 만족할 만한 음질을 얻는 것이 불가능

종단간 지연

임계치보다 더 큰 지연을 겪은 패킷은 무시하여 손실됨

패킷 지터

지터: 가변적인 지연으로 패킷이 송신 측에서 생성된 때부터 수신 측에서 수신될 때까지의 시간이 달라지는 현상

수신자의 오디오 지터 제거

• 지터가 있을 때도 음성 단위데이터를 일정한 간격으로 재생할 수 있어야 함
• 방법
  • 각 단위데이터 앞에 타임스탬프 붙이기
  • 수신자에서의 단위데이터 재생 지연

고정 재생 지연

수신자는 단위데이터(chunk)가 생성된 후 정확히 q msec가 지나서 재생 시도

적응 재생 지연

네트워크 지연과 네트워크 지연 변이를 측정하고, 이에 따라 각 말하기 구간의 시작 지점에서 재생 지연을 적절히 조절

패킷 손실의 복구

FEC (forward error correction)

• 원래 패킷 스트림에 중복된 정보를 추가하는 것
• 기법 1 - n개 단위데이터 다음에 하나의 중복 인코딩된 단위데이터 전송
  • 둘 이상의 패킷 손실로부터 재구성 불가능
  • 그룹 크기가 작아질수록 오디오 스트림 전송률 증가
• 기법 2 - 저해상도의 오디오 스트림을 중복 정보로 전송
  • 연속적이지 않은 패킷 손실이 있을 때, 수신자가 다음 패킷과 함께 도착하는 저비율로 인코딩된 단위데이터를 재생하여 손실을 감춤
  • 연속적인 패킷 손실에 취약

인터리빙

• 오디오 유닛을 재순서화하여 원래 인접해 있던 데이터 유닛을 전송되는 스트림에서는 일정 간격 떨어지도록 함
• 패킷 손실로 인한 영향 감소
• 오디오 스트림의 감지되는 품질 향상
• 단점 - 지연시간 증가

손실 은폐

• 패킷 반복 - 패킷 손실이 있기 바로 전에 도착한 패킷의 복사본으로 대
• 인터폴레이션 - 손실 이전과 이후 오디오 사용

실시간 대화형 애플리케이션을 위한 프로토콜

RTP

• 오디오를 위한 PCM, GSM, MP3, 비디오를 위한 MPEG과 H.263과 같은 일반적인 형식을 전달하는 데 사용
• 상용 제품과 연구용 시작품 제작에 사용
• SIP와 상보적 관계

RTP 기초

• 미디어 단위데이터를 RTP 패킷으로 캡슐화한 후 그 패킷을 UDP 세그먼트로 캡슐화해서 IP에 전달
• 패킷 전달과 그 순서를 보장하지 않음
• 멀티캐스트 트리로 전송 가능

RTP 패킷 헤더 필드

페이로드 타입, 순서번호, 타임스탬프, 출발지 식별자 필드

SIP

• 콜 요청자와 콜 응답자 사이에서 IP 네트워크상으로 콜을 설정하는 방법 제공
• 콜 요청자가 콜 응답자의 현재 IP 주소를 알 수 있도록 하는 방법 제공
• 콜 관리 방법 제공
• 대역 외 프로토콜(out-of-band) - SIP 메시지는 미디어 데이터의 송수신용으로 사용되는 소켓과는 다른 소켓으로 전송됨
• SIP 메시지는 아스키로 읽을 수 있고, HTTP 메시지와 유사
• 모든 메시지에 대한 응답을 요구하며, UDP나 TCP 상에서 동작 가능

멀티미디어 지원을 위한 네트워크

최선형 네트워크 설정

네트워크 두 지점 간에 애플리케이션 성능을 예측하고 성능 요구사항에 적합한 충분한 대역폭을 운용하기 위한 쟁점

• 네트워크 두 종단 지점 간 트래픽 요구사항의 모델링이 필요함
• 잘 정의된 성능 요구사항이 제공되어야 함
• 필요 작업량에 대한 종단간 성능 예측 모델 및 모든 사용자의 요구사항을 만족시킬 수 있도록 하면서 대역폭 예약 비용을 최소화할 수 있는 기술 필요

다중 서비스 클래스의 제공

동기 부여 시나리오

• 원칙 1: 패킷 마킹은 라우터가 다른 트래픽 클래스에 속한 패킷들을 구별할 수 있도록 함
• 원칙 2: 한 클래스가 잘못 행동하는 다른 클래스의 트래픽으로부터 나쁜 영향을 받지 않도록 하기 위해, 트래픽 흐름들을 어느 정도 분리하는 것이 바람직함
• 원칙 3: 서로 다른 클래스의 흐름을 분리 설정하면서도, 가능한 한 효율적으로 자원을 사용하는 것이 바람직함

리키 버킷(Leaky Bucket)

감시 기준

• 평균율(일정 시간당 패킷 수)
• 최고율
• 버스트 크기
  • burst: 상당히 짧은 시간 동안 네트워크로 전송될 수 있는 최대 패킷 수

Diffserv

• 가장자리(edge) 기능: 패킷 분류와 트래픽 조절
• 코어(core) 기능: 전달
• PHB(per-hop behavior)는 서로 다른 성능을 보이는 서로 다른 트래픽 클래스들을 만들어낼 수 있음
• PHB는 클래스 간의 성능에 있어서의 차이점을 정의하지만, 이런 행동이 가능하도록 특정 기법을 사용하도록 요구하지 않음
• 성능 차이는 관측/측정 가능해야 함

연결별 QoS 보장: 자원 예약과 콜 수락

• 콜 수락(call admission) 절차 - 하나의 흐름이 QoS 요구사항을 선언하고 네트워크가 요구된 QoS를 고려하여 흐름을 받아들이거나 또는 차단하는 절차
• 원칙 4: 충분한 자원이 항상 가용하지 않다면 QoS 보장을 위해 하나의 흐름이 자신의 QoS 요구사항을 선언하고, 네트워크가 그 흐름을 수락하거나 또는 차단하는 콜 수락 절차가 필요함
• QoS를 보장받기 위해 필요로 하는 다음과 같은 몇 가지 새로운 기법과 프로토콜
  • 자원 예약 - 하나의 콜이 요구하는 QoS를 얻기 위해 필요한 자원을 보장받도록 해당 자원을 그 콜에게 할당하는 것
  • 콜 수락
  • 콜 설정 시그널링 - 콜 수락 절차에서 하나의 콜은 종단 간의 QoS 요구사항을 확실히 만족시키기 위해 그 출발지에서 목적지로 가는 경로상에 있는 각각의 네트워크 라우터 모두에서 충분한 자원을 예약할 수 있어야만 함