HTML5 서버 푸시에 대한 자세한 소개

다양한 BS 아키텍처 애플리케이션에서는 이메일, 메시지, 할 일 항목 등과 같은 알림을 받기 위해 서버가 클라이언트에 다양한 메시지를 적극적으로 푸시할 수 있다고 예상하는 경우가 많습니다.

BS 아키텍처 자체의 문제는 서버가 항상 질문과 답변 메커니즘을 채택했다는 것입니다. 즉, 클라이언트가 서버에 적극적으로 메시지를 보내지 않으면 서버는 클라이언트에 메시지를 푸시하는 방법을 알 수 없습니다.

HTML 및 브라우저와 같은 다양한 기술 및 표준의 개발로 인해 서버가 메시지를 적극적으로 푸시할 수 있는 다양한 수단과 방법이 생성되었습니다. AJAX, Comet, ServerSent 및 WebSocket이 있습니다.

이 글에서는 위에서 언급한 다양한 기술적 방법에 대해 간단하게 설명합니다.

AJAX

일반 페이지는 브라우저에서 다음과 같이 작동합니다.

사용자는 브라우저에 액세스해야 하는 주소를 제공합니다.

브라우저는 이 주소를 기반으로 서버에 액세스하고 서버 연결을 사용하여 TCP를 생성합니다. (HTTP 요청)

서버는 이 주소와 다른 데이터를 기반으로 HTML 텍스트를 구성하고 이를 TCP 연결에 쓴 다음 연결을 닫습니다.

브라우저는 서버에서 HTML 텍스트를 가져와 구문 분석하고 표시합니다. 사용자가 탐색할 때

이 때 사용자는 웹사이트의 3499910bf9dac5ae3c52d5ede7383485를 클릭하거나 ff9c23ada1bcecdd1a0fb5d5a0f18437 제출을 트리거합니다.

브라우저는 양식의 매개변수 또는 a의 매개변수를 사용합니다. 접속 주소

와 서버는 TCP 연결을 생성합니다

서버는 HTML 텍스트를 구성한 다음 연결을 닫습니다

브라우저는 현재 표시된 페이지를 파괴하고 새로운 HTML 텍스트에 따라 사용자에게 새 페이지를 표시합니다

우리가 쉽게 알 수 있는 것은 전체 과정 중에 한 번 연결이 설정되면 더 이상 페이지를 유지할 수 없다는 것입니다. 전체 과정이 약간 강제적인 것 같습니다. 어쩌면 저는 새 콜라를 원할 수도 있지만 당신은 나에게 전체 패키지를 주겠다고 고집합니다.

이 시점에서 XmlHttpRequest 구성 요소를 살펴보겠습니다. 이 구성 요소를 사용하면 HTTP 요청을 수동으로 생성하고 원하는 데이터만 보낼 수 있다는 것이 가장 큰 이점입니다. 응답 시 원본 페이지는 파기되지 않습니다. 마치 내가 "커피 다 먹었으니 리필 좀 해주세요"라고 외쳤더니 웨이터가 다 먹은 정식을 버리는 대신 커피 한 잔을 가져다 준 것 같아요.

AJAX를 사용하여 서버 푸시를 구현할 때 핵심은 클라이언트가 서버에 "나에게 보낼 메시지가 있나요?"라고 계속 묻고 서버는 "예" 또는 "아니요"라고 응답하여 효과를 얻는 것입니다. 구현 방법도 매우 간단합니다. jQuery 프레임워크로 캡슐화된 AJAX 호출을 사용하는 것도 매우 편리합니다.

