시큐어 릴라이어블 트랜스포트

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

시큐어 릴라이어블 트랜스포트(SRT)는 하이비전에서 개발한 오픈 소스 비디오 전송 프로토콜이다. 지터 및 대역폭 변화에 강하며, AES 암호화를 지원하여 낮은 지연 시간으로 라이브 비디오 전송에 최적화되어 있다. UDP를 기반으로 TCP와 유사한 신뢰성을 제공하며, UDT 프로젝트를 기반으로 한다. SRT 얼라이언스는 SRT 프로토콜 개발 및 사용을 지원하는 단체이며, GStreamer, FFmpeg, OBS Studio, VLC 미디어 플레이어 등 다양한 소프트웨어에서 지원된다.

더 읽어볼만한 페이지

스트리밍 - 실시간 전송 프로토콜
실시간 전송 프로토콜(RTP)은 스트리밍 미디어의 실시간 전송을 위해 설계된 프로토콜로, IP 네트워크에서 오디오/비디오 전송의 표준으로 사용되며, 멀티미디어 데이터 전송, 타임스탬프, 순서 제어, QoS 피드백 등을 제공한다.
스트리밍 - 페이스북 워치
페이스북 워치는 페이스북에서 제공하는 주문형 비디오 서비스로, 오리지널 프로그램과 라이선스 콘텐츠를 제공하며 광고 수익을 창출한다.
비디오 소프트웨어 - 바인 (서비스)
2012년 설립되어 트위터에 인수된 바인은 6초 반복 동영상 공유 서비스로 인기를 얻었으나 2016년 서비스가 종료되었고, 짧은 영상 콘텐츠 제작과 인터넷 밈 생산에 기여했으며, 서비스 종료 후 후속 서비스인 바이트가 출시되었으나 중단되었다.
비디오 소프트웨어 - IGTV
IGTV는 인스타그램 계정으로 로그인하여 사용할 수 있는 동영상 플랫폼 서비스로, 모바일과 데스크톱에서 각기 다른 사양의 동영상 업로드, 자동 재생, 프로필 탭, 페이스북 페이지 연동, 가로형 동영상 지원 등의 기능을 제공했다.
응용 계층 프로토콜 - 실시간 전송 프로토콜
실시간 전송 프로토콜(RTP)은 스트리밍 미디어의 실시간 전송을 위해 설계된 프로토콜로, IP 네트워크에서 오디오/비디오 전송의 표준으로 사용되며, 멀티미디어 데이터 전송, 타임스탬프, 순서 제어, QoS 피드백 등을 제공한다.
응용 계층 프로토콜 - D-Bus
D-Bus는 2002년에 시작된 프로세스 간 통신 시스템으로, 시스템 버스와 세션 버스를 통해 정보 공유, 모듈성, 권한 격리를 제공하며, 일대일 요청-응답 및 발행/구독 통신 방식을 지원한다.

시큐어 릴라이어블 트랜스포트
설명
유형	비디오 전송 프로토콜
개발자	SRT 얼라이언스
발표일	2017년
최신 버전	1.5.2 (2023년 8월 2일)
상태	활성
기술 정보
전송 방식	UDP
포트	(기본) 5000
라이선스	LGPL 2.1

2. 역사

하이비전은 2017년 NAB 쇼에서 SRT 프로토콜과 참조 구현을 오픈 소스로 공개했다.^[9] 2020년 3월, 개별 인터넷 초안인 draft-sharabayko-mops-srt^[1]가 인터넷 기술 특별 태스크 포스의 MOPS(Media OPerationS) 워킹 그룹에 검토를 위해 제출되었다.

2. 1. 개발 배경

'''시큐어 릴라이어블 트랜스포트'''(SRT)는 하이비전(Haivision)에서 처음 개발한 오픈 소스 비디오 전송 프로토콜이다. 스트리밍 성능을 최적화하고 지터 및 대역폭 변화의 영향을 최소화하며, 오류 수정 메커니즘을 통해 패킷 손실을 줄이는 데 도움을 준다. SRT는 AES를 이용한 종단 간 암호화를 지원하며,^[3] 애플리케이션이 구성한 대기 시간에 따라 제한된 시간 동안만 패킷 재전송을 시도한다.^[4]

