Spring boot 채팅 구현 #1 HTTP, Polling, Long Polling 개념 정리

 

서론

 

미니 프로젝트를 하면서 프론트엔드에서 firebase로 채팅 기능을 구현하려고 했으나, 다소 미흡하게 끝나서 개인적으로 아쉬움이 많이 남았다.

 

그래서 다시 업데이트한다는 의미에서 이번에는 스프링부트 서버 쪽에서 채팅 기능을 구현하기로 마음먹었다.

 

그렇게 채팅 기능을 구현하기 위한 기본? 이라고 할 수 있는 Web Socket부터 다시금 공부를 시작하게 되었다.

 

그런데 역시, 프로그래밍 기술이라는 것은, 과거에 존재했던 기술의 단점을 보완하는 새 기술이 등장하는 식으로 다 연계되어있다.

 

Web Socket을 공부하다 보니, STOMP라는 프로토콜이 있다는 것을 알게 되고, STOMP를 공부하다 보니, 또 RabbitMQ나 Kafka 같은 외부 메세지 브로커의 존재를 알게 되었다.

 

그렇게 꼬리에 꼬리를 물듯이 계속해서 공부를 하다 보니, 결국 깊은 이해를 위해서는 Web Socket 전에는 어떤 식으로 통신을 했을까? 에 대한 질문까지 도달하게 되었다.

 

그렇게 해서 HTTP 통신부터 시작해서 전부 정리해 보기로 했다.

 

이번 포스팅에서는 HTTP 통신에 대한 정리부터 Polling, Long Polling, Web Socket이 나오게 된 이유까지 정리할 것이다.

 

 

HTTP 통신

 

출처 - MDN

 

HTTP는 웹 통신에서 가장 기본적인 프로토콜이라고 할 수 있다.

 

클라이언트에서 request 요청을 통해 서버로 데이터를 달라고 요청하면,

 

서버에서는 response 응답을 통해 서버에서 요청한 데이터를 돌려준다.

 

그리고 요청에 대한 응답이 끝나면 연결이 끊어진다.

 

이를 Connectionless라고 한다.

 

또한 통신이 끝나면 상태를 유지하지 않는다.

 

이를 Stateless라고 한다.

 

이 두개의 특징을 보완, 확장하기 위해 HTTP 헤더, 쿠키, 세션 등의 개념이 생겨났지만... 이하 생략

 

아무튼 이러한 특징 때문에 계속해서 업데이트가 필요한 (실시간 검색 순위, 주식 주가, 뉴스) 등의

 

데이터를 받기 위해서는, 단 한 번의 HTTP 통신으로만은 불가능하다.

 

그렇게 해서 나온 개념이 Polling이다.

 

 

Polling

 

Polling이란 일정한 간격(예: 0.5초)으로 서버에 계속 요청을 보내는 것이다.

 

그리고 서버는 요청에 맞게 데이터를 응답해준다.

 

그러나 폴링의 문제점은 아주 당연하겠지만,

 

계속 데이터를 요청해야 한다는 것이고,

 

당연히 0.5초마다 데이터를 요청한다고 해서 계속 새로운 데이터를 응답받지도 않을 것이다.

 

그래서 HTTP Overhead 오버헤드라는 문제가 발생한다. 

 

간단히 말하면 리소스 낭비가 발생한다는 것.

 

이를 보완하기 위해 나온 개념이 Long Polling이다.

 

 

Long Polling

 

 

Long Polling이 동작하는 원리는 다음과 같다.

 

1. 클라이언트가 서버에 요청한다.

 

2. 서버는 클라이언트가 사용할 수 있는 데이터가 있다면 응답한다.

 

3. 근데 만약 클라이언트가 사용할 만한 데이터가 없다면? 서버는 바로 응답하는 대신 보류하고 기다린다.

 

4. 그렇게 사용할만한 데이터가 생기면 서버는 클라이언트로 응답한다.

 

이때 Long Polling에는 제한 시간이 존재하며, 보류하는 시간이 제한 시간을 초과하게 되면

 

연결이 끊어지며, 클라이언트는 다시 요청을 해야 한다.

 

바로 응답을 하지 않는다는 특징 때문에 Hanging GET이라고도 불린다.

 

 

마무리

 

하지만 Long Polling 역시, 클라이언트에서 주기적으로 요청을 해줘야 한다는 점은 변하지 않는다.

 

기본적으로 비효율적이다.

 

바로 이 단점을 보완하기 위해서 Web Socket이 나왔는데,

 

다음 편에서는 Web Socket과 STOMP, Message Broker 등에 대해서 알아보겠다.