HTTP是大部分互联网应用接口的首选协议，但是由于HTTP协议短连接且是单向请求(request/response)的特性，决定了调用方要获得实时结果，需要不断的轮询(Polling)服务接口。从而造成大量无意义的请求及服务器相应的开销。针对此现状，许多方案应运而生。比如基于XMPP pubsub的方案、基于HTTP的web-hook的方案、适合即时通讯的comet方案等。但是由于HTTP的简洁及标准的力量，上述方案都没有得到大规模的流行HTTP Polling的现状暂时无人能够改变。
PubSubHubbub是Google推出的一个基于Web-hook方式的解决方案，它包括PubSubHubbub协议及一个开源的参考实现(Reference Implementation)
原理
原理及数据流图在官网的Slide上已经有详细描述，这里以静态图补充。
价值
Publisher发布方
许多Blog服务提供者来说，RSS对它们来说是一个鸡肋，对运营及广告等业务没什么帮助，但是却流量很大。因此他们经常非常矛盾的维护着这个接口。如果PubSubHubbub能够在业界大范围的适用，至少从访问压力层面解除了BSP对提供RSS接口之忧。
特例 Realtime RSS(Twitter, 微博服务等)
Twitter/微博等realtime RSS可以从此方案受益，按照常规的方案，订阅方为了获取realtime的结果，几乎需要以每分钟1次的频率来访问RSS API, 如果订阅方能够以PubSubHubbub的方式来访问RSS，那么RSS API的请求量几乎可以降为0
Subscriber订阅方
Subscriber比如RSS阅读器，搜索引擎等类似业务。Google Reader看似PubSubHubbub最大的赢家。
另外在有hub的前提下，即使Publisher不支持PubSubHubbub, subscriber可以通过hub直接取到feed内容，就是说类似阅读器这样的应用现在就可以完全切换到PubSubHubbub体系上。
不适合的场景
Twitter client, 由于client处于防火墙后，通常也没有固定的可直接访问的HTTP Endpoint, 所以没法适用PubSubHubbub
最后，PubSubHubbub是否在业界大范围的改变现状，我们拭目以待。
更精确一点，貌似HTTP是有连接、无状态的，而不是无连接的。而且，这个连接可以是持续而稳定的，因为它是TCP。“HTTP的无状态性”应该更加精确一些。
@Alex 改成“短连接单向请求的特性”了，本文要强调的是无长连接，相对与XMPP, Telnet, IRC等协议相比，请求方一问一答调用结束，无法由服务器主动推送数据给客户端。HTTP状态可以由cookie, url参数等保持，并不是本文重点。
当feed的数量达到一定的数量时，估计Hub的压力也会很大。而且如果publisher不能主ping Hub的话，Hub是不是要主动polling，那样Hub的压力就更大了。
@伤感熊 hub是分布式的，可以布任意多台。如果publisher实现PubSubHubbub的话，hub的负荷非常小。只有老的publisher类型的hub的压力才会大，不过比起当前的rss polling的方式，最差的情况就是开销没减少。
GR却死了……
Thanks for this info. I built my site Play Tailor Swift 2048 based on this graphic.
Play Taylor Swift 2048