WebSocket & STOMP의 개념

Polling, Long Polling, SSE(Server Sent Event)

이전 글에서 클라이언트와 서버가 데이터를 실시간으로 주고 받는 방법으로 Polling, Long Polling, SSE를 알아보았는데, 이 방법들은 클라이언트와 서버가 동시에 양방향 통신이 불가능하다는 단점이 있다.

웹소켓은 HTML5의 새로운 기능으로, 웹 애플리케이션과 서버 간에 상시 연결을 유지할 수 있는 통신 프로토콜이다.

HTTP 프로토콜과 다르게 클라이언트와 서버 간의 양방향 통신이 가능하여 실시간 데이터 전송을 필요로 하는 다양한 애플리케이션에서 활용된다.

 

웹 소켓 특징

1. 지속적인 연결 (Connection)
연결이 한 번 성립되면 종료될 때까지 유지되므로 클라이언트와 서버 간의 상시 연결을 의미하며, 데이터 전송에 있어 빠르고 효율적인 통신을 가능한다.

2. 상태 저장 (Stateful)
웹소켓은 클라이언트가 이전에 보낸 요청에 대한 상태를 저장한다.

3. 데이터 송수신
웹소켓은 텍스트 및 바이너리(예: 이미지) 데이터를 프레임 단위로 송수신한다.

‘프레임’이란, 실제 데이터(payload)와 메타데이터(헤더)를 포함하는 개념으로, HTML에서의 body와 유사한 역할을 하는데,  소켓은 HTTP와 다르게 헤더의 양이 작기 때문에 오버헤드가 발생할 확률이 적다.

웹소켓은 최소화된 API를 제공하는데, 부족한 기능의 경우 서브 프로토콜(STOMP)을 활용하여 보완할 수 있다.

4. 프로토콜 스킴
웹소켓은 HTTP와는 다른 커스텀 URL 스킴을 사용한다.

일반적으로 HTTP는 http와 https라는 스킴을 사용하지만, 웹소켓은 ws(비보안)와 wss(보안)라는 스킴을 통해 연결된다.

 

---

웹소켓 프로토콜의 통신 과정

웹소켓 프로토콜의 통신 과정은 크게 3단계로 이루어진다.

1. 오프닝 핸드쉐이크: 클라이언트가 서버에 웹소켓 연결 요청을 보내는 단계

이 과정에서 웹소켓은 아직 열리지 않았으므로 HTTP 프로토콜을 사용하여 진행되며, 연결이 성립되면 웹소켓 프로토콜로 전환된다.

요청은 Header에 Connection : Upgrade를 추가하여 전송하면 서버에 웹소켓 커넥션을 열어주는 Switching Protocols 101 코드로 응답한다.

// 요청
GET /destination HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==    // Base64로 인코딩된 16바이트 난수값, 프로토콜 호환성 검증을 위한 키
Sec-WebSocket-Version: 13                        // WebSocket 프로토콜 버전
Sec-WebSocket-Protocol: chat, superchat          // 선택적, 사용할 서브프로토콜 나열

// 응답
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=    // Sec-WebSocket-Key에서 생성된 해시값
Sec-WebSocket-Protocol: chat                           // 선택적, 서버가 선택한 서브프로토콜

 

2. 양방향 데이터 전송: 클라이언트와 서버 간에 양방향으로 데이터가 송수신된다. 이 단계에서 클라이언트와 서버는 실시간으로 정보를 주고받을 수 있다.

이 때 프레임(frame)이라 불리는 데이터 단위로 정보를 주고받는데, 담긴 데이터 종류에 따라 다음과 같이 분류한다.

• 텍스트 프레임 - 프레임 내의 데이터가 텍스트 데이터
• 이진 데이터 프레임 - 프레임 내의 데이터가 바이너리 데이터
• 핑퐁 프레임 - 서버나 브라우저에서 자동 생성해서 보내는 프레임으로, 커넥션이 유지되고 있는지 확인할 때 사용

3. 클로징 핸드쉐이크: 연결을 종료하기 위한 단계

클라이언트 또는 서버 둘 중 아무 곳에서나 연결 종료 요청을 보내고, 상대방이 이를 수락함으로써 연결이 종료된다.

---

웹소켓의 단점

1. 프레임에 대한 헤더가 존재하긴 하지만 구체적인 메세지 형식을 지정할 수 없음

2. HTML5를 지원하지 않는 브라우저는 사용할 수 없음

 

이러한 단점을 서브 프로토콜 & 라이브러리로 극복이 가능하다.

주로 구체적인 메시지 형식을 지정하는데에 STOMP라는 서브 프로토콜을 사용하며, 웹소켓을 사용할 수 없는 브라우저의 경우 SockJS 라이브러리를 사용하여 호환할 수 있도록 한다.

추가적으로 SockJS는 웹소켓 연결 실패 시 HTTP 실시간 통신으로 대체한다.

-> 먼저 웹 소켓 연결을 시도, 실패하면 HTTP Streaming(SSE) 방식을 사용, 해당 방식 역시 실패할 경우 Long Polling을 수행한다.

---

STOMP (Simple Text Oriented Message Protocol)

TCP나 WebSocket 같은 양방향 네트워크 프로토콜 위에서 작동하는 텍스트 기반 메시지 프로토콜로 아래와 같은 특징을 지닌다.

• 헤더나, 메시지 종류, 형식, 내용 등을 정의

// WebSocket만 사용할 경우 - 형식이 없으므로 직접 정의
ws.send(JSON.stringify({
  type: "CHAT",
  room: "room1",
  message: "hello"
}));

// STOMP 사용 시 - 표준화된 형식 사용
client.publish({
  destination: '/topic/chat.room1',
  body: "hello"
});

• pub / sub 구조

// WebSocket은 단순 연결만 제공하므로 메시지 라우팅을 직접 구현해야 하지만 
// STOMP는 pub/sub 패턴을 기본 제공하여 목적지 기반 라우팅이 가능

@MessageMapping("/chat.room1")
@SendTo("/topic/chat.room1")
public String handle(String message) {
    return message;
}

---

Pub / Sub 구조

Pub / Sub을 이해하기 위해 먼저 아래의 개념에 대해 알아야 한다.

 

• Publisher(발행자): 메시지를 생성하고 전송하는 주체
• Subscriber(구독자): 메시지를 수신하는 주체
• Message Broker(메시지 브로커): 발행자와 구독자 사이에서 메시지를 중계하는 미들웨어로 RabbitMQ, Apache Kafka가 존재
• Topic(토픽): 메시지를 구분하는 기준이 되며, 메시지가 전달되는 목적지이다.
• Channel(채널): 메시지가 전달되는 파이프라인

 

1. 메시지 브로커 설정 및 토픽 생성.

2. 퍼블리셔가 메시지를 발행하고 메시지 브로커에 전송

3. 메시지 브로커는 해당 토픽의 구독자에게 메시지를 전달

4. 구독자는 자신이 구독한 토픽에 새로운 메시지가 들어올 때마다 이를 실시간으로 수신

---

정리하면 웹 소켓은 HTTP와는 다르게 브라우저와 서버 간의 양방향 통신을 가능하게 하는 프로토콜이며, STOMP는 WebSocket 위에서 Pub/Sub 메시징을 체계적으로 관리하기 위한 서브 프로토콜이다. 

또한 SockJS는 WebSocket을 호환성 문제 없이 사용하기 위한 라이브러리라고 생각하면 된다.