可以用不关闭的 HTTP 连接，来替代 WebSocket 吗？
刚好在过去的职业生涯里多次使用到了各种服务端推送技术。给大家介绍我常用的 3 种技术——websocket，sse，httpstream。
websocket：概念提出于 2008 年。次年草案，2010 年由苹果率先支持草案。2011 年标准化（RFC6455)。2012 年 api 标准化。
sse：概念提出得更早2006 年，但进度明显比 websocket 慢，标准化也是 2011 年，但 2015 年才得到主流浏览器的支持，早期浏览器通过 long polling polyfill 支持 sse，2019年前后主流浏览器已切换到 http-streaming 对 sse 进行支持。
HTTP-streaming：服务端通过三板斧——
Content-Type: text/event-stream
Connection: keep-alive
Transfer-Encoding: chunked
告诉浏览器，我一会儿还要不断 response，切莫关闭连接。2018 年标准化，2020 年各大主流浏览器支持。（可以看到基本上是支持力度最高的那个）
三者的区别在于：
- websocket 是真正的双向通信，可以实现任意时间客户端向服务端发送数据，服务端向客户端发送数据，任意时间。
- sse 是单向通信，只能是服务端向客户端通信，通用性较差，且是在 stream 协议上封装的协议比如 event-id, data。 支持重连，跟ws一样不需要你去碰chunk这一层。
- streaming 相比 sse 更加底层也更加通用，可能需要先手动解析 chunk，一个大的 json 有可能会被分片成多个 chunk，这就需要客户端拼接解析才能得到 json，比 sse 麻烦，但优势在于客户端可以像普通的 post 请求那样发送一个 json 到服务端，服务端根据入参轮询 缓存/中间件/数据库/订阅 mq，然后持续性发送 response。相比 sse，stream 的优势可以先由客户端 post 一个 request，然后不断地read response。
总结：
ws 可以是客户端和服务端任意端发起数据传输，但通常一个应用或者一个页面只有一个 ws 连接，意味着所有请求都复用这个连接，这就要集中化处理各式各样的请求，编程难度较大，对于应用协议的设计功力是一种考验。
sse 编码简单，但只能是服务端单向向客户端传输数据，如果想先让客户端 post 一个请求，服务端根据请求的参数再进行选择性推送，只能寻求更加底层的 stream 了。
streaming 客户端编码难度较大，特别是 chunk 的处理，类似于粘包问题。但对于服务端来说编码会更加简单，就是普通的 post 接口，对于 HttpReuestWriter w，for 循环多次调用 w.write(xxx) 即可。
最终选用哪种技术就看需求了。
