- 요즘 SSE와 같은 client ←> server 통신 방법들에 대해
블로그나 커뮤니케이션 주제로 떠오르는 것 같아
평소에 개념조차 명확히 모르고 있었던 부분이라 gpt와 함께 정리를 해보았다.
✅ 1. 기본 개념 정리
| 기술명 | 설명 |
|---|
| Short Polling | 클라이언트가 일정 주기로 서버에 “새 데이터 있어요?” 하고 계속 요청함. |
| Long Polling | 요청은 주기적으로 하되, 서버는 새 데이터가 생길 때까지 응답을 대기함. |
| SSE | 클라이언트가 서버에 한 번 연결하면, 서버는 이벤트가 생길 때마다 단방향으로 푸시함. |
| WebSocket | 클라이언트-서버 간에 지속적 연결을 유지하며 양방향 통신을 함. |
| |
🧱 2. 기술별 구조도
⚖️ 3. 기술별 비교표 (속도/부하/적합한 케이스)
| 항목 | Short Polling | Long Polling | SSE | WebSocket |
|---|
| 통신 방향 | 양방향 (요청 → 응답) | 양방향 (요청 → 지연응답) | 단방향 (서버 → 클라이언트) | 양방향 |
| 지속 연결 | ❌ (매번 새 연결) | ❌ (요청마다 연결, 길게 유지) | ✅ | ✅ |
| 실시간성 | ⛔ 낮음 (주기 polling) | ⚠️ 보통 (응답 지연으로 대응) | ✅ 좋음 | ✅ 최고 |
| 리소스 효율 | ⛔ 매우 비효율 (HTTP 요청 반복) | ⚠️ 적당함 (연결 수 많으면 부담) | ✅ 효율적 (1회 연결 유지) | ⚠️ 유지비용 있음 (스레드/세션 관리) |
| 브라우저 지원 | ✅ (AJAX로 가능) | ✅ | ✅ (EventSource) | ✅ |
| 방화벽/프록시 호환성 | ✅ 좋음 | ✅ 좋음 | ✅ 아주 좋음 (HTTP 기반) | ❌ 프록시 설정 필요 |
| 자동 재연결 | ❌ 직접 구현 | ❌ 직접 구현 | ✅ 자동 지원 | ❌ 직접 구현 |
| 메시지 유형 | 텍스트/JSON | 텍스트/JSON | 텍스트 기반 | 텍스트 + 바이너리 |
| 적합 예시 | 알림 배지 체크, 간단한 상태 확인 | Slack 메시지 읽음 체크 | 알림, 주가, 뉴스 | 채팅, 게임, 공동 편집 |
