UDP, RTP, RTCP 프로토콜, OSI 7계층, TCP/IP 계층 정리

OSI 7계층

OSI 7계층은 네트워크 통신에서 일어나는 과정을 7단계로 나누어 설명하는 모형으로, 통신 장애 시 특정 단계의 어떤 과정에서 문제가 발생하는 지 이해하는 데에 도움이 됩니다. 또한, 새로운 프로토콜이 어느 레이어에 속하는지 파악하면 대략적인 행동을 예측할 수 있습니다.

Host Layer	7	Application	HTTP, DHCP, DNS, POP3	응용 계층. 최종 사용자에 가장 가까우며, User Interface를 제공하는 역할
	6	Presentation	TLS, SSL, FTP, SSH	표현 계층. 데이터 전송을 위한 변환 작업, 암/복호화를 담당.
	5	Session	NetBIOS, RTCP	세션 계층. 두 기기, 두 응용 프로그램 간 연결 지원.
	4	Transport	TCP, UDP	데이터 전송 및 조율, 용량, 속도, 목적지 처리. 서비스 구분에 따른 데이터 전송 방식 지원. 데이터 전송 단위: Segment
Media Layer	3	Network	IP, ICMP, ARP	최적의 중계 노드 경로를 구성하는 라우팅을 지원. 패킷 전달을 담당. 데이터 전송 단위: Packet
	2	Datalink	Ethernet, MAC	직접 연결된 노드 간 데이터 전송. 물리 계층의 오류를 수정하여 패킷 데이터를 실어 보내는 계층 환경에 맞는 통신 프로토콜을 지원하며, 두 개의 부계층인 MAC(Media Access Control, 매체 접근 제어), LLC(Logical Link Control, 논리 연결 제어)로 나뉨. 데이터 전송 단위: Frame
	1	Physical	NIC(Network Interface Card)	전기적, 물리적 표현. 케이블 종류, 무선 주파수 링크, 핀 배치, 전압 등 물리 요건이 포함됨. 데이터 전송 기능만 제공할 뿐 알고리즘을 통한 오류 제어 등은 지원되지 않음. 데이터 전송 단위: Bit

사실은 여러 계층에 걸쳐있는 프로토콜이 더 많습니다.

en.wikipedia.org/wiki/List_of_network_protocols_(OSI_model)

www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.znetwork/znetwork_24.htm

TCP/IP 4계층

네트워크 통신 모델의 표준은 OSI 7계층이지만, 실질적으로 인터넷 환경의 대부분은 TCP/IP 통신으로 이루어져 있어 해당 통신을 기준으로 OSI 7계층 모델을 TCP/IP 4계층 (또는 인터넷 프로토콜 스위트, Internet Protocol Suite) 모델로 간략화 할 수 있습니다.

4	Application	HTTP, FTP, SMTP, SSH, DNS	OSI 7계층의 Application, Presentation, Session 계층이 해당
3	Transport	TCP, UDP	OSI 7계층의 Transport 계층과 동일
2	Internet	IP, ICMP, ARP	OSI 7계층의 Network 계층과 동일
1	Network Access	Ethernet, MAC, NIC	OSI 7계층의 Datalink, Physical 계층에 해당

UDP, User Datagram Protocol, 사용자 데이터그램 프로토콜

Datagram은 단문 메시지를 의미하며, UDP는 단문 메시지 교환을 위해 사용하는 프로토콜입니다. UDP는 같은 Transport 계층 프로토콜인 TCP에 비해 전송 방식이 단순하며 전송 속도가 빠르지만, 이를 위해 오류 검사, 수정, 재요청 기능이 빠져있으며, 이 때문에 데이터의 도착 순서가 뒤바뀌거나, 데이터가 중복되거나 누락되는 등 신뢰성이 낮습니다.

