Websocket vs STOMP

박태정·2025년 3월 18일

웹소켓

목록 보기
5/8

웹소켓의 발전된 형태가 STOMP

-> Websocket 위에서 동작하는 메시징 프로토콜

일반 Websocket

메시지가 서버에 들어오면 서버는 웹소켓으로 연결된 클라이언트 모든 대상들에게 메시지를 전부 다 송신해주는 방식이다.

그룹화된 채팅 A-B, A-B-C, B-C, C-D 이런식으로 그룹화된 상황에서 메시지를 모두 전송하려고 하면 일반적인 websocket으로 구현하기에는 매우 복잡해서 한계가 존재한다.

이러한 작업을 위해 STOMP라고 하는 고급화된 웹소켓 위에서 동작하는 기술이 나오게된다.

STOMP

간단한 예시를 들어서 설명

  • 클라이언트 1이 카톡처럼 여러 채팅방 중에 room1 이라는 채팅방에 접속을 한다고 하면 room1을 구독을 한다. 이 구독을 한다는 것을 서버에 알린다.

  • 서버는 room1번에 들어오는 메시지는 클라이언트 1번한테 줘야겠다 라고 구분지어서 사용자들을 구분지어서 그룹화 하는데 이 작업을 브로커라는 요소가 대신해준다.

  • 웹서버에서는 클라이언트를 직접 연결을 지어줬어야한다면 STOMP에는 브로커라는 개념이 있어서 클라이언트가 room1 구독할래 라고만 알려주면 브로커가 알아서 room1에 전부 다 매칭을 시켜준다.

  • 클라이언트 1과 클라이언트 2가 room1을 구독하고 있다고 할 때 클라이언트 1이 room1에 메시지를 송신하면 브로커가 메시지가 들어옴을 인식을 하고 room1에 들어와 있는 참여자들을 파악후 클라이언트 1과 클라이언트2한테만 메시지를 전달해준다. 즉, 그룹화 되어있는 클라이언트들한테 메시지를 전송하게 된다.

  • 즉, Websocket은 서버가 클라이언트한테 직접 메시지를 전달을 했다면 STOMP는 브로커가 클라이언트가 속한 그룹에 메시지를 전달을 한다.
  • Websocket + broker = STOMP
  • STOMP는 목적지 기반 메시지 라우팅 지원
    - 클라이언트와 서버가 특정 주제(topic) -> 여기서는 room으로 설명하고 있다. 메시지를 교환하는 구조

  • 메시지 교환 절차
    - 클라이언트에서 지정된 특정 room에 메시지를 발행하면 broker에 의해서 해당 room채널에 메시지가 전달
    - 동시에 room을 구독하고 있는 클라이언트에게 실시간으로 메시지가 전달된다.

  • redis pub/sub을 통해 멀티서버 환경 고려한다.

클라이언트1 는 A서버, 클라이언트2는 C서버에 있다고 가정
1. 클라이언트1이 A서버에 클라이언트2에 메시지를 전달해달라고 요청

2. A서버는 본인이 판단하지 않고 redis에 publish를 '클라이언트2에 메시지를 전달해달라고 요청'을 전달

3. redis에 subscribe를 하고 있는 모든 서버에 이 내용을 전달

4. 3개의 서버는 각자 판단을 한다 내 서버가 클라이언트2 한테 메시지를 보낼 수 있는지 확인 C서버가 가능하다고 판단 후 전송

웹소켓 통신 환경에서의 멀티 서버 문제점 및 해결 방안

  • 웹소켓 통신에서 특정 사용자는 특정 서버의 메모리에 의존적이어서, 클라이언트 A가 발행한 메시지를 클라이언트 B는 다른 서버에 연결되어 받지 못할 수 있다.

  • 이러한 멀티 서버 환경에서 원활한 채팅을 위해서 메시지를 서버에 모두 전파해주는 redis pub/sub 기능 사용

메시지 발행, 구독 절차

  • 클라이언트는 송신할 메시지를 Websocket server에 송신

  • Websocket server는 해당 메시지를 곧바로 특정 topic에 메시지를 발행하지 않고, redis의 pub/sub 기능을 활용하여 메시지를 모든 서버에 publish

  • 모든 서버는 redissubscribe하고 있기에 redis로 부터 발행된 message를 받아서, 본인 서버의 topic에 메시지를 발행

  • 각 서버를 subscribe하고 있는 클라이언트들은 특정 room에 전파된 message를 수신

0개의 댓글