EventSource & WebSocket & HTTP

一、EventSource（SSE / 服务器发送事件）

通俗理解：相当于服务器给客户端开了一个"专属推送通道"，一旦连接建立，服务器就能随时给客户端发消息，客户端只能接收不能主动发送，就像老师给学生单方面发通知，不用学生反复问。

专业定义 ：EventSource 是浏览器原生 API，用于建立单向、持久的 HTTP 长连接，让服务器主动向客户端推送实时数据，也被称为 SSE（Server-Sent Events），是轻量级实时推送解决方案。

1. 核心特点（必背）

• 单向通信：仅支持「服务器 → 客户端」单向推送，区别于 WebSocket 的双向通信，适合只需要服务器主动发消息的场景（比如公告推送）。

• 基于标准 HTTP：无需升级协议，普通后端接口就能支持，不用像 WebSocket 那样单独配置协议，接入成本极低。

• 自动重连：网络断开、服务器异常时，浏览器会自动重试连接（默认重试间隔几秒），无需手动写重连逻辑，降低开发成本。

• 事件驱动：支持自定义事件类型（比如 userUpdate、systemNotice），还能设置消息 ID，实现断线续连（重连时会携带上一次的消息 ID，避免漏收消息）。

• 轻量简单：API 简洁、代码量少，比 WebSocket 更轻量，无需处理复杂的双向通信逻辑，适合简单实时场景。

2. 前端基本用法（可直接默写）

// 1. 建立连接（参数是后端 SSE 接口地址）
const es = new EventSource('/api/sse');

// 2. 监听默认消息（服务器未指定 event 时触发）
es.onmessage = (e) => {
  console.log('收到默认消息:', e.data); // e.data 是服务器发送的字符串，需自行解析 JSON
};

// 3. 监听自定义事件（服务器通过 event: 字段指定事件名）
es.addEventListener('userUpdate', (e) => {
  const data = JSON.parse(e.data); // 通常服务器会发 JSON 字符串，需解析
  console.log('用户信息更新:', data);
});

// 4. 监听连接状态
es.onopen = () => console.log('SSE 连接成功'); // 连接建立时触发
es.onerror = (err) => {
  console.error('SSE 连接出错/断开:', err);
  // 特殊场景可手动关闭，避免无效重连
  // es.close();
};

// 5. 手动关闭连接（不需要时调用，比如页面销毁时）
// es.close();

3. 服务器端要求（关键考点）

SSE 能正常工作，服务器响应必须满足两个核心要求：正确设置响应头 + 规范的数据格式，缺一不可。

（1）必须设置的响应头

Content-Type: text/event-stream  // 告诉浏览器这是 SSE 流数据
Cache-Control: no-cache          // 禁止缓存，避免浏览器缓存旧消息
Connection: keep-alive           // 保持 HTTP 长连接，避免连接被断开

（2）规范的数据格式

数据必须以 \n\n 结尾（表示一条消息结束），支持三种核心字段，可组合使用：

// 1. 普通消息（仅含数据，触发前端 onmessage）
data: 这是一条普通消息\n\n

// 2. 带自定义事件名（触发前端对应 addEventListener 监听的事件）
event: userUpdate          // 事件名，与前端监听的一致
data: {"id":1,"name":"张三"}\n\n  // 数据，建议用 JSON 字符串

// 3. 带消息 ID（用于断线续连，重连时浏览器会发送 Last-Event-ID 头）
id: 1001                   // 消息唯一 ID
data: 带 ID 的消息内容\n\n

4. 适用场景（区分记忆，避免混淆）

• 实时通知类：系统公告、用户消息提醒、订单状态通知（只需要服务器推，客户端不用回）。

• 数据刷新类：股票/基金行情、实时监控数据（如服务器负载、设备状态）、日志流展示。

• 进度展示类：文件上传/下载进度、任务执行进度（服务器实时推送进度百分比）。

• 简单聊天场景：仅需要服务器转发消息（如广播消息），无需客户端主动发消息的场景。

5. EventSource vs WebSocket vs 轮询（面试高频对比）