TCP	UDP
연결 신뢰성을 위해 핸드셰이크 과정이 선행되어야 함	연결 설정을 하지 않음
수신자가 데이터를 받을 준비가 되어있는지 확인	수신자가 데이터를 받을 준비가 되어있는지 확인하지 않고 단방향으로 정보를 전송
수신자가 응답에 ACK를 설정하여 메시지 수신 확인 여부를 전달	수신 확인 불가
Sequence Number 토대로 데이터 순서 재조립	도착 순서에 관한 정보가 없어 예측 불가
신뢰성을 바탕으로 세그먼트 오류 검사, 수정, 재요청이 가능	TCP 보다 헤더가 단순하여 속도가 빠르고 오버헤드가 적다.

UDP는 이러한 특징 때문에 실시간성에 중점을 둔 IPTV, VoIP, 온라인 게임, 동영상 스트리밍 서비스 등에서 사용됩니다.

UDP 헤더 구조

UDP 헤더는 각각 16비트의 크기를 가지는 Source Port, Destination Port, Length, Checksum 네 개의 필드로 구성되어 있으며, UDP 헤더는 항상 8바이트의 고정 크기를 가집니다.

RTP(Realtime Transport Protocol, 실시간 전송 프로토콜)

RTP는 실시간 비디오, 오디오 및 데이터를 전송하는 데 사용하는 프로토콜입니다. 실제 서비스 명을 예로 들면 VoIP, WebRTC, IPTV 등에 사용되는 프로토콜입니다. RTP는 실시간성을 중요하게 생각하기 때문에 TCP가 아닌, UDP를 기반으로 사용합니다. UDP가 데이터를 데이터그램 단위로 나뉘 패킷 스위칭을 통해 효율적이고 빠르게 전송하는 방법에 대한 규칙이라면, RTP는 UDP 윗 단에서 작용하는, 전송할 패킷을 어떤 코덱으로 인코딩하고, 수신한 패킷을 어떤 코덱으로 디코딩할 지에 대한 규칙입니다.

실시간 영상의 경우, 최초 한 번만 전체 프레임을 전송하게 되며, 이후 프레임은 이전 프레임과 비교해서 바뀐 부분만 전송됩니다. 이를 Delta Frame이라고 하며, Delta Frame만을 전송하는 방식이 유효한 이유는, 영상이 '비슷한 장면이 연속적으로 이어지는' 특성을 가지고 있기 때문입니다.

RTP 프로토콜은 스트리밍 미디어의 단대단 실시간 전송을 위해 설계되었으며 지터 보상, 패킷 손실 및 누락 감지를 위한 기능을 제공합니다. 영상 제공자가 서버에 단대단으로 전송한 스트리밍 미디어는 다시 IP 멀티캐스트 형태로 각 단말에 일대다 형태로 전송됩니다.

RTP Header, RTCP 헤더

RTP 헤더에는 동기화를 위한 타임스탬프, 패킷 손실 및 재정렬 감지를 위한 시퀀스 번호, 데이터 인코딩 포맷을 지시하는 페이로드 포맷이 포함됩니다.

1. Version(2비트): RTP의 버전을 표시합니다. 현재 버전은 2.
2. P(1비트): Padding, RTP 패킷의 마지막 부분에 패딩 바이트 유무 표시하는 플래그, P=1이면 패딩 존재.
3. X(1비트): eXtension, 헤더와 페이로드 데이터 사이에 하나 이상의 확장 헤더 유무 표시하는 플래그, X=1이면 확장 헤더 존재.
4. CC(4비트): CSRC Count, SSRC identifier 이후 전달되는 CSRC identifier 수 표시
5. M(1비트): 애플리케이션 수준에서 개별적인 방식으로 사용되는 플래그. M=1이면 현재 데이터가 응용 프로그램과 관련이 있다는 의미이다.
6. PT(7비트): Payload Type, 페이로드 타입은 RTP가 전송하고 있는 실시간 데이터의 압축 코덱을 명시한다. PT는 Capability Exchange 단계에서 송신자, 수신자 상호 인지가 필요하다.
7. 시퀀스 번호(16비트): 시퀀스 번호는 수신자가 패킷 손실을 확인하고 복원할 수 있도록 한다. 초기 시퀀스 번호는 보안 상의 이유로 임의로 설정되며, 이후 패킷마다 1씩 증가한다.
8. 타임스탬프(32비트): 타임스탬프는 RTP 패킷의 첫 번째 바이트가 샘플링 된 순간을 의미한다. 초기 타임스탬프는 임의로 선정되며 증가량은 일정하지 않다.
9. SSRC Identifier(32비트): Synchronization SouRCe Identifier, 스트림의 소스를 고유하게 식별하는 ID. 동일한 RTP 세션 내의 SSRC는 고유합니다.
10. CSRC Identifier(각 32비트 씩): Contributing SouRCe Identifier, 여러 소스에서 생성된 contributing source의 ID 열거형.
11. Header Extension(옵션, eXtension 필드가 존재 유무를 공지): 첫 16비트는 profile-specific identifier를, 이후 16비트는 32비트 단위로 확장 헤더의 길이를 지정한다. 이때 32비트(profile-specific id와 length)는 제외된다. 이후 확장 헤더 데이터가 이어진다.

