⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 ithan.blog.csdn.net/article/details/135012848 「IT·陈寒」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

1. 引言

在构建基于浏览器的实时对话系统时，开发者通常会选择使用WebSocket作为实现实时通信的协议。然而，有些场景下，使用EventSource作为替代方案也是一个值得考虑的选择。

“

本文将深入探讨为什么ChatGPT对话系统选择使用EventSource而非WebSocket，并通过代码示例和详细解释，帮助读者理解这一决策的原因。

2. WebSocket和EventSource简介

2.1 WebSocket

WebSocket是一种在单个TCP连接上进行全双工通信的协议，它允许在客户端和服务器之间进行实时的双向数据传输。WebSocket通过一个持久的连接，使得服务器能够主动向客户端推送数据，而不需要客户端发起请求。

2.2 EventSource

EventSource是HTML5引入的一种轻量级的、基于文本的协议，用于从服务器推送事件。与WebSocket不同，EventSource建立在HTTP协议之上，使用了单向的服务器推送。它允许服务器发送事件到客户端，但客户端只能接收而不能发送。

3. ChatGPT对话系统的特点

ChatGPT对话系统作为一个浏览器端的实时对话应用，具有以下特点：

单向通信： ChatGPT对话系统是用户向模型发送消息，模型回复消息的单向通信模式。
长轮询： 对于模型的回复，ChatGPT通常使用长轮询等待模型的响应。

4. EventSource的优势

4.1 简单易用

EventSource相对于WebSocket而言更为简单易用。它建立在HTTP协议之上，无需进行握手等复杂的初始化过程。在浏览器端，使用EventSource只需要创建一个EventSource对象并指定服务器的URL即可。

4.2 容错性强

EventSource具有良好的容错性。当连接断开时，它会自动尝试重新连接，而不需要开发者手动处理重新连接的逻辑。这使得在不稳定的网络环境中，EventSource更为可靠。

4.3 兼容性良好

相对于WebSocket，EventSource在浏览器的兼容性方面更有优势。绝大多数现代浏览器都原生支持EventSource，而WebSocket则需要额外的处理以兼容一些旧版本的浏览器。

5. 为何选择EventSource而非WebSocket？

ChatGPT对话系统之所以选择EventSource而非WebSocket，主要是基于以下考虑：

5.1 单向通信模式

由于ChatGPT对话系统是用户向模型发送消息，模型回复消息的单向通信模式，WebSocket的双向通信能力并没有被充分利用。使用WebSocket会引入不必要的复杂性，而EventSource更符合ChatGPT对话系统的通信需求。

5.2 长轮询模式

ChatGPT通常使用长轮询等待模型的回复，而EventSource天然支持这种模式。WebSocket在这种场景下并没有显著的优势，反而会增加额外的复杂性。

5.3 简化部署和维护

使用EventSource可以简化部署和维护工作。由于EventSource建立在HTTP协议之上，无需考虑WebSocket的握手和心跳等复杂机制，使得整体系统更加简洁。

6. 使用EventSource的代码示例

6.1 服务端实现

在服务端，使用Node.js和Express框架作为演示：

const express = require('express');
const { v4: uuidv4 } = require('uuid');

const app = express();
const port = 3000;

const clients = new Map();

app.get('/events', (req, res) => {
  const clientId = uuidv4();
  const newClient = res;
  clients.set(clientId, newClient);

  req.on('close', () => {
    clients.delete(clientId);
  });

  res.setHeader('Content-Type', 'text/event-stream');
  res.setHeader('Cache-Control', 'no-cache');
  res.setHeader('Connection', 'keep-alive');
  res.flushHeaders();

  clients.forEach((client) => {
    client.write(`data: A new user joined!\n\n`);
  });
});

app.post('/send-message', express.json(), (req, res) => {
  const { message } = req.body;

  clients.forEach((client) => {
    client.write(`data: ${message}\n\n`);
  });

  res.status(200).send('Message sent successfully!');
});

app.listen(port, () => {
  console.log(`Server is listening at http://localhost:${port}`);
});

6.2 客户端实现

在浏览器端，使用JavaScript：

const eventSource = new EventSource('http://localhost:3000/events');

eventSource.onmessage = (event) => {
  const message = event.data;
  console.log(`Received message: ${message}`);
};

document.getElementById('sendMessageBtn').addEventListener('click', () => {
  const message = prompt('Enter your message:');
  fetch('http://localhost:3000/send-message', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ message }),
  });
});

在上述代码中，客户端通过EventSource建立与服务器的连接，并监听onmessage事件处理服务器发送的消息。用户可以通过点击按钮发送消息，服务器将消息广播给所有连接的客户端。

7. 性能考量与拓展

7.1 性能考量

在性能方面，WebSocket通常更为高效，因为它建立在TCP连接上，具有低延迟和高吞吐量的特性。然而，对于一些实时性要求不高或者场景较为简单的应用，EventSource的性能已经足够满足需求，并且其简洁性更加符合一些特定场景的需求。

7.2 拓展可能性

ChatGPT对话系统可以考虑在未来的版本中增加对WebSocket的支持，以应对一些需要更低延迟、更高实时性的场景。通过在系统中引入灵活的通信机制，可以更好地满足不同用户和应用的需求。

8. 总结

本文深入探讨了为什么ChatGPT对话系统选择使用EventSource而非WebSocket。通过对WebSocket和EventSource的简介、ChatGPT对话系统特点以及EventSource的优势进行分析，我们发现在特定场景下，选择EventSource能够更好地满足应用需求，简化部署和维护工作。

最后，通过代码示例展示了如何在ChatGPT对话系统中使用EventSource实现实时通信，并对性能考量和拓展可能性进行了讨论。在实际应用中，开发者可以根据具体需求选择最适合的通信方式，以提供更好的用户体验和系统性能。

芋道源码 —— 纯源码解析博客

ChatGPT对话为什么不用WebSocket而使用EventSource？