태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.
 

 
블로그 이미지
[www.netrain.co.kr]에서 네트워크/보안을 공부하시는 분들을 위해 서비스를 제공하는 블로그입니다 승진아빠
Follow silpir  on Twitter


[RTP] Real-time Transport Protocol의 이해

네트워크 기초 | 2010.04.28 22:33 | Posted by 승진아빠


어렵고 복잡한 이야기는 생략하도록 하겠습니다. RTP는 이름 그대로 실시간으로 전송되는 데이터에 대한 정보를 담고 있는 Protocol입니다. 기본 12 byte로 되어 있으며 Audio나 Video 등 multimedia를 전송하는 경우 사용합니다. 왜 필요할까요?

보통 Multimedia 데이터를 전송하는 경우 UDP를 사용한다고 어제 말씀 드렸습니다. 이 UDP라는 놈이 좀 문제입니다. 첫째 어제 말씀드렸던 것과 같이 Sequence Number가 없어요. 순서가 뒤죽박죽 들어오면 어느 데이터가 먼저 보낸진 것인지 알 수가 없다는 말입니다.

그래서, RTP에는 Sequence Number이라는 것과 Timestamp를 사용합니다.

TCP는 Sequence Number를 어떻게 증가시킨다고 말씀드렸죠? 보낸 데이터의 양만큼 증가를 시켜서 전체 Buffer에서 어느 위치에 속하는지를 알려준다고 설명드렸었습니다. 그런데, RTP의 Sequence Number는 1씩 증가를 합니다. 편하군요.
 
그런데, 문제는 전에 보낸 데이터가 나중에 들어왔을때 재조합을 해야 하는데 그게 어려워요. 생각을 해보세요. 10칸짜리 화물차가 있습니다. 한번 싫은 물건은 다시 내렸다 실는건 불가능하다는군요. 화물차에 실어야 하는 내용물은 '석탄', '옷', '음료수', '과자'인데 순서대로 실어야 하고 각각 몇칸씩 차지하는지 모릅니다.

이런 경우 차례대로 들어오면 상관이 없지만, 음료수가 먼저 들어오면 운에 맡기는 수밖에 없겠죠!

그래서, TCP는 Sequence Number를 이용해서 자신이 어느위치에 들어가야 하는지 알려주도록 설계가 되었는데 RTP는 그렇게 하지를 않은겁니다. 어떻게 해야 할까요? 할 수 없죠. 추가 정보를 넣는 수 밖에요. ^^

그래서 Timestamp 정보를 같이 보내줍니다.  보낸 시간 정보를 주는거죠. 시간정보를 주면 어떻게 아냐구요? 아날로그 신호를 디지털 신호로 변조할 때, 전화같은 경우 1초에 8,000개의 Sampling을 하게 됩니다. 나이퀴스트라는 사람이 만든 법칙이라고 하죠. Max Hz의 2배 이상의 Sampling을 하면 원음에 가까이 복원가능하다는 이론................. 보통 유선전화에서 전달 되는 신호가 300Hz ~ 3400Hz이기 때문에 8000개면 충분하데요. ^^

8,000개의 Sample을 하나하나씩 데이터로 만드는데 1개당 1byte 값을 가지게 됩니다. 다 합치면 8000 byte 겠군요. 1초에 8,000 byte를 전송하려면 8000 X 8 = 64Kbps의 속도가 필요하겠네요.

하여튼 이 8,000개의 Data를 하나씩 전송시키려고 하니 무슨 문제가 발생합니까? 1byte를 보내기 위해 L4 Header, L3 Header, L2 Header를 추가하면... 휴~ 배보다 배꼽이 더 크겠군요. 그래서, IPT에서는 뭉터기로 보내죠. Default로 160개의 Sample을 한꺼번에 던집니다... 그러기 위해서는 1초에 50개의 Packet을 만들어서 던져야 겠네요. 그럼, 데이터들의 Delay는 20ms를 유지해야 정상적으로 들리겠군요.

참 힘들게 삽니다.. 그쵸? ^^

다시 조금 위로 올라가면 1초에 8,000개의 Sample을 만들어서 던지려면 Sample과 Sample 사이에는 얼마의 Delay가 발생할까요? 1초/8,000 = 125us 군요. 이 정보를 싫어 보냄으로써 몇번째 Sample인지 알려주는 방식... 그게 RTP라는 놈입니다. 무서운 놈이죠! 가까이 하고 싶지 않지만, 요즘 하도 UC가 대세라... 담달부터 저도 좀 더 깊숙히 공부하려구요.

UDP가 이 문제만 있을까요? 아니죠. Session을 관리하지 않기 때문에 마구잡이로 들어오면 이놈이 그놈 다음건지, 저놈은 이놈이랑 같은 서비스인지... 정신 하나도 없답니다. 그래서, 또 RTP의 도움을 받는군요.

SSRC와 CSRC 등을 가지고 Source identifier를 판단하고 Session을 관리합니다. 마치 Session Layer에서 Session ID를 통해 관리하는 것과 비슷하군요.

UDP와 RTP 참 힘들게 살죠? ^^ 그래도 상호간 서로 부족한 부분을 메워가며 잘 살고 있잖아요. TCP처럼 혼자 다 해결하려는 놈들...... 나중에 고생할겁니다. 우리도 서로 부족한 부분을 서로가 메워가며 살아가기로 해요.

이상.... 이경태였습니다. ^^
 

티스토리 툴바