特性	EventSource (SSE)	WebSocket	轮询 (Polling)
通信方向	单向（服务→客）	双向（客↔服）	客户端主动拉取（客→服→客）
底层协议	标准 HTTP 协议	独立 WebSocket 协议（握手用 HTTP）	标准 HTTP 协议
重连机制	浏览器自动重连	需手动实现重连逻辑	无内置重连（靠定时发送请求模拟）
开发复杂度	低（原生 API，无需额外依赖）	中（需处理双向通信、重连、心跳）	低（简单请求响应），但低效
延迟	低（服务器实时推送）	极低（长连接双向实时传输）	高（取决于定时间隔，如10秒轮询则延迟最高10秒）
适用场景	简单单向实时推送	高频双向交互	实时性要求低、简单场景

一句话记忆（必背）：需要简单单向实时推送 → 用 EventSource；需要全双工、高频交互 → 用 WebSocket；实时性要求低、开发最简单 → 用轮询（不推荐）。

6. EventSource 面试常考问题（直接背诵答案）

• 问题1 ：EventSource 是什么？和 WebSocket 的核心区别是什么？

  答：EventSource 是浏览器原生 API，基于 HTTP 长连接实现服务器到客户端的单向实时推送（SSE）；核心区别是通信方向（SSE 单向，WebSocket 双向）和协议（SSE 基于 HTTP，WebSocket 是独立协议）。

• 问题2 ：EventSource 服务器端需要满足什么要求？

  答：一是设置3个核心响应头（Content-Type: text/event-stream、Cache-Control: no-cache、Connection: keep-alive）；二是数据格式必须以 \n\n 结尾，支持 data、event、id 三个字段。

• 问题3 ：EventSource 为什么能自动重连？断线续连是怎么实现的？

  答：浏览器原生内置自动重连机制，网络断开后会定期重试；断线续连靠消息 ID（id 字段），重连时浏览器会发送 Last-Event-ID 请求头，服务器根据该 ID 推送未接收的消息，避免漏收。

• 问题4 ：EventSource 的适用场景有哪些？举2个例子。

  答：适合单向实时推送场景，比如系统公告推送、股票行情刷新、任务进度展示；例子：1. 网站实时公告弹窗；2. 后台任务执行进度实时展示。

二、WebSocket（面试重点）

通俗理解：相当于客户端和服务器之间架了一条"双向通话线路"，一旦接通，双方都能随时说话、听对方说话，不用反复拨号（不像 HTTP 每次请求都要建立连接），适合实时互动场景。

专业定义 ：WebSocket 是一种在单个 TCP 连接上进行全双工、长连接的网络协议，允许客户端和服务器之间实时双向通信，建立连接后可持续收发数据，无需频繁创建 HTTP 请求，解决了 HTTP 无法主动推送、轮询低效的问题。

1. 核心特点（必背）

• 全双工通信：客户端和服务器双向通信，双方都能随时主动发送消息（比如聊天时，你发消息给服务器，服务器也能主动推别人的消息给你）。

• 长连接：一次握手成功后，TCP 连接持续保持，直到客户端或服务器主动关闭，无需每次通信都建立新连接，减少开销。

• 轻量高效：数据传输的帧头非常小（远小于 HTTP 请求头），传输效率高，适合高频实时数据交互。

• 协议兼容：基于 TCP 协议，端口通常使用 80（ws）/443（wss），兼容大部分防火墙，不易被拦截。

• 协议升级：不属于 HTTP 协议，但握手阶段依赖 HTTP 协议完成"升级"，握手成功后不再使用 HTTP 协议。

2. 建立过程（关键考点，必背）

WebSocket 建立连接分为"握手阶段"和"通信阶段"，核心是握手时完成 HTTP 协议升级，步骤如下：

1. 客户端发起 HTTP 请求，携带"协议升级"相关请求头，告知服务器要升级为 WebSocket 协议：
   Connection: Upgrade // 表示要升级协议 Upgrade: websocket // 要升级的目标协议是 WebSocket Sec-WebSocket-Key: xxxxxxxx // 随机字符串，用于服务器校验 Sec-WebSocket-Version: 13 // WebSocket 版本，固定为13

2. 服务器接收请求后，校验 Sec-WebSocket-Key，确认可以升级协议，返回 101 状态码（Switching Protocols），完成握手：
   HTTP/1.1 101 Switching Protocols Connection: Upgrade Upgrade: websocket Sec-WebSocket-Accept: xxxxxxxx // 服务器对 Sec-WebSocket-Key 加密后的结果

