[Spring Framework] 웹소켓 공식문서 읽기 1 - WebSocket API, SocketJS Fallback 그리고 STOMP Overview & Benefits

사실 필자는 학창시절에 다 외우면 공부를 잘하는 것이라고 생각했다.

 

하지만, 이해가 수반되어야 그 어떤것이라도 외울 수 있는 것이라고 최근에서야 깨달았고, (오 나의 늦은 20대의 고백~)

 

 

Netty공식문서를 읽어보니 Web Socket을 지원한다길래

 

이게 Spring Framework에서 지원하는 Web Socket과 무엇이 다른지 알기 위해서 글을 다시 정리한다.

 

 

그냥 공식문서를 읽어보는건데,

 

가장 흔한 채팅방을 기준으로 생각해보겠지만 이를 정말 많은 사람이 접근할 시 어떻게 설계를 해야 하는지 공부하고 정리하려고 한다. (귀찮음을 극복할 수 있다면 말이다 하하)

 

해당 글은 Spring > WebSockets 공식문서를 참고해서, 이해가 안되는 부분에 살을 붙여서 정리한 것이니 해당 글을 봐주면 좋겠다.

 

순서는 WebSockets -> WebSocket API -> SocketJS Fallback ->STOMP 이다.

 

spring framework 목차 중

 

그럼 레츠 고!

 

0. 시작전에

우선 해당 사이트에서 글을 읽으면 키워드가 몇 개 보인다.  SockJS, STOMP 그리고 publish-subscribe 인데, 다시 정리하고 가자.

 

SocektJS?

SockJS는 프런트엔드와 백엔드 구성 요소를 모두 갖춘 오픈 소스 실시간 메시징 라이브러리로, WebSocket API를 에뮬레이션하도록 설계되었습니다.

 

여기서 에뮬레이션이 뭐야? 하고 찾아보니... 하나의 시스템이 다른 시스템의 기능을 흉내 내는 것 이라고 한다. 

 

그러니까 WebSocket API와 비슷하게 동작하는 메시징 라이브러리중 하나로 SocketJS가 있다는 것으로 이해된다.

 

STOMP?

STOMP는 단순(또는 스트리밍) 텍스트 지향 메시징 프로토콜(STOP)이다.

STOMP는 상호 운용 가능한 와이어 형식을 제공하여 STOMP 클라이언트가 모든 STOMP 메시지 브로커와 통신할 수 있도록 함으로써 다양한 언어, 플랫폼 및 브로커 간에 쉽고 광범위한 메시징 상호 운용성을 제공한다.

 

RFC 6455 AI한테 물어보기

RFC 6455는 웹소켓 프토로콜의 국제 표준 규격서 인데 아니 무슨... 목차가 11장까지 있어. 전공서적이야 ㅠㅠ...

 

그렇기에 필자는 너무 길어서 읽기 싫어서 그냥 AI한테 핵심을 좀 요약해 달라 해보았다.

 

이에 대해서 제미나이에게 질문을 해 보았다.

 

궁금하면 해당 글을 펴서 읽어보길 바란다.

 

나
제미나이! https://datatracker.ietf.org/doc/html/rfc6455 이거 요약좀... 무슨말이야?

제미나이
1. 한 줄 정의: "웹을 위한 양방향 전용선"
기존의 인터넷(HTTP)은 무전기 같아서 내가 말을 하고(Request) 끝나야 상대방이 대답(Response)을 할 수 있었습니다. 하지만 **웹소켓(RFC 6455)**은 전화기와 같습니다. 연결만 되면 클라이언트와 서버가 동시에 서로에게 데이터를 막 보낼 수 있습니다(Full-Duplex).

2. 핵심 작동 원리 (이 문서가 정의하는 것)
오프닝 핸드셰이크 (Opening Handshake):처음엔 일반적인 HTTP 요청처럼 시작합니다.

