• Feeds

  • PubSubHubbub的价值

    HTTP是大部分互联网应用接口的首选协议,但是由于HTTP协议短连接且是单向请求(request/response)的特性,决定了调用方要获得实时结果,需要不断的轮询(Polling)服务接口。从而造成大量无意义的请求及服务器相应的开销。针对此现状,许多方案应运而生。比如基于XMPP pubsub的方案、基于HTTP的web-hook的方案、适合即时通讯的comet方案等。但是由于HTTP的简洁及标准的力量,上述方案都没有得到大规模的流行HTTP Polling的现状暂时无人能够改变。

    PubSubHubbub是Google推出的一个基于Web-hook方式的解决方案,它包括PubSubHubbub协议及一个开源的参考实现(Reference Implementation)

    原理

    原理及数据流图在官网的Slide上已经有详细描述,这里以静态图补充。

    pubsubhubbub

    价值

    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是否在业界大范围的改变现状,我们拭目以待。

    如想及时阅读Tim Yang的文章,可通过页面右上方扫码订阅最新更新。

    « | »

    9 Comments  »

    1. Alex

      更精确一点,貌似HTTP是有连接、无状态的,而不是无连接的。而且,这个连接可以是持续而稳定的,因为它是TCP。“HTTP的无状态性”应该更加精确一些。

    2. Tim

      @Alex 改成“短连接单向请求的特性”了,本文要强调的是无长连接,相对与XMPP, Telnet, IRC等协议相比,请求方一问一答调用结束,无法由服务器主动推送数据给客户端。HTTP状态可以由cookie, url参数等保持,并不是本文重点。

    3. 当feed的数量达到一定的数量时,估计Hub的压力也会很大。而且如果publisher不能主ping Hub的话,Hub是不是要主动polling,那样Hub的压力就更大了。

    4. Tim

      @伤感熊 hub是分布式的,可以布任意多台。如果publisher实现PubSubHubbub的话,hub的负荷非常小。只有老的publisher类型的hub的压力才会大,不过比起当前的rss polling的方式,最差的情况就是开销没减少。

    5. ushuz

      GR却死了……

    6. Alessia

      Thanks for this info. I built my site Play Tailor Swift 2048 based on this graphic.

    Leave a Comment