[개념정리] WebSocket 과 STOMP

이번 강의주차에서는 실시간 데이터 처리에 대한 내용을 다루다 보니 그에 필요한 WebSocket과 STOMP 의 개념 및 동작 방식 등을 알아갈 필요가 생겼다. 

 

WebSocket이란 ? 

: 서버와 클라이언트가 한 번 연결되면 끊지 않고 양방향으로 자유롭게 데이터를 주고받을 수 있는 프로토콜

 

웹소켓의 통신구조

: 클라이언트 → 서버로의 요청이 아니라, 클라이언트의 요청없이도 서버 → 클라이언트로 정보를 실시간으로 보낼 수 있다는 것

 

양방향 통신 구조에서는 HTTP 통신을 할 수 없기 때문에 별도의 프로토콜을 사용하게 되는데, http:// 가 아닌 ws://의 url을 가진 웹소켓 프로토콜을 사용하며 명시적으로는 해당 프로토콜을 사용하지는 않지만 내부적으로 사용하게 된다.

 

👉  양방향 통신 파헤쳐보기

1. 기존에 알고있던 방식 : 단방향 통신 (HTTP)

• 핵심 특징
  • 먼저 말을 걸 수 있는 건 오직 클라이언트뿐이고, 서버는 클라이언트가 물어보기 전까지는 절대 먼저 말을 걸 수 없음
  • 실시간으로 변하는 정보에 대해 그때그때마다 요청을 보내고 응답을 받아야하기 때문에 실시간 변동 데이터에는 부적합함

2. 새롭게 배울 방식 : 양방향 통신

• 핵심 특징
  • 연결 (Handshake) : 전화를 걸어 연결을 맺고
  • 유지 : 한번 연결되면 끊지않고 선을 계속 유지
  • 자유로운 대화 : 누가 먼저할 것 없이 서로 데이터를 보내고 싶을 때 언제든 보낼 수 있음

 

여기서 WS 프로토콜의 작동 원리는 아래와 같은데,

• 1단계 : 핸드셰이크 (HandShake)
  → 클라이언트가 서버에게 일반적인 HTTP 요청을 보내지만, 그 안에 특별한 헤더를 숨겨서 보내게 됨
• 2단계 : 프로토콜 전환 (Connection Open)
  → 1단계가 성공하면 http:// 연결에서 ws:// 연결로 바뀌게 되며 끊어지지 않고 계속 이어지게 됨
• 3단계 : 데이터 전송 (Data Frames)
  → HTTP의 복잡한 규칙을 버리고, 가벼운 메세지 형태로 데이터를 빠르게 주고 받음

여기서, HTTP라고 하여 실시간 채팅 구현을 하지 못하는 것은 아니지만 요청 시마다 새롭게 연결을 시도해야하고, 처리 후 연결을 끊는 불필요한 과정들이 반복되게 되며 성능 저하까지 초래하게 되기 때문이다.

 

TCP (Transmission Control Protocol) 란?

TCP의 3가지 특징

1. 신뢰성 (Reliability) : 데이터를 보내고 나서 상대방이 잘 받았는지 확인 도장(ACK)을 받고, 데이터가 도중에 유실되면 끝까지 책임지고 다시 보내주게 됨
2. 순서 보장 (Ordering) : 데이터 도착 순서가 뒤죽박죽이되는 경우가 발생할 수 있는데, TCP가 순서를 정리하여 애플리케이션에 전달하게 됨
3. 연결 지향 (Connection-oriented) : 데이터를 보내기 전에 준비상태를 확인하고 안되었다면 서로 합의하는 과정을 거치게 됨

이전에도 정리했던 TCP 개념과 특징을 다시 언급하게 된 것은 웹소켓이 TCP 위에서 작동하기 때문이며, 연결된 상태를 유지할 수 있는 부분과 순서가 뒤바뀌지 않고 정확하게 전달되는 것 또한 TCP가 가진 특징 덕분이라고 할 수 있다. 

 

Polling (HTTP 기반)