"나 웹소켓으로 업그레이드할래!"라고 요청(Upgrade: websocket)을 보내고,
서버가 "그래!"(101 Switching Protocols)라고 응답하면 그 즉시 웹소켓 연결로 바뀝니다.

이 덕분에 80번(HTTP)이나 443번(HTTPS) 포트를 그대로 써서 방화벽 문제를 피할 수 있습니다.데이터 프레임 (Data Framing):데이터를 주고받을 때 HTTP처럼 무거운 헤더(Header)를 매번 붙이지 않습니다.

아주 가벼운 '프레임' 단위로 쪼개서 보내기 때문에 속도가 빠르고 효율적입니다.마스킹 (Masking):보안을 위해 클라이언트가 서버로 데이터를 보낼 때는 반드시 데이터를 뒤섞는(Masking) 규칙을 따라야 한다고 정의되어 있습니다
.
3. 왜 중요한가요?
이 표준이 나오기 전에는 채팅이나 주식 차트처럼 실시간 기능이 필요하면, 브라우저가 서버한테 1초마다 "새로운 거 있어?"라고 계속 물어봐야 했습니다(Polling).

하지만 이 RFC 6455 덕분에 서버가 브라우저에게 먼저 데이터를 밀어넣어 주는(Push) 기능이 웹에서 표준화되었습니다.

요약하자면:
"채팅, 실시간 게임, 주식 거래소 같은 실시간 웹 서비스를 만들 때 사용하는 웹소켓 기술의 교과서입니다."

----

나:
솔직히 이거를 내가 가지고 구현할 일이 없자나. 이미 잘 구현되어 있는 라이브러리들이 많아서

제미나이: 
맞습니다. 100% 동감합니다.
현업에서 RFC 6455 명세서를 펴놓고 비트 연산해가며 패킷을 직접 조립할 일은 전혀 없습니다. Python의 websockets, Java의 Spring WebSocket이나 Netty, Node.js의 Socket.io 같은 라이브러리가 이미 완벽하게 구현해 뒀으니까요.

하지만 **"구현할 일"**은 없어도 **"들여다볼 일"**은 생깁니다.

특히 백엔드 아키텍처나 대용량 트래픽을 다루신다면(사용자분의 관심 분야시죠!), 아래 3가지 상황 때문에 이 원리를 아는 게 도움이 됩니다.

1. "연결이 자꾸 끊겨요" (트러블슈팅)
로드밸런서(AWS ALB, Nginx) 뒤에 숨은 서버가 웹소켓 연결을 맺을 때, **헤더 값(Upgrade, Connection)**이 어떻게 넘어가는지 모르면 디버깅이 지옥이 됩니다.

RFC 내용: "핸드셰이크 과정에서 이 헤더가 없으면 연결을 거부해라"라는 규칙이 있습니다. Nginx 설정에서 이 헤더를 명시적으로 넘겨주지 않아서 연결이 안 되는 경우가 허다합니다.

2. "서버 부하가 너무 심해요" (성능 최적화)
라이브러리 기본 설정만 쓰다가 동접자가 늘어나면 메모리가 터집니다.
RFC 내용: 웹소켓은 Ping/Pong(하트비트) 프레임이 프로토콜 레벨에서 정의되어 있습니다.

활용: 애플리케이션 레벨(JSON으로 {type: 'ping'})에서 구현하는 것보다, 프로토콜 자체의 Ping/Pong을 활용하거나 Netty의 IdleStateHandler 같은 걸 튜닝할 때 이 개념이 필수적입니다.

3. 보안 이슈 (Masking)
가끔 직접 TCP 툴로 테스트하다가 "왜 서버가 내 요청을 뱉지?" 싶을 때가 있습니다.
RFC 내용: "클라이언트가 서버로 보낼 때는 무조건 데이터를 마스킹(Masking) 해야 한다"는 규약이 있습니다. (중간에 프록시 캐시가 오염되는 걸 막기 위함)

활용: 보안 감사나 저수준 디버깅 시 "아, 마스킹 안 돼서 드랍됐구나"를 바로 알 수 있습니다.

