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个规范定义好的字段:
- 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的简单使用示例
浏览器端的使用:
1const es = new EventSource('/sse')
服务端的使用:
1const sseStream = new SseStream(req) 2sseStream.pipe(res) 3sseStream.write({ 4 id: sendCount, 5 event: 'server-time', 6 retry: 20000, // 告诉客户端,如果断开连接后,20秒后再重试连接 7 data: {ts: new Date().toTimeString(), count: sendCount++} 8})
更多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
公众号关注一波~
网站源码:linxiaowu66 · 豆米的博客
Follow:linxiaowu66 · Github
关于评论和留言
如果对本文 JS实时通信三把斧系列之三: eventsource 的内容有疑问,请在下面的评论系统中留言,谢谢。