インターネットは過剰と過密による窒息死を防ぐためにHTTPからIPFSへ大改造すべきだ

linksweb

[筆者: Amber Case](位置対応ソフトウェア企業GeoloqiのCEO、同社は2012年にEsriが買収。過去にSXSWiやTEDでキーノートスピーカーを経験。 Calm Technology: Designing for Billions of Devices and the Internet of Thingsの著者。)

IPFSはまだ、シリコンバレー界隈でもよく知られていない技術だが、オープンソースの人たちのあいだでは口コミで急速に広まりつつある。多くの人たちが、インターネット上のファイル転送やストリーミングのスピードを大きく高速化する技術として、IPFSに注目している。

でも私から見れば、それは単なる高速化技術ではなくて、実際はもっと重要な技術だ。IPFSによって、Webサイトはコンテンツやサービスの起点となる中心的なサーバが不要になり、インターネットのアーキテクチャを抜本的に変える良い機会になると思われる。しかしそのためには、業界が未来に関して抱える自己矛盾を早期に(間に合うタイミングで)解決する必要がある*。〔*: 一点サーバ主義はボトルネックだが今の利益の源泉、など。〕

それではまず、背景事情から説明しよう。

なぜWebは遅くて脆くて何でもすぐなくなるのか

IPFSは新しい、ピアツーピアのハイパーメディアプロトコルで、今のWebを支配しているHTTP(Hypertext Transfer Protocol)を補完、もしくは置換する規格だ。HTTPにはこんな問題がある: どこかのWebサイトを訪れるとき、ブラウザはそのサイトをサーブしているコンピュータに直接接続することになり、サーバが遠くにあって転送処理が大量の帯域を消費するときでも、それは変わらない。

データの転送が複数のネットワークにまたがる場合は、データのプロバイダは各ネットワークで課金され、帯域を浪費する。しかもHTTPでは一度に一つのコンピュータからファイルをダウンロードし、複数のコンピュータから同時に少しずつダウンロードすることができない。

そのため今日のわれわれは、遅くて高価なインターネットを我慢し、しかも合衆国などでは最後の1マイルを提供するキャリアの貪欲と、加速度的に増加するモバイルデバイスからの接続リクエストに苦しめられる。その結果今のインターネットは、遅くて高価なだけでなく、信頼できない。HTTP転送は、何かの事情でリンクが一つ切れただけで、転送は完全に断たれる。Webページやメディアファイル(画像、ビデオなど)のロードが遅いとき、その犯人はたいてい、HTTPチェーンを構成するリンクのひとつだ)。

IPFSでインターネットを改造する

IPFS(InterPlanetary File System)(惑星間ファイルシステム)は、J.C.R. Lickliderのヴィジョン“intergalactic” Internet(“惑星間”インターネット)に触発されて、Juan Benetが構想した。10代でメキシコから合衆国に移住した彼はスタンフォード大学でコンピュータ科学の学位を取り、その後自分の会社を興したが、それは2013年にYahoo!が買収した。その後Y Combinatorに在籍した彼は昨年Protocol Labsを作ってIPFSの普及活動を開始し、20年間既成事実のようにのさばってきたプロトコルを置換する、という謙虚な*目標を掲げた。〔*: 謙虚な…大事業を“ささやかな”と形容するようなジョーク。〕

ピアツーピアの分散ファイルシステムであるIPFSは、すべてのコンピューティングデバイスを同じファイルシステムで結びつける。Juanによると、それによってIPFSは、HTTPの欠点のいくつかを取り除く。中でもとくに重要なものが二つある:

Juanは語る: “IPFSでは、アドレスとしてコンテンツを指定し、起点のサーバを指定しない。コンテンツは特定のサーバ上ではなく、どこかに恒久的に保存できる。そのコンテンツを、ユーザにとても近いところに保存してサーブできるし、極端に言うと同じ部屋の別のコンピュータでもよい。指定するアドレスがIPではなくコンテンツになると、データを特定のホストに縛られずに検証できる。単一のサーバを指定するHTTP方式では、それが信頼できないホストかもしれない。ユーザのデバイスがそのコンテンツを一度持てば、それを無期限にキャッシュすることもできる”。

