Logo花儿尊上
←Back to Journal
02 / Entry· 7 min read

HTTP、HTTPS、WS、WSS、SSE 到底有什么区别

想搞懂 HTTP/HTTPS 请求响应、WebSocket/WSS 双向通信、SSE 服务器推送的区别？本文通过对比分析，助你快速掌握不同通信方式的应用场景。

networkprotocol
🔊 系统朗读

写 Web 应用，这几个缩写迟早都会碰上：HTTP、HTTPS、WS、WSS、SSE。它们长得像，也经常被混着说，但背后是不同的通信方式和安全级别。

先给个最粗的印象：

  • HTTP：浏览器和服务器之间最基础的请求响应协议
  • HTTPS：加了一层加密的 HTTP
  • WS：WebSocket，浏览器和服务器之间的双向长连接
  • WSS：加了加密的 WebSocket
  • SSE：Server-Sent Events，服务器单向往浏览器推事件流

光记这五条意义不大。要分清它们，其实盯住两件事就够了：消息往哪个方向走，连接加不加密。下面就顺着这两条线一个个看。

HTTP：最基础的请求和响应

HTTP 全称 HyperText Transfer Protocol，超文本传输协议。它本来是给浏览器取网页用的，后来几乎所有互联网应用都跑在它上面。

模型简单到一句话能说完：

text
客户端发请求 -> 服务端处理 -> 服务端返回响应

浏览器要一个页面，发出去是这样：

http
GET /articles/1 HTTP/1.1
Host: example.com

服务器回过来：

http
HTTP/1.1 200 OK
Content-Type: text/html

<html>...</html>

这里有个关键点：HTTP 里永远是客户端先开口，服务端只能等着被问，不能自己主动给客户端塞消息。这个限制后面会反复提到，因为 WebSocket 和 SSE 某种程度上都是在绕开它。

正因为这个特点，HTTP 拿来做这些事很顺手：

  • 打开网页，加载图片、CSS、JS
  • 调 REST API、提交表单
  • 查一次数据、做一次性的操作

还有一点常被误解：HTTP 是无状态的。无状态不是说服务器存不了数据，而是说协议本身不记得你上次来干过什么。你先后请求 /profile 和 /orders，在协议眼里就是两个互不相干的请求，它并不知道这俩是同一个人发的。把多次请求串成一个会话，是 Cookie、Session、Token、JWT 这些机制在背后做的，跟 HTTP 协议本身无关。

HTTPS：给 HTTP 套层加密

HTTPS 不是另起炉灶的新协议，它就是：

text
HTTP + TLS

在 HTTP 底下垫了一层 TLS 加密。

裸 HTTP 的麻烦在于数据是明文跑的。你连着公共 Wi-Fi 访问一个 HTTP 站点，路上任何一个网络节点理论上都能看到你请求了啥、提交了啥，甚至改掉服务器返回的内容你也察觉不到。

TLS 这层主要解决三件事：

  1. 加密：传输内容被加密，中间人就算截下来也读不懂。
  2. 身份认证：浏览器靠证书确认对面真的是 example.com，而不是冒充的。
  3. 完整性：内容在路上被动过手脚，双方能发现。

所以 HTTPS 不只是"更安全的 HTTP"，今天它基本是底线——登录、支付、后台、API，没什么理由不用。

地址上的区别大家都熟：

text
http://example.com
https://example.com

但本质区别不在那个 s，而在底下有没有走 TLS。

WS：让服务器也能主动发消息

HTTP 的一问一答很清楚，但前面说了，它有个硬限制：服务端不能主动推。

拿聊天举例。只用普通 HTTP 的话，客户端想知道有没有新消息，只能反复去问：

text
有新消息吗？
有新消息吗？
有新消息吗？

这就是轮询（polling）。短轮询费资源、还慢；后来改进出长轮询（long polling）——服务端先把请求挂住，有消息了再返回，没消息就拖到超时。长轮询能凑合用，但说到底还是拿请求响应硬凑实时效果。

WebSocket 是来正经解决这件事的。它在浏览器和服务器之间拉一条一直开着的连接，连上之后，两头谁想发就发：

text
客户端建立连接 <-> 服务端保持连接
客户端能随时发
服务端也能随时发

