WebSocket
WebSocket은 클라이언트와 서버 간의 실시간 양방향 통신을 가능하게 하는 전이중(full-duplex) 통신 프로토콜이다.
Http의 한계와 WebSocket의 필요성
HTTP는 요청(request)과 응답(response) 기반의 단방향 통신 구조로 클라이언트가 서버에 요청을 보내기 전에는, 서버는 클라이언트에게 메시지를 전달할 수 없다.
따라서 실시간 채팅과 같이 서버가 먼저 데이터를 보내야 하는 상황에서는 비효율적
HTTP 기반 채팅에서는 사용자가 새 메시지를 보았는지 확인하려면 클라이언트가 주기적으로 서버에 요청(polling)을 보내야 하며, 이는 성능 낭비를 초래한다.
WebSocket 동작 방식
- 클라이언트는 서버에 HTTP 기반으로 WebSocket handshake 요청 전송. (해당 http에는 연결에 필요한 정보와 token인증 정보가 포함된다,)
- 서버가 이를 수락하면 연결이 WebSocket 프로토콜로 업그레이드되고, 이후에는 HTTP가 아닌 WebSocket 프레임으로 통신.
- 연결이 유지되는 동안, 클라이언트와 서버는 양방향으로 실시간 메시지 전송 가능.
이때 WebSocket 통신에서는 url 주소가 http://로 시작하는 http 프로토콜과 달리 we:// 로 시작한다
HTTP vs Web Socket
| 항목 | HTTP | WebSocket |
|---|---|---|
| 프로토콜 | 요청/응답 기반, 단방향 | 전이중(Full-Duplex), 양방향 |
| 연결 지속성 | 요청마다 새로 연결 | 연결 유지 |
| 실시간성 | 낮음 (Polling 필요) | 높음 (서버 → 클라이언트 즉시 전송 가능) |
| 전송 효율성 | 헤더 포함 반복 전송으로 오버헤드 큼 | 초기 연결 이후엔 경량 메시지 프레임 사용 |
| URI | http\:// / https\:// | ws:// / wss:// |
Polling vs SSE vs WebSocket
polling
http를 사용하고도 실시간 요청처럼 보이게 하는 방식. 클라이언트가 주기적으로 요청을 보내 업데이트를 확인하는 방법이다, 다만 지속적인 서버 request로 서버 과부하 발생 가능성이 높다.
- 장점
- 구현이 간단하고 기존 HTTP 방식 그대로 사용 가능
- 단점
- 실시간성이 낮고, 트래픽 낭비가 큼
- 사용자 수가 많아지면 서버 과부하 발생
- 불필요한 요청이 많아 네트워크 비효율적
SSE
sse(server-sent events) 기술은 HTTP 기반의 실시간 통신이다. sse 통신 기술은 서버에서 클라이언트로의 단방향 통신이며 클라이언트에서 서버로 요청하려면 일반적인 http request를 전송해야한다.
주로 실시간 업데이트가 필요한 애플리케이션에서 사용(특히, 사용자에 알림을 주기 위한 목적으로 많이 활용)
- 장점
- 구현이 간단하며 브라우저 지원도 좋음
- 실시간 알림, 주가 변동, 뉴스 피드 등에 적합
- 단점
- 단방향 통신이므로 양방향 대화에는 부적합
stomp
STOMP(Simple Text Oriented Messaging Protocol)는 WebSocket 위에서 동작하는 간단한 텍스트 기반 메시징 프로토콜.
stomp 등장 배경
웹소켓으로 클라이언트 A와 B가 1대1 통신을 한다고 하자 클라이언트 A가 메세지를 보내면 서버는 A를 포함한 B에 메세지를 전송 여기 까지는 정상 작동 이때 B가 클라이언트 C와 1대 채팅을 한다고 하면 이 그룹을 묶어서 선별적으로 서버가 데이터를 전송하는 것은 어렵기 때문에 stomp 사용
stomp 동작 과정
-
핸드셰이크
클라이언트 ↔ 서버 간 WebSocket 연결을 맺고, STOMP 프로토콜로 업그레이드 -
구독(Subscribe)
클라이언트가SUBSCRIBE프레임으로
특정 목적지(destination), 예를 들어/topic/room1을 구독 -
발행(Send)
클라이언트가SEND프레임으로
목적지에 메시지 전송 → 브로커가 받아서 내부 큐/토픽에 저장 -
전달(Message)
브로커가/topic/room1을 구독 중인 모든 클라이언트로
MESSAGE프레임을 전송
redis pub/sub을 통해 멀티 서버 고려
redis 없을 때
웹소켓 서버를 여러 대 띄우면, 클라이언트 A → 서버1,클라이언트 B → 서버2로 연결될 수 있다.
그런데 서버1에만 있는 A의 메시지를 서버2에 있는 B가 받으려면,서버 간에 “누가 누구를 구독 중인지” 공유가 필요하다.
redis 사용
위와 같은 문제를 해결하기 위해 redis의 pub/sub 기능을 사용
동작과정
- 클라이언트 A는 websocket server에 송신
- 이후 서버는 해당 메세지를 곧바로 특정 topic(room)에 전달하지 않고 공용 redis pub/sub 기능을 이용해 모든 서버에 발행(publish)
3.모든 서버는 redis를 구독(sub) 하고 있기에 redis에서 받은 message를 보고 해당 메세지의 수신자와 자신의 메모리에 있는 정보가 있다면 수신자에게 전달.
