실시간 통신, 어떻게 할래? 🤔 폴링부터 WebSocket까지

_sw_·2025년 3월 2일

우연한 기회를 통해서 실시간 통신 방식들을 서로 비교해봐야할 상황이 생겼다.

실시간과 관련해서는 거의 경험이 없다시피 했고, 대충 WebSocket 개념 정도..? 만 알고있었다.

언제가되든 실시간과 관련된 기능을 꼭 한 번 경험해볼 날이 올 것 같아 다양한 방식들을 알아보는 시간을 가졌다..!

Polling

Polling은 특정 장치가 다른 장치의 상태를 주기적으로 검사하고, 일정 조건을 만족할때 송수신 자료처리를 하는 방식을 말한다. 웹에서 실시간 통신을 폴링 방식으로 구현할 경우, 클라이언트는 일정 주기로 서버에 요청을 보내어 상태를 확인한다.

폴링 방식은 구현 방식이 가장 간단하지만, 서버로 보내는 요청이 길어질 수 록 서버 리소스 낭비가 심해지고, 이벤트가 발생하는 시점과, 서버가 요청에 대한 응답을 보내는 시점이 정확하게 일치하지 않기 때문에 실시간 성에서 단점을 가진다.

Long Polling

Long Polling은 Polling과 반복적으로 서버에 요청을 보내는 측면에서는 같지만 다음과 같은 특징을 가진다.

Polling과는 달리 서버에 요청을 보내고 서버에서 곧바로 응답을 보내는 것이 아니라 이벤트가 발생하기 까지 일정시간 대기 했다가 이벤트가 발생하면 응답을 내려주는 방식이다.
이벤트가 발생하면 즉시 응답하고, 일정 시간이 지나면 타임아웃 처리 후 다시 요청한다.

Long Polling은 이벤트 발생 빈도가 매우 높다면, 일반 Polling과 차이가 줄어들지만, 그렇지 않은 경우에는 서버 부하를 줄이는 데 더 효과적이다.

Server-Sent Event (SSE)

SSE(Server-Sent Events)는 서버 → 클라이언트 단방향 통신을 형성하여, 클라이언트가 별도의 요청을 보내지 않아도 서버가 지속적으로 이벤트를 푸시할 수 있는 방식을 말한다.

초기에 클라이언트가 연결 요청(Request Connect)을 보내고, 서버가 OK 응답을 반환하면 단방향 통신이 유지되면서 서버에서 여러 이벤트를 보낸다.

연결을 종료할 때는 클라이언트가 명시적으로 연결 해제 요청(Request Disconnect)을 보내거나,서버에서 특정 조건(예: 타임아웃, 리소스 제한 등)에 의해 연결을 종료할 수도 있다.

SSE는 서버에서 이벤트가 발생했을 때 클라이언트로 메세지를 보내기 때문에 실시간 성이 뛰어나지만 HTTP/HTTPS 프로토콜에 따라 도메인에 연결할 수 있는 요청 개수가 한계가 있다.

HTTP의 경우 6개, HTTPS의 경우 100개 정도이기 때문에 대규모 서비스에서 SSE를 활용하는 것에는 어려움이 있을 수 있다.

또한, 양방향 연결이 아닌 서버에서 클라이언트로 연결되는 단방향 연결이기 때문에 클라이언트와 서버의 양방향 통신이 필요한 경우에는 적절하지 않은 방식이다.

Web Socket

Web Socket은 웹 브라우저에서 소켓 통신을 가능하게 설계된 방식으로 양 끝단의 컴퓨터가 서로 자유롭게 데이터를 주고받을 수 있다는 점이 특징이다.

기존 소켓 통신을 브라우저에서 활용할 수 있도록 최적화 된 방식이기 때문에 아래와 같은 소켓 연결 / 해제 과정을 따른다.

connect()
- 클라이언트가 서버로 WebSocket 연결 요청을 보냄. ( HTTP / HTTPS )
- HTTP 요청의 헤더로 Upgrade : websocket 을 함께 보내 연결된 이후 WebSocket 프로토콜로 전환하여 요청/응답을 처리
read() / write()
- WebSocket 연결이 완료된 상태에서 서버/클라이언트 순서에 관계없이 데이터를 주고 받을 수 있음
- HTTP/HTTPS 프로토콜 대신 WS/WSS 프로토콜을 활용한다.
close()
- 클라이언트의 close()을 보내 소켓 통신을 중단한다.

🧐 Why HTTP → WS?

그냥 두 프로토콜의 목적이 다르기 때문이다.

WebSocket 프로토콜은 전이중 통신을 지원하는 프로토콜이고, 연결된 이후 클라이언트와 서버 간 연결을 지속하며 동시에 데이터를 주고 받을 수 있다.
HTTP의 경우 요청-응답 프로토콜이며 WebSocket과 다르게 요청을 보내는 경우에만 응답을 받을 수있고, 응답을 받으면 연결을 종료한다.

그 외

여러 통신 방식을 찾아보면서 추가로 언급된 방식들이다. 짧게 읽어본 내용들이라 디테일하게 파악하진 못했지만 주로 멀티미디어와 관련된 실시간 통신 방식인 것으로 보였다. 이번 실시간 통신 방식들을 주로 서버로부터 메세지를 받거나 서버의 이벤트를 감지하기 위한 목적의 실시간 통신을 비교해보고 있었기 때문에 해당 방식들은 조금만 알아보았다..ㅎ

Web Real Time Communication (WebRTC)

웹 브라우저간 외부 플러그인의 도움 없이 P2P 통신이 가능하도록 설계된 API. 음성 통화, 화상 통화, 파일 공유 등에 활용한다.

https://webrtc.org/?hl=ko

HTTP Live Streaming (HLS)

HTTP 기반 적응형 비트레이트 스트리밍 통신 프로토콜을 의미하며, 여러 미디어 플레이어에서 HTTP 기반 파일을 작은 단위로 다운로드하여 잠재적으로 무한한 전송 스트림을 적재하며 동작하는 방식.

https://ko.wikipedia.org/wiki/HTTP라이브스트리밍

Fin.

우연한 기회로 실시간 통신들의 여러가지 방식을 알아보게 되었다.

어떤 곳에 어떤 방식을 적용하는 것이 좋을지 생각도 해밨다. 각 바식을 이해하면서 각 방식의 장단점이 명확하다는 생각이 들었고, 어느 한가지만 사용한다기 보다 서로 단점을 보완할 수 있게 여러가지 방식을 함께 활용하고 있을 수 도 있겠다는 생각도 들었다.

예를 들어 SSE의 경우 도메인에 연결할 수 있는 인스턴스의 수가 적기 때문에 모든 개체를 무한정 연결해두었을 때 나중에 연결조차 하지 못하는 경우가 발생할 수 있다.

이 경우에는 특정 이벤트가 발생하는 시점을 대략 예측할 수 있다는 가정하에 롱 폴링과 SSE를 섞어 사용해볼 수도 있을 것 같다.

특정 이벤트 처리를 위해 9분이 걸린다고 하면 7 ~ 8분 쯤에는 롱 폴링으로 실시간 통신을 시도하고, 이벤트 발생 확률이 높은 9분 대에는 SSE를 적용하여 실시간성을 최대한 높이면서 짧은시간 연결을 유지하도록해서 현재 연결상태에 있는 인스턴스의 개수를 최소한으로 유지할 수 있을 것 같다.

이런 생각들이 옳은 방향으로 생각하고 있는 것인진 모르겠지만, 이런 식으로 여러가지 생각을 많이 해볼 수 있었던 주제였던 것 같다.