Spring boot 채팅 구현 #2 Web Socket, STOMP, Message Broker 개념 정리

 

 

1편에서 나왔던 Polling의 단점을 보완하기 위해 Web Socket이 등장한다.

 

Web Socket

 

역사

 

2008년 Web Socket은 TCP 기반 소켓 API를 대체할 목적으로, HTML5에서 TCPConnection으로 처음 참조되며, 최초 버전의 프로토콜이 탄생되었다.

 

2009년 Web Sockets API는 W3C에 의해 표준화되었다.

 

https://www.w3.org/TR/2009/WD-websockets-20091222/

The Web Sockets API

 

2011년 Web Socket Protocol은 IETF에 의해 RFC 6455로 표준화되었다.

 

https://datatracker.ietf.org/doc/html/rfc6455

RFC 6455: The WebSocket Protocol

 

 

Web Socket의 특징

 

Web Socket은 OSI 7계층에 위치한 프로토콜이며, 4계층의 TCP에 의존하고 있다.

 

HTTP 프로토콜과 달리 전이중 통신 채널을 사용한다. 

 

즉, 클라이언트와 서버 사이에 소켓 커넥션을 유지하고 양방향 통신이 가능하다.

 

그렇기 때문에 매번 새로운 요청을 보내는 Polling 방식에 비해서 더 낮은 부하를 사용하여 통신이 가능해진다.

 

 

추가적인 특징

 

1. HTTP와 HTTPS와 통신이 가능한 HTTP 포트 80과 HTTPS 포트 443을 사용한다. 즉, HTTP와 호환이 가능하다.

 

2. 대부분의 브라우저에서 Web Socket 프로토콜을 지원한다.

 

 

그렇다면 Web Socket의 원리에 대해서 알아보자.

 

 

Web Socket의 원리

 

 

1. 클라이언트가 서버로 웹소켓을 연결하기 위한 HTTP 요청을 한다. (웹소켓 핸드쉐이크)

 

2. 서버는 101로 응답을 하게 되는데, 101은 Switching Protocols, 즉 프로토콜을 업그레이드한다는 것이며

    HTTP 프로토콜에서 Web Socket 프로토콜로 전환한다는 의미이다.

 

 

3. 소켓 커넥션이 연결되고, 양방향 통신이 가능해진다. 한쪽에서 채널을 닫으면 연결은 끊기게 된다.

 

 

하지만 이러한 웹소켓에도 단점이 존재했다.

 

HTTP 통신은 헤더를 사용해서, 데이터에 대한 규약과 정의, 인증 등에 대한 상세한 부가적인 정보를 전송하지만

 

웹소켓은 그와 달리 Low-Level 전송 프로토콜이라는 것. 

 

그래서 클라이언트와 서버가 미리 규약을 정해놓지 않고서는 데이터를 라우팅하기 힘들다는 단점이 존재한다.

 

 

STOMP

 

STOMP, Streaming Text Oriented Messaging Protocol는 순전히 메세징을 위해 탄생한 프로토콜이다.

 

메세지 기반 통신을 제공하고, 큐 및 토픽과 같은 메시징 패턴을 사용해서 데이터를 전송한다.

 

STOMP는 메시징 프로토콜이며, 기존 프로토콜 위에 구축된다. 즉, Web Socket과 같이 사용하면 된다.

 

Low-Level이라는 웹소켓의 단점을 보완할 수 있는 프로토콜로서, 메시지를 프레임(헤더, 바디)으로 구성하여 전송한다.

 

또한 1:N, N:1, N:N의 통신을 구축할 때, 효과적으로 사용 가능하다.

 

 

다양한 규약이 존재하지만, 대표적으로 메세지를 송신하고, 수신할 때의 인터페이스만 살펴보자.

 

 

SEND(메시지 발행 시)

 

send 프레임은 destination의 경로로 메세지를 발행한다.

 

 

SUBSCRIBE(메시지 구독 시)

 

subscribe 프레임은 destination의 경로로 구독한다는 의미이며, 구독된 목적지로 전송된 메세지는 메세지 프레임의 형태로 구독자에게 전송된다.

 

이때 싱글 커넥션에서 멀티플한 구독자를 가질 수 있기 때문에 구독자를 구분하기 위해 id를 포함해야 한다. 

 

 

공식문서

https://stomp.github.io/stomp-specification-1.2.html

https://stomp.github.io/stomp-specification-1.2.html

 

STOMP는 Pub/Sub 기반으로 동작하는데, 아래 그림으로 이해해보자.

 

 

Publisher, 발행, 메세지를 송신하는 쪽

 

Subscriber, 구독, 메세지를 수신하는 쪽

 

으로 나뉘어져 송수신 처리가 명확하다.

 

중간에서 서버가 메세지를 받아서 처리해주는 식이며, 클라이언트는 발행과 구독 역할을 둘 다 지킬 수 있다.

 

 

하지만 STOMP도 한계가 존재하는데, 웹소켓 서버가 다수가 될 경우,

 

채널 관리가 서버마다 독립적으로 이루어지게 되고, 각 웹소켓 서버마다 호환이 어려워진다는 것이다.

 

 

이 문제를 해결하기 위해서는,

 

각 서버에 접속 중인 클라이언트를 전부 파악하고, 각 클라이언트가 구독하고 있는 채널 정보를 공유해야 한다.

 

하지만 더 간단하게 해결할 수 있는 방법이 있는데, 그것이 바로 외부 Message Broker를 사용하는 것이다.

 

 

외부 Message Broker

 

 

아래 스프링 공식문서에 나오는 그림을 보자.

 

 

외부 Message Broker 적용 전

 

 

 

외부 Message Broker 적용 후

 

 

두 가지의 가장 큰 차이점은 STOMP TCP 통신을 통해 message가 외부 Message Broker까지 전달이 되고,

 

내부 Broker에서 구독 클라이언트로 메시지를 전송하기 위해 Broker Relay를 사용한다는 것이다.

 

이러한 프로세스를 통해 만약 웹소켓 서버가 여러 개 존재하더라도, 외부 Message Broker를 거쳐서

 

메세지가 전달이 되기 때문에, 정확한 라우팅으로 메세지 송수신이 가능해진다.

 

또한 외부 Message Broker는 Message Queing 방식을 통해 메세지를 처리한다.

 

 

Message Queing

 

Producer와 Consumer라는 용어가 사용된다.

 

Producer가 메시지를 큐에 보내고, 

 

Consumer가 큐에서 메시지를 꺼내서 처리하는 식으로 동작한다.

 

Message Queing은 비동기 방식으로 작동되며, 큐 자료구조이므로, FIFO 방식을 따르게 된다.

 

이를 통해 메시지 순서와 전달이 보장되게 된다.

 

또한 이러한 프로세스를 통해 작업을 하나씩 처리하게 되므로, 부하를 분산시킬 수 있다.

 

 

AMQP

 

앞에서 설명한 외부 Message Broker는 RabbitMQ, ActiveMQ(JMS) 등등이 있다.

 

그리고 모두 AMQP, Advanced Message Queuing Protocol 라는 프로토콜을 따른다.

 

대표적인 특징은 다음과 같다.

 

1. 메시지 지향

 

2. 큐잉

 

3. 라우팅

 

4. 신뢰성

 

5. 보안

 

그 외에도 Exchange, Queue, Exchange Types에 대한 이해가 필요한데,

 

그 부분은 다음 포스팅에서 다루도록 하겠다.