yamaokaです。
Twitterのみならず、FriendFeedやFacebookなど
よりリアルタイムに近い更新がwebで求められるようになってきています。
従来、更新情報の配信はRSSなどのフィードやAPIを通して行われてきました。
しかしその場合、配信している側のサーバーに
定期的にリクエストを投げないと更新があったかどうかわかりません。
サーバーへのアクセスが多くなった場合、結構な負荷になります。
さらにお行儀の悪いクライアントが存在すると、頻繁なアクセスを繰り返し、
あたかもDoS攻撃のような状況が起こることもありえます。
そこで考えられたオープンなHTTPベースのプロトコルがPubSubHubbubです。
Google ReaderとFriendFeedが対応している他、
国内のサービスではlivedoor Blogとliverdoor Readerがそれぞれ対応しています。
ではPubSubHubbubはどのような仕組みになっているのでしょうか。
実際の仕組みについて、プロジェクトサイトに用意されているスライドが非常にわかりやすいので貼っておきます。
PubSubHubbubのプロトコルを構成するのはPublisher、Subscriber、Hubの3者です。
Publisherはコンテンツを配信するサーバーに、
Subscriberは更新情報を受け取るクライアント（フィードリーダーなど）に相当します。
そして新しく登場したのがHubです。このHubは一体何をしてくれるのでしょうか。
コンテンツ配信の仕組みはこうです。
- コンテンツの更新があった場合、PublisherはHubに更新をPOSTで通知する
- Hubは新しいコンテンツをGETで取得、更新が実際に存在することを確認する
- Hubは取得した更新情報をSubscriberのコールバックURLにPOSTで通知する
Subscriberに更新情報がプッシュの形で届くのがポイントですね。
データのやりとりはAtomのフォーマットで行われます。
この方式のメリットとしては次のようなものがあります。
- Subscriberの利用者がよりリアルタイムに近い更新情報を得られること
- PublisherはHubだけに更新情報を通知すればよく、複数のSubscriberからアクセスが殺到する事態にはならないので負荷が軽減されること
- Subscriberが増加するなどして負荷が上がる場合、Hubを増やせばスケールすることが容易でありPublisherには影響が及ばないこと
さらに、PubSubHubbubではSubscriberがHubに取得したい更新情報を登録する場合、
本当にその登録が正しいか検証する仕組みも導入されています。
具体的にはHubはSubscriberのコールバックURLにGETでアクセス、正しい要求か検証を行います。
これによって、検証されていない大量のリクエスト（DoSのような）を防ぐ仕組みです。
また、Subscriberにとっては自分が選んだ更新情報だけを受け取れるので、
意図しないスパムのような被害を抑えることも可能です。
システムの安全性とスケールの容易性が考慮されており、
利用者はリアルタイム性というメリットを享受できる仕組みとして
PubSubHubbubは優れているのではないでしょうか。
実はこのPubSubHubbubプロトコル、Googleの20%ルールから産まれたプロジェクトだそうです。面白いですね。
webのリアルタイム性が訴求されている現状、
このような仕組みを作る取り組みはますます重要になっていくと思います。
最後に。PubSubHubbubという単語ですが、
Publisherの「Pub」とSubscriberの「Sub」、そしてHubを組み合わせた造語だと思われます。
さらに「hubbub」という喧騒を表す単語を組み合わせて語呂をよくした感じでしょうか。
発音は「パブサブハバブ」でいいのだと思います......多分。