3. 握手成功后，HTTP 协议正式升级为 WebSocket 协议，后续双方通过 WebSocket 数据帧进行双向通信，不再使用 HTTP 协议。

3. 前端基本使用（可直接默写）

// 1. 创建 WebSocket 连接（ws 是普通连接，wss 是加密连接，类似 http/https）
const ws = new WebSocket('ws://localhost:8080');

// 2. 连接成功（握手完成后触发）
ws.onopen = () => {
  console.log('WebSocket 连接成功');
  // 连接成功后，客户端可主动发送消息
  ws.send('hello server，我是客户端'); // 发送的是字符串，复杂数据需转 JSON
};

// 3. 接收服务器发送的消息
ws.onmessage = (e) => {
  // e.data 是服务器发送的内容，可根据需求解析 JSON
  console.log('收到服务器消息:', e.data);
};

// 4. 连接错误（如服务器异常、网络断开）
ws.onerror = (err) => {
  console.error('WebSocket 连接出错:', err);
};

// 5. 连接关闭（客户端或服务器主动关闭）
ws.onclose = (event) => {
  console.log('WebSocket 连接关闭', event.code, event.reason);
  // 可在这里实现手动重连逻辑
};

// 补充：主动关闭连接
// ws.close();

4. 核心区别（面试高频，对比记忆）

（1）WebSocket vs HTTP

• HTTP：短连接、单向通信、无状态，每次通信都要建立 TCP 连接，客户端发起请求后，服务器才会响应，无法主动推送。

• WebSocket：长连接、双向通信、有状态，一次握手后持续连接，双方可随时主动发送消息，无需频繁建连。

（2）WebSocket vs EventSource（SSE）

• EventSource：单向通信（服务→客）、基于 HTTP、自动重连，轻量简单，适合简单推送场景。

• WebSocket：双向全双工、独立协议、需手动重连，功能更强，适合高频交互场景，开发复杂度稍高。

5. 适用场景（精准记忆，避免混淆）

• 实时交互类：在线聊天、弹幕、直播互动（如点赞、评论实时展示）。

• 高频数据类：在线游戏（玩家操作实时同步）、股票行情实时刷新、实时监控大屏。

• 协作编辑类：多人在线文档协作（如腾讯文档）、实时白板。

6. 补充细节（面试加分点）

• WebSocket 数据传输格式：分为文本帧和二进制帧，可传输字符串、JSON、图片等数据。

• 心跳机制：由于网络波动，长连接可能被网关断开，通常需要手动实现心跳（客户端定期发送空消息，服务器回应），维持连接。

• 加密连接：wss 是 WebSocket 的加密版本，基于 TLS/SSL 加密，和 https 类似，更安全，生产环境推荐使用。

7. 一句话总结（必背）

WebSocket 是一种双向实时长连接协议，基于 TCP 实现，通过 HTTP 握手升级协议，解决了 HTTP 无法主动推送、轮询低效的问题，适合高实时性交互场景。

8. WebSocket 面试常考问题（直接背诵答案）

• 问题1 ：WebSocket 是什么？核心特点有哪些？

  答：WebSocket 是基于 TCP 的全双工长连接网络协议，允许客户端和服务器实时双向通信；核心特点是全双工、长连接、轻量高效、基于 HTTP 握手升级、兼容防火墙。

• 问题2 ：WebSocket 的建立过程是什么？关键请求头和响应头有哪些？

  答：建立过程分3步：1. 客户端发 HTTP 请求，携带 Connection: Upgrade、Upgrade: websocket、Sec-WebSocket-Key 等头；2. 服务器返回 101 状态码，携带 Sec-WebSocket-Accept 头，完成协议升级；3. 升级为 WebSocket 协议，开始双向通信。

• 问题3 ：WebSocket 和 HTTP、EventSource 的核心区别是什么？

  答：和 HTTP 比：WebSocket 是长连接、双向通信，HTTP 是短连接、单向请求响应；和 EventSource 比：WebSocket 是双向全双工，需手动重连，EventSource 是单向推送，自动重连，基于 HTTP。

