在ChatGPT官网咱们能够看到，对话的方式仅仅只要一个post恳求，而没有运用IM中运用的websocket链接。
同时咱们能够看到与一般的post恳求不一样的是，回来信息Response没有了，取而代之的是EventStream。
那么这个EventStream是什么东西？
一通查证后，发现这个是Web API中的EventSource接口回来的数据。
MDN的官方描绘是这样的(传送门)：
EventSource接口是 web 内容与服务器发送事情 一个EventSource实例会对HTTP服务器敞开一个耐久化的衔接，以text/event-stream格式发送事情，此衔接会一向保持敞开直到通过调用EventSource.close()关闭。
好家伙，还有这好东西。是我以前坐井观天了。
通过一番对比，总结了一下 EventSource 和 Websocket 的差异和好坏：
EventSource:
-
优势：
- 简略易用：EventSource API十分简略，易于运用和了解。
- 服务器推送：EventSource适用于服务器主意向客户端推送数据，客户端只能接纳服务器发送的事情。
- 主动重连：EventSource会主动处理衔接断开和重新衔接的状况，适用于长时间保持衔接并接纳事情流的场景。
- 兼容性：EventSource在大多数现代浏览器中得到支撑。
-
下风：
- 单向通讯：EventSource只支撑从服务器到客户端的单向通讯，客户端无法向服务器发送数据。
- 较少的功用：比较于WebSocket，EventSource供给的功用较为有限，仅限于接纳服务器发送的事情。
WebSocket:
-
优势：
- 双向通讯：WebSocket支撑双向通讯，客户端和服务器能够互相发送数据。
- 实时性：WebSocket供给了更低的推迟和更快的数据传输速度，适用于实时性要求较高的应用场景。
- 丰厚的功用：WebSocket供给了更多的功用，例如数据帧的自定义和二进制数据的传输等。
-
下风：
- 杂乱性：WebSocket API相关于EventSource更为杂乱，运用起来或许需求更多的代码和了解。
- 需求服务器支撑：运用WebSocket需求服务器端完成对应的WebSocket协议，而EventSource只需求服务器端支撑发送事情即可。
- 兼容性：相关于EventSource，WebSocket在某些较旧的浏览器或网络环境中的支撑或许不够广泛。
综上所述，EventSource 适用于服务器主动推送事情给客户端，并且在保持长时间衔接和接纳事情流时表现良好。 WebSocket 适用于需求实时双向通讯和更丰厚功用的场景，但需求服务器端和客户端都支撑 WebSocket 协议，选择运用哪种技能应基于具体需求和应用场景进行评估。
那么有了上面的定论咱们再来看看，为什么 ChatGPT 对话为什么不必 Websocket 而运用 EventSource ？
当然，ChatGPT 对话能够运用Websocket或EventSource进行实时通讯，下面是我个人的总结：
- 服务器推送：
EventSource专心于服务器向客户端主动推送事情的模型，这关于ChatGPT对话十分适用。ChatGPT通常是作为一个长时间运行的服务，当有新的回复可用时，服务器能够主动推送给客户端，而不需求客户端频繁发送恳求。 - 主动重连和错误处理：
EventSource具有内置的主动重连机制，它会主动处理衔接断开和重新衔接的状况。这关于ChatGPT对话而言很重要，由于对话或许需求持续一段时间，衔接的稳定性很重要。 - 简略性和易用性：相关于
WebSocket，EventSource的API愈加简略易用，只需实例化一个EventSource目标，并处理服务器发送的事情即可。这使得开发者能够更快速地完成对话功用，减少了一些杂乱性。 - 广泛的浏览器支撑：
EventSource在大多数现代浏览器中得到广泛支撑，包含移动端浏览器。比较之下，WebSocket在某些旧版本的浏览器中或许不被彻底支撑，需求考虑兼容性问题。
需求留意的是，WebSocket也是一种很好的选择，特别是当需求完成更杂乱的实时双向通讯、自定义协议等功用时，或者对浏览器的兼容性要求较高时。终究选择运用WebSocket还是EventSource应该根据具体的项目需求和技能考虑来确定。