function getMessage(fn) {
    $.ajax({
        url: "Handler.ashx", //一个能够提供消息的页面
        dataType: "text",    //响应类型，可以是JSON，XML等其它类型
        type: "get",         //HTTP请求类型，还可以是post
        success: function (d, s) {
            fn(d);           //得到了正常的响应时，利用回调函数通知外部        },
        complete: function (x, s) {
            setTimeout(function () {
                getMessage(fn);
            }, 5000);       //无论响应成功或失败，在若干秒后再询问一次服务器        }
    });
}

위 코드를 통해 5초마다 처리해야 할 메시지가 있는지 서버에 요청할 수 있습니다. 이런 방식으로 푸시를 수행할 수 있습니다. 효과는 좋지만 문제가 있습니다.

간격이 빠를수록 푸시의 적시성이 향상되고,

간격이 느려질수록 서버 소비가 낮아집니다. 푸시의 적시성 및 서버 소비량이 적습니다.

그리고 엄밀히 말하면 이 실제 방식은 실제 서버가 적극적으로 메시지를 푸시하는 방식은 아니지만 초기 기술적 수단이 부족하여 AJAX 라운드 로빈 방식이 매우 일반적인 방식이 되었습니다.

다음은 서버 푸시 이벤트 사양에 대한 자세한 설명입니다.

Specification

서버 전송 이벤트 사양은 HTML 5 사양의 구성 요소입니다. 특정 사양 문서는 참조 리소스를 참조하세요. 사양은 비교적 간단하며 주로 두 부분으로 구성됩니다. 첫 번째 부분은 서버 측과 브라우저 측 간의 통신 프로토콜이고, 두 번째 부분은 브라우저 측에서 JavaScript에서 사용할 수 있는 EventSource 객체입니다. 통신 프로토콜은 일반 텍스트 기반의 간단한 프로토콜입니다. 서버 측 응답의 콘텐츠 유형은 "text/event-stream"입니다. 응답 텍스트의 내용은 다양한 이벤트로 구성된 이벤트 스트림으로 볼 수 있습니다. 각 이벤트는 유형과 데이터라는 두 부분으로 구성되며 각 이벤트에는 선택적 식별자가 있을 수 있습니다. 다양한 이벤트의 내용은 캐리지 리턴 및 줄 바꿈 문자만 포함하는 빈 줄("rn")로 구분됩니다. 각 이벤트의 데이터는 여러 행으로 구성될 수 있습니다. 코드 목록 1은 서버측 응답의 예를 제공합니다.

서버 측 응답의 예

data: first event

data: second event
id: 100

event: myevent
data: third event
id: 101

: this is a comment
data: fourth event
data: fourth event continue

코드 목록 1에 표시된 것처럼 각 이벤트는 빈 줄로 구분됩니다. 각 행에 대해 앞의 콜론(":")은 행의 유형을 나타내고 뒤의 콜론은 해당 값을 나타냅니다. 가능한 유형은 다음과 같습니다.

1. 유형이 비어 있습니다. 이는 해당 행이 주석이며 처리 중에 무시됨을 나타냅니다.

2. 유형은 데이터입니다. 이는 행에 데이터가 포함되어 있음을 의미합니다. 데이터로 시작하는 줄은 여러 번 나타날 수 있습니다. 이 모든 행은 해당 이벤트에 대한 데이터입니다.

3. 유형은 이벤트이며, 이 줄에 사용되는 이벤트 유형을 나타냅니다. 브라우저가 데이터를 수신하면 해당 유형의 이벤트를 생성합니다.

4. 유형은 id이며, 이 행에서 이벤트를 선언하는 데 사용되는 식별자를 나타냅니다.

5. 유형은 retry입니다. 즉, 이 줄은 연결이 끊어진 후 다시 연결하기 전 브라우저의 대기 시간을 선언하는 데 사용된다는 의미입니다.

위 코드에서 첫 번째 이벤트에는 "첫 번째 이벤트" 데이터만 포함되어 있으며 두 번째 이벤트의 식별자는 100이고 데이터는 "두 번째 이벤트"입니다. "myevent" 유형의 경우 마지막 이벤트에 대한 데이터는 "네 번째 이벤트n네 번째 이벤트 계속"입니다. 여러 행의 데이터가 있는 경우 실제 데이터는 각 데이터 행을 개행 문자로 연결하여 형성됩니다.

서버에서 반환된 데이터에 이벤트 식별자가 포함되어 있는 경우 브라우저는 가장 최근에 수신된 이벤트의 식별자를 기록합니다. 서버 연결이 중단된 경우 브라우저가 다시 연결되면 마지막으로 수신된 이벤트의 식별자가 HTTP 헤더 "Last-Event-ID"를 통해 선언됩니다. 서버 측은 브라우저 측에서 보낸 이벤트 식별자를 통해 연결을 계속하기 위해 어떤 이벤트부터 시작할지 결정할 수 있습니다.

서버에서 반환된 응답의 경우 브라우저는 처리를 위해 JavaScript의 EventSource 개체를 사용해야 합니다. EventSource는 표준 이벤트 리스너 메서드를 사용하며 해당 이벤트 처리 메서드만 개체에 추가하면 됩니다. EventSource는 표 1과 같이 세 가지 표준 이벤트를 제공합니다.

표 1. EventSource 객체에서 제공하는 표준 이벤트

onerror

Name	Description	이벤트 처리 방법
open	서버에 접속할 때 성공적으로 설정됨	onopen
message	생성 error	에러가 발생했을 때 출력 발생
	如之前所述，服务器端可以返回自定义类型的事件。对于这些事件，可以使用 addEventListener 方法来添加相应的事件处理方法。代码清单 2 给出了 EventSource 对象的使用示例。 EventSource 对象的使用示例 var es = new EventSource(&#39;events&#39;); es.onmessage = function(e) { console.log(e.data); }; es.addEventListener(&#39;myevent&#39;, function(e) { console.log(e.data); }); 如上所示，在指定 URL 创建出 EventSource 对象之后，可以通过 onmessage 和 addEventListener 方法来添加事件处理方法。当服务器端有新的事件产生，相应的事件处理方法会被调用。EventSource 对象的 onmessage 属性的作用类似于 addEventListener( ‘ message ’ )，不过 onmessage 属性只支持一个事件处理方法。在介绍完服务器推送事件的规范内容之后，下面介绍服务器端的实现。 服务器端和浏览器端实现 从上一节中对通讯协议的描述可以看出，服务器端推送事件是一个比较简单的协议。服务器端的实现也相对比较简单，只需要按照协议规定的格式，返回响应内容即可。在开源社区可以找到各种不同的服务器端技术相对应的实现。自己开发的难度也不大。本文使用 Java 作为服务器端的实现语言。相应的实现基于开源的 jetty-eventsource-servlet 项目，见参考资源。下面通过一个具体的示例来说明如何使用 jetty-eventsource-servlet 项目。示例用来模拟一个物体在某个限定空间中的随机移动。该物体从一个随机位置开始，然后从上、下、左和右四个方向中随机选择一个方向，并在该方向上移动随机的距离。服务器端不断改变该物体的位置，并把位置信息推送给浏览器，由浏览器来显示。 服务器端实现 服务器端的实现由两部分组成：一部分是用来产生数据的 org.eclipse.jetty.servlets.EventSource 接口的实现，另一部分是作为浏览器访问端点的继承自 org.eclipse.jetty.servlets.EventSourceServlet 类的 servlet 实现。下面代码给出了 EventSource 接口的实现类。 EventSource 接口的实现类 MovementEventSource public class MovementEventSource implements EventSource { private int width = 800; private int height = 600; private int stepMax = 5; private int x = 0; private int y = 0; private Random random = new Random(); private Logger logger = Logger.getLogger(getClass().getName()); public MovementEventSource(int width, int height, int stepMax) { this.width = width; this.height = height; this.stepMax = stepMax; this.x = random.nextInt(width); this.y = random.nextInt(height); } @Override public void onOpen(Emitter emitter) throws IOException { query(emitter); //开始生成位置信息 } @Override public void onResume(Emitter emitter, String lastEventId) throws IOException { updatePosition(lastEventId); //更新起始位置 query(emitter); //开始生成位置信息 } //根据Last-Event-Id来更新起始位置 private void updatePosition(String id) { if (id != null) { String[] pos = id.split(","); if (pos.length > 1) { int xPos = -1, yPos = -1; try { xPos = Integer.parseInt(pos[0], 10); yPos = Integer.parseInt(pos[1], 10); } catch (NumberFormatException e) { } if (isValidMove(xPos, yPos)) { x = xPos; y = yPos; } } } } private void query(Emitter emitter) throws IOException { emitter.comment("Start sending movement information."); while(true) { emitter.comment(""); move(); //移动位置 String id = String.format("%s,%s", x, y); emitter.id(id); //根据位置生成事件标识符 emitter.data(id); //发送位置信息数据 try { Thread.sleep(2000); } catch (InterruptedException e) { logger.log(Level.WARNING, \ "Movement query thread interrupted. Close the connection.", e); break; } } emitter.close(); //当循环终止时，关闭连接 } @Override public void onClose() { } //获取下一个合法的移动位置 private void move() { while (true) { int[] move = getMove(); int xNext = x + move[0]; int yNext = y + move[1]; if (isValidMove(xNext, yNext)) { x = xNext; y = yNext; break; } } } //判断当前的移动位置是否合法 private boolean isValidMove(int x, int y) { return x >= 0 && x <= width && y >=0 && y <= height; } //随机生成下一个移动位置 private int[] getMove() { int[] xDir = new int[] {-1, 0, 1, 0}; int[] yDir = new int[] {0, -1, 0, 1}; int dir = random.nextInt(4); return new int[] {xDir[dir] * random.nextInt(stepMax), \ yDir[dir] * random.nextInt(stepMax)}; } } 类 MovementEventSource 需要实现 EventSource 接口的 onOpen、onResume 和 onClose 方法，其中 onOpen 方法在浏览器端的连接打开的时候被调用，onResume 方法在浏览器端重新建立连接时被调用，onClose 方法则在浏览器关闭连接的时候被调用。onOpen 和 onResume 方法都有一个 EventSource.Emitter 接口类型的参数，可以用来发送数据。EventSource.Emitter 接口中包含的方法包括 data、event、comment、id 和 close 等，分别对应于通讯协议中各种不同类型的事件。而 onResume 方法还额外包含一个参数 lastEventId，表示通过 Last-Event-ID 头发送过来的最近一次事件的标识符。 MovementEventSource 类中事件生成的主要逻辑在 query 方法中。该方法中包含一个无限循环，每隔 2 秒钟改变一次位置，同时把更新之后的位置通过 EventSource.Emitter 接口的 data 方法发送给浏览器端。每个事件都有对应的标识符，而标识符的值就是位置本身。如果连接断开之后，浏览器重新进行连接，可以从上一次的位置开始继续移动该物体。 与 MovementEventSource 类对应的 servlet 实现比较简单，只需要继承自 EventSourceServlet 类并覆写 newEventSource 方法即可。在 newEventSource 方法的实现中，需要返回一个 MovementEventSource 类的对象，如下所示。每当浏览器端建立连接时，该 servlet 会创建一个新的 MovementEventSource 类的对象来处理该请求。 servlet 实现类 MovementServlet public class MovementServlet extends EventSourceServlet { @Override protected EventSource newEventSource(HttpServletRequest request, String clientId) { return new MovementEventSource(800, 600, 20); } } 在服务器端实现中，需要注意的是要添加相应的 servlet 过滤器支持。这是 jetty-eventsource-servlet 项目所依赖的 Jetty Continuations 框架的要求，否则的话会出现错误。添加过滤器的方式是在 web.xml 文件中添加代码如下所示的配置内容。 Jetty Continuations 所需 servlet 过滤器的配置 <filter> <filter-name>continuation</filter-name> <filter-class>org.eclipse.jetty.continuation.ContinuationFilter</filter-class> </filter> <filter-mapping> <filter-name>continuation</filter-name> <url-pattern>/sse/*</url-pattern> </filter-mapping> 浏览器端实现 浏览器端的实现也比较简单，只需要创建出 EventSource 对象，并添加相应的事件处理方法即可。下面代码给出了相应的实现。在页面中使用一个方块表示物体。当接收到新的事件时，根据事件数据中给出的坐标信息，更新方块在页面上的位置。 浏览器端的实现代码 var es = new EventSource(&#39;sse/movement&#39;); es.addEventListener(&#39;message&#39;, function(e) { var pos = e.data.split(&#39;,&#39;), x = pos[0], y = pos[1]; $(&#39;#box&#39;).css({ left : x + &#39;px&#39;, top : y + &#39;px&#39; }); }); 在介绍完基本的服务器端和浏览器端实现之后，下面介绍比较重要的 IE 的支持。 IE 支持 使用浏览器原生的 EventSource 对象的一个比较大的问题是 IE 并不提供支持。为了在 IE 上提供同样的支持，一般有两种办法。第一种办法是在其他浏览器上使用原生 EventSource 对象，而在 IE 上则使用简易轮询或 COMET 技术来实现；另外一种做法是使用 polyfill 技术，即使用第三方提供的 JavaScript 库来屏蔽浏览器的不同。本文使用的是 polyfill 技术，只需要在页面中加载第三方 JavaScript 库即可。应用本身的浏览器端代码并不需要进行改动。一般推荐使用第二种做法，因为这样的话，在服务器端只需要使用一种实现技术即可。 在 IE 上提供类似原生 EventSource 对象的实现并不简单。理论上来说，只需要通过 XMLHttpRequest 对象来获取服务器端的响应内容，并通过文本解析，就可以提取出相应的事件，并触发对应的事件处理方法。不过问题在于 IE 上的 XMLHttpRequest 对象并不支持获取部分的响应内容。只有在响应完成之后，才能获取其内容。由于服务器端推送事件使用的是一个长连接。当连接一直处于打开状态时，通过 XMLHttpRequest 对象并不能获取响应的内容，也就无法触发对应的事件。更具体的来说，当 XMLHttpRequest 对象的 readyState 为 3（READYSTATE_INTERACTIVE）时，其 responseText 属性是无法获取的。 为了解决 IE 上 XMLHttpRequest 对象的问题，就需要使用 IE 8 中引入的 XDomainRequest 对象。XDomainRequest 对象的作用是发出跨域的 AJAX 请求。XDomainRequest 对象提供了 onprogress 事件。当 onprogress 事件发生时，可以通过 responseText 属性来获取到响应的部分内容。这是 XDomainRequest 对象和 XMLHttpRequest 对象的最大不同，也是使用 XDomainRequest 对象来实现类似原生 EventSource 对象的基础。在使用 XDomainRequest 对象打开与服务器端的连接之后，当服务器端有新的数据产生时，可以通过 XDomainRequest 对象的 onprogress 事件的处理方法来进行处理，对接收到的数据进行解析，根据数据的内容触发相应的事件。 不过由于 XDomainRequest 对象本来的目的是发出跨域 AJAX 请求，考虑到跨域访问的安全性问题，XDomainRequest 对象在使用时的限制也比较严格。这些限制会影响到其作为 EventSource 对象的实现方式。具体的限制和解决办法如下所示： 服务器端的响应需要包含 Access-Control-Allow-Origin 头，用来声明允许从哪些域访问该 URL。“*”表示允许来自任何域的访问，不推荐使用该值。一般使用与当前应用相同的域，限制只允许来自当前域的访问。 XDomainRequest 对象发出的请求不能包含自定义的 HTTP 头，这就限制了不能使用 Last-Event-ID 头来声明浏览器端最近一次接收到的事件的标识符。只能通过 HTTP 请求的其他方式来传递该标识符，如 GET 请求的参数或 POST 请求的内容体。 XDomainRequest 对象的请求的内容类型（Content-Type）只能是“text/plain”。这就意味着，当使用 POST 请求时，服务器端使用的框架，如 servlet，不会对 POST 请求的内容进行自动解析，无法使用 HttpServletRequest 类的 getParameter 方法来获取 POST 请求的内容。只能在服务器端对原始的请求内容进行解析，获取到其中的参数的值。 XDomainRequest 对象发出的请求中不包含任何与用户认证相关的信息，包括 cookie 等。这就意味着，如果服务器端需要认证，则需要通过 HTTP 请求的其他方式来传递用户的认证信息，比如 session 的 ID 等。 由于 XDomainRequest 对象的这些限制，服务器端的实现也需要作出相应的改动。这些改动包括返回 Access-Control-Allow-Origin 头；对于浏览器端发送的“text/plain”类型的参数进行解析；处理请求中包含的用户认证相关的信息。 本文的示例使用的 polyfill 库是 GitHub 上的 Yaffle 开发的 EventSource 项目，具体的地址见参考资源。在使用该 polyfill 库，并对服务器端的实现进行修改之后，就可以在 IE 8 及以上的浏览器中使用服务器推送事件。如果需要支持 IE 7，则只能使用简易轮询或 COMET 技术。本文的示例代码见参考资源。 小结 서버에서 브라우저로 데이터를 푸시해야 하는 경우 사용할 수 있는 HTML 5 사양 표준 기반 기술에는 WebSocket 및 서버 푸시 이벤트가 포함됩니다. 개발자는 애플리케이션의 특정 요구 사항에 따라 적절한 기술을 선택할 수 있습니다. 서버 측에서 데이터를 푸시해야 하는 경우 서버 푸시 이벤트 사양이 더 간단하고 구현하기 쉽습니다. 이 기사에서는 서버 푸시 이벤트의 사양 내용, 서버 측 및 브라우저 측 구현에 대한 자세한 소개와 IE 브라우저 지원 방법에 대한 자세한 분석을 제공합니다.

위 내용은 HTML5 서버 푸시에 대한 자세한 소개의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!