ネットワーク – HTML5Experts.jp

通信キャリアプロフェッショナルが語るHTML5への期待「HTML5 Conference 2013」

馬場美由紀 — Thu, 09 Jan 2014 01:00:13 +0000

連載： HTML5 Conference 2013レポート (21)

「HTML5 Conference 2013」ルーム5Cの最終セッションは「通信キャリアプロフェッショナルが語るHTML5への期待」と題したパネルディスカッションが行われた。パネラーとして登壇したのはNTTコミュニケーションズの宮川晋氏（専門：バックボーンNW）、ソフトバンクモバイルの湧川隆次氏（専門：アクセスNW）、KDDIの藤井彰人氏（専門：クラウド基盤）の3人。コーディネータをNTTコミュニケーションズの小松健作氏が務めた。

これからのアプリ開発はネットワークの知識は欠かせない

セッション開始にあたり、まず小松氏が同セッションの目的を紹介した。
「HTML5の登場により、Webが進化しているのは承知のとおり。通信など他のレイヤーに影響を及ぼしている。つまりWebアプリ開発者も、キャリア通信のところで何が起きているか知らないとやっていけない状況になっている。またこれは逆もしかり。そこでまずキャリアプロフェッショナルに、今、通信のところでは何が起きているか語ってほしい」。こう口火を切り、宮川氏のプレゼンテーションが始まった。

アプリ屋さんはTCPより下を、IP屋さんはTCPより上を

「私はIP屋なので、Webの世界は知らない」。開口一番そう話し、プロフィールの紹介を始めた宮川氏。同氏は会社での仕事のほか、RFC3769 Requirements IPv6　Prefix DelegationなどIPv6の規格の標準化・実用化に長らく携わっているという。
「今日はIPネットワークに携わっている側から、HMTLをやっている皆さんに知っていただきたいこと、あるいは教えていただきたいことについて話をしたい」

こう前置きし、最初に宮川氏が紹介したのはIETFの「HourGlass（砂時計モデル）」図。同図では砂時計の真ん中部分がIPとなっており、IP屋さんはTCPより上については良くわからず、反対にアプリ屋さん（HTMLを書く人）はTCPより下については気にしなくてよかった。しかし「HTML5関連の技術であるSPDYやWebSocket、WebRTCなどが登場してからはそうも言っていられなくなった」という。

CGN（Carrier Grade NAT）という技術がある。これは1つのグローバルアドレスを複数のユーザーで共用するという、IPv4延命のための技術だ。重要なのはCGNでは1台のマシンで使用できるTCPの数には限界があるということ。最近のWebアプリはAjaxを用いて多数のTCPを張り、表示の高速化を図っている。つまりたくさんのTCPを同時使用しているということ。このような状況下でCGNが導入されればCGNに多大な負荷と影響を及ぼすことになると予想できるという。もちろんIPv6化も検討が進められているが、「これも問題がないわけではない」と宮川氏は次の点を指摘する。

SPDYやWebSocketなどとインフラとの親和性が本当にあるのか。
ファイアウォールやロードバランサーとかがうまく機能するのか
全部HTTPSになるとしたら、コンテンツの中身をプロバイダは見えなくなる。ISPはもう何もできなくなるがいいのか

また今のネットワークはクライアント/サーバモデルに忠実なので、North-Southが太くてEast-Westはあまり考えていないつくりになっている。しかしこれからWebRTCが流行ったりすると、EW方向も重要になると思われる。

「アプリ屋さんと意見交換をしたい。現在、V6協議会研究で『IPv4枯渇に係るインターネット新技術導入に向けた検討WG』を運営している。一緒にやってくれる人を大募集している」

IPv6は真のエンドツーエンド実現。だからIPの知識が必要

続いて湧川氏が登壇。
「キャリアという紹介があったが、実はソフトバンクモバイルに入ったのは今年4月。IETFでモバイルの標準化にずっと携わってきた。今日はHTML5のWebsocketやSPDYが、どうIPに影響するかというところから話をさせていただこうと思っている」。こう切り出し、湧川氏のプレゼンが始まった。

今まではサーバーとマシンとのやり取りはHTTP1.1。複数のTCPでマルチにセッションを張り、各TCPが1つのやり取りをしてデータを落としてきた。これを効率化するために登場したのが、WebSocketである。これにより、一つのTCPパイプの中で複数のストリームを流せるようになった。そしてHTTP2.0では暗号化して仮想的なセッションでやり取りするという新しい動きが出てきている。

「しかし疑問もある」と湧川氏。それはTCPのLong-Livedセッションはモバイルには向かないのではということ。先述したように今までは一つのページに複数のTCPを張り、通信をしていたので非常に短いセッションですんだ。一方今はWebSocketのように1つのTCPに複数のストリームを流していくので、長い時間TCPのセッションを張ることになる。そうなるとモバイルはどうしても「パケ詰まりにより、無線の混雑が起きてしまう」と指摘する。またモバイルはハンドオーバーもある。「モバイルの場合、TCPのセッションを減らそうといっても、複数のセッションを張ることになると思う」と湧川氏。

一般的にキャリア側ではユーザーが便利に使えるよう、さまざまな施策を講じてきた。以下がそれだ。