SRT 설계자인 마크 시몬토스키(Marc Cymontkowski)에 따르면, 공용 인터넷을 통한 MPEG 전송 스트림 전송 외에도 IoT 연결, 메타데이터 교환, 통신 프로토콜, 압축되지 않은 데이터 전송에도 사용된다.^[5]

SRT의 참조 구현은 원래 Lesser General Public License 버전 2.1로 공개되었으나,^[6] 2018년 3월 22일에 Mozilla Public License로 재허가되었다.^[7] UDP 기반 데이터 전송 프로토콜(UDT) 프로젝트는 SRT 프로젝트의 기반이 되었으며,^[9] SRT C API는 설계상 UDT API를 기반으로 한다.^[10]

SRT는 낮은 대기 시간의 라이브 비디오 전송을 위해 설계되었다.^[9]^[3] 하이비전(Haivision)은 2017년 NAB 쇼에서 SRT 프로토콜과 참조 구현을 오픈 소스로 공개했다.^[9] 2020년 3월, 개별 인터넷 초안인 draft-sharabayko-mops-srt^[1]가 인터넷 기술 특별 태스크 포스의 MOPS(Media OPerationS) 워킹 그룹에 검토를 위해 제출되었다.

SRT는 자유 소프트웨어 멀티미디어 프레임워크인 GStreamer, FFmpeg, OBS Studio 및 VLC 자유 소프트웨어 미디어 플레이어에서 지원된다.^[4]^[8]

2. 2. 오픈 소스화 및 SRT Alliance

하이비전은 2017년 NAB 쇼에서 SRT 프로토콜과 참조 구현을 오픈 소스로 공개했다.^[9]

SRT의 참조 구현은 원래 Lesser General Public License 버전 2.1로 공개되었지만,^[6] 2018년 3월 22일에 Mozilla Public License로 재허가되었다.^[7]

2. 3. 라이선스 변경

프로토콜의 참조 구현은 원래 LGPL 버전 2.1로 공개되었지만,^[6] 2018년 3월 22일에 MPL로 재허가되었다.^[7]

3. 특징

SRT는 TCP와 유사하게 연결 및 제어, 안정적인 전송을 제공하지만, UDP를 기본 전송 계층으로 사용하여 응용 계층에서 이를 수행한다. 낮은 지연 시간(기본값: 120ms)을 유지하면서 패킷 복구를 지원하고 AES를 사용한 암호화를 지원한다.

이 프로토콜은 빠른 파일 전송을 위해 설계된 UDT 프로젝트에서 파생되었다.^[15]^[2] UDT는 연결, 시퀀스 번호, 승인 및 손실된 패킷의 재전송에 유사한 방법을 활용하여 신뢰성 메커니즘을 제공했으며, 선택적 및 즉각적인(NAK 기반) 재전송을 활용한다.

SRT는 라이브 스트리밍 모드를 지원하기 위해 그 위에 몇 가지 기능을 추가했다.

3. 1. 신뢰성

SRT는 TCP와 유사하게 연결 및 제어를 통해 안정적인 전송을 제공한다. 그러나 UDP를 기본 전송 계층으로 사용하며, 응용 계층에서 이를 처리한다. 낮은 지연 시간(기본값: 120ms)을 유지하면서 패킷 복구를 지원한다. SRT는 AES를 사용한 암호화도 지원한다.^[2]

이 프로토콜은 빠른 파일 전송을 위해 설계된 UDT 프로젝트에서 파생되었다.^[15] UDT는 연결, 시퀀스 번호, 승인 및 손실된 패킷의 재전송에 유사한 방법을 사용하여 신뢰성 메커니즘을 제공했다. 선택적 및 즉각적인(NAK 기반) 재전송을 활용한다.

SRT는 라이브 스트리밍 모드를 지원하기 위해 다음과 같은 기능을 추가했다.

