HyeonSeo Jang
Jang-GO의 개발 블로그
개발 관련된 공부 내용을 지속적으로 포스팅 합니다.

스프링 웹 소켓 알아보기(2)

웹 소켓이란 뭘까?

웹 소켓 프로토콜

  • 웹 소켓 프로토콜은 단일 TCP연결을 통해 클라이언트와 서버가 full-duplex 즉, 전 이중 통신을 수행하는 방법이다.
  • HTTP와는 다른 TCP 프로토콜이지만 80 및 443 포트를 사용하고 기존 방화벽 규칙을 재사용할 수 있도록 HTTP를 통해 작동하도록 설계되었다.
  • WebSocket 상호작용은 HTTP 업그레이드 헤더를 사용하여 업그레이드하거나, WebSocket 프로토콜로 전환하는 HTTP 요청으로 시작한다. 
    GET /spring-websocket-portfolio/portfolio HTTP/1.1
Host: localhost:8080
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: Uc9l9TMkWGbHFD2qnFHltg==
Sec-WebSocket-Protocol: v10.stomp, v11.stomp
Sec-WebSocket-Version: 13
Origin: http://localhost:8080
  • Upgrade헤더와 Connection은 Upgrade를 사용해야함

이 경우 웹 소켓을 지원하는 서버는 확인했다는 신호로 2xx번대 상태코드가 아닌 101 Switching Protocols의 리턴이 온다.

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

성공적인 핸드셰이크 후, HTTP 업그레이드 요청을 기반으로 하는 TCP 소켓은 클라이언트와 서버 모두가 메시지를 계속 보내고 받을 수 있도록 열려 있는다.

HTTP vs WebSocket

앞서 말했듯 WebSocket은 HTTP와 호환되도록 설계되었지만 두 프로토콜이 매우 다른 아키텍처와 애플리케이션 프로그래밍 모델을 가져온다는 점을 이해하는 것이 중요하다.

HTTP

  • 보통의 REST는 여러 URL로 모델링되며, 애플리케이션과 상호 작용하기 위해 클라이언트는 request-response 스타일로 URL에 접근한다.
    이후 서버는 HTTP URL, 메서드 및 헤더에 따라 적절한 핸들러로 요청을 라우팅한다.

WebSocket

  • 그러나 WebSocket에서 일반적으로 초기 연결에 대한 URL하나만 존재한다. 그 후 모든 애플리케이션 메시지는 동일한 TCP 연결에서 흐른다.
  • 또한 HTTP와 달리 메시지의 구조나 의미(semantics)에 대한 표준화된 규약이 없다.
  • 따라서 WebSocket 클라이언트와 서버는 HTTP 핸드셰이크 과정에서 Sec-WebSocket-Protocol헤더를 통해 상위 레벨의 메시징 프로토콜을 협상해야한다.

STOMP??

STOMP는 메시지의 구조와 의미를 표준화하여 클라이언트와 서버 간의 통신을 간소화한다.

특징

  • 메시징 프로토콜 표준화 : 클라이언트와 서버가 메시지의 의미와 형식을 쉽게 이해할 수 있도록 정의
  • Pub/Sub 모델 지원 : 특정 topic에 대한 구독과 메시지 발송이 가능하며 이를 통해 채팅 애플리케이션, 실시간 알림 시스템 구현에 적합
  • WebSocket과 통합: WebSocket 핸드셰이크 요청의 Sec-WebSocket-Protocol 헤더에서 v10.stomp, v11.stomp 등을 사용해 STOMP 협상 가능.

웹 소켓을 사용하는것이 더 유리할 경우

WebSocket을 사용할 필요가 없는 경우

  • 주기적인 업데이트로 충분한 경우
    뉴스 피드, 이메일 알림, 소셜 미디어 피드와 같은 애플리케이션은 실시간 업데이트가 필요하지만, 몇 분 간격으로 업데이트되는 것으로 충분할 수 있다. 이러한 경우 WebSocket은 오히려 과한 선택이 될 수 있다.
  • 메시지 빈도가 낮은 경우
    네트워크 상태 모니터링처럼 메시지의 빈도가 낮거나 간헐적으로 발생하는 경우, HTTP 스트리밍이나 폴링 방식으로도 충분히 효율적으로 구현할 수 있다.

WebSocket이 적합한 경우

  • 실시간 상호작용이 필요한 애플리케이션
    협업 도구(문서 편집, 화상 회의), 온라인 게임, 금융 애플리케이션(주식 거래, 차트 갱신)과 같이 낮은 지연 시간(Latency)과 높은 응답성을 요구하는 경우에는 WebSocket이 훨씬 적합하다.

  • 낮은 지연 시간, 높은 빈도, 높은 메시지 볼륨의 조합
    메시지가 자주 발생하고(고빈도), 데이터의 양이 많으며(고볼륨), 실시간 처리가 필요한 애플리케이션에서 WebSocket은 가장 적합한 선택이다.

    Table of Contents