前言

前两篇文章分析了websocket和socket.io,现在就剩下最后一个实时通信技术-eventsource。很多人也许好奇,有了websocket这种实时通信,为什么还需要eventsource呢?答案其实很简单,那就是eventsource其实是单向通信,而websocket是双向通信。在股票行情、新闻推送的这种只需要服务器发送消息给客户端场景中,使用SSE更加合适。另外SSE是使用HTTP传输的,这意味着我们不需要一个特殊的协议或者额外的实现就可以使用。而websocket要求全双工连接和一个新的websocket服务器去处理。加上SSE在设计的时候就有一些websocket没有的特性,比如自动重连接,event IDs,以及发送随机事件的能力,所以各有各的特长,我们需要根据实际应用场景,去选择不同的应用方案。

1、SSE介绍

SSE的简单模型是:一个客户端去从服务器端订阅一条“流”,之后服务端可以发送消息给客户端直到服务端或者客户端关闭该“流”,所以eventsource也叫作"server-sent-event"。相比以前的轮询,SSE可以为B2C带来更高的效率。有一张图片画出了二者的区别:(引用自What is Server-Sent Events)

1.1、SSE数据帧的格式

event-source必须编码成utf-8的格式,消息的每个字段使用"\n"来做分割,并且需要下面4个规范定义好的字段:

  1. Event: 事件类型
  2. Data: 发送的数据
  3. ID: 每一条事件流的ID
  4. Retry: 告知浏览器在所有的连接丢失之后重新开启新的连接等待的时间,在自动重新连接的过程中,之前收到的最后一个事件流ID会被发送到服务端。

下图是通过wireshark抓包得到的数据包的原始格式:

1.2、SSE通信过程

SSE的通信过程比较简单,底层的一些实现都被浏览器给封装好了,包括数据的处理。大致流程如下:

在浏览器中截图如下:

携带的数据是JSON格式的,浏览器都帮你整合成为一个Object:

在wireshark中,其通信流程如下:

1.2.1、 发送请求

1.2.2、 得到响应

1.2.3、 在开始推送信息流之前,服务器还会发送一个客户端会忽略掉的包,这个具体原因不清楚:

1.2.4、 断开连接后的重传

2、SSE的简单使用示例

浏览器端的使用:

const es = new EventSource('/sse')

服务端的使用:

const sseStream = new SseStream(req)
sseStream.pipe(res)
sseStream.write({
  id: sendCount,
  event: 'server-time',
  retry: 20000, // 告诉客户端,如果断开连接后,20秒后再重试连接
  data: {ts: new Date().toTimeString(), count: sendCount++}
})

更多API使用和demo介绍分别参考:

API

demo

3、兼容性以及缺点

3.1、兼容性

3.2、缺点

  1. 因为是服务器->客户端的,所以它不能处理客户端请求流
  2. 因为是明确指定用于传输UTF-8数据的,所以对于传输二进制流是低效率的,即使你转为base64的话,反而增加带宽的负载,得不偿失。

4、结语

至此3篇关于RTC通信的文章介绍完成,但愿能够给童鞋们一个基本的印象,在实际应用中如果有什么问题,欢迎探讨。

参考

1、https://hpbn.co/server-sent-events-sse/ 2、https://html.spec.whatwg.org/multipage/server-sent-events.html#server-sent-events 3、https://gist.github.com/jareware/aae9748a1873ef8a91e5 4、https://streamdata.io/blog/server-sent-events/