Polling (Short Polling)
HTTP 기반 가장 단순한 실시간 통신 방식
작동 방식
클라이언트가 일정 주기마다 반복적으로 HTTP 요청을 보냄
→ "새 데이터 있어?" → 서버는 즉시 응답
장점
- 구현이 매우 쉽다 (타이머 사용)
- 별도 서버 설정 없음 — 기존 HTTP로 끝
단점
- 데이터가 없어도 계속 요청 → 트래픽 낭비
- 실시간성이 떨어짐
(데이터가 0.1초 전에 생겨도 다음 요청 때까진 모름)
Long Polling
Polling의 단점을 보완한 방식
작동 방식
- 클라이언트가 HTTP 요청을 보냄
- 서버는 데이터가 생길 때까지 연결 유지
- 데이터 발생 시 응답 후 연결 종료
- 클라이언트는 다시 요청 보내며 반복
장점
- Short Polling보다 훨씬 효율적
- 실시간성과 비슷한 수준으로 동작
단점
- 데이터가 너무 자주 발생하면
연결을 계속 끊고 새로 맺어야 하므로 비효율 - 완전한 실시간 스트리밍 수준은 아님
SSE (Server-Sent Events)
HTTP 기반 실시간 단방향(Server → Client) 스트리밍
작동 방식
- 클라이언트가 서버에 “구독 요청(EventSource)”
- 서버가 연결을 유지한 채 필요할 때마다 이벤트 Push
- 클라이언트는 받기만 가능 (단방향)
- 서버로 데이터 보내려면 일반 HTTP 요청 사용
장점
- WebSocket보다 구현이 간단
- 자동 재연결, 이벤트 스트림 기반
- HTTP 인프라 그대로 사용 가능 (프록시, 로드밸런서 친화적)
- 단방향 실시간에 매우 적합
단점
- 클라이언트 → 서버 방향은 지원 X
- 다량의 양방향 실시간 통신에는 부적합
언제 쓰면 좋을까?
| 상황 | 예시 |
|---|---|
| 서버에서 일방적으로 알려주기만 하면 됨 | SNS 알림 |
| 실시간 점수 중계 | 스포츠 |
| 잦은 가격 갱신 | 주식/코인 시세 |
| 실시간 상태 모니터링 | IoT 센서 |
WebSocket
클라이언트 ↔ 서버 간 양방향 실시간 통신
작동 방식
- 최초 한번 HTTP 기반 Handshake
- 이후 HTTP가 아닌 WebSocket 프로토콜로 전환
- 양방향/연결 유지 상태에서 바로 전송
장점
- 완전한 실시간
- 양방향 통신
- 메시지 헤더가 가벼워 효율적
단점
- 서버 구현 난이도 ↑
- 상태를 유지해야 하므로 관리 비용 ↑
- 프록시/로드밸런서 환경에서 설정 필요
기술 비교 요약표
| 기술 | 통신 방향 | 연결 지속 | 실시간성 | 사용 예 |
|---|---|---|---|---|
| Short Polling | Client → Server | ❌ | 느림 | 간단한 반복 업데이트 |
| Long Polling | Client → Server | ⏳ (대기 후 종료) | 중간 | 채팅 알림 |
| SSE | Server → Client | ⭕ 유지 | 좋음 | 알림 / 시세 / 모니터링 |
| WebSocket | 양방향 | ⭕ 유지 | 매우 높음 | 실시간 채팅, 게임, 콜 |
어떤 상황에서 무엇을 사용할까?
| 상황 | 추천 |
|---|---|
| 매우 가벼운 요청, 구현 쉬움이 우선 | Short Polling |
| 실시간 + HTTP 기반 + 단방향이면 충분 | SSE |
| 양방향 대화형 서비스 (채팅, 게임, 협업툴) | WebSocket |
| 실시간처럼 보이면 되지만 부하는 줄이고 싶음 | Long Polling |
결론
| 요구사항 | 해결책 |
|---|---|
| 데이터가 자주 변하지 않음 | Polling |
| 실시간이 필요하지만 단방향 | SSE |
| 양방향이 반드시 필요 | WebSocket |
| 간단한 실시간 구현 | Long Polling |
