Hatena::ブログ(Diary)

naoyaのはてなダイアリー

January 23, 2013

Webはインターネットになった

先週金曜日にエンジニアサポートCROSS2013に行ってきた。目当ては @Jxck_ さんホストによる次世代Webセッション。セッション自体は前後半に分かれていて

  • 前半はプロトコル編。SPDY (wikipedia) や HTTP/2.0 の動向やその課題点など
  • 後半はアーキテクチャ編。プロトコルが変わった上で、その上で動くソフトウェアのアーキテクチャが云々

という内容でした。前半がより技術寄り、後半はテーマ的にもより広範の話題を扱うという感じでどちらも面白かった。

こちらに細かいログがあります。

話の前提になる SPDY や HTTP/2.0 周りの昨今については

あたりが詳しい。

SDPY や HTTP/2.0 の要素や実装の課題といったところも興味を引いたけど、後半で語られていたような既存アーキテクチャとのギャップをどう捉えるかというような話から、昨今のインターネットをとりまく様々な状況を考えさせられた。その辺りについて少し書いてみようと思います。最初は技術の話ですが、後半はより広範囲な考えについての記述になります。

SPDY がやろうとしていること

(当日の議論で話題になった範囲に限定すると) SPDY や HTTP/2.0 がやろうとしていることは、誤解をおそれずに言えば、たくさんのTCPコネクションを並列に貼ってる現状のHTTP/1.1は何かと非効率だから接続を一本にまとめてしまおう。そうすれば回り回って高速化が見込めるよ、ということだと思う。

もちろん件の仕様の主眼は高速化だけではないのだけれど、SPDY という名前がそこが関心どころだというのを物語っている。

SPDY と HTTP/2.0 は技術政治的にはどいういものかと言えば前者は Google が実装ファーストですでに実用化しているものであり、後者はIETFで標準化しようという流れのもの。(技術的には後者も SPDY を土台にしているので別物ではない。)

SPDY は Google、Twitter で導入されているし、ちょうど今日 Facebok が SPDY に対応したLINE も SPDY

f:id:naoya:20130123130840p:image:w500

SPDY indicator を Chrome に入れると、稲妻のアイコンが光って SPDY で通信しているかどうかを確認することができる。

ところで現状の SPDY は TLS (SSL) の NPN という仕様を利用して従来の HTTP を使うか SPDY を使用するかを決めている。ここ最近 Google や Twitter が https になったのは、主目的にセキュリティのためだと思うが、一方で NPNベースの SPDY を導入するのにも良い前提だったのでしょう。

実際問題として平均的なウェブサイトで SPDY を導入して高速化が見込めるかというと多くの場合はノーでしょう。一般的なサイトでは、プロトコルや接続数を最適化するよりも前に高速化できる、しなければならないところがもっとある。Google, Twitter, Facebook, LINE ほどの大規模トラフィックを持つ列強にっとてはその最適化で十分お釣りがくる・・・ということなのだと思います。

SPDY は現状のデファクトスタンダードである HTTP/1.1 では当然利用できないので、サーバー側とクライアント側両方にその拡張を施せるプレイヤーが有利です。Google は Chrome を抑えているからその芸当ができた。Twitter や Facebook は Chrome の仕様に合わせた。LINE はスマートフォンのアプリからの接続なので Google 同様クライアントを抑えていると言える。クライアントを抑えているので blog にもある通り NPN を使わない SPDY という独自方式を採用することができている。

既存の制約を壊すかどうか

「複数の接続を一本にすれば速くなる(かも)ね」というのはその通りですが、これまでの HTTP は「敢えて」そうしてこなかったのであり、それがステートレス性を含むさまざまな制約となっていた。「制約」と書くとネガティブに聞こえるけど、実際にはそれはアーキテクチャをシンプルかつスケーラブルに保つための「制約」であって、それが疎結合やRESTという考え方の基になっているのはご存じの通り。

「敢えてそうしない」がかつての Web を支えていた。

議論の中で「HTTPの上にHTTPを再構築しようとしている」という指摘があったけど、SPDY がやっていることはそういうこと。だから同じように通信の多重化やサーバーサイドからの push を目的としている WebSocket が同様の議論の対象になるのは必然と言える。

SPDY や WebSocket は HTTP/1.1 の制約では都合が悪かったところを、ある意味破壊して、実現できなかったことを可能にしましょうという仕様。そういうギャップがあるから、既存のロードバランサーやリバースproxyと相性が悪いとか、セッション維持方式のアプリケーションサーバーで問題がおこるといった HTTP/1.1 の制約を前提にしているものとぶつかってしまう。

セッションの中で何度も「break the web」という言葉が飛び交っていたけど、大げさな話ではない。

「Webってインターネットになったんだな」

じゃあ、そもそも何でそういう「Webではなかったもの」みたいな SPDY や WebSocket がこうして議論になっているのか、必要とされるのか。それは @yohei さんの

「Webってインターネットになったんだな」

という一言が非常によく表している。

むかしはむしろ「Webとインターネットを混同するな」と言われていた。インターネットには HTTP 以外のプロトコル、HTTP ではないネットワーク、Web ではないものが他にもあった。つまり、Web はインターネットの中で相対化されていた。でもその他のプロトコルの面倒くささとか、ファイアウォールの問題なんかがあって結局すべてが HTTP に集約されてきたのがこれまでの歴史。

