실시간 웹 통신: WebSocket과 STOMP

📝 필기 (Notes)

• HTTP의 근본적 한계
  • 요청-응답(Request-Response) 모델: 클라이언트가 먼저 요청하지 않으면 서버는 응답할 수 없음.
  • 실시간 통신(예: 채팅)에 부적합: 서버가 새로운 메시지를 능동적으로 클라이언트에게 보내줄 수 없기 때문.
• HTTP 기반의 실시간 통신 '흉내내기'
  • 폴링(Polling): 클라이언트가 주기적으로 서버에 "새 소식 있나요?"라고 계속 요청.
    • 단점: 대부분 불필요한 요청이며, 서버와 네트워크 자원 낭비가 심함.
  • 롱 폴링(Long Polling): 클라이언트가 요청하면, 서버는 새로운 소식이 생길 때까지 응답을 보류.
    • 단점: 폴링보다는 낫지만, 여전히 요청/연결 해제가 반복되고 서버에 부담을 줌.
• 진정한 양방향 통신, WebSocket
  • 본질: 클라이언트와 서버 간에 하나의 TCP 연결을 계속 유지하며, 양방향으로 데이터를 주고받는 프로토콜.
  • 동작 방식:
    1. 핸드셰이크(Handshake): 일반 HTTP 요청으로 시작하되, 헤더에 Upgrade: websocket, Connection: Upgrade를 담아 연결 방식을 바꿀 것을 제안.
    2. 프로토콜 전환: 서버가 동의하면 HTTP 상태 코드 **101 (Switching Protocols)**로 응답. 이 시점부터 통신 방식이 WebSocket으로 전환됨.
    3. 데이터 교환: 연결된 통로를 통해 **프레임(Frame)**이라는 가벼운 데이터 조각을 교환. 매번 무거운 HTTP 헤더를 보낼 필요가 없어 오버헤드가 극도로 낮음.
• WebSocket만으로는 부족한 점: "규칙 없는 대화방"
  • 메시지 형식의 부재: 데이터의 구조(누가, 누구에게, 무엇을)에 대한 약속이 없어 개발자가 직접 정의해야 함.
  • 발행/구독(Pub/Sub) 모델의 부재: 근본적으로 1:1 통신 채널이라, 채팅방 같은 1:N 통신 로직(누가 어떤 방에 있는지, 어떻게 메시지를 전파할지 등)을 서버가 직접 구현해야 하는 복잡함이 있음.
• STOMP: WebSocket 위에 세운 질서
  • 정의: WebSocket 위에서 동작하는, 텍스트 기반의 간단한 메시징 프로토콜. 발행/구독 모델을 쉽게 구현하도록 메시지 형식과 흐름을 정의한 약속.
  • STOMP 프레임 구조: COMMAND(명령), Headers(부가정보), Body(내용)로 구성.
    • destination 헤더가 메시지의 '주소' 역할을 함.
  • 핵심 통신 흐름:
    1. CONNECT: STOMP 프로토콜로 통신 시작 요청.
    2. SUBSCRIBE: 클라이언트가 특정 destination(주소)으로 오는 메시지를 받겠다고 구독 신청. (예: /topic/chat/room/1)
    3. SEND: 클라이언트가 특정 destination으로 메시지를 발행. (예: /app/chat/message)
    4. MESSAGE: 브로커가 구독자들에게 메시지를 전달.
• Spring에서의 구현 전략
  • Configuration (WebSocketMessageBrokerConfigurer):
    • registerStompEndpoints("/ws-stomp"): WebSocket 핸드셰이크를 위한 최초 접속 주소를 설정.
      • .withSockJS(): WebSocket을 지원하지 않는 환경에서 폴링 방식으로 자동 전환해주는 호환성 옵션.
    • configureMessageBroker(): 메시지 라우팅 규칙 설정.
      • enableSimpleBroker("/topic", "/queue"): /topic, /queue로 시작하는 주소를 메시지 브로커가 직접 처리하여 구독자에게 전달. (메모리 기반, 단일 서버용)
      • setApplicationDestinationPrefixes("/app"): /app으로 시작하는 주소는 @MessageMapping 컨트롤러에게 전달.
  • Controller (@MessageMapping, @SendTo):
    • @MessageMapping: 클라이언트의 SEND 요청을 받을 엔드포인트를 지정.
    • @SendTo: 메서드 처리 후, 결과를 특정 destination으로 발행(브로드캐스팅)할 때 사용.
    • SimpMessagingTemplate: @SendTo로 처리하기 힘든 동적 destination 전송이나 1:1 메시지 전송에 사용.
  • 보안:
    • CORS: 허용된 도메인만 접속하도록 setAllowedOriginPatterns 설정.
    • 인증/권한: ChannelInterceptor를 이용해 CONNECT 시점에 토큰을 검증하거나, 특정 destination 구독 권한을 체크.

🔑 단서/질문 (Cues/Questions)

• 전통적인 HTTP 모델이 실시간 채팅 애플리케이션에 부적합한 근본적인 이유는 무엇인가요?
• WebSocket은 Polling/Long Polling과 비교했을 때, '연결' 관점에서 어떤 결정적인 차이점을 가지나요?
• WebSocket이 이미 양방향 통신을 제공함에도 불구하고, 그 위에 STOMP와 같은 프로토콜이 필요한 이유는 무엇인가요?
• Spring 설정에서 enableSimpleBroker와 setApplicationDestinationPrefixes의 역할과 메시지 흐름의 차이를 설명해 보세요.
• WebSocket 핸드셰이크가 기존 HTTP 프로토콜을 '재치있게' 활용하는 방식은 구체적으로 어떻게 이루어지나요?

📜 요약 (Summary)

HTTP의 단방향 요청-응답 구조는 실시간 통신에 비효율적이므로, 이를 극복하기 위해 하나의 TCP 연결을 유지하며 양방향 통신을 하는 WebSocket이 등장했습니다. 하지만 WebSocket 자체는 통신 규칙이 없어, 그 위에 발행/구독 모델과 메시지 형식을 정의한 STOMP 프로토콜을 함께 사용함으로써 복잡한 실시간 애플리케이션을 체계적으로 구현할 수 있습니다.

🧠 심화 학습을 위한 질문