• 问题4 ：WebSocket 为什么需要心跳机制？如何实现？

  答：因为网络波动、网关超时等原因，长连接可能被断开，心跳机制用于维持连接；实现方式：客户端定期（如30秒）发送空消息（或特定心跳消息），服务器收到后回应，若客户端长时间未收到回应，则触发重连。

• 问题5 ：ws 和 wss 的区别是什么？生产环境为什么推荐用 wss？

  答：ws 是 WebSocket 普通连接，明文传输；wss 是加密连接，基于 TLS/SSL 加密，数据传输更安全；生产环境用 wss 可避免数据被窃听、篡改，符合安全规范。

三、HTTP（超文本传输协议，基础必背）

通俗理解：相当于互联网的"通信规则"，客户端（比如浏览器）和服务器之间要传输数据，必须遵守这个规则，本质是"一问一答"------客户端问（请求），服务器答（响应），是互联网最基础的通信协议。

专业定义 ：HTTP（HyperText Transfer Protocol，超文本传输协议）是一种基于请求-响应模型、无状态的应用层协议，用于客户端和服务器之间传输超文本（HTML、JSON、图片等），是互联网数据传输的基础。

1. 核心特点（必背）

1. 基于请求-响应模型：严格遵循"客户端发起请求 → 服务器处理请求 → 服务器返回响应"的流程，一问一答，没有请求就没有响应。

2. 无状态（Stateless）：服务器不记住任何客户端的上下文信息，每次请求都是独立的，服务器无法通过前一次请求判断当前请求的客户端身份；需要维持状态（如登录状态），需借助 Cookie、Session、Token 等机制。

3. 明文传输：HTTP 传输的内容不加密，数据在传输过程中可能被窃听、篡改，安全性低；因此有了 HTTPS（HTTP + TLS/SSL 加密）。

4. 可扩展性强：支持自定义请求头/响应头、扩展请求方法、扩展状态码，能适应不同的业务场景（如跨域预检、缓存控制）。

5. 基于 TCP 可靠传输：底层默认使用 TCP 协议，保证数据能可靠到达（TCP 有重传、校验机制），但也因此存在建立连接的延迟（三次握手）。

2. 请求结构（必背，面试常考）

一次 HTTP 请求由「请求行、请求头、空行、请求体」四部分组成，缺一不可，结构如下：

1. 请求行（Request Line） ：核心部分，包含请求方法、请求 URL、HTTP 协议版本，格式：请求方法 + 空格 + URL + 空格 + 协议版本 + 换行GET /api/user HTTP/1.1 // 示例：GET 方法，请求地址 /api/user，协议版本 1.1

2. 请求头（Request Headers）：用于传递客户端信息、请求参数等，键值对形式，常见字段：

   • Host：请求的服务器域名（如 www.baidu.com）。

   • User-Agent：客户端信息（如浏览器版本、设备型号）。

   • Content-Type：请求体的数据格式（如 application/json、multipart/form-data）。

   • Cookie：携带客户端的 Cookie 信息（用于维持登录状态）。

   • Authorization：身份验证信息（如 Token、Basic 认证）。

3. 空行：用于分隔请求头和请求体，必须存在（即使没有请求体），告诉服务器请求头已结束。

4. 请求体（Request Body）：可选，用于携带客户端提交的数据（如 POST 请求的表单数据、JSON 数据）；GET 方法通常没有请求体（参数放在 URL 中），POST、PUT、PATCH 等方法常用请求体。

3. 常用请求方法（必背，区分含义和使用场景）

请求方法	核心含义	关键特点	使用场景
GET	获取服务器资源	参数在 URL 中，可缓存，幂等（多次请求结果一致）	查询数据（如查询用户信息、商品列表）
POST	向服务器提交数据	参数在请求体，不可缓存，非幂等	提交表单、创建资源（如注册、新增订单）
PUT	更新服务器资源（完整覆盖）	参数在请求体，幂等	完整更新资源（如修改用户所有信息）
PATCH	更新服务器资源（部分更新）	参数在请求体，幂等	部分更新资源（如只修改用户手机号）
DELETE	删除服务器资源	幂等	删除资源（如删除订单、删除用户）
HEAD	获取响应头，不获取响应体	和 GET 类似，仅返回头部	检查资源是否存在、获取资源缓存信息
OPTIONS	预检请求，获取服务器支持的方法	跨域场景下自动触发	跨域请求前，验证服务器是否允许当前请求

