JS实时通信三把斧系列之三: eventsource

前言

前两篇文章分析了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通信的文章介绍完成，但愿能够给童鞋们一个基本的印象，在实际应用中如果有什么问题，欢迎探讨。