を紹介して、本日のエントリーは締めたいと思います。こちらの書籍では、Web Intents については触れていませんが、Web でのマルチデバイス連携や、今後のWebの進展に対して、日本の進むべき方向について、大変分かりやすくまとめられています。この分野に興味のある方は、是非一読されることをお薦めします。
WebSocket が、12月12日についにRFCになりました（RFC6455)。テキスト転送だけでなく、バイナリー転送もサポートされ、コネクションをキープするための ping/pongなどコントロールフレームも定義されました。rfcになる過程で様々なバージョンと、その実装系が出ていますので、そこのネゴシエーションの仕組みが入っていたり、以前は割と自由に使えそうだった subprotocolが、IANAにレジストレーションが必要になったりと、なかなかしっかりしたプロトコルに仕上がっている印象です。
さて、今年最後となる、今日のポストでは、このWebSocketにより、今後のWebはどうなっていくのかについて、僕が最近感じている妄想を書き連ねてみます。
WebSocketとは、いったい何なのか？
さて、WebSocketとは、いったい何なのでしょうか？この問に対して、一般的には、
- WebでPush通信が可能になる
- Webで双方向通信が可能になる
- Webを高速化できる
結論から先に言うと、「WebSocketはWeb上に、個々のVPNを作る技術である」と僕は思っています（あくまで、僕の私見です）。
ここで、VPNとは、インターネットを介して、個別のプライベートネットワークに接続するための技術の総称です。具体的には、IPパケットのデータ部分に、接続したい相手先のアドレス（IP-VPNで、社内網に接続する場合は、社内のプライベートアドレス）を記述しておき、
- グローバルのIPアドレスで、IPパケットがVPNの入り口（ゲートウェイ）まで届き
- ゲートウェイで変換処理がなされ、データ部分に書かれている宛先のアドレス（プライベートアドレスなど）にデータが届けられる
VPNの観点で、WebSocketを再検証してみる
さて、WebSocketに話を戻すと、WebSocketのプロトコル自体が、上のVPNの仕組みに非常に似ています。IPパケットのデータ部分で、接続するWebSocketサーバのURL（ws://example.netなど）が指定されており、実際の通信は、このサーバーに対して行われます。システム依存ではありますが、IPパケットで指定されているIPアドレスは、あくまでゲートウェイ（具体的には Load barancer, proxy, URL routerなど）を指定するものであり、ブラウザが直接的に接続する、サーバーとは異なります。ユーザーが本当に接続するのは、URLで指定されたWebSocketサーバーになりますので、これはVPNの仕組みと非常に似たものと言えます。
具体的な例をあげましょう。通常のVPNのユースケースとして、VPNで社内網に接続し、リモートデスクトップで自席のPCに接続するというものがありますが、このユースケースを WebSocket で実現するサービスを ERICOMという会社が提供しており、ブラウザからリモートデスクトップ(VMWare View)を利用することが出来ます（デモサイト）。ただ、執筆時点(2011.12.31)ではエラーとなり接続できません
従来のVPNとの違いとして、マルチデバイスへの対応の容易性があげられます。実際、先にあげたデモは、個別のソフトウェアのインストールはもちろん不要ですし、iPadなどのデバイスでも利用することが出来ます。これだけでも、従来のVPNを用いたリモートデスクトップの利用に比べ、格段にアドバンテージがあると言えます。
更に、僕が注目するポイントは、その利用の容易性です。従来のリモートデスクトップ利用の場合、
- 接続用ソフトを起動し、VPNに接続する
- リモートデスクトップのソフトウェアを起動し、サービスにアクセスする
- そのURLにアクセスする
Webをベースプラットフォームとして、異なるネットワークが作られていく
こうなってくると、Webは、単にWebページ（コンテンツ）にアクセスするための仕組みとは言えなくなります。むしろ、Webが基本のプラットフォームとなり、そこの上に個別のポリシーのネットワークが形成される。そして、ユーザーは、それらのネットワーク上を自由に行き来するという世界観で捉えるほうが妥当であると僕には感じられます。
実際、このような流れは、既に存在します。Facebook, Twitter, Google+などのソーシャルサービスが、既にそれを具現化しており、ユーザーは、それぞれのネットワークの中で生活しています。そのネットワークの、それぞれのFriend Listの中で、メッセージがダイレクトに交換され、コミュニケーションなどのサービスを利用している図式は、まさにWeb上のVPNの中で、サービスが提供されていると考えられます。
そして、今既に提供されているこれらのサービス。それは、現状Cometと呼ばれる HTTP のポーリングを駆使した技術の上で成り立っています。それ故に高コストであったり、制御が面倒など自由なサービスを実現するのに様々な制約が課され、従来のVPNのように自由自在なサービスを提供するのが困難なものでした。しかし、WebSocketは、そのような制限を解放します。開発者は従来のVPNのように自由なサービスを実現することが可能になり、ユーザーはそれらを自由に利用出来るようになります。それは、ユーザーから見たネットワークが、IPではなくWebになると捉えることも可能でしょう。IPはそこ（Gateway）に到達するための橋渡し役となり、本当に意味を持つもの(ネットワークの最終到達点)は、URLになるというわけです。
提供されるサービスは、従来からWebで既に提供されているサービスかもしれません。オフィス系のアプリケーションかもしれませんし、ゲームかもしれませんし、テレビ電話かもしれません。しかし、従来提供されていたもののレスポンス性や機能性ががあがったり、他のサービスと連携可能となったりなど柔軟に利用出来るようになることで、とんでもないブレークスルーが生まれることは実証済みです。GMailや、Google Maps、Twitter, Facebookなどが、これまでのWebの歴史の中でそれらを実証してきました。
WebSocketが通信面で、その制限をなくし、HTML5の他のAPIと結びつくことで魅力的なサービスが生まれていくでしょう。「ソーシャルサービスを加速し、より魅力的なものに変えていく、それを底辺から支えるものが WebSocket である」と僕は確信しています。
ネットワーク屋さんの観点で、さらに考察してみる
さて、ネットワーク屋さんの観点で見ると、これまで TCP/IP をベースとし、プロトコルや設計を行って来たこれまでの考え方が、URLに置き換わることに他なりません。現在でも、
「これからのインターネットの進化はコンテンツをベースに考えなければならない」
と言われていますが、WebSocketは、さらにこの考え方を一歩前進させるであろうと僕は考えています。
「これからのインターネットの進化は URL で識別される仮想的なネットワークをベースに考えなければならない」
といったところでしょうか(もっと突っ込んで言うと、識別されるネットワークの単位は Origin になるんだろうなと想定しています）。
URLは、従来のインターネットで言うと IPアドレスに相当しますので、そのメタファーで行くと、TCPのポート番号のように、WebSocketの上で動く個別のプロトコルを識別するものと、そのプロトコルの実体が必要になってきます。
それに該当するのが、WebSocketの subprotocol になるでしょう。WebSocketが RFC となった今、次に来るのは、その上で動く subprotocol になるのは必然なんじゃないかなと。それにより、WebSocket上でやりとりされるデータの相互接続性が得られ、Webは更に進化していくでしょう。(subprotocolがRFCの過程で、IANAへのregistryが必要になった点も、大きくそれを後押しします）
また、Webで提供されるサービスが大きく変わり、テレビ電話のようなリアルタイムサービスが提供されるようになると、それを下から支えるIP網やその下のデータリンクレイヤには、これまで以上に品質が求められるようになるでしょう。遅延が大きく、ロスが大きく、帯域の狭い網や簡単にセキュリティの攻撃を受けるような網では、これからのWebで満足のいくサービスを提供することは出来ません。網は単なる土管では決してありません。
そして、インターネットとのメタファーで、もう一つ重要になるのはルーティングプロトコルです。SNSの世界で、ルーティングテーブルは、ソーシャルグラフがそれにあたり、Internal なルーティングプロトコル（RIPやOSPFに相当）は、ユーザーが「いいね！」を押したときや、「フォロー」したときのシステムでのDBの変更に相当します。
そう考えてくると、「BGPのような Externalなルーティングプロトコルはどうなるんだろう？」ということが頭をよぎります。ソーシャルグラフを、個々のプロバイダがリアルタイムにやりとりできるようになると、例えば FacebookのVideo callingと、Google+ のHangouts間でダイレクトにテレビ電話ができるようになります。僕は、ソーシャルグラフの事情にあまり詳しくありませんので、これぐらいで留めておきますが、想像するだけでワクワクしてきます。
最近のDevice系の話も考えると、ソーシャルグラフに、テレビや車などの各種機器・デバイスが含まれるようになるかもしれません。そんな人とモノがWebの上で結びつく、すなわち SNS と Web of things が融合し、それが、ある規定のもとに相互接続されていくようになるんじゃないかなと。
VPNという言葉は不適切?
さて、ここまで「VPN」という言葉を連発してきました。ここで、VPNという言葉には、他と繋がっていない独立したネットワークというニュアンスが強いように思われます（社内網に繋ぐといったユースケースは、その典型）。しかし、Webはオープンなもので、相互接続されているからこそ今のWebが形成されてきましたし、今後の進化もそれが大前提となるでしょう。そう考えると VPN と言う言葉は相応しくはないだろうなと思います。
インターネットの上に、異なるWebというプラットフォームが作られる。個々のポリシーに基づくネットワーク（インターネットで言うとASみたいなもの）が作られ、それらが相互接続することで、Webという巨大なネットワーク 〜 One Web 〜 が形成されていく・・・という考え方が適切で、そうなるとVPNという言葉は不適切なように思えます。今の技術とのメタファーでVPNというのは構わないでしょうが、実のところそれは違うでしょうね。
