以下几乎是任何文化背景下的每次长途旅行中都会遇到的一个故事情节。坐在后座上的孩子总是不停地问：“我们到了吗？...我们到了吗？...我们到了吗？” 直到恼怒的家长从前座厉声说到：“不要再问了，到了之后我会告诉 您！" 这样的小插曲往往会引来一阵大笑，但是不好笑的是，与那个迫不及待的孩子采用相同做法的情况在 Web 上不知道有多少。
您可能会使用某种提要阅读器来追踪您最喜欢的出版商发布的新内容，不论是新闻站点、博客还是还是像 IBM® developerWorks 这样的日志。如果是这样，您的阅读器习惯上会每隔 15 分钟轮询一次站点并请求提要 URL，或者查看是否存在新的内容。如果您的提要阅读器和站点充分利用了 HTTF 和 Cache-Control（尤其是后者），则会在提要没有更改的情况下将网络交换降至最少。但是，即使利用的资源最少，叠加起来也会造成超时，尤其在您考虑到其他所有人和您一样对同一个站点感兴趣时。
所有这种没必要的流量是一个真正问题，因此，在几年前，Google 的一些工程师决定开发传统发布/订阅模式的一种新形式。发布/订阅就像是车里的家长，他对孩子说 “您告诉我您喜欢的地标，我就会告诉您我们什么时候到那”，所以孩子没必要反复询问 “我们已经到了吗？”。在这种情况下，您可以订阅您感兴趣的提要，该提要的发布者就会注意到您的改变，无需进行轮询。
发布/订阅已经出现有一段时间了，尤其是在关闭的系统中，但是 Web 的开启使其安全有效地实现变得有点棘手。虽然已经有一些早期的研究成果，例如 RSSCloud（参阅 ），但也该是为 Web 使用新一代的发布/订阅的时候了。结果就出现了 PubSubHubbub 这个古怪的名称，通常将其缩写为 "PuSH"。PuSH 可能是 Google 上的极少数原创作品之一，但它也是从一开始就公开开发的一种规范，许多 Google 以外的贡献者都参与了它的研究。更令人高兴的是，该规范已经和一种开放源码参考实现共同开发。曾经也有过其他的一些实现，但是对于某种规范的开发人员而言，能够致力于某个开放源码参考项目来帮助启动社区，这也是一件很好的事。
在本文中，我将介绍 PuSH 并向您展示如何开始使用开放源码参考实现。
PubSubHubbub 简介 在脑海中将 PuSH 组织为发现、订阅和发布三个阶段很有用。本文将概述 PuSH 的大部分主要部件，尽管并非全部（例如，PuSH 有一个经过深思熟虑的取消订阅的机制，这实际上也是 PuSH 自身的一个阶段）。
发现 当订户对某个主题感兴趣时，发现阶段就开始了。PuSH 中的主题基本上就是一个 URL，通常您也可以将它看作一个提要 URL。每一个 IBM developerWorks 专区都有自己的 RSS 提要，而且每一个提要都可以是一个 PuSH 主题，其中的主 URL 与非 PuSH 感知客户端用于轮询的提要 URL 是相同的。
PuSH 的重要改进之一就是允许实际订户不同于管理其 PuSH 订阅的系统，它们甚至可以位于不同的服务器上。这允许用户将部分协议移交给专业的库，甚至移交给 Web 服务。大多数的 PuSH 描述都将订户描述为单一的实体，但我却认为该协议实际上定义了两个单独的实体，我将其中之一称为订户代理，另一个称为订户。在某些情况下，这两者是相继实现的，但是这种情形不是必然的。 是发现过程的图解。
图 1. PuSH 发现过程 订户代理代表订户请求提要，并在 PuSH hub 的提交内寻找一个或多个特殊链接。以下就是此种链接的一个例子：
1
| <link rel="hub" href="http://pubsubhubbub.appspot.com"/>
|
在这种情况下，提要显示 “我在 上发布到 PuSH hub”。而这个 PuSH hub 恰好这是 Google 的参考 PuSH hub，运行于 Google App Engine 之上。如果您愿意，您可以使用任何您喜欢的 hub，其中包括您使用 Google 的开放源码实现来运行的一个 hub。
如果没有这样的 PuSH hub 链接，订户代理没有执行进一步的操作，订户必须求助于轮询，或者其他一些机制。如果存在这样的链接，那么下一阶段就是订户联系该 hub，开始订阅阶段。
订阅 是订阅过程的图解。代理将 HTTP POST 发送至包含回访信息的 hub，该 hub 是应该接收新内容通知的 URL，订户对此处的主题感兴趣。由于还有一个安全机制，所以恶意软件无法通过假装成订户代理来制造破坏，无法让人们订阅他们不需要的提要。
图 2. PuSH 订阅过程 一旦完成了订阅，hub 就会将回访 URL 添加到其订户代理列表中，以便通知发布人是否对内容进行了任何更改。
发布 是发布过程的图解。当主题更新后，就会使用已更新内容的 URL 将 HTTP POST 发送至其每一个 hub。PuSH 规范将这称为 “新内容通知”。然后每一个 hub 都会发送一个针对主题的新内容的 GET 请求，也称为 “内容提取”。接着该 hub 会在一个称作 “内容分发” 的过程中通过 HTTP POST 将更新的内容发送给每一个订户。
图 3. PuSH 发布过程 PuSH 的能力所有这些看起来像是一个相当精细的操作，但在交换过程中稍微有点复杂，PUSH 提供了大量分散化操作，因此更具可扩展性和灵活性。 只是说明了在 PUSH 网络中，交互在多个 hub、发布者、订户和订户代理之间是多么的灵活。
图 4. 多个订户、订阅代理、hub 和发布者之间的交互 |
