[Java Script] HTTP 폴링, 롱폴링

 

최근에는 실시간 웹 어플리케이션 개발이 다양한 서버 측 푸시 기술을 시뮬레이션하는 폴링이란 기술을 주축으로 이뤄진다. 그중에 가장 대중적인 기술은 코멧인데 이 기술은 기본적으로 클라이언트로 메시지를 전달할 때까지 HTTP 응답을 지연시킨다.

 

 

폴링

 

- 주기적인 시간마다 클라이언트가 서버로 요청을 동기적으로 호출해서 사용 가능한 정보가 있는지 알아낸다. 요청을 주기적인 간격으로 이뤄 지며 클라이언트는 정보가 있든 없든 응답을 받는다. 구체적으로 말해, 정보가 있으면 서버는 그 정보를 송신하고 정보가 없으면 서버는 부정적인 응답을 반환하고 클라이언트는 연결을 닫는다.

- 폴링은 메시지가 전달되는 간격을 정확히 알고 있을 때 적절한 해결책이다. 왜냐하면 서버에 정보가 있음을 알고 있어야만 클라이언트를 동기화해서 요청을 전송할 수 있기때문이다. 다만, 실시간 데이터는 대체로 그렇게 예측 가능하지도 않고 불필요한 요청을 보낼 수도 있어서 과다한 연결이 불가피하다. 그래서 결국 메시지 비율은 적은데도 수많은 연결을 불필요하게 여 닫아야 할 수도 있다. 

 

리얼타임 웹을 위한 기법으로 일정한 주기(특정한 시간)를 가지고 서버와 응답을 주고받는 방식이 폴링 방식이다.

 

ex) 실시간으로 변하는 야구중계 같은 데이터가 있다면 브라우저에서 5초 단위로 서버에 요청을 보내 업데이트하는 방식(네이버 실시간 문자중계 같은거?)

 

• 만약 정보가 변하지 않으면 리소스를 낭비하고 오버헤드/트래픽이 발생한다.

• Ajax Polling이라고도 불리는데 주로 Ajax호출을 사용하기 때문이다.

• 또한 서버에서 데이터가 오지 않았는데 추가적으로 여러번 요청이 오게 되면 이전 데이터는 쓸모 없는 데이터가 되버린다. setTimeout같은 타이머를 이용해서 일정한 시간 간격으로 XMLHttpRequest를 보내 구현한다.

• 하지만 이 폴링기법은 두 가지 문제가 있는데, 폴링 주기에 관한 문제로 주기가 짧으면 서버의 성능에 부담이 가고, 죽기가 길면 실시간 성능이 약간 떨어지는 문제가 있다.

 

해결법

 

1) comet을 구현하는 방법

 

1-1) 롱폴링기법

-  클라이언트가 서버에 있는 정보를 요청하면 지정한 시간동안 연결을 열어둔다. 서버에 정보가 없으면 클라이언트가 요청한 정보가 생길 때 까지 또는 지정한 시간이 끝날 때까지 해당 요청을 열어둔다. 지정 시간이 끝나면 클라이언트는 서버에 있는 정보를 다시 요청한다. 롱 폴링은 코멧 또는 리버스 에이작스(Riverse ajax) 라고도 한다.  코멧은 서버가 클라이언트로 뭔가를 송신할 수 있을때까지 HTTP 응답 완료를 지연시킨다. 이 기법을 'GET' 또는 '미결 POST(pending -POST) 라고 부른다. 메시지 양이 많으면 롱 폴링을 사용해도 기존의 폴링에 비해 특별히 성능이 개선되지 않는 것을 염두에 두어야 한다. 클라이언트가 새 정보를 가져오기 위해 끊임 없이 서버로 재연결을 해야 하는데, 그로인해 네트워크 반응이 빠른 폴링과 같아지기 때문이다. 롱 폴링의 또다른 단점은 표준 구현이 없다는 점이다. 

서버 측에서 접속을 열어두는 시간을 길게하는 방식.

  즉, 이벤트가 발생(변경된 데이터가 있을 때만 응답)하면 바로 응답이 이루어지기 때문에 실시간성이 아주 높으며,스트리밍방식과 달리 웹브라우저 환경에 관계없이 사용할 수 있기 때문에 흔히 사용하는 방식

ex) 브라우저가 서버로 요청을 보내면 서버는 요청한 데이터가 변경되었을때만 응답을 보낸다.

Transfer-Encoding : chunked 같은 응답을 반환해서 커넥션을 유지하여 동작한다. 

만약 커넥션이 끊겼다면 클라이언트는 다시 서버에 연결을 요청한다. 

이러한 방식은 실시간으로 응답받는 경우에 적당하고 서버의 부하도 줄여주지만 데이터가 자주 바뀌는 경우(대용량 채팅)에는 한명의 유저가 채팅을 입력할 경우 엄청난 수의 변경 호출이 일어나서 적합하지 않습니다. 또한 폴링과 롱폴링 모두 오랫동안 연결되어 있는 커넥션을 최적화 하지 못하는 문제가 있다. 이 방식을 위해서는 연결된 커넥션과 요청 리스트들을가지고 있어야 한다.

 

1-2) 스트리밍 방식

하나의 웹 요청에 대해 웹 접속을 계속 열어두고, 새로 이벤트가 발생하면

발생할 때마다 부분적인 응답으로 브라우저로 보내는 방식

 

- 클라이언트가 요청을 보내면 서버는 지속적으로 업데이트 되며 무한히 또는 지정한 시간동안 열린 상태로 유지되는 오픈된 응답을 전송하고 관리한다. 서버는 메시지를 전달할 준비가 되면 응답을 업데이트 한다. 스트리밍은 왠지 예측 불가능한 메시지 전달에 적합한 해결책을 것 같아 보이지만 서버는 HTTP 응답을 완료하라는 신호를 절대 보내지 않으므로 연결이 계속 열린채로 있게 된다 이럴경우 프록시와 방화벽은 응답을 버퍼에 저장해서 메시지 전달이 더 지연될 수도 있다. 따라서 잦은 스트리밍 시도는 방화벽이나 프록시가 있는 네트워크에선 불안정하다