WebSocket

WebSocket 은 양방향 실시간 통신으로서, 지속적인 연결이 필요할 경우 사용한다.

규모가 커질 경우 외부 브로커를 별도로 두어 같이 운용하는경우가 대부분이다.

STOMP는 개발을 빨리 해야 할 때, 메세지 라우팅/권한 제어가 중요한 경우에 사용하고, 순수 WebSocket은 초저지연, 대규모 fan-out이 필요한 경우 적합하다.

 

예를들어, 채팅, 알림, 협업툴의 경우 STOMP를 쓰고, 게임, 실시간 시세, 대규모 push 같은 경우는 순수 WebSocket을 쓴다.

 

• STOMP 장점
  • @MessageMapping, @SendTo, SimpMessagingTemplate 등 Http Controller를 쓰듯 편하게 쓸 수 있다.
  • RabbitMQ 같은 메세지 브로커와 궁합이 잘 맞는다.
• 단점
  • 헤더가 많고, 텍스트 기반으로 용량이 상대적으로 큼
  • kafka와 연계가 잘 안맞음

 

대략적인 방식은 다음과 같다

• Http를 통해 클라이언트가 handshake 요청 (Upgrade 요청)
• 서버가 클라이언트 인증(주로 JWT) 후 승인 혹은 거절
• 승인시, WebSocket 으로 연결
• 주기적으로 ping, pong (톰캣에서 처리)
• 메세지 송, 수신
  • 메세지 규격을 정의 해야 하고, 이를 기반으로 메세지를 주고 받아야 한다.
• Disconnect를 통해 연결 해제

 

HandShake 절차

• 클라이언트가 ID / PWD 등으로 로그인을 수행하면서 (Http) 서버로 부터 인증정보(주로 JWT)를 받는다.
  • SSE의 경우, http를 통해 통신하므로 이미 JWT 필터를 통해 검증을 하지만, WebSocket은 프로토콜이 달라서 별도로 해야한다.
• 클라이언트가 Http GET 요청에 특정 헤더를 포함하여 요청한다. 이 부분은 Tomcat 에서 알아서 처리 한다.
  • Sec-WebSocket-Key : 내가 요청한 서버가 맞는지 확인하기 위해 클라이언트에서 키를 생성하여 보낸다. 서버는 이를 리턴해야 하고, 클라이언트는 이를 확인하여 최종 연결 한다.
  • Sec-WebSocket-Protocol 
  • Sec-WebSocket-Extensions : 데이터 압축 등 확장 기능 요청
  • Sec-WebSocket-Accept : 톰캣에서 연결 수립시 사용하는 헤더
  • Origin : 요청 도메인 정보
• WebSocket 프로토콜 처리는 톰켓이 하고, 인증, 인가 세션관리 등은 개발자가 구현 한다. (아래 부터)
• 클라이언트가 전달해준 인증 정보를 인증 (주로 JWT) 후 수립
  • HandShakeInterceptor 를 구현체로 별도로 구성하여 처리
    • beforeHandShake 메소드를 오버라이드 하여 이곳에서 JWT 검증 후 연결 수립 여부 결정
    • WebSocketSession.attributes 에 사용자 정보를 저장하여 메세지를 주고 받을때 이를 활용
      • Spring Security 에서 인증정보를 SecurityContext에 저장하는 개념과 비슷

 

메세지 송, 수신 및 연결 종료

• WebSocketHandler 를 코드로 구현하여 관리한다.
• 연결 이후 메세지 송, 수신, 오류 및 연결 종료까지 모든걸 담당
• AfterConnectionEstablished : 연결 수립 후 1번만 실행
• handleMessage : 메세지가 올 때 수행
• handleTransportError : 오류 발생시 수행
• afterConnectionClosed : 연결이 닫혔을때 한번 수행
  • 주로 연결 종료는 톰캣에서 담당하나, 비즈니스 로직에 따라 수동으로 끊을 수 있다.