RTCP(RTP Control Protocol, RTP 제어 프로토콜)

RTCP는 RTP 프로토콜을 제어하기 위해, RTP와 결합하여 사용되는 프로토콜입니다. RTCP는 전송에 직접 관여하지 않지만, RTP 세션의 통계 및 제어 정보를 수신자에게 제공하여 패킷 손실, 패킷 지연 변화, 왕복 지연 시간 등의 피드백을 제공합니다. 이 과정에서 적응형 미디어 인코딩 코덱 및 전송 오류를 감지하여 다음 기능을 제공합니다.

1. PLI(Picture Loss Indication): 데이터 손실로 인해 Delta Frame이 아닌, 전체 데이터를 다시 요청
2. FIR(Full Intra Request): 스트리밍 전송하는 사용자가 바뀌었을 경우 새로운 데이터 전송에 대응
3. 일반적으로 RTP는 짝수 UDP 포트에서 전송되며, RTCP는 (RTP 포트+1)번 포트에서 전송됩니다. RTCP 자체는 데이터 암호화와 인증 방법을 제공하지 않으며, 암호화 기능을 추가하면 SRTP로 구현될 수 있습니다.
4. RTCP는 모든 세션 참가자에게 Canonical End-Point Identifier인 CNAME을 제공합니다. SSRC ID는 세션 내내 고유하지만, SSRC와 앤드포인트 사용자의 즉각적인 바인딩은 세션 중에 변경될 수 있기 때문에, CNAME을 사용하여 end-point를 고유하게 식별합니다.
5. 세션 제어 기능을 제공합니다. RTCP는 모든 세션 참가자가 접근할 수 있지만, RTP는 미디어 소스에 의해서만 전송됩니다.
6. RTCP 통계는 사용자 수가 얼마나 많던지간에 모든 참가자에게 전송되어야 합니다.이러한 트래픽은 참가자 수에 비례하여 증가하며, 네트워크 정체를 방지하기 위해 세션 대역폭 관리 기능이 포함되어 있습니다. 세션 대역폭 관리 기능은 보고서 전송 빈도를 동적으로 제어하여 이루어집니다.

RTCP 대역폭 사용량은 총 세션 대역폭의 5%를 넘지 않는 선에서 이루어져야 하며, RTCP 대역폭의 25%를 항상 미디어 소스가 사용하여야만 대규모 컨퍼런스 등에서 신규 수신자가 과도한 딜레이 없이 발신자의 CNAME을 획득할 수 있습니다.

RTCP 보고 간격은 의도하지 않은 동기화 보고 공격을 방지하기 위해 무작위로 지정되며, 권장되는 한 스테이션 당 최소 RTCP 보고 간격은 5초입니다. 스테이션은 5초 간격보다 짧은 시간 안에 RTCP 보고를 전송해선 안됩니다.

RTCP Header, RTCP 헤더

1. Version(2비트): RTP의 버전을 표시합니다. 현재 버전은 2.
2. P(1비트): Padding, RTP 패킷의 마지막 부분에 패딩 바이트 유무 표시하는 플래그, P=1이면 패딩 존재.
3. RC(5비트): Reception Report Count, 패킷에 포함된 수신 보고서 블록 수이다. 0 값도 유효하다.
4. PT(8비트): Packet Type, RTCP 패킷 타입을 명시하기 위한 일정한 값을 포함한다.
5. Length(16비트): 32비트 단위로 계산한, 헤더를 포함하는 RTCP 패킷의 길이 - 1
6. SSRC Identifier(32비트): Synchronization SouRCe Identifier, 스트림의 소스를 고유하게 식별하는 ID.

