Jana Iyengar が語る QUIC の開発 : Web の基盤となる標準の再構築

数か月前に Fastly に入社して以来、最も心躍る体験のひとつは、Fastly がインターネットの改善に向けて奮闘する様子を目の当たりにできること、そして、志を同じくする仲間たちと一緒にそのような取り組みをさらに深く掘り下げる機会を持てたことです。このような改善のひとつが QUIC です。ご存知のとおり QUIC は、TCP に取って代わった画期的なトランスポート・レイヤー・ネットワーク・プロトコルです。実際、数十億人のユーザーが毎日、Web 上で行う動作の一環として QUIC を使用しています。undefined

Fastly でこの取り組みを指揮している主要チームメンバーのひとりが Infrastructure Services 部門におけるプロダクト担当 VP の Jana Iyengar です。長年にわたりネットワークの世界に携わってきた Jana は、トランスポート標準に関する経験が豊富です。近年は特に、QUIC と HTTP/3 の構築とデプロイに取り組むとともに、IETF の QUIC 仕様のエディターも務めています。 

Jana の経歴を知って、コミュニティに集う優秀な人々と共に、誰もが毎日使用するインターネットの基盤となる基本的な標準の再構築に奔走してきた経験についてぜひ話を聞きたいと思いました。ある一人の人物がインターネット全体の改善に大きく貢献したという興味深いストーリーをお楽しみください。

Anil Dash : では早速、始めましょう。私は2010年のウェビー賞の授賞式で、TCP/IP プロトコルの創生を称え、「インターネットの父」のひとりとして知られる Vint Cerf 氏に Lifetime Achievement Award を授与しました。QUIC は今や TCP に取って代わり、偉業を成し遂げたといえますが、どのようにして始まったのですか？また、現場ではどのように受け止められていますか？

Jana Iyengar : はじめに、トランスポートの分野に23年間携わってきた者としてお話しさせてください。これは、QUIC に限ったことではなく、私たちが20年間にわたって解決しようと試みてきた問題でもあります。

「世紀の変わり目」以降のことですね。

そうです。私たちは、この問題を解決したいと思ってきました。初期の取り組みとして、HTTPNG と呼ばれた次世代 HTTP などが挙げられますが、すべては90年代後半に起こりました。しかし、ドットコムバブルの破綻後、IT 業界は最後までやり遂げることができませんでした。 

この業界が消費者から利益を得ながら、それを還元していなかったことは注目に値します。誰も Web の基盤に投資していませんでした。

実際のところ、Web の真の潜在能力がどれほどのものかを理解している人はいませんでした。重要なのは Web ポータルだと考えられていたため、誰も彼もがポータルをセットアップしました。ひとたびその流行が去ると、Web の本質的な部分に目が向けられるようになり、それを活用するための取り組みが始まりました。Web に頼る企業が増え、よくできた Webサイトが欲しいと考える時代から、それが必須である時代へと移り変わりました。最終的に必要なのは、ちゃんと機能する Web でした。undefined2010年には、セキュリティとスピードの両方が重要であると理解されていましたが、プライバシーの保護に対する関心はまだあまり高くはありませんでした。しかし、2013年にエドワード・スノーデン氏が政府によるインターネットトラフィックの監視を暴露して世の中の注目を浴びたこともあり、プライバシーの保護において転機が訪れました。

詳しくお聞かせください。

まず、セキュリティとプライバシーの違いを明らかにする必要があります。私たちがセキュリティについて語るとき、意味しているのは転送中の情報の暗号化です。一方プライバシーとは、PII (個人を特定できる情報) を安全に保護することを意味します。スノーデン氏の暴露により、私たちはエクスチェンジポイントのトラフィックが絶えず監視されていることを知り、安全なコミュニケーションというものは存在しないことが明らかになりました。外部者があらゆるユーザーデータを監視できるということです。それまで、セキュリティはパフォーマンスの面で優れているとは考えられておらず、サーバーのリソースに大きな負担がかかる可能性があるという懸念がありました。非効率なセキュリティによってインフラストラクチャに多大なる負荷がかかっており、高いコストが発生していると考えられていたのです。

しかし、議論の風向きが変わり、コミュニケーションの安全確保が重要視されるようになりました。セキュリティを確保する手段は、エンドツーエンドの暗号化一択となり、データセンター内や、サービス間をも含め、すべてにおいて標準となりました。一方で、レイテンシを短縮したいという願望も変わらずにありました。つまり、高速であると同時に安全なコミュニケーションが求められたのです。undefined

この時点で、TCP の使用は一般的になっていましたが、新しいデバイスが登場し、Web の利用が拡大したことで、TCP の使用に限界がきました。次に何が起こりましたか？

その結果として QUIC が誕生しました。TCP が Web トラフィックに対してパフォーマンス上の問題を抱えていたことは、1995年から知られています。

QUIC は、優れたセキュリティ、低レイテンシ、迅速なデプロイといったニーズを満たすために生まれたのです。こういった課題の解決が急がれ、すでに興味深い取り組みが数多く行われていましたが、それまではまだ機が熟していませんでした。QUIC 誕生の契機となり原動力となったのは、あらゆる Web コミュニケーションの一部である TCP と TLS のハンドシェイクにおけるレイテンシのオーバーヘッドを解消したいという願いでした。

