(네트워크)폴링방식 vs 롱 폴링방식
*리얼타임 웹을 위한 기법으오 일정한 주기를 가지고 서버와 응답을 주고받는 방식이 폴링방식이다.
이는 Ajax Polling이라고도 불리는데 주로 Ajax호출을 사용하기 때문이다.
하지만 이 폴링기법은 두 가지 문제가 있는데, 폴링 주기에 관한 문제로 주기가 짧으면 서버의 성능에 부담이 가고, 주기가 길면 실시간 성능이 약간 떨어지는 문제가 있다.
그래서 이 폴링의 지연을 최대한 줄이기 위해 comet을 구현하는 방법이 있고 이 방법 중에 하나가 롱폴링기법이있다. 이 롱폴링 방식은 서버 측에서 접속을 열어두는 시간을 길게하는 방식이다.
롱폴링 에서는 이벤트가 발생하면 바로 응답이 이루어지기 때문에 실시간성이 아주 높으며,스트리밍 방식과 달리 웹브라웆 환경에 관계없이 사용할 수 있기 떄문에 흔히 사용하는 방식이다.
롱폴링 방식외에 스트리밍 방식이 있는데 이 스트리밍 방식은 하나의 웹 요청에 대해 웹 접속을 계속 열어두고, 새로 이벤트가 발생하면 발생할 때마다 부분적인 응답으로 브라우저로 보내는 방식이다.
-간단한 구현
- 쓸모없는 요청-응답 때문에 많은 트래픽이 낭비됨
- 반복하는 주기가 짧지 않은 경우, 폴링기법 추천
(예: 페이스북 웹채팅에서 사용자 리스트 갱신주기 1분-폴링기법 사용)
-서버에서 커넥션을 물고 기다리고 있으며, 이벤트의 업데이트가 있을 경우 클라이언트로 응답을 준다.
Long-Polling방식은 소켓처럼 거의 실시간으로 응답을 받게 할 수 있습니다.
하지만 만약 100명이상이 채팅하는 환경이라면???
-->Long-Polling방식은 구조상 누군가가 말 한마디 하는 순간 100명의 유저가 동시에 응답을 받고, 다시 응답을 받기 위한 호출(Request)을 100명 모두가 동시에 하게 됩니다.
순간적으로 Request Queue가 쌓이게 될테니 서버가 버벅대거나 심하면 뻗을 수도 있습니다.
(참고로 IIS의 Max Request Limits는 5000개 라고 하네요.)
참고: http://onecellboy.tistory.com/210
이는 Ajax Polling이라고도 불리는데 주로 Ajax호출을 사용하기 때문이다.
하지만 이 폴링기법은 두 가지 문제가 있는데, 폴링 주기에 관한 문제로 주기가 짧으면 서버의 성능에 부담이 가고, 주기가 길면 실시간 성능이 약간 떨어지는 문제가 있다.
그래서 이 폴링의 지연을 최대한 줄이기 위해 comet을 구현하는 방법이 있고 이 방법 중에 하나가 롱폴링기법이있다. 이 롱폴링 방식은 서버 측에서 접속을 열어두는 시간을 길게하는 방식이다.
롱폴링 에서는 이벤트가 발생하면 바로 응답이 이루어지기 때문에 실시간성이 아주 높으며,스트리밍 방식과 달리 웹브라웆 환경에 관계없이 사용할 수 있기 떄문에 흔히 사용하는 방식이다.
롱폴링 방식외에 스트리밍 방식이 있는데 이 스트리밍 방식은 하나의 웹 요청에 대해 웹 접속을 계속 열어두고, 새로 이벤트가 발생하면 발생할 때마다 부분적인 응답으로 브라우저로 보내는 방식이다.
-간단한 구현
- 쓸모없는 요청-응답 때문에 많은 트래픽이 낭비됨
- 반복하는 주기가 짧지 않은 경우, 폴링기법 추천
(예: 페이스북 웹채팅에서 사용자 리스트 갱신주기 1분-폴링기법 사용)
-서버에서 커넥션을 물고 기다리고 있으며, 이벤트의 업데이트가 있을 경우 클라이언트로 응답을 준다.
- 구현기술
- iframe : 구현이 쉬우나 로딩이 표시되고 크로스 도메인을 지원하지 않음
- htmlFile : IE 에서만 동작함
- JSONP : 대중적인 사용방식, 크로스도메인 문제 해결
- XmlHttpRequest : 크로스 도메인을 지원하지 않음
<폴링방식과 롱폴링 방식 선택하기>
- Long-Polling 방식을 선택해야 하는 경우
- 약 3초간의 오차로 실시간 응답이 필요한 경우
- 메신저 같이 1:1이나 약 10명 이하의 상대와 채팅하는 경우
- 채팅서버만 분리 할 수 있는 경우
- Poliing 방식을 선택해야 하는경우
- 응답이 실시간이 아니어도 괜찮거나 3초 이상의 시간차가 발생해도 무난한 경우
- 약 10명 이상의 상대와 채팅해야 하는 경우
- 다른 서버 어플리케이션과 함께 동작해야 하는 경우
Long-Polling방식은 소켓처럼 거의 실시간으로 응답을 받게 할 수 있습니다.
하지만 만약 100명이상이 채팅하는 환경이라면???
-->Long-Polling방식은 구조상 누군가가 말 한마디 하는 순간 100명의 유저가 동시에 응답을 받고, 다시 응답을 받기 위한 호출(Request)을 100명 모두가 동시에 하게 됩니다.
순간적으로 Request Queue가 쌓이게 될테니 서버가 버벅대거나 심하면 뻗을 수도 있습니다.
(참고로 IIS의 Max Request Limits는 5000개 라고 하네요.)
하지만 아까 말했듯이 실시간 응답이 매우 중요한 요소이며, 종종 버벅대거나 뻗어도 상관없을정도로 채팅서버만 물리적으로 분리 해도 되는 환경이라면 Long-Polling도 괜찮은 선택이고,
그 외의 상황이라면 기본적으로 Polling방식의 채팅을 구현하는것이 안정적일 것 같습니다.
그 외의 상황이라면 기본적으로 Polling방식의 채팅을 구현하는것이 안정적일 것 같습니다.
Performance Counter로 시스템을 감시해보면 그 차이가 더욱 명확하다.
Long-Polling방식은 유저들이 아무말도 안하고 있을 땐 리소스를 거의 먹지 않고 있다가
누군가 말하기 시작하면 카운터가 불규칙적으로 요동치기 시작합니다.
Polling방식은 말하든 안하든 주기적으로 새로고침 할 뿐이니깐 일정주기별로 물결그래프가 그려진다. 아무래도 Polling 방식이 다른 서버 어플리케이션과 함께 동작할 경우 오버헤드를 체크하기가 훨씬 쉽다.하지만 유저가 아무것도 안해도 쓸데없이 리소스를 먹는다.
하지만 Polling 방식으로 구현해도 혹시나 Server Request가 동시에 일어나게 되는 구조로 구현하신다면 Long-Polling의 단점을 그대로 안게 되므로 장점이 없어져 버립니다.
참고: http://onecellboy.tistory.com/210
댓글
댓글 쓰기