补充：幂等性：多次执行同一请求，结果一致（不会因为多次请求导致资源状态变化），GET、PUT、DELETE、PATCH 是幂等的，POST 是非幂等的。

4. 响应结构（必背，和请求结构对应）

一次 HTTP 响应由「状态行、响应头、空行、响应体」四部分组成，结构如下：

1. 状态行（Status Line） ：包含 HTTP 协议版本、状态码、状态描述，格式：协议版本 + 空格 + 状态码 + 空格 + 状态描述 + 换行HTTP/1.1 200 OK // 示例：协议 1.1，状态码 200，描述 OK（成功）

2. 响应头（Response Headers）：传递服务器信息、响应参数等，常见字段：

   • Content-Type：响应体的数据格式（如 application/json、text/html）。

   • Set-Cookie：服务器向客户端设置 Cookie。

   • Cache-Control：缓存控制策略（如 no-cache、max-age=3600）。

   • Location：重定向地址（配合 3xx 状态码使用）。

3. 空行：分隔响应头和响应体，必须存在。

4. 响应体（Response Body）：服务器返回给客户端的具体数据，可能是 HTML、JSON、图片、视频等。

5. 常见状态码（必背，按类别记忆）

状态码分为5大类，每类有核心常用码，记住类别含义+常用码即可，无需记所有码：

1. 1xx（信息类）：表示服务器已接收请求，正在继续处理，很少用到。

   • 100 Continue：服务器已接收请求头，客户端可继续发送请求体。

2. 2xx（成功类）：请求成功被服务器处理。

   • 200 OK：请求成功（最常用）。

   • 201 Created：资源创建成功（如 POST 新增用户、订单）。

   • 204 No Content：请求成功，但无响应体（如 DELETE 删除成功）。

3. 3xx（重定向类）：请求需要客户端进一步操作（跳转）。

   • 301 永久重定向：请求的资源已永久迁移到新地址，后续请求需用新地址（如域名更换）。

   • 302 临时重定向：请求的资源临时迁移，后续请求仍可用原地址（如登录后跳转）。

   • 304 Not Modified：协商缓存命中，服务器无需返回资源（客户端直接用本地缓存）。

4. 4xx（客户端错误类）：请求有问题，服务器无法处理（客户端责任）。

   • 400 Bad Request：请求参数错误（如格式错误、缺少必填参数）。

   • 401 Unauthorized：未登录（需要身份验证，如未传 Token）。

   • 403 Forbidden：已登录，但无权限访问（如普通用户访问管理员接口）。

   • 404 Not Found：请求的资源不存在（如 URL 写错）。

   • 405 Method Not Allowed：请求方法不被允许（如用 GET 访问需要 POST 的接口）。

   • 429 Too Many Requests：请求过于频繁（限流）。

5. 5xx（服务端错误类）：服务器处理请求时出错（服务器责任）。

   • 500 Internal Server Error：服务器内部错误（最常见，如代码报错）。

   • 502 Bad Gateway：网关错误（如服务器依赖的服务不可用）。

   • 503 Service Unavailable：服务不可用（如服务器过载、维护）。

   • 504 Gateway Timeout：网关超时（服务器依赖的服务响应太慢）。

6. HTTP 版本演进（必背，核心差异）

HTTP 经历了多个版本，核心演进方向是"提升性能、降低延迟、增强安全性"，重点记 1.0、1.1、2、3 四个版本：

• HTTP/1.0（早期版本）：

  • 一次请求一个 TCP 连接，用完就断开（短连接）。

  • 串行请求：一个请求完成后，才能发起下一个请求，效率极低。

• HTTP/1.1（目前最常用）：

  • 支持长连接（Keep-Alive）：一个 TCP 连接可发送多个 HTTP 请求，减少建连开销。

  • 存在队头阻塞（Head-of-line Blocking）：同一 TCP 连接中，一个请求卡住，后面所有请求都要等待。

  • 支持管道化、分块传输编码，优化传输效率。

