Multipath TCP (MPTCP) pour DiscourseHub et PWA iOS Safari derrière Caddy

Soutien Installation
, , , ,
1

Poursuite de la discussion depuis Caddy devant le Nginx de l’application via Docker Compose :

Après ma discussion précédente sur l’exécution de Caddy devant le conteneur nginx de Discourse pour fournir HTTP/3 et QUIC 0-RTT, j’ai étudié une question distincte mais liée : si le Multipath TCP (MPTCP) pourrait améliorer la continuité de la connexion pour les utilisateurs iOS passant d’un réseau Wi-Fi à un réseau cellulaire.

Mon travail précédent portait principalement sur les performances de chargement initial des pages. Cette question est différente : j’accède régulièrement à mon archive privée d’études sur Discourse en me déplaçant entre différentes activités, et les connexions interrompues ou les mises en mémoire tampon peuvent retarder l’accès à des informations importantes.

Pourquoi je pose cette question

Dans certains endroits, le Wi-Fi est fiable tandis que la réception cellulaire est mauvaise ; ailleurs, la situation est inversée.

Le basculement réseau standard d’iOS n’a pas toujours fourni la continuité dont j’ai besoin. J’utilise déjà une technologie distincte de liaison/basculement de réseau (bonding/failover) pour la résilience de la connexion, mais je souhaite comprendre si une partie de cette continuité pourrait être obtenue de manière native entre un client iOS et mon serveur Discourse.

En particulier, je m’intéresse au transfert de connexion (handover) et à l’évitement des requêtes bloquées, plutôt qu’à l’agrégation de la bande passante de deux connexions.

Ce que j’ai trouvé jusqu’à présent

La documentation de compatibilité Linux MPTCP liste Caddy à partir de la version 2.10.0 comme prenant en charge MPTCP par défaut, sous réserve du support du système d’exploitation.

La documentation MPTCP d’Apple décrit comment les applications peuvent opter pour MPTCP via URLSessionConfiguration.

Cependant, j’ai également trouvé une explication sur les forums Apple Developer indiquant que WKWebView n’expose pas d’option de configuration MPTCP équivalente.

Cela me laisse incertain quant à savoir si DiscourseHub, Safari ou une PWA iOS installée pourraient bénéficier de MPTCP, en particulier lorsque HTTP/3 sur QUIC est également disponible.

Environnement serveur confirmé

J’ai vérifié le VPS de production à l’aide de commandes en lecture seule, sans modifier sa configuration.

  • Proxy inverse : Caddy v2.11.4, image Docker officielle caddy:2.11.4

  • Hôte : Ubuntu, noyau Linux 6.8.0-146-generic

  • MPTCP de l’hôte : net.mptcp.enabled = 1

  • MPTCP du conteneur : /proc/sys/net/mptcp/enabled = 1

  • Réseau Docker : caddy_default, pilote bridge, options {}

  • Environnement Go : GODEBUG non défini

  • Ports publiés : TCP 80, TCP 443 et UDP 443, sur IPv4 et IPv6

Le nginx de Discourse reste derrière Caddy, Caddy fournissant le point d’accès public HTTPS et HTTP/3.

Ces vérifications suggèrent que le serveur dispose des prérequis de base pour la prise en charge de MPTCP, bien que je n’aie pas vérifié la négociation MPTCP réelle à travers la redirection des ports publiés de Docker.

Questions

  1. DiscourseHub : Son réseau iOS utilise-t-il des composants capables de demander MPTCP, ou son contenu web principal est-il géré via des API réseau qui n’exposent pas cette capacité ?

  2. Safari et PWA installées : Existe-t-il une différence entre l’accès à Discourse via DiscourseHub, Safari et une PWA iOS installée ? Le client doit-il explicitement demander MPTCP, ou l’une de ces méthodes d’accès pourrait-elle en bénéficier de manière transparente ?

  3. Réseau Docker : La configuration bridge/NAT peut-elle préserver la négociation MPTCP initiale et les sous-flux supplémentaires, ou cela pourrait-il provoquer un retour à un TCP ordinaire ?

  4. HTTP/3 par rapport à MPTCP : Puisque HTTP/3 utilise QUIC sur UDP plutôt que TCP, la migration de connexion QUIC fournirait-elle une continuité comparable lors du changement de réseau ? Existe-t-il une distinction pratique entre HTTP/2 sur MPTCP et HTTP/3 sur QUIC dans cette situation ?

  5. Récupération côté Discourse : Existe-t-il des mécanismes existants dans Discourse ou ses clients iOS pour récupérer les requêtes interrompues lorsque le réseau sous-jacent change ? Existe-t-il une méthode recommandée pour déterminer quel transport un client iOS utilise réellement ?

Je ne propose pas que Discourse lui-même gère plusieurs interfaces réseau. J’essaie de comprendre où se situe la responsabilité entre le client iOS, le protocole de transport, Docker/Caddy et Discourse, et s’il existe des capacités existantes que je pourrais exploiter.

Je serais reconnaissant pour toute indication ou correction de ma compréhension.

Merci !