QUIC は既存の技術的進歩の集大成といえます。HTTP/2 が公開された2015年、誰もがスタックの最上層部でレイテンシを短縮しようとしていましたが、実際にこれを可能にする鍵はスタックのはるか下層部にありました。QUIC に関する取り組みは、当時私が勤めていた Google で始まりました。私たちは社内で QUIC の開発に取り組み、イタレーションしてリリースしました。その後、業界の他の人たちに使用を促す取り組みが始まりました。IETF 標準化団体に参加し、幸いにも Mozilla、Apple、Microsoft、Fastly を含む多くの企業が Google の概念実証に基づいてサポートすることを決めました。

つまり、1つのプロトタイプが実に千回分もの会議に値するものだったということですね。

はい、まったくそのとおりです。私たちが作成したプロトタイプはライブ環境で機能するものだったので、すぐに採用が可能でした。

抵抗はありませんでしたか？標準の設定は論争の原因となることもあるため、不満がある人もいたのではないでしょうか。

近寄ってきて「私のネットワークではこれを使うつもりはありません」と言う人はいました。

基本的に、そういう人たちには「これはすでにあなたのネットワークで起こっていることです」と伝えました。

もし QUIC が機能していなかったら、デプロイしたときにそのような意見を耳にしていたはずです。しかし、QUIC はすでに機能していたので、根拠のない批判の多くをかわすことができました。

私たちは、より多くのことを安全にできるようにしたかったので、QUIC のトランスポート自体で暗号化したいと考えました。これについては多くの議論がありました。 

それについて詳しくお話しいただけますか？どのような内容の議論が行われたのですか？

私たちは、ネットワークへの新しいトランスポート技術のデプロイにそれまで苦労してきました。多くのメカニズムが干渉し、TCP ヘッダーを読み込んで操作する環境では、新しいトランスポートのデプロイは不可能です。

QUIC のプロトコルヘッダーはほぼ完全に暗号化されましたが、多くのネットワーク事業者がこれについて不平を言いました (未だに不平を耳にします)。しかし、私たちはこのプロトコルを保護したため、イタレーションして改良することが可能でした。誰も QUIC の内部構造を操作することはできません。コンテンツを中継するシステムにとってヘッダーは不透明であるため、プロトコルのコントロールを維持できるようになりました。

QUIC の歴史にはもっと多くの出来事があり、それらは GitHub やメーリングリストのアーカイブ、夕食時の会話の記憶などに記録されています。私は、QUIC の成熟に関する以前の記事で、QUIC の進化にまつわるストーリーをご紹介しました。

ここで QUIC の現状に目を向けてみましょう。QUIC プロトコルは目に見えないところで私たちをサポートしてくれていますが、今後どうなると思いますか？この新しいバージョンの TCP を活用してどのようなことが可能になりますか？

QUIC は Web のために構築されました。現在、ほぼすべてのブラウザが QUIC をネイティブサポートしています。iOS と Microsoft はプラットフォームレベルでサポートしています。大半の CDN プラットフォームのベンダーもサポートしています。

ただし、Web は、QUIC をこれらのサーバーやクライアントのスタックに組み込むための単なる手段にすぎません。QUIC はプロトコルであるのと同様にプラットフォームでもあります。(QUIC を活用する) MASQUE は、ID を隠すことを可能にするトンネルを提供します。このプロトコルは例えば、iCloud プライベートリレーや、Fastly が使用している INVISV のリレー製品の基盤になっています。

あなたは、インターネットの先駆者たちとともに伝説の人物となっています。これらの先駆者は大きな影響をもたらしました。このように受け継がれてきた功績において、ご自身をどのように位置づけていますか？

どうお答えすればよいのか分かりません。先駆者と呼ばれる人たちの何人かと話す機会がありましたが、最初から影響を及ぼそうと考えていた人はいませんでした。当初、IPv4 は実験的なものと考えられ、本番環境のインターネットでの使用は想定されていませんでした。自分の影響力について考えていたら、最高の仕事をすることはできないと思います。最高の仕事ができるのは、最善を尽くしているときです。QUIC はコミュニティによる大きな努力の賜物です。それに、このコミュニティには複数のリーダーがいます。

影響力に関して個人的な野心があったというわけではありませんが、QUIC の開発は非常にやりがいのあるチャレンジでした。私はトランスポートの分野で仕事をしてきた23年間において、何度か新しい技術のデプロイを試みました。私はよく自分のことを「失敗したトランスポート技術の守護聖人」と呼んでいました。QUIC を実現し、現在見られるデプロイのレベルまで引き上げるのに多くの人々が関わってきました。QUIC を使用して次は何ができるか考えるとワクワクします。

この記事は、プライバシーに関するプラクティスやテクノロジーをインターネットの構造に統合する Fastly の取り組みをご紹介する Privacy Week の一環として書かれたものです。