WebSocket과 WebRTC 비교하며 이해하기

2025년 새해 새로운 목표로 프로젝트를 진행하기로 했다. 

디스코드 클론코딩인데 기능 구현을 하려다 보니 WebSocket과 WebRTC에 대해서 필수로 알고 있어야 해서 내 나름대로 머리에 잘 들어오는 순서대로 정리해 보았다. 

 

아래 내용에서 구현하거나 자료를 찾다가 틀린 부분이나 추가할 내용이 있으면 계속해서 추가할 예정이다.

---

• 웹의 통신 방식에는 여러 가지가 있다.
• 대표적으로 HTTP, Websocket, Polling, gRPC, SSE, GraphQL 등이 있는데, 각각의 방식마다 특징이 있어 웹 애플리케이션의 특성에 따라 알맞은 것을 선택하여 사용한다.
• HTTP는 웹 통신의 기본 프로토콜로 요청-응답 방식 기반으로 한 대표적인 통신 프로토콜이다.
• WebSocket은 실시간 양방향 통신을 지원하는 프로토콜로 실시간 채팅, 알림 서비스 등을 제공할 때 사용한다.
• WebRTC 또한 HTTP, WebSocket과 같은 통신 프로토콜 중 하나로 HTTP와 WebSocket이 클라이언트와 서버간의 통신을 위한 방식인 반면, WebRTC는 브라우저 간 직접적인 실시간 통신을 지원하는 기술이다.
  • WebRTC는 P2P 방식으로 설계되어, 실시간 영상 통화나 파일 전송 등 서버를 거치지 않고 직접 브라우저 간에 데이터를 교환할 수 있다는 장점이 있다.

통신방식	설명	주요 특징	용도	WebAPI
HTTP	클라이언트-서버 요청-응답 방식	단방향 통신, 무상태성	웹 페이지 요청, REST API 호출	XMLHttpRequest, fetchAPI
WebSocket	클라이언트-서버 간 지속적인 양방향 통신	양방향, 지속 연결	실시간 웹 애플리케이션, 채팅 서비스	websocket
WebRTC	브라우저 간 직접적인 P2P 통신	실시간 음성/영상 통화, 데이터 전송	영상/음성 통화, 파일 공유	webrtc

---

웹소켓(WebSocket)

• HTML5 표준 기술로 사용자의 브라우저와 서버 사이의 동적인 양방향 연결 채널을 구성
• Websocket API를 통해 서버로 메세지를 보내고, 요청 없이 응답을 받아오는 것이 가능

1. HTTP vs 웹소켓 차이점

• Websocket 프로토콜은 접속 확립에 HTTP를 사용하지만 그 후의 통신은 WebSocket 독자의 프로토콜로 이루어짐
• header가 상당히 작아 overhead가 적은 특징이 있음
• 장시간 접속을 전제로 하기 때문에, 접속한 상태라면 클라이언트나 서버로부터 데이터 송신이 가능
• 데이터의 송신과 수신에 각각 커넥션을 맺을 필요가 없어, 하나의 커넥션으로 데이터를 송수신 할 수 있음
• 통신시 URL은 ws:// 형태

2. socket.io

• 웹소켓은 HTML5의 기술이기 때문에 오래된 버전의 웹 브라우저는 웹소켓을 지원하지 않음
• 이를 해결하기 위해 나온 기술 중 하나
• 웹페이지가 열리는 브라우저가 웹소켓을 지원하면 웹소켓 방식으로 동작하고, 지원하지 않는 브라우저라면 일반 http를 이용해서 실시간 통신을 흉내
• node.js 기반으로 만들어진 기술로, 거의 모든 웹 브라우저와 모바일 장치를 지원하는 실시간 웹 애플리케이션 지원 라이브러리
• 100% 자바스크립트로 구현되어 있으며, 현존하는 대부분의 실시간 웹 기술들을 추상
• 브라우저별로 지원하는 웹소켓 버전이 다르며 오래된 브라우저의 경우 아예 지원하지 않으므로 많이 사용

3. socket.io vs WebSocket

