Polling과 Long Polling

보통 클라이언트와 서버 모델은 클라이언트가 요청을 하고 서버가 응답해주는 형태이다.

즉, 서버는 클라이언트에게 요청이 안오면 응답해주지 않는다.

실시간 웹 구현의 한계성

위와 같은 HTTP프로토콜 특성때문에 실시간을 위해 필요한 지속되는 연결을 가질 수 없다.

클라이언트에서 서버에 접속하면 응답하고 연결이 끊어진다. 이 때문에 현재 웹에서 운용되는

실시간 서비스(ex. 네이버 실시간 검색어)들은 대부분 실시간이 아니다.

PUSH SERVER

Push Server는 클라이언트의 요청이 없어도 서버가 클라이언트에게 응답을 해주는 방식이다.

하지만 HTTP 프로토콜 특성 상 실제 Push Server는 구현되지 않는다. 하지만 Push Server의

효과와 비슷한 모델들이 등장한다.

웹 서버의 Push Server 모델은 POLLING, LONG POLLING, STREAM이 존재한다.

POLLING

클라이언트가 주기적으로 웹서버에게 새로운 내용이 있는지 물어보는 방식이다.

클라이언트와 서버 모두 구현이 단순하다. 요청에 대한 서버 부담이 크지 않거나 실시간 메시지 전달이

크게 중요하지 않은 서비스에 적합하다.

POLLING의 문제점

폴링의 주기가 짧으면 서버의 성능에 부담이 간다.

주기가 길면 실시간성이 떨어진다.

LONG POLLING

클라이언트가 웹서버에게 새로운 내용이 있는지 물어보았을 때, 웹서버에 새로운 내용이 없다면 응답하지 않다가

새로운 내용이 생기면 이 때 응답해주는 방식이다.

실시간 메시지 전달이 중요하지만 서버의 상태 변경이 빈번히 발생하지 않는 서비스에 적합하다.

주기적인 POLLING 방식에 비해 불필요한 요청/응답 트랜잭션을 덜 유발한다.

그렇다고 LONG POLLING 방식이 서버 응답을 무한정 기다리는 것이 아닌 특정 시간이 지나면 해당 트랜잭션을

완료하고 새로이 요청을 한다

※ 참조 : 

http://jokergt.tistory.com/65

http://onecellboy.tistory.com/210