웹소켓은 언제 쓰고, HTTP 폴링과 비교하면 어떤가요?
양방향 실시간 통신인 웹소켓의 사용 사례와, HTTP 폴링·롱폴링과 비교한 장단점을 정리합니다.
웹소켓(WebSocket) 은 하나의 TCP 연결 위에서 클라이언트와 서버가 양방향으로 실시간 통신할 수 있는 프로토콜입니다. HTTP로 핸드셰이크한 뒤 연결을 지속(persistent) 합니다.
언제 쓰나
서버가 능동적으로, 자주, 낮은 지연으로 데이터를 밀어줘야 할 때 적합합니다.
- 채팅·메신저
- 실시간 알림·피드
- 협업 편집(문서·화이트보드)
- 실시간 시세·대시보드, 온라인 게임
HTTP 폴링과 비교
- 폴링(Polling) — 클라이언트가 주기적으로 요청을 반복해 새 데이터를 확인. 구현은 쉽지만 불필요한 요청이 많고 실시간성이 떨어집니다.
- 롱 폴링(Long Polling) — 서버가 데이터가 생길 때까지 응답을 보류했다가 보냄. 폴링보다 실시간성이 낫지만 매번 연결을 다시 맺는 오버헤드가 있습니다.
- 웹소켓 — 연결을 유지하며 양방향으로 즉시 주고받음.
| 항목 | 폴링 | 롱 폴링 | 웹소켓 |
|---|---|---|---|
| 방향 | 단방향(요청) | 단방향(요청) | 양방향 |
| 실시간성 | 낮음 | 중간 | 높음 |
| 오버헤드 | 높음(반복 요청) | 중간 | 낮음(연결 유지) |
| 구현 | 쉬움 | 중간 | 상대적으로 복잡 |
트레이드오프
웹소켓은 실시간·양방향에 강하지만, 연결 유지·재연결·확장(스케일아웃) 관리가 필요합니다. 실시간성이 크게 중요하지 않거나 가끔만 갱신하면, 단순한 폴링이나 SSE(서버센트 이벤트, 서버→클라 단방향) 가 더 단순하고 적절할 수 있습니다.
웹소켓과 HTTP 폴링 비교로 옳은 것은?
이 레슨을 다 읽으셨나요?
완료 표시는 이 브라우저에 저장됩니다.