Scribble at 2022-06-21 10:21:05 Last modified: 2022-06-21 10:43:56

ゴシックと言ったらいいのか、なにやらグロテスクな絵柄を各所にちりばめた文書だが、中身は最新のプロトコルの一つである QUIC についてのインタラクティブな解説だ。ご承知のとおり、QUIC は Google が開発・提案したインターネット上の通信プロトコルであり、現在は RFC となって企業の思惑は払拭されている（というのが大方の理解だが）からか、次世代の規格（HTTP/3）としてブラウザやサーバ・ソフトウェアでの応用となる実装が進んでいる。

いま「応用」と書いたが、その理由は QUIC が HTTP のようなアプリケーション層のプロトコルではなく、TCP/IP 参照モデルで更に下位となるトランスポート層でのデータ伝送にかかわるプロトコルだからだ（OSI 参照モデルで言えば、アプリケーション層からトランスポート層までのあいだにセッション層やプレゼンテーション層がある）。したがって、QUIC にもとづいて処理される通信内容は、僕らが HTTP とか SMTP とか FTP とかのアプリケーション層で知っている様子とはかなり違っていて、はっきり言えば人が読んで即座にわかるようなものではない。バイナリ・データだからだ。

でも、それを処理する仕組みについて知っておくことは有用だし、それなりに面白い。

ちなみに、ウェブ・サーバが HTTP/3 に対応しているかどうかチェックできるサイトもあるが、そういうものは特に躍起になって気にする必要はない。現在、ウェブ・アプリケーションやウェブ制作の事業にかかわるウェブ・サーバのアプリケーションとして HTTP/3 に対応しているのは、Nginx と LightSpeed だけであり、Apache は QUIC に関するサポートの可否について公式アナウンスは全くないし、試験的な対応が始まっているのかどうかすら不明だ。現実問題として大半の商用ウェブ・サーバでは2015年に規格化された HTTP/2 ですら、それが良いか悪いかの話は別にできるとしても、昨年の時点でも統計では 50% の普及率である。それに、HTTP/2 や HTTP/3 についてはスピードとか安全性の利点は数多く紹介されているとは言え、従来の HTTP だけで通信することが深刻なほどの大きなリスクとなるわけではない。なぜなら、ウェブ・サーバと僕らのソフトウェアとで個人情報や機密情報を通信するときに最大のリスクとなるのは、実は使っている通信プロトコルやサーバ・ソフトウェアなどではなく、情報を受け取る側の事業者のデータ管理方法という、人間の問題だからだ。こういう問題を QUIC だろうと何だろうと、しょせんは機械の決まりごとにすぎない通信プロトコルは解決できないのである。解決するには、サーバの運用から情報の扱い方も含めて、便利で素敵な AI とやらを使って完全に自動化し、ホモ・サピエンスなどという欠陥生物の判断や操作が業務フローに入る余地を排除しなくてはならない。