背景
大家好,我是江辰,最近小小的实现了下 chatGPT 的问答式回复,调研了前端如何实现这种问答式申请,有几种计划,Http、EventSource、WebSocket,三种实现计划各有优缺点,Http 和 WebSocket,想必大家耳闻能详,这里我讲讲 EventSource
EventSource
EventSource 是服务器推送的一个网络事件接口。一个 EventSource 实例会对 HTTP 服务开启一个长久化的连贯,以 text/event-stream 格局发送事件,会始终放弃开启直到被要求敞开。
一旦连贯开启,来自服务端传入的音讯会以事件的模式散发至你代码中。如果接管音讯中有一个事件字段,触发的事件与事件字段的值雷同。如果没有事件字段存在,则将触发通用事件。
与 WebSockets, 不同的是,服务端推送是单向的。数据信息被单向从服务端到客户端散发。当不须要以音讯模式将数据从客户端发送到服务器时,这使它们成为绝佳的抉择。例如,对于解决社交媒体状态更新,新闻提要或将数据传递到客户端存储机制(如 IndexedDB 或 Web 存储)之类的,EventSource 无疑是一个无效计划。
— 引自 MDN
比照 WebSocket,它就是 简略,不便,在特定的一些场景下,比方聊天音讯或市场价格,这就是 EventSource 善于的
应用形式
它的应用形式极其简略
const evtSource = new EventSource('sse.php');
const eventList = document.querySelector('ul');
evtSource.onmessage = function(e) {let newElement = document.createElement("li");
newElement.textContent = "message:" + e.data;
eventList.appendChild(newElement);
}
对吧,几行代码搞定,如何携带参数,在 new EventSource('sse.php?id=123');
其中 id=123
,就是咱们要给链接传的参数
问题来了
当我实现之后,发现它在一直的 主动重连?搜了很多文档,想不通,为何会主动重连,这里伏笔。想不通,ok,我就换个思路,改用 Axios 实现
axios
axios 实现如下
const streamToString = async (readableStream) => {return new Promise((resolve, reject) => {const chunks = [];
readableStream.on("data", (data) => {chunks.push(data);
});
readableStream.on("end", () => {resolve(Buffer.concat(chunks).toString('base64'))
});
readableStream.on("error", reject);
});
}
axios({
method: 'get',
url:`//xxx/api/chat/stream?prompt=${textarea.current.value.trim()}`,
headers: {'Content-Type': 'application/x-www-form-urlencoded'},
responseType: 'stream'
}).then(async res => {const raw = await streamToString(res.data);
})
此时还不知问题的 严重性!实现完之后,发现不对劲啊,readableStream.on is not a fucntion
,???(黑人问号脸),遂打印 log 看看输入的 res.data
是啥,字符串?基本不是一个办法啊,但看网上实现,是这样啊,没错?又看了几遍,都是这样实现的,很懵,直到看了下 axios 的 issue,传送门,2016 年就有人提出了这个问题,也就是说 axios 在浏览器侧始终没有实现 steram,我心田 cnm,网上的文档都是假的!!!
也就是说,依照目前 MDN 说法,responseType
反对的类型有,arraybuffer、blob、document、json、text、ms-stream
,其中 ms-stream
,此响应类型仅容许用于下载申请,并且仅受 Internet Explorer 反对
坑坑坑,又要开始了其余计划,想想 Fetch 能不能行,浏览器原生反对哦!
Fetch
Fetch API 提供了一个 JavaScript 接口,用于拜访和操纵 HTTP 管道的一些具体局部,例如申请和响应。它还提供了一个全局 fetch() 办法,该办法提供了一种简略,正当的形式来跨网络异步获取资源。
这种性能以前是应用 XMLHttpRequest 实现的。Fetch 提供了一个更现实的代替计划,能够很容易地被其余技术应用,例如 Service Workers。Fetch 还提供了专门的逻辑空间来定义其余与 HTTP 相干的概念,例如 CORS 和 HTTP 的扩大。
— 引自 MDN
利用 Fetch 实现了如下代码
const response = await fetch(`//xxx/api/chat/stream?prompt=${textarea.current.value.trim()}`);
const reader = response.body.getReader();
const eventList = document.querySelector('ul');
while (true) {const { value, done} = await reader.read();
const utf8Decoder = new TextDecoder('utf-8');
let data: any = value ? utf8Decoder.decode(value, {stream: true}) : '';
try {data = JSON.parse(data)
if (data.id || !data.content) {return}
let newElement = document.createElement("li");
newElement.textContent = "message:" + data.content;
eventList.appendChild(newElement);
} catch (e) { }
if (done) {break;}
}
实现没有问题,在我电脑上也跑通了,能稳固接管服务端音讯,不会主动重连,高枕无忧,转交敌人试用
。。。。
交给敌人试用,反馈说,会呈现回复不全???,调试搞起
浏览器侧接管的音讯
抓包看的音讯
比照看,浏览器侧 丢包!丢包了!!!几番排查下来,不知为何会丢包,而且是只有 Windows 上会丢包(必现),macOS 上不会,不懂了呀,咱们本人测试 Win 下 ping 都是稳固的,有懂的同学,能够告知下,谢谢!
最终解决方案
又回到 EventSource,没错,又回来了,折腾下来发现,每次收完音讯,你必须手动敞开下,evtSource.close();
,才不会主动重连,而且主动重连就是 EventSource 的个性之一,害,伏笔解决了。这个敞开有个前提是,服务端下发字段通知你,能敞开,你能力敞开哦,折腾啊!!!
总结
通过这次的学习,让我对 EventSource 以及 Fetch、Axios 有了一次粗浅的认知,大家看完感觉还不错的话,欢送点赞,珍藏哦
文章同步更新平台:掘金、CSDN、知乎、思否、博客,公众号(家养程序猿江辰)
我的联系方式,v:Jiang9684,欢送和我一起学习交换
完