WebSocketプロトコルのバージョン変更

家のマシンから自分が作ったWebSocketサービスに接続出来なくなったので、少し調べてみたら、
Chrome14からはWebSocketプロトコルのバージョンがdraft10になっていた為でした。
Chrome13まではdraft76で、draft10とは互換性が無いとの事。

使用しているPHPWebSocketはまだ対応していないようですが、下記に関して対応する必要があります。

  $status = '101 Web Socket Protocol Handshake';
  if (array_key_exists('Sec-WebSocket-Key1', $headers)) {
    // draft-76
    $def_header = array(
    'Sec-WebSocket-Origin' => $origin,
    'Sec-WebSocket-Location' => "ws://{$host}{$path}"
    );
    $digest = $this->securityDigest($headers['Sec-WebSocket-Key1'], $headers['S    ec-WebSocket-Key2'], $key3);
  } else {
    // draft-75
    $def_header = array(
    'WebSocket-Origin' => $origin,
    'WebSocket-Location' => "ws://{$host}{$path}"
    );
    $digest = '';
  }

もう少し調べたいところですが、ちょっと時間がないので、、少し落ち着いてから調べます。

こちらに詳しく書かれていました。

Comet メモ

WebSocketを使用したmashupを作るにあたり、以前から知られているCometについては、
サーバからpushする技術ぐらいにしか理解していなかった為、少し調べてみました。

  • ■ 目的
  • 従来のWebページはクライアントからリクエストがあった時のみ、サーバからレスポンスが返ってくる。
    その際、クライアントからはHTTPコネクションを生成し、サーバからレスポンスが返るとコネクションはクローズする。
    上記の手法でも通常は問題は無いが、リアルタイム性を求められるアプリケーション等の場合は不都合である。
    (例えば、チャットや株価情報など)
    その場合、AJAX等で非同期にサーバへHTTP通信をする手法が考えられるが、
    サーバ/クライアントに負荷が掛かったり、他ユーザからの更新情報をリアルタイムに受け取る事は難しい。
    こうした経緯からCometと呼ばれる概念(Cometは複数の技術の総称)が生まれた。
    なお、Comet, AJAXの名称は共に洗剤から由来している。

  • ■ トランスポート処理手法
    1. ポーリング
    2. サイトあるいはアプリケーションから、更新有無を問い合わせるリクエストを定期的に送信するという非常に単純な仕組み。
      デメリットとして等間隔(例えば、5秒など)でリクエストを送信するが、サーバ側で高負荷になっていた場合も常にリクエストを出し続けてしまう事が起こり得る。この場合、サーバ側に未処理リクエストが溜まり続けてしまう。

    3. ロングポーリング
    4. クライアントからリクエストをサーバに送信し、すぐに返却可能なデータがある場合はすぐにレスポンスを返すが、まだ返却可能なレスポンスデータが存在しない場合は、レスポンスを返さずに未応答リクエストとしてサーバ側で保持する。
      データの用意が出来た段階で、保持していた接続を見つけてレスポンスを返す。
      Meeboで使用されて、有名となった。
      ロングポーリングの発展系として、スマートポーリングと呼ばれる手法がある。
      スマートポーリングはレスポンスデータが返って来なかった場合にリクエスト頻度を下げるポーリング手法である。
      例えば、空レスポンスであったら、次回のリクエスト間隔は1.5倍にするなど。

    5. 永久フレーム
    6. ロングポーリングは永久フレームから生まれた手法である。
      永久フレームとは、非表示のインラインフレーム(iframe)を開き、
      チャンク形式エンコーディングを利用して送信する。
      この方式は非常に大きなドキュメントを段階的にロードする為に考案された。
      但し、IEでは永久フレームを使用した場合、チャンクを受け取る度に「カチッ」という効果音がなってしまう為、
      使用に耐えないものであった。
      そこで登場したのが、GoogleがGoogle Talk考案したhtmlfileというActiveXオブジェクトを用いる手法である。
      この手法により、IE問題はクリアされ永久フレームは有効な手法として広まった。

    7. XHRストリーミング
    8. サーバと通信をする為の最も良い方法はXMLHttpRequestを使用する事である。
      通常、ポーリングやロングポーリングのデータ転送で使用されている。
      XHRストリーミングでは、XHR通信を行った後にreadystateをチェックし続け、
      接続が切れる前に同一コネクションを使用して会話をする。
      現状、最善の手法であるが、いくつかデメリットが存在する。
      通常Webサーバはリクエストを受けるとすぐにレスポンスを返すように最適化されているが、
      ストリーミングでは接続を保持し続ける必要がある為、注意が必要である。
      また、クライアント側においてははXHRストリーミングがパフォーマンス上の問題を引き起こすケースがある。
      ストリーミングのレスポンスがあまりに長く続くと、ブラウザのメモリ消費が過大となり、クラッシュしてしまう。
      解決方法としては、一定数のレスポンス後に一旦レスポンスを終了し、新たにリクエストを生成すれば良い。
      なお、IEではXHRストリーミングを正式サポートしていないので注意が必要である。

  • ■ 今後の動向
  • 前述までのCometを使用したとしても、大量コネクション保持やサポート問題等の為、完全なソリューションではない。
    そこで、HTML5からforkしたWebSocketに期待が集まっている。
    現在策定中のWebSocketはCometのデメリットを補いつつ、リアルタイムアプリケーションを容易に構築出来る可能性を秘めている。

    調査にあたり、続・ハイパフォーマンスWebサイト ―ウェブ高速化のベストプラクティスを参照させてもらいました。


    twitter × Google maps with WebSocket

    twitter API と Google Maps API のmashupサービス twigeo を作りました。
    これだけだとありきたりの為、最近話題に上がるWebSocketを使用し、
    “ほぼ”リアルタイムにServer => Clientへtweetをpushするようにしています。
    誰得なサービスか分からないのですが、、皆さん様々な場所でtweetされているのですね。

    WebSocketを実現する為にPHP WebSocketを使用させてもらいました。
    PHP WebSocketはチャットのような複数クライアント間でメッセージのやり取りを行いやすいように
    設計がされていますが、本サービスではクライアント間のやり取りはなく、
    一方的にサーバ側からpushするのみとなりますので、少し手を入れる必要がありました。
    また、twitter StreamingAPIを使用する際にOAuthが必要ですので、tmhOAuthを使用しています。
    なお、現状WebSocketをサポートしているブラウザは、Chrome, Safariとなります。
    Firefoxは次バージョンからサポートされるようです。

    現在対応出来ていない仕様やバグは以下です。

  • tagエラー
  • 初期画面で自身の位置情報が固定
  • InのTweet量に対して、Outは視認性を良くする為にSleepを入れている関係上、叙々に配信が遅れてしまう
  • いづれも軽微な対応で済みそうですので、暇をみて対応したいと思います。