プロトコル – HTML5Experts.jp

WebSocket、WebRTC、ホームネットワーク、W3C標準化etc.通信エンジニアの習性は「何でもつなぐ」── 小松健作さん

小松健作 — Mon, 19 Aug 2013 22:00:38 +0000

エキスパートインタビュー第二弾は、小松健作さん。NTTコミュニケーションズでHTML5、特にWebSocketやWebRTCなどの通信系の研究開発、W3Cの標準化活動に携わっています。通信技術のエキスパートである小松さんに、これまでのキャリアと最近の活動を聞きました。

Webのオープンに自由につながる世界観が大好き

──最近、WebSocketやWebRTCなどのWeb通信系に加えて、ホームネットワーク系のDLNA（Digital Living Network Alliance）に関する研究開発もされているそうですね。

　エキスパートNO.2　小松健作さん

通信系のエンジニアって、何でもかんでもつなぐのが大好きなんです。通信系のAPIってことで、WebSocketをやってきたけど、それがホームネットワークにも広がってきたってかんじ。これまでのWebは自分の端末をクラウドのWebサーバと繋ぐパターンがメインで、ホームネットワークの端末同士を繋ぐ用途には殆ど使われてなかったんです。このような用途には、主にApple TVやビエラリンクに代表されるような、各ベンダーに特化した連携サービスが使われています。

それが最近のWebではブラウザからテレビを操作するというような、ベンダーにかかわらず端末同士をオープンに繋ぐことができるようになってきました。オープンで自由につながるっていうのがすごく大好き。HTML5の中でも、Canvasなどの描画系技術も基本知識としては押さえているつもりだけど、どっぷりつかるのはやっぱり通信系ですね。

──なるほど。通信エンジニアの習性というか、好みを聞いたのは初めて。何でもつなぐのが大好きなんですね。僕的には、ホームネットワークとWebSocketって全然違う技術。なんで小松さんそこいったのかなと思ってたけど、「つなぐ」っていう共通点があった。

なんでHTTPからWebSocketに飛び込んだかっていうと、HTTPって結構制約が多いじゃないですか。あくまでも文章をダウンロードするための用途っていうか。つなぐという意味では自由がない。WebSocketはその制約がなくなって、クラウドと自分のデバイスを自由につなげられる世界が作られる。そうなるとすごく楽しいなと。ホームネットワークについてもベンダーに特化した仕様ではなく、Webとオープンに自由につながる世界観ができれば自然に面白いことができるんじゃないかなって思ってます。

磁気センサーからデータマイニングまで。幅広いキャリア

──小松さんって、キャリア的には通信エンジニアになるんですか？

白石編集長

う～ん…自分の専門職が何なのか語るのは難しいなあ。大学の時は磁気センサーのデバイスの研究をしていました。会社に入ってからは映像配信システムやCDN（コンテンツデリバリネットワーク）など、どちらかというとインフラよりのネットワークエンジニアを10年くらいやってきました。

でも新しいことがやりたくて、データマイニングの研究を始めました。テキスト解析など今で言うビッグデータに走ってましたね。そんな中、HTML5に出会いWebSocketで一番最初に作ったのがwakachiのデモ。当時社内の要望で、テキスト解析システムをHTTPインタフェースで作って欲しいと頼まれたんだけど、たった一つの文章でも下手をすると30秒ぐらいかかっちゃったり、これだと一億文書解析するのに100年かかっちゃう。それがWebSocketで処理すると、1時間か2時間くらいで分析できてしまう。WebSocketを使うと、簡単に業務課題を解決できると思って飛び込んだのが3～4年前です。

──小松さんはいろんなことをされてますよね。初めてお会いしたときは、Webサービス系をやってなかったでしたっけ？

Webサービス系もやってましたね。NTTの中でいろんな会社を渡り歩いていますが、新サービスを立ち上げる担当を任されることが多かったんです。NTT東にいた頃は、フレッツとか、ひかり電話とか…。Webに関しては、やれって言われたわけじゃなくて、すごいと思って個人的にやってたら仕事になったかんじですが（笑）。今はHTML5に関する事業を社内で立ち上げる役目です。通信系のWebSocketやWebRTC、ホームネットワークとか…ざっと挙げただけでも結構あります。

jQueryのように誰でも簡単に使いこなせる仕組み作り

──ホームネットワークでいろんなデバイスが共通のプロコトルでつながる話を聞きたいです。将来的にはあらゆる家電にWebサーバーが搭載されると、それを連携させる仕組みや標準化も必要になりますね。

WebSocketやWebRTCをうまく活用して、リアルタイムコミュニケーションなどの双方向性サービスがもっと広がる形を作っていきたいと考えています。ただ、WebSocketやWebRTCを使うには新たにサーバーを立てなくてはいけないし、ネットワークの知識も必要だし、面倒なことが多いのも事実。そこを通信事業者としてサポートして、もっと気軽に使える環境を築いていきたい。例えばjQueryのように、誰でも簡単に使いこなせるようなもの。今のWebはjQueryが登場したからこそインタラクティブなものに発展しました。そういうチャレンジングな世界観を創りたいですね。

