Spring - 웹소켓과 STOMP

 

Websocket

 

웹소켓은 하나의 TCP 연결을 공유하여 실시간 양방향 통신을 제공하는 기술이다.

텍스트 채팅 서비스에 주로 사용되며 화상 회의 서비스도 구현할 수 있으나, 화상 회의에는 주로 WebRTC 기술을 사용한다.

 

클라이언트는 서버에 소켓을 연결한 상태를 유지하여 언제든지 서버에서 보낸 데이터를 받을 준비를 하고 있다.

HTTP 통신은 지속적으로 데이터를 요청하는 폴링의 방식을 사용해야 하지만 웹소켓은 그럴 필요가 없다.

 

 

Websocket의 특징

• 기본 웹소켓은 낮은 수준의 프로토콜로 제공하는 기능이 제한적이라 구현 부담이 크다.
• 웹소켓 세션도 관리가 되지 않아 따로 관리를 해야 한다. -> 그래서 필요한 것이 STOMP
• 어느 한 쪽에서 연결 종료를 요청하거나 네트워크 문제가 발생하면 연결이 닫히고 통신이 종료된다.

 

STOMP (Simple Text Oriented Messaging Protocol)

 

메시징 시스템 간의 데이터를 교환하기 위한 텍스트 기반 프로토콜이다.

웹소켓 기반으로 동작하며 메시징 애플리케이션의 표준 프로토콜이다.

 

 

STOMP의 특징

• pub/sub 구조(pub/sub 역할은 동시에 수행할 수 있다.) 
  • publisher: 특정 토픽이나 큐에 메시지를 생성하고 발행한다.
  • subscriber:  특정 주제나 큐를 구독할 수 있다.
  • messagge broker: 발행된 메시지를 관리하고 구독자들에게 해당 주제의 메시지를 전달한다.
• 메시지 중심으로 읽기 편하고 단순하다
• 메시지 브로커와 호환성이 좋다.

 

(Raw) Websocket vs. STOMP

 

Websocket?

• 별도의 메시징 프로토콜이 없어 클라이언트와 서버가 직접 데이터 포멧을 정의해야 한다.
• 특정 채널이나 주제를 구독하는 기능이 없다.
• 단순하지만 직접 구현해야 할 것이 많다.

STOMP?

• Frame 구조(COMMAND + Header + Body)의 메시지 포맷이 존재한다.
• 메시지를 주제 또는 큐에서 발행할 수 있다.
• SEND, SUBSCRIBE, UNSUBSCRIBE, CONNECT 등의 명령을 지원한다.
• RabbitMQ, ActiveMQ와 같은 메시지 브로커를 지원한다.

 

STOMP의 메시지 전달 과정

1. 클라이언트가 destination을 지정하여 서버로 메시지 전송
2. 서버로 메시지가 전달되면 ClientInboundChannel(Request Channel)을 통해 앱 내부로 전달
3. @MessageMapping(앱 핸들러) 메서드가 메시지 처리 후 결과를 반환
4. 애플리케이션이 @SendTo로 메시지를 반환하면 BrokerChannel(내부)를 통해 브로커로 전달
5. SimpleBroker or 외부 브로커가 메시지를 큐잉
6. ClientOutboundChannel(Response Channel)를 통해 클라이언트로 메시지 전송
7. 구독한 모든 클라이언트가 메시지 수신

 

* channel은 메시지가 흘러가는 통로이며 메시지를 pub/sub 구조로 라우팅해준다.

*큐잉은 큐(FIFO)를 사용하여 요청을 차례대로 저장하고 순서대로 처리하는 것을 말한다.

* SimpleBroker는 실제로 클라이언트 세션을 관리하고 전송한다. 

• Request Channel: 클라이언트 -> 앱 핸들러
• Broker Channel: 앱 핸들러 -> SimpleBroker
• Response Channel: Response Channel -> SimpleBroker -> 클라이언트

 

 

참고 자료|

https://brunch.co.kr/@springboot/695