HTTPが全てを飲み込む（中編）～HTTPの上にIPやイーサネットが実装されて便利になること

今回は「HTTPが全てを飲み込む（中編）～HTTPの上にIPやイーサネットが実装されて便利になること」についてご紹介します。

関連ワード （佳境、宛先、目的等） についても参考にしながら、ぜひ本記事について議論していってくださいね。

本記事は、Publickey様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。

Webを構成する重要な要素の1つであるHTTPは、その最新仕様で2層構造となり、バージョンに関係なく使えるSemanticsと、特徴の異なる通信仕様を定めたHTTP/1.1、2、3に分割されました。

さらに現在では、HTTPの上にあらためてUDPやIP、イーサネットなどのプロトコルを実装する提案が行われており、まさにHTTPは通信の全てを飲み込む勢いで進化しつつあります。

こうしたHTTPの最新動向の解説が、大手CDNベンダのFastlyが2023年11月8日開催したイベント「Yamagoya 2023」で同社シニアプリンシパルエンジニアの奥一穂氏が行ったセッション「HTTPが全てを飲み込む」にて行われました。

本記事ではこのセッションをダイジェストで紹介していきます。記事は以下の3つに分かれています。

• HTTPが全てを飲み込む（前編）～HTTPの2層構造と、HTTP Semanticsとは何か？
• HTTPが全てを飲み込む（中編）～HTTPの上にIPやイーサネットが実装されて便利になること
• HTTPが全てを飲み込む（後編）～アップロードのレジューム機能標準化など開発中の新機能

今お読みの記事は「HTTPが全てを飲み込む（中編）～HTTPの上にIPやイーサネットが実装されて便利になること」です。

extended CONNECTの登場

でも、HTTP/2ではupgradeが廃止されたと、さっき言いましたよね。upgradeを使っているWebSocketはどうしたらいいんでしょう。

これはHTTP/1.1のWebSocketのリクエストですけれども、こうやってHTTP接続をWebSocketのために使う、upgradeはそういった切り替えをやっています。

ところがHTTP/2にはconnectionヘッダもupgradeヘッダもありません。

そこで出てきたのがextended CONNECT、つまりCONNECTメソッドの拡張という考え方です。

従来のCONNECTメソッドはTCPトンネルを作成するための機能で、通信相手はhost:portで指定していました。

TCPトンネルとは、つまりはバイト列を双方向転送するためのものですから、実はupgradeと求められている機能、実装されている機能はほぼ同じです。

ただ何が違うかというと、upgradeは通信相手はhost:portではなくURIで指定される点と、バイト列で表現されるプロトコルが、例えばWebSocketである、というようなことをupgradeヘッダで指定している、この2点が違うわけです。

それならCONNECTメソッドでURIとプロトコルを指定するようにしたらいいじゃん！ ということでできたのが、extended CONNECTと呼ばれるやり方です。

メソッドはCONNECTですが、「:protocol」（コロンプロトコル）という特殊なヘッダを使って実はWebSocketにコネクトするんだよ、みたいなことを言ってやるわけですね。

この赤い丸のところ見ていただければわかるように、CONNECTメソッドですけれども、「:scheme」「:authority」「:path」などが指定され、そしてHTTP/1.1ではupgradeヘッダを使っていたところを、HTTP/2、3では「:protocol」を使っていて、指定するトークンは同じなっている、そういうことがご覧いただけるかと思います。

CONNECTを使った新しいプロトコル「connect-udp」

このextended CONNECTという仕組みを使って、新しいプロトコルが登場してきています。

「connect-udp」、これはTCPトンネルではなくUDPトンネルを作ります。

CONNECTで作ったトンネルでUDPパケットを転送する。ただ、このままだとバイト列のトンネルですのでリアルタイム性が低いという問題があります。

そこでHTTP/3では、UDPパケットを個別のQUICパケットとしてエンコードして送受信してやることで、生のUDP通信とほぼ変わらないパフォーマンスを発揮するようになります。

これが実際にどういうところで使われてるかといいますと、例えばAppleさんのiCloud Private Relayですね。

iCloud Private RelayはTCPやUDPの通信をAppleのサーバを通してVPNのように通信する仕組みです。この場合UDPの転送トンネル化というのはconnect-udpを使って実装されています。

新しいプロトコルconnect-ip

CONNECTでTCPトンネルが作れてUDPトンネルも作れて、次に出てきたのが、IPトンネルを作りたいよね、というものが「connect-ip」です。

connect-ipの何が嬉しいかというと、HTTPを使ってL3VPNが作れるんですね。