# 소스 시간 전송(타임스탬프 기반 패킷 전달)을 통한 지연 시간 제어

# 완화된 발신자 속도 제어

# 조건부 "너무 늦은" 패킷 삭제 (제때에 복구되지 않은 손실된 패킷으로 인해 발생하는 HOL 차단 방지)

# 즉시 패킷 재전송(주기적인 NAK 보고)

3. 2. 낮은 지연 시간

SRT는 TCP와 유사하게 연결 및 제어, 안정적인 전송 기능을 제공한다. 그러나 UDP를 기본 전송 계층으로 사용하며, 응용 계층에서 이러한 기능을 구현한다. 낮은 지연 시간(기본값: 120ms)을 유지하면서 패킷 복구를 지원하며, AES 암호화를 지원한다.^[15]

SRT는 라이브 스트리밍 모드를 위해 다음과 같은 기능을 추가했다.

제어된 지연 시간, 소스 시간 전송 (타임스탬프 기반 패킷 전달)
완화된 발신자 속도 제어
조건부 "너무 늦은" 패킷 삭제 (시간 내에 복구되지 않은 손실된 패킷으로 인한 HOL 차단 방지)
조기 패킷 재전송 (주기적 NAK 보고)

3. 3. 보안

SRT는 AES를 이용한 종단 간 암호화를 지원한다.^[3] 재전송을 할 때 SRT는 애플리케이션이 구성한 대기 시간을 기반으로 제한된 시간 동안만 패킷을 재전송하려고 시도한다.^[4]

3. 4. 패킷 손실 복구

SRT는 TCP와 유사하게 연결 및 제어, 안정적인 전송 기능을 제공한다. 하지만 UDP 프로토콜을 기본 전송 계층으로 사용하며, 응용 계층에서 이를 처리한다. 낮은 대기 시간(기본값 120ms)을 유지하면서 패킷 복구를 지원한다. SRT는 AES를 이용한 암호화도 지원한다.^[15]

이 프로토콜은 빠른 파일 전송을 위해 설계된 UDT 프로젝트에서 파생되었다.^[2] UDT는 연결, 시퀀스 번호, 승인, 손실된 패킷 재전송과 같은 방식을 통해 안정적인 메커니즘을 제공했으며, 선택적이고 즉각적인(NAK 기반) 재전송 방식을 활용한다.

SRT는 라이브 스트리밍 모드를 지원하기 위해 다음과 같은 기능을 추가했다.

# 제어된 지연 시간, 소스 시간 전송 (타임스탬프 기반 패킷 전달)

# 완화된 발신자 속도 제어

# 조건부 "너무 늦은" 패킷 삭제 (시간 내에 복구되지 않은 손실된 패킷으로 인한 HOL 차단 방지)

# 조기 패킷 재전송 (주기적 NAK 보고)

3. 5. 제어된 지연 시간

SRT는 라이브 스트리밍 모드를 지원하기 위해 다음과 같은 기능을 추가했다.

소스 시간 전송(타임스탬프 기반 패킷 전달)을 통해 지연 시간을 제어한다.
완화된 발신자 속도 제어를 제공한다.
조건부 형태의 "너무 늦은" 패킷 삭제 기능을 제공한다. 이는 제때에 복구되지 않은 손실된 패킷으로 인해 발생하는 HOL 차단을 방지한다.
즉시 패킷 재전송(주기적인 NAK 보고) 기능을 제공한다.

3. 6. 완화된 발신자 속도 제어

SRT는 라이브 스트리밍 모드를 지원하기 위해 추가된 기능 중 하나로, 발신자가 전송 속도를 완화된 형태로 제어할 수 있도록 한다.

4. 패킷 구조

SRT 패킷은 애플리케이션 계층에서 생성되어 전송 계층으로 전달된다. 애플리케이션에서 생성된 각 SRT 미디어 또는 제어 데이터 단위는 SRT 패킷 헤더로 시작한다.^[1]

