跳到主要内容

实时通讯

  • WebSocket
  • Server-Sent Events（SSE）

WebSocket​

  • 双向通信：WebSocket允许客户端和服务器之间建立双向通信通道
  • 持久连接：一旦建立了WebSocket连接，它将保持打开状态，直到客户端或服务器明确关闭它。这降低了每次通信都需要建立新连接的开销。

适用场景：

  • 聊天应用
  • 监控数据
  • 实时销量
  • 即时通知应用程序

Server-Sent Events​

  • 单向通信：SSE允许服务器向客户端发送事件，但客户端不能向服务器发送数据。这是一种从服务器到客户端的单向流通信

  • 基于HTTP：SSE建立在HTTP协议之上，因此不需要额外的协议或端口。它使用简单的文本数据流，易于实现。

  • 自动重连：SSE具有自动重新连接的能力，如果连接中断，客户端会尝试重新连接服务器，确保持续接收事件

适用场景：

  • 即时更新的新闻网站
  • 实时监控系统
  • 服务器推送通知给客户端
  • 客户端不需要向服务器发送数据的应用程序

服务端设置​

  • 1、设置响应头
    • Content-Type: text/event-stream
      • 指定响应内容类型为 Event Stream，告诉客户端这是一个 SSE 响应
    • Cache-Control: no-cache
      • no-cache 指令确实会被缓存，只是每次使用缓存时都要向服务器验证缓存响应的有效性。这种方式确保了客户端获取的是最新的资源
    • Connection: keep-alive
    • 告诉服务器保持连接，以便持续发送事件给客户端。
  • 2、发送事件数据
  • 3、处理客户端断开连接

客户端设置​

  • 客户端通过创建一个 EventSource 对象来与服务器建立 SSE 连接
js
// 客户端创建 EventSource 对象，并指定要监听的服务器端SSE的URL
const eventSource = new EventSource('/api/v1/sse');

// 监听事件
eventSource.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log('Received message from server:', data.message);
  // Handle the received data as needed
};

// 处理错误
eventSource.onerror = (error) => {
  console.error('EventSource error:', error);
};

// 关闭连接
eventSource.close()

WebSocket和Server-Sent Event对比​

  • SSE服务器压力小，WebSocket服务器压力更大
  • SSE 是比较适合单向数据传递的场景，不需要客户端向服务端发送数据
  • WebSocket比SSE更强大，双向通信

WebRTC​

  • WebRTC（Web Real-Time Communication）是一种实时通信技术，用于在Web浏览器之间直接传输音频、视频和数据，而无需中间服务器的参与

谈谈长轮询​

  • 长轮询是基于HTTP的实时通信技术

长轮询工作原理​

  • 客户端发起请求：客户端发送HTTP请求到服务器，并等待响应。
  • 服务器保持连接：服务器收到请求后，不会立即响应，而是将连接挂起（hold），直到数据更新或达到预设超时时间。
  • 响应与重连
    • 有数据更新：服务器立即返回新数据，客户端处理数据后发起新请求。
    • 超时无更新：服务器返回空响应，客户端重新发起请求。

长轮询实现方案流程​

长轮询需要前后端配合

  • 1、客户端向服务端发起请求
  • 2、服务端挂起这个请求，若没有新数据，会保持连接状态，直到数据更新或者超时
    • 通常会设置30-60秒
  • 3、服务端响应处理
    • 若有新数据，服务端会立即响应，客户端处理数据后立即发起新请求
    • 若超时无数据，服务端返回空响应，如204状态码，客户端会重新发起请求
      • 204 No Content：服务端已经成功处理了请求，但是没有返回任何内容

1、前端处理完数据后立即发起新请求，维持长轮询

2、注意长轮询发起请求使用ajax/fetch，不能使用WebSocket、SSE

为什么长轮询能够在一定程度上减轻服务端的压力​

  • 长轮询通过减少无效请求、复用连接和服务端主动控制响应，降低了服务端压力
  • 减少无效请求次数，优化了传统的轮询模式

长轮询场景​

实时获取、实时性

  • 获取二维码的状态方案
    • 长轮询由前端发起请求，服务端会等到二维码扫描完成后才响应
    • 若二维码仍未被扫描，则会继续发送查询请求，直至状态变化（已失效或已成功）

长轮询和普通轮询区别​

指标普通轮询长轮询
请求频率固定间隔（如1秒1次）仅在数据更新或超时后触发（动态调整）
连接建立次数高（每次请求新建连接）低（连接复用，减少握手开销）
无效请求比例高（无数据更新时仍需处理请求）低（仅处理有效数据或超时）
实时性受限于轮询间隔（如1秒延迟）接近实时（数据更新后立即响应）
适用场景数据更新频率高且可预测数据更新频率低或不可预测