실시간 데이터 전송 (Polling / webSocket)

이번 스프린트에서 실시간 데이터 전송에 대한 작업을 맡게 되었다.

프로젝트를 하면서 Polling과 WebSocket 에 대한 학습한 내용을 블로그에 공유해보려 한다.

 

Polling 방식

클라이언트에서 주기적으로 서버에 새로운 데이터를 요청하는 단방향성 방식이다.

setInterval( getDataFunction , 5000);

특징

• 기존 HTTP 실시간 통신 방식(COMET)이다.
• 업데이트 된 데이터가 없어도 계속해서 데이터를 줘야하므로 서버의 리소스를 낭비하게 된다.
• 폴링의 주기가 짧으면 서버 성능에 부담이 간다.
• 폴링의 주기가 길면 실시간성이 떨어진다.
• 실시간으로 데이터를 주는 건 불가능하다. 실시간 효과를 내려면 주기의 간격을 줄여야 한다. 그렇게 되면 서버에 매우 큰 부하를 주게 된다.
  • 폴링 종류 중에 롱폴링을 사용해서 실시간으로 데이터를 주고 받을 수 있다.

장점

• 코드 구현이 간단하기 때문에 생산성과 유지보수성이 좋다.
• 서버의 부담이 크지 않거나 실시간 메시지 전달이 크게 중요하지 않은 경우에 적합하다.

단점

• HTTP의 통신 빈도가 높기 때문에 실시간 대형 서비스에서 도입하기 어렵다.
• 요청의 응답 내용이 자주 변경되지 않으면 불필요한 요청 / 응답 트래픽이 발생한다

 

LongPolling

롱폴링은 일단 서버로 요청을 보내고 이 상태에서 기다리다가 서버에서 이벤트가 있다면 응답을 받고 연결이 종료된다. 그리고 클라이언트는 곧바로 다시 요청을 보내서 다음 이벤트를 기다린다.

즉, 서버에서 특정한 상태 값이 변하기 전까지는 응답을 미루는 것이다.

 

특징

• 항상 연결이 유지 되어 있다.
• 사실상 실시간 통신이 가능하다.
• 데이터 업데이트가 빈번한 경우엔 폴링에 비해 성능상 이점이 크지 않다.
  • 그렇기 때문에 실시간 통신은 웹소켓을 사용하도록 하자.

 

webSocket 방식

웹 브라우저와 웹 서버가 지속적으로 연결된 라인을 통해 실시간으로 데이터를 주고받을 수 있는 양방향성 방식이다.

WS 모듈

• 표준 웹소켓을 구현한 모듈이기 때문에 웹브라우저 뿐 아니라 어디서든 사용 가능하다.
• 간단하게 웹 소켓을 사용하고자 할 때 좋다.

 

Socket.IO

• ws 프로토콜이 아닌 http 프로토콜을 사용한다는 차이가 있다.
• Socket.IO는 먼저 폴링 방식으로 서버와 연결하기 때문에 HTTP 프로토콜을 사용한다.
• 소켓을 지원하지 않는 브라우저에서는 웹소켓 대신 자동으로 폴링 방식을 사용할 수 있다.
• 클라이언트 측에서 웹 소켓 연결이 끊겨져도 재연결을 시도하는 등의 다양한 메서드들이 준비되어 있다.

 

장점

• 양방향성 통신으로 HTTP의 한계를 극복할 수 있다.
• 폴링 방식은 주기적으로 HTTP 요청이 발생하고 연결이 끊어지지만, 웹 소켓은 클라이언트와 서버가 한 번의 요청으로 지속적으로 연결된다.
• 실시간 서비스에 유용하다.
• HTTP 방식과 달리 불필요한 요청 / 응답 헤더 데이터가 존재하지 않다.

 

단점

• 폴링 방식보다 구현이 복잡하다.

 

Polling vs WebSocket

• Polling은 클라이언트가 일정 주기마다 서버에 요청을 보내 새로운 변경사항이 있는지 확인한다. 이 방식은 서버측에 변화가 없더라도 일정 주기마다 요청을 보내 확인을 해야 하므로 불필요한 트래픽이 낭비된다. 그러나 WebSocket 방식은 한 번의 요청으로 서버와 브라우저 간의 실시간 양방향 통신환경을 가질 수 있어, 클라이언트의 요청 없이 서버가 먼저 데이터를 전송할 수 있다.
• 네트워크 탭을 확인해보면 폴링 방식은 주기적으로 클라이언트에서 서버로 요청을 보내지만 소켓은 로컬 호스트를 요청한 것과 웹 소켓을 요청한 것 두 번뿐이다.