本文同步发表在豆米的博客：豆米的博客
前言
前两篇文章分析了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个规范定义好的字段：
- Event: 事件类型
- Data: 发送的数据
- ID: 每一条事件流的ID
- 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介绍分别参考：
3、兼容性以及缺点
3.1、兼容性
3.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/