また、L3VPNを作れるということは、HTTPの基盤の上でUDPやTCPのサーバをVPN経由で公開する、といったものを実装できる。というのが大きなメリットになっています。

そして、HTTP/3でデータグラム拡張を使えば、性能上の問題というのは先ほどと同じように解決できます。

新しいプロトコルconnect-ethernetとconnect-tcp

次に、connect-ipがあるなら「connect-ethernet」もあっていいじゃないかということで出てきました。

さらに、「connect-tcp」も出てきました。

でも、connect-tcpと言ったところで、もう普通のCONNECTがあるではないかと、そう思うかもしれません。

しかし従来のCONNECTは、個別のIPアドレスを持ったコネクトプロキシを用意する必要がありました。なぜかというと、クライアントは接続先をhost:portで指定してプロキシに繋ぐ、そういうモデルになってるからです。

これだと、CONNECTプロキシを立てても、それをさまざまな目的のために使うのが実はやりにくかった。

connect-tcpではURIを用いて中継するエンドポイントを指定することで、1台のプロキシサーバでさまざまな設定のネット中継機能を提供できるようになります。

例えば、LAN内にデータベースサーバやLDAPサーバなどのいろんなサーバがあって、そこにインターネットから繋ぎにいくようなゲートウェイを作るときに、1つのサーバ、1つのゲートウェイの中にいくつものエンドポイントを作って、データベースに接続しに行く場合のユーザー名パスワードはこの値、LDAPサーバに行くときには、別のユーザー名とパスワードの値にする、そういった柔軟性のあるゲートウェイを作れるようになります。

WebScoketを置き換えるWebTransport

CONNECTシリーズにとどまらず、WebTransportという新しいプロトコルも標準化が佳境に入りつつあります。

WebTransportは、従来のWebSocketを置き換えるものです。

WebSocketには3つの限界が指摘されています。1つ目は、1本の双方向バイトストリームを使うので、同時に複数種類の通信がやりにくい。2つ目は、TCPの上で1本のバイトストリームを使うため、どうしてもヘッドオブラインブロッキングが発生します。つまり、パケットが欠落すると後続のデータが届いてても使えない、という問題です。

3つ目は、UDPのように音声データのような再送が不要なデータがボンボンと届く、そういった使い方にも向いていません。

こうした特性のため、WebSocketは低レイテンシが求められる、例えばチャットやゲームのようなものには不向きです。

WebSocketのこれらの問題点を解消するような、例えば複数ストリームに対応し、データグラムを送れるようにする、それが「WebTransport」です。

WebTransportには複数ストリームの機能があるので、HTTPスタックにも手を加える形になります。そのため、このような構造になっています。

例えばWebTransportで複数ストリームを開く場合は、HTTPからストリームを借りてQUICのストリームを直接開く、といった形になります。

ただ、WebTransportはHTTP/3、UDPの上で動くプロトコルですから、そのままでは繋がらないところもある。そのため、HTTP/2にもWebTransportをバックポートとして使えるようにしようとしています。

その場合はどうしても性能は落ちますが、UDPが使えないようなネットワークでもWebTransportが使えるようになります。

media over QUICは低レイテンシな配信向け

さらにですね、「media over QUIC」といったようなものも開発が始まっています。

これは例えばビデオの会議であるとか、ゲーム配信であるとかビデオチャットであるとかそういう低レイテンシでのメディア配信を狙ったプロトコルです。

既存のソリューションとしてWebRTCがあるのですが、WebRTCはSCTCPやDTLSなどマイナーな技術に依存していてスタックが複雑であるという問題があります。

そこでQUICをベースにしたmedia over QUICという新しいプロトコルを仕様を整理して作っています。

これはWebTransport上でも動作するので、Webブラウザの上で動かすこともできますし、HTTPでキャッシングできるようになるかもしれません。そういった形での開発というのが進んでいる感じになっています。

HTTPのバージョンに関係なくトンネルを作ることができるように

これらextended CONNECTについてまとめると、HTTPのバージョンに関係なくトンネルを作ることができるようになります、ということです。

従来はGETとupgradeを使っていたものが、HTTP/2と3ではCONNECTと:protocolという特殊なヘッダを使ってトンネルを作ることができるようになります。

そしてこれはHTTPの上で動いてるので、URIで宛先を指示したりプロキシキャッシュを使ったりできる柔軟性を持っています。

これらを利用して多数のユースケースがどんどん提案されて標準化が進んでいる。それらが今紹介したような一連の新しいプロトコルです。

≫後編に続く：アップロードのレジューム機能標準化など開発中の新機能