キャッシュ
CDN
オプティマイザー
フィルタリング
ファイアウォール
DPI（Deep Packet Inspection）
QoS

今後、暗合化してエンドツーエンドで通信をするようになると、「キャリアができることはなくなる」と湧川氏は言う。つまりアプリケーションを書く人が用途と使える機能をきちんと理解して使うことが重要になるという。そしてIPv6が普及すると、真のエンドツーエンドが実現する。「すばらしい世界だが、大丈夫かどうか、注意が必要。ぜひアプリ開発者と議論していきたい」（湧川氏）。

ネットワークのSDKもプログラムブルに

最後に登壇したのは藤井氏。「先の二人とはバックグラウンドがかなり違う」プレゼン冒頭でこう切り出し、藤井氏のプレゼンが始まった。同氏がGoogleからKDDIに転職したのは今年の4月で、MashupやWebAPIでアプリケーションを作っていくことに関心を抱いているという。KDDIではクラウド基盤のサービスの企画を担当している。

「HTML5はモバイル、ウェアラブル、クラウドへ転換していく」と藤井氏。そのときにクラウドの基盤とアプリケーションの配信基盤が今後、どうなっていくのか、そこに関心があるという。データセンターなどのインフラとアプリケーション開発基盤がセットになったものがどんどん登場している。その例として藤井氏が挙げたのが、Facebookのデータセンターのハードウェア設計をオープンソース化する「Open Compute Project」やAmazonの「AWS SDK for JavaScript」。「インスタンスを追加したりロードバランスの設定を変えたり、ということがAWSで動的に変えていける時代になっている」（藤井氏）

Webアプリケーションの基盤としてのPaaS、BaaS、MEAP（モバイル・エンタープライズ・アプリケーション・プラットフォーム）なども登場している。

「ネットワークのSDKのところがプログラムブルになるなど、Webアプリ開発者もアプリだけをみていれば良いという時代は終わったと言える。どんなクラウド、開発基盤を求めていくのか。Webアプリ開発者のその分野への自由な進撃が始まる」（藤井氏）

3人のプレゼンが終了し、コーディネータの小松氏は「これからのWebアプリケーション開発では、ネットワークやクラウドなどの知識もなければ難しくなる。そのための取り組みとしてキャリア側で用意していることやアプリ開発者に期待していることが教えてほしい」と問いかけた。

「2015年11月にIETFの会合が横浜で開催される。しかもW3CのTPACとの同時開催を今、画策している。この同時開催の裏側にあるのは、インフラとアプリがバラバラで開催することに限界がきているから。お互いにセッションし合わなければならないほど、深刻な事態に突入してきている。これは逆にビジネスチャンスでもある。IETFやTPACで何かしようとしたら2年ぐらいかかるので、『こういうアイデアがあるんだけど』という人がいれば、どんどん発信してほしい。そして2年後の横浜で世界に向かって成果として出す。これはすごいバリューになる」（宮川氏）

「アプリ開発側からネットワークの方にもっと寄ってきて欲しい。要求仕様を出してもらえると、私たちができることはまだまだ一杯ある。アプリ開発側がどういうところに問題を感じているかをぜひ、教えて欲しい」（湧川氏）

「ネットワークやクラウドを含め、すべてがプログラムできるような世界がくる。それを考慮に入れたアプリケーションの開発やアーキテクチャの作り方をしていってほしい。また先述したようにさまざまなインフラのサービスが登場しているので、それを使い分けていくのも面白いと思う。そのためにも、ほかのレイヤーの知識を身につけてほしいですね」（藤井氏）

ネットワークの知識は欠かせない

藤井氏の話に付け足す形で宮川氏はジュニパーネットワークスがこの秋に発表したOSSプロジェクト「OpenContrail」を紹介。同プロジェクトではApache License 2.0で利用できる SDNコントローラ、仮想ルータ、オーケストレーションAPI、アナリティクス、管理コンソールなど、データセンターのオーバーレイを実行するのに必要なすべてのコンポーネントを提供している。

また同プロジェクトではXMPPというチャットで使われるプロトコルを採用していることから、「例えば30分だけより大きな帯域を確保したいというと、15分後にそれが実現する、ということもできるようになるかも」と、アプリ側でできることの広がりを示唆した。

アプリ開発者にとってネットワークの知識がこれから大事になることを改めて実感できた同セッション。「HTML5の普及でネットワークへの敷居は下がってきている。Googleなども遅延をなくそうといろんな仕掛けに取り組んでいる。ぜひ、みなさんもネットワークを武器にしてこれからのアプリ開発に生かしてほしい」（湧川氏）、「HTML5だけに小さくまとまってしまうのではなくて、ネットワークとクラウドのところにも興味を広げ、大きな可能性を探ってほしい」（藤井氏）と呼びかけ、セッションは終了した。

（レポート：中村仁美／撮影：斉藤和佳子）

【講演資料・セッション映像】

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

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

連載：エキスパートインタビュー (2)

エキスパートインタビュー第二弾は、小松健作さん。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仕様として存在しているのですが、相互接続性の問題から実際には殆ど使われていません。