[Spring] 웹소켓 Stomp 1

0. 주요 개념과 용어

HTTP 

- 비연결형, 클라이언트가 매 번 서버에 요청을 보내어 TCP 연결 시도, 요청 처리 후 연결을 끊는다.

- 클라이언트의 요청 -> 서버 응답 구조

- 서버가 먼저 클라이언트에 신호를 전달할 수 없다.

- http:// 프로토콜 사용

- TCP 기반

 

Web Socket

- 클라이언트 <-> 서버 실시간 통신 구조

- 서버가 먼저 클라이언트에 신호를 전달할 수 있다. 

- ws:// 프로토콜 사용 (Stomp 사용 시에는 생략)

- TCP 기반 

 

TCP는 기본적으로 양방향 연결 (3 way HandShake)

3 way HandShake 과정이 끝나야 데이터 전송 가능

- HTTP와 Web Socket은 기본적으로 TCP 기반이다.

- HTTP는 3 way HandShake 이후 클라이언트 요청 - 서버 응답 이후 바로 양방향 연결을 끊는다.

- Web Socket은 3 way HandShake 이후 양방향 연결을 계속 유지한다.

 

Web Socket - 3 way HandShake 이후

Web Socket 연결에서 반드시 첫 요청에 대해서는 HTTP 메시지를 통해 연결 요청을 서버에 보낸다.

 

• 클라이언트 → 서버 : HTTP 요청 + Upgrade: websocket
• 서버 → 클라이언트 : HTTP 101 Switching Protocols
• 이후 TCP 연결을 그대로 사용하며 양방향 통신 지속

 

첫 연결을 맺은 뒤에는 별도의 http 형식의 메시지 없이 통신 가능

=>  간결한 형식의 메시지를 주고 받을 수 있다.

=> 빠른 성능 보장

 

처음 요청에서만 HTTP 메시지를 보낼 수 있다.

첫 연결 시 HTTP 헤더를 통해 token, session 등 인증 정보를 보낼 수 있고, 이를 통해 인증 처리를 할 수 있다.

 

 

Polling

HTTP를 사용하면서 실시간으로 통신하는 것처럼 보여지는 코드 기법JavaScript (front) 코드에서 n초마다(특정 시간마다) 서버로 새로운 메시지가 있다면 전달한다.

장점 : HTTP 요청만 처리하면 되기 때문에 추가 설정이 필요없는 간결하다.

단점 : 많은 부하를 서버에

주면서 (특정 시간마다 계속 서버에 HTTP 요청) 동시에 완벽한 실시간 채팅이 아니다.

 

 

 

Stomp (Simple Text Oriented Message Protocol)

- Web Socket 위에서 동작하는 메시지 프로토콜

- 기존 WebSocket 통신 방식을 효율적인 방법으로 관리할 수 있도록 하는 프로토콜

- Stomp는 기본적으로 발행 Publish, 구독 Subscribe 개념으로 동작한다.

Web Socket 동작

Web Socket 동작 : A가 서버에 메시지 송신 시 A, B 모두 메시지를 수신받는다.

Web Socket의 한계 - 섬세하게 수신할 곳을 지정하여 수신하는 것이 어렵다 => Stomp 등장 배경

 

- 메시지 전송 대상 세밀 제어가 어렵다.

- 메시지 브로드캐스트 수준만 지원한다. 

 

1) client A의 http 요청, room1 구독 / client B의 http 요청, room1 구독

2) client A의 room1 메시지 송신 : broker에게 전달

3) broker는 room1에 client A의 메시지 전달

4) room1을 구독한 client A, B에게 모두 메시지 전달

 

room1 = Topic

Topic : 특정 room을 지징하는 Stomp의 관용적 용어

 

Stomp는 웹소켓 기반으로 동작을 하되, 중간에 Broker를 가진다.

Stomp는 Web Socket과 다르게 "목적지 기반 메시지 라우팅" 지원- 클라이언트와 서버가 특정 Topic (주제) 또는 경로를 기준으로 메시지를 교환하는 구조- 클라이언트에서 지정된 특정 roomId에 메시지 발행 -> broker에 의해 해당 roomId 채널에 메시지 전달- 동시에 roobId를 구독하고 있는 클라이언트에 실시간으로 메시지 전달

 

 

멀티 서버 환경에서의 Redis Pub/Sub

가정 : 동일한 여러 서버가 있고 서버 앞단에 로드 밸런서가 존재할 경우 사용자의 요청은 로드밸런서에 먼저 들어온다.

 

웹소켓 통신에서 특정 사용자는 "특정 서버 메모리에 의존적" => client A가 발행한 메시지를 client B가 다른 서버에 연결되어 있어 받지 못할 수 있다.

 

멀티 서버 환경에서는 특정 Topic을 구독한 client들의 정보가 서로 다른 서버에 있을 수 있다는 문제에 대해 Redis의 Pub/Sub 기능을 이용해 해결 가능

(Redis 또는 Kafka를 주로 사용)

 

1) Client A가 송신할 메시지를 웹소켓 서버에 송신 (로드 밸런서 -> 특정 웹소켓 중 랜덤 1개 서버에서 수신)

2) 수신한 웹소켓 서버는 메시지를 바로 특정 topic (room)에 발행하지 않고 Redis의 pub/sub 기능을 이용해 모든 서버에 메시지를 publish

3) 모든 웹소켓 서버는 redis로부터 발행된 message를 받아 각 서버의 topic (room)에 메시지 발행

4) 각 서버들은 특정 topic을 구독하고 있는 다른 Client (B)의 정보를 메모리에 가지고 있는지 확인

5) 메모리에 특정 topic을 구독하고 있는 다른 Client (B)의 정보를 가지고 있는 서버만 Client B에 메시지를 전달하고 ,다른 서버들은 전달 x

 

예시 

1) client A, B가 특정 topic room 1을 구독하고 있다.

2) Web Socket Server 3이 client B에 대한 정보를 메모리에 가지고 있다.

3) client A가 room 1 topic에 메시지를 송신한다.

4) 로드 밸런서를 거쳐 Web Socket Server 1이 client A의 메시지를 받는다.

5) Web Socket Server 1은 바로 메시지를 room1에 발행하지 않고 Redis 서버에 전달한다.

6) Redis 서버는 메시지를 받아서 모든 서버 (Web Socket Server 1, 2, 3)에 publish 한다.

7) 모든 서버들은 redis에게서 메시지를 subcribe하여 room1 topic에 메시지를 전달한다. 

8) Web Socket Server 1, 2는 client B에 대한 정보가 메모리에 없기 때문에 동작하지 않는다.

9) Web Socket Server 3이 client B의 정보를 가지고 있다.

10) Web Socket Server 3은 room 1 topic에 redis에서 받은 메시지를 전달하고 room1이 client B에 메시지를 전달한다.

 

 

/app : 발행에서의 관례적 표현

/topic : 다대다 구독에서의 관례적 표현 (단체 채팅)

/queue : 1:1 구독에서의 관례적 표현 (1:1 채팅)