RSS是一种基于XML的联合供稿格式，用于站点把文章标题、链接和摘要打包成固定文档，方便阅读器统一抓取。WebSub则是一套建立在HTTP之上的发布订阅协议，它并不替代RSS文档本身，而是为RSS提供了一种实时送达机制。简单来说，RSS负责描述内容，WebSub负责通知变化。
一、RSS与WebSub的基础关系
从协议层级看，RSS是数据格式，WebSub是传输通知协议，两者是互补而非竞争关系。一个典型的RSS源在头部通过<atom:link rel="hub">声明自己所支持的Hub地址，阅读器解析后发现该字段，便知道可以借助WebSub获得实时更新，而不必频繁请求RSS文件。
这种关系类似于报纸和送报员：RSS是印好的报纸内容，WebSub是骑单车送报的人。没有送报员，订户只能自己跑去报亭看有没有新刊；有了WebSub，报亭一印好就直接推到家门口。因此WebSub常被称为RSS的实时化扩展，很多现代聚合器同时消费RSS文档与WebSub推送。
1.1 传统RSS的工作方式
在纯RSS模式下，客户端按照设定间隔（如30分钟）向源地址发起GET请求，比对lastBuildDate或文章GUID判断是否有新内容。这种方式实现简单，但实时性受轮询频率限制。若缩短间隔，源站带宽和服务器压力骤增；若拉长间隔，用户看到新内容就慢。
此外，大量订阅器同时轮询会形成洪峰流量，而绝大多数请求返回的都是未更新空响应。这不仅浪费资源，也让小型博客难以承受高频抓取。WebSub正是为消除这种无效轮询而设计。
1.2 WebSub在RSS生态中的位置
WebSub引入三个角色：发布者（RSS源站）、Hub（中转推送服务器）、订阅者（阅读器）。发布者对外声明Hub，订阅者向Hub发起订阅请求并附上回调URL。当发布者更新RSS时，主动通知Hub，Hub再向所有订阅者回调新内容或告知摘要，从而完成实时分发。
由于RSS文档结构不变，老式阅读器依然可用，只是新阅读器多了一条更快的通道。这种向后兼容的设计是WebSub能迅速被接纳的重要原因。
二、WebSub如何改进RSS的实时性
WebSub把拉模型改成推模型，核心改进在于事件驱动而非时间驱动。下面从订阅建立、内容发布、推送过程三个环节说明它如何把延迟从分钟级降到秒级。
2.1 订阅发现与注册
订阅者拿到RSS地址后，先抓取文档寻找rel="hub"链接。若找到，便向Hub发送表单形式的订阅请求，包含回调地址和验证令牌。Hub会向回调地址发起一次GET验证，确认订阅者确实掌控该URL，然后记录映射关系。
以下为订阅请求的简化代码示例（语言：python）：
import requests
hub_url = "https://hub.ipipp.com/"
callback = "https://reader.ipipp.com/callback"
topic = "https://blog.ipipp.com/rss.xml"
data = {
"hub.mode": "subscribe",
"hub.topic": topic,
"hub.callback": callback,
"hub.verify": "sync",
"hub.verify_token": "abc123"
}
resp = requests.post(hub_url, data=data)
print(resp.status_code)
这段代码向Hub声明：当topic对应的RSS更新时，请推送到callback。验证通过后，订阅关系生效，后续无需再轮询topic。
2.2 发布者触发推送
当博主发布新文章，CMS在生成新RSS后，只需向Hub发一个轻量通知，告知主题已变更。Hub收到后，立即查询订阅列表，并行向各回调地址发送POST请求，携带完整内容或更新摘要。
发布者通知Hub的代码如下（语言：php）：
<?php
$hub = "https://hub.ipipp.com/";
$topic = "https://blog.ipipp.com/rss.xml";
$ch = curl_init($hub);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query(array(
"hub.mode" => "publish",
"hub.url" => $topic
)));
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$result = curl_exec($ch);
curl_close($ch);
echo $result;
?>
注意这里发布者并不需要知道有多少订阅者，也不直接联系阅读器，所有分发压力由Hub承担。这让源站代码保持极简，同时把实时能力外包给专业推送网络。
2.3 订阅者接收与处理
订阅者的回调接口收到Hub的POST后，解析Body中的RSS或Atom内容，提取新条目写入本地数据库，并立即在界面提醒用户。由于推送发生于发布后数秒内，用户感知延迟极低。
一个简易回调处理片段（语言：nodejs）：
const express = require('express');
const app = express();
app.use(express.text({type: '*/*'}));
app.post('/callback', (req, res) => {
const content = req.body;
// 解析content中的item节点，存入存储
console.log('收到推送长度:', content.length);
res.sendStatus(200);
});
app.get('/callback', (req, res) => {
// Hub验证订阅时的挑战返回
if (req.query['hub.mode'] === 'subscribe') {
res.send(req.query['hub.challenge']);
} else {
res.sendStatus(404);
}
});
app.listen(3000);
上述代码同时处理了验证挑战与内容接收。相比定时任务不断拉取RSS，这种事件函数只在有更新时执行，CPU与带宽占用都更小。
三、实时性改进带来的收益与注意点
WebSub将RSS端到端延迟从常见的十分钟级压缩到秒级，同时把源站请求量降低九成以上。对于新闻、监控告警、社区动态等时效敏感场景，这种改进是决定性的。
但也要注意，Hub的可靠性直接影响送达率。若使用第三方公共Hub，需评估其稳定性；自建Hub则要保证高可用与防滥用。此外，WebSub推送内容可能被中间人篡改，生产环境应配合签名校验或HTTPS双向认证。
| 对比维度 | 传统RSS轮询 | RSS加WebSub |
|---|---|---|
| 更新延迟 | 取决于轮询间隔，通常分钟级 | 发布后秒级到达 |
| 源站负载 | 随订阅者增多线性上升 | 仅发一次通知给Hub |
| 实现复杂度 | 客户端简单，服务端被动 | 需Hub与订阅验证机制 |
| 适用场景 | 低时效聚合 | 实时信息流 |
综合来看，WebSub不是颠覆RSS，而是弥补其最大短板。理解两者关系，有助于在构建内容分发系统时既保留RSS的开放兼容，又获得现代推送的即时体验。
RSSWebSubpubsubhubbub修改时间：2026-08-04 09:21:18