화상통화 구현 시 웹rtc가 웹소켓에 비해 나은 게 맞을까요?

Question

최근 카톡의 화상통화 구현을 생각해 보고 있는데요.gpt 검색해 보니 웹rtc 방식과 웹소켓 방식이 있더라구요. 그러면서 웹소켓은 데이터 용량이 더 많이 든다는 단점을 말해주던데요.어차피 통화라는 게 둘 만 데이터 통신 하는 게 아니라 서버도 보관용으로 같이 데이터를 쌓아 두어야 한다면 과연 웹소켓이 웹rtc에 비해 데이터 전송량이 더 많다고 할 수 있을까요?게다가 웹rtc stun, turn 서버 두느니 웹소켓 서버 하나 두는 게 더 나을 것 같기도 하구요.다른분들은 웹rtc와 웹소켓의 비교에 대해서 어떻게들 생각하시나요?

캐티 · Answer

p2p 통신을 하여서 트래픽 요금이 절감대빈다. stun 서버는 구글이 운용 중인 서버가 있어서 무료이어요. stun 서버에 머 특별한 기능이 없스빈다. 순수하게 구현하라고 하여도 구현이 가능하는 것이어요. tcp tls 처리를 하여야 하면 암호화 모듈을 사용하는 편이 좋아서 앵간할꺼빈다. 이렇다 하더라도 tcp 기능은 빼고 사용하면 좋아요. 애초에 tcp 연결 기능을 사용하려면 방화벽을 열어야 할꺼빈다. webrtc-quic 표준도 준비 중인 것 같은데, 아직까지 udp-over rtp rtcp sctp 이 셋 기반 구현이어서 프토코콜 스택 낭비(오버헤드)가 있쩌. 이렇다 하더라도 심각한 문제는 아닐꺼빈다. sctp 프로토콜에 구조체를 살펴보면 N개 chunk를 한번에 담는 패킷 전송 방법이 앵간하빈다. 느린 체크섬에 오버헤드를 줄이려는 의도였겠지만 udp 패킷은 MTU 1500 이내 주로 MTU 1350 바이트 이내 패킷을 전송하여야 일반적으로 레이턴시가 짧스빈다. MTU 1350 바이트가 되는 이유는 경로상에 라우터 설정이 제한되어 있거나 일부 블록에 컨트롤 데이터를 넣었어서 이렇다고 전망하빈다. 나도 라우터를 운영한다면 새로운 컨트롤 블록을 보내지 않고 원래 보내야 할 블록에 찡겨넣어서 절약을 하겟쩌. 머 이렇다 하더라도 오디오 비디오 통신은 일정한 데이터를 보내고 받으므로 udp-over 자체가 특별한 문제가 되지 않을 꺼빈다. 이러면 udp-over sctp 기반인 데이터 통신만 쫌 그렇쩌. wifi에 24시간 작동을 하면 한번은 끊기는 것 같스빈다. 브라우저 자체에 문제일지도 모를 일이저.전송량 자체로 따지면 rtp rtcp 구조체를 별도로 사용하는 웹rtc가 처리 성능이 높다고 전망하빈다. 웹소켓에서 오디오 비디오 스트림을 전송하려면 인터레이스만 최고 성능을 내겠쩌. 이거는 실시간 구현이어서 패킷 순서가 심하게 밀리면 망하는 tcp 통신에 특성으로 이럴 수 밖에 없스빈다. 반면에 udp통신은 패킷 순서가 심하게 밀려도 특별한 문제가 없쩌. turn 서버는 클라우드플레어 워프를 사용하는 이용자 사이에 p2p 연결을 하는데 없으면 연결이 안되는데, 일반적인 고려 사항은 아니빈다. 솔까 1:1 연결이 아니라면 굳이 turn 서브를 사용하지 않고 이미 접속한 다른 이용자의 컴퓨터를 릴레이 하여서 네트워크 유지비를 절감하면 좋스빈다.웹 소켓이 먼가 포지션이 애매하빈다. http3가 udp 기반으로 작동하면서 websocket도 h3 기반에 올라가느냐 원래는 이케 되어야 하지만 애매한 포지션으로 h2 기반으로 작동하는 서버가 많을 꺼빈다. 이럼 유지 개발 관리가 앵간하겠쩌. 이럼 나는 그냥 webrtc-quic이 아직 없었다 하더라도 webrtc-stcp 정도로 만족 할꺼빈다.머 이거는 웹브라우저나 웹어플리케이션 한정이고 직접 udp프로토콜을 개발하는 이유는 위에 문제에 다 나왔쩌. 이케 하였다 하더라도 이미 무료로 공개된 구글 stun 서버와 클라우드플레어 turn 서버는 감사하게 잘 사용할 계획이빈다. udp 토렌트 트레커 서버를 stun 서버로 사용해도 되빈다. 사용하는 구조체가 다르지만 기능이나 구현 원리가 동일하빈다.솔까 .. webrtc 시그널에 webtracker (웹소켓) 서버를 사용하는 거는 내 서버가 없어도 되어서 이럼 끝나쩌.

화상통화 구현 시 웹rtc가 웹소켓에 비해 나은 게 맞을까요?

1개의 답변

기술 목록