웹소켓 알아보기

들어가며

실시간 서비스에서 Polling, Long Polling, SSE 3가지 방식을 이용해 HTTP 통신을 할 수 있다.

그러나 해당 방식들에는 큰 단점이 하나 존재하는데 먼저 3가지 방식에 대해 알아본 뒤 얘기하도록 하겠다.

 

Polling

원하는 응답이 올 때까지 서버로 지속적인 요청을 보내는 방식이다.

 

단점

1. 트래픽 낭비

원하는 응답이 올 때까지 지속적인 요청이 필요하므로 트래픽이 낭비된다.

 

2. 요청 주기로 인해 실시간성 확보 불가능

요청-응답 구조를 통해서 통신하는 과정에서 응답 이후 다음 요청이 오기 전까지 약간의 시간 간격이 발생하는데 이때 이벤트가 발생한다면(여기서는 메일이 도착하는 경우) 실제 시간과는 오차가 발생하게 된다.

 

3. HTTP 오버헤드

HTTP 통신에서는 요청에 헤더가 함께 전송되는 것이 일반적인데, 요청이 늘어날수록 이 헤더의 양도 증가함으로써 오버헤드가 발생할 수 있다.

 

 

 

Long Polling

지속적인 요청이 필요한 Polling의 단점을 개선한 방식으로, 요청을 받은 뒤 서버에서는 이벤트 발생까지 기다렸다가 응답을 보내게 된다.

Polling 방식에 비해 불필요한 요청이 감소하고 이벤트에 대한 응답 속도가 향상되지만, 그럼에도 다음과 같은 단점이 있다.

 

단점

1. 클라이언트 수가 많아질수록 서버 부하가 증가한다.

 

 

SSE(Server-Sent Event)

해당 방식은 클라이언트가 요청하고 서버가 응답하는 구조로 되어있긴 하지만 이벤트가 발생할 때마다 서버가 응답할 뿐 클라이언트가 재요청을 하지는 않는다.

 

단점

1. 클라이언트에 문제가 생겨도 서버가 알아채기 힘들다.

 

웹소켓의 등장

앞서 얘기한 방식들의 공통적인 단점은 결국 서버와 클라이언트가 동시에 양방향으로 통신할 수 없다는 것이다.

이 단점을 해결하기 위해 웹소켓이 등장하게 되었다.

 

웹소켓은 서버와 클라이언트가 동시에 양방향으로 통신할 수 있게 해 주는데, 이는 HTTP가 가지는 2가지 특성인 비연결성(Connectionless)과 무상태성(Stateless)과 다르게 연결성, 상태성을 지니고 있기 때문이다.

 

특징

1. HTML5에 새로이 추가됨.

 

2. 텍스트/바이너리(ex. 사진) 데이터를 프레임 단위로 송수신함.

 

3. 서브 프로토콜 활용(ex. STOMP, 밑에서 설명할 예정)

웹 소켓은 실시간 양방향 통신을 위해 최소한의 기능만 포함된 API이므로 기능이 부족할 수 있다. 그래서 서브 프로토콜 사용으로 이를 보완할 수 있다.

 

4. 커스텀 URL Scheme 사용

http://', 'ftp://', 'market://'과 같은 문자열을 URL Scheme이라 부릅니다. URL Scheme을 통해 앱이 실행되는 방식은 다음과 같습니다.

1. 웹 페이지에서 하이퍼링크 클릭 시 URL Scheme이 시스템에 전달됨
2. 시스템에서 전달된 URL Scheme을 보고 실행 가능한 앱이 있는지 확인
3. 해당 URL Scheme을 받을 수 있는 앱이 있다면 앱을 실행시키며 이 URL을 함께 전달
4. 앱이 실행되면서 URL에 포함된 내용을 참조해서 특정 기능을 수행함

출처: https://developers.naver.com/docs/utils/mobileapp/#1-url-scheme-%EA%B5%AC%EC%84%B1

 

웹소켓 통신 과정

웹소켓을 이용한 통신은 다음처럼 3단계로 구분할 수 있다.

 

1. Opening Handshake

2. 양방향 데이터 송수신

3. Closing Handshake

 

이를 그림으로 표현하면 다음과 같다.

여기서 HTTP 상태 코드 101번은 서버가 프로토콜 업그레이드를 승인한다는 의미로 보내는 응답코드이다.( https://http.cat/status/101)

또한 3번 과정 같은 경우 웹소켓 통신은 양방향 통신이므로 당연히 서버가 먼저 Close 요청을 보내는 것도 가능하다.

 

STOMP(Stream Text Oriented Message Protocol)

• 웹소켓 위에서 동작하는 텍스트 기반 메세징 프로토콜로서 클라이언트와 서버가 전송할 메시지의 유형, 형식, 내용등을 정의할 수 있다.
• 특정 topic을 게시하는 Pub(Publisher), 그 topic을 구독하는 Sub(Subscriber)의 구조로 되어있다.
• 즉, Pub에서 메시지를 전송하면 연결된 모든 Sub에게 메시지가 전송된다.
• 일반적으로 채팅 시스템을 구현할 때 자주 사용된다.

 

웹소켓 관련 라이브러리

Socket.io

웹소켓 연결 실패시 HTTP 실시간 통신으로 대체할 수 있다.

 

SockJS

순차적으로 다음과 같은 방식들을 사용해서 연결을 시도한다.

 

1. 웹소켓

2. SSE

3. Long Polling

 

스프링 프레임워크를 사용해 개발하는 경우 SockJS 사용을 추천한다. 스프링에서 공식적으로 지원하고 있기 때문이다.