今回のゲストは数々のオープンソースソフトウェア（OSS）で知られる奥一穂さん。通信プロトコルの最先端は今どうなっているのか，お話を伺いました。

Fastly 奥 一穂さん

HTTP/2サーバであるH2Oなど通信プロトコルを専門とする職業OSSプログラマー。
IETFでの標準化にも参画する。サイボウズ・ラボ，DeNAを経て，現在はFastlyに勤務。

Twitter：@kazuho
URL：http://blog.kazuhooku.com/

LOGO，HyperCardから，H2Oへ

竹馬：自分の周囲で「一緒に働いたことがある人だと誰がすごかった？」というテーマで話すと奥一穂さんの名前が挙がることが多く，一度お話を聞いてみたいと思っていました。まずはこれまでの経歴を伺えますか。

奥：最初にコンピュータを触ったところから始めると，小学生のとき親の都合でオーストラリアの学校に通っていて，授業で触った学習用プログラミング言語のLOGOを気に入ってコンピュータ室に入り浸っていました。中学生になってからは親が持っていたPC-9801とかMacのHyperCardとかポケコンとか。それが1990年ごろです。

大学の教育用計算機センターで遊んだり，アルバイトをしたりしていたころにPalm OSが出たんですが，TCP/IPスタックとモデムがあって，でもWebブラウザがなかった。HyperCardみたいなオーサリング環境が好きで，それを再現したくてC言語でプログラムを書けるようになったのだし，Palm OSのブラウザがないなら，と自分で作りました。

そんなことばっかりやっていたせいで大学を退学したんですが，先輩の会社に転がりこんでいたら，IBMやNTTドコモ，SONYといった企業さんからそのブラウザをバンドルしたいという話をもらい，それが本業になったという感じです。

Palm OSは下火になってしまったんですが，そのあと未踏ソフトウェア創造事業でWebベースのPerlの統合開発環境をやって，そのとき誘われてサイボウズ・ラボに入って，ローカライズ支援ツールのJapanizeや，閲覧ログをとったりするPathtraqを作りました。

それらに関係して，Q4MというMySQL用のメッセージキューを作ってオープンソースにしました。Q4Mの最大のユーザーがDeNAだったので，大きなシステムに触れるのに惹かれてDeNAに転職したんです。

そうしたらDeNAがngmocoっていうスマホ用のゲームSDKの会社を買って，携帯端末で実行環境を書いた経験のあるプログラマーが社内にいたぞってことでサンフランシスコに送り込まれて……。その過程でJSXというプログラミング言語（注1）を開発して，JSXの実行環境の1つとして作られたWebソケットサーバが，今やっているH2Oのもとになっています。ちょうど手頃なHTTP/2のサーバがなかったんです。そのあとH2Oの一番大きなユーザーであるFastlyに転職して現在に至ります。

注1）

ReactのJSXとは別のもの。

OSSを引っさげて飯を食べる

竹馬：一穂さんと言えば，自作のOSSを引っさげて転職する人で，かっこいいな，まねしたいな，とあこがれてるんですが，なかなかそこまでできる人はいません。選ぶテーマにコツとかあるんでしょうか。もちろん，品質が高いコードを書けることが前提で。

奥：こういうスタイルの人は，そこまでいないわけでもないです。僕の知り合いにも，オープンソースのプロダクトを開発して，それで屋号を掲げて飯を食べている人は何人かいます。Varnish開発者のPHK（Poul-Henning Kamp）さん，HAProxyのWilly Tarreauさん。PowerDNSのBert Hubertさんも似たような感じかな。通信プロトコルをやっている人たちにとっては，OSSを小規模な会社，1人あるいは小規模なそれ専業でやって，それをビジネスにしたり，コンサルティングをやるというのは一般的だと思います。通信ソフトだからこそだと思いますが。

ソフトウェア自体は価値の中心ではなくて，インテグレーションが価値の中心。ライブラリを作っている人は，インテグレーションのコストを下げるためにオープンにしていくのが当然の流れなんだろうと思っています。

竹馬：標準化の世界ですよね，通信って。

奥：通信は相手と話せないと意味がないですから。で，もう一つの飯の食い方は，コストがかかっている部分をコンピュータサイエンスの技術を使って改善して，スケールメリットで儲けること。大きい会社のR&D部門に寄食する感じですよね。そこでは大きなイノベーションは不要なんです。新しいものを作るのではなくて，今あるものを改善するという話なので，着実に成果を出せる分野です。そういうところに属するのが合理的な選択だと思いますね。

竹馬：まさに今の一穂さんの立場ですよね。

奥：CDN（Contents Delivery Network）ってなんだかんだ言ってWeb配信のための最適化をやる業界じゃないですか。僕みたいな仕事をやっている人がいっぱいいるわけです。そういう環境がどれだけあるかという話になりますね。

QUICは自由な進化のための基盤

竹馬：一穂さんが今取り組んでいるQUICについて，技術的なことをお聞きします。今はHTTP/3って言うんですか，より自由度の高いUDP（User Datagram Protocol）の上でTCPのような機能を実現しているものですよね。TCPのようなレイヤだと，古いものは負債もたまっているんでしょうか。

奥：そう。TCPとTLS（Transport Layer Security）を置き換える部分をQUIC，HTTP特有の部分をHTTP/3と呼ぶことになりました。TCPについてはいろいろあるのですが，TCPが発明された50年ほど前にはすごいネットワークが細かった。でも今はネットワークが太いので，通信のボトルネックがパケットの量ではなく，エンド間で往復するラウンドトリップにあるんです。

TCPがあって，TLSがあって，その上にHTTP/2がのっていたんだけど，やはりレイヤが多いのでオーバーヘッドがある。TCPのパケットをロスしたときにHTTPの別のストリームでHead of LINE Blocking（パケットが届いていても利用できない状態）が発生してしまったりとか。

また，TCP自体は平文なので，攻撃に対しても弱いんです。TCP/TLSを一体化させてしまえば攻撃耐性は上がるし，プライバシーも守れる。今はTCPが平文だから，中継装置が勝手にいろんなことやるんですね。そのせいでTCPの改良ができない。たとえばTCP Fast Openの導入もなかなか進まない。TCPは実質的に硬直化しています。

この現状を踏まえて，できる限り硬直化しないように暗号化／難読化されたプロトコルを作ろうというのがQUICのもう一つの目的です。より高速で，より安全なだけでなく，今後自由に進化するための基盤を作ろうということです。中継装置に関係なく，エンド間で自由に進化させることができるという，これがQUICの基本的な考え方です。