Multipath TCP (MPTCP) für DiscourseHub und iOS-Safari-PWA hinter Caddy

Unterstützung Installation
, , , ,
1

Fortsetzung der Diskussion aus Caddy vor der Nginx-Instanz der App via Docker Compose:

Nach meiner früheren Diskussion darüber, Caddy vor dem nginx-Container von Discourse zu betreiben, um HTTP/3 und QUIC 0-RTT bereitzustellen, habe ich mich mit einer separaten, aber verwandten Frage beschäftigt: Ob Multipath TCP (MPTCP) die Verbindungsstetigkeit für iOS-Nutzer verbessern könnte, die zwischen WLAN und Mobilfunknetz wechseln.

Meine früheren Arbeiten befassten sich hauptsächlich mit der Ladezeit der ersten Seite. Diese Frage ist anders: Ich greife regelmäßig auf mein privates Discourse-Studienarchiv zu, während ich mich zwischen verschiedenen Aktivitäten bewege, und unterbrochene Verbindungen oder Pufferungen können den Zugriff auf wichtige Informationen verzögern.

Warum ich frage

An einigen Orten ist das WLAN zuverlässig, während der Mobilfunkempfang schlecht ist; andersherum ist die Situation umgekehrt.

Das gewöhnliche Netzwerk-Switching von iOS hat nicht immer die Stetigkeit bereitgestellt, die ich benötige. Ich nutze bereits separate Netzwerk-Bonding-/Failover-Technologien für Verbindungsresilienz, bin aber daran interessiert zu verstehen, ob ein Teil dieser Stetigkeit nativ zwischen einem iOS-Client und meinem Discourse-Server erzielt werden könnte.

Insbesondere interessiert mich das Handover von Verbindungen und das Vermeiden von stockenden Anfragen, nicht unbedingt die Aggregation der Bandbreite zweier Verbindungen.

Was ich bisher herausgefunden habe

Die Linux-MPTCP-Kompatibilitätsdokumentation listet Caddy ab Version 2.10.0 als standardmäßig MPTCP-fähig auf, vorbehaltlich der Betriebssystemunterstützung.

Die MPTCP-Dokumentation von Apple beschreibt, wie Anwendungen über URLSessionConfiguration in MPTCP einsteigen können.

Allerdings habe ich auch eine Erklärung im Apple Developer Forum gefunden, die darauf hinweist, dass WKWebView keine äquivalente MPTCP-Konfigurationsoption bereitstellt.

Dies lässt mich unsicher, ob DiscourseHub, Safari oder eine installierte iOS-PWA von MPTCP profitieren könnten, insbesondere wenn auch HTTP/3 über QUIC verfügbar ist.

Bestätigte Serverumgebung

Ich habe den Produktions-VPS mit schreibgeschützten Befehlen überprüft, ohne seine Konfiguration zu ändern.

  • Reverse Proxy: Caddy v2.11.4, offizielles caddy:2.11.4 Docker-Image

  • Host: Ubuntu, Linux-Kernel 6.8.0-146-generic

  • Host-MPTCP: net.mptcp.enabled = 1

  • Container-MPTCP: /proc/sys/net/mptcp/enabled = 1

  • Docker-Netzwerk: caddy_default, Driver bridge, Optionen {}

  • Go-Umgebung: GODEBUG nicht gesetzt

  • Veröffentlichte Ports: TCP 80, TCP 443 und UDP 443, auf IPv4 und IPv6

Das nginx von Discourse bleibt hinter Caddy, wobei Caddy den öffentlichen HTTPS- und HTTP/3-Endpunkt bereitstellt.

Diese Prüfungen deuten darauf hin, dass der Server die grundlegenden Voraussetzungen für die MPTCP-Unterstützung erfüllt, obwohl ich die tatsächliche MPTCP-Verhandlung über die Port-Weiterleitung von Docker nicht verifiziert habe.

Fragen

  1. DiscourseHub: Verwendet sein iOS-Netzwerk Komponenten, die in der Lage sind, MPTCP anzufordern, oder wird der Hauptwebinhalt über Netzwerk-APIs verarbeitet, die diese Fähigkeit nicht offenlegen?

  2. Safari und installierte PWAs: Gibt es einen Unterschied zwischen dem Zugriff auf Discourse über DiscourseHub, Safari und eine installierte iOS-PWA? Muss der Client MPTCP explizit anfordern, oder könnte einer dieser Zugriffsmethoden transparent davon profitieren?

  3. Docker-Netzwerk: Kann die Bridge-/NAT-Konfiguration die anfängliche MPTCP-Verhandlung und zusätzliche Subflows beibehalten, oder könnte dies dazu führen, dass Verbindungen auf gewöhnliches TCP zurückfallen?

  4. HTTP/3 versus MPTCP: Da HTTP/3 QUIC über UDP anstelle von TCP verwendet, würde QUIC-Connection-Migration bei Netzwerkwechseln vergleichbare Stetigkeit bereitstellen? Gibt es in dieser Situation einen praktischen Unterschied zwischen HTTP/2 über MPTCP und HTTP/3 über QUIC?

  5. Wiederherstellung auf der Discourse-Seite: Gibt es bestehende Mechanismen in Discourse oder seinen iOS-Clients, um unterbrochene Anfragen wiederherzustellen, wenn sich das zugrunde liegende Netzwerk ändert? Gibt es eine empfohlene Methode, um festzustellen, welchen Transport ein iOS-Client tatsächlich verwendet?

Ich schlage nicht vor, dass Discourse selbst mehrere Netzwerkinterfaces verwalten sollte. Ich versuche zu verstehen, wo die Verantwortung zwischen dem iOS-Client, dem Transportprotokoll, Docker/Caddy und Discourse liegt und ob es bestehende Fähigkeiten gibt, die ich nutzen könnte.

Ich wäre für jeden Hinweis oder jede Korrektur meines Verständnisses dankbar.

Danke!