『Reverse HTTP Transport』という提案仕様がIETFに提出されています。著者はMetaとNokiaの方々らです。また、HAProxyの方も同様の機能を検討しているそうです(参考URL)。
普通のProxyサーバでは、Proxyサーバからオリジンサーバにコネクション確立するのが一般的です。そのためにオリジンサーバが外部から接続を受けられるようにする必要があります。
Reverse HTTP Transportでは、逆にオリジンサーバからProxyサーバにコネクションを確立し、HTTPリクエストを受け付けるという構成になります。コネクションの確立/TLSハンドシェイクだけが逆向きで、コネクション確立された接続上で、ProxyからHTTPリクエストが送られます。
これによりオリジンサーバをインターネットに公開する必要がなくなります。
プロトコルについて
この Reverse HTTP Transport はプロトコルスタック的にはHTTP2/TLS or HTTP/3/QUICという主要な技術は変更無く使用されます。通常の場合との違いは次のとおりです
- ALPN IDとして"h2-reverse", "h3-reverse"を使用する
- Proxy側はTLS CertificateRequestを送信する必要がある
- オリジンサーバは有効な証明書チェーンを応答する必要がある
- オリジンサーバはORIGINフレームを送信し、自身がホストするオリジン名を通知する。なお、このオリジン名は送信したクライアント証明書とマッチする必要がある。
- Proxy側は、オリジンサーバの送ってきたORIGINフレームとクライアント証明書を照合する
Proxyはオリジンサーバがホストしてるオリジン名を把握できるので、HTTPリクエストをオリジンサーバ宛に中継できるようになる。
