A1BnB의 게스트들이 게시물 상세 페이지에 접근할 때 메시지 버튼을 누르면 호스트와의 실시간 채팅을 할 수 있도록 구현하고자 한다. 실시간 채팅을 구현하기 위해서는 기존의 HTTP 프로토콜이 아닌 다른 방식의 프로토콜을 이용한다는 사실을 검색을 통해 알게 되었는데, 이번 포스팅은 WebSocket을 통해 구현해보려 한다.
WebSocket
WebSocket은 기존의 단방향 HTTP 프로토콜과 호환되어 양방향 통신을 제공하기 위해 개발된 프로토콜이다.
특징
- 실시간 양방향 통신: WebSocket은 클라이언트와 서버가 지속적으로 연결되어 있어 실시간으로 데이터를 주고 받을 수 있음
- 낮은 지연시간: HTTP 프로토콜의 요청-응답 방식에 비해 지연시간이 매우 낮음
- 효율적인 데이터 전송: HTTP 헤더 정보가 필요 없어 데이터 전송이 효율적임
동작 과정
앞서 WebSocket은 클라이언트와 서버가 지속적으로 연결되어 있어 양방향 통신이 가능하다 했는데 어떻게 통신이 이뤄지는지 동작과정을 알아보자.
1. 클라이언트 WebSocket 연결 요청
- 클라이언트가 HTTP 프로토콜을 사용하여 서버에 WebSocket 연결을 요청
- 이때 클라이언트는 HTTP 헤더에 "Upgrade: websocket" 을 포함하여 WebSocket 프로토콜로의 전환을 요청
2. 서버 WebSocket 연결 승인
- 서버는 클라이언트의 WebSocket 연결 요청을 확인하고, HTTP 상태 코드 101(Switching Protocols)을 응답
- 서버 또한 "Upgrade: websocket" 헤더를 포함하여 WebSocket 프로토콜로의 전환을 승인
3. WebSocket 프로토콜 전환
- 클라이언트와 서버는 HTTP 프로토콜에서 WebSocket 프로토콜로 전환
- 이후 클라이언트와 서버는 WebSocket 프로토콜을 통해 실시간으로 데이터를 주고받음
STOMP
WebSocket은 텍스트 데이터를 교환한다는 것 외에 어떠한 형식도 존재하지 않기 때문에 클라이언트와 데이터를 교환하는데에 한계가 있다. 따라서 메시징 방식에 하나의 통신 규약을 얹게 되었는데, 그것이 STOMP이다.
STOMP(Simple Text Oriented Messaging Protocol)는 WebSocket 연결을 기반으로 하여 메시징 구조를 제공한다. STOMP를 사용하면 메시지 헤더, 바디, 명령어 등 규격화된 메시지 형식을 사용할 수 있어 보다 효율적인 메시지 전송이 가능하다.
동작 원리
메시징 모델
STOMP는 Publish-Subscribe(Pub/Sub) 메시징 모델을 사용한다. Pub/Sub는 메시지를 공급하는 객체(Publisher) 와 소비하는 객체(Subscriber)를 의미하며, Publisher가 특정 Topic에 메시지를 보내면 해당 topic을 구독한 모든 Subscriber 에게 메시지가 전송되는 방식이다.
프레임 구조
STOMP 프로토콜은 텍스트 기반의 프레임 구조를 사용하며, 프레임은
명령어, 헤더, 본문으로 구성된다.
- 명령어: SEND, SUBSCRIBE, UNSUBSCRIBE 등
- 헤더: 대상(Destination), 메시지 ID, 구독 ID 등의 정보 포함
- 본문: 실제 메시지 내용 포함
메시지 전송 과정
- 발행자는 SEND 명령어를 통해 메시지를 특정 대상에 게시
- 구독자는 SUBSCRIBE 명령어를 사용하여 관심 있는 대상 구독
- 메시지 브로커는 발행된 메시지를 구독자에게 전달
- 구독자는 수신한 메시지 처리
메시지 브로커
STOMP 프로토콜은 메시지 브로커와 함께 사용되며, 메시지 브로커는 발행자가 보낸 메시지를 구독자에 전달하는 역할을 수행한다.
- STOMP 메시지 브로커로는 RabbitMQ, ActiveMQ, Apache Kafka 등이 많이 사용된다.
- Spring에서는 In Memory Brocker인
Simple Message Broker를 제공한다.
