WebSocket + STOMP

짱센호랑이·2023년 8월 22일
0

SSAFY 공통 프로젝트를 진행하면서 WebSocket과 STOMP를 이용할 일이 생겼다.

클라이언트와 서버의 실시간 통신을 구현하는데 있어서 WebSocet은 정말 매력적이지 않을 수 없다.

그러나 본격적으로 웹 소켓을 사용해 본 건 이번 프로젝트가 처음이었기 때문에 문제도 많이 발생했는데, 이 포스팅에서는 WebSocekt과 STOMP에 대해 간단히 알아보고 내가 프로젝트를 진행할 때 발생했던 문제점과 간단했던 해결 방법에 대해 회고해보고자 한다.


WebSocket?

웹 소켓 vs http

WebSocket은 서버와 클라이언트간의 양방향 통신을 위해 사용하는 프로토콜이다.

기존 HTTP 방식은 요청 - 응답 방식으로, 클라이언트가 요청하면 서버가 응답하는 단방향 통신이다.

하지만 WebSocket은 한번 연결이 이루어지면 서버와 클라이언트가 지속적으로 양 방향으로 데이터를 주고 받을 수 있는 연결지향 양방향 통신이 가능하다.

이러한 특징을 살려 실시간 채팅, 실시간 주식 정보 제공 간은 어플리케이션에서 WebSocket이 많이 사용된다.

즉, WebSocket은 웹의 통신 방식을 단방향에서 양방향으로 확장시켜주는 기술이라고 할 수 있다.


동작 원리

동작 원리

WebSocket은 RFC 6455 명세에 포함된 프로토콜로, HTTP/HTTPS 프로토콜 위에서 동작한다.
기본적인 통신 과정은,

  1. 최초의 HandShake 요청 : 클라이언트가 HTTP를 통해 서버에 연결 요청.
  2. 서버에서 응답 : 서버는 클라이언트에게 HTTP 101 Switching Protocols 라는 응답을 보냄.
  3. 이후의 통신 : HandShake가 완료된 후에는 WebSocket 프로토콜 위에서 양방향 통신이 시작된다.

장점

  1. 실시간 통신 : 서버와 클라이언트 간에 지속적이고 양방향의 통신이 가능하다.
  2. 효율적 : 일단 연결이 수립되면 추가적인 헤더나 메타데이터 없이 데이터를 주고 받을 수 있어 더 경제적이다.
  3. 저 지연성 : 실시간 통신을 위해서는 낮은 지연시간이 필요하고, WebSokcet은 이를 지원함.

단점

  1. 호환성 문제 : 오래된 웹 브라우저나 시스템에서는 WeboSocket을 지원하지 않을 수 있다.
  2. 보안 : WebScoket 자체가 안전하지 않은 것은 아니지만, WebSocket을 사용할 때는 추가적인 보안 고려가 필요하다.

STOMP

다음은 STOMP에 대해 간단히 알아보자.

STOMP는 WebSocket위에서 동작하는 간단한 텍스트 기반 메시지 프로토콜이다.

클라이언트와 서버가 전송할 메세지의 형식을 정의한 통신 규약과 같다고 이해하면 된다.

또한 메시지 브로커라는 것을 활용하여 pub-sub(발행 - 구독) 방식으로 클라이언트와 서버가 손쉽게 메시지를 주고받을 수 있게 하는 하위 프로토콜로 볼 수 있다.

pub-sub (발행-구독) 방식이란?

간단하게 알아보면, 발신자가 특정 경로(주소)로 메시지를 전송하면 그 경로를 구독하고 있는 사용자는 메시지를 받아볼 수 있는 것이다.

이것을 통해 채팅 기능 등을 쉽게 구현할 수 있다.


STOMP는 왜 사용할까?

WebSocket은 서버와 클라이언트간 메시지를 양방향으로 주고 받을 수 있는 프로토콜이다. 하지만 그 메시지를 어떤 형식으로 주고받을지는 정해진것이 없다.

하지만 STOMP를 사용하면

  • 메시징 프로토콜과 메시징 형식을 개발 할 필요가 없다.
  • 연결 주소마다 새로운 핸들러를 구현하고 설명해줄 필요가 없다.
  • 메시지 브로커를 사용하면 구독을 관리하고 메시지를 BroadCast하는데 사용할 수 있다.
  • 외부 Message Queue를 사용할 수 있다. (RabbitMQ, Kafka 등 )

즉, STOMP를 사용하면 형식을 고민하고 파싱하는 코드를 구현하지 않아 도 된다.

파싱하는 과정이 가장 귀찮다고 생각하는데, 파싱하는 코드를 직접 작성하지 않는다는건 서버와 클라이언트가 데이터를 주고받을 때 가장 좋은 기능이지 않을까 싶다.


STOMP의 통신 흐름

웹소켓 통신 흐름

위 그림을 토대로 간단하게 정리해보면

  1. 구독자들은 "/topic"으로 시작하는 주소를 구독하고 있다.
  2. 발신자는 서버를 통한 가공 및 처리를 위해 "/app" 으로 시작하는 주소로 메시지를 송신.
  3. 가공을 마친 메시지를 "/topic" 으로 시작하는 주소에 담아 전송
  4. 메시지 브로커가 전달받고 이 메시지를 "/topic"을 구독중인 구독자들에게 메시지를 송신함.

과 같은 순서로 발행-구독 방식 통신이 이루어지게 된다.


다음 포스팅에는 서비스를 개발하는데 WebSocket과 관련된 문제들과 그 문제를 해결했던 방법 등을 기술해보겠다.

profile
뭐라도 해야지

0개의 댓글