← 원문 보기

🃏 치트시트 · 2026년 6월 16일

브라우저 기반 통신 총정리, HTTP부터 WebRTC까지, 어디에 부하가 가는가

HTTP/1.1·2·3, Long Polling, Server-Sent Events, WebSocket, WebRTC, WebTransport를 Stateless/Stateful 관점에서 정리하고, 클라이언트·서버·네트워크 부하를 실측 수치로 비교한다.

시작, 왜 이렇게 많은 통신 방식이 있나

  • 웹은 처음엔 단순했다.
  • 요청 한 번, 응답 한 번.
  • 여러 자원을 동시에 받고 싶다
  • 서버가 먼저 알려주고 싶다

한 단계 뒤로, Stateless vs Stateful 이라는 첫 단추

  • vs 의 선택은 통신 방식 선택보다 먼저 와야 한다.
  • 수평 확장 전략·인프라 복잡도·운영 비용
  • Stateless
  • Stateful

기본 HTTP, Stateless 의 정수

  • HTTP/1.1: 한 연결 위에서 순차적 요청·응답
  • 요청마다 연결을 새로 맺는 것
  • 한계 1, Pipelining 의 실패
  • 한계 2,

Polling, HTTP 위에서 실시간 흉내내기

  • Short Polling: 매 N초마다 묻기
  • 단점
  • 부하
  • 장점

Server-Sent Events, 서버가 스트림으로 push

  • SSE 는 사실상 하나의 HTTP 응답이 영원히 끝나지 않는 방식이다.
  • 하나의 HTTP 응답이 영원히 끝나지 않는
  • EventSource 는 연결이 끊어지면 자동으로 재시도하고, 마지막으로 받은 이벤트 ID 를 Last-Event-ID 헤더로 보낸다.
  • 연결당 메모리

WebSocket, 한 번 열고 양방향

  • WebSocket 은 HTTP 핸드셰이크로 시작해서 프로토콜을 통째로 바꾸는 방식이다.
  • 프로토콜을 통째로 바꾸는
  • 작은 메시지를 자주 주고받기에 최적
  • 필요

WebRTC, 서버를 거치지 않는 P2P

  • WebRTC 는 두 브라우저가 서로 직접 연결되는 방식이다.
  • 서로 직접 연결
  • Signaling Server
  • STUN Server

WebTransport, HTTP/3 위의 양방향 stream (미래)

  • WebTransport 는 HTTP/3 위에서 양방향 stream + datagram 을 제공하는 새 API.
  • HTTP/3 위에서 양방향 stream + datagram
  • 다중 stream
  • Datagram

벤치마크, 실측 차트

  • 여기까지 본 부하 수치를 한눈에.
  • 메모리
  • CPU
  • 지연

종합 비교, 어디에 부하가 가나

  • | 방식 | 통신 주체 | 프로토콜 | 상태 | 클라이언트 | 서버 | 네트워크 | 부하 위치 |
  • HTTP/1.1/2/3
  • Short Polling
  • Long Polling

시나리오별 선택 가이드

  • | 시나리오 | 권장 |
  • HTTP/2 또는 HTTP/3
  • SSE
  • WebSocket

정리

  • 브라우저 통신은 한 방향으로 발전해왔다.
  • "요청-응답"이라는 HTTP의 본질적 제약을 어떻게 우회하느냐
  • "서버에 얼마나 의존하느냐"
  • 시그널링만

참고 자료

  • MDN, HTTP/3
  • MDN, Server-Sent Events
  • MDN, WebSocket API