这跟 HTTP 一问一答完全不是一回事，更像一根一直通着的管子。

有意思的是，WebSocket 这条连接是从一个普通 HTTP 请求"升级"上来的。客户端先发一个带升级标记的请求：

http
GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

服务端同意的话，回一个 101：

http
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

握手过了这一下，连接就从 HTTP 切成 WebSocket，之后两边改用 WebSocket 帧来回传数据，不再走 HTTP 那套格式。

WebSocket 适合两头都要频繁说话的场景：

  • 聊天室、直播弹幕
  • 在线协作文档、多人编辑
  • 实时游戏、股票行情
  • 设备状态同步

一句话，它的卖点是"双向 + 实时"，客户端和服务端地位差不多，谁都能主动开口。

WSS：加密版的 WebSocket

WS 和 WSS 的关系，跟 HTTP 和 HTTPS 一模一样：

text
ws://example.com/socket    明文
wss://example.com/socket   加 TLS

生产环境用 WSS，别用 WS，理由跟 HTTPS 那套一样：加密、防篡改、能验证服务器身份。

还有个绕不开的限制：如果页面本身是 HTTPS，浏览器一般不让它去连明文的 ws://，因为这属于混合内容（mixed content），会被直接拦掉。所以 HTTPS 页面就得配 wss://，这不是建议，是硬要求。

SSE：服务器单向往下推

SSE 全称 Server-Sent Events。它也是服务器推送，但和 WebSocket 不同，它是单向的——只有服务器往客户端推，客户端没法顺着这条连接往回发消息。

模型是这样：

text
客户端发起一个 HTTP 连接
服务端就着这条连接，源源不断往下发事件

浏览器有原生的 EventSource 来连：

js
const source = new EventSource("/events");

source.onmessage = (event) => {
  console.log(event.data);
};

服务端那边把响应类型设成 text/event-stream，然后按一个很简单的文本格式往外吐：

text
data: hello

data: world

事件之间用一个空行隔开。除了 data，还有几个字段挺有用：id 给事件编号，event 指定事件名，retry 告诉浏览器断了之后隔多久重连。

SSE 有几个特点值得单独拎出来：

  • 它就是普通 HTTP，不需要协议升级，老的网关、代理基本都认。
  • 断线后浏览器会自己重连，重连时还会带上 Last-Event-ID 头，配合服务端的 id 字段就能接着上次断的地方续传。这套是浏览器内建的，不用自己写。
  • 只能传 UTF-8 文本，传不了二进制。要发图片、音视频这类，SSE 不合适。
  • HTTP/1.1 下有个坑：浏览器对同一个域名的并发连接数通常只有 6 个，一条 SSE 就占掉一个。多开几个标签页，连接很容易被占满，后面的请求只能排队。换到 HTTP/2 靠多路复用能缓解这个问题。

SSE 特别顺手的场景：

  • 通知流、消息提醒
  • 日志、任务进度这类实时输出
  • 股票价格推送
  • AI 的流式输出

最后这个现在很常见。AI 应用那种"一个字一个字往外蹦"的效果，就很适合 SSE——客户端问一次，服务端把生成的内容一段段推回来：

text
data: 你好

data: ，这是

data: 一段

data: 流式输出

比起 WebSocket，SSE 更轻，也更贴合"问一次、服务端持续回"这种单向场景。

放在一起对比

协议/技术是否加密通信方向连接特点常见场景
HTTP否客户端请求、服务端响应短连接或复用连接网页、API、资源加载
HTTPS是客户端请求、服务端响应HTTP over TLS登录、支付、安全 API
WS否双向长连接实时聊天、游戏、协作
WSS是双向加密长连接生产环境的实时通信
SSE看跑在 HTTP 还是 HTTPS服务端单向推长连接事件流通知、日志、AI 流式输出

补一句：SSE 没有 sses:// 这种东西，它就是跑在 HTTP 或 HTTPS 上。用 HTTPS 传 SSE，它自然就是加密的。

有了 WebSocket，为什么还要 SSE？

WebSocket 都能双向了，SSE 是不是多余？其实不是，能力强不等于到处都合适。

