SSE(Server-Sent Events)는 서버에서 클라이언트로 실시간 데이터를 일방적으로 전송할 수 있는 HTTP 기반의 통신 방식입니다. 클라이언트는 서버와 연결을 유지하면서, 서버로부터 지속적으로 데이터를 받아오는 구조입니다
1. SSE 란?
- 단방향 통신: 서버에서 클라이언트로 데이터를 전송하는 단방향 스트리밍 방식입니다. 서버는 지속적으로 데이터를 전송할 수 있지만, 클라이언트는 별도의 요청을 보내지 않습니다.
- 자동 재연결: 클라이언트는 연결이 끊어지면 자동으로 다시 서버에 연결을 시도합니다.
- 이벤트 스트림 형식: 서버는 텍스트 기반의 데이터를 특정 형식(
data,event,id)으로 클라이언트에 전송합니다. - HTTP 프로토콜 사용: HTTP 프로토콜을 사용하기 때문에 방화벽이나 프록시 서버와 호환성이 높습니다.(XHR 스트리밍을 사용)
- 브라우저 지원: 대부분의 최신 브라우저에서 SSE를 지원하지만, 특정 구형 브라우저에서는 지원하지 않을 수 있습니다.
2. vs Websocket
- WebSockets는 장치의 TCP/IP 프로토콜인 전송 계층에서 동작합니다. (WebSockets do not use
XMLHttpRequest) - 서버와 브라우저 간에 양방향(full-duplex),저지연(low-latency), 이벤트 기반 연결(event-driven conenctions)을 제공합니다.
- 양방향(two-way) 연결을 제공
- Socket.IO를 사용해서 HTTP로 대체 가능합니다.
- 재연결에 대한 내장 지원 없음: WebSocket 연결이 끊어지면(예: 네트워크 문제로 인한 경우) 클라이언트는 서버에 재연결을 시도하지 않으므로, 서버를 폴링하고 연결이 가능해지면 다시 연결하는 추가 코드를 작성해야 합니다.
3. XHR과 XHR 스트리밍과 SSE
XHR(XMLHttpRequest) 스트리밍은 HTTP 연결을 장시간 유지하며, 주로 요청-응답(Request-Response) 기반으로 동작합니다. 일반적인 XHR 요청은 서버에 요청을 보내면 서버가 모든 데이터를 한 번에 응답하는 방식으로 동작합니다. 그러나 XHR 스트리밍에서는 서버가 데이터를 즉시 보내기보다는, 부분적으로 데이터를 전송하면서 연결을 유지하고, 클라이언트는 그 데이터를 계속해서 수신할 수 있습니다.
3-1. 일반적인 XHR 요청과 XHR 스트리밍의 차이점
- 일반적인 XHR 요청은 서버로부터 모든 응답이 완료될 때까지 기다렸다가 한 번에 데이터를 수신합니다. 서버에서 데이터를 처리한 후 전체 응답이 준비되면 이를 한 번에 클라이언트에 보내고 그 시점에서 연결이 종료됩니다. 이 과정에서 클라이언트는 모든 응답 데이터를 메모리에 버퍼링한 후 이를 처리합니다.
- XHR 스트리밍은 서버가 데이터를 즉시 전송하지 않고, 연결을 열어둔 상태에서 조금씩 전송합니다. 즉, 서버는 클라이언트에 필요한 데이터를 실시간으로 나눠서 보내고, 클라이언트는 그 데이터를 수신하면서 바로 처리할 수 있습니다. 이 방식은 장시간 연결을 유지하기 때문에 지속적인 데이터 전송이 필요한 경우 적합합니다.
3-2. SSE(Server-Sent Events)와 XHR 스트리밍의 차이점
SSE는 XHR 스트리밍과 비슷한 방식으로 장시간 연결을 유지하면서 데이터를 지속적으로 받는 방식입니다. 하지만 SSE는 XHR 스트리밍보다 더 효율적이고, 클라이언트 쪽에서 메모리 관리가 더 용이하게 설계되어 있습니다.
- XHR 스트리밍은 서버가 보내는 모든 데이터를 클라이언트가 메모리에 버퍼링하며, 그 데이터를 모두 받기 전까지 클라이언트 메모리에서 삭제되지 않습니다. 서버와의 연결이 끊어지면 그동안 받은 데이터를 클라이언트가 한꺼번에 처리할 수 있습니다. 즉, 데이터를 계속 쌓아 두기 때문에 메모리 사용량이 증가할 수 있습니다.
- SSE(Server-Sent Events)는 데이터를 이벤트 단위로 실시간 처리하는 방식입니다. 클라이언트는 서버로부터 데이터를 수신할 때마다 해당 데이터를 처리한 후, 더 이상 필요하지 않은 데이터는 메모리에서 즉시 삭제할 수 있습니다. 덕분에 XHR 스트리밍과 비교했을 때, SSE는 메모리 사용량이 적고 효율적입니다.
4. WebSocket, XHR, SSE 차이점
| 특징 | WebSocket | XHR (XMLHttpRequest) | SSE (Server-Sent Events) |
|---|---|---|---|
| 통신 방식 | 양방향 (Full-duplex) | 주로 요청-응답 (Request-Response) | 단방향 (서버 -> 클라이언트) |
| 연결 유지 | 지속적인 연결 | 요청 시마다 새로운 연결 | 지속적인 연결 (HTTP 기반) |
| 사용 사례 | 채팅, 실시간 게임, 협업 도구 등 실시간 상호작용이 필요한 경우 | 간헐적 데이터 요청 또는 파일 업로드/다운로드 | 실시간 뉴스, 주식 시세, 알림 등 일방향 데이터 스트림 |
| 데이터 전송 | 텍스트 및 이진 데이터 (UTF-8, Binary) | 텍스트 또는 바이너리 데이터 | 텍스트 데이터 (UTF-8만 지원) |
| 프로토콜 | ws:// 또는 wss:// | HTTP/HTTPS | HTTP/HTTPS |
| 지연 시간 | 매우 낮음 | 요청마다 대기 시간 발생 가능 | 낮음 (연결 후 데이터는 즉시 푸시됨) |
| 이벤트 기반 | 이벤트 기반 (양방향 모두 가능) | 요청 후 응답 시 처리 | 이벤트 기반 (서버가 이벤트 푸시) |
| 재연결 지원 | 클라이언트 코드로 재연결 구현 필요 | 새로 요청하여 재연결 가능 | 기본적으로 자동 재연결 지원 |
| 방화벽 호환성 | 일부 기업용 방화벽에서 차단될 수 있음 | 대부분의 방화벽에서 문제 없음 | 방화벽에서 문제 없음 |
| 메모리 사용 | 메모리 사용량 적음 (데이터 처리 후 즉시 삭제 가능) | 요청마다 메모리에 데이터 축적 가능 | 메모리 사용 효율적 (처리된 데이터 즉시 삭제) |
| 브라우저 지원 | 모든 주요 브라우저에서 지원 | 모든 주요 브라우저에서 지원 | 모든 주요 브라우저에서 지원 |
| 복잡성 | 구현이 다소 복잡 (양방향 통신 처리 필요) | 구현이 간단하지만 폴링 등은 비효율적일 수 있음 | 구현이 비교적 간단 |
| 동시 연결 제한 | 제한 없음 (단, 서버 성능에 의존) | 요청마다 새로운 연결, 제약 없음 | 브라우저당 6개의 동시 연결 제한 |