블로그 목적
WebRTC API 프로토콜에 대해서 공부및 정리후 나만의 노하우와 지식을 공유한다.
블로그 요약
1. WebRTC API 포로토콜 에 대해서 알아본다.
2. 프로토콜 중 STURN&TURN 관련 반드시 알아야할 coturn 서버를 구축및 테스트해본다.
블로그 상세내용
WebRTC에 대해서 알아볼까요?
요즘 트렌드가 주요용어에 대해서 궁금하면 챗GPT에 물어보는게 대세인데요...ㅋ
저도 한번 물어봅니다. 제가 알고 있는 WebRTC로 잘 대답해주려나요...
오늘의 질의 내용은 너가 알고 있는 WebRTC 가 모야? 인데요..
아래와 같이 답변해 주네요~
그리고, 얼마전에 SK컴즈에서도 AI챗이라는 서비스에 대해서 베타버전으로 출시를 했습니다.
여기도 한번 똑같이 물어보겠습니다. 아마도 차이점이 있을것 같은데요...
무엇인가 같은듯, 추가적인 정보들을 알려주고 있네요...
그럼 위의 2가지 내용을 취합해서 간단하게 저만의 방식으로 WebRTC와 관련 프로토콜을 정리해보도록 하겠습니다.
WebRTC 란 무엇인가?
WebRTC는 Web Real-Time Communication 의 약자이고요.
한마디로, 웹 브라우저에서 실시간 음성, 영상 그리고 데이터등등의 멀티미디어 데이터를 간단하게 주고 받을 수 있는 오픈소스 프로젝트라고 머릿속에 넣어두시면 될것 같고요...
WebRTC 는 말그대로 Peer 간에 실시간 통신을 구현하기 위해서 일련의 API와 프로토콜을 제공하고 있습니다.
아래에서 제가 설명드릴 프로토콜을 통해서 Peer-to-Peer, 소위 말해 P2P 기반으 통신이 가능하게되는거죠.
WebRTC 는 특히 클라이언트와 서버 모델과는 다르게 서버를 거치지 않고 직접 통신한다는 것이 큰 차이점인데요..
물론, 서로의 통신을 위한 SDP 네고가 필요한데요..그때는 Signaling 서버가 필요하긴 합니다.
참고로 SDP에 대해서 간략하게 설명드리자면요.
WebRTC에서는 Session Description Protocol (SDP)을 사용하여 미디어 스트림을 교환합니다.
SDP는 미디어 스트림의 형식, 코덱 및 네트워크 설정 등을 포함하는 메타 데이터 형식입니다.
예를 들어, 브라우저 A가 비디오 스트림을 전송하려고 할 때 SDP 메시지를 생성합니다. 이 메시지에는 브라우저 A의 로컬 미디어 스트림 정보가 포함됩니다. 예를 들어, 다음과 같은 SDP 정보가 포함될 수 있습니다.
v=0
o=- 7205366038164463278 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE video
a=msid-semantic: WMS
m=video 9 UDP/TLS/RTP/SAVPF 120 121 126 97
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:bS+b
a=ice-pwd:Wccyr8p4dD4yI57b1a5VzTW5
a=ice-options:trickle
a=fingerprint:sha-256 6E:34:2E:94:68:C1:AB:6F:00:45:58:9B:F7:27:EE:75:DF:BF:3D:1C:2C:FA:67:56:52:3D:6C:3E:91:70:9F:0B
a=setup:active
a=mid:video
a=sendrecv
a=rtcp-mux
a=rtpmap:120 VP8/90000
a=rtpmap:121 VP9/90000
a=rtpmap:126 H264/90000
a=rtpmap:97 H264/180000
a=fmtp:120 max-fs=12288;max-fr=60
a=fmtp:121 max-fs=12288;max-fr=60
a=fmtp:126 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=640c1f
a=fmtp:97 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=640c1f
a=ssrc-group:FID 3796301145 1545297595
a=ssrc:3796301145 cname:UAO+5+x5p/pKtWTr
a=ssrc:3796301145 msid:FAA56A3F-26C3-44F2-8F27-1A3304F4C128 6544f7ce-f771-4ed1-b04d-6d3e6dd3b6e3
a=ssrc:3796301145 mslabel:FAA56A3F-26C3-44F2-8F27-1A3304F4C128
a=ssrc:3796301145 label:6544f7ce-f771-4ed1-b04d-6d3e6dd3위의 SDP 예시에서는 다음과 같은 정보를 포함하고 있습니다.
v: 프로토콜 버전
o: 세션 생성자 정보 (세션 ID 및 버전, IP 주소 등)
s: 세션 이름
t: 세션 타이밍 정보
a: 미디어 속성 (여러 개의 속성을 포함할 수 있음)
m: 미디어 유형 및 포트 정보
c: 커넥션 정보 (IP 주소 및 포트)
ice-ufrag: ICE 유저네임 프래그먼트 (네트워크 연결 설정을 위한 정보)
ice-pwd: ICE 패스워드 (네트워크 연결 설정을 위한 정보)
fingerprint: 미디어 인증 정보 (인증 알고리즘 및 인증키)
setup: 미디어 송수신 모드 설정 (active, passive, actpass 중 하나)
mid: 미디어 스트림 ID
sendrecv: 미디어 송수신 모드 (sendonly, recvonly, sendrecv 중 하나)
rtcp-mux: RTCP multiplexing 사용 여부
rtpmap: RTP payload type 및 인코딩 포맷 정보
fmtp: RTP payload format의 특정 매개변수 값 (예: 최대 프레임 크기, 최대 프레임 레이트 등)
ssrc-group: SSRC 그룹 정보 (여러 개의 SSRC를 그룹으로 묶을 수 있음)
ssrc: SSRC 정보 (SSRC ID, cname, msid, mslabel, label 등)
이러한 SDP 정보를 상대방과 교환하여 미디어 스트림의 설정을 확인하고, 미디어 스트림을 송수신합니다. 이를 통해 WebRTC 애플리케이션에서 실시간으로 비디오, 오디오 등의 미디어 데이터를 전송할 수 있습니다.
아무튼, 이외에 모든 실제적인 통신은 Peer 간에 이루어지는게 특징이자 특징이죠.
그리고, WebRTC가 지원하는 프로토콜 및 기술을 잠시 간략하게 정리해보자면요.
ICE, STUN, TURN, NAT, SDP 와 같은 프로토콜및 기술들을 머릿속에 정리해두시길 추천드립니다.
(SDP에 대한 내용은 위에서 간단하게 정리해드렸으니 참고하시면 될것 같고요.)
우선, ICE에 대해서 말씀드리자면요..
ICE는 Interactive Connectivity Establishment의 약자이고요.
P2P 통신을 위한 네트워크 연결 설정 프로토콜입니다.
WebRTC에서 미디어 스트림을 전송하기 위해서는 먼저 상대방과의 연결 설정이 필요한데, 이를 위해 ICE는 다양한 네트워크 환경에서 유연하게 연결 설정을 할 수 있도록 도와줍니다.
WebRTC에서 ICE를 사용한 연결 설정 과정을 설명하면 다음과 같습니다.
1.로컬 미디어 스트림 정보 수집
브라우저는 로컬 미디어 스트림 정보(예: 비디오, 오디오)를 수집합니다.
2.로컬 ICE 에이전트 정보 수집
브라우저는 로컬 ICE 에이전트를 생성하여 로컬 IP 주소 및 포트 정보를 수집합니다.
3.STUN 서버와 통신하여 공인 IP 주소 및 포트 정보 수집
로컬 ICE 에이전트는 STUN 서버에 접속하여 공인 IP 주소와 포트 정보를 요청합니다.
4.NAT 타입 확인
STUN 서버는 로컬 IP 주소와 포트 정보를 받은 후, 클라이언트의 공인 IP 주소와 포트 정보를 응답합니다.
이를 통해 브라우저는 NAT 타입을 확인하고, NAT 장치에 의해 로컬 IP 주소와 포트 정보가 공인 IP 주소와 포트 정보로 매핑되어 있는지 확인합니다.
5.P2P 연결 시도
로컬 ICE 에이전트는 다른 ICE 에이전트와 P2P 연결을 시도합니다.
이때, NAT 장치에 의해 로컬 IP 주소와 포트 정보가 공인 IP 주소와 포트 정보로 매핑되어 있다면, P2P 연결이 성공적으로 수립됩니다.
6.TURN 서버 사용
만약 P2P 연결이 실패할 경우, 로컬 ICE 에이전트는 TURN 서버에 접속하여 NAT를 우회하고, 다른 ICE 에이전트와의 P2P 연결을 시도합니다.
위와 같은 과정을 통해 WebRTC에서 다양한 네트워크 환경에서도 신뢰성 높은 P2P 통신이 가능하게 되는데요.
그럼, 위에서 간단하게 말씀드린 STUN, NAT, TURN 에 대해서도 알아보도록 할께요~
STUN은 Session Traversal Utilities for NAT (STUN) 의 약자이고요..
WebRTC에서 STUN은 NAT(Network Address Translation)을 우회하여 미디어 스트림을 P2P(Peer-to-Peer)로 전송하기 위한 프로토콜입니다.
WebRTC에서는 브라우저에서 실행되는 미디어 스트림을 P2P로 전송하기 위해 먼저 로컬 컴퓨터와 상대방 컴퓨터의 IP 주소와 포트 정보를 알아야 합니다.
그러나 NAT은 로컬 IP 주소와 포트 정보를 NAT 장치에 의해 공인 IP 주소와 포트 정보로 매핑하기 때문에,
로컬 컴퓨터에서 상대방 컴퓨터의 IP 주소와 포트 정보를 바로 알 수 없습니다.
STUN은 이러한 NAT 문제를 해결하기 위해 먼저 로컬 컴퓨터가 STUN 서버에 요청을 보내면,
STUN 서버는 해당 요청을 받아서 로컬 컴퓨터의 공인 IP 주소와 포트 정보를 응답해줍니다.
로컬 컴퓨터는 이렇게 받은 공인 IP 주소와 포트 정보를 이용하여 상대방 컴퓨터와의 P2P 연결을 시도합니다.
STUN은 UDP(User Datagram Protocol) 기반으로 동작하며, 주로 TURN과 함께 사용됩니다.
TURN은 STUN으로 P2P 연결을 시도했으나 실패할 경우에 사용되며, NAT 뒤에서도 P2P 통신이 가능하도록 중계 서버 역할을 합니다.
참고로, WebRTC에서 STUN 서버는 브라우저에 내장되어 있으며, 개발자가 별도로 설정하지 않아도 자동으로 사용됩니다.
이어서, NAT에 대해서도 간략하게 정리해보자면요.
NAT는 Network Address Translation의 약자이고요
로컬 네트워크와 인터넷을 연결하는 라우터 등의 장치에서 사용되는 기술로, 로컬 IP 주소와 포트 정보를 공인 IP 주소와 포트 정보로 변환하는 역할을 합니다.
WebRTC에서는 P2P(Peer-to-Peer) 기반의 미디어 스트림 전송을 위해 로컬 컴퓨터와 상대방 컴퓨터의 IP 주소와 포트 정보를 알아야 합니다.
그러나 NAT은 로컬 IP 주소와 포트 정보를 NAT 장치에 의해 공인 IP 주소와 포트 정보로 매핑하기 때문에, 로컬 컴퓨터에서 상대방 컴퓨터의 IP 주소와 포트 정보를 바로 알 수 없습니다.
NAT는 보안상의 이유로 로컬 네트워크의 IP 주소를 숨기는 역할을 하며, IP 주소 부족 문제를 해결하기 위해서도 사용됩니다.
NAT는 보통 사설 IP 주소 대역(예: 10.0.0.0/8, 192.168.0.0/16 등)을 사용하는 로컬 네트워크와 공인 IP 주소를 사용하는 인터넷을 연결하는 라우터 등의 장치에서 사용됩니다.
다시말해서, WebRTC에서 이런 NAT 문제를 해결하기 위해 STUN과 TURN 프로토콜이 사용됩니다.
STUN은 NAT 장치에 의해 매핑된 공인 IP 주소와 포트 정보를 확인하는데 사용되며,
TURN은 STUN으로 P2P 연결을 시도했으나 실패할 경우에 사용되며,
NAT 뒤에서도 P2P 통신이 가능하도록 중계 서버 역할을 합니다.
WebRTC에서는 NAT 문제를 해결하고 P2P 통신을 위해 STUN과 TURN 서버가 자주 사용되므로,
개발자는 이러한 서버를 구축하거나 외부에서 제공되는 서버를 이용할 수 있습니다.
마지막으로, TURN에 대해서 정리해보려고 하는데요..
TURN은 Traversal Using Relays around NAT 의 약자고요.
P2P(Peer-to-Peer) 기반의 미디어 스트림 전송에서 NAT(Network Address Translation)을 우회하여 통신할 수 있도록 해주는 프로토콜이라고 머릿속에 넣어두시면 될것 같고요.
TURN 서버는 P2P 연결이 실패한 경우, 즉 NAT 장치나 방화벽 등으로 인해 상대방 컴퓨터와 직접적인 P2P 연결이 불가능한 경우, 중계 서버 역할을 수행합니다.
이 때, TURN 서버는 ICE(Interactive Connectivity Establishment) 프레임워크와 함께 사용되며,
ICE는 STUN 서버를 사용하여 NAT 장치의 IP 주소와 포트 정보를 확인한 후, P2P 연결을 시도합니다.
그러나 STUN 서버만으로 P2P 연결이 실패한 경우, TURN 서버를 이용하여 중계 서버를 통해 P2P 통신을 시도합니다.
TURN 서버를 사용하면 NAT 장치를 우회하여 상대방 컴퓨터와의 P2P 연결이 가능하므로, WebRTC에서의 실시간 미디어 스트림 전송이 원활하게 이루어질 수 있습니다.
하지만 TURN 서버를 사용하면 서버와의 데이터 통신이 추가되므로, P2P 연결보다는 대역폭과 지연 시간이 증가할 수 있습니다.
TURN 서버는 개발자가 직접 구축할 수도 있지만, 외부에서 제공되는 TURN 서버를 이용할 수도 있습니다.
Google, Amazon, Microsoft 등 다양한 클라우드 서비스 업체에서 TURN 서버를 제공하고 있으며, 이를 이용하여 WebRTC 애플리케이션을 개발할 수 있습니다.
만약 자신이 WebRTC로 무엇인가 해볼(?) 예정이시면 반드시 머릿속에 넣어두어야 할 개념이니깐요...
꼭 숙지하시면, 다른사람과의 커뮤니케이션할때 커뮤니케이션 미스가 나지 않을것 같고요...
그럼, 블로그의 하이라이트인 TURN서버로 유명한 Coturn 에 대해서도 알아보도록 할께요~
Coturn은 무엇일까요?
Coturn은 NAT traversal 기술을 사용하여 VoIP, 원격 데스크톱 및 P2P 통신을 가능하게하는 TURN 및 STUN 프로토콜을 구현하는 서버이며, 오픈소스라고 머릿속에 정리해두시면 될것 같고요..
(참고로, 아래 github 에서 관련 소스를 받거나 정보를 얻을 수 있습니다. )
https://github.com/coturn/coturn
GitHub - coturn/coturn: coturn TURN server project
coturn TURN server project. Contribute to coturn/coturn development by creating an account on GitHub.
github.com
coturn 은 docker Hub 에서 image 를 댕겨와서 바로 docker 를 사용해서 기동시킬 수 있는데요...
아래 명령어로 댕겨오시면 됩니다.
$ docker pull coturn/coturn
정상적으로 image 를 댕겨왔는지 확인은 아래 명령어로 하시면 되고요.
$ docker image ls
그리고, coturn 관련 환경설정은 아래와 같이 하시면 될것 같고요.(해당 환경설정은 사용하고자 하시는 용도에 따라 변경하시면 됩니다.)
마지막으로, coturn 컨테이너를 아래와 같이 실행하시면 됩니다. (역시나 자신의 환경에 맞춰서 실행하시면 되겠죠?)
$ docker run -d --name coturn --restart always -p 3478:3478 -p 5349:5349 -p 3478:3478/udp -v /home/some/tongker/config/coturn_3478/turnserver.conf:/etc/turnserver.conf -v /log/coturn_3478/:/log/coturn_3478/ coturn/coturn -c /etc/turnserver.conf --verbose=3
그리고 아래 페이지에서 turn 서버 관련 테스트가 가능합니다.
https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
Trickle ICE
webrtc.github.io
테스트해보니 아래와 같이 turn 서버 기능을 잘하는것으로 확인되었습니다.
오늘의 블로그는 여기까지고요..
항상 믿고 봐주셔서 감사합니다.
그럼 결론을 정리해보고, 블로그를 마치도록 할께요~
결론
하나, WebRTC에 대한 개념과 정의를 머리속에 정리해주셔야겠죠?
WebRTC는 Web Real-Time Communication 의 약자이고요.
한마디로, 웹 브라우저에서 실시간 음성, 영상 그리고 데이터등등의 멀티미디어 데이터를 간단하게 주고 받을 수 있는 오픈소스 프로젝트라고 머릿속에 넣어두시면 될것 같고요...
둘, WebRTC가 지원하는 프로토콜 및 기술을 잠시 간략하게 정리해보자면요.
ICE, STUN, TURN, NAT, SDP 와 같은 프로토콜및 기술들을 머릿속에 정리해두시길 추천드립니다.
셋, Coturn은 NAT traversal 기술을 사용하여 VoIP, 원격 데스크톱 및 P2P 통신을 가능하게하는 TURN 및 STUN 프로토콜을 구현하는 서버이며, 오픈소스라고 머릿속에 정리해두시면 될것 같고요..
오늘 하루도 기쁘고 행복한 하루되세요~
(지금은 지역광고 시간입니다. ^^; )
혹시나 이 블로그가 삶(?)을 살아가시는데 조금이나마 도움이 되셨다면,
제가 얼마전에 네이버 인플루언서에 선정되었거든요...
(아쉽게도 IT는 아니지만, 아래 네이버 인플루언서의 팬이 되주시면, IT외에 제 개인적인 관심사인 경제, 부동산, 주식관련해서 정성스럽게 만든 저만의 컨텐츠를 받아보실수 있습니다. ^^;)
