소프트웨어 아키텍처 설계 웹 측 폴링 전략 : 폴링, 긴 폴링, 긴 연결, 웹 소켓

 

목차

① 폴링

② 긴 투표 (혜성)

③ 긴 연결 (SSE)

④WebSocket

네 가지 웹 인스턴트 메시징 기술 비교


웹측 인스턴트 메시징 기술 : 간단히 말해 인스턴트 메시징 기술은 이러한 기능을 구현하는 것입니다. 서버는 데이터 업데이트 또는 클라이언트의 변경에 즉시 응답 할 수 있습니다. 예를 들어 인스턴트 메시징 및 기타 기능은이 기술을 통해 구현됩니다. 그러나 웹에서는 브라우저의 한계로 인해 즉각적인 커뮤니케이션을 실현하기위한 몇 가지 방법이 필요합니다. 이 제한의 주된 이유는 일반적인 웹 통신에서 브라우저가 먼저 서버에 요청을 보낸 다음 서버가 응답하여 데이터의 실제 업데이트를 완료하기 때문입니다.

  웹측 인스턴트 메시징을 실현하는 방법 : 인스턴트 메시징을 실현하는 방법에는 폴링, 롱 폴링 (comet), 영구 연결 (SSE) 및 WebSocket의 네 가지 주요 방법이 있습니다. 이들은 크게 두 가지 범주로 나눌 수 있는데 하나는 짧은 폴링, 혜성 및 SSE를 포함하여 HTTP 기반으로 구현되고 다른 하나는 HTTP 기반 즉 WebSocket 기반으로 구현되지 않습니다. 다음은이 네 가지 폴링 방법과 각각의 장단점을 설명합니다.

① 폴링

  짧은 폴링의 기본 개념은 브라우저가 정기적으로 브라우저에 http 요청을 보내는 것입니다. 요청을받은 후 서버는 데이터 업데이트 여부에 관계없이 직접 응답합니다. 이러한 방식으로 구현 된 인스턴트 통신은 기본적으로 브라우저가 요청을 보내고 서버가 요청을 수락하는 프로세스이며 클라이언트가 지속적으로 요청할 수 있도록함으로써 클라이언트는 서버에서 수신 한 실시간 데이터 변경 사항을 시뮬레이션 할 수 있습니다.

  이 방법의 장점은 비교적 간단하고 이해하기 쉬우 며 구현에 기술적 인 어려움이 없다는 것입니다. 단점은 분명하다.이 방법은 지속적으로 http 연결을 설정해야하기 때문에 서버와 클라이언트의 자원을 심각하게 낭비합니다. 특히 클라이언트 측에서는 거리 측면에서 비교하고 싶은 사람이 많고 동시에 짧은 폴링을 기반으로 한 애플리케이션에 위치하면 각 사용자의 클라이언트는 http 요청을 서버 측에 미친 듯이 보냅니다. 중단없이.. 인원이 많을수록 서버 측에 대한 부담이 커지는데 이는 매우 비합리적입니다.

  따라서 짧은 폴링은 동시 온라인 사용자가 많고 성능에주의를 기울이는 웹 응용 프로그램에는 적합하지 않습니다.

var xhr = new XMLHttpRequest();
    setInterval(function(){
        xhr.open('GET','/user');
        xhr.onreadystatechange = function(){

        };
        xhr.send();
    },1000)

② 긴 투표 (혜성)

Ajax 구현 :

  서버가 클라이언트로부터 요청을 받으면 서버는 직접 응답하지 않지만 먼저 요청을 일시 중단 한 다음 서버 측 데이터가 업데이트되었는지 여부를 결정합니다. 업데이트가 있으면 응답하고, 데이터가 없으면 일정 시간 제한 (서버 측 설정)이 지나면 복귀합니다. . 클라이언트 측 JavaScript 응답 처리 기능은 연결을 다시 설정하기 위해 서버에서 반환 한 정보를 처리 한 후 요청을 다시 발행합니다.

  짧은 폴링과 비교하여 긴 폴링은 불필요한 http 요청의 수를 크게 줄여 리소스를 절약합니다. 긴 폴링의 단점은 연결이 중단되면 리소스가 낭비된다는 것입니다.

  function ajax(){
        var xhr = new XMLHttpRequest();
        xhr.open('GET','/user');
        xhr.onreadystatechange = function(){
              ajax();
        };
        xhr.send();
    }

폴링과 긴 폴링은 모두 HTTP를 기반으로하며 둘 다 고유 한 단점이 있습니다. 폴링에는 더 빠른 처리 속도가 필요하고, 긴 폴링에는 동시성을 처리 할 수있는 기능이 필요합니다. 둘 다 "수동 서버"의 표현입니다. 서버가 정보를 적극적으로 푸시하지는 않지만 클라이언트가 ajax 요청을 보낸 후 응답합니다. 이상적인 모델은 "서버 측 데이터가 변경된 후 클라이언트에 능동적으로 푸시 될 수 있음"입니다.이 "활성"서버는 이러한 유형의 문제에 대한 좋은 솔루션입니다. 웹 소켓은 그러한 솔루션입니다.

③ 긴 연결 (SSE)

  SSE는 Server-Sent Events라고하는 HTML5의 새로운 기능입니다. 서비스가 데이터를 클라이언트로 푸시 할 수 있습니다. SSE는 기본적으로 이전의 긴 폴링 및 짧은 폴링과 다르며 모두 http 프로토콜을 기반으로하지만 폴링은 클라이언트가 먼저 요청을 보내야합니다. SSE의 가장 큰 특징은 클라이언트가 요청을 보낼 필요가 없기 때문에 서버 측 데이터가 업데이트되는 한 즉시 클라이언트로 보낼 수 있다는 것입니다.

  SSE의 장점은 분명하며 클라이언트에서 서버로 많은 요청을 설정하거나 유지할 필요가 없으므로 많은 리소스를 절약하고 애플리케이션 성능을 향상시킵니다. 그리고 나중에 소개 될 SSE 구현은 매우 간단하며 다른 플러그인에 의존 할 필요가 없습니다.

④WebSocket

  WebSocket은 Html5에서 정의한 새로운 프로토콜로 기존의 http 프로토콜과 달리 서버와 클라이언트 간의 전이중 통신을 구현할 수 있습니다. 간단히 말하면 먼저 클라이언트와 서버 사이에 연결을 설정해야하며이 부분에는 http가 필요합니다. 연결이 이루어지면 클라이언트와 서버는 같은 위치에 있고 서로에게 데이터를 보낼 수 있으며 요청과 응답의 차이는 없습니다.

  WebSocket의 장점은 양방향 통신을 구현하는 것이지만 단점은 서버 측의 논리가 매우 복잡하다는 것입니다. 이제 다양한 배경 언어에 사용할 수있는 다양한 플러그인이 있습니다.

http://www.cnblogs.com/huchong/p/8530067.html

네 가지 웹 인스턴트 메시징 기술 비교

  호환성의 관점에서 짧은 폴링> 긴 폴링> 긴 연결 SSE> WebSocket;

  성능면에서 WebSocket> Long connection SSE> Long polling> Short polling입니다.

추천

출처blog.csdn.net/boonya/article/details/109593096