결론
"바퀴를 다시 만들 필요는 없지만, 바퀴가 펑크 났을 때 구조는 알아야 고친다" 정도로 생각하시면 됩니다.
그냥 "아, HTTP로 시작해서 101 응답받고 연결되면, 그때부턴 가벼운 바이너리 프레임으로 핑퐁하는구나" 정도의 개념만 머릿속에 넣어두시면 충분합니다!

---

나:
가벼운 바이너리 프레임이라고 하면, osi 7 layer의 frame이 이진수로 표현된다는걸 말하는거니?

제미나이:
아, 아주 예리한 질문이네요! 결론부터 말씀드리면 "아닙니다".

두 가지 "프레임(Frame)"은 이름만 같을 뿐, **완전히 다른 계층(Layer)**의 개념입니다.

기존 HTTP (Text 기반):데이터를 보낼 때마다 주저리주저리 글로 씁니다.
웹소켓 (Binary 기반): 딱 필요한 정보만 **0과 1의 비트(Bit)**로 꽉 채워서 보냅니다.

"첫 1비트는 끝(FIN) 신호, 다음 4비트는 데이터 타입(Opcode)..." 이런 식으로 약속된 비트 칸에 데이터만 쏙쏙 집어넣기 때문에 **'바이너리 포맷'**이라고 부르는 것입니다.

 

그래서 왜 ... 이게 필요한지에 대해 개발자들의 영원한 친구... stack overflow에서 찾아보았다.

 

Why to use websocket and what is the advantage of using it? (Why use websocket over http?)

해당 글은 stackoverflow의 글을 참고했다. (여기 클릭)

1. 연결의 지속성과 서버 푸시 (Server-Push)

 

원문 요약: 웹소켓은 연결이 끊기지 않고 계속 유지됩니다. 덕분에 클라이언트가 요청하지 않아도 서버가 언제든 데이터를 보낼 수 있습니다.

 

• 서버 푸시(Server-push): 클라이언트(브라우저)가 "새로운 거 있나요?"라고 묻지 않아도, 서버가 알아서 데이터를 밀어 넣어줄 수 있다.
• 활용: 채팅 메시지 수신이나 주식 가격 변동처럼, 서버 쪽의 변화를 클라이언트가 즉시 알아야 할 때 매우 유용하다.
• HTTP와의 차이: 일반적인 HTTP로는 서버가 먼저 데이터를 보낼 수 없습니다. 그래서 HTTP 환경에서는 몇 초마다 계속 "데이터 왔어?"라고 묻는 폴링(Polling) 방식을 써야 하는데, 이건 매우 비효율적이다.

2. 압도적인 전송 효율 (Efficiency)

 

 

원문 요약: 이미 연결된 상태에서 데이터를 보내고, 데이터 프레임 구조가 매우 효율적이라 HTTP보다 훨씬 가볍습니다.

 

• 가벼운 프레임: 웹소켓 데이터 프레임은 오버헤드가 매우 적다.
  • 데이터를 감싸는 껍데기(Header)가 보통 고작 6바이트(헤더 2바이트 + 마스킹 키 4바이트)밖에 안된다.
• 비교: 반면 HTTP 요청은 매번 무거운 헤더(Headers)와 쿠키(Cookie) 등을 주렁주렁 달고 다녀야 하므로 훨씬 비효율적이다.

3. 전이중 통신 (Full Duplex)이란?

 

 

원문 요약: 연결된 상태에서 언제든지 양방향으로 데이터를 보낼 수 있다는 뜻입니다.

 

• 한쪽이 말하고 끝날 때까지 기다리는 게 아니라(무전기), 동시에 서로 데이터를 주고받을 수 있는 상태(전화기)를 말한다.

4. 저지연 (Lower Latency)이란?

 

 

원문 요약: 요청하고 응답받는 데 걸리는 시간이 아주 짧다는 뜻입니다.

 

