
프론트엔드
Web application에서 Server to Client통신
두줄요약
서버에서 클라이언트로 이벤트를 전달하는 Polling, Comet, SSE, WebSocket 방식을 비교했습니다.\n통신 빈도와 연결 유지 비용을 기준으로 Polling 또는 WebSocket을 선택할 수 있습니다.
구조와 흐름
- HTTP의 단방향 요청·응답 한계를 보완하는 서버→클라이언트 이벤트 전달 방식
- Polling, Comet의 Streaming·Long Polling, SSE, WebSocket 순의 통신 모델 소개
- Streaming의 hidden iframe과 XMLHttpRequest 기반 구현 방식 및 readyState 활용
장단점
- Polling의 쉬운 구현과 반복 연결·해제 비용
- Long Polling의 이벤트 발생 시점 응답과 서버 부하 가능성
- SSE의 HTTP 기반 단순성 및 서버→클라이언트 단방향 제약
- WebSocket의 TCP 기반 전이중 통신, 작은 데이터 프레임 헤더, 구형 IE 호환성 제약
선택 이유
- 빈번한 양방향 메시지 교환에 적합한 WebSocket
- 1시간 단위처럼 드문 업데이트에서 연결 유지 비용을 피하는 Polling
- 별도 프로토콜·라이브러리 없이 단방향 푸시가 필요한 경우의 SSE
적용해볼 점
- 기존 로그인 세션 종료, 비동기 작업 완료 알림 같은 서버 주도 이벤트에 적용
- 통신 빈도와 연결 유지 비용을 기준으로 Polling과 지속 연결 방식 선택


