# stomp
TIL - WebSocket과 STOMP
채팅 기능 구현을 위해서 WebSocket을 사용하게 되었다. 앞서 WebSocket과 STOMP에 대한 내용을 간단하게 정리한 적이 있었는데, 너무 간단해서 추가로 다시 작성해보았다. WebSocket WebSocket의 등장 Http의 비연결 통신의 단점을 보완하고자 등장하였다고 한다. → 실시간 양방향 통신을 가능하게 한다. Http에는 양방향이 없나? Http에도 실시간 양방향 통신을 가능하게 하는 방식이 존재한다. Polling, Long Polling, Streaming 하지만, Http는 비연결성 이라는 특징이 있으므로 매번 연결을 맺고 끊는 과정에서 비용이 발생한다. → 요청을 보내고 응답을 받는 Http의 방식은, 실시간성을 요할 경우 데이터 송수신에 부담이 간다. WebSocket을 사용하는 이유 처음 hand shake 시에는 Http와 유사한 양의 정보를 주고받지만, 연결이 되고 나면 주고받는 정보가
스프링으로 채팅 기능 구현하기 (개념편)
들어가며 새로 진행 중인 프로젝트에서 채팅 기능을 처음으로 구현하고자 한다. 실시간 통신이 가능한 웹소켓과 STOMP에 대해 알아보자. STOMP로 채팅 서비스를 구현해보자. 웹소켓이란? 웹소켓은 응용 계층에서 사용되는 양방향, 전이중 통신 프로토콜로서 클라이언트와 서버가 데이터를 주고 받는 구조를 가지고 있다. 그러나 HTTP와는 다르게, 한 번 연결되면 서버나 클라이언트 중 한 쪽의 연결 해제가 있기 전까지 연결이 유지된다는 특이성이 있다. 그로 인해 실시간 데이터가 지속적으로 업데이트되는 상황(채팅, 게임, 트레이딩)에서 유용하게 사용되곤 한다. HTTP, HTTPS 연결을 웹소켓으로 업그레이드하여 사용하는데, 과정은 다음과 같다. 클라이언트에서 서버로 HTTP 요청
대기열+웹 소켓 트러블 슈팅
개선 전 수강신청 로직 클라이언트에서 수강 신청 요청 과 함께 웹 소켓 연결 요청 둘은 각각의 비동기 요청 서버는 수강 신청 요청을 Redis 대기열로 등록 서버에서 대기열에 등록된 요청을 처리, 처리와 함께 pub sub 구조로 해당 요청을 보낸 클라이언트에게 처리 결과 전송 문제 분산 서버로 확장시 웹 소켓 연결과 처리 결과 전송 로직에 문제가 발생함 원인 클라이언트로 부터 들어오는 모든 요청은 ALB에의해 라운드로빈 방식으로 모든 서버를 돌아가며 요청이 가게 되는데 이 때 /ws 요청을 받은 서버가
Websocket & STOMP 란?
📌 Websocket란? > Websocket은 클라이언트와 서버 간의 전이중 양방향 통신 💡 주로 데이터를 보내거나 받는 데 사용되며 빈도가 높고 대기 시간이 짧으며, 클라이언트와 서버 간에 TCP 연결을 만들고 둘 중 하나가 연결을 끊을 때까지 둘 다 데이터를 교환할 수 있다. ✨🚨 Websocket 의 특징 1) 양방향 통신(Full-Duplex) 데이터 송수신을 동시에 처리할 수 있는 통신 방법 클라이언트와 서버가 서로에게 원할 때 데이터를 주고 받는다. (통상적인 HTTP 통신은 클라이언트가 요청을 보내는 경우에만 서버가 응답하는 단방향 통신 ) 2) 실시간 네트워킹(Real Time-Networking) 웹 환경에서 연속된 데이
Spring + WebSocket + STOMP
WebSocket 프로토콜은 두 가지 유형의 메시지를 정의하고 있지만 그 메시지의 내용까지는 정의하고 있지 않다. STOMP란? > Simple Text Oriented Messaging Protocol > 텍스트 기반의 메시지 프로토콜 메시지 브로커를 활용하여 Pub/Sub 방식으로 클라이언트와 서버가 쉽게 메시지를 주고 받을 수 있다. 발신자가 메시지를 발생하면, 수신자가 그것을 수신하는 메시징 패러다임이다. 메시지 브로커는 발신자가 보낸 메시지들을 받아서 수신자들에게 전달해 준다. > STOMP 프로토콜은 WebSocket만을 위해 만들어진 프로토콜이 아니다. 중요한 점은 STOMP는 TCP, WebSocket과 같이 양방향 네트워크 프로토콜 기반으로 동작한다. Spring은 WebSocket 위에 STOMP 프로토콜을 얹어서 사용하는 방법을 지원한다.
reDuck 채팅 서비스 1
졸업 프로젝트로 진행하고 있는 reDuck서비스의 채팅 시스템을 도입하며 고민했던 것을 기록하기 위해 작성합니다. 채팅 시스템는 우리에게 익숙한 카카오톡 서비스를 참고하여 1:1채팅을 구현하였습니다. 여러 기능 중 고민이 많았던 채팅방 목록, 채팅방 개설, 채팅방 입장 & 퇴장 에 대해 적어보겠습니다. 더 좋은 설계나, 제가 한 방식들에 부족한 부분이 많이 있겠지만, 초기 단계를 기록하며 발전되어가는 흐름을 보는것에 의미가 있을 것 같아 작성하게 되었습니다. STOMP (Simple Text Oriented Messaging Protocol)를 사용하였고, 현재는 내부 브로커를 이용하고 있습니다. 추후에 외부 브로커를 사용하려고 합니다. 채팅 내역은 지금은 MySQL에 저장하고 있어, 모든 설명은 MySQL기준입니다. NoSQL 에 채팅 내역들을 저장하고 여러 다른 기능들을 사용해야겠지만, 우선 빠르게 기능을 완성시킨 후 고도화할 예정입니다. ERD 먼
표준 메세징 프로토콜 정리 (AMQP, STOMP, MQTT)
AMQP (Advanced Message Queue Protocol) 등장 배경 AMQP는 메세지 지향 미들웨어 (MOM) 을 위한 표준 응용 계층 프로토콜입니다. 간단히 말하면, 메세지 통신을 위한 규약 스펙 입니다. 플랫폼 종속적인 제품들 사이에서 서로 다른 이기종간에 메세지를 교환하기 위해서는 메세지 포맷 변환을 위해 속도가 느린 메세지 Bridge를 이용하거나, 시스템 자체를 통일 시켜야 하는 불편함과 비효율성이 있었습니다. 그래서, 서로 다른 시스템들 간의 최대한 효율적인 방법으로 메세지를 교환하기 위해 AMQP 프로토콜이 등장하게 되었습니다. AMQP는 금융계의 이기종 플랫폼간의 메세지 상호 정보 교환을 위해서 JPMorgand의 John O'Hara에 의해
WebSocket, STOMP
WebSocket 일반적으로 HTTP 프로토콜은 클라이언트가 서버에 요청을 보내고, 서버는 요청에 대한 응답을 보내는 단방향 통신 방식이다. 이는 주로 웹 페이지를 요청하고 정적인 콘텐츠를 전달하는 데에 사용된다. 그러나 HTTP는 요청-응답 사이클이 완료되면 연결을 닫게 되며, 실시간 업데이트가 필요한 애플리케이션에는 적합하지 않다. WebSocket은 이러한 제한을 극복하기 위해 설계되었다. 클라이언트와 서버 간의 연결을 유지하면서, 양방향으로 데이터를 전송할 수 있다. 이를 통해 실시간 채팅, 주식 시장 업데이트, 게임 등과 같은 실시간 데이터 통신이 가능해진다. WebSocket 통신의 과정 클라이언트가 서버에 WebSocket 연결 요청을 보낸다. 이 요청
Spring STOMP
WebSocket 웹소켓은 웹브라우저와 서버 간의 양방향으로 송신과 수신할 수 있는 지속적인 연결을 의미한다. 한 번 웹소켓 연결이 되면 이 연결은 클라이언트나 서버가 연결을 끊기 전까지 계속 열려있다. 웹소켓은 실시간 채팅을 할 때 주로 사용한다. STOMP STOMP(simple text oriented message protocol)는 클라이언트와 서버가 서로 통신하는 데 있어 메시지의 형식, 유형, 내용 등을 정의해주는 프로토콜이라고 할 수 있다. STOMP를 사용하게 되면 단순한 Binary, Text가 아닌 규격을 갖춘 메시지를 보낼 수 있다. STOMP의 형식은 command, header:value, body로 구성되어 있다. command는 subscribe와 send가 있다. subscribe의 경우 구독할 주소를 헤더에 명시해야 하고 send의 경우 보내는 주소 이외의 메시지 타입과 바디를 명시해야 한다. 메시지 수신을 위한 구독 예시 2
[SpringBoot] API 구현 - #4 채팅방 구현 (1)
Flutter로 만든 어플과 통신하기 위한 백엔드 서버 구현 이번 글은 2가지로 나누어서 작성한다. 실제 구현은 다음 글에서 진행하고, 현재 글에서는 개념 위주로 정리한다. 메시지(채팅방) 구현할 때 어떻게 통신할까? Http통신은 『클라이언트 → 서버』 > Http 통신은 단방향 프로토콜 → ‘클라이언트 요청 후 서버 응답’ 구조이기 때문에, 실시간으로 메시지 반영 불가능 → 메시지가 존재하는지 서버에 계속 물어보면? (Polling) → 서버에 트래픽 부담 즉, Http통신은 채팅방 생성에 적합하지 않다. WebSocket 『클라이언트 ↔ 서버』 [클라이언트] HTTP로 통신(요청) → handshake 요청 클라이언트 : “서버는 응답하라! 난 홍길동이다! 우리 ‘qWeRrTy1U2i3O4p==’라고 암호를 정하자!” ( HTTP Upgrade 헤더 사용 ) [서버] 101 Switching Protocol로 응답
Websocket 이 뭐죠? (이론편)
사내 서비스에서 사용자 알림 기능을 구현할 때 웹 소켓을 사용하기에 이를 정리하고 이해해보려 한다. 웹 소켓이란? 웹 소켓이란 클라이언트와 서버가 http 프로토콜 안에서 전이중 통신을 할 수 있게 하는 통신 프로토콜이다. > 전이중 통신이란, 양방향 통신 중에서도 동시에 보내면서 받을 수도 있는 통신을 말한다. 채팅방처럼 보내는 도중에 응답을 받을 수도 있는 그런 것을 떠올리면 된다. 위의 설명에서도 나오다시피 웹 소켓의 예제들은 주로 채팅 서비스를 구현하면서 많이들 공부하는데, 이는 웹 소켓의 전이중 통신 방식을 제일 잘 보여주는 것이 채팅 서비스 기능이기 때문이다. 꼭 채팅이 아니더라도 실시간 알림 같은 기능으로도 이용할 수 있다. 등장 배경(사실은 추측에 가깝다) 웹 서비스는 본래 사용자의 요청이 들어오면 해당 요청에 대한 응답을 전해주고 연결이 종료된다. 하지만 웹 서비스가 발전하면서 기존의 요청에 대한 응답만 전달할 것이 아니라 특정
[Network] STOMP
STOMP > STOMP is the Simple(Streaming) Text Orientated Messaging Protocol STOMP란 TCP나 웹소켓같은 양방향 네트워크 프로토콜 위에서 동작하는 텍스트 기반 메세징 프로토콜로, 클라이언트와 서버가 통신에 사용하는 메세지의 유형, 형식, 내용등을 정의한다. 웹소켓을 사용하면 서버와 클라이언트가 실시간으로 메세지를 주고받을 수 있지만, 웹소켓은 메세지의 형식까지는 정의하고있지 않기 때문에 STOMP를 사용하여 메세지의 형식을 지정하는 방식으로 웹소켓의 단점을 보완할 수 있다. STOMP기반 통신과정 STOMP를 사용하는 서버와 클라이언트는 메세지브로커를 통한 pub/sub방식으로 메세지를 주고받는다. Pub/Sub모델 
웹 소켓???
본 글은 CRAFT 로 먼저 작성 한 후, VELOG에 옮긴 글이기때문에 가독성이 안좋을 수 있습니다. 가독성이 좋은 , 정리된 원본 글을 보고싶은 분들은 아래 링크를 클릭하세요. 완성된 정리본 : https://www.craft.me/s/DtXX6CV4kjYesk > ## 🤔 왜 웹소켓을 사용하게되었나요?? 웹소켓은 클라이언트와 서버 간의 실시간 양방향 통신이 가능한 기술이며, 이 때문에 인스타그램과 같은 플랫폼의 DM 기능이나 채팅 기능을 구현하는데 적합합니다. 기본적으로 HTTP 통신에서 클라이언트는 서버에 요청하고 서버가 그에 대한 응답을 제공합니다. 하지만 실시간 채팅 기능이 필요한 경우, 서버가 클라이언트의 요청 없이도 데이터를 전달할 수 있어야 합니다. 즉 모든 사용자가 "양방향" 통신을 해야한다. 이러한 패러다임의 변화를 위해 웹 소켓이 사용됩니다. 
React - 채팅하기
React로 SockJS, STOMP를 사용하여 채팅기능을 구현해보자. 구현된 채팅은 중고 거래 웹에 맞게 1:1 채팅 기능으로 구현했다. 이번 채팅 구현에는 JavaScript 라이브러리인 SockJS와 STOMP 프로토콜로 구현했다. 서버측 구현은 BE팀에서 담당했다. (여기선 React에서 사용된 코드만 정리했다.) 채팅은 서버와 클라이언트 양쪽에서 실시간 통신을 위해 동일한 라이브러리를 사용해야하기에 협업이 잘 되어야 한다 🤝 SockJS SockJS란 웹 애플리케이션과 웹 서버 간에 실시간 양방향 통신을 가능하게 해주는 JavaScript라이브러리다. SockJS는 웹 소켓(WebSocket)을 사용할 수 있는 경우에는 웹 소켓을 사용하여 통신하지만, 웹 소켓을 지원하지 않는 경우에는 다른 대안 수단으로 통신하도록 해주는 유용한 라이브러이다. [웹 소켓을 지원하지 않는 환경에서의 SockJS](https://dev-gorany.tistory
[WebSocket] WebSocket, STOMP
웹 소켓 1-1. 웹 소켓이란? 웹 소켓이란 클라이언트와 서버 간의 연결을 길게 유지하고, 이 연결을 통해서 양방향으로 데이터를 전송할 수 있게 해주는 통신 규약이다. 그리고 실시간성을 보장한다. 따라서 채팅, 알림, 실시간 주식 거래 사이트 등의 기능을 제공할 때 사용된다. 그런데, HTTP에서도 Polling, Long Polling, Streaming와 같이 실시간성을 보장하는 기법들이 존재하는데 웹 소켓을 사용하는 이유는 무엇일까? 웹 소켓과 HTTP의 차이점은 다음과 같다. 1-2. HTTP와의 차이 HTTP 비 연결성: 따라서 매번 연결을 맺고 끊는 과정에서 비용이 발생한다. Request - Response 구조: 일반적인 HTTP 통신은 클라이언트의 요청에서 통신이 시작된다. 따라서 채팅이나 알림 서비스와 같이 서버 측에서 발생한 데이터를 사용자에게 전달하는 기능을 만들기는 어렵다. 매 요청과 응답을 보낼
[JAVA] 실시간 Python 파일 실행하여 진행도 확인하기 (2) - WebSocket (SockJs, Stomp)통신
1. 목적 이전 포스팅에서는 자바에서 Python 파일을 직접 실행하여 한 줄 씩 결과 값을 Log로 출력하는 것을 해보았다. 이번에는 서버에서 출력하는 값을 실시간으로 클라이언트로 가져와 뷰에서 값이 출력하는 것을 해볼 것이다. Websocket 통신으로 SockJs와 Stomp를 사용하였다. 2. Websocket 통신 - SockJS와 Stomp WebSocket 실시간 양방향 통신을 위한 프로토콜. 서버와 클라이언트 간 웹 기반의 애플리케이션에서 데이터를 전송하기 위해 사용된다. SockJS WebSocket의 대안으로 사용되는 JavaScript 라이브러리. 브라우저 웹 서버 사이 짧은 지연시간과 크로스 브라우징을 지원하며 Websocket이 지원안되는 최신 브라우저에서도 잘 작동되도록 해준다.(Fallback) STOMP 간단한 텍스트 기반 메시징 프로토콜. 중개자 역할을 하는 서버와 클라이언트 간의 표준 메시징 프로토콜이다.
STOMP에 RabbitMQ를 추가해보았다.
이전 게시글에서는 웹소켓에서 STOMP 프로토콜을 추가해 채팅 서버를 구현해보았습니다. 이번에는 STOMP에 외부 메시지 브로커인 RabbitMQ를 추가해보았습니다. STOMP 프로토콜로만 채팅서버를 구현했을 때는 다음과 같습니다. > - Spring 환경에서 STOMP 프로토콜을 사용한다면 메시지 브로커로 In Memory Broker을 사용하게 됩니다. registry.enableSimpleBroker("/sub"); 이 부분이 내장된 인메모리 메시지 브로커를 활성화하는 것입니다. /sub로 시작하는 대상 주제를 가진 클라이언트에게 메시지를 브로드캐스트합니다. 즉 , **`/su
[Sprinboot] WebSocket, STOMP 활용한 채팅 기능 - 2 (채팅방 입장)
채팅방 입장 ChatRoomController 4, 채팅방에 들어갔을 경우 입장메시지를 띄워주는 역활을 합니다. 유저가 처음들어갔을 경우에는 ROOMIN, 유저가 나갔다가 다시 들어갈 경우는 EXIT으로 convertAndSend("/topic/chats/" + chatRoom.getId() 구독을 통하여 메시지를 던져줍니다. ChatRoomService 1, findById(roomId) 채팅방이 존재하는지 찾기 위한 로직 2, canAddChatRoomUser 채팅방에 유저가 들어갈 수 있는지 확인해주는 로직 3, getByIdAndUserId 실질적으로 방에 들어가는 로직입니다. 유저가 방에 들어갈 수 있는 상태인지 Service 부분에서 한번 더 체크합니다. 5, 방에 들어간 유저를 COMMON 타입으로 바까주는 로직입니다. COMMON으로 바뀐 유저는 현재 채팅방에 들어가있는 상태의 유저입니다. 6, 저희 서비
STOMP 파헤치기
개요 프로젝트들에서 자주 사용한 STOMP 프로토콜에 대해서 조금 더 깊게 정리하고자 작성하게 됐습니다. STOMP란 무엇인가? Simple Text Oriented Messaging Protocol의 약자로, 웹소켓의 서브 프로토콜 입니다. 웹소켓과는 다르게 다음과 같은 특징을 가집니다. 규격화된 형식 (Frame) 웹소켓은 Text와 Binary 형식의 타입을 정하긴 하지만, 어떤 규격도 정해져 있지 않습니다. 하지만 STOMP는 다음과 같은 형식을 따라갑니다. 아래는 실제 제 프로젝트에서 사용되고 있는 STOMP의 예시입니다. 
웹 소켓 -> STOMP로 변경한 채팅 서버
이전 게시물에서는 웹 소켓을 이용한 채팅 서버를 구현해 보았다. 그러나 웹 소켓만으로는 채팅서버에 문제가 있습니다. 웹 소켓에 대한 문제점 다음과 같이 채팅방 식별자(아이디)와 Set을 Map 자료구조를 통해 구현했습니다. > 웹 소켓 서버가 2대 이상이라면, 메모리 기반으로 관리하는 세션 정보를 서로 알아야 합니다. > → 즉, 다른 서버에서 생성한 세션 정보를 서로 공유해야 하는 문제점이 있습니다. STOP란 메세징 전송을 효율적으로 하기 위한 프로토콜로 pub/sub 기반으로 동작한다. 메시지를 송신, 수신에 대한 처리가 명확하게 정의할 수 있다. WebsocketHand