항목	socket.io	webSocket
설치	추가 라이브러리 필요 (socket.io)	브라우저 내장 API 사용
폴백 지원	지원 (롱폴링 등)	폴백 없음 (WebSocket 미지원 브라우저 불가)
사용 편의성	이벤트 기반 통신으로 직관적	메서드 호출 및 수동 구현 필요
추가 기능	인증, 브로드캐스트, 룸/네임스페이스 등 다양한 기능 제공	최소 기능 제공
성능	약간의 오버헤드 발생	더 가벼움

• socket.io: 채팅, 알림 시스템, 게임 같은 복잡한 실시간 애플리케이션
• Websocket: 단순한 실시간 데이터 스트리밍(예: 주가, 날씨정보)

4. 동작원리

1) 핸드쉐이크(handshake)

웹소켓 연결은 HTTP를 통해 시작된다. 클라이언트가 서버에게 웹소켓 연결을 요청하면, 클라이언트와 서버 간에 일련의 핸드쉐이크 과정이 발생한다. 클라이언트는 HTTP Upgrade 요청 헤더를 사용하여 웹소켓 연결로 업그레이드하고, 서버는 이를 승인하며 101 Switching Protocols 응답을 보낸다.

2) 연결 유지(Keeping Connection)

핸드쉐이크 이후에는 TCP 기반의 연결이 설정되며, 이 연결은 지속적으로 유지된다. 이로써 양방향 데이터 전송이 가능해진다.

3) 데이터 교환(Data Exchange)

연결이 확립되면 클라이언트와 서버 간에 데이터를 교환할 수 있다. 데이터는 메시지의 형태로 주고받으며, 이 메시지는 이벤트 기반으로 동작한다. 클라이언트 또는 서버는 언제든지 메시지를 보낼 수 있으며, 상대방은 이에 응답할 수 있다.

4) 연결 종료(Connection Termination)

웹소켓 연결을 종료하려면 클라이언트 또는 서버가 종료 프레임을 보내면 된다. 이 프레임은 연결을 명시적으로 닫는 데 사용된다. 또한, 연결이 비정상적으로 종료되는 경우에는 네트워크 문제 또는 다른 이유로 인해 연결이 끊어진 것으로 판단된다.

5) 프로토콜과 데이터 형식(Protocol and Data Format)

웹소켓 프로토콜은 헤더 정보를 최소화하여 낮은 오버헤드로 데이터를 전송한다. 메시지는 프레임 단위로 나눠지며, 각 프레임은 데이터를 포함하거나 컨트롤 명령을 전송하는 데 사용된다.

5. 웹소켓 프로토콜의 철학

• 웹소켓은 기존의 브라우저에서 사용되던 Origin 정책을 준수한다.
• 한 개의 포트 및 IP에 여러 개의 연결을 유지하기 위해 주소 및 프로토콜 네이밍을 사용한다.
• HTTP 등의 프로토콜과 마찬가지로 TCP 위에서 계층화되어 동작하므로 이후 TCP로 데이터를 보내는 것은 동일하지만, 길이에 제한이 없다.
• 프록시와 같은 중재자와도 원활하게 동작할 수 있도록 종료(closing) handshake 과정을 사용한다.

6. 구성

• 클라이언트
• 서버

---

WebRTC

• WebRTC(Web Real-Time Communication)은 웹 애플리케이션과 사이트가 중간자 없이 브라우저 간에 오디오나 영상 미디어를 포착하고 마음대로 스트림 할 뿐 아니라, 임의의 데이터도 교환할 수 있도록 하는 기술
• WebRTC는 중간자 없이 브라우저 간을 P2P로 연결하는 기술이므로 빠른 속도가 보장되고, HTTPS가 강제되기 때문에 중간자 공격에 대한 보안이 보장된다.
• WebRTC는 구글이 주도한 오픈소스 프로젝트를 기반으로 한 웹 표준이기 때문에 특히 크롬에서 호환성이 높다. 그리고 파이어폭스와 오페라 등이 WebRTC를 적극적으로 후원하고 있다. 한편 사파리 역시 WebKit 기반 브라우저이기 때문에 WebRTC가 지원되기는 하지만, 다른 브라우저에 비해 호환성이 떨어지는 편이다.
  • 크로스 브라우징 이슈 해결을 위해서는 adapter.js 라이브러리를 함께 사용하는 것이 필수적이다. 이 라이브러리는 shim 패턴 및 폴리필을 이용해 다양한 브라우저에서 발생할 수 있는 크로스 브라우징 이슈를 사전에 처리해준다.