• 왜 빠른가?: 이미 연결이 맺어져(Established) 있기 때문이다.
• 데이터를 보낼 때마다 TCP 연결을 새로 맺기 위해 패킷이 왔다 갔다 하는 과정(3-way handshake 등)이 필요 없습니다. 특히 네트워크가 느린 환경에서 이 초기 연결 시간이 절약되는 건 아주 큰 이점이다.

결론적으로 말하자면 끊이지 않고 계속 빠르게 데이터를 주고 받기 위한 상황에서 쓰기 유용한 도구라고 생각된다.

 

이것이 끊임없이, 실시간으로 통신해야 하는 경우라면 web socket을 사용해야 하지만, 그렇지 않은 경우에는 딱히 쓸 일이 없어 보인다.

 

기존의 Polling, 긴 Polling, HTTP Streaming 그리고 WebSocket Protocol에 대한 흐름을 읽어보고 싶으면 다음 링크를 추천한다. (여기 클릭!)

 

1. Introduction to WebSocket

헥헥... 드디어... 공식문서 읽는다 히히...

 

WebSocket 프로토콜, RFC 6455는 하나의 TCP 연결을 통해 client와 server같의앙뱡항 통신 채널인 전이중 통신(full duplex)를 설립하기 위해 표준화된 방식을 제공한다.

 

이것은 HTTP의 TCP 프로토콜과 다르지만 80포트와 443포트를 사용해서 HTTP 위에서 작동하도록 설계되었는데, 이는 방화벽 규칙을 재 사용하게 해준다.

 

여기서 방화벽 규칙 혹은 룰을 재사용한다는게 이해가 안됏는데, 기본적으로 80이랑 443포트의 경우는 기존의 방화벽 룰에서 허용이 되는 포트들이다. 그렇다면 웹소켓은 별도의 방화벽 룰을 요청하지 않고 기존의 룰에 따라서, 바로 적용할 수 있도록 80, 443 포트 위에서 작동하도록 한 것이다.

 

그러면 정말 그런지 계속 읽어보자.

 

웹소켓 통신은 HTTP Upgrade 헤더를 사용해 '프로토콜을 업그레이드(이 경우엔 웹소켓으로 전환)'하겠다는 HTTP 요청으로 시작된다. 다음 예시를 보자.

 

GET/spring-websocket-portfolio/portfolioHTTP/1.1
Host: localhost:8080
Upgrade: websocket (1)
Connection: Upgrade (2)
Sec-WebSocket-Key: Uc9l9TMkWGbHFD2qnFHltg==
Sec-WebSocket-Protocol: v10.stomp, v11.stomp
Sec-WebSocket-Version: 13
Origin: http://localhost:8080

 

(1) : The Upgrade Header.

(2) : Using the Upgrade conneciton.

 

보통의 200상태 코드를 사용하는 대신, WebSocket을 가진 서버는 다음과 같은 비슷한 결과를 반환한다.

 

HTTP/1.1 101 Switching Protocols(1)
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: 1qVdfYHU9hPOl4JYYNXF623Gzn0=
Sec-WebSocket-Protocol: v10.stomp

 

(1) Protocol switch

 

성공적인 핸드쉐이크 후에, HTTP 업그레이드 요청 밑에 깔린 TCP 소켓이 메시지를 계속해서 보내고 받을 수 있게끔 client와 서버 둘 다 에게 열린채로 남아있다. 

 

2. HTTP vs WebSocket

WebSocket은 HTTP와 호환되도록 설계되었고 HTTP 요청으로 시작하지만,

 

두 프로토콜이 매우 다른 아키텍처와 애플리케이션 프로그래밍 모델을 낳는다는 점을 이해하는 것이 중요하다.

HTTP와 REST에서 애플리케이션은 여러 개의 URL로 모델링된다.

애플리케이션과 상호작용하기 위해 클라이언트는 요청-응답 방식으로 해당 URL에 접근한다.

서버는 HTTP URL, 메서드, 헤더를 기반으로 적절한 핸들러로 요청을 라우팅한다.

 

