Websocket & STOMP 란?

📌 Websocket란?

Websocket은 클라이언트와 서버 간의 전이중 양방향 통신

💡 주로 데이터를 보내거나 받는 데 사용되며 빈도가 높고 대기 시간이 짧으며, 클라이언트와 서버 간에 TCP 연결을 만들고 둘 중 하나가 연결을 끊을 때까지 둘 다 데이터를 교환할 수 있다.

✨🚨 Websocket 의 특징

1) 양방향 통신(Full-Duplex)
데이터 송수신을 동시에 처리할 수 있는 통신 방법
클라이언트와 서버가 서로에게 원할 때 데이터를 주고 받는다. (통상적인 HTTP 통신은 클라이언트가 요청을 보내는 경우에만 서버가 응답하는 단방향 통신 )

2) 실시간 네트워킹(Real Time-Networking)
웹 환경에서 연속된 데이터를 빠르게 노출한다.
여러 단말기에 데이터를 빠르게 교환한다.
ex) 채팅, 주식, 비디오 데이터

➡️ 웹 소켓 이전의 비슷한 기술

Polling : 일정 주기로 요청을 송신하는 것.
실시간 네트워킹에서는 언제 통신이 발생할지 예측이 불가능하므로 불필요한 요청과 연결을 생성한다.
즉 바뀐게 없는데도 요청을 계속하고 응답도 계속 한다.

Long Polling
Polling의 단점을 해소하기 위해서 서버에서 조금 더 대기를 하면서, 이벤트가 발생할 때 응답을 하는 방식
응답을 받으면 끊고 다시 재요청한다.
결국 많은 양의 메시지가 쏟아지면 Polling과 동일해진다.

Streaming
서버에 요청 보내고 끊기지 않은 연결상태에서 끊임없이 데이터를 수신한다.
클라이언트에서 서버로의 데이터 송신이 어렵다.

🏷️ 세 개의 방식 모두 HTTP를 통해 통신하기 때문에 요청/응답 모두 헤더가 불필요하게 크다는 단점이 있다.

---

🔖 HTTP를 통한 Websocket

✨ HTTP RESTful Api에서 클라이언트는 서버에 요청합니다. 서버는 요청을 처리하고 HTTP 상태 코드(및 데이터)로 응답한다.

그러나 서버가 모든 클라이언트에 알림을 보내려는 경우 API를 통해 효율적이지 않고, 클라이언트는 긴 폴링 메커니즘을 사용해야하며 클라이언트는 데이터를 수신하자마자 데이터 및 서버 응답을 서버에 계속 요청한다.

이 경우 데이터를 사용할 수 있는지 여부에 관계없이 서버는 데이터를 사용할 수 있는지 여부를 확인하는 데 동작한다.

Websocket은 양방향 통신을 생성한다. 즉, 클라이언트와 서버 모두 데이터를 보내거나 받을 수 있다.

---

🚨 HTTP vs 웹 소켓 차이점

지금까지 존재했던 통신방법과 WebSocket의 결정적인 차이는 프로토콜에 있다.

WebSocket 프로토콜은 접속 확립에 HTTP를 사용하지만, 그 후의 통신은 WebSocket 독자의 프로토콜로 이루어진다. 또한, header가 상당히 작아 overhead가 적은 특징이 있다.

장시간 접속을 전제로 하기 때문에, 접속한 상태라면 클라이언트나 서버로부터 데이터 송신이 가능하다.

더불어 데이터의 송신과 수신에 각각 커넥션을 맺을 필요가 없어, 하나의 커넥션으로 데이터를 송수신 할 수 있다.

➡️ WebSocket 소켓이 필요한 경우

• 실시간 양방향 데이터 통신이 필요한 경우.
• 많은 수의 동시 접속자를 수용해야 하는 경우.
• 브라우저에서 TCP 기반의 통신으로 확장해야 하는 경우.
• 개발자에게 사용하기 쉬운 API가 필요할 경우.
• 클라우드 환경이나 웹을 넘어 SOA(Service Oriented Architecture) 로 확장해야 하는 경우

💡 WebSocket 서버의 종류

• pywebsocket(apache)
• phpwebsocket(php)
• jWebSocket(java,javascript)
• web-socket-ruby(ruby)
• Socket.IO(node.js)

