Caddy 経由の DiscourseHub と iOS Safari PWA における Multipath TCP (MPTCP)

サポート インストール
, , , ,
1

Caddy in front of app’s Nginx via Docker Compose の議論を継続します。

Discourse の nginx コンテナの前に Caddy を配置して HTTP/3 と QUIC 0-RTT を提供する件について以前議論したのを受け、今回は別件だが関連する質問について調査しています。iOS ユーザーが Wi-Fi とセルラーネットワークの間を移動する際の接続継続性を、Multipath TCP (MPTCP) が向上させる可能性があるかという点です。

以前の作業は主に初期のページ読み込みパフォーマンスに関心がありました。今回の質問は異なります。私は活動場所を移動しながら個人的な Discourse 学習アーカイブに定期的にアクセスしており、接続の中断やバッファリングが発生すると、重要な情報へのアクセスが遅れてしまいます。

質問の背景

一部の場所では Wi-Fi が安定している一方でセルラーの受信状態が悪く、別の場所ではその逆です。

通常の iOS のネットワーク切り替えでは、私が求める継続性が常に得られるわけではありません。接続のレジリエンスのためにすでに別のネットワークボンディング/フェイルオーバー技術を使用していますが、iOS クライアントと私の Discourse サーバーの間で、その継続性の一部をネイティブに実現できるかどうかを理解したいと考えています。

特に、帯域幅の集約よりも、接続のハンドオーバーやリクエストの停止を避けることに興味があります。

現時点での調査結果

Linux MPTCP 互換性ドキュメント には、Caddy v2.10.0 以降が MPTCP をデフォルトでサポートしていることが記載されています（オペレーティングシステムのサポートに依存）。

Apple の MPTCP ドキュメント は、アプリケーションが URLSessionConfiguration を通じて MPTCP を有効にできる方法を説明しています。

しかし、Apple Developer Forums の解説 によれば、WKWebView には同等の MPTCP 設定オプションが公開されていないようです。

そのため、DiscourseHub、Safari、またはインストールされた iOS PWA が MPTCP の恩恵を受けられるかどうか、特に QUIC 経由の HTTP/3 も利用可能な場合にどうなるかについて、確信が持てません。

確認済みサーバー環境

読み取り専用のコマンドを使用して本番 VPS を確認し、設定を変更することなく検証しました。

  • リバースプロキシ: Caddy v2.11.4、公式 caddy:2.11.4 Docker イメージ

  • ホスト: Ubuntu、Linux カーネル 6.8.0-146-generic

  • ホストの MPTCP: net.mptcp.enabled = 1

  • コンテナの MPTCP: /proc/sys/net/mptcp/enabled = 1

  • Docker ネットワーク: caddy_default、ドライバー bridge、オプション {}

  • Go 環境: GODEBUG は未設定

  • 公開ポート: IPv4 および IPv6 で TCP 80、TCP 443、UDP 443

Discourse の nginx は Caddy の背後にあり、Caddy が公開用の HTTPS および HTTP/3 エンドポイントを提供しています。

これらの確認から、サーバーには MPTCP サポートの基本的な前提条件が整っていることが示唆されますが、Docker の公開ポート転送を介した実際の MPTCP ネゴシエーションは検証していません。

質問事項

  1. DiscourseHub: その iOS ネットワーキングは MPTCP を要求できるコンポーネントを使用しているのか、それともメインの Web コンテンツは、この機能を公開していないネットワーク API 経由で処理されているのか？

  2. Safari とインストールされた PWA: DiscourseHub、Safari、インストールされた iOS PWA を通じて Discourse にアクセスすることには違いがあるか？クライアントが明示的に MPTCP を要求する必要があるのか、それともこれらのアクセス方法のいずれかが透過的に恩恵を受けられるのか？

  3. Docker ネットワーキング: ブリッジ/NAT 設定は、初期の MPTCP ネゴシエーションおよび追加のサブフローを保持できるか、それともこれが原因で接続が通常の TCP にフォールバックしてしまう可能性があるか？

  4. HTTP/3 と MPTCP: HTTP/3 は TCP ではなく UDP 経由の QUIC を使用するため、ネットワーク切り替え時に QUIC の接続移行が同程度の継続性を提供するか？この状況において、MPTCP 経由の HTTP/2 と QUIC 経由の HTTP/3 の間に実用的な違いはあるか？

  5. Discourse 側のリカバリー: 基盤となるネットワークが変更された際に、中断されたリクエストを回復するための既存のメカニズムは、Discourse またはその iOS クライアントに存在するか？iOS クライアントが実際にどのトランスポートを使用しているかを特定する推奨方法はありますか？

Discourse 自体が複数のネットワークインターフェースを管理すべきだと提案しているわけではありません。iOS クライアント、トランスポートプロトコル、Docker/Caddy、Discourse の間で責任がどこにあるのか、そして活用できる既存の機能があるのかを理解しようとしています。

ご指摘や私の理解に対する訂正をいただければ幸いです。

ありがとうございます。