이 문서는 클라이언트-서버 간 실시간 데이터 통신을 위한 주요 기술인 Polling, Long Polling, SSE(Server-Sent Events), WebSocket을 비교하고, 특정 시나리오(1500개 동시 연결 및 방송)에 가장 적합한 기술을 분석합니다.
1. 기본 기술 비교 (Polling vs Long Polling vs SSE)
클라이언트가 서버로부터 최신 정보를 받아오기 위한 세 가지 기본적인 접근 방식입니다.
기술별 동작 방식
1. Polling (폴링)
- 동작 방식: 클라이언트가 일정한 주기로 서버에게 “새로운 데이터 있어?”라고 계속해서 물어보는 방식입니다.
- 장점: 구현이 매우 간단하고 직관적입니다.
- 단점: 불필요한 요청이 많아 비효율적이며, 데이터 수신에 지연이 발생할 수 있습니다.
2. Long Polling (롱 폴링)
- 동작 방식: 클라이언트가 요청을 보내면, 서버는 새로운 데이터가 생길 때까지 응답을 대기시킵니다. 데이터가 생기면 응답하고, 클라이언트는 즉시 다음 요청을 보내 다시 대기합니다.
- 장점: 폴링보다 효율적이고 실시간에 가깝습니다.
- 단점: 요청마다 연결을 새로 맺는 오버헤드가 발생합니다.
3. SSE (Server-Sent Events)
- 동작 방식: 클라이언트가 서버에 최초 한 번의 연결을 맺으면, 그 연결을 계속 유지하면서 서버가 필요할 때마다 일방적으로 클라이언트에게 데이터를 밀어넣는(Push) 방식입니다.
- 장점: 한 번의 연결로 오버헤드가 적고 매우 효율적입니다.
EventSourceAPI는 자동 재연결도 지원합니다. - 단점: 서버에서 클라이언트로의 단방향 통신만 가능합니다.
비교 요약표
| 구분 | Polling | Long Polling | SSE (Server-Sent Events) |
|---|---|---|---|
| 연결 방식 | 요청마다 연결/종료 반복 | 요청마다 연결, 데이터 수신 후 종료 | 최초 1회 연결 후 유지 |
| 통신 방향 | 클라이언트 → 서버 | 클라이언트 → 서버 | 서버 → 클라이언트 (단방향) |
| 지연 시간 | 김 (최대 폴링 주기) | 짧음 | 매우 짧음 (실시간) |
| 효율성 | 낮음 (불필요한 요청 많음) | 보통 | 높음 (오버헤드 적음) |
| 주요 용도 | 실시간성이 중요하지 않은 경우 | 실시간 채팅, 알림 | 실시간 알림, 주식 시세, 라이브 스코어 등 |
2. 시나리오 분석: 1500개 동시 연결 및 전체 방송
요구사항: 1500개의 클라이언트가 동시에 연결되어야 하며, 변경 사항이 발생하면 모든 클라이언트에게 데이터를 전송(Broadcast)해야 합니다.
이 시나리오에서는 WebSocket이 가장 효율적이고 적합한 선택입니다.
기술별 적합성 평가
| 항목 | WebSocket | SSE (Server-Sent Events) | Long Polling |
|---|---|---|---|
| 1500 연결 확장성 | 매우 높음 | 보통 (브라우저 제한 고려) | 매우 낮음 |
| 방송 효율성 | 매우 높음 | 높음 | 낮음 (Thundering Herd 문제) |
| 서버 리소스 사용량 | 낮음 | 보통 | 매우 높음 |
| 통신 방향 | 양방향 | 단방향 (서버→클라이언트) | 양방향 (비효율적) |
| 추천 여부 | 강력 추천 | 차선책 | 절대 비추천 |
- WebSocket (강력 추천): 적은 리소스로 수천 개의 동시 연결을 안정적으로 관리할 수 있습니다. 서버는 연결된 소켓 목록을 통해 매우 빠르고 효율적으로 방송할 수 있습니다. 양방향 통신이 가능해 향후 확장에도 유리합니다.
- SSE (차선책): 1500개의 HTTP 연결을 유지하는 것은 WebSocket보다 리소스 소모가 크며, 브라우저의 도메인당 동시 연결 개수(약 6개) 제한이 심각한 제약이 될 수 있습니다.
- Long Polling (절대 비추천): 1500개의 요청이 동시에 응답을 받고, 즉시 1500개의 새로운 요청이 몰려오는 “Thundering Herd” 문제로 서버에 엄청난 부하를 유발하여 시스템 장애로 이어질 수 있습니다.
3. 심층 분석: SSE vs WebSocket 리소스 사용량
“SSE가 WebSocket보다 리소스 사용량이 적다”는 주장은 특정 관점에서만 사실이며, 대규모 동시 접속 환경에서는 오해를 유발할 수 있습니다.
오해의 근원: 유휴(Idle) 연결 관리
- 데이터 전송이 거의 없는 유휴 상태의 단일 연결만 놓고 보면, SSE가 더 가볍게 보일 수 있습니다. SSE는 본질적으로 긴 HTTP 요청 하나이며, 비동기 서버에서 유휴 연결은 거의 리소스를 차지하지 않기 때문입니다. 반면 WebSocket은 상태(Stateful)를 유지하기 위한 관리 비용이 미세하게 더 듭니다.
진실: 실제 데이터 전송 시의 효율성
대규모 데이터 전송 및 방송 환경에서는 프로토콜 오버헤드가 성능을 좌우하며, 이 지점에서 효율성이 역전됩니다.
- SSE: 메시지를 보낼 때마다 `data: <메시지>
` 형식의 텍스트 기반 HTTP 청크로 전송됩니다. 이 형식 변환 자체가 오버헤드입니다.
- WebSocket: 최초 핸드셰이크 후에는 매우 가벼운 바이너리 기반 프레이밍(Framing) 프로토콜을 사용합니다. 메시지에 붙는 헤더가 최소 2바이트까지 작아질 수 있어 오버헤드가 압도적으로 낮습니다.
최종 결론: 시나리오에 따른 리소스 사용량
| 비교 항목 | SSE (Server-Sent Events) | WebSocket | 설명 |
|---|---|---|---|
| 유휴 연결 비용 | 약간 더 낮을 수 있음 | 약간 더 높을 수 있음 | 단일 유휴 연결의 상태 관리 비용 측면. 현대 서버에선 거의 무의미한 차이. |
| 메시지 전송 오버헤드 | 높음 (텍스트 기반) | 매우 낮음 (바이너리 기반) | 실제 성능을 좌우하는 가장 중요한 요소. |
| 1500개 방송 효율성 | 낮음 | 매우 높음 | 낮은 오버헤드 덕분에 CPU와 네트워크 자원을 훨씬 적게 사용. |
| 전체 리소스 사용량 (대규모 방송 시나리오 기준) | 높음 | 낮음 | 데이터 전송이 잦은 대규모 환경에서는 WebSocket이 압도적으로 효율적. |
결론적으로, 1500개 연결과 같은 대규모 동시 접속 및 방송이 필요한 실시간 서비스에서는 프로토콜의 근본적인 효율성 차이로 인해 WebSocket이 SSE보다 훨씬 적은 리소스를 사용하며 안정적이고 확장성 있는 솔루션입니다.
댓글 (0)