为什么建议国内的AI对话服务不采用EventSource协议？_eventstream

        EventSource协议随着ChatGPT的兴起，越来越受到开发者的关注。

        众所周知，在Chrome检查模式下（F12），我们可以看到，一般情况下：POST请求发送给服务器，服务器会一次性返回Response信息回来（如下图，抓取登录百度的数据包）。

 

        而ChatGPT对话服务却稍微有所不同。虽然同样采用POST请求，将问题发送给服务器，而服务器却返回EventStream，而且EventStream的内容随着时间（Timing）一直在不断变化，直到输出内容结束。EventStream协议接受的请求头类型也是我们平时比较少见的：Content-Type:text/event-stream。

        这就让我们产生一个疑问：EventStream究竟是什么？为什么Chatgpt采用EventStream进行数据的传输？通过直接询问Chatgpt，它给出了如下的答案：

EventStream 和 EventSource 是两个在 Web 开发中经常使用的术语。它们之间存在一定的关系。

EventStream：
EventStream 是一种基于消息传递的编程模型，通常用于实现实时数据流的处理。它是一种持续不断地从数据源接收事件，并将这些事件流传送给消费者的机制。EventStream 可以被视为一个无限的、按时间顺序排列的事件序列。

EventSource：
EventSource 是 Web API 的一部分，是为了实现服务器端向客户端推送事件而设计的。它定义了一种从服务器获取事件的方式，利用了浏览器的长连接技术，以便服务器能够主动将事件通过 HTTP 协议推送给客户端。EventSource 接口提供了 DOM 事件模型，允许开发者通过特定的 URL 与服务器建立连接，并通过监听事件的方式接收服务器推送的事件。

它们之间的关系：
EventStream 是一个抽象的概念，用于描述连续的事件流。它可以采用不同的实现方式，比如通过推送技术实现的服务器端主动推送、通过轮询实现的客户端主动拉取等。而 EventSource 是实现了服务器端主动推送的一种具体技术，它利用了长连接和事件监听机制，可以在浏览器与服务器之间建立持久性的连接，并实时接收服务器端推送的事件。

可以说，EventSource 是一种使用 EventStream 进行连接和事件推送的具体实现方式。

总结：
EventStream 是一种抽象的事件流机制，而 EventSource 是基于 EventStream 的一种具体实现，用于在 Web 开发中实现服务器端向客户端推送事件的技术。它们之间的关系是 EventSource 是一种使用 EventStream 实现的具体机制。

        EventSource协议并不是什么新玩意。早在十几年前，html5协议起草发布时，就已经作为重要的内容纳入其中，目的是为了实现服务器端往客户端更实时推送信息。

        阅读到这里，对网络传输协议稍微了解的读者不免产生一个疑问：很多系统的聊天功能、推送服务、游戏实时数据都是采用WebSocket协议，实现客户端和服务端的双通道通讯。那么，EventSource协议的优势是什么？通过对比，不难发现，EventSource 在某些场景下更适合，它的优势如下：

1. EventSource 的实现更简单：WebSocket 是一种全双工通信协议，与传统的 HTTP 不同，它需要在客户端和服务器之间建立一个持久的、双向的连接。实现 WebSocket 需要在服务器和客户端都编写特定的逻辑，这对于一些简单的实时推送场景来说可能过于繁琐，而 EventSource 则提供了更简单的实现方式。它使用了长连接和纯文本传输，没有复杂的握手和协议解析过程，使得服务器和客户端的开发和维护变得更加容易。

2. EventSource 的实现更轻量：WebSocket 建立了双向的持久连接，并且在整个通信过程中保持连接状态。这对服务器来说会增加一定的资源消耗，尤其是在需要同时处理大量连接时。EventSource 采用的是服务器向客户端单向推送数据的方式，是基于 HTTP/1.1 协议的一种机制，它使用了 HTTP 的长连接和基于文本的传输，相对 WebSocket 的二进制传输来说，它的实现更加轻量。这使得 EventSource 可以在各种环境下更广泛地应用，并且更容易适配现有的服务器架构。

3. 浏览器支持度更好：尽管现代浏览器已经广泛支持 WebSocket，但 EventSource 的支持度更好。EventSource 在早期版本的浏览器中也得到了良好的支持，并且在一些限制性环境下（如移动应用）更容易使用。

        这也就不难解释为什么OpenAI团队在实现ChatGPT服务的时候，采用的是EventSource协议，而不是WebSocket协议了。ChatGPT这种服务是服务器向客户端推送回复内容的单向通讯，基本上不需要用到复杂的WebSocket协议。

        既然是这样，读者肯定会问：EventSource协议优势那么多，而且还是ChatGPT也在采用的协议，为什么你不建议国内的AI对话采用EventSource协议呢？

        笔者一开始在开发Bmob后端云的AI服务时，也是基于上述的分析，计划采用EventSource协议进行开发。可随着分析的不断深入，发现国内不少厂商在支持EventSource协议上的不足。由于Bmob后端云通过SDK的形式，提供简单易用的API调用给开发者，开发者的应用类型多种多样，包括小程序、Android、iOS、快应用、HTML5、uni-app等等，这就要求开发的AI人工智能SDK方案要兼容所有这些平台和服务。

        可遗憾的是，作为开发者数量比较多的小程序，首先就不支持EventSource，而且这个问题早在2018年前就有开发者提出，官方却始终没有解决。

         同样，uni-app也一样不支持EventSource，这就让这个协议雪上加霜。

         所以，我们在策划开发Bmob后端云的AI人工智能SDK时，综合考虑到这些，还是选择了WebSocket协议。虽然这种协议相对复杂，但无疑能够兼容国内几乎所有的平台。这也是笔者标题中提到的，如果你想开发一套能够兼容国内绝大多数平台的AI人工智能服务，建议抛弃EventSource协议，采用WebSocket协议。

        Over！

        欢迎有不同意见的朋友拍砖。

        欢迎加本人微信（xiaowon12）聊技术聊想法。