WebSocket 是一条全双工的管子，两头频繁互发时它最在行。但代价是服务端得维护连接状态，网关、负载均衡、连接数管理、心跳、断线重连，每一样都得认真对付。

SSE 更像一个"服务端输出流"。它就是 HTTP，浏览器还帮你把自动重连做好了，跟现有的 Web 基础设施几乎零摩擦。很多场景其实只需要服务端单向推，这时候 SSE 反而更省心。

还是拿 AI 流式回答说事：

text
用户问一次
服务器把生成结果不停往回送
前端一段段渲染

这里用户并不需要在同一条连接上反复给模型发东西，单向就够了，SSE 正合适。

但换成多人协作文档：

text
A 在输入
B 也在输入
服务器把变更广播给所有人
客户端回确认、解冲突、同步光标位置

这种两头都在不停说话的，就得上 WebSocket。

HTTP/2、HTTP/3 有什么影响？

往底层再看一点，HTTP 自己也一直在升级。

HTTP/1.1 时代，一条 TCP 连接上的请求会互相排队，也就是队头阻塞。HTTP/2 上了多路复用，一条连接能并发跑多个请求。HTTP/3 干脆换到 QUIC（跑在 UDP 上），把连接建立和丢包时的表现又改善了一截。

但不管版本怎么变，HTTP 在应用层上还是请求响应那一套。HTTP/2 当年带过一个 Server Push，本想让服务端主动推资源，结果实际没怎么用起来——Chrome 从 106 版（2022 年）起已经默认把它关掉了，所以别再把它当推送方案来用。

SSE 在 HTTP/1.1 和 HTTP/2 上都能跑。到了 HTTP/2，前面提的那个 6 连接限制会缓解很多。

WebSocket 最早靠 HTTP/1.1 的 Upgrade 握手建连。后来也有了基于 HTTP/2 的方案（RFC 8441），但实际部署里，多数系统还是按老的 WebSocket 模型来理解和落地。

到底怎么选

不用记太多，对着需求问自己几个问题就行。

只是普通接口，客户端问一次、服务端答一次？用 HTTP/HTTPS。沾上登录、用户数据、支付、后台，生产环境就上 HTTPS，没得商量。

要两头都能随时主动发消息？用 WebSocket，线上用 WSS。

只是服务端要一直往下推，客户端发起一次就够？用 SSE，线上跑在 HTTPS 上。

再具体到常见场景：

  • REST、GraphQL 查询、文件上传下载：HTTPS
  • AI 流式输出、日志实时输出、任务进度：SSE
  • 实时通知：SSE 或 WebSocket 都行，看要不要客户端回话
  • 聊天、在线游戏、协作文档：WebSocket
  • 股票行情：WebSocket 或 SSE，看要不要双向
  • 简单的状态查询：HTTP 轮询也够用，别过度设计

协议和模式不是一回事

HTTP、WebSocket 是协议；SSE 严格说更像一套基于 HTTP 的事件流约定，算不上独立协议。

HTTPS 和 WSS 强调的则是"安全传输"，它们不是什么新的通信思路，就是在原协议底下加了 TLS 而已。

理清楚就这么几条：

text
HTTP  -> 请求响应
HTTPS -> 加密的请求响应

WS    -> 双向长连接
WSS   -> 加密的双向长连接

SSE   -> 基于 HTTP 的服务端单向事件流

小结

HTTP 是整个 Web 的地基，解决的是客户端怎么向服务端要资源和数据。HTTPS 在它下面加 TLS，把加密、认证、完整性补齐。

WebSocket 突破了请求响应的限制，让两头能拉一条持久的双向通道；WSS 是它的加密版，也是线上更常见的选择。

SSE 卡在普通 HTTP 和 WebSocket 中间，双向能力不如 WebSocket，但在"服务端一直往下推"这类事情上更简单自然，通知、日志、任务进度、AI 流式输出都很合适。

说到底，选哪个不是看谁更高级，而是看消息怎么流动：

text
问一次答一次     -> HTTP/HTTPS
服务端一直推     -> SSE
两头实时互发     -> WS/WSS

方向想明白了，选型这事基本就不纠结了。

分享
← 返回博客列表
🎁 有邀请福利哦，点击查看
🎁