폴링(Polling)과 롱 폴링(Long Polling)에 대해서

HTTP 통신

http 규격은 클라이언트에서 서버로의 단방향 통신을 위해 만들어진 방법이기 때문에, 만약 서버가 클라이언트에게 무언가 데이터를 보내야 하는 상황이 생기면 대략 난감해진다. 웹소켓이 생기기 전 이를 해결하기 위해서 일반적인 http request에 약간의 트릭을 사용해서 마치 양방향처럼 작동하게 만든 기술이 바로 폴링(Polling)이다.

 

폴링(Polling)

클라이언트가 일정한 주기로 서버에게 필요한 데이터를 요청하는 방식이다.

가장 쉬운 방법이지만, 변경 사항이 있던 없던 계속 요청을 보내기 때문에 서버에 부담을 주게 된다.

따라서 데이터를 요청하는 주기가 짧아질수록 부하는 커지게 되고, 네트워크나 HTTP 커넥션을 맺기 위한 비용이 계속 발생한다. 연결을 맺고 끊는 것부터가 부담이 많은 방식이지만, 클라이언트에서 실시간정도의 빠른 응답을 기대하기 어렵다.

 

주기적으로 서버에게 물어본다.

 

롱 폴링(Long Polling)

1. 클라이언트가 서버에게 요청을 보내지만, 서버는 즉시 응답을 전달하지 않는다.
2. 특정 이벤트가 발생하거나, 전달해줄 이벤트가 없는 경우 타임아웃이 발생하면 응답을 전달하면서 연결이 종료된다.
3. 응답을 받은 클라이언트는 곧바로 다시 서버에게 데이터를 요청한다. (= http request를 보낸다.)

 

요청을 가지고 있다가 변경이 일어나면 클라이언트에게 알려준다.

 

무조건 롱 폴링이 좋은가?

폴링은 주기적으로 데이터를 요청하면서 의미 없이 서버의 리소스를 소비하게 된다.

언뜻 보기에는 이벤트가 발생했을 때만 클라이언트로 응답을 주는 롱 폴링 방식이 무조건 좋을 거 같지만, 항상 그렇지는 않다.

 

클라이언트로 보내는 이벤트들의 시간간격이 좁다면 기존의 폴링과 별 차이가 없으며, 다수의 클라이언트에게 동시에 이벤트가 발생한 경우에는 곧바로 다수의 클라이언트가 서버로 접속하기 때문에 서버의 부담이 급증하게 된다.

 

예를 들어, 100명이 채팅하는 단체 채팅방을 롱 폴링으로 구현한다고 가정하면, 누군가 한마디 메시지를 작성하면 100명이 동시에 응답을 받고, 100명이 동시에 당시 요청을 수행해야 한다. 서버의 요청 큐(request queue)에 갑작스러운 요청이 몰리면서 서버에 부하가 발생할 수 있는 것이다.

 

클라이언트에게 제공하는 서비스 성격과 특징에 따라 적절한 방식으로 선택해야 한다.

 

 

출처

폴링에 대해 알아보자