쉽게 생각하면 고객 화면이면 http:localhost8080/customer 이겠지?

 

그런데 상품 화면을 본다면 보통 다른 url 을 요청할 것이다. http:localhost8080/products 처럼 말이다.

 

이렇게 여러 개의 URL로 모델링되며, 세부적인 작업은 또 요청 method 로 구분이 가능하다(GET, POST 등)

반면, 웹소켓에서는 일반적으로 초기 연결에 URL이 하나만 존재한다.

이후 모든 애플리케이션 메시지는 동일한 TCP 연결을 통해 전달된다. 이는 완전히 다른 비동기 이벤트 기반 메시징 아키텍처를 의미한다.

 

그러면 아니... 예를 들어 웹소켓을 통해서 대화를 한다고 하면, 대화방이 다른데 그걸 어떻게 구분하는건가?

 

그것은 논리적인 구분(Logical Separation)을 통해 구현한다.

 

채팅방에 번호가 있다면, 해당 사람은 어느 채팅방에 접속할거야! 하는 정보를 보내면 된다.

웹소켓은 저수준 전송 프로토콜로, HTTP와 달리 메시지 내용에 대한 의미를 규정하지 않는다.

즉, 클라이언트와 서버가 메시지 의미에 동의하지 않으면 메시지를 라우팅하거나 처리할 방법이 없다.

WebSocket 클라이언트와 서버는 HTTP 핸드셰이크 요청의 헤더를 통해 상위 레벨 메시징 프로토콜(예: STOMP) 사용을 협상할 수 있다.

Sec-WebSocket-Protocol. 이러한 프로토콜이 없는 경우, 클라이언트와 서버는 자체적인 규칙을 마련해야 한다.

 

3. 웹소켓을 사용하는 경우

공식문서를 읽기 전에, 위에 정리를 한것을 보면 Why to use websocket and what is the advantage of using it? (Why use websocket over http?)

를 보며 느낀점이 여기 정리가 되어있다.

웹소켓을 사용하면 웹 페이지를 동적이고 인터랙티브하게 만들 수 있다.

하지만 많은 경우 AJAX와 HTTP 스트리밍 또는 롱 폴링을 함께 사용하면 간단하고 효과적인 솔루션을 제공할 수 있다.

예를 들어 뉴스, 메일, 소셜 피드는 동적으로 업데이트되어야 하지만, 몇 분 간격으로 업데이트해도 전혀 문제가 없을 수 있다.

반면, 협업, 게임, 금융 앱은 실시간에 훨씬 더 가까워야 한다.

지연 시간만으로는 결정적인 요소가 될 수 없다. 메시지 양이 비교적 적은 경우(예: 네트워크 장애 모니터링)에는 HTTP 스트리밍이나 폴링이 효과적인 해결책이 될 수 있다. 낮은 지연 시간, 높은 빈도, 그리고 높은 볼륨의 조합이 WebSocket을 사용하기에 가장 적합한 이유다.

 

4. WebSocket API 섹션

Spring Framework는 웹소켓 메시지를 처리하는 클라이언트 및 서버 측 애플리케이션을 작성할 수 있는 WebSocket API를 제공한다.

 

해당 챕터는 어떤 메시지를 처리할 수 있도록 클라이언트 및 서버 측 애플리케이션을 어떻게 설정하는지를 알려준다.

 

실질적으로 해당 코드를 보고서는 스프링 웹 소켓을 구현하기 어렵다는 판단이다.

 

쭉 이어서 밑에 오는 SocketJS Fallback과 STOMP 설명을 같이 읽어야 한다.

 

 

하여간 해당 섹션의 설명은 메시지를 어떻게 주고받을지(비즈니스 로직)보다는

 

연결 통로 자체를 어떻게 열고 닫을지, 보안(CORS)은 어떻게 할지 연결이 끊기면 어떻게 할지(SockJS) 같은 '인프라 설정'을 담당한다.

 

WebSocketHandler, WebSocketConfiguration 를 활용하면 된다는 것이다!