1. P2P 절차

1) 각 브라우저가 P2P 커뮤니케이션에 동의

2) 서로의 주소를 공유

• 브라우저 간 직접 통신을 위해서는 각각 현재 연결된 라우터의 공인 IP 주소와 포트(사설 IP 매칭)를 알아야 한다.
• 하지만 어떤 라우터들은 특정 주소나 포트와의 연결을 차단하는 방화벽 설정이 되어 있을 수 있다. 따라서 라우터를 통과해서 연결할 방법을 찾는 과정을 NAT 트래버셜(NAT traversal)이라고 한다.

3) 보안 사항 및 방화벽 우회

• NAT 트래버셜 방법
  1. STUN 서버(Sesstion Traversal Utilites for NAT)
     • 단말이 자신의 공인 IP 주소와 포트를 확인하는 과정에 대한 프로토콜 ⇒ 자신의 공인 IP와 포트 찾아
  2. TURN 서버(Traversal Using Relay NAT)
     • 방화벽 정책으로 인해 STUN 서버로 자신의 주소를 찾지 못할 경우 사용
     • 네트워크 미디어를 중개하는 서버 사용 → 구조상 P2P가 아니기 떄문에 필연적으로 지연 발생(최후의 수단)
• STUN, TURN 서버를 이용해 자신의 주소 획득 >> 후보 찾기
  • 후보 찾기 결과
    • 자신의 사설 IP와 포트 넘버
    • 자신의 공인 IP와 포트 넘버(STUN, TURN 서버에서 획득)
    • TURN 서버의 IP와 포트 넘버(TURN 서버에서 획득)
  • 후보 찾기 방법 → ICE(Interactive Connectivity Establishment) 프레임워크 활용
    • ICE: 두 개의 단말이 P2P 연결을 가능하게 하도록 최적의 경로를 찾아주는 프레임워크

4) 멀티미디어 데이터 실시간 교환

• SDP(Session Description Protocol)
  • WebRTC에서 스트리밍 미디어의 해상도나 형식, 코덱 등의 멀티미디어 컨텐츠의 초기 인수를 설명하기 위해 채택한 프로토콜

2. WebRTC 아키텍처

 

1) Signaling Server

유저 간 연결을 하기위해 요구되는 정보들을 교환하도록 도와줌

SDP, ICE 등의 정보를 교환하는데 사용

시그널링을 할 때 WebSocket 또는 XMLHttpRequest 등 사용 가능

2) STUN Server

ICE Candidate에 대한 정보를 주는 서버

3) TURN Server

P2P 통신에 실패했을 때 사용할 수 있는 서버

4) 미디어 서버

P2P 연결로 3인, 4인 그리고 그 이상의 인원의 데이터 송수신을 지원하게 되면 클라이언트 측면에서의 과부하가 심하게 오기 때문에 권장하지 않는다. 이러한 문제의 해결책으로 나온 것이 SFU와 MCU 방식의 미디어 서버를 두는 것이다.

Mesh

• 피어 간의 offer/answer 정보 중계 → 처음 WebRTC가 피어 간의 정보를 중계할 때만 서버에 부하 발생
• 피어 연결 완료 후에는 서버에 별도 부하 없음
• 1:1 연결에 적합
• 서버 부하가 적기 때문에 서버 자원이 적게 든다.
• 피어간 직접 연결로 데이터를 송수신 하기 때문에 실시간성이 보장된다.
• N:N 또는 N:M 연결에서 클라이언트의 과부하가 급격하게 증가함. 예를 들어, 위의 그림과 같이 5인이 WebRTC 연결을 한다고 가정하면 Uplink(나의 데이터를 연결된 다른 사용자에게 보내는 개수) 4개, Downlink(연결된 다른 사용자의 데이터가 나에게 들어오는 개수) 4개로 총 8개의 링크를 유지하며 데이터를 송수신