IPFSはHTTPベースのインターネットにつきまとっていたセキュリティの問題も解決する。コンテンツをアドレスし、コンテンツにサインインするIPFSベースのサイトでは、DDoS攻撃が不可能である。また、Webサイトが突然落ちるという、従来からよくあるダメージを減らすためにIPFSでは重要な公共的コンテンツをアーカイブし、重要な情報を容易に(分散的に)保存できる。

IPFSによってインターネットが、われわれが理想としてきたシステムに成長できる。

IPFSの究極の利点は、コンテンツの分散配布だ。言い換えるとコンテンツへのアクセスが、特定のサービスの調子の良し悪しに左右されない。オフラインでのアクセスも可能だ。“IPFSでは、WebサイトやWebアプリケーションに特定の起点サーバというものがない”、とJuanは説明する。“それらは、Bitcoinのネットワークが分散しているように分散できる”。まさにそれこそが、今のHTTPには逆立ちしてもできないことであり、とくにそれほど接続性の良くないネットワーク(すべての途上国)や、大都市圏以外の地域にとって恩恵だ。

2月にアルファでリリースされたIPFSを、今多くのアーリーアダプター(初期的採用者)たちが実験している。たとえば9月8日にはNeocitiesが、メジャーなサイトとしては初めてIPFSを実装した。それはInternet Archiveからの分散Webの呼びかけに応えたものだ。今や、Webサイトがどんどん減っている。長い年月の間にサイトのオーナーたちが、それらを放棄し、無メンテないし閉鎖してしまうからだ。インターネットという、記憶/記録の集大成が、崩壊しつつある。IPFSの今後の普及が早ければ、恒久的なコンテンツやサービスが増え、崩壊を最小限で食い止められるだろう。

しかし、“ピアツーピア”という言葉を聞いただけでびびってしまう大企業が、Neocitiesの例に倣って、未実証のプロトコルを採用するだろうか? この点に、最後の問題がある。

IPFSがインターネットビジネスの将来にとって重要である理由

私の次の本でも説明しているが、インターネット上のコンテンツはますます、そこから得られる利益よりも制作と配布の費用の方が上回るようになりつつある。そのためメジャーなインターネット企業でも、コンテンツの需要にいち早く応えるのが難しくなっている。Akamai、Google、Amazonなどの大企業では、大量のエンジニアを、このたった一つの問題への対応に投入している。

でも、最悪の状態が訪れるのはこれからだ。低価格のスマートフォンの大普及により、全世界のコンテンツ消費者の全員が次の10年間でオンライン化する。そして物のインターネット(Internet of Things, IoT)が何十億ものデバイスをインターネットに接続することによって、インターネットの過密と、それによる性能劣化はさらに激化する。

かなり前から緊急に必要になっているのは、私が小さなシンギュラリティ(micro-singularities)〔Wikipedia〕と呼んでいるものに対するヘッジだ。その超ミニシンギュラリティにおいては、ヴァイラルなイベントが突然何10億ものインターネットユーザをフリーズし、システム全体が窒息する。これに自然災害やそのほかの緊急事態が絡めば、文字通り人命に拘わるだろう。

Netflixは最近、ストリーミングのための大規模なピアツーピア技術の実験を開始した。これだけ大きくてユーザ数も多い企業が、早くから、よりスマートなコンテンツ配布方法を探求していることは、希望の兆候かもしれない。NetflixやYouTubeのような帯域大食らいの人気サービスは、IFPSで改造されたインターネットの上で、より一層栄えるだろう。そしてコンテンツをサーブするために要する時間と費用も、激減する。

