1. 引言
1.1 Chatgpt带给我的冲击
随着OpenAI Chatgpt的横空出世，我的世界观发生了变化。
以前一直觉得电影中的AI其实这是一种人们的假想，因为作为程序员的我们最清楚，机器能分析自然语言并且理解自然语言是多么难的一件事情，但是Chatgpt出世了。
自然而然，我们是最早接触的一批人。这让我有点接受不了这个新玩意。
用 Chatgpt3 的时候还没有这种感觉，但是Gpt4太夸张了，人类一败涂地，高考，雅思，...一切人类的考试，他考都是状元级别。语言干不过人家，代码写不过人家，学习能力还没人家强，科技也在AI的帮助下突飞猛进，人类考虑到的他考虑到了，人类考虑不到的他也考虑到了，所有公司现在都为了不在时代的冲刷下死亡，都选择快速拥抱Gpt，生怕自己被淘汰。大刘的技术爆炸真的要来了，嵌入式也在快速发展，Moss还会远吗？
1.2 Chatgpt给我带来的反思
Chatgpt4给我一种抡了一辈子的锄头，突然看见联合收割机的感觉。生产力本就过剩的社会，AI的出现居然又疯狂解放生产力。App和网站说到底就是简化人们使用互联网的入口，以后App和网站还需要吗？甚至手机还需要吗？电脑还需要吗？屏幕接一个嵌入式AI就好了，载体甚至可以是任何东西。
所以我们以后干什么呢？
难道就像乌托邦的社会一样，AI去做一切的劳动力，人类只用创新就行了，足够的生产力供应全部的人类，人类拥有了历史上前所未有的自由和解放之后，人类去发挥自己的自主能动性去创新吗？
我不知道，也不敢想象，现在能做的也只是快速拥抱AI。
不学习还能怎么办？
传统的请求-响应模型在一定程度上无法满足用户对实时性的需求。频繁的轮询会增加服务器和客户端的负担，同时带来延迟和资源浪费。这促使了对更有效的实时通信方式的探索。
2. 初识 OpenAI SSE 协议
2.1 OpenAI SSE 协议
对接的过程中我发现一个很有趣的东西，OpenAI 的 API 分为两种对接类型：
- Http Restful 接口类型。
- OpenAI SSE 协议的流式响应类型。
作为一种基于 HTTP 的轻量级通信协议，OpenAI SSE 专注于实现服务器到客户端的单向通信，为聊天应用的实时性提供了全新的解决方案。
2.2 OpenAI SSE 协议的基本原理
OpenAI SSE（Server-Sent Events）协议基于 HTTP，通过建立持久连接实现服务器到客户端的单向通信。客户端通过简单的事件流（Event Stream）接收实时的信息。服务器将事件流以纯文本形式发送到客户端，客户端通过监听这些事件来获取实时更新。这种轻量级协议消除了频繁轮询的需要，实现了更高效的实时通信。
2.3 为什么要用 OpenAI SSE 协议呢？
最简单最直观的说法就是让用户直观的得到响应。
但是经过我的一番了解之后，OpenAI SSE的好处主要有：
实时性与用户体验
OpenAI SSE 协议通过建立持久连接，使得服务器能够实时地将信息推送到客户端，实现了高度实时性。这对于聊天应用来说，意味着用户可以更迅速地接收到新消息，极大地提升了用户体验。
减轻服务器和网络负担
相较于传统轮询方式，OpenAI SSE 协议采用单向通信的方式，减轻了服务器和网络的负担。服务器只需在有新消息时进行推送，降低了不必要的通信开销，提高了系统的效率。
简化开发复杂性
OpenAI SSE 协议的设计简单而直观，使得开发者能够更轻松地实现实时通信功能，减少了复杂的技术实现难度。这使得聊天应用的开发周期更加迅速。
支持多样化的应用场景
OpenAI SSE 不仅适用于聊天应用，还可用于各种需要实时性的场景，如实时数据更新、通知推送等。其灵活性使得它成为多领域实时通信的理想选择。
2.4 传统的聊天应用架构
传统聊天应用采用客户端-服务器架构，其中服务器负责处理连接、消息传递和存储。登录过程包括用户认证和获取联系人列表。消息发送涉及客户端向服务器发送消息，服务器负责处理和转发。消息接收阶段中，服务器向在线用户推送消息，离线用户的消息存储在数据库中，待其上线时再推送。这种模式满足基本聊天需求，但实时性和服务器压力仍是挑战。
2.5 SSE 与传统请求-响应模型的区别
SSE（Server-Sent Events）与传统请求-响应模型的主要区别在于实时性和通信方式。传统模型中，客户端通过定期发起请求轮询服务器，而SSE则建立持久连接，允许服务器主动向客户端推送实时事件。这消除了轮询的开销，提高了实时通信效率，使客户端能够即时接收到服务器推送的信息。
总结
一定要多思考，如果人永远待在舒适圈的话，人永远不会成长。共勉
觉得作者写的不错的，值得你们借鉴的话，就请点一个免费的赞吧！这个对我来说真的很重要。૮(˶ᵔ ᵕ ᵔ˶)ა