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

逃离我推掉我的手 2021-06-26 16:06 917阅读 0赞

## 前言 ##

前两篇文章分析了`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`)  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1d1TGV4_size_16_color_FFFFFF_t_70]

### 1.1、`SSE`数据帧的格式 ###

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

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

下图是通过`wireshark`抓包得到的数据包的原始格式：  
![在这里插入图片描述][20190812225719982.png]

### 1.2、`SSE`通信过程 ###

`SSE`的通信过程比较简单，**底层的一些实现都被浏览器给封装好了，包括数据的处理**。大致流程如下：  
![在这里插入图片描述][20190812230154779.png]在浏览器中截图如下：  
![在这里插入图片描述][20190812230915937.png]携带的数据是`JSON`格式的，浏览器都帮你整合成为一个`Object`：  
![在这里插入图片描述][20190812231054551.png]  
在`wireshark`中，其通信流程如下：

#### 1.2.1、 发送请求 ####

![在这里插入图片描述][2019081223115999.png]

#### 1.2.2、 得到响应 ####

![在这里插入图片描述][20190812231330124.png]

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

![在这里插入图片描述][20190812231711544.png]

#### 1.2.4、 断开连接后的重传 ####

![在这里插入图片描述][20190812231856855.png]

## 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、兼容性 ###

![在这里插入图片描述][20190812232145534.png]

### 3.2、缺点 ###

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

## 4、结语 ##

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

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1d1TGV4_size_16_color_FFFFFF_t_70]: /images/20210626/29f5940c581f46a7836c5c548c7aa5e0.png
[20190812225719982.png]: /images/20210626/97d7515e77ae43c5887d4f7a1ebfc762.png
[20190812230154779.png]: /images/20210626/1a19a7a03f60433fa370045d8cf6f09a.png
[20190812230915937.png]: /images/20210626/ca17f392c8a64a9fa13891d142299d3c.png
[20190812231054551.png]: /images/20210626/5b76fc2d322447288872a50cc1a84677.png
[2019081223115999.png]: /images/20210626/02ecc558f25c4c548b6dcae1bf345bb0.png
[20190812231330124.png]: /images/20210626/5bf513681d7146f5aaafe06bb14c4178.png
[20190812231711544.png]: /images/20210626/b4226f462eaf4a6f82993fb0e4e44efa.png
[20190812231856855.png]: /images/20210626/9879e6533efa4a59a0fa2caf58a96284.png
[API]: https://developer.mozilla.org/en-US/docs/Web/API/EventSource
[demo]: https://github.com/linxiaowu66/nodejs-rtc-demo/blob/master/es.js
[20190812232145534.png]: /images/20210626/2601537faa284b25ac6dfdf9ae6bab68.png