──その小松さんのビジョンには、すごく共感します。言葉にしちゃうとSaaSとかPaaS、BaaSになっちゃうのかもしれないけど、それとは違う。アプリを簡単に作れるようにとか、双方向に通信する次のWebを加速させるといったことのために取り組むという姿勢に感銘を受けました。WebRTCやWebsocketが当たり前の世界でないなら、あって当たり前の世界に変えていけば、Webがさらに進化する。時代の到来を早めようとしている気がします。

僕、性格的にせっかちなんです。そういう世界を先に見たくて（笑）。

標準化の活動。日本のデベロッパーにも参加してほしい

──小松さんが主導で進められたW3Cの活動についても聞きたいです。日本人でWebの標準化について語れる人はまだあまりいません。小松さんはどんなマインドで臨まれているのでしょうか。

世界から見ても日本のデベロッパーはとても高いポテンシャルを持っているのですが、これまでW3Cみたいな国際標準化団体を遠い存在に感じていたと思います。きっかけ、やり方のヒントがわかればそこに踏み出していけるはず。そう考えて、もっと世界に飛び立つための仕組みやベースを作りたかったんです。

──日本のWeb開発者とW3Cメンバーとの交流イベント「W3C Developer Meetup」をやってみてどうでしたか？

日本の開発者は、これまでW3Cと接触する機会が殆どなかったわけで、それだけでも意義が大きかったと思っています。みんな楽しんでくれていたことに一番の達成感を感じました。今後はこのきっかけを継続する仕組みを作らないといけない。コードは世界共通言語なわけですし、英語が得意でなくても標準化に貢献できるような形も作っていきたいですね。

いやらしいことを考えずにつぶらな眼（まなこ）で貢献をしていけば、何か成果が生まれてくるし、日本全体がよくなってくる。今までの自分自身の活動もそうですね。やらないより、やったほうが絶対よかった。「それって儲かるんですか？」ってよく聞かれるんだけど、金銭などのリターンを常に前提においてやっていたら今の自分はなかったと思ってます。

エキスパートメンバーで有機的なコラボレーションを

──最後に、今後の活動や「HTML5 Experts.jp」に対する抱負をぜひ！

エキスパートの人たちと意見交換や何かを作り上げたい。有機的なコラボレーションができたらいいですね。執筆陣やレビュワー以上のつながりを作り出し、エキスパート同士のコラボでどんどん新たなWebの世界を引き拓いていきたいです！

[エキスパート No.2 小松健作] 1972年生まれ。NTTコミュニケーションズにてネットワークとWebとの関わりや、インタラクティブマルチデバイスWebサービスに関する研究開発・標準化活動に従事。Google API Expert（HTML5）、Microsoft Most Valuable Professional（Internet Explorer）
こてさきAjax – livedoor Blog（ブログ）

変わるWebプロトコルの常識（SPDY, HTTP2.0編）

小松健作 — Tue, 09 Jul 2013 11:54:25 +0000

最新の各種通信プロトコルにより、Webの可能性は大きく広ろうとしています。今回は、それらの中から Web をより高速かつスケーラブルなものに変えていくプロトコル、SPDYとHTTP2.0 について解説します。

HTML5の登場により、Webで使われるプロトコルは、 HTTP1.1 から大きく変わろうとしています。具体的には、SPDY, HTTP2.0, WebSocket, WebRTC といったプロトコルがそれにあたります。これらは、現状のHTTPが抱える各種問題点を解決するものです。

しかしながら、これらのプロトコルについて、

いったい何であるのか
今のWebの何を解決してくれるのか

は、あまり知られていません。そこで数回に分けて、これらのプロトコルがいったい何であるのか、今のWebの何を解決してくれるのかを解説したいと思います。_[1]

今回は、SPDY, HTTP2.0について取り上げます。

そもそも HTTP とは？

まず、従来のWebプロトコル HTTP についておさえておきましょう。HTTPは Hypertext Transfer Protocol の頭文字をとったもの。その名の通り HTML (Hypertext Markup Language) 文書をサーバーからブラウザにダウンロードするために開発されました。ちなみに現在もっとも使われているバージョンは1.1です。

このHTTPの特徴は、動作が非常に単純であることにつきます。その動作パターンは以下のようになります。

ブラウザから、サーバーに HTML 文書を要求(request)する
サーバーは、ブラウザに要求された HTML文書を返す（response）

このため、HTTPは request & response型のプロトコルと呼ばれます。

Webの進化に伴い、スピードの問題が!!

Webが登場してしばらくの間は、このHTTPで全く問題がありませんでした。Webの初期は文書を表示することしかできなかったため、一つのHTML文書をダウンロードすれば良かったからです。

しかしWebの進化に伴い、特にスピード面で問題が出るようになりました。多くのリソースをダウンロードすることによる、パフォーマンス上のボトルネックが生じるようになったのです。

今皆さんが利用しているWebページは、多くのリソース（JavaScriptやスタイルシート, 画像など）から構成されています。例えば、HTML5 Experts.jpのトップページでは 80個のリソース から構成されています。これらのリソースを、HTTPを用いて 素直に 取得しようとすると、以下の様なパターンとなります。

