서버 푸시 기술

6383 단어 서버
서버 푸시 기술은 최근 프로젝트에서 사용할 수 있는 기술이기 때문에 미리 연구했다.
이러한 장면을 고려하여 각종 WEB 응용 프로그램에서 다른 사용자가 관심 있는 메시지를 변경한 경우 사용자는 알림을 받기를 원합니다.만약 웹 사이트에 주가 등 동적 데이터가 표시된다면 모든 사용자는 변경에 대한 통지를 즉시 받아야 한다.
이러한 장면 자체는'서버 푸시'라고 불리는 문제에 속한다.일반적으로 서버는 Hub 실체로서 서버는 먼저 발생한 모든 변경에 대한 통지를 받고 서버는 이러한 변경을 모든 연결된 클라이언트에게 통지한다.그러나 유감스럽게도 HTTP는 클라이언트-서버 통신의 표준 프로토콜로 무상태이며 어떤 의미에서 보면 일방적인 프로토콜이기도 하다.HTTP 장면의 모든 통신은 클라이언트가 시작해서 서버가 끝날 때까지 해야 하지만 우리가 언급한 장면의 수요는 완전히 상반된다.서버 전송에 있어 서버가 통신을 시작하고 클라이언트에게 데이터를 보내야 한다.HTTP 프로토콜은 관련 구성이 없습니다. 웹 사이트 응용 프로그램 개발자는 독창적인 방법으로 이러한 문제를 회피합니다.
현재로서는 서버 푸시(PUSH) 메커니즘이 크게 몇 가지로 나뉩니다.
1. 짧은 폴링
클라이언트는 서버와 고정 (또는 구성 가능) 시간 간격으로 연락하여 새로운 업데이트를 사용할 수 있는지 확인합니다.대부분의 경우, 이러한 문의는 순전히 낭비이다. 왜냐하면 서버에 업데이트가 없기 때문이다.이런 방법은 대가가 없는 것이 아니라 두 가지 주요 문제가 있다.
우선 이런 방법은 인터넷 자원을 낭비하고
그 다음으로 폴링은 일정한 시간 간격이 있기 때문에 클라이언트는 실시간 업데이트를 받지 못한다.
2. 긴 폴링
긴 폴링은 서버 데이터를 업데이트하는 데 사용되는 또 다른 방법입니다.이러한 방법의 이념은 클라이언트가 연결을 구축하고 서버가 연결을 막는 것이다. (요청 라인을 일부 조건에서 대기 상태로 만드는 것을 통해) 데이터가 사용할 수 있을 때 서버는 막힌 연결을 통해 데이터를 보내고 연결을 닫는다.클라이언트는 업데이트를 받은 후 즉시 연결을 다시 구축하고 서버는 상술한 과정을 반복하여 실시간에 가까운 통신을 실현한다.그러나 긴 폴링에는 다음과 같은 결함이 있습니다. 일반적인 브라우저는 기본적으로 각 서버에 두 개의 연결을 허용합니다.이런 상황에서 하나의 연결은 시종 바쁜 상태이다.따라서 UI는 사용자 요청에 대한 서비스 제공에 사용할 수 있는 연결이 하나만 있습니다.이로 인해 일부 작업의 성능이 저하될 수 있습니다.여전히 HTTP 연결을 열고 닫아야 합니다. 만약 지속적인 연결 모드 (keepalive=false) 를 사용한다면 이런 방법의 대가가 매우 높을 수 있습니다.이런 방법은 실시간에 가깝지만 진정한 실시간은 아니다.(물론 일부 외부 요소는 항상 통제할 수 없다. 예를 들어 네트워크 지연 시간은 어떤 방법에서든 이런 요소가 존재한다.)
3. 흐름 전송
유통도(streaming channel)는 긴 휠체어와 대체적으로 같고 서버가 응답 흐름을 닫지 않는다는 차이점이 있다.브라우저가 더 많은 데이터가 곧 도착할 것이라고 생각하도록 일부러 열려 있는 상태를 유지한다.그러나 유통도에도 결함이 있다. 가장 큰 문제는 데이터 리셋(flushing)이다.
플러그인이 오래 열리는 것을 발견하면, 일부 브라우저는 플러그인을 닫기로 스스로 결정할 수도 있습니다.이런 상황에서 통로는 다시 세워야 한다.
일반적으로 첫 번째 문제는 모든 흐름 응답에 쓰레기를 추가하는 유효한 하중을 통해 해결할 수 있으며, 응답 데이터가 버퍼를 채울 수 있도록 한다.두 번째 문제는 "활동 유지"또는 고정 간격 "동기화"메시지로 브라우저를 속여서 브라우저가 데이터가 비교적 느린 속도로 전송된다고 생각하도록 할 수 있다.
다음은 자주 사용하는 추송 실현 기술을 소개한다.
1. Comet
Comet는 때때로 역방향 Ajax나 서버 사이드 푸시(server-side push)라고도 부른다.그 사상은 매우 간단하다. 데이터를 서버에서 브라우저로 직접 미루고 브라우저가 데이터를 요청할 때까지 기다릴 필요가 없다.간단하게 들리지만 웹 응용 프로그램, 특히 HTTP 프로토콜에 익숙해지면 결코 간단하지 않다는 것을 알게 될 것입니다.Comet 스타일의 웹 응용 프로그램을 실현하고 브라우저와 서버에서의 신축성을 확보하는 것은 최근 몇 년 동안만 가능하다.
Apache Tomcat의 경우 Comet를 사용하려면 주로 두 가지 작업이 필요합니다.우선 Tomcat에 대한 프로필 서버가 필요합니다.xml 살짝 수정.기본적으로 더 일반적인 동기식 IO 커넥터가 활성화됩니다.이제 비동기 버전으로 전환하기만 하면 됩니다. 아래와 같습니다.
<!-- This is the usual Connector, comment it out and add the NIO one -->
   <!-- Connector URIEncoding="utf-8" connectionTimeout="20000" port="8084" 