자세한 내용은 여기를 클릭하면 된다.

 

5. SocketJS Fallback

공용 인터넷 환경에서는 사용자가 제어할 수 없는 제한적인 프록시로 인해 WebSocket 상호 작용이 차단될 수 있다.

 

이는 프록시가 헤더를 전달하도록 구성되어 있지 않거나 Upgrade, 유휴 상태인 것처럼 보이는 장시간 연결을 종료하기 때문이다.

 

 

아직 제대로 이해가 안된다. 제한적인 프록시? 이게 정확히 무슨 상황인가? 공용 인터넷 환경인가 말 그대로?

 

찾아보니 보안규칙이 아주 엄격하거나, 옛날 방식을 고수하는 중계 서버를 말한다. (관공서 혹은 회사 등등)

 

이런 환경에서는 웹소켓의 연결 방식인 Upgrade와 유지방식(Long-lived connection)을 이해하지 못한다는 것이다.

 

 

그래서! 이를 해결하기 위한 방법으로 WebSocket 에뮬레이션을 사용하면 된다고 한다.

 

에뮬레이션? 찾아보니 게스트 시스템과 동일한 방식으로 동작하도록 설계된 컴퓨터 시스템 이라고 한다.

 

그러면 WebSocket 에뮬레이션이란, WebSocket은 아닌데 WebSocket과 동일한 일을 하는 라이브러리? 혹은 그런것을 사용하면 된다는것으로 이해된다.

 

즉, 먼저 WebSocket을 사용하려고 시도한 다음, WebSocket 상호 작용을 에뮬레이션하고 동일한 애플리케이션 수준 API를 노출하는 HTTP 기반 기술로 전환하는 것이다. 

 

 

웹소켓이 막히면, SockJS는 'HTTP(일반 웹페이지 통신 방식)'를 가지고 웹소켓인 척 연기(에뮬레이션)를 시작한다.

 

WebSocket연결이 안되면, SocketJS가 이제 빠른 속도로 HTTP요청을 아주 빠르게 주고 받아서, 실시간처럼 보이지만 사실은 에뮬레이션으로 웹소켓을 흉내낸다고 한다.

 

내부적으로 어떻게 구현하든 외부에서 볼 때는 잘 동작하면 그만 아닌가? 

 

그래서 동일한 애플리케이션 수준 API를 노출하는 HTTP 기반 기술로 전환 이라는 표현을 했다.

 

서블릿 스택에서 스프링 프레임워크는 SockJS 프로토콜에 대한 서버(및 클라이언트) 지원을 모두 제공한다.

 

 

그래서 해당 공식문서의 개요를 보면 다음과 같이 나온다.

 

SockJS의 목표는 애플리케이션이 WebSocket API를 사용하면서도 필요에 따라 런타임에 애플리케이션 코드 변경 없이 WebSocket이 아닌 다른 대안으로 전환할 수 있도록 하는 것입니다.

 

SocketJS Fallback에 대해 이미 개요에서 설명을 하고 있다. 

 

 

여기서 Fallback이라는 말을 번역하면 대체 라는 뜻인다.

 

IT에서는 에러가 발생시 원래 기능을 대체하는 기능 이라고 설명하고 있는데, 에뮬레이션으로서의 역할을 생각하면 적절한 단어라고 생각한다.

 

 

SockJS 클라이언트는 먼저 GET /info서버로부터 기본 정보를 얻기 위해 패킷을 전송한다.

 

그 후, 사용할 전송 방식을 결정해야 합니다. 가능하면 WebSocket을 사용하고, 그렇지 않은 경우 대부분의 브라우저에서 HTTP 스트리밍 옵션이 하나 이상 제공된다.

 

만약 HTTP 스트리밍도 없다면 HTTP (롱) 폴링 방식을 사용합니다.

 

모든 전송 요청은 다음과 같은 URL 구조를 갖는다.

https://host:port/myApp/myEndpoint/{server-id}/{session-id}/{transport}

 

