💡 개요
아래의 코드는 chat-service 의 WebSocketConfig.registerStompEndpoints() 메서드를 사용해 WebSocket 엔드포인트를 지정하는 부분이다.
@Override
public void registerStompEndpoints(StompEndpointRegistry registry) {
registry.addEndpoint("/ws")
.setAllowedOrigins("<http://localhost:3000>")
.withSockJS();
}
오늘은 저 SockJS에 대해 정리해 보자.
📕 SockJS
SockJS란 WebSocket을 사용할 수 없는 환경에서도 양방향 통신을 사용할 수 있도록 지원하는 기술이다.
만약 클라이언트와 서버 모두 WebSocket을 지원한다면 그냥 WebSocket을 그대로 사용한다.
그 이유는 SockJS의 기본 연결 방식이 WebSocket이기 때문이다.
위의 네트워크 로그에서 볼 수 있듯이, 클라이언트는 서버로 보내는 HTTP 요청에 Upgrade: websocket 헤더를 추가했다.
현재 내가 사용 중인 크롬 브라우저와 Spring 백엔드 서버는 모두 WebSocket을 지원하기 때문에, 101 Switching Protocols 응답이 성공적으로 반환된 것이다.
하지만 구형 브라우저(HTML5 이전 버전)나 서버의 문제로 인해 이러한 WebSocket 통신을 사용할 수 없는 경우에 SockJS를 사용하는 것이다.
WebSocket을 사용할 수 없는 경우 대체 방법이 대표적으로 두 가지 있다.
🚀 XHR Streaming
XHR Streaming은 클라이언트가 서버에 한 번 연결한 후, 서버가 데이터를 여러 번 보내는 방식이다.
- 클라이언트가 서버에게 AJAX 요청을 보냄
- 클라이언트와 서버 간의 연결이 수립되고, 서버는 지속해서 클라이언트에게 데이터를 보냄
- 클라이언트는 데이터를 수신함
- 이 과정이 반복됨
🚀 XHR Polling
XHR Polling은 클라이언트가 일정한 간격으로 서버에 요청을 보내 데이터를 가져오는 방식이다.
- 클라이언트가 일정 주기로 서버에 요청을 AJAX 요청을 보냄
- 서버가 새로운 응답이 있으면 응답함
- 만약 새로운 데이터가 없으면 서버는 클라이언트의 요청을 대기시킴 (Long Polling)
- 이 과정이 반복됨
🤔 느낀 점
이 두 방식은 마치 WebSocket처럼 지속적인 데이터 흐름을 제공하는 것처럼 보일 수 있다.
그러나 WebSocket처럼 완전한 양방향 통신을 지원하는 것은 아니며, 클라이언트가 요청을 보내야 서버가 응답할 수 있다는 차이가 있다.
그럼에도 불구하고, 클라이언트 입장에서는 WebSocket과 유사한 실시간 통신 경험을 제공할 수 있다.
'개발 일기' 카테고리의 다른 글
[개발 일기] 2025.02.13 - 자바 record (0) | 2025.02.13 |
---|---|
[개발 일기] 2025.02.12 - 스티키 세션 (1) | 2025.02.12 |
[개발 일기] 2025.02.10 - 디미터의 법칙 (1) | 2025.02.10 |
[개발 일기] 2025.02.09 - IP보안 (0) | 2025.02.09 |
[개발 일기] 2025.02.08 - 함수형 프로그래밍 (0) | 2025.02.08 |