---

📌 STOMP란?

STOMP는 간단한 텍스트 지향 메시징 프로토콜

💡 Spring의 STOMP 지원을 사용할 때 Spring WebSocket 애플리케이션은 클라이언트에 대한 STOMP 브로커 역할을 한다.

메시지는 메시지 처리 방법 또는 구독을 추적하고, 구독된 사용자에게 메시지를 브로드캐스트하는 간단한 메모리 내 브로커로 라우팅된다.

실제 메시지 브로드캐스팅을 위해 전용 STOMP 브로커(예: RabbitMQ, ActiveMQ 등)와 함께 작동하도록 Spring을 구성할 수도 있다.

이 경우 Spring은 브로커에 대한 TCP 연결을 유지하고, 메시지를 릴레이하며, 연결된 WebSocket 클라이언트로 메시지를 전달한다.

따라서 Spring 웹 애플리케이션은 통합 HTTP 기반 보안, 공통 유효성 검사 및 친숙한 프로그래밍 모델 메시지 처리 작업에 의존할 수 있다. @Controller

---

📌 Socket.io ?

그러나 웹소켓은 HTML5의 기술이기 때문에 오래된 버전의 웹 브라우저는 웹소켓을 지원하지 않는다.

특히 자동 업데이트가 되지 않는 익스플로러 구 버전 사용자들은 웹소켓으로 작성된 웹페이지를 볼 수 없다.

따라서, 이를 해결하기 위해 나온 여러 기술 중 하나가 Socket.io 이다.

웹페이지가 열리는 브라우저가 웹소켓을 지원하면 웹소켓 방식으로 동작하고, 지원하지 않는 브라우저라면 일반 http를 이용해서 실시간 통신을 흉내내는 것이다.

Socket.io는 node.js 기반으로 만들어진 기술로, 거의 모든 웹 브라우저와 모바일 장치를 지원하는 실시간 웹 애플리케이션 지원 라이브러리이다.

이것은 100% 자바스크립트로 구현되어 있으며, 현존하는 대부분의 실시간 웹 기술들을 추상화해 놓는다.

다시 말해, Socket.io는 자바스크립트를 이용하여 브라우저 종류에 상관없이 실시간 웹을 구현할 수 있도록 한 기술이다.

---

🚩 WebSocket 사용의 어려운 점

1) 프로그램 구현에 보다 많은 복잡성 초래 :
WebSocket은 HTTP와 달리 Stateful protocol이기 때문에 서버와 클라이언트 간의 연결을 항상 유지해야 하며 만약 바정상적으로 연결이 끊어졌을 때 적절하게 대응해야 한다. 이는 기존의 HTTP 사용 시와 비교했을 때 코딩의 복잡성을 가중시키는 요인이 될 수 있다.

2) 서버와 클라이언트 간의 Socket 연결을 유지한다는 것 자체가 비용이 드는 일이다. 특히나 트래픽양이 많은 서버 같은 경우에는 CPU에 큰 부담이 될 수 있다.

3) 오래된 버전의 웹 브라우저에서는 지원하지 않는다.(물론 SockJS 라이브러리 같은 경우에는 Fallback option을 제공하고 있다.) 참고로 인터넷 익스플로어 같은 경우에는 10 버전부터 지원한다.

4) 서버와 클라이언트 간의 연결이 끊어졌을 때 생성되는 에러 메세지가 구체적이지 않아서 (예를 들어 여러가지 다른 이유로 연결이 끊어졌는데 에러 메세지가 같은 경우) 디버깅을 하는데 어려움이 많기도 하다.

---

출처 : https://helptechcommunity.wordpress.com/2020/01/28/websocket-chat-application-using-spring-boot-and-react-js/
https://kyleyj.tistory.com/59
https://inpa.tistory.com/entry/WEB-%F0%9F%8C%90-%EC%9B%B9-%EC%86%8C%EC%BC%93-Socket-%EC%97%AD%EC%82%AC%EB%B6%80%ED%84%B0-%EC%A0%95%EB%A6%AC#http_vs_%EC%9B%B9_%EC%86%8C%EC%BC%93_%EC%B0%A8%EC%9D%B4%EC%A0%90