여러 보고는 각각 고유한 패킷 헤더를 가지는 단일 복합 RTCP 패킷으로 연결할 수 있습니다.

메시지 유형

RTCP는 다음과 같은 패킷의 종류를 구별합니다: sender report, receiver report, source destination, goodbye. 또한, 프로토콜은 확장 가능하며, 애플리케이션에 고유한 RTCP 패킷을 허용합니다.

1. Sender Report(SR): 발신자 보고는 활성 발신자에 의해 주기적으로 전송되며, 인터벌 동안 발생한 모든 RTP 패킷에 대한 송수신 통계를 포함합니다. SR 메시지는 두 가지 타임스탬프를 가지는데, Network Time Protocol 형식을 활용하는 Absolute Timestamp와 이에 대응하는 RTP Timestamp가 존재합니다. 두 타임스탬프는 같은 랜덤 오프셋, 같은 단위를 가집니다. Absolute Timestamp는 수신자가 RTP 메시지를 동기화하는 데 사용합니다.
2. Receiver Report(RR): 수신자 보고는 RTP 패킷을 보내지 않는 수동 참가자를 위한 메시지입니다. 이 보고서는 발신자와 다른 수신자에게 서비스 품질을 알려줍니다.
3. Source DEScription(SDES): SDES 메시지는 CNAME 아이템을 세션 참가자에게 전송하기 위해 사용됩니다. 이외에도 이름, 이메일 주소, 핸드폰 번호 등 소스 소유자에 대한 추가 정보를 제공하기 위해 사용됩니다.
4. goodBYE(BYE): 스트림을 종료하기 위해 전송하는 BYE 메시지. 이를 통해 엔드 포인트가 회의에서 나가는 것을 알릴 수 있습니다. 다른 방법으로도 다른 소스가 해당 소스의 부재를 알 수는 있지만, 메시지는 직접적인 알림을 제공합니다. BYE 메시지는 미디어 믹서에 유용합니다.
5. APPlication-specific message(APP): 애플리케이션 별 확장 설계를 위한 매커니즘을 제공하는 애플리케이션 별 메시지

대규모 배포 확장성

IPTV와 같은 대규모 애플리케이션에서는, 혼잡을 제어하는 데 필요한 RTCP 대역폭 제어 매커니즘으로 인해, 몇 분에서 몇 시간 정도 되는 매우 긴 딜레이가 발생할 수 있습니다. 허용 가능한 빈도는 일반적으로 분당 1 개 미만입니다. 이로 인해 수신자가 관련 통계를 부적절하게 보고하거나 미디어 발신자의 평가가 세션의 현재 상태에 비해 부정확해질 수 있습니다. 이러한 문제를 완화하기 위해 RTCP Filtering, RTCP Biasing 및 Hierarchical Aggregation이 도입되었습니다.

Hierarchical Aggregation

Hierarchical Aggregation 또는 RTCP 피드백 계층은 RTCP 피드백 모델을 최적화한 것이며, Hierarchical Aggregation의 목표는 서비스 품질(QoS) 측정과 최대 사용자 수 상한을 늘리는 것입니다. RTCP 대역폭은 일정하며 세션 대역폭의 5%만을 차지합니다. 때문에 QoS 보고 간격은 세션 구성원의 수에 비례하여 높아지나, 허용되는 보고 간격은 약 10 초입니다.

Hierarchical Aggregation은 단일 소스, 즉 IPTV만 허용되는 멀티 캐스트와 함께 사용됩니다. Any-Source Multicast는 사용자 수가 많은 대규모 애플리케이션에는 적합하지 않습니다.

Feedback Target

Feedback Target은 Receiver Report(RR)를 수신한 뒤, 요약된 RR 패킷(= 수신자 요약 정보, RSI)를 송신자에게 재전송하는 것입니다.