[WebSocket] 웹소켓이란?

들어가며

프로젝트를 진행하다 실시간 채팅 기능을 구현하게 되어, 구현하면서 공부한 것들을 정리해보았습니다.

 

Before websocket

• ajax : 새로고침 없이 사용자 몰래 요청을 주고 받고 렌더링 가능
• polling : 주기적으로 http 통신을 보내는 방식
  • 장점: 응답간격 일정하게, 일괄처리
  • 단점: 실시간은 아님, 보낼 것이 없어도 일단 보내야해서 자원 낭비. http header는 무겁다.
• long polling : time-out 될 때까지 소켓을 열어두는 방식, 연결이 끊기면 다시 연결하기
  • 장점 : 실시간
  • 단점 : 여전히 보낼 것이 없어도 계속 보내야함.

What is WebSocket?

• 특징
  • 양방향 전이중 통신을 위한 TCP 기반의 transport protocol
  • 소켓 연결을 계속해서 유지합니다.
  • 최초 연결 시 http 통신을 통해 http handshake를 진행 후 웹소켓 통신으로 전환하는 특징.
• 장점
  • 헤더가 http 보다 작아서 자원 낭비가 적음.
  • http request를 통해 handshake를 하기 때문에 추가적인 방화벽 필요 없고, 기존의 cors 등 인증 방법을 그대로 사용가능.
• 단점
  • stateful 하기 때문에, 비정상적으로 연결이 끊어졌을 때 적절할 대처가 필요하고, 따라서 구현이 복잡해질 수 있습니다.
  • 소켓을 열어놔야해서 http 대비 비용이 큼.
  • subProtocol이 필요하다. 웹소켓 자체는 사실 프로토콜이라고 부르기 애매하다. payload의 데이터를 어떻게 구성하고 해석할지에 대해서 정해놓은 것이 없다. 따라서 서브 프로콜이 필요하다.

How does is work?

• HTTP 요청
  • Connection헤더 : Upgrade를 담아서 보내서 프로토콜을 전환할 것을 알림
  • Uprade 헤더 : WebSocket을 담아서 보내서 WebSocket으로 전환할 것을 알림
  • WebSocket Protocol 헤더 : 어떤 Subprotocol을 사용할 것인지
  • Sec-WebSocket-Key: 클라이언트마다 유니크한 값
• HTTP 응답
  • 응답 코드: 101
  • Sec-WebSocket-Accpet: 클라이언트에서 보낸 Sec-WebSocket-Key를 활용하여 GUID를 만들어서 리턴
  • Sec-WebSocket-Protocol: 어떤 서브 프로코톨을 쓸 것인지 결정

SubProtocols

어떤 방법으로 frame의 페이로드를 포맷하고 해석할 것인지 정의하는 프로토콜입니다.

• AMQP
  • 금융 산업에서 만들어짐
  • 보안성이 뛰어나지만, 비교적 무거움
• MQTT
  • 기술산업에서 기기들 사이의 통신을 위해 사용
  • 가볍고, 보안성이 AMQP 보다 안좋음
• STOMP
  • Text 기반의 프로토콜이라 이해하기 쉽고, 가볍고, 웹에서 사용하기 용이함
  • 그리고 Spring에서 기본적으로 제공하고 있음.

Massage Broker

Spring 공식문서에 따르면 다양한 MessageBroker를 사용할 수 있다고 해서 찾아보았습니다.

What is Massage Brokers?

메시지를 보내는 주체가 다양하고, 받는 주체도 다양하기 때문에, 메시지를 잘 ‘전달’하는 프로세스가 필요하고, 이것을 책임지는 주체가 Broker.

비동기, 비동조, 탄력성, 보증, 확장

Who are the brokers?

• RabbitMQ
  • 많은 양의 데이터를 처리하고, 복잡한 작업을 요하고, 빠르게 응답해야할 때 적합
• ActiveMQ
  • 보안성/신뢰성이 강조된 Broker
• Kafka
  • Queue 방식 대신에, message를 log에 쌓아두고, Consumer가 읽고는 방식을 사용
  • 데이터를 남겨야하고, 빠르게 통신을 해야하는 경우에 적합하다. 신뢰성은 조금 낮다.
• SimpeStompBroker
  • Spring Stomp에서 기본적으로 제공하는 브로커.
  • 복잡한 기능을 제공하지 않음