웹 소켓이 등장하기 까지 - Polling Long Polling, Streaming, Web Socket
Polling vs Long Polling vs Streaming
About Polling, Long Polling, Stream, WebSocket
RTCS 실시간 웹 서비스를 위한 도전
기존 웹페이지는 HTTP protocol의 req/res 패러다임이라 클라이언트에서 요청을 보내야지만 그에 대한 응답을 받을 수 있었다. 하지만 요즘엔 브라우저도 개발자도 함께 발전을 하면서 동적 웹사이트를 구현하며, 웹에서는 일반적으로 클라이언트에서 서버로 요청을 보내지만, 서버에서 클라이언트에게 데이터를 전달 해 주어야 하는 상황이 발생한다. 흔히들 실시간 통신은 웹소켓을 통해 구현되어야 한다는 것을 알지만, 해당 포스팅에서는 웹소켓이 나오기전까지 어떻게 구현 되었는지 그에대한 통신 방식에 대한 특징과 종류에 대해 포스팅 해볼 예정입니다.
1. Polling
클라이언트가 서버에서 HTTP req를 주기적으로 요청하고, 그에대해 서버가 res하는 방식이다. 그렇기때문에 클라이언트와 서버 모두 구현이 단순하다. 즉, 요청에 대한 서버 부담이 크지 않거나 실시간 메세지 전달이 크게 중요하지 않은 서비스에서 구현되어야 한다.
단, 실시간 메시지 전달의 중요성에 따라 요청 주기를 조절할 수 있지만 요청 주기가 짧으면 자칫 서버에 무리를 줄 수 있기 때문에 주의해야 한다. 또한, 실시간 메시지 전달을 고려하여 요청 주기를 짧게 설정하더라도 서버의 상태가 자주 변경되지 않는다면 불필요한 요청/응답 트래픽이 많이 발생할 것이다.
2. Long Polling
클라이언트가 서버에서 HTTP req를 하면, 서버는 대기하고 있으면서 이벤트가 발생했을 때, 클라이언트에게 res하는 방식으로 말할 수 있다. 그렇기 때문에 Polling처럼 불필요한 요청에 계속 응답하는 것이 아니라 요청에 따른 커넥션 맺는 과정에서 발생하는 비용은 줄어들지만, 클라이언트가 늘어난다고 가정했을 때, 그에 따른 응답수 또한 늘어나야 하므로 Polling 방식과 큰 차이는 없어진다.
다만, Long Polling 방식은 실시간 메시지 전달이 중요하지만 서버의 상태 변경이 빈번히 발생하지는 않는 서비스에 적합하다. 보통 서버 응답을 무한정 기다리는 게 아니라 특정 시간이 지나면 해당 요청/응답 트랜잭션을 완료하고 새로이 요청하는 방식으로 구현하기 때문이다. RTCS는 클라이언트의 상태 확인(Alive Check)을 위해 ping-pong 방식을 사용하고 있으며 주기를 설정할 수 있다.
3. Streaming
Polling과 Long Polling 방식은 항상 커넥션을 걸었다 끊었다 하는 방식이었다면, 이 Streaming 방식은 이벤트가 발생했을 때 응답을 내려주는데, 응답을 완료 시키지 않고 계속 연결을 유지하는 방식이라고 말할 수 있다.
Long Polling에 비해 응답마다 다시 요청을 하지 않아도 되어 효율적이나, 연결 시간이 길어질수록 연결의 유효성 부담이 발생한다. 그래서 연결을 길게 맺고 있는 경우 연결의 유효성 관리 등의 부담이 발생한다. 스트리밍 방식도 보통 특정 시간을 주기로 연결을 재설정하도록 구현한다.