ブラウザから、サーバーに HTML 文書を要求する
HTML 文書を取得したら、次のリソース（スタイルシート）を要求する …
最後の画像リソースをダウンロードしたら、それを表示してWebページが完成する

つまり、request & responseの繰り返しが 80 回起きるわけです。もし、仮にサーバーからリソースをダウンロードするのに 1 回あたり、0.2秒かかったとすると 16 秒かかる計算になります。こんなに時間がかかっては、正直サービスになりません。

このため、現在Webで使われている HTTP1.1 では、同時に送信するリクエストの数を増やすことで、ダウンロード時間の短縮を図っています_[2]。運送業者にたとえるなら、80個の荷物を1台のトラックで1個づつピストン輸送するよりも、同時に複数台のトラックでピストン輸送したほうが早く終わる…という感じです。

この解決策により、スピードの問題は著しく改善しました。現在のWebでは様々なテクニックを駆使し、10本以上の同時リクエストを送信することで、スピードの高速化を図っています。

同時リクエストの乱用による新たな問題

しかし、このようなHTTPの同時リクエストの乱用は、新たな問題を生むことになりました。サーバーやネットワーク機器の負荷を上昇することとなってしまったのです。

先の運送業者の例で、伝え忘れていたことがありました。このトラックは、一本の車線を占有しないと走れないという困った特徴があります。これは、同時に10台でピストン輸送しようとすると、10本の車線が必要となることを意味しています。

これは、あまりにも大変で、無駄が多いことは直感的にわかると思います。トラックに積荷を載せる倉庫は、多くの車線をカバーする大きなものが必要になりますし、途中の道路についても同様です。

ここで、倉庫をサーバーとし、道路をネットワーク、車線をTCPコネクションとしたのが今のWebです。HTTPはTCPコネクションという車線の上を走るトラックに相当しますので、同時に送信するリクエスト数が増えれば増えるほど、TCPコネクション数が上昇し、サーバーやネットワークに過剰な負荷を引き起こします_[3]。

SPDY, HTTP2.0の登場

このようなTCPコネクション数の乱用による問題を解決するために登場したのが SPDY, HTTP2.0です。これらの最新Webプロトコルを用いることで、スピードを高めつつ、サーバーやネットワークの負荷を下げることが可能となりました。

そのアイディアは非常に単純・明快です。トラックでたとえれば、一台あたり一本の車線を専有してしまうのが諸悪の根源です。もし筆者が運送業者の社長であれば、運転手を説得し、全てのトラックを一本の車線で走らせることでしょう。冒頭の図面のように。SPDYやHTTP2.0についても、全く同様のアイディアです。複数のHTTPを一本のTCPコネクションで運べるようにしたのです_[4]。

最初に登場したのは、SPDYです。Googleが提唱した独自プロトコルで、ドラフト仕様が最初に公開されたのは 2009 年のことです。HTTPの多重化以外にも、HTTPヘッダーの圧縮やサーバープッシュ、フロー制御など高速化のためのさまざまな機能が盛り込まれています。

既に、Googleの各種サービスや Twitter, Facebookなどの大規模サイトで実際に利用されており、運用実績があるのも大きな魅力です。ブラウザとしてはすでにChromeやFirefoxが対応しており、Internet Explorerの次期バージョン IE11 でもサポートされることから、今後更に普及することが予想されます。

HTTP2.0の検討は、SPDYをきっかけとして 2012年に始まりました。SPDYのエッセンスを新しい HTTP のバージョンに盛り込み、HTTP1.1の様々な問題を解決した標準仕様を策定しようとする取り組みです。最初のドラフトは SPDY そのものでしたが、徐々にその形を変えてきています。今年度内には、テスト実装も予定されており、これをベースとして検討がより具体化されると予想されます。

SPDY と HTTP2.0の関係・これから

SPDYとHTTP2.0の関係ですが、SPDY/4では、HTTP2.0仕様の一部を取り込み始めています。短絡的に考えるのは早計ですが、SPDYとHTTP2.0は互いに影響を与えながら、あるべき次世代 HTTP の結論を導くことでしょう。

ただし、SPDYがカバーしようとする領域は HTTP だけではありません。Webに関わるその他のプロトコル〜DNSやWebSocketなど〜もSPDYの中に取り込んでいこうとするアイディアもあります。こういった様々な興味深いトピックも、HTML5 Experts.jpでは今後紹介していければと思っています。

[1] このシリーズは、最新Webプロトコルの入門編的な記事です。その後、より詳しいシリーズを執筆する予定です。

[2] 正確にはHTTP1.1というより、現在のブラウザのHTTP実装がそうなっているというほうが正しいのですが、話が複雑になるので割愛します。

[3] 例えばIPv4枯渇に伴い、特にモバイルキャリアのネットワークに CGN（Carrier Grade NAT）の導入が進んでいますが、このような振る舞いがCGNに大きなインパクトを与えています。

[4] 多重化のアイディアは、HTTP1.1でもpipeline仕様として存在しているのですが、相互接続性の問題から実際には殆ど使われていません。