• Polling은 HTTP 기반으로 동작하는 연결 방식 중 하나
• 클라이언트가  서버에 주기적으로 요청을 보내 업데이트를 확인
• HTTP 요청만 처리하면 되므로 추가 설정이 필요없이 간결함
• 지속 요청에 따른 서버 과부하 가능성이 존재

폴링 기반 통신 방식 정리

1. 기본 폴링 (Short Polling) : "계속 물어보기"
   가장 원시적인 방법이며 일정 주기에 따라 계속 요청을 보내어 확인함
   • 장점 : 구현이 쉬움
   • 단점 :
     • 데이터가 없어도 확인요청을 보내어 낭비가 발생
     • 실시간성이 떨어짐 ( 정해진 주기에만 업데이트가 발생하므로 )
2. 롱 폴링 (Long Polling) : "기다렸다가 받아오기"
   기본 폴링의 단점을 보완하여 만든 방식
   • 장점 : 기본 폴링보다 불필요한 요청이 줄어들고, 실시간성이 좋아짐
   • 단점 : 데이터가 너무 자주 쏟아지느 상황에서는 연결의 맺고끊음이 반복되어 비효율적

 

WebSocket과의 차이

• 클라이언트 서버 간 지속적인 연결을 유지
• 연결 상태가 유지되기 때문에, 서버가 바로바로 메시지를 보낼 수 있고 클라이언트도 즉시 응답을 받을 수 있음
• 무거운 HTTP 메시지가 필요 없이 직접 메시지를 주고 받음으로서 서버 부하 측면에서 우수
  
  데이터가 자주 바뀌지 않는다면 Polling도 나쁘지 않은 선택이나, 실시간 채팅 또는 주식처럼 1초가 급하고 데이터가 쏟아지는 형태라면 WebSocket이 정답

---

STOMP란?

: Simple Text Oriented Messaging Protocol의 약자로, WebSocket 위에서 동작하는 메시징 프로토콜

 

WebSocket이 연결을 유지하며 데이터를 주고받는 통로라면, STOMP는 그 위에서 어떻게 메시지를 주고받을지 규칙을 정한 약속

 

STOMP 프레임의 구조 : 프레임 단위로 이루어지며 각 프레임은 명령(COMMAND), 헤더(HEADER), 바디(BODY)

 

STOMP - COMMAND

명령(COMMAND)	주체	설명
CONNECT	클라이언트 → 브로커	메시지 브로커에 연결을 요청합니다.
CONNECTED	브로커 → 클라이언트	연결 요청에 대한 성공 응답입니다.
SEND	클라이언트 → 브로커	특정 Destination으로 메시지를 전송합니다.
SUBSCRIBE	클라이언트 → 브로커	특정 Destination의 메시지를 구독합니다.
UNSUBSCRIBE	클라이언트 → 브로커	특정 Destination의 구독을 해지합니다.
MESSAGE	브로커 → 클라이언트	구독 중인 클라이언트에게 메시지를 전달합니다.
ACK	클라이언트 → 브로커	특정 메시지를 성공적으로 수신하고 처리했음을 브로커에게 알립니다. (수신 확인)
NACK	클라이언트 → 브로커	특정 메시지를 수신/처리하지 못했음을 브로커에게 알립니다. (수신 거부)
BEGIN	클라이언트 → 브로커	트랜잭션의 시작을 알립니다.
COMMIT	클라이언트 → 브로커	현재 트랜잭션 내의 모든 작업을 확정합니다.
ABORT	클라이언트 → 브로커	현재 트랜잭션을 취소하고 롤백합니다.
DISCONNECT	클라이언트 → 브로커	브로커와의 연결을 종료합니다.

 

STOMP - HEADER

헤더 키(HEADER KEY)	설명	사용되는 COMMAND 예시
destination	메시지가 향할 목적지 (토픽 또는 큐)를 지정합니다.	SEND, SUBSCRIBE, MESSAGE
content-type	BODY에 포함된 데이터의 MIME 타입을 명시합니다. (예: application/json, text/plain)	SEND, MESSAGE
id	구독 또는 트랜잭션을 식별하는 고유 ID입니다.	SUBSCRIBE, BEGIN
message-id	메시지 브로커가 생성하는 메시지의 고유 ID입니다.	MESSAGE, ACK, NACK
receipt	클라이언트가 이 프레임을 수신했음을 브로커에게 확인받기 위해 사용하는 ID입니다.	모든 클라이언트 프레임 (SEND, SUBSCRIBE 등)
host	연결 시도 시 브로커의 가상 호스트를 지정합니다.	CONNECT

 

