웹 소켓 이전 HTTP 프로토콜 기반으로한 실시간 통신 방식
1. 폴링 (Polling)
- 클라이언트가 주기적(일정 시간)으로 서버에 요청을 보내는 방식
- 새로운 데이터가 없더라도 서버는 응답을 보냄
- 클라이언트는 응답을 받으면 처리, 일정 시간 후에 다시 요청을 보내는 과정을 반복
단점: 불필요한 요청 수
2. 롱 풀링 (Long Polling)
- 클라이언트가 서버에 요청을 보냄
- 서버는 새로운 데이터가 없다면 일정 시간 동안 응답을 하지 않고 세로운 데이터가 있을 때 까지 기다림
- 일정 시간 동안 새로운 데이터 없음 -> 서버는 TIME OUT 발생
- 새로운 데이터가 있음 -> 서버는 즉시 응답으로 보냄
단점: 폴링에 비해 요청 수는 줄음 그러나 아직도 많음
단점: 요청과 응답 사이에 발생하는 지연 시간
3. 서버 센트 이벤트 (Server-Sent Event)
- 클라이언트는 최소로 한 번 서버에 연결을 요청한다. 서버는 요청을 받고 이후 새로운 데이터가 생길 때마다 적절히 처리하여 클라이언트에게 응답을 보냄
=> HTTP 통신을 종료하지 않고 연결을 유지하는 방식
위 3가지 HTTP 통신 방식 모두 클라이언트의 요청에 따른 서버만 일방적으로 응답 하는 방식
완전한 실시간 통신을 보장하지 않음!
이를 해결하기 위해 웹 소켓(Web Socket) 등장!
웹 소켓 (Web Socket) 설명
- 웹 소켓은 HTML5에 등장 실시간 웹 애플리케이션을 위해 설계된 통신 프로토콜이며, TCP를 기반으로 한다.
- TCP를 기반으로 한 웹 소켓은 신뢰성 있는 데이터 전송을 보장 + 메시지의 경계를 존중 + 순서가 보장된 양방향 통신을 제공
- 서버간의 최초 연결이 이루어지면, 이 연결을 통해 양방향 통신을 지속적으로 할 수 있음!
(데이터는 패킷(Packet) 전송은 연결중단과 추가 HTP 요청없이 양방향으로 이루어짐)
* 웹 서버와 클라이언트 간의 전이중(full-duplex) 통신을 가능하게 하는 프로토콜 입니다. (실시간 통신을 위해 필요!)
+ 전이중 통신 - 클라이언트와 서버가 동시에 데이터를 주고받을 수 있음
* HTTP 통신과 달리 지속적인 연결을 유지하며 실시간 양방향 통신을 지원
+ HTTP 통신 방식 - 클라이언트가 서버에 요청(Request)를 보내고, 서버가 이에 응답(Response)하는 반이중 통신 방식, 클라이언트가 서버에게 요청을 하지 않는 이상 서버는 클라이언트에게 먼저 데이터를 보낼 수 없음.
-> 불필요한 트래픽 증가로 인한 서버 비용 증가, 요청과 응답사이의 지연시간으로 인한 실시간 통신 효율성 저하
[웹 소켓을 이용해, Client A, B의 채팅 과정]
※ 전제 조건
- 서버: 클라우드 서버 (IP: 142.xxx.xxx.xxx)
- 클라이언트: A, B 2명이 각각 다른 외부 기기에 접속
- 채팅방: room1, room2, room3 세 개의 채팅방 채널이 서버에 구성되어 있음.
- 웹 소켓 엔드포인트: /ws-stomp
- STOMP Prefixes
- 클라이언트 -> 서버 : (/pub)
- 서버 -> 클라이언트 : (/sub)
- 웹소켓세션 ID: 클라이언트의 세션 ID - "{클라이언트 이름} + _sessionID"
1. Client A의 웹 소켓 연결 및 'room1' 채널 입장
2. Client B의 웹 소켓 연결 및 'room1' 채널 입장
Client A의 웹 소켓 연결 및 'room1' 채널 입장 과정과 동일하다.
다른 것은 입장 메시지의 발송 대상자가 구독자로 추가된 Client B 도 해당한다.
3-1. ['room1'] Client A 와 Client B 의 채팅 (Client A - "안녕하세요!" 메시지 발송)
3-2. ['room1'] Client A 와 Client B 의 채팅 (Client B - "반갑습니다!" 메시지 발송)
