네트워크
멀티미디어 네트워킹
서비스 품질(Quality of Service) => QoS
응용 서비스가 요구하는 서비스 품질
- 손실(loss)
- 지연(delay)
- 지연 변이(delay jitter)
Packet망에서 응용서비스가 요구하는 서비스 품질을 QoS라고 한다.
데이터의 경우는 QoS의 주 이슈가 되지 않는다. Data취급 받는 경우는 다음과 같다.
image의 경우도 데이터로 취급한다.
audio와 video의 경우 파일 전체를 다운 받아서 local computer에서 실행할 경우 데이터로 취급한다.
데이터가 네트워크 서비스의 주 대상일 때는 QoS가 이슈가 되지 않는다.
음성과 동영상의 경우는 패킷의 전송지연과 지연변이의 영향을 많이 받는다. QoS보장이 큰 이슈로 작용하고 있다.
전송지연과 지연변이(Delay and Delay Jitter)
- 네트워크의 Packet이 만들어지고 전송되어 받는데까지 걸리는 사간을 Network delay또는 Total Packet delay라고 부른다.
- Network Delay = Transmission time + Propagation time + queuing time
> Transmission time : 전송시간 = 패킷길이/전송속도
> Propagation time : 전파지연시간 = 전송 거리/빛의 속도
> Queuing time : 라우터의 buffer에 Packet이 머무는 시간 / 라우터처리속도보다 패킷이 더 빨리 올경우 Congestion이 발생
> 전송시간과 전파지연시간은 모든 패킷이 공통으로 필요로 하는 시간으로 일정하다고 볼 수 있다.
> Queuing time은 그때그때의 네트워크 망상태에 따라서 달라 질 수 있다. 이에 의해서 패킷들이 도착하는 시간은 변한다.
이는 전송지연의 이유가 되며, 지연으로 인해 패킷이 손실 될 경우 지연변이라고 한다.
* 멀티미디어 네트워크 서비스 유형 및 특징
- 서비스 유형
1) 저장 스트리밍
2) 생방송 스트리밍
3) 실시간 대화형(ex. 인터넷 전화)
- 근본적인 특징
> 전송 지연에 민감하다.
> 데이터 손실은 어느정도 허용한다.(사람이 느끼지 못하는 것이 대부분이다.)
* 저장 스트리밍 서비스
- 미디어는 서버에 저장되있다.
- 미디어 사용 요청이 오면 Client에게 전송된다.
- 스트리밍이란? client에게 모든 미디어가 도착하기 전에 Play가 시작되는 것을 말한다.
- 이경우 Packet은 자기가 Play되는 시점 전에 도착해야 한다.
> Network delay시간이 일정할 경우에는 스트리밍을 하는데 문제가 없다.
> 하지만, Network delay시간은 일정하지 않다. 이 경우를 해결하기 위해 buffering을 사용하는 것이다.
- 대화식 동작이 구현되야 한다.
> 사용자가 되감기, 일시정지, 빠른진행 등의 VCR기능을 사용할 수 있어야 한다.
> 초기 delay는 10초, VCR기능 동작시 1~2초이내에 반응을 보이면 Human Factor에서 허가가 된다.
* 생방송 멀티미디어 서비스
- 지연에 대해서 요구되는 사항이 많다.
> 패킷이 도착하는 시간이 엄격하게 제약되있다.
- 재생할 패킷을 보관하는 버퍼가 있다.
- 스트리밍 서비스를 한다.
- buffer에 어느정도 Packet이 쌓이면 재생이 시작하기 때문에 첫 패킷이 도착한후 몇초 후에 재생이 시작된다.
- 대화식 동작은 부분적으로 가능할 수 있다.
> 빠른 진행은 불가능(생방송의 특징), 되감기, 일시정지는 구현이 되있다면 가능 할 것이다.
* 실시간 대화형 멀티미디어 서비스
- IP전화 및 화상회의가 이에 해당된다.
- 종단간 음성은 150msec보다 작을 경우 양호한 수준이며, 400msec이하일 경우 사용이 가능하다.(Human Factor)
- 세션 시작을 위해 별도의 protocol이 존재한다.
- 패킷들은 play되어야 하는 시점에 도착해야 한다.
* Internet과 멀티미디어 서비스
- TCP/UDP/IP는 지연을 보장하지 않는다.
- 응용계층에서의 기술을 통해서 최대한의 QoS를 보장할 수 있는 방법을 강구하고 있다.
- 지금까지 나온 해결책
1) 통합 서비스 접근
> 각 응용 서비스에 필요한 대역을 보장한다. 서비스 마다 대역을 새로 만들어야 하므로 현실성이 떨어진다.
> 인터넷의 근본적인 변화가 필요하며, IP계층을 수정해야 한다.
2) 차별 서비스 : 서비스에 따라서 차별화하여 제공해주자.
3) 자유방임
> 현재 그대로 사용하며, 필요하면 대역을 더 제공해주어서 congestion을 줄여 queuing time을 줄인다.
> 대역의 한계가 있으므로, 근본적인 해결이 되지 않는다.
> CDN, 응용 계층에서의 멀티캐스트
* 음성 압축(Audio compression)
- 아날로그 신호를 일정한 속도로 샘플링한다.
- 각 코딩에 따라서 방식이 다르며, 인터넷 전화의 경우 5.3kbps부터 시작된다.
* Analog-to-Digital Coding
- PCM방식 : 샘플링 > 계수화 > 부호화의 과정을 거치면서 실행된다.
> 샘플링 : 일정 시간(T초)마다 voltage값을 읽어낸다.
> 계수화 : voltage의 층을 나눈다. 초대 진폭값과 최소 진폭값의 사이 값. L개의 구간으로 나누어 값이 속한 구간의 값으로 결정
> 부호화 : 계수화된 데이터를 bit로 변경한다.
- Sample 측정 주기를 잘 해야지 음성 복원에 도움이 된다.
> Nyquist정리에 의하면 채집율은 신호에 포함된 최대 주파수의 최소한 두배가 되야한다.
> 음성의 경우 최대 주파수가 4Khz이므로 채집율은 매초 8000번이 된다.
- 부호화를 할경우 음성인경우 각 샘플당 8bit로 대체 시킨다.
> 따라서 64000bit/sec의 전송 속도가 필요하게 된다.
* 비디오 압축
- 이미지 프레임을 일정속도로 플레이 하는 것
- human factor에 의해 1초에 약 30장의 이미지가 필요하다.
- 이미지의 경우는 픽셀단위로 구성되는데, 각 픽셀을 bit로 나타낸다.
- 프레임과 프레임사이에 중복되는 픽셀은 압축하여 보낸다.(용량 packet의 길이를 줄이기 위한 방법)
> 이러한 노력이 없다면 대략적인 계산으로 1초에 10^7bit을 보내야 한다.
- 동영상은 엄청난 용량이 소모될 뿐만아니라 네트워크가 바쳐주지 못하는 경우가 많다.
* 스트리밍 멀티미디어 서비스를 위한 접근법
ⓐ 응용계층에서의 지원 방법
> buffering 기능
~ 지연 변이에 대한 대책으로 버퍼링을 위해서 초기에 어느정도 지연되서 재생이 시작된다.
~ 이는 네트워크 상에서 발생할 수 있는 패킷의 지연과 지연 변이를 방지해줄 수 있다.
~ 만약, 지연이 오래되어 버퍼링이 모두 소모되면 일시정지후 버퍼링을 다시 채운후 재생을 실시한다.
> encoding과 압축으로 용량을 줄인다.
* 인터넷 멀티미디어 실행 방법
ⓐ 단순한 방법
> HTTP object로 오디오/비디오 파일을 local computer에 다운 받은후 클라이언트의 media play에서 실행
> 스트리밍 방법이 아니고, play할 때까지 오랜 시간이 걸린다.
ⓑ 스트리밍 접근
> 웹 서버가 브라우져로 오디오/비디오 파일의 meta file을 보낸다.
> meta file은 audio/video파일의 URL과 content type정보를 갖고 있다.
> 브라우져는 media player를 시작하고, meta file을 넘겨준다.
> media player는 meta file이 지시하는데로 웹 서버에 연결하여 스트림으로 전송 받는다.
> 이 경우 웹 서버와 스트리밍 서버를 분할하여 관리 할 수도 있다.
> 이 경우 UDP를 사용하는 것이 적절하다.
~ 스트리밍 서비스의 경우 위에서 말했듯이 신뢰성에 의미가 없으며, Congestion control이 없는 것이 더 좋다.
> 서로 다른 client의 수신 속도를 처리하는 방식
~ 다른 속도로 encoding된 비디오 copy를 보관하여 client의 속도에 맞추어 전송을 실시한다.
(고/저화질 선택 기능도 이와 같은 예이다.)
> 대화식 제어 : 스트리밍 미디어 제어
~ RTSP라는 별도의 프로토콜을 사용한다.
~ RTSP는 TCP를 사용한다.
~ RTSP는 사용자의 미디어 제어 기능을 제공해준다.
~ RTSP와 Media의 연결은 처음에 전달받는 meta file을 통해서 일치시킨다.
~ RTSP제어 메세지는 포트번호 554번을 사용한다.
ex)
1) 브라우져에 미디어가 포함될 경우 클라이언트는 meta file을 서버로 부터 전송 받는다.
2) 클라이언트는 특정 미디어 파일의 재생을 실시한다.(meta file의 RTSP 주소를 이용해 보낸다)
3) 서버는 세션을 설정하고 요청된 미디어를 스트리밍 해준다.
4) 클라이언트는 미디어를 시청할 수 있다.
5) 클라이언트는 VCR기능을 실시할 때마다 서버에 RTSP 프로토콜로 현 상태를 전송해준다.
(서버는 모두다 응답하지 않고 일정시간 마다 응답해준다. 단지 요청에 따라서 미디어를 조정할 뿐이다)
대화식 멀티미디어
- 인터넷 전화를 생각하면 된다.
- 통화자의 음성은 말하는 구간(Talk)과 묵음 구간(silent)이 반복된다.
> 말하는 구간은 64kbps(if using the PSM coding)
> 패킷은 말하는 구간에서 생성
> 20msec마다 패킷을 만들어서 전송
~ 64000 bit / sec = 8000 byte / sec
~ 8000 byte / sec * 20/100 sec = 160 byte(패킷 하나의 크기)
> packet과 해더는 UDP datagram으로 캡슐화 한다.
※ RTP는 추후에 설명하도록 하겠다.
* 인터넷 전화는 패킷 손실과 지연이 발생할 것이다.
- 네트워크에서의 손실 : Buffer overflow of Router / congestion / 근본적 해결 불가
- 지연 손실 : Packet이 수신자에게 너무 늦게 도착하여 쓸모가 없는 경우
- 지연 허용치 : 400 ms(Human Factor)
- 손실 허용치 : 인코딩 방식에 따라 손실 처리방법은 1%~10% 사이
* 인터넷 전화 또한 네트워크 기반이므로 지연 변이가 발생 할 것이다.
- 지연 변이에 대비로 멀티미디어 네트워킹에선 Buffering을 사용했다.
- 실시간 대화의 경우 이 시간 설정에 한계가 있다.(허용한도 : 20msec)
- 지연 손실/변이에 대비하는 방식
ⓐ 고정 재생 지연
~ Buffered time(Q)을 두어서 재생을 하는 것.
~ Q가 크면 패킷의 손실은 줄어든다. Q가 작으면 더 좋은 품질의 대화가 가능하다.
~ Q에 따른 사람의 반응( 150msec미만 : 감지 못함/150~400msec : 감지하지만 대화 방해X/400msec 이상 : 대화가 방해됨)
ⓑ 적응 재생 지연(Adaptation)
~ Packet을 재생하는 시간을 유동적으로 하자.(재생 지연 시간 Q를 유동적으로 한다.)
~ 재생 지연을 최소화 하고 손실율을 낮추는 효과가 있다.
~ 가중 평균 기법을 사용해여 동적으로 지연시간(Q)을 결정한다.
~ Silent 구간 뒤에 패킷이 온다면, Q가 비이상적인 값을 갖을 수 있다. 따라서, 수신자는 말하는 Time을 알아야한다.
> 이러한 경우 Time-stamp와 함께 일련번호를 확인한다.
> 일련 번호는 송신자가 패킷을 전송할 때마다 순차적으로 전송해주는 값이다.
> 일련 번호의 interval을 통해서 손실 여부를 파악한다.
> 이렇게, 인터넷 전화를 할 때 필요한 추가적 정보를 담는 프로토콜을 RTP라고 한다.
* 인터넷 전화에서 패킷 손실 복구하는 방법
- 네트워크 상에서 일반적으로 재전송 기법을 사용해서 패킷 손실을 복구했다.
- 하지만, 실시간 서비스인 인터넷 전화에서의 재전송은 의미는 없다.
따라서, FEC(Foward Error Correction) 에러 복구를 사용한다,
- FEC 기법
ⓐ 가장 간단한 방법
~ n개의 패킷을 그룹화 하여 XOR 연산을 한 중복 패킷을 보낸다.
~ 이 패킷은 n개의 패킷 전송 뒤에 따라서 보내지게 된다. 이를 위해 대역 낭비가 1/n만큼 발생한다.
~ 손실이 발생할 시 중복 패킷과 패킷들의 XOR연산으로 추측(복원)해낸다.
~ 복원하는 측면에서 n이 작을 수록 좋지만, n이 작을 수록 대역 낭비가 커지므로 효율적이지 않다.
~ n이 커진다면, 패킷 그룹에서 1개를 초과하는 패킷 손실이 발생할 확률이 높아진다.
이는 이 방법으로 복원을 완벽하게 할 수 없는 상태가 되는 것을 보여준다.
ⓑ 2nd FEC 방법
~ ⓐ방법보다 실질적인 방법으로 보내진 패킷을 압축(저품질로 변경)하여 다음 패킷에 합쳐서 보내는 것이다.
~ 패킷 손실이 발생하면, 다음 패킷에서 저품질 패킷을 가져와 재생시킨다.
~ 연속적인 손실이 없다면 손실을 복구 할 수 있다.
ⓒ 인터리빙(interleaving)
~ 여러개의 패킷을 n msec길이로 분해하여 여러개의 패킷을 섞에서 보낸다.
~ 하나의 패킷이 손실되어도 재생되는데 많은 영향을 끼치지 않는다.
* RTP(Real-Time Protocol)
- RTP는 멀티미디어 데이터를 전송하는 패킷의 구조를 정의한다.
- RTP에는 페이로드 유형, 패킷의 일련 번호, 타임 스템프등의 정보를 담고 있다.
- UDP 패킷으로 캡슐화 된다.
- 인터넷 전화상에서는 양말단이 모두 RTP로 동작해야지 서로 통화가 가능하다.
- RTP는 QoS를 보장하기 위해서 있는 것이 아니다. RTP와 QoS는 서로 무관하다.
- RTP Header
> Payload type : 현재 패킷에서 사용된 인코딩 유형을 표시하여 변복조시 서로 유형을 맞추기 위해서 사용
> Sequence number : RTP 패킷을 전송할때마다 하나씩 증가하며, 패킷 손실여부 파악을 위해서 사용
> Time-stamp : PRT 패킷의 첫번째 바이트를 샘플링하는 시간. 샘플링 할때마다 1씩 증가시킨다.
Payload를 통해 인코딩 유형을 알기 때문에 시간을 계산해낼 수 있다.
> SSRC : RTP스트림의 소스를 명시
* RTCP(Real-Time control Protocol)
- RTSP(Real-Time stream Protocol)과 혼동하지 말 것
- RTP와 협력하여 동작
- PRTC패킷은 송신한 패킷의 수, 손실된 패킷의 수, 패킷의 도착 시간 변이등 송수신 상태를 교환할때 사용한다.
> 이 정보를 사용하여 성능을 향상 시키는데 사용한다. (전송율을 조정)
- RTP와 포트 번호로 구분을 한다.
- RTCP는 같은 세션 내에 있는 RTP 미디어 스트림을 동기화 시킬 수 있다.
> RTP 패킷의 타임 스탬프, 패킷이 생성될 때의 시간을 이용하여 동기화시킴
ex) 화상 회의시 video RTP 스트림과 audio RTP 스트림이 전송되며, 이를 RTCP가 동기화 하여 일치화 시켜 보여준다.
- RTCP 트래픽은 세션 대역의 5%이내로 제한한다.
> 과도하게 보내면 대역 낭비를 이르켜 오히려 효율을 낮출 수 있다.
- RTCP 트래픽은 수신자가 75% 송신자가 25%를 사용한다.
* SIP(Session Initiation Protocol)
- 인터넷 전화에서 일반 전화의 Signalling 역할을 하는 프로토콜이다.
- 호(일반 전화의 circuit)를 설정 할때 SIP은 다음과 같은 정보를 제공한다.
> 상대방에게 자신이 전화를 걸겠다는 것을 알려준다.
> 송수신자는 미디어 형태 및 코딩 방식을 합의, 설정한다.
> 통화를 실시하며, 통화가 끝나면 호를 해제(자원을 회수)한다.
- 상대방의 IP주소를 결정하는 역할을 한다.(마치 DNS Server처럼)
- SIP 메세지는 TCP/UDP 어느 것으로 보내도 관계가 없다.
- 통화중에 오는 호설정 메세지 처리를 한다.
※ 상대방의 IP주소를 기억하기는 힘들다. 따라서 다음과 같은 형식으로 대체하며, 각각은 특정 IP와 Mapping되있다.
> Free Name : 사용자가 임의로 저장한 이름(핸드폰의 주소록)
> E-mail : 상대방이 설정해 놓은 E-mail주소
> Identified ID : ISP가 설정해준 특정 ID
* 호 설정(일반 전화의 circuit setting)
- 상대방 IP 주소를 알고 있는 경우
i) SIP invite message를 이용하여 자신의 port번호, 자신의 IP주소, 원하는 코딩방식을 상대방에게 전송한다.
ii) 상대방은 전화에 응답 의사가 있는 경우 200 OK message를 이용하여 자신의 포트번호, IP주소, 코딩방식을 전송한다.
iii) 200 OK message 확인 후, 코딩방식이 일치하면 ACK을 보낸다.
- 호 설정이 끝나며 통화가 실행된다.
- i)단계에서 보낸 코딩 방식을 상대방이 지원하지 않는다면, 상대방이 ii)단계에서 보낸 코딩방식 중에서 하나를 선택한다.
그 후 다시 i)단계로 돌아가 새로운 SIP invite message를 보낸다.
- ii)단계에서 상대방이 요청을 거부하면 그에 대한 이유가 자신에게 돌아오게 된다.
- 상대방 IP 주소를 모를 경우 (이름 변환과 상대방 위치 찾기)
- 상대방이 이동중일 경우에는 IP찾기가 힘들다.
- SIP은 여러개의 서버를 가지고 있으며, 그 중에서 중요한 역할을 하는 것은 SIP 등록자 서버와 SIP 프록시 서버이다.
i) SIP Registrar Server
> Client가 인터넷 전화 관련 프로그램을 실행하면 Client는 SIP Register메세지를 SIP등록자 서버로 보낸다.
> SIP 등록자 서버는 이 정보를 저장하고 있으며, IP Mapping시 사용한다.
ii) SIP Proxy Server
> SIP Proxy Server는 상대방에게 까지 가는 경로를 파악하여 SIP 메세지를 전달하는 역할을 한다.
> 상황에 따라서 여러개의 Proxy Server를 거쳐서 도달 할 것이다.
ⓐ 자신의 Proxy Server(myaddr.co.kr)로 Invite message를 보낸다.
ⓑ Proxy server는 대상의 SIP Registrar Server(destiny.com)로 Invite message를 보낸다.
ⓒ 대상의 SIP Registrar Server(destiny.com)는 현재 상대방이 있는 위치의 SIP registrar를 알려주며, 메세지를 반송한다.
ⓓ SIP Proxy server는 건네 받은 SIP Registrar Server(current.co.jp)로 Invite message를 보낸다.
ⓔ 건내받은 SIP Registrar Server는 상대방에게 메세지를 전송한다.
ⓕ 상대방은 SIP invite message에 대한 대답을 자신이 현재 속해있는 SIP registrar server(current.co.jp)로 보낸다.
ⓖ 전해받은 message를 SIP Proxy server(myaddr.co.kr)로 전송한다.
ⓗ 전해받은 message가 200OK면 ⓘ단계로 간다. 그 외에는 호 설정이 해제된다.
ⓘ 호가 설정되었으며, 서로 통화를 실시한다.
* H.323
- SIP과 비슷한 역할을 하는 또 다른 실시간 대화형 프로토콜 이다.
- 화상 회의까지 할 수 있게 필요한 모든 것을 규정한 완전 통합형 프로토콜로 덩치가 크다.
(SIP보다 크다.)
- H.323은 ITU(전화기반)에서 만들었다. 반면 SIP은 IETF에서 만들었다. 이에따라 HTTP에 기반을 두고 있다.
> H.323은 전화 지향적, SIP은 Web 지향
- SIP은 Keep it simple stupid(KISS)원칙을 사용하여 H.323보다 간단하다.
* 컨텐츠 분배 네트워크(CDNs)
- 하나의 서버에서 스트림파일을 실시간으로 전송하는데는 한계가 있다.
- 특히, Stream Server가 멀리 있다면, Router congestion이 걸릴 확률이 높다.
- 이러한 까닭으로, Congestion을 줄이기 위해서 만든 방법이 CDNs이다.
- Stream Server를 여러 곳에 두어서 Client는 가까이에 있는 Server의 서비스를 받게하는 기술이다.
ex) Google과 같은 국제적 웹사이트는 각 대륙(작게는 나라안에도 몇개의)마다
Stream Server를 두어 양질의 서비스를 제공한다.
- CDNs를 구현하기 의해서는 2가지 문제점을 해결해야 한다.
ⓐ 동기화 : 컨텐츠가 업데이트 될때마다 CDN의 모든 서버를 업데이트 한다.
ⓑ DNS : Client는 본래 서버 주소만 알고 있다.
본래 서버는 Client의 IP를 통해 위치를 파악하여, 근처 CDN의 URL로 다시 연결 시켜준다.
CDN을 지원하기 위한 DNS가 따로 존재한다.