Polling vs WebSocket

서버에서 데이터가 바뀌었을 때 클라이언트가 그것을 어떻게 아느냐는 문제에 대한 두 가지 접근.

Polling

클라이언트가 주기적으로 서버에 "바뀐 거 있어?"라고 HTTP 요청을 반복하는 방식. 구현이 단순하지만 대부분의 요청이 빈 응답으로 끝나는 낭비가 있고, 실시간성이 polling 간격만큼 지연된다.

Long polling: "바뀐 거 있어?" 요청에 서버가 즉시 응답하지 않고 변경이 생길 때까지 홀딩했다가 그때 응답한다. 클라이언트는 응답을 받으면 곧바로 다시 요청 대기. Polling보다 실시간에 가깝지만 여전히 HTTP 요청-응답 구조 안에 있다.

WebSocket

HTTP 핸드셰이크로 시작해 연결을 TCP 소켓처럼 계속 열어두는 방식. 연결이 유지되는 동안 서버가 클라이언트에게 먼저 메시지를 보낼 수 있다(server push). 채팅, 실시간 알림, 협업 도구에 적합.

연결 흐름:

1. 클라이언트 → HTTP Upgrade 요청
2. 서버 → 101 Switching Protocols 응답
3. 이후 ws:// 프로토콜로 양방향 통신 유지

비교

| | Polling | WebSocket | |---|---|---| | 연결 방식 | 매번 새 HTTP 요청 | 한 번 연결 후 유지 | | 방향성 | 클라이언트 → 서버 (요청 기반) | 양방향 | | 서버 푸시 | 불가 (Long polling은 흉내) | 가능 | | 오버헤드 | HTTP 헤더 매 요청마다 | 연결 후 최소화 | | 적합한 상황 | 변경 주기가 길거나 단순한 경우 | 실시간 이벤트 기반 |

관련 개념

TCP에 기반한 지속 연결 특성 이해가 WebSocket 동작 원리를 파악하는 데 도움이 된다.
SSE(Server-Sent Events)는 WebSocket과 달리 단방향(서버→클라이언트)만 지원하는 중간적 선택지도 있다.