채팅과 관련된 기능을 구현할때 생겼던 고민들을 정리한 블로그 입니다.
1. 채팅은 항상 WebSocket으로 진행되어야 할까?
채팅은 웹 소켓으로 만진행되지 않아도 될 것입니다. 이유는 Polling같은 실시간성을 갖게 하는 방법을 추가하면 된다고 생각했습니다. 근본적으로 어떤 DataSource를 서버에 요청하게 되면 서버는 적절한 자원을 Client에게 전달해 줄 것입니다. 이러한 Feature를 근본으로 두면 꼭 WebSocket으로 하지 않아도 됩니다.
(1) Polling으로 해결할 수 있는 채팅의 장단점
장점으로서는 간편한 구현, 단점으로서는 주기가 짧으면 서버에 오버헤드 발생, 주기가 길다면 실시간성이 떨어짐. 명확한 장단점을 갖고 있습니다. 이를 해결하기 위해 LongPolling이라는 기법도 존재합니다.
(2) Long Polling
롱 폴링(Long Polling)은 웹 개발 및 네트워킹에서 클라이언트(일반적으로 웹 브라우저)와 서버 간의 실시간 통신을 모방하는 백엔드 기술이다. 이는 실시간 웹 애플리케이션에서 사용된다.
롱 폴링은 요청을 장기간 유지하여 새로운 데이터가 도착할 때까지 열린 상태로 두는 방식으로 통신 효율성을 개선한다. 서버는 클라이언트의 요청을 즉시 응답하지 않고, 새로운 정보가 있을 때까지 대기한다. 새로운 데이터가 준비되면 서버는 클라이언트에게 응답을 보내며, 클라이언트는 해당 데이터를 처리한 후 즉시 새로운 롱 폴링 요청을 보낸다.
이처럼 클라이언트와 서버 간의 연결을 장시간 유지하면 전체 요청 횟수가 줄어들어 네트워크 부담을 완화할 수 있다. 이러한 특성 덕분에 롱 폴링은 확장성이 뛰어나고 반응성이 높은 채팅 애플리케이션, 멀티플레이어 게임, 실시간 알림 시스템, 산업 자동화 솔루션 등에 적합한 기술 스택으로 활용된다.
(3) 롱 폴링의 작동 방식
롱 폴링은 서버가 새로운 데이터를 준비하는 즉시 클라이언트에 전달하는 푸시(Push) 기반 접근 방식이다. 이를 통해 클라이언트가 주기적으로 서버를 확인할 필요 없이 실시간 업데이트를 받을 수 있다.
(4) 롱 폴링의 동작 흐름
- 클라이언트가 서버에 HTTP 요청을 보낸다.
- 서버는 즉시 응답하지 않고 요청을 열린 상태로 유지하며 연결을 활성화된 상태로 둔다.
- 새로운 데이터가 없으면 서버는 대기 상태를 유지한다.
- 서버에 새로운 데이터가 생기거나 사전 정의된 타임아웃(timeout)이 발생하면, 서버는 최신 데이터를 포함한 응답을 클라이언트에게 보낸다.
- 클라이언트는 응답을 받으면 즉시 새로운 요청을 서버에 보내 연결을 지속한다.
- 이 과정이 반복되면서 실시간 업데이트가 이루어진다.
(5) 롱 폴링 vs 숏 폴링(Short Polling)
전통적인 HTTP 요청 방식에서는 클라이언트가 서버에 요청을 보내고 응답을 기다리는 숏 폴링(Short Polling) 기법이 사용된다. 그러나 숏 폴링은 실시간 처리에 적합하지 않다. 클라이언트가 일정 주기마다 서버에 요청을 보내기 때문에 불필요한 네트워크 부하와 높은 지연 시간(latency) 이 발생할 수 있다.
숏 폴링은 풀(Pull) 기반 접근 방식으로, 클라이언트가 주기적으로 서버에 업데이트를 요청하지만 데이터가 없을 경우 불필요한 요청이 반복되어 자원이 낭비된다. 반면 롱 폴링은 서버가 새로운 데이터를 준비하는 즉시 클라이언트에 전달하는 푸시(Push) 기반 접근 방식으로, 네트워크 효율성과 응답성을 높일 수 있다.
2. WebSocket을 통해서 채팅을 구현한다면
만약 WebSocket을 통해서 채팅이 이루어진다면 다음과 같은 것들을 고민할 수 있습니다. 만약 여러 채팅방에 있다면 어떻게 해결하지? 전체 채팅, 팀 채팅, 귓속말 등 다양한 Envet를 한개의 소켓통신으로 처리하는 시나리오를 상상할 수 있습니다. 이러한 이벤트를 처리 할 수 있고, 심지어는 서버는 이와 같은 문제를 해결할 수 있습니다.
근본적으로 돌아와서 그러면 어떻게 서버와 WebSocket으로 통신을 할까에 대해서 고민했습니다. Spring에서 문서를 읽다가 STOMP과 관련된 문서를 보았습니다. STOMP (Simple Text Oriented Messaging Protocol)은 메시지를 효율적으로 Server와 Client간에 소통하기 위한 프로토콜 입니다. (STOMP과 관련된 한국어 학습 자료를 찾으신다면 잘 정리된 블로그가 있습니다.)
STOMP 프로토콜 소개 사이트 입니다. https://stomp.github.io/stomp-specification-1.2.html
https://stomp.github.io/stomp-specification-1.2.html
STOMP Protocol Specification, Version 1.2 Abstract STOMP is a simple interoperable protocol designed for asynchronous message passing between clients via mediating servers. It defines a text based wire-format for messages passed between these clients and s
stomp.github.io
(1) 실제 구현체
실제 구현은 https://spring.io/guides/gs/messaging-stomp-websocket 이 예제 프로젝트를 구현했으며, Hello모델을 통신하는 과정을 구현했습니다. Git example도 잘 정리되어 있습니다.
(3) 장 단점
스프링에서 제공하는 STOMP관련 API는 쉽게 구현할 수 있다는 장점을 갖고 있었습니다. 또한 AMQP라이브러리를 통해서 여러개의 Broker를 만들 수 있다는 것도 장점 입니다. 단점은 소켓특성상, 채팅을 소켓에 연결되어야만 받을 수 있다는 것 입니다.
레퍼런스
https://docs.spring.io/spring-framework/reference/web/websocket/stomp/message-flow.html
https://docs.spring.io/spring-framework/reference/web/websocket/stomp.html
https://spring.io/guides/gs/messaging-stomp-websocket
https://medium.com/@kova98/long-polling-in-net-08caa91000cd