WebSocketってなあに?

ざっくりと

  • クライアント、サーバ間で双方向通信を行うためのプロトコル
    • connectionをはりっぱなしにして、双方向の通信ができる
  • 1つのクライアントが何度もリクエストを投げないので、webサーバの負荷が減る
    • 擬似的にAjaxでやろうとすると、クライアントが何度もリクエストを投げるので、通信やサーバの負荷が上がる
  • HTTPとくらべて軽量のプロトコルなので、通信量が少ない
  • 元々HTML5の一部だったけど、現在は独自のモジュール扱いらしい

ブラウザの対応状況はどんな感じなの?


実は何回かプロトコルが細々と変わってて、色々ややこしい事になってるので一覧表を見てくださいな


node.js ならば、socket.ioっていうライブラリを使えば、その辺の問題をなんとかしてくれる

cometって昔あったよね?

  • あれは、擬似的に双方向通信を可能にしてた
  • リクエストを受けてもすぐに情報を返さないで、本当に情報を返したい時に返す
  • 接続方法は、ストリーミングと、通信リソースの軽減を目指した、ロングポーリングがメジャー
ストリーミング
  • 接続後、データの送信を完了させないで、必要に応じてデータを送信する方法
ロングポーリング
  • 接続後、イベントが発生してデータが来ると接続を遮断して、クライアントはpushが欲しい時に再度接続を行なって待つ方法
    • ストリーミングよりもコネクションを節約できる
  • どちらにせよ無理やり従来のブラウザで双方向通信を可能にしたので、ブラウザ側やサーバ側で色々問題があったらしい
    • HTTPコネクションを維持し続けるので、通信リソースを食う
    • 同時接続数やタイムアウトの時間がブラウザ毎にまちまちなので、その辺を意識したクライアント、サーバ側の実装が大変


その辺の問題点を解決するため、

  • 無理やりHTTPプロトコルを使わないで、軽量な独自プロトコルを作ろうぜ!
  • そんでブラウザでも標準的に使えるようにしようぜ!

っていうのが、websocket

SPDYとはどう違うの?


そもそもの目的が異なる
詳しくは、こっち読んで

websocket = node.jsって印象だけど、サーバ側はnode.jsじゃないとダメなの?


当然ながらプロトコルが実装されたモジュールがあるなら、どんなのつかっても構わない


ざっくりとそんな感じで