Long Polling vs SSE vs WebSockets vs QUIC Simply Explained

YouTube에서 보기 | 영상 길이: 10분 43초

요약

이 영상은 두 기계 간의 데이터 교환을 위한 4가지 기법—Long Polling, Server-Sent Events(SSE), WebSockets, QUIC—을 각각의 동작 원리, 실제 코드 데모, 사용 사례, 장단점 순서로 비교 설명한다.

Long Polling

[00:16] Long Polling은 클라이언트가 HTTP 요청을 서버에 보내고, 서버가 새로운 정보가 생길 때까지(또는 타임아웃이 날 때까지) 요청을 열어 두는 방식이다.

동작 흐름:

1. 클라이언트가 HTTP 요청 전송
2. 서버가 데이터가 생기거나 타임아웃이 될 때까지 요청을 보류
3. 데이터가 생기면 서버가 응답 전송 → 연결 닫힘
4. 클라이언트가 응답을 받는 즉시 다시 요청 → 사이클 반복

코드 데모: Express 서버에 두 개의 엔드포인트를 구성한다. /poll 엔드포인트는 클라이언트를 Long Polling 대상으로 등록하고 고유한 클라이언트 ID를 부여하며, 메시지가 전송되거나 연결이 닫힐 때까지 응답 객체를 저장해둔다. /update 엔드포인트는 등록된 모든 클라이언트에게 메시지를 전송하고 연결을 닫는다. 클라이언트(HTML + JS)는 /poll에 요청하고, 메시지를 받으면 화면에 표시한 뒤 즉시 다시 /poll을 호출해 연결을 재확립한다.

사용 사례:

• 모니터링 시스템: 서버/네트워크 상태 주기적 확인
• 데이터 동기화: 유저 상태, 캘린더 이벤트처럼 업데이트가 드문 데이터 동기화

장점:

• 호환성: 기존 HTTP 인프라에서 특별한 프로토콜이나 라이브러리 없이 동작
• 구현 간단: SSE, WebSocket보다 이해하고 구현하기 쉬움
• 폴백 옵션: WebSocket이나 SSE를 지원하지 않는 환경에서 폴백으로 사용 가능

단점:

• 높은 레이턴시: 매 응답마다 새 요청을 시작해야 하므로 WebSocket/SSE보다 느림
• HTTP 오버헤드 증가: 반복적인 요청/응답 사이클로 오버헤드 발생
• 스케일링 이슈: 클라이언트 수가 많아질수록 서버 부하가 급증

Server-Sent Events (SSE)

[02:48] SSE는 서버가 클라이언트로 업데이트를 단방향으로 push하는 단일 지속 HTTP 연결 방식이다.

동작 흐름:

1. 클라이언트가 HTTP 연결을 맺고 서버의 이벤트 스트림을 구독
2. JavaScript에서 new EventSource(url) 객체를 생성하면 연결 수립
3. 서버는 이벤트가 발생할 때마다 UTF-8 인코딩 텍스트 형식으로 데이터를 전송
4. 연결은 클라이언트가 구독을 끊거나 서버가 전송을 멈출 때까지 유지

코드 데모: Express 서버의 /events 엔드포인트가 SSE 연결을 열고, res.write()를 사용해 매초 현재 시각을 이벤트로 전송한다. 클라이언트가 연결을 끊으면 서버는 setInterval을 정리하고 연결을 닫는다. 브라우저 개발자 도구의 Network 탭에서 EventStream으로 매초 이벤트가 도착하는 것을 확인할 수 있다. 주의할 점은 SSE는 단방향이므로, 클라이언트에서 서버로 데이터를 보내려면 별도 채널이 필요하다.

사용 사례:

• 라이브 피드: 뉴스 티커, 금융 데이터 대시보드처럼 실시간 업데이트가 표시되는 앱
• 진행 상황 업데이트: 파일 업로드, 데이터 처리 등 서버 사이드 장기 작업의 진행률 실시간 표시

장점:

• 구현 간단: 브라우저 네이티브 EventSource API 지원으로 라이브러리 불필요
• 효율적: 연결이 유지되므로 Long Polling보다 오버헤드 낮음
• 자동 재연결: 연결이 끊겨도 클라이언트가 자동으로 재연결 시도

단점:

• 단방향만 가능: 서버→클라이언트 방향만 지원. 양방향이 필요하면 별도 채널 필요
• 브라우저 지원: 일부 구형 브라우저나 특정 환경에서 미지원
• 스케일링 한계: 클라이언트당 TCP 연결 하나를 점유하므로 클라이언트 수가 많아지면 제한됨

WebSockets