SFU(Selective Forwarding Unit) 서버

• 종단 간 미디어 트래픽을 중계하는 중앙 서버 방식
• 클라이언트 피어간 연결이 아닌 서버와 클라이언트 간의 피어 연결
• 1:1, 1:N, N:M 등 모든 연결 형식에서 클라이언트는 연결된 모든 사용자에게 데이터를 보낼 필요 없이 서버에게만 자신의 영상 데이터를 보내면 된다.
• 하지만 1:N, N:N 혹은 N:M 형식이라면 상대방의 수만큼 데이터를 받는 피어를 유지해야 한다.
• 1:N 형식 또는 소규모 N:M 형식의 실시간 스트리밍에 적합
• 데이터가 서버를 거치고 Mesh 방식보다 느리지만 비슷한 수준의 실시간성 유지하면서 클라이언트가 받는 부하 줄어든다.
• 시그널링 서버보다 서버 비용 증가
• 대규모일 경우 여전히 클라이언트가 많은 부하 감당

MCU(Multi-point Control Unit) 서버

• 다수의 송출 미디어를 중앙 서버에서 혼합 또는 가공하여 수신측으로 전달하는 중앙 서버 방식. 예를 들어 5인이 WebRTC 연결을 한다면 자신을 제외한 다른 4인의 Vedio 데이터를 하나의 Video 데이터로 편집하고, audio 데이터도 마찬가지로 편집하여 한 명에게 보낸다. 이 작업을 남은 4명에게도 동일하게 적용한다.
• 클라이언트 피어간 연결이 아닌 서버와 클라이언트 간의 피어 연결
• 모든 연결 형식에서 클라이언트는 연결된 모든 사용자에게 데이터를 보낼 필요 없이 서버에게만 자신의 영상 데이터를 보내면 된다. (uplink 1개)
• 모든 연결 형식에서 클라이언트는 연결된 사용자의 수와 상관없이 서버에게서 하나의 피어로 데이터를 받으면 된다. (downlink 1개)
• 중앙 서버의 높은 컴퓨팅 파워가 요구 된다.
• 클라이언트의 부하가 현저히 줄어든다.
• WebRTC의 최대 장점인 실시간성이 저해되고, video, audio를 결합하는 과정에서 비용이 많이 든다.

이렇게 까지만 봤을 때 SFU 방식이 적당할 듯

일단 우리에게는 높은 컴퓨팅 파워의 서버가 없으며, 실시간성을 저해하는 것보다는 클라이언트의 부하가 나을것 같다….

chatGPT 문의 결과

다양한 사용자 수에 따른 비교

1:10 (소규모 그룹 채팅)

• SFU:
  • 서버 부하: 낮음.
  • 클라이언트 부하: 클라이언트가 최대 10개의 스트림(오디오+비디오)을 처리해야 함.
  • 지연: 서버 지연이 낮아 실시간성 우수.
• MCU:
  • 서버 부하: 믹싱 작업으로 부하 증가.
  • 클라이언트 부하: 단일 스트림 처리로 매우 낮음.
  • 지연: 믹싱으로 인해 100~300ms의 추가 지연 발생.

1:100 (중규모 회의 또는 대규모 그룹 채팅)

• SFU:
  • 서버 부하: 여전히 낮음 (단순 전달 작업).
  • 클라이언트 부하: 각 클라이언트가 최대 100개의 스트림을 수신해야 하므로 매우 높음. 낮은 스펙의 클라이언트에서는 처리 불가.
  • 지연: 클라이언트 CPU 및 네트워크 병목으로 인해 실시간성 저하.
• MCU:
  • 서버 부하: 믹싱 작업이 매우 커짐 (CPU/GPU 자원 소비 증가).
  • 클라이언트 부하: 여전히 낮음 (단일 스트림).
  • 지연: 믹싱에 300~500ms 추가 지연 발생. 실시간성 저하 가능성 있음.

