AI时代，流式传输哪家强
AI摘要: 本文探讨了AI时代下流式传输技术的必要性，对比分析了SSE、WebSocket和gRPC三种主流方案的技术实现与适用场景。重点阐述LLM响应延迟问题对传统HTTP请求的局限性，以及server端主动推送机制的核心价值。通过对比各技术在协议基础、通信模式、性能开销和心智负担等方面的差异，明确gRPC在Agent应用中的性能优势及浏览器兼容性限制。
最近在公司干些感觉没啥用的Agent相关的工作，虽然大家的工作很忙，但是我却是比较清闲，也是摸摸鱼看看文档学习。据我浅浅观测，正式工作干的感觉都是苦力活，将已有的知识和工具熟练度输出，技能反而并没有太大长进，而看文档和分享会才是知识增长的输入机会。
吐槽完之后，这里简单回忆复习下计网中的流式传输。由于decoder结构，目前所有的LLM响应一次请求的时间极长，只能一个字一个字的解码，如果按照传统的http请求方式，大概率两种可能：1. 响应超时失败，2. 经过漫长的等待，响应成功返回结果，而用户早卸载了App。因此，在AI时代，我们需要一些server端主动推送的技术，LLM生成多少就先告诉client多少，用户体验最重要。
chatGPT采用的SSE
SSE是在HTTP1.1的基础上构建的，可以让server端单向给client端发送消息。我们最常见的HTTP1.1请求头中写的是content-type:application/json, 代表返回数据的类型为JSON，而SSE在请求头中设置为content-type: text/event-stream. 代表这server端每次准备好数据后发送一个server side event给client处理。当client向server发送HTTP请求时，就能开启一个HTTP长连接，慢慢等着server端的数据就好了
websocket
这是最常见的server和client互相通信，互相推送技术，也是建立在HTTP1.1上. 由于HTTP1.1默认为一问一答模式，所以在其基础上修改，设置请求头Connection: Upgrade, Upgrade: websocket，就能实现websocket协议，实现互相通信。不过其实现起来稍微复杂，需要手动维护心跳，超时等情况。
gRPC
gRPC建立在HTTP2的基础上，和websocket一样支持双向通信。也是目前做Agent应用时候，非常好的一种流式技术方案选择。同时，由于websocket需要TCP三次握手，有需要在HTTP连接上升级，多次的操作导致websocket比较重，首次连接的耗时远远高于gRPC。而且，websocket需要手动维护心跳，发送事件，接收事件，超时等等，对程序员的心智负担较重，gRPC则由于HTTP2的多路复用，以及TCP的握手次数更少，性能，延迟和操作便捷性也更好。最大的缺点可能是浏览器环境支持不够好，如果是app端，那就非常适合了。