SRT 패킷 헤더
오프셋	옥텟	0								1								2								3
옥텟	비트	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	F	필드 의미는 패킷 유형에 따라 다름
4	32	필드 의미는 패킷 유형에 따라 다름
8	64	타임스탬프
12	96	대상 소켓 ID
...	...	패킷 내용 (패킷 유형에 따라 다름)

SRT 패킷 헤더의 구조는 위 표와 같으며, 옥텟은 네트워크 바이트 순서로 전송된다. 비트bit^영어 전송 순서는 매체에 따라 달라진다.

4. 1. 데이터 패킷 헤더

SRT 데이터 패킷 헤더
오프셋	옥텟	0								1								2								3
옥텟	비트	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	0	패킷 시퀀스 번호
4	32	PP		O	KK		R	메시지 번호
8	64	타임스탬프
12	96	대상 소켓 ID
...	...	데이터

헤더의 필드는 다음과 같다.

'''패킷 시퀀스 번호''' (31 비트)
'''PP''' (2 비트): 패킷 위치 플래그
'''O''' (1 비트): 순서 플래그
'''KK''' (2 비트): 키 기반 암호화 플래그
'''R''' (1 비트): 재전송된 패킷 플래그
'''메시지 번호''' (26 비트)
'''데이터''' (가변 길이)

4. 2. 제어 패킷 헤더

SRT 제어 패킷 헤더
오프셋	옥텟	0								1								2								3
옥텟	비트	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	1	제어 유형															하위 유형
4	32	유형별 정보
8	64	타임스탬프
12	96	대상 소켓 ID
...	...	제어 정보 필드(CIF)

헤더의 필드는 다음과 같다.

'''제어 유형''' (15 비트): 제어 패킷 유형이다.
'''하위 유형''' (16 비트)
'''유형별 정보''' (32 비트)
'''제어 정보 필드''' (가변 길이)

5. 작동 모드

SRT는 세 가지 작동 모드를 제공하며, 처음 두 가지는 UDT에서 파생되었다.

파일 스트림 모드: TCP와 유사하다.
파일 메시지 모드: SCTP 프로토콜과 유사하며, 경계가 명확하게 정의된 데이터 블록을 전송한다.
라이브 모드: 데이터는 이미 적절한 시간 간격을 두고 작은 패킷(전송된 스트림이 MPEG-TS인 경우 일반적으로 최대 13,160억)으로 전송되어야 한다. 동일한 시간 간격으로 동일한 단일 패킷이 수신 측에서 전달된다.

6. 구현