STOMP - BODY

: 바디는 헤더 섹션이 끝난 후에 위치하며, 클라이언특 ㅏ실제로 전송하려는 데이터(Payload)를 담고 있음

• SEND 명령에서는 전송하려는 실제 메시지 내용이 포함됨
• MESSAGE 명령에서는 브로커가 클라이언트에게 전달하는 메시지 내용이 포함됨
• CONNECT, SUBSCRIBE, ACK 와 같은 일부 COMMAND 프레임은 BODY가 없을 수 있음

BODY의 내용은 content-type 헤더에 지정된 형식(Ex. JSON, XML, 일반 텍스트)을 따르게 됨 

 

일반 웹소켓과 STOMP의 차이점 정리

일반 웹소켓 사용 시 기술적 난제

1. 비구조화된 데이터 스트림
   • 웹소켓은 텍스트(UTF-8)와 바이너리(Binary)라는 두 가지 형태의 타입만을 정의
   • 프로토콜 자체는 메시지의 내용이 무엇인지, 어떤 형식(JSON, XML 등)인지, 어떻게 처리해야 하는지에 대한 정보를 포함하지 않음
   • 수신된 데이터 스트림을 파싱하고 해석하는 로직을 애플리케이션 레벨에서 처음부터 구현해야 함
2. 라우팅(Routing) 메커니즘의 부재 :
   • 순수 웹소켓은 단순히 Point to Point 의 연결 통로일 뿐임
   • 발행-구독(Pub/Sub)의 개념이 내장되어 있지않음
3. 애플리케이션 레벨 프로토콜의 필요성 부각
   • 웹소켓 위에서 동작하는 독자적인 서브 프로토콜을 만들게 됨
   • 이는 표준화 되어있지 않아 유지보수가 어렵고, 클라이언트 ↔︎ 서버 간의 강한 결합을 초래

 

STOMP

1. 표준화 된 메시지 라우팅 (Pub/Sub 모델) :
   • STOMP는 '목적지(Destination)' 라는 개념을 도입하여 메시지 라우팅을 표준화함
   • 클라이언트는 특정 주소를 SUBSCRIBE 함으로서 해당 주제에 대한 관심을 표명
   • 서버나 다른 클라이언트가 해당 주소로 메시지를 SEND하면, 메시지 브로커는 이를 구독중인 모든 클라이언트에게 자동으로 전달
   • 비즈니스 로직과 메시지 흐름에 집중할 수 있는 환경을 제공하게 됨
2. 메시지 브로커와의 통합
   • STOMP는 RabbitMQ, Kafka와 같은 메시지 브로커가 사용하는 프로토콜 중 하나
   • Spring Boot 내장 브로커를 사용하다가 트래픽 증가 시 코드를 거의 수정하지 않고 백엔드를 외부 전문 메시지 브로커로 교체하여 확장성을 확보할 수 있음 
3. 보안 및 메타데이터 처리
   • 순수한 웹소켓에서는 인증 토큰을 쿼리 파라미터로 넘기거나 첫번째 메세지로 보내야 하는 등 구현이 까다로움
   • STOMP는 CONNECT 프레임이나, SEND 프레임의 헤더에 인증토큰을 자연스럽게 포함시킬 수 있어 Java의 Spring Security와의 통합이 용이함
4. STOMP 사용 시 단점
   • 바이너리 비효율성 (텍스트 기반 프로토콜)
     • STOMP는 순수 텍스트 프레임으로 메시지를 주고바다아, 약간의 지연시간이 발생할 수 있음
   • 일반 웹소켓보다 헤더 오버헤드가 많음
     • 메시지마다 "command + header + body" 구조이다보니 프레임 크기가 커지고 파싱 비용이 증가함