[05:15] WebSocket은 단일 장기 TCP 연결 위에서 클라이언트와 서버 간의 풀 듀플렉스(양방향) 실시간 통신을 제공하는 프로토콜이다.

동작 흐름:

1. 클라이언트가 WebSocket 핸드셰이크를 시작 — HTTP 요청에 특정 업그레이드 헤더를 포함해 WebSocket 연결로 전환
2. 연결이 수립되면 HTTP 오버헤드 없이 클라이언트와 서버 모두 실시간으로 메시지를 주고받을 수 있음
3. 어느 쪽이든 통신이 더 이상 필요 없을 때 연결을 닫을 수 있음

코드 데모: Express HTTP 서버(3000 포트)가 정적 파일을 제공하고, 별도의 WebSocket 서버(3001 포트)가 소켓 연결을 처리한다. 클라이언트가 연결되면 서버는 수신된 메시지를 모든 연결된 클라이언트에게 브로드캐스트하고, 매초 “ping from server” 메시지를 keep-alive로 전송한다. 클라이언트는 WebSocket API로 3001 포트에 연결하고, 폼 제출로 메시지를 서버에 전송할 수 있다. 데모에서 클라이언트가 메시지를 보내면 서버가 수신하고, 다시 연결된 모든 클라이언트에게 브로드캐스트되는 것을 실시간으로 확인할 수 있다.

사용 사례:

• 실시간 메시징 앱: Discord처럼 양방향 실시간 통신이 핵심인 서비스
• 라이브 알림 및 업데이트: Notion처럼 여러 사용자의 변경 사항을 실시간으로 UI에 반영하는 서비스

장점:

• 낮은 레이턴시: HTTP 오버헤드 없이 거의 실시간 통신 가능
• 양방향: 클라이언트와 서버 모두 자유롭게 데이터를 주고받을 수 있어 인터랙티브 앱 구현에 적합
• 효율적: 연결이 유지되고 핸드셰이킹이 최소화되어 HTTP 기반 방식보다 오버헤드 낮음

단점:

• 구현 복잡: Long Polling, SSE보다 구현 및 관리가 복잡
• 방화벽/프록시 문제: 일부 방화벽이나 프록시가 WebSocket 연결을 차단하거나 간섭할 수 있음
• 스케일링 이슈: 많은 WebSocket 연결을 동시에 관리하는 것이 서버에 부담이 됨

QUIC

[07:55] QUIC(Quick UDP Internet Connections)는 Google이 개발한 트랜스포트 레이어 프로토콜로, TCP가 아닌 UDP 위에서 동작하며 HTTP/2와 HTTP/3의 성능을 개선하기 위해 설계되었다.

동작 원리:

• TCP + TLS + HTTP/2의 기능을 하나의 프로토콜로 통합
• UDP 위에서 안전하고 신뢰할 수 있는 연결을 확립
• 여러 데이터 스트림을 멀티플렉싱하여 레이턴시 감소 및 로드 시간 개선
• TCP의 가장 큰 문제 중 하나인 Head-of-Line 블로킹을 회피: 패킷 손실이 발생해도 다른 스트림에 영향을 주지 않아 더 빠른 복구 가능
• 연결 마이그레이션 지원: Wi-Fi에서 셀룰러로 전환되는 등 클라이언트 IP 주소가 바뀌어도 기존 세션을 계속 유지

실제 사례 - Uber: Uber는 QUIC를 도입하여 드라이버 위치, 가용성, 탑승 상태 업데이트의 반응성을 크게 향상시켰다. 특히 네트워크 환경이 좋지 않은 지역에서 성능 개선 효과가 두드러진다. (Uber Engineering Blog 링크 제공)

사용 사례:

• 빠른 웹 브라우징: 연결 수립 시간 단축, Head-of-Line 블로킹 없는 멀티플렉스 연결, 레이턴시 감소로 전반적인 웹 성능 향상

장점:

• 성능: 특히 네트워크 상태가 나쁜 환경에서 TCP보다 빠른 속도와 낮은 레이턴시
• 보안: 기본적으로 TLS 암호화가 내장되어 보안 강화
• 연결 마이그레이션: IP 주소 변경에도 세션 유지

단점:

• 구현 복잡: 전통적인 TCP보다 복잡하며 특수 라이브러리 필요
• UDP 제한: UDP 트래픽을 차단하거나 제한하는 네트워크에서는 동작 불가
• 채택률: 성장 중이지만 TCP 등 전통 프로토콜보다 아직 덜 보급됨

4가지 방식 최종 비교

키워드

Long-Polling, Server-Sent-Events, WebSocket, QUIC, 실시간-통신, HTTP, TCP, UDP, 풀-듀플렉스, 멀티플렉싱, Head-of-Line-블로킹, 연결-마이그레이션