• {server-id} : 클러스터 내 요청 라우팅에 유용하지만 그 외에는 사용되지 않습니다.
• {session-id} : SockJS 세션에 속하는 HTTP 요청들을 서로 연관시킵니다.
• {transport} : 운송 유형을 나타냅니다(예: websocket, xhr-streaming, 등).

 

그리고 코드를 보면 뭔가 이전 챕터 WebSocket API에서 본 것과 유사한데, 전자는 순수한 웹 소켓을 만드는 방법에 대해 알려주는 것이고, 해당 챕터인 SockJS Fallback은 좀 더 쉽게 SockJS 를 이용해서 코드를 작성하는 법에 대해 설명한다.

 

WebSocketConfiguration에서 SockJS를 활성화 하는법, 이미 운명해버린 인터넷 익스플로러에서의 사용법, iframe에서의 사용법, SockJS의 하트비트 와 CORS설정 등등을 제공한다.

 

6. STOMP

STOMP는 Simple Text Oriented Messaging Protocol의 약자로, 직역하면 간단한 텍스트 지향 메시징 프로토콜이다.

 

STOMP는 일반적으로 사용되는 최소한의 메시징 패턴만을 처리하도록 설계되었다.

 

TCP, WebSocket과 같은 신뢰할 수 있는 양방향 스트리밍 네트워크 프로토콜을 통해 사용할 수 있다.

 

STOMP는 텍스트 기반 프로토콜이지만, 메시지 페이로드는 텍스트 또는 바이너리 데이터일 수 있습니다.

 

 

STOMP를 사용해서 얻을 수 있는 이점은 다음과 같다.

 

• 사용자 정의 메시징 프로토콜이나 메시지 형식을 따로 고안할 필요가 없다.
• Spring Framework의 Java 클라이언트를 포함하여, 이미 제공되는 STOMP 클라이언트를 사용할 수 있다.
• 구독(subscription)을 관리하고 메시지를 브로드캐스트하기 위해 메시지 브로커(RabbitMQ, ActiveMQ 등)를 선택적으로 사용할 수 있다.
• 연결당 하나의 WebSocketHandler로 원시(raw) WebSocket 메시지를 처리하는 대신, 애플리케이션 로직을 여러 개의 @Controller 인스턴스로 구성하고 STOMP destination 헤더를 기반으로 메시지를 라우팅할 수 있다.
• Spring Security를 사용하여 STOMP destination 및 메시지 유형에 따라 메시지에 보안을 적용할 수 있다.

 

---

 

사실 WebSocket에 대한 글은 차고 넘친다. 

 

그런데 필자는 공부할 때 만큼은 남의 글을 보지 않고, 우선 내 방식대로 정리하는것을 선호한다.

 

그렇게 안하면 안남아서... 그리고 남의 글은 또 금방 잊게되더라 ㅠㅠ...

 

 

해당 글은 그래서... 필자가 Netty공부를 하는데 아니 뭐 갑자기 WebSocket을 지원한다고 하길래

Spring Framework에서 지원하는 websocket과 뭐가 좀 다른가 싶어서 보기 위해서

 

공식문서를 토대로 이해가 안되는 부분은 살을 붙여가며 글을 적었다.

 

 

더 필요하다면 아무래도 해당 글 이외에 STOMP관련 글도 읽으면 좋을 듯 하다.

 

출처:

https://docs.spring.io/spring-framework/reference/web/websocket.html

https://ably.com/topic/sockjs-vs-websocket

https://stomp.github.io/

https://stackoverflow.com/questions/44898882/why-to-use-websocket-and-what-is-the-advantage-of-using-it

https://docs.spring.io/spring-framework/reference/web/websocket/server.html

https://docs.spring.io/spring-framework/reference/web/websocket/fallback.html

https://spring.io/blog/2012/05/08/spring-mvc-3-2-preview-techniques-for-real-time-updates

https://docs.spring.io/spring-framework/reference/web/websocket/stomp/benefits.html