• HTTP/2（性能优化版）：

  • 二进制分帧：将请求/响应拆分为二进制帧，传输更高效。

  • 多路复用：一个 TCP 连接可并行处理多个请求，彻底解决队头阻塞。

  • 头部压缩（HPACK）：压缩请求头/响应头，减少传输体积。

  • 服务器推送（Server Push）：服务器可主动向客户端推送资源（如 HTML 所需的 CSS、JS）。

• HTTP/3（最新版本）：

  • 底层改用 QUIC 协议 + UDP，不再依赖 TCP。

  • 彻底解决队头阻塞（UDP 无连接，帧独立传输）。

  • 连接迁移更稳定（如手机切换网络，无需重新建立连接），传输速度更快、更可靠。

7. 核心区别（面试高频）

• HTTP vs HTTPS：HTTP 是明文传输，不安全；HTTPS 是 HTTP + TLS/SSL 加密，数据传输安全，端口用 443（HTTP 用 80）。

• HTTP vs WebSocket：HTTP 是请求响应式、短连接、单向；WebSocket 是长连接、双向全双工，基于 HTTP 握手升级协议。

• HTTP vs EventSource（SSE）：HTTP 是单向请求响应，无法主动推送；SSE 是基于 HTTP 长连接，服务器单向推送，自动重连。

8. 一句话总结（必背，面试直接用）

HTTP 是基于 TCP 的请求响应式无状态应用层协议，负责客户端与服务器的数据传输，通过请求方法、URL、头部、状态码完成通信，HTTP/1.1 支持长连接但有队头阻塞，HTTP/2 用多路复用优化性能，HTTP/3 改用 QUIC 协议进一步提升效率。

9. HTTP 面试常考问题（直接背诵答案）

• 问题1 ：HTTP 是什么？核心特点有哪些？

  答：HTTP 是基于 TCP 的请求响应式无状态应用层协议，用于客户端和服务器传输数据；核心特点是请求响应模型、无状态、明文传输、可扩展、基于 TCP 可靠传输。

• 问题2 ：HTTP 请求和响应的结构分别是什么？

  答：请求结构：请求行 + 请求头 + 空行 + 请求体；响应结构：状态行 + 响应头 + 空行 + 响应体。

• 问题3 ：GET 和 POST 的核心区别是什么？（至少3点）

  答：1. 用途：GET 用于获取资源，POST 用于提交资源；2. 参数位置：GET 参数在 URL，POST 参数在请求体；3. 缓存：GET 可缓存，POST 不可缓存；4. 幂等性：GET 幂等，POST 非幂等；5. 安全性：GET 明文传输（参数暴露），POST 相对安全（参数在请求体）。

• 问题4 ：常见的 HTTP 状态码分类及常用码有哪些？

  答：分5类：1xx 信息类（100）、2xx 成功类（200、201、204）、3xx 重定向类（301、302、304）、4xx 客户端错误（400、401、403、404、429）、5xx 服务端错误（500、502、503、504）。

• 问题5 ：HTTP/1.1 和 HTTP/2 的核心差异是什么？

  答：1. 传输方式：HTTP/1.1 是文本传输，HTTP/2 是二进制分帧；2. 队头阻塞：HTTP/1.1 有队头阻塞，HTTP/2 多路复用解决队头阻塞；3. 头部压缩：HTTP/2 支持 HPACK 头部压缩，HTTP/1.1 不支持；4. 服务器推送：HTTP/2 支持，HTTP/1.1 不支持。

• 问题6 ：HTTP 为什么是无状态的？如何解决无状态的问题？

  答：无状态是因为服务器不记住客户端的上下文信息，每次请求都是独立的；解决方式：使用 Cookie、Session、Token 等机制，存储客户端状态信息（如登录状态）。

• 问题7 ：HTTP 和 HTTPS 的区别是什么？HTTPS 的加密原理是什么？

  答：区别：HTTP 明文传输、不安全、端口80；HTTPS 加密传输、安全、端口443，基于 HTTP + TLS/SSL。加密原理：采用对称加密（传输数据）+ 非对称加密（交换对称密钥）+ 数字证书（验证服务器身份），保证数据机密性、完整性、真实性。

面试复习提示：重点背诵「核心特点、一句话总结、面试常考问题」，代码示例可默写核心片段，对比类知识点（如三者对比、版本对比）重点记差异点，确保面试时能快速应答、不混淆。