@Jxck_ さん「HTTP はもともとドキュメントを操作するためのプロトコルだった。」ドキュメント = 始めと終わりが決まっているテキスト。でも最近は Facebook や Twitter のストリームのようにドキュメントでないものを操作するようになったし、Lingr や LINE のように HTTP で(ユーザー体験的には) ステートフルなチャットも行うようになったし、ネイティブアプリのように内部に多数の状態をもったアプリケーションを JavaScript で動かすようになったし・・・と、10年前には「Webではなかったもの」を Web の上で動かすようになり、こうして Web == インターネットになった。

その「Webではなかったもの」を動かす必要に駆られた理由は、紛れもなく、ユーザーからの要請。みんなもっと便利で、もっと快適で、もっと好きなことが書けて、もっとモバイラビリティの高いアプリケーションが欲しいと思っていましたよね。

こうして Web == インターネット、としたときに足りない仕組みとか邪魔な制約というものが目立つようになってきたのが昨今・・・ということ。「REST」という言葉で説明できていた Web のアーキテクチャも、それだけでは説明できなくなる。

技術だけではない Web とインターネットのギャップ

その「Webがインターネットになった」ということが表現した背景にある、既存のWebと今のWebとの差分 ・・・ ギャップはプロトコルやアーキテクチャの範囲に留まらない・・・と自分は考える。そういう意味で本当に本質的な一言だったと思う。

SPDY の話で "クライアントとサーバー両方握っているからできる芸当"、と書いたけれども、yohei さんは「これからはクライアントとサーバー両方を掌握しているところが一番面白い、強い時代なんです」と言っていた。技術的には確かにそうだが、その傾向に違和感を覚える向きもあると思います。HTTP/1.1 はクライアントやサーバーを選ばなかったからこそ技術的に中立だったし、広域分散的でもあった。そのあたりは単に実装や技術というよりは技術的な「思想」のレイヤ。SPDY、HTTP/2.0、WebSocket でその前提を崩していいのか、というのは上位概念である思想の議論だと思います。

iOS/Androidアプリは果たしてWebなのか、という議論もあります。Facebook、Twitter のiOSアプリはWebにあるデータを表示するクライアントだけれども、じゃあそこはWebなのか。アプリによっては、そのアプリが生み出したデータがインターネットにあっても Hyper Link で辿ることができないようなものが多い、さすがにそれは Web じゃないんじゃない? という指摘。今や Post PC 時代、これから先もスマートフォンは世界に普及していってそこからインターネットに繋ぐ人口は爆発的に増え続ける。かつての日本のように、モバイル端末から接続する人がインターネットのマジョリティになる。その時、その Web なのかそうでないのかよくわからない世界がインターネットの大多数になります。これをどう考えたらいいのか。

結局 Web == インターネットになったから、これまでは「Web」という文脈で切り取れば説明/理解できていたあれこれが、もうそれでは包含しきれなくなってきているのだと思う。

"The Web We Lost"

先にも述べた通り「Webがインターネットになった」というのは、大局的には、ユーザーの需要によって喚起された結果です。では果たして「Web == インターネット」になっていくことはすべてにおいて好ましい結果となるのか。そういうわけではなさそうだ、というのが先のギャップから垣間見えてくる。

ブログでも、Twitter でも何度か引用したけど、Tim Barners Lee が 2011 年に Long Live the Web: A Call for Continued Open Standards and Neutrality という論文を書いている。Webの中立性、Web上のコンテンツの中立性や民主性。それはWebのアーキテクチャと強く関係している。

Why should you care? Because the Web is yours. It is a public resource on which you, your business, your community and your government depend. The Web is also vital to democracy, a communications channel that makes possible a continuous worldwide conversation.

Long Live the Web: A Call for Continued Open Standards and Neutrality: Scientific American

かつての Web が、Web のアーキテクチャから導かれた中立性により世の中に新しい可能性を提示したからこそここまで世界に受け入れられ広まっていったということは疑いようのない事実だと思う。でも、そのWebのアーキテクチャが徐々に壊れてきている、というのが氏の訴えだった。

今回のパネルディスカッションの話から、嫌でもこの訴えが思い出された。Webはインターネットになったから、ある部分が壊れた。

The Web We Lost (翻訳) と言った記事が注目を集めたのは、この大きな流れからすると当然のことだったんだと思う。

The first step to disabusing them of this notion is for the people creating the next generation of social applications to learn a little bit of history, to know your shit, whether that's about Twitter's business model or Google's social features or anything else. We have to know what's been tried and failed, what good ideas were simply ahead of their time, and what opportunities have been lost in the current generation of dominant social networks.

So what did I miss? What else have we lost on the social web?

The Web We Lost - Anil Dash

オープンなインターネットなんてそんな過去のものにこだわってもしょうがないでしょ、という声も聞こえてくるとは思います。「そんなの知るか、俺たちはクールなアプリを作るだけ」というのも結構だと思う。

でも気づいた頃には無視できないくらいWeb が変容しているかもしれないし、インターネットに関わる以上はそれから無関係ではいられないのではないか・・・と思う昨今です。少しくらい歴史とか、何が必要条件だったのか、くらいのことを知ってみても良いのではないでしょうか。今を理解する土台くらいにはなるでしょう。

SPDY の話からずいぶん遠くまで来てしまったけれど、技術、アーキテクチャ、ネットワーク、コンテンツ、ユーザーを切り離して考えることができないからこそインターネットは面白いのだろうな、とも思います。