현재 SRT의 구현은 오픈 소스 SRT 라이브러리가 유일하다. 더 자세한 내용은 [https://github.com/Haivision/srt/tree/master/docs 소스 코드 문서]에서 확인할 수 있다.^[12]

6. 1. SRT 라이브러리 기능

현재 사용 가능한 유일한 구현은 오픈 소스 SRT 라이브러리이다.

C 언어 API는 주로 이전 UDT API를 기반으로 하며, 새로운 기능이 추가됨에 따라 추가적인 변경이 이루어졌다. API는 TCP와 매우 유사하다.

SRT는 실제로 세 가지 작동 모드를 제공하며, 처음 두 가지는 UDT에서 파생되었다.

파일 스트림 모드: TCP와 유사
파일 메시지 모드: SCTP 프로토콜과 유사하며, 경계가 명확하게 정의된 데이터 블록을 전송한다.
라이브 모드: 데이터는 이미 적절한 시간 간격을 두고 작은 패킷(전송된 스트림이 MPEG-TS인 경우 일반적으로 최대 13,160억)으로 전송되어야 한다. 동일한 시간 간격으로 동일한 단일 패킷이 수신 측에서 전달된다.

SRT 라이브러리는 또한 다음과 같은 기능을 제공한다.

사전 공유 키를 사용한 암호화. 암호화 지원은 원래 OpenSSL에서 제공되었으며, 이제는 대안으로 Nettle (GNU TLS) 또는 mbedTLS를 사용할 수 있다.
SRT 접근 제어 (일명 "StreamID")는 애플리케이션에서 리소스를 식별하고 여러 목적으로 동일한 서비스 포트 번호를 사용하는 동안 사용자 암호 접근 방식을 사용하는 데 사용될 수 있다.^[12]
선택적 순방향 오류 정정 메커니즘.

더 자세한 문서는 [https://github.com/Haivision/srt/tree/master/docs 소스 코드 문서]에서 확인할 수 있다.

6. 2. API

C 언어 API는 주로 이전 UDT API를 기반으로 하며, 새로운 기능이 추가됨에 따라 추가적인 변경이 이루어졌다. API는 TCP와 매우 유사하다.

SRT는 실제로 세 가지 작동 모드를 제공하며, 처음 두 가지는 UDT에서 파생되었다.

파일 스트림 모드: TCP와 유사
파일 메시지 모드: SCTP 프로토콜과 유사하며, 경계가 명확하게 정의된 데이터 블록을 전송한다.
라이브 모드: 데이터는 이미 적절한 시간 간격을 두고 작은 패킷(전송된 스트림이 MPEG-TS인 경우 일반적으로 최대 13,160억)으로 전송되어야 한다. 동일한 시간 간격으로 동일한 단일 패킷이 수신 측에서 전달된다.

SRT 라이브러리는 또한 다음과 같은 기능을 제공한다.

사전 공유 키를 사용한 암호화. 암호화 지원은 원래 OpenSSL에서 제공되었으며, 이제는 대안으로 Nettle (GNU TLS) 또는 mbedTLS를 사용할 수 있다.
SRT 접근 제어 (일명 "StreamID")는 애플리케이션에서 리소스를 식별하고 여러 목적으로 동일한 서비스 포트 번호를 사용하는 동안 사용자 암호 접근 방식을 사용하는 데 사용될 수 있다.^[12]
선택적 순방향 오류 정정 메커니즘.

더 자세한 문서는 https://github.com/Haivision/srt/tree/master/docs 소스 코드 문서에서 확인할 수 있다.

7. SRT Alliance

해비전(Haivision)과 와우자 스트리밍 엔진(Wowza Streaming Engine)이 설립한 SRT 얼라이언스는 회원들이 ''시큐어 릴라이어블 트랜스포트''(SRT) 프로토콜과 이를 기반으로 한 소프트웨어를 개발, 사용 및 홍보하는 단체이다.^[11]

참조

_[1] 간행물 The SRT Protocol IETF 2023-10-20
_[2] 웹사이트 UDT: Breaking the Data Transfer Bottleneck https://udt.sourcefo[...] 2020-08-27
_[3] 웹사이트 Secure, Reliable, Transport https://github.com/H[...] GitHub 2021-09-26
_[4] 웹사이트 SRT in GStreamer https://www.collabor[...] 2018-02-16
_[5] 웹사이트 It glues everything together: an interview with Marc Cymontkowski, evangelist of SRT https://blog.medialo[...] 2019-11-05
_[6] 웹사이트 SRT Video Transport Protocol Open-Sourced https://www.phoronix[...] Phoronix 2017-04-24
_[7] 웹사이트 Change License to MPLv2.0 · Haivision/srt@a75d4c4 https://github.com/H[...] GitHub 2018-03-22
_[8] 뉴스 Secure Video Comes of Age https://www.collabor[...] 2018-06
_[9] 문서 Why We Created SRT and the Difference Between SRT and UDT https://www.haivisio[...] Marc Cymontkowski
_[10] 문서 Haivision srt API docs https://github.com/H[...]
_[11] 웹사이트 Microsoft Joins SRT Open Source Streaming Project https://www.thebroad[...] 2018-09-17
_[12] 웹사이트 SRT Access Control Guidelines https://github.com/H[...] 2019-11-07
_[13] 웹사이트 5 Reasons You Should Pick RIST over SRT https://www.rist.tv/[...] 2021-12-04
_[14] 간행물 The SRT Protocol IETF 2023-10-20
_[15] 웹인용 UDT: Breaking the Data Transfer Bottleneck https://udt.sourcefo[...] 2020-08-27

본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com