💡 WebSocket -> STMOP -> Message Broker 순으로 진행됨

1. WebSocket

1-1. WebSocket이 뭘까

• 통신 프로토콜
• 실시간으로 상호작용하는 웹 서비스를 만드는 표준 기술
  • HTTP처럼 클라이언트가 요청을 보내지만, 한 번 요청을 받으면 연결된 커넥션이 끊어지지 않음
  • HTTP 전송 메커니즘을 사용해서 클라이언트 요청을 시작, 이후 TCP 연결을 웹 소켓 연결로 사용
  • 연결이 유지된 상태로 통신을 이어갈 수 있음
  • 클라이언트를 기다리지 않고 서버가 데이터를 보낼 수 있음
• TCP 위에서 동작
• Full-dulpex 방식

1-2. WebSocket은 왜 사용할까

• 실시간 데이터를 다뤄야 하는 어플리케이션에서 선호

  • 동적 데이터를 활용한 지속적이고 빈번한 업데이트가 이뤄질 때 사용함 Ex) SNS에서 여러 사용자와 연결을 유지하며 지속적인 업데이트를 제공해야 할 때
    

• 기존에는 클라이언트가 HTTP 요청을 보내고, 웹 서버가 응답을 보내는 단방향 메시지 교환 방식을 사용

  • 상호작용하는 웹 페이지를 만들기 위해서는 복잡한 코드로 구현
  • 이를 해결하기 위해 양방향 메시지 교환이 가능한 웹 소켓 등장!

• 웹 소켓의 등장 이전엔 Polling, LongPolling 등의 방식으로 실시간인척 하는 방식이 있었음

  • Polling: 일정 간격으로 서버에 요청을 보내서 응답을 받는 방식
    • 서버의 부담이 증가하고, 요청을 보내는 간격이 길어지면 실시간이 아니게 된다.
  • Long Polling: 클라이언트의 요청에 바로 응답하지 않고 이벤트 발생 시까지 대기한다.
    • 클라이언트는 타임아웃 혹은 응답이 올 때까지 대기하고, 이벤트가 발생하면 바로 다시 요청을 보냄
    • 데이터의 변경이 빈번하면 요청도 자주 일어나므로 일반 Polling 방식과 차이점이 없음

1-3. HTTP와 차이점

• HTTP와 웹 소켓 둘 다 커뮤니케이션 프로토콜

• HTTP에선 클라이언트의 요청이 있으면 응답을 준 후, 커넥션을 닫는다.

  • Half-duplex: 양방향 통신이지만 한 번에 하나의 전송만 이뤄지며, 송수신이 동시에 되지 않음
  • Long Polling 등 업그레이드 버전이 있음

• 웹 소켓은 연결을 끊기 전까지 계속해서 커넥션을 유지하며 정보를 보내준다.

  • Full-duplex: 양방향 통신이며 동시에 송수신을 할 수 있음

• HTTP

  • half-duplex
  • uni-directional messaging
  • 매번 클라이언트의 요청으로 시작
  • 한 번의 요청-응답 주고 받기 후 연결 끊김

• 웹 소켓

  • full-duplex
  • bi-directional messaging
  • 서버와 클라이언트 모두 데이터 보내기 가능
  • 끊기 전까지 계속해서 유지

2. STOMP

2-1. STOMP가 뭘까

• Simple Text Orientated Messaging Protocol의 약자
• 웹 소켓 위에서 사용됨(TCP - HTTP 관계로 주로 비교됨)
• 중개 서버를 통한 클라이언트간에 비동기적 메시지 전송을 위한 프로토콜
• 텍스트 기반의 메시지 형식을 사용
• HTTP를 모델로 한 프레임 기반의 프로토콜

  # frame 구조
  
  COMMAND
  header1:value1
  header2:value2
  
  Body^@

  • header와 body는 선택사항
• subscribe 와 publish 를 기반으로 동작
  • SUB : 하나의 채널을 클라이언트가 구독
  • PUB : 하나의 채널을 구독 중인 모든 클라이언트에게 메시지를 발행
• STOMP 서버
  • 메시지가 전송될 수 있는 여러 목적지(채널)으로 구성
  • 각 목적지는 형식이 정해져있지 않은 문자열
  • 메시지 전송 전략을 따로 정의하지 않고, 서버와 목적지 별로 달라질 수 있음
• STOMP 클라이언트
  • 생산자로서 SEND 프레임을 통해 서버에게 메시지를 보냄
  • 소비자로서 SUBSCRIBE 프레임을 사용해 특정 목적지에 메시지를 보내고, MESSAGE 로 프레임을 받음

3. Message Broker

💡 왜 갑자기 메시지 브로커?
→ STOMP는 다양한 외부 메시지 브로커를 붙일 수 있다는 장점이 있다..! 하는 김에 한 번 같이 알아보자

3-1. Message Broker?

• 메시지 브로커는 애플리케이션, 시스템 및 서비스가 서로 간에 통신하고 정보를 교환할 수 있도록 해주는 SW

  • 정규 메시징 프로토콜 간에 메시지를 변환함으로써 수행
  • 상호 의존적인 서비스들이 서로 다른 언어나 플랫폼으로 개발된 경우에도 통신이 가능해짐

• 메시징 미들웨어 또는 메시지 지향 미들웨어(MOM) 솔루션 내의 SW 모듈

  • 애플리케이션 컴포넌트 간에 데이터 흐름을 처리하는 표준화된 수단을 제공
  • 여러 플랫폼에서 개발된 애플리케이션이 내부적으로 통신할 수 있도록 해주는 분산 통신 계층 역할 수행

• 메시지를 검증, 저장, 라우팅하고 이를 적절한 대상에 전달할 수 있음

  • 다른 애플리케이션 간의 중개자 역할
  • 수신자의 구체적인 상태를 몰라도 송신자가 메시지를 발행할 수 있도록 도와줌

• 메시지 큐를 이용함

  • 데이터의 패킷을 순서대로 저장해 소비될 때까지 갖고있음
  • 데이터 손실을 방지하고 연결에 장애가 발생해도 시스템이 계속 동작할 수 있도록 도움

3-2. Message Broker Model

• Point-to-Point 메시징
  • 송신자와 수신자 간에 일대일 관계를 지닌 메시지 큐에서 사용되는 패턴
  • 각 메시지는 하나의 수신자에게만 전송, 한 번만 이용됨
  • 메시지가 한 번만 전달돼야 하는 경우에 사용됨
• Publish/Subscribe 메시징
  • 메시지의 생성자는 토픽에 발행, 메시지 이용자는 수신하고자 하는 토픽을 구독
  • 발행된 모든 메시지는 해당되는 토픽을 구독한 모든 이용자에게 전달됨
  • 브로드캐스트 방식

3-3. Message Broker VS API

• REST API가 보통 커뮤니케이션에 자주 사용되는데, REST API는 HTTP를 통해 통신함
  • HTTP는 응답-요청 방식을 사용하기 때문에 동기식 통신에 더 유용함
  • 소비자가 메시지를 받을 수 없는 상황에서 발행자는 계속해서 기다려야 함
• 메시지 브로커는 수신 서비스의 응답을 기달 필요가 없이 서비스 간의 비동기 통신이 가능

---

참고

• WebSocket과 Socket.io
• 웹소켓
• Websocket vs HTTP: 6 Unique Differences & Use Cases
• 메시지 브로커란?
• Message Queues: An Introduction | IBM