10:10 (다중 소규모 그룹 채팅)

• SFU:
  • 서버 부하: 낮음 (10개의 별도 채널 관리).
  • 클라이언트 부하: 각 클라이언트는 최대 10개의 스트림을 수신해야 하므로 적당한 수준의 자원 필요.
  • 지연: 서버 지연이 낮아 실시간성 우수.
• MCU:
  • 서버 부하: 믹싱 작업 증가 (10개의 믹싱 스트림 생성).
  • 클라이언트 부하: 단일 스트림으로 낮음.
  • 지연: 믹싱으로 인해 200~400ms 추가 지연 발생.

결론: 사용자 수에 따른 선택

1. 1:10 소규모 채팅:
   • SFU가 적합. 서버 부하가 적고 실시간성이 뛰어남.
2. 1:100 대규모 채팅:
   • MCU가 적합. 클라이언트 부하를 최소화하고 사용자 경험을 보장.
3. 10:10 다중 소규모 채팅:
   • 상황에 따라 다름.
     • 클라이언트의 성능이 좋다면 SFU.

저사양 디바이스를 고려한다면 MCU.

디스코드에서는?

디스코드는 주로 SFU 방식을 사용한다. 다만, 서버와 클라이언트 간의 균형을 맞추기 위해 다음을 적용한다.

• 저사양 디바이스나 네트워크 품질이 낮은 환경에서는 SFU + 다운샘플링(화질/음질 조정).
• 대규모 사용자 회의에서는 MCU와 유사한 중앙 집중화 전략으로 스트림을 최적화.

구성

• 클라이언트
• Signaling Server
• STUN Serer
• TURN Server
• MediaServer

---

WebRTC vs WebSocket

WebSocket

• 모든 최신 브라우저와 웹소켓 JS 폴리필을 사용하는 레거시 브라우저에서도 지원되는 IETF 표준 마련
• HTTP 호환 핸드쉐이크와 기본 포트를 사용하므로 기존 방화벽, 프록시 및 웹 서버 인프라와 함께 사용하기 훨씬 쉬움
• 훨씬 더 간단한 브라우저 API
• 클라이언트/브라우저에서 서버로만 연결
• TCP 기반으로 구축되었기 때문에 신뢰할 수 있는 순차적 전송만 지원

WebRTC

• WebRTC에 시그널링 서버가 사용되고, 시그널링 서버에 웹소켓을 사용할 수 있음
• 웹소켓에 비해 복잡
• 연결 실패 가능성
• CPU, 메모리 사용량이 더 많아질 수 있음

요소	WebRTC	WebSocket
CPU 사용량	중간(암호호 및 P2P 연결 관리)	낮음(단순 텍스트 처리)
메모리 사용량	중간(P2P 연결 및 ICE 정보 유지)	낮음(단순 연결관리)
지연 시간	낮음(P2P 연결)	낮음(서버를 경유)
구현 복잡도	높음(STUN/TURN 등 설정 필요)	낮음(기본 HTTP 서버로 구현 가능)

---

참고자료

https://inpa.tistory.com/entry/WEB-🌐-웹-소켓-Socket-역사부터-정리

[WEB] 🌐 웹 소켓 (Socket) 정리 (역사부터 차근차근)

 

https://jaehyeon48.github.io/network/websocket-protocol/

웹 소켓 프로토콜

 

https://wormwlrm.github.io/2021/01/24/Introducing-WebRTC.html

WebRTC는 어떻게 실시간으로 데이터를 교환할 수 있을까? - 재그지그의 개발 블로그

 

https://velog.io/@jasondal91/내가-이해한-WebRTC

내가 이해한 WebRTC

 

https://stackoverflow.com/questions/18799364/webrtc-vs-websocket-if-webrtc-can-do-video-audio-and-data-why-do-i-need-webs

WebRTC vs WebSocket: If WebRTC can do Video, Audio, and Data, why do I need WebSocket?

 

https://millo-l.github.io/WebRTC-구현-방식-Mesh-SFU-MCU/

WebRTC 구현 방식(Mesh/P2P, SFU, MCU) | millo's tech blog