SSE, WebSockets, 폴링 비교

WebSockets는 클라이언트와 서버 사이에 영구적인 TCP 연결을 설정합니다. 양쪽 모두 언제든지 메시지를 보낼 수 있으므로, WebSockets는 채팅 애플리케이션, 협업 문서 편집, 멀티플레이어 게임, 실시간 커서처럼 진정한 실시간 상호 작용이 필요한 통신에 적합합니다. 어느 한쪽이 명시적으로 연결을 닫을 때까지 연결이 유지됩니다.

SSE(서버 전송 이벤트)는 일반 HTTP 연결을 사용하며, 서버가 일련의 이벤트로 데이터를 클라이언트에 스트리밍합니다. 연결은 단방향이므로 서버만 데이터를 보냅니다. 클라이언트는 SSE 연결을 통해 메시지를 다시 보낼 수 없으며, 이를 위해 별도의 HTTP 요청을 보내야 합니다. SSE는 브라우저의 EventSource API를 통해 구현됩니다.

단기 폴링은 클라이언트가 일정한 간격(예: 5초마다)으로 HTTP 요청을 보내는 방식입니다. 요청 내용은 "업데이트가 있습니까?"와 같습니다. 서버는 현재 데이터로 즉시 응답합니다. 구현은 가장 간단하지만 가장 비효율적입니다. 새로운 내용이 없을 때도 클라이언트가 많은 요청을 보내기 때문입니다. 데이터가 매우 느리게 변경되는 경우에만 적합합니다.

롱 폴링은 단기 폴링을 개선한 방식입니다. 클라이언트가 요청을 보내면 서버는 새로운 데이터를 사용할 수 있을 때까지 연결을 열린 상태로 유지합니다. 새로운 데이터가 도착하면 서버가 응답하고, 클라이언트는 즉시 또 다른 요청을 보냅니다. 불필요한 응답은 줄어들지만, 각 응답마다 새로운 TCP 연결을 설정해야 하므로 SSE보다 여전히 오버헤드가 큽니다.

SSE는 서버에서 클라이언트로 데이터를 푸시할 때 WebSockets보다 몇 가지 실용적인 장점이 있습니다. 일반 HTTP를 통해 작동하므로 프로토콜 업그레이드가 필요하지 않고, 특별한 설정 없이도 기업용 프록시와 부하 분산기를 통과할 수 있습니다. EventSource에는 자동 재연결 기능이 내장되어 있습니다. 텍스트 기반 프로토콜이므로 브라우저의 네트워크 탭에서 쉽게 문제를 확인할 수 있습니다.

SSE에는 실제적인 한계가 있습니다. 텍스트만 사용할 수 있으므로 이진 데이터는 base64로 인코딩해야 하고, 단방향이므로 클라이언트가 데이터를 다시 푸시할 수 없습니다. 또한 HTTP/1.1에서는 도메인당 동시에 연결할 수 있는 EventSource 연결 수가 6개로 제한됩니다(HTTP/2에서는 하나의 연결을 통해 다중화하므로 이 제한이 사라집니다). 양방향 통신을 구현하려면 SSE와 함께 REST 호출을 사용해야 합니다.

SSE는 실시간 지표를 표시하는 실시간 대시보드, 새로운 알림을 푸시하는 알림 피드, 서버에서 실행되는 장기 작업의 진행률 표시줄, 실시간 소셜 미디어 피드, 주가 표시기, 메시지가 서버에서 클라이언트로만 흐르는 채팅 인터페이스에 적합합니다. 채팅 메시지는 별도로 POST해야 합니다. 이러한 경우는 모두 서버가 업데이트를 시작하는 시나리오입니다.

낮은 지연 시간의 양방향 통신이 필요할 때는 WebSockets가 필요합니다. 예를 들어 하나의 연결을 통해 양방향으로 메시지가 흐르는 실시간 채팅, Google Docs와 같은 협업 편집, 클라이언트 동작과 서버 업데이트가 빠르게 모두 발생하는 멀티플레이어 게임, 실시간 경매 및 거래 플랫폼이 이에 해당합니다. 양방향성은 구현의 복잡성을 감수할 만한 이유가 됩니다.

HTTP/2는 SSE의 활용 가능성을 크게 높입니다. 연결 다중화 덕분에 하나의 도메인에서 발생하는 모든 SSE 스트림이 하나의 TCP 연결을 공유하므로, 도메인별 연결 수 제한이 사라집니다. 서버가 HTTP/2를 지원한다면 여러 데이터 스트림을 동시에 사용하는 대시보드에서 SSE를 더욱 실용적으로 사용할 수 있습니다.

판단 기준은 다음과 같습니다. 낮은 지연 시간의 양방향 통신이 필요하면 → WebSockets를 사용합니다. 서버가 업데이트를 푸시하고 클라이언트는 읽기만 하면 → SSE를 사용합니다. 가끔 업데이트가 필요하고 단순성이 중요하면 → 폴링을 사용합니다. 서버 API가 이미 존재하고 SSE를 추가할 수 없으면 → 폴링을 사용합니다. 지연 시간 요구 사항을 충족하는 가장 단순한 해결책부터 시작합니다.

WebSocket 프레이밍은 초기 핸드셰이크 후 메시지마다 2~14바이트를 추가합니다. SSE는 연결마다 한 번 HTTP 헤더를 추가한 다음 줄바꿈으로 구분된 텍스트를 전송합니다. 단기 폴링은 폴링할 때마다 전체 HTTP 요청 및 응답 헤더를 포함합니다. 데이터 빈도가 높을 때는 오버헤드 측면에서 WebSockets가 유리합니다. 서버 푸시 빈도가 낮을 때는 SSE가 적절한 오버헤드로 더 단순한 해결책을 제공합니다.

SSE와 WebSockets의 핵심적인 방향 차이는 무엇입니까?

WebSockets: 양방향 영구 TCP 연결(채팅, 게임, 협업 편집). SSE: EventSource API를 통한 단방향 서버-클라이언트 HTTP 푸시(알림, 대시보드, 피드). 단기 폴링: 일정한 간격의 요청(가장 간단하지만 가장 비효율적). 롱 폴링: 데이터를 사용할 수 있을 때까지 서버가 응답을 유지(요청 횟수는 적지만 지연 시간이 큼). SSE의 장점: 프록시를 통과할 수 있고 자동으로 재연결됩니다. SSE의 한계: 텍스트만 지원하고 단방향이며 HTTP/1.1에서는 연결 수가 제한됩니다.