Server-sent Events vs. Websocket
웹 애플리케이션이 점점 더 실시간적이고 동적으로 발전함에 따라, 서버와 클라이언트 간의 효율적인 통신 방식이 중요해졌다. 전통적인 HTTP 요청-응답 모델은 실시간 데이터 전송에 최적화되어 있지 않기 때문에, 이를 보완하기 위한 기술로 서버 전송 이벤트(Server-Sent Events, SSE)와 웹소켓(WebSocket)이 등장했다. 두 기술 모두 실시간 통신을 가능하게 하지만, 그 작동 원리와 적합한 사용 사례에는 중요한 차이가 있다.
서버 전송 이벤트(SSE)
개념과 작동 원리
서버 전송 이벤트(SSE)는 HTTP 연결을 통해 서버에서 클라이언트 브라우저로 데이터를 단방향으로 스트리밍하는 웹 기술이다. HTML5 표준의 일부로, EventSource
API를 통해 구현된다. SSE는 기존 HTTP 프로토콜을 활용하며, 특별한 프로토콜 전환 없이 서버에서 클라이언트로의 실시간 데이터 푸시가 가능하다.
SSE의 작동 과정은 다음과 같다:
- 클라이언트는
EventSource
객체를 생성하여 서버와 연결을 수립한다. - 서버는
text/event-stream
콘텐츠 유형으로 응답하며, 연결을 열린 상태로 유지한다. - 서버는 필요할 때마다 정해진 형식으로 데이터를 전송한다.
- 클라이언트는 이벤트 리스너를 통해 서버에서 오는 메시지를 처리한다.
- 연결이 끊어지면 클라이언트는 기본적으로 자동 재연결을 시도한다.
코드 예시
클라이언트 측 (JavaScript):
|
|
서버 측 (Node.js with Express):
|
|
웹소켓(WebSocket)
개념과 작동 원리
웹소켓(WebSocket)은 단일 TCP 연결을 통해 클라이언트와 서버 간의 양방향 통신 채널을 제공하는 프로토콜이다. HTML5와 함께 도입된 웹소켓은 HTTP와는 별개의 프로토콜(ws:// 또는 wss://)을 사용하며, 초기 핸드셰이크는 HTTP를 통해 이루어지지만 이후 연결이 성공하면 프로토콜이 업그레이드된다.
웹소켓의 작동 과정은 다음과 같다:
- 클라이언트는
WebSocket
객체를 생성하여 서버에 연결을 요청한다. - 서버와 클라이언트는 HTTP 프로토콜을 통해 핸드셰이크를 수행한다.
- 핸드셰이크가 성공하면 연결은 HTTP에서 웹소켓 프로토콜로 업그레이드된다.
- 이후 클라이언트와 서버는 동일한 연결을 통해 양방향으로 메시지를 주고받을 수 있다.
- 연결은 어느 한쪽에서 명시적으로 종료할 때까지 유지된다.
코드 예시
클라이언트 측 (JavaScript):
|
|
서버 측 (Node.js with ws):
|
|
SSE와 WebSocket의 비교 분석
핵심 차이점
SSE와 WebSocket의 가장 근본적인 차이점은 통신 방향과 프로토콜에 있다:
- SSE는 HTTP 프로토콜을 사용하는 단방향(서버 → 클라이언트) 통신 기술이다.
- WebSocket은 독립적인 프로토콜을 사용하는 양방향(서버 ↔ 클라이언트) 통신 기술이다.
상세 비교
특성 | 서버 전송 이벤트(SSE) | 웹소켓(WebSocket) |
---|---|---|
통신 방향 | 단방향 (서버 → 클라이언트) | 양방향 (서버 ↔ 클라이언트) |
프로토콜 | HTTP/HTTPS | WebSocket (ws:// 또는 wss://) |
연결 수립 | 표준 HTTP 요청 | HTTP 업그레이드를 통한 프로토콜 전환 |
메시지 형식 | 텍스트 기반 (text/event-stream) | 텍스트 또는 바이너리 데이터 |
최대 연결 수 | 브라우저별 HTTP 연결 제한 적용 | 일반적으로 더 많은 동시 연결 가능 |
자동 재연결 | 기본 내장 | 직접 구현 필요 |
이벤트 ID 지원 | 지원 (Last-Event-ID 헤더) | 직접 구현 필요 |
이벤트 유형 구분 | 네이티브 지원 | 메시지 내용으로 구현 필요 |
복잡성 | 상대적으로 단순 | 상대적으로 복잡 |
오버헤드 | HTTP 헤더로 인한 오버헤드 | 초기 설정 후 최소 오버헤드 |
브라우저 지원 | IE를 제외한 대부분 지원 | 모든 현대 브라우저 지원 |
프록시 처리 | 일반 HTTP 프록시 통과 가능 | 일부 프록시에서 문제 발생 가능 |
방화벽 통과 | 일반적으로 쉬움 (HTTP 80/443 포트) | 일부 환경에서 차단될 수 있음 |
서버 구현 | 대부분의 웹 서버에서 쉽게 구현 | 전용 WebSocket 서버 또는 라이브러리 필요 |
확장성 | 다수의 연결 시 서버 부하 증가 | 효율적인 양방향 통신으로 확장성 우수 |
데이터 크기 | 텍스트 기반으로 제한적 | 대용량 바이너리 데이터 전송 가능 |
보안 | 표준 HTTP 보안 (HTTPS) | TLS를 통한 보안 (WSS) |
사용 사례 | 알림, 피드, 업데이트 등 단방향 통신 | 채팅, 게임, 협업 도구 등 양방향 통신 |
세부 비교 분석
통신 방식과 프로토콜
SSE는 기존 HTTP 프로토콜을 사용하여 서버에서 클라이언트로 데이터를 푸시한다. 클라이언트가 서버로 데이터를 보내려면 별도의 HTTP 요청이 필요하다. 이는 구현이 단순하고 기존 웹 인프라와 호환성이 좋다는 장점이 있다.
WebSocket은 HTTP를 통해 초기 핸드셰이크를 수행한 후, 독립적인 양방향 통신 채널로 전환된다. 이후에는 클라이언트와 서버가 동일한 연결을 통해 자유롭게 메시지를 주고받을 수 있다. 이러한 방식은 더 효율적인 통신이 가능하지만, 구현 복잡성이 증가한다.
연결 관리와 재연결
SSE는 연결이 끊어졌을 때 자동으로 재연결을 시도하는 메커니즘이 기본적으로 내장되어 있다. 또한 Last-Event-ID
헤더를 사용하여 재연결 시 마지막으로 수신한 이벤트 이후의 데이터만 요청할 수 있다.
WebSocket은 연결 관리와 재연결 로직을 직접 구현해야 한다. 연결이 끊어지면 클라이언트는 이를 감지하고 명시적으로 재연결을 시도해야 한다. 또한 마지막 상태를 복구하기 위한 메커니즘도 직접 구현해야 한다.
메시지 형식과 크기
SSE는 텍스트 기반 프로토콜로, 메시지는 ‘data:’, ’event:’, ‘id:’ 등의 접두사가 있는 줄로 구성된다. 이는 구조화된 이벤트 전송에 적합하지만, 바이너리 데이터 전송에는 제한이 있다.
WebSocket은 텍스트와 바이너리 데이터를 모두 효율적으로 전송할 수 있다. 이는 이미지, 오디오, 비디오 등 다양한 유형의 데이터를 처리하는 데 더 유연하다.
오버헤드와 성능
SSE는 HTTP 프로토콜을 사용하므로, 각 메시지에 HTTP 헤더가 포함되어 일정한 오버헤드가 발생한다. 또한 텍스트 기반 메시지는 효율성 측면에서 제한이 있을 수 있다.
WebSocket은 초기 연결 이후에는 최소한의 오버헤드로 통신이 가능하다. 프레임 헤더는 매우 작고, 바이너리 데이터 전송이 효율적이다. 따라서 고성능 실시간 애플리케이션에 더 적합하다.
브라우저 호환성과 인프라 지원
SSE는 Internet Explorer를 제외한 대부분의 현대 브라우저에서 지원된다. HTTP 기반이므로 기존 프록시, 로드 밸런서, 방화벽 등과 호환성이 좋다.
WebSocket은 모든 현대 브라우저에서 지원되지만, 일부 네트워크 인프라(특히 오래된 프록시 서버)에서는 WebSocket 연결이 차단되거나 제대로 작동하지 않을 수 있다.
적합한 사용 사례
SSE에 적합한 사용 사례
- 실시간 업데이트 피드: 뉴스 피드, 소셜 미디어 타임라인, 주식 시세 등
- 공지사항과 알림: 사용자에게 전달해야 하는 시스템 알림, 이벤트 알림
- 대시보드 모니터링: 서버 상태, 시스템 성능, 트래픽 정보 등의 실시간 표시
- 이벤트 로그 스트리밍: 서버 로그, 사용자 활동 로그 등의 실시간 스트리밍
- 진행 상황 업데이트: 파일 업로드, 다운로드, 처리 작업 등의 진행 상황 표시
WebSocket에 적합한 사용 사례
- 채팅 애플리케이션: 실시간 메시징, 그룹 채팅, 화상 통화 등
- 멀티플레이어 게임: 실시간 게임 상태 동기화, 플레이어 간 상호작용
- 협업 도구: 실시간 문서 편집, 화이트보드, 프레젠테이션 등
- IoT 장치 제어: 장치 상태 모니터링 및 실시간 제어
- 트레이딩 플랫폼: 실시간 주문, 거래 실행, 시장 데이터 업데이트
- 라이브 스트리밍: 낮은 지연 시간이 필요한 미디어 스트리밍
하이브리드 접근법
많은 현대적인 웹 애플리케이션은 SSE와 WebSocket을 상황에 따라 적절히 조합하여 사용한다:
- 리소스 효율성: SSE는 서버에서 클라이언트로의 단방향 통신만 필요한 경우에 사용하고, WebSocket은 양방향 통신이 필요한 기능에만 사용
- 점진적 향상: SSE를 기본으로 구현하고, WebSocket을 지원하는 환경에서는 WebSocket으로 업그레이드
- 기능별 선택: 알림과 업데이트는 SSE로, 채팅과 실시간 상호작용은 WebSocket으로 구현
구현 시 고려사항
SSE 구현 시 고려사항
- 연결 제한: 브라우저당 도메인별 HTTP 연결 수 제한을 고려해야 함
- 메시지 크기: 대용량 데이터 전송 시 성능 이슈가 발생할 수 있음
- IE 지원: Internet Explorer는 SSE를 지원하지 않으므로 폴리필이 필요
- 시간 초과 처리: 일부 프록시는 오랜 시간 유지되는 연결을 종료할 수 있음
- 확장성: 많은 수의 동시 연결 처리를 위한 서버 아키텍처 설계 필요
WebSocket 구현 시 고려사항
- 프록시 및 방화벽: 일부 네트워크 환경에서는 WebSocket 연결이 차단될 수 있음
- 인증 및 보안: 연결 수립 후에도 지속적인 인증 및 권한 검증 필요
- 상태 관리: 연결 상태를 모니터링하고 연결 끊김을 처리하는 로직 필요
- 메시지 형식: 구조화된 메시지 형식 및 프로토콜 설계 필요
- 확장성: 대규모 동시 연결을 처리하기 위한 서버 인프라 설계 필요
용어 정리
용어 | 설명 |
---|---|