[TIL]20240808 SSE와 웹소켓 비교

아티클에 대한 요구사항을 받았을 때 웹소켓에 대해 공부하면서 SSE에 대한 내용도 있었는데, 웹소켓에 머리가 어질어질해서 다음에 알아봐야지 했던 SSE. 사실 실시간 뉴스 피드는 알림같은 느낌이라 꼭 웹소켓이어야 할까? 라는 생각이 들긴 했지만 아직 GPT가 없으면 코드를 작성하는데 어려움을 겪는 나에게는 GPT의 추천을 따를 수 밖에..! 팀이 흩어지게되서 결국 그 기능을 구현해 볼 기회는 없었지만 알아 둘 필요를 느껴서 개발일지의 소재로 정했다. 

Server-Sent Events(SSE)는 웹 애플리케이션에서 서버가 클라이언트에게 실시간으로 데이터를 전송할 수 있게 해주는 기술이다. SSE는 단방향 통신 방식으로, 서버에서 클라이언트로만 데이터를 보낼 수 있고, HTML5에서 제공하는 표준 기술이다. SSE는 웹소켓(WebSocket)과 함께 실시간 웹 애플리케이션 구현에 자주 사용되며, 각기 다른 장단점을 가지고 있다. 이번 개발일지에서는 SSE의 개념과 동작 방식, 웹소켓과의 비교, 그리고 간단한 코드 예시를 통해 정리해보았다! 

🤓Server-Sent Events(SSE)란 ?

Server-Sent Events(SSE)는 클라이언트가 서버와의 연결을 지속적으로 유지하면서 서버에서 데이터를 수신할 수 있는 웹 표준 기술이다. SSE는 서버가 클라이언트에게 비동기적으로 여러 번의 업데이트를 보낼 수 있도록 하고, 클라이언트는 수신한 데이터를 사용해 웹 페이지를 실시간으로 업데이트할 수 있다. 이 방식은 주로 주식 시세나 뉴스 피드와 같은 실시간 데이터를 클라이언트에게 전달할 때 사용된다.

 

▶SSE의 주요 특징

→ 단방향 통신:

SSE는 서버에서 클라이언트로의 단방향 데이터 전송만 지원한다. 서버는 데이터를 푸시(push)할 수 있지만, 클라이언트는 서버로 데이터를 보낼 수 없다.

→ 자동 재연결:

SSE는 클라이언트와의 연결이 끊어졌을 때 자동으로 재연결을 시도한다. 이를 통해 네트워크 장애나 서버 재시작 등으로 인한 데이터 손실을 최소화할 수 있다.

→ 텍스트 기반 전송:

SSE는 데이터를 텍스트 형식으로 전송한다. 서버는 클라이언트에게 단순한 텍스트 메시지를 보낼 수 있으며, 클라이언트는 이를 수신하고 처리할 수 있다.

→ 브라우저 지원:

SSE는 대부분의 최신 웹 브라우저에서 지원된다. 이는 클라이언트 측의 설정이나 추가적인 라이브러리 설치 없이 사용할 수 있음을 의미한다.

 

▶SSE와 웹소켓(WebSocket)의 비교

SSE와 웹소켓 모두 서버와 클라이언트 간의 실시간 데이터 전송을 지원하지만, 각각의 특성과 사용 용도가 다르다.

▽ SSE(Server-Sent Events) & WebSocket

통신 방식	단방향 (서버 -> 클라이언트)	양방향 (서버 <-> 클라이언트)
프로토콜	HTTP	TCP (ws:// 또는 wss://)
연결 유지	HTTP 지속 연결	WebSocket 프로토콜 기반 지속 연결
브라우저 지원	대부분의 최신 브라우저에서 지원	대부분의 최신 브라우저에서 지원
전송 형식	텍스트 기반	바이너리 및 텍스트 모두 지원
재연결 지원	기본 제공	클라이언트 측에서 구현 필요
사용 사례	뉴스 피드, 실시간 알림 등	채팅 애플리케이션, 게임, 실시간 협업 도구 등

→ SSE는 단방향 통신이므로 서버가 클라이언트에게 알림, 뉴스 피드 등의 데이터를 실시간으로 전달할 때 적합하다. HTTP 프로토콜을 사용하기 때문에 방화벽이나 프록시 서버와의 호환성이 뛰어나다.

→ 웹소켓은 양방향 통신을 지원하여 서버와 클라이언트 간의 상호작용이 필요한 채팅 애플리케이션, 실시간 게임, 협업 도구 등에서 더 유용하다. 그러나 TCP 기반의 WebSocket 프로토콜을 사용하므로, 방화벽 설정이 필요할 수 있다.

 

▶ SSE 구현 예시

아래는 Spring Boot를 사용해 SSE를 구현하는 간단한 예시이다. 서버에서 클라이언트에게 실시간으로 "Hello SSE" 메시지를 5초마다 보내는 기능을 구현한 예시!  ( 클라이언트 측 코드는 봐도 모르겠어서 패스!)

▽ 서버 측 예시 코드 (Spring Boot)

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.http.MediaType;
import java.time.LocalTime;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.Flow.Publisher;
import reactor.core.publisher.Flux;

@RestController
public class SseController {

    // 클라이언트가 /sse 요청 시 서버에서 데이터를 전송하는 엔드포인트
    @GetMapping(value = "/sse", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
    public Flux<String> streamEvents() {
        // 5초마다 "Hello SSE" 메시지를 전송하는 Flux 생성
        return Flux.interval(Duration.ofSeconds(5))
                .map(sequence -> "Hello SSE at " + LocalTime.now());
    }
}

 

→ @RestController와 @GetMapping 애너테이션을 사용하여 RESTful 엔드포인트를 정의하였다.

/sse 엔드포인트는 MediaType.TEXT_EVENT_STREAM_VALUE를 사용해 클라이언트에 텍스트 이벤트 스트림(SSE) 형식으로 데이터를 전송한다.

→ Flux.interval() 메서드는 5초마다 "Hello SSE" 메시지를 전송하도록 구성된다

 

▶SSE 사용 시 주의사항

→ 브라우저 호환성:

대부분의 최신 브라우저에서 SSE를 지원하지만, 구형 브라우저에서는 작동하지 않을 수 있다. 사용하기 전에 브라우저 호환성을 확인하는 것이 중요하다.

→ 연결 유지 비용:

클라이언트와 서버 간의 연결을 지속적으로 유지하므로, 많은 수의 클라이언트가 연결되면 서버의 리소스가 많이 사용될 수 있다. 서버의 성능과 네트워크 상태를 모니터링하고, 필요에 따라 서버 자원을 적절히 분배해야 한다.

→ 보안 문제:

SSE는 기본적으로 클라이언트-서버 간의 텍스트 전송이기 때문에, 보안 설정을 통해 데이터의 기밀성을 보호해야 한다. HTTPS 프로토콜을 사용하여 데이터 전송을 암호화하고, 클라이언트 측에서 데이터 검증을 수행해야 한다.

 

▶정리

 SSE의 개념과 동작 방식, 웹소켓과의 비교를 하면서, SSE로 했어도 괜찮지 않았을까?란 생각이 들었다. SSE는 서버에서 클라이언트로 데이터를 푸시하는데 적합한 기술이지만, 단방향 통신만 가능하다는 한계가 있다. 이러한 한계 때문에 웹소켓과 혼동할 수 있지만, 웹소켓은 양방향 통신을 지원하고 SSE는 단방향이라는 점에서 차이가 있다. SSE를 처음 구현한다면 HTTP 기반의 지속적인 연결 유지와 데이터 푸시 방식에 대해 익히는 것이 쉽지 않을거다. 특히, 서버와 클라이언트 간의 연결 상태 관리와 효율적인 데이터 전송에 대해 이해하는게 많이 어려워서 느린 이해력을 가진 나는 구현하는데 한참걸리지 않을까 싶다😢