http 규격이 클라이언트에서 서버로의 단방향 통신을 위해 만들어진 방법이기 때문에, 웹소켓이 생기기 전에는 실시간 통신을 위해 일반적인 http request에 약간의 트릭을 사용해서 실시간인것처럼 작동하게 만든 기술이 폴링입니다.
폴링(Polling)
(클라이언트) 밥먹고싶어 -> (서버) 기다려
(클라이언트) 밥먹고싶어 -> (서버) 기다려
(클라이언트) 밥먹고싶어 -> (서버) 기다려
(클라이언트) 밥먹고싶어 -> (서버) 그래
클라이언트가 일정 주기로 서버에게 필요한 데이터를 요청하는 방식입니다.
가장 쉬운 방법이지만, 변경 사항이 있던 없던 계속 요청을 보내기 때문에 서버에 부담을 주게 됩니다.
따라서 데이터를 요청하는 주기가 짧아질수록 부하는 커지게 되고, 네트워크나 HTTP 커넥션을 맺기 위한 비용이 계속 발생합니다.
http request connection을 맺고 끊는 것부터가 부담이 많은 방식이지만, 클라이언트에서 실시간정도의 빠른 응답을 기대하기도 어렵습니다.
롱 폴링 (Long Polling)
(클라이언트) 나랑 사귈래? -> (서버) 생각할 시간을 줘
(답들을때까지 기다림)
(서버) 좋아! -> (클라이언트) 야호!
- 클라이언트가 서버에게 요청을 보내지만, 서버는 즉시 응답을 전달하지 않습니다.
- 특정 이벤트가 발생하거나, 전달해줄 이벤트가 없는 경우 타임아웃이 발생하면 응답을 전달하면서 연결이 종료됩니다.
- 응답을 받은 클라이언트는 곧바로 다시 서버에게 데이터를 요청합니다.(=http request를 날린다)
무조건 롤 폴링이 좋은가?
폴링은 주기적으로 데이터를 요청하면서 의미없이 서버의 리소스를 소비하게 됩니다.
언뜻 보기엔 이벤트가 발생했을 때만 클라이언트로 응답을 주는 롱 폴링 방식이 유용해보이지만, 항상 그렇지는 않습니다.
클라이언트로 보내는 이벤트들의 시간간격이 좁다면 기존의 폴링과 별 차이가 없으며,
다수의 클라이언트에게 동시에 이벤트가 발생한 경우에는 곧바로 다수의 클라이언트가 ㅂ서버로 접속하기 때문에 서버의 부담이 급증하게 됩니다.
예를 들어, 100명이 채팅하는 단체 채팅방을 롱 폴링으로 구현한다고 가정하면,
누군가 한마디 메시지를 작성하면 100명이 동시에 응답을 받고, 100명이 동시에 다시 요청을 수행해야 합니다.
서버의 요청 큐 request queue 에 갑작스런 요청이 몰리면서 서버에 부하가 발생할 수 있습니다.
클라이언트에게 제공해야 하는 서비스 성격과 특징에 따라 적절한 방식을 선택하는 것이 좋습니다.
| 롱 폴링 | 폴링 |
|---|---|
| - 응답을 실시간으로 받아야 하는 경우 - 메신저 같이 1대1, 혹은 적은 수의 사용자가 동시에 사용하는 경우 - 예시: 페이스북 웹채팅, 구글메신저 | - 응답을 실시간으로 받지 않아도 되는 경우 - 다수의 사용자가 동시에 사용하는 경우 - 예시: 전체 채팅이 필요한 웹 게임 |
스트리밍
롱 폴링과 마찬가지로 클라이언트에서 서버로 일단 http 요청을 합니다.
서버에서 클라이언트로 이벤트를 전달할 때, 해당 요청을 끊지 않고 필요한 메시지만 보내기를 flush 반복하는 방식입니다.
롱 폴링에 비해 서버에서 메시지를 보내고도 다시 http 요청연결을 하지 않아도 되서 부담이 경감될 것으로 보입니다.
HTML5 webSocket
롱 폴링과 스트리밍의 경우 서버에서 클라이언트로 메시지를 보낼 수는 있으나,
클라이언트에서 서버로 메시지를 보내는 것은 어렵다는 문제도 있습니다.
클라이언트와 서버와의 실시간 상호작용을 위해 만들어진 스팩이 바로 webSocket 웹소켓입니다.
오늘은 폴링을 알아보는 시간이니, 웹소켓은 나중에 알아보겠습니다.
참고내용
강준형님 기술블로그: 폴링, 롤폴링, 그리고 스프링예제
강준형님 기술블로그: 폴링, 롤폴링 그리고 자바스크립트 예제
폴링, 롱 폴링, 웹소켓