protocol="HTTP/1.1" redirectPort="8443"/ -->
<Connector connectionTimeout="20000" port="8080" protocol="org.apache.
coyote.http11.Http11NioProtocol" redirectPort="8443"/>

그리고 실행 org를 만듭니다.apache.catalina.CometProcessor 인터페이스의 servlet입니다.CometProcessor 인터페이스 요구 실현event 방법.이것은 Comet 상호 작용에 사용되는 라이프 사이클 방법입니다.Tomcat은 다른 CometEvent 인스턴스를 사용하여 호출됩니다.검사CometEvent의eventType를 통해 생명주기의 어느 단계에 있는지 판단할 수 있다.요청이 처음 들어왔을 때 BEGIN 사건이 발생합니다.READ 이벤트는 데이터가 전송되고 있음을 나타냅니다. 요청이 POST 일 때만 이 이벤트가 필요합니다.END 또는 ERROR 이벤트가 발생하면 종료를 요청합니다.
구체적인 예는 이것 주소를 참조하십시오.
현재 자주 사용되는 Comet 프레임워크는 다음과 같습니다.
CometD: Dojo Fondation 프로젝트로 Bayeux protocol의javascript,java,perl,python 및 기타 언어의 실현을 제공합니다.CometD의 사이트에서 Sun, IBM, BEA 등 회사의 Comet가 실현한 제품에 대한 링크를 동시에 제공한다.
2. HTML5
HTML5는 SSE 및 Web Socket과 같은 두 가지 W3C 표준 푸시 방식을 제공합니다.
먼저 SSE(Server-sent-envets)를 소개합니다. PHP 서버를 예로 들면,
고객이 방문한 페이지는 다음과 같습니다.
sse.htm 
<!DOCTYPE html>  
<html>  
<body>  
  <script>  
    var source = new EventSource('source.php');  
    source.onmessage = function(event){  
      var text = event.data;  
      window.webkitNotifications.createNotification('', 'Alert', text).show();  
    }  
  </script>  
</body>  
</html>

서버가 메시지를 보내는 스크립트는
source.php 
header("Content-Type: text/event-stream");
header("Cache-Control: no-cache");

mysql_connect("localhost", "user", "pass");
mysql_select_db("eventstream");

$q = mysql_query("select textnotif from notification where read='0'");
$r = mysql_fetch_array($q);

$notif = $r[textnotif];

if($notif != ""){  
    echo "data: ".$notif.PHP_EOL;  
}

SSE는 현재 브라우저 Chrome, Safari에서 서버에서 클라이언트로 메시지를 단방향으로 푸시하는 기능을 지원합니다.구체적으로 어떤 브라우저가 지원되는지 점여기에서 볼 수 있습니다.
WEB Socket은 양방향 메시지 채널을 제공합니다.WebSocket은 HTTP 프로토콜의 초기 악수 단계를 거쳐 웹 Socket 프로토콜로 업그레이드되어 실시간 데이터 통신을 지원합니다.WebSocket 프로토콜은 더욱 가벼운 Header를 설계했다.
여기 WebSocket 기술을 사용하는 실례를 참고할 수 있습니다.현재 인터넷에는 웹소켓에 대한 내용이 비교적 많다.
웹소켓은 양방향 소통의 장점을 가지기 때문에 채팅방, 게임, 주식 거래 등 양방향 통신이 필요한 응용을 실현할 수 있다.SSE는 서버에서 클라이언트로의 단방향 푸시만 가능하지만 자동으로 다시 연결할 수 있고 EventID 등 장점이 있기 때문에 쓸모가 있다.
참고할 수 있는 또 다른 경량급 서버 푸시 프레임워크는 Pushlets HTTP Push에서 DHTML까지, 그리고 Pushlets 프레임워크의 구체적인 실현 실례를 제공한다.
참조:

1. Java를 사용하여 Comet 스타일의 웹 응용 프로그램 구현


2. BiDirection 데이터 교환을 위한 HTML5 웹소켓 적용
3. Pushlets
서버 다운타임 분석 프로세스 1회 기록(1) - 문제 해결
독립판이 준비되어 있지 않으므로 응용 프로그램 Verifier를 사용할 때 Windows SDK부터 넣으십시오.

좋은 웹페이지 즐겨찾기

개발자 우수 사이트 수집

개발자가 알아야 할 필수 사이트 100선 추천 우리는 당신을 위해 100개의 자주 사용하는 개발자 학습 사이트를 정리했습니다
best100-homepage