WebSockets & Realtime Systems Programming · 课时

重新认识服务器发送事件（SSE）

重新评估 SSE 在服务器到客户端单向流式传输中的作用，并针对特定使用场景将其与 WebSockets 进行比较。

重新认识服务器发送事件（SSE） 是 CoddyKit 上的免费 WebSockets & Realtime Systems Programming 课时。这是第 2 节课，共 4 节。你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。这是 WebSockets & Realtime Systems Programming 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 WebSockets & Realtime Systems Programming 课程共包含 4 节课。

本课时的部分内容尚未翻译，以英文显示。

Revisiting Server-Sent Events

Welcome back to Server-Sent Events (SSE)! While we briefly touched upon SSE earlier, this lesson dives deeper into its unique strengths and optimal use cases in modern realtime web development.

In a world dominated by WebSockets for full-duplex communication, SSE holds its ground for specific scenarios where a simpler, unidirectional stream is all you need.

SSE: Server-to-Client Only

The fundamental principle of SSE is its unidirectional nature. It allows a server to push updates to a client over a single, persistent HTTP connection.

Data flows only from the server to the client.
Clients cannot send messages back to the server using the same SSE connection.
This simplicity makes it ideal for broadcast-style updates.

Why Choose SSE? Key Benefits

SSE offers several advantages, especially when compared to constantly polling a server:

Simplicity: Built on HTTP, easier to implement than WebSockets for simple pushes.
Automatic Reconnection: Browsers handle reconnects automatically if the connection drops.
Event IDs: Built-in mechanism to track the last received event, preventing data loss.
Browser Native: Uses the standard EventSource API, no complex libraries needed.

SSE vs. WebSockets: Unidirectional vs. Bidirectional

This is the crucial distinction:

SSE: Best for scenarios where the client only needs to receive updates (e.g., news feeds, stock prices). It's like a radio broadcast.
WebSockets: Essential for interactive applications where clients and servers need to send and receive messages freely (e.g., chat apps, online gaming). It's like a phone call.

Choosing between them depends purely on your application's communication needs.

Use Case: Realtime Data Feeds

Consider applications that display live, constantly updating information. These are perfect candidates for SSE:

Stock Tickers: Displaying real-time changes in stock prices.
News Feeds: Pushing new headlines or articles as they're published.
Sports Scores: Instant updates on game scores or events.

The client just listens; it doesn't need to send anything back to initiate updates.

Use Case: Notifications and Progress

Another strong use case for SSE is delivering non-interactive notifications or tracking progress:

User Notifications: "You have a new message!" or "Your friend liked your post."
Background Job Progress: Showing the status of a long-running server task (e.g., "File upload 50% complete").

These scenarios benefit from the server pushing updates without client request, and the client doesn't need to respond.

Building an SSE Server (Node.js)

Here's a simple Node.js example using Express to create an SSE endpoint. Notice the Content-Type header, crucial for SSE.

Try running this example:

const express = require('express');
const app = express();
const PORT = 3000;

app.get('/events', (req, res) => {
  res.setHeader('Content-Type', 'text/event-stream');
  res.setHeader('Cache-Control', 'no-cache');
  res.setHeader('Connection', 'keep-alive');
  res.flushHeaders(); // Flush headers to establish connection

  let counter = 0;
  const intervalId = setInterval(() => {
    counter++;
    res.write(`data: Server time: ${new Date().toLocaleTimeString()}, count: ${counter}\n\n`);
    if (counter >= 5) {
      res.end(); // End connection after 5 messages
      clearInterval(intervalId);
    }
  }, 1000);

  req.on('close', () => {
    console.log('Client disconnected');
    clearInterval(intervalId);
  });
});

app.get('/', (req, res) => {
  res.send('<p>Go to <a href="/events">/events</a> to see SSE stream.</p><script>const eventSource = new EventSource("/events"); eventSource.onmessage = function(event) { console.log(event.data); document.body.innerHTML += `<p>${event.data}</p>`; }; eventSource.onerror = function(error) { console.error("SSE Error:", error); };</script>');
});

app.listen(PORT, () => {
  console.log(`SSE server listening on port ${PORT}`);
});

Consuming SSE in the Browser

On the client side, consuming SSE is straightforward using the native EventSource API. No special libraries are needed!

This JavaScript snippet shows how to connect and handle incoming messages:

const eventSource = new EventSource('/my-sse-endpoint');

eventSource.onmessage = function(event) {
  console.log("Data received:", event.data);
  // event.data contains the message payload
  // event.lastEventId contains the ID of the last event
};

eventSource.addEventListener('myCustomEvent', function(event) {
  console.log("Custom event received:", event.data);
});

eventSource.onopen = function() {
  console.log("SSE connection established.");
};

eventSource.onerror = function() {
  console.error("SSE connection error or closed.");
  if (eventSource.readyState === EventSource.CLOSED) {
    console.log("Connection closed. Browser will try to reconnect.");
  }
};

// To manually close the connection
// eventSource.close();

Understanding SSE's Limitations

While powerful for its niche, SSE isn't a silver bullet. Be aware of its limitations:

No Bidirectional Communication: Clients cannot send data back to the server over the SSE connection. For that, you need a separate HTTP request or WebSockets.
Text-Only Data: SSE natively supports only UTF-8 encoded text data. Binary data requires encoding (e.g., Base64), adding overhead.
Connection Limits: Browsers typically limit the number of concurrent HTTP connections (usually 6-8 per domain), which applies to SSE.

Event IDs and Automatic Reconnects

EventSource offers built-in features for robustness:

Last-Event-ID: If the connection drops, the browser automatically includes the Last-Event-ID header in the reconnection request. The server can use this to send only missed events.
Automatic Reconnection: The browser automatically attempts to reconnect to the SSE endpoint if the connection is lost. The server can also suggest a retry interval using retry: field.

These features greatly simplify error handling compared to polling.

SSE Quick Check

Considering the core functionalities, which statement best describes Server-Sent Events (SSE)?

SSE Revisited: Recap

In this lesson, we revisited Server-Sent Events (SSE), understanding its distinct role in realtime web applications.

SSE is ideal for unidirectional server-to-client streaming, perfect for live feeds and notifications.
It's simpler to implement than WebSockets for push-only scenarios, offering automatic reconnection and event IDs.
Remember its limitations: no client-to-server communication and text-only data.

Choose SSE when you only need the server to broadcast updates to clients, keeping your architecture lean and efficient.

常见问题解答

「重新认识服务器发送事件（SSE）」课时是免费的吗？

是的 — 「重新认识服务器发送事件（SSE）」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 WebSockets & Realtime Systems Programming 课程的其余内容，请升级到 CoddyKit PRO。 WebSockets & Realtime Systems Programming 课程共包含 4 节课。

「重新认识服务器发送事件（SSE）」这节课中我会学到什么？

重新评估 SSE 在服务器到客户端单向流式传输中的作用，并针对特定使用场景将其与 WebSockets 进行比较。你通过在浏览器中直接运行的动手代码来练习 WebSockets & Realtime Systems Programming，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 WebSockets & Realtime Systems Programming 需要有经验吗？

无需任何先前经验。CoddyKit 上的 WebSockets & Realtime Systems Programming 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。这是第 2 节课，共 4 节。

「重新认识服务器发送事件（SSE）」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 WebSockets & Realtime Systems Programming 课中编写并运行代码吗？

能。每节 WebSockets & Realtime Systems Programming 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

← 返回 WebSockets & Realtime Systems Programming