IPFSでネットワーク上のサービスが良くなるだけでなく、IPFSによってインターネットが、われわれが理想としてきたシステムに成長できる。その理想は、現在のプロトコルでは絶対に実現しない。世界中の人びとを(オフラインにおいてさえ)本当に結びつけ、人間の現状が恒久的にそしてコンスタントに進化し、誰もが望むような未来が実現していく。そんな理想は。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Google、QUICプロトコルでウェブをさらにスピードアップ

2795841993_231f831381_o

聞いたことはないかもしれないが、あなたがChromeユーザーなら既にGoogleのQUICプロトコルを使っている可能性は高い。先週Googleが公表したところによると、ChromeからGoogleサーバーに送られるリクエストの約半数には、QUICが使われている。

いったいその何が重要なのか? QUICはGoogleによるUDPレベルの実験的低遅延インターネットプロトコルであり、UDPはゲーム、ストリーミングメディア、およびVoIPサービスでよく使われるプロトコロルだ。’QUIC’ という名前は Quick UDP Internet Connectionから来ている。

プロトコルの世界でUDP(およびQUIC)と比較されるのはTCPだ(Internet Protocol[IP]との組み合わせでインターネットの核となる通信言語となっている)。UDPはTCPより著しく軽量だが、その代わりにTCPよりもサポートしているエラー訂正サービスが少ない。これは送信サーバーが、例えばデータが届いているか、正しい順番で届いているかを調べるために、受信サーバーと頻繁にやり取りしていないことを意味する。UDPがゲームサービスに最適である理由はそこにある。この種のサービスではオーバーヘッドを減らして遅延を最小にすることが望まれており、もし最新のマウス動作をサーバーが受け取っていなければ、1~2秒を費して訂正する必要はない ― なぜならアクションはもう先へ進んでいるから。しかし、ウェブサイトのリクエストには向いていない、なぜなら全データが届いたことを保証できないからだ。

QUICにおけるGoogleの狙いは、UDPとTCPの良いところを取り、最新のセキュリティー技術と組み合わせることだ。

0rtt-graphic

通常のセキュアなTCP接続では、ブラウザーが実際にデータを受信し始めるまでに、2~3回やりとりが行われるのが普通だ。QUICを使うと、ブラウザーは過去にやりとりしたサーバーとは直ちに通信を開始することができる。さらにQUICは、輻輳(ふくそう)制御や自動再送信等の新機能を導入することによって純粋なUDPよりも信頼性を高めている。
Googleは、後にHTTP/2標準の基礎となったSPDYという、QUICKと同様の目的を持つ代替プロトコルを既に開発しているが、HTTP/2はTCP上で動作しているため同じ遅延問題を抱えている。

それならなぜGoogleは、TCPの改善に取り組まないかと疑問に思うのは当然だ。問題は、同社の指摘によると、TCPサポートはしばしばオペレーティングシステムに直接組み込まれていることにある ― そしてOSはGoogleの制御が一切及ばない部分である。「QUICなら新しいアイデアを実験してすぐに結果を見ることができる」とチームはこの方式を採用した理由を書いている。「効果が証明された暁には、QUICの機能がTCPとTLSに移行されることを望んでいる」。未だにインストールされているWindows XPの数を踏まえると、それは一夜にして起こることでないことは明らかだ。

もしGoogleが全く新しいプロトコルを設計すれば、インターネットの根幹を支える全マシンもそれを理解しなければならない ― しかし彼らが既に理解しているのはUDPだ。

2015-04-18_1036Googleによると、QUICはGoogle検索において、平均ページ読み込み時間で約3%の改善を見せている。大したことがないように聞こえるが、Google検索が既に最適化できるだけ最適化されていることを忘れてはならない。他のサイト ― 特に遅延の大きいウェブアプリ ― ではもっと大きな改善が見込める。YouTubeをQUIC経由で接続したユーザーは、ヒデオ視聴中に再バッファリングが約30%少なくなったという報告がある他、QUICの改善された輻輳制御およびUDPのロスリカバリーによって、非常に遅い接続のユーザーでも、QUICによるページ読み込み時間の改善が見られている。

Googleは、HTTP2-over-QUICを、将来の新たなインターネット標準としてIETFに提案する計画だと話している。

これは様々な意味でGoogleのSPDYへの取り組みと類似している。同社はあの時もまずChromeと自社サービス上でプロトコルのプロトタイピングを行い、その後HTTPの新バージョンの基盤として提案した。
なお、自分のChromeがQUICを使って接続しているかどうかを知るには、このブラウザー機能拡張をインストールすればよい。

[原文へ]

(翻訳:Nob Takahashi / facebook

GoogleはHTTP/2を優先してSPDYのサポートを終了へ

Googleが今日、‘Google版のHTTP’とも言えるSPDYのChromeブラウザにおけるサポートを2016年の前半までに終える、と発表した。HTTPの次のバージョンHTTP/2の規格策定作業がすで相当進んでいるので、Googleも独自のソフトウェアを捨ててそちらを採用することにした。ChromeのメインリリースがHTTP/2をサポートするのは数週間後、と言われる。

HTTP/2は今のHTTP 1.1に対し重要な改良をいくつも加えている。長年お役に立ってきた HTTP 1.1も、それが90年代後半に策定されてから今日までのあいだにWebが大きく変わり、とくに、複雑なページや、ストリーミングなど大型コンテンツの読み込みの遅さ、遅れが目立ってきた。今日のWebサイトはコンテンツが大型化しただけでなく、非常に複雑にもなっているので、わずか1ページの読み込みにサーバへのリクエストを数百回も行い、同時に数十もの接続を開き保持することすら、珍しくない。

SPDY(“スピーディ”と発音する)は、ストリームや優先度設定(prioritization)、プロトコルネゴシエーションといった新しい機能をHTTPに持ち込み、ブラウザが多くのファイルをサーバにリクエストする場合のやりとりの回数を減らした。またSPDYはHTTPのヘッダを圧縮してオーバヘッドを減らしているが、その機能はHTTP/2にもある

HTTP/2はSPDYを踏み台にしてスタートし、最終形もGoogle色を多く残している。HTTP/2はこの数年間でSPDYに数々の変更を加えたが、それでもHTTP/2のプロトコルにはSPDYの考え方がそのまま生かされている。たとえばSPDYのストリームの概念も、その典型だ(HTTP/2のストリームは、多重化が加わるなど、SPDYに対しやや改良が加えられているが)。

HTTP/2はこれからほぼすべてのブラウザがサポートすることになるので、Googleとしても独自プロトコルに固執する理由はない。SPDYは、HTTP/2にその方向性を提供したが、現時点ではもはやGoogleのやるべきことは残っていない。将来、HTTP/2に対し不満が出てきたら、またGoogleの出番があるかもしれないけど。

GoogleのエンジニアChris BentzelとBence Békyは、次のように述べている: “オープンなスタンダードであるHTTP/2の策定過程に貢献できて幸甚である。その策定と実装の過程には業界の幅広い参加が得られたので、今後の広範な採用を期待したい。また弊社は、インターネットの基盤的なプロトコルの今後のさらなる進歩により、より高速でより安全なインターネットを多くの人びとに提供していきたい”。

同社はサーバのデベロッパに対して、同社の方向性に従うこと、これからはもっぱらHTTP/2のみを実装することを、推奨している。またTLSに関しても、そのHTTP/2バージョンでセキュアなhttps接続を支えるALPNへの準拠を、求めている。ブラウザと違ってGoogleのサーバは、まだ当分SPDYをサポートすると思われるが、しかし長期的にはやはりSPDYのサポートを完全に終了するだろう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))