Multipath TCP (MPTCP) per DiscourseHub e PWA di iOS Safari dietro Caddy

Supporto Installazione
, , , ,
1

Proseguo la discussione da Caddy davanti all’Nginx dell’app tramite Docker Compose:

Dopo la mia precedente discussione sull’esecuzione di Caddy davanti al container nginx di Discourse per fornire HTTP/3 e QUIC 0-RTT, sto esaminando una domanda separata ma correlata: se Multipath TCP (MPTCP) potrebbe migliorare la continuità della connessione per gli utenti iOS che passano tra reti Wi-Fi e cellulari.

Il mio lavoro precedente si concentrava principalmente sulle prestazioni di caricamento iniziale delle pagine. Questa domanda è diversa: accedo regolarmente al mio archivio privato di studio su Discourse mentre mi sposto tra diverse attività, e interruzioni della connessione o buffering possono ritardare l’accesso a informazioni importanti.

Perché sto facendo questa domanda

In alcune località, il Wi-Fi è affidabile mentre la ricezione cellulare è scarsa; altrove, la situazione è invertita.

Il normale passaggio di rete su iOS non ha sempre fornito la continuità di cui ho bisogno. Utilizzo già una tecnologia separata di bonding/failover di rete per la resilienza della connessione, ma sono interessato a capire se parte di quella continuità potrebbe essere ottenuta nativamente tra un client iOS e il mio server Discourse.

In particolare, sono interessato al passaggio di connessione (handover) ed all’evitare richieste bloccate, piuttosto che all’aggregazione della banda di due connessioni.

Cosa ho trovato finora

La documentazione di compatibilità MPTCP per Linux elenca Caddy v2.10.0 e versioni successive come supportanti MPTCP in modo predefinito, soggetto al supporto del sistema operativo.

La documentazione MPTCP di Apple descrive come le applicazioni possano aderire a MPTCP tramite URLSessionConfiguration.

Tuttavia, ho anche trovato una spiegazione nei forum Apple Developer che indica che WKWebView non espone un’opzione di configurazione MPTCP equivalente.

Questo mi lascia incerto su se DiscourseHub, Safari o una PWA iOS installata potrebbero beneficiare di MPTCP, in particolare quando è disponibile anche HTTP/3 su QUIC.

Ambiente server confermato

Ho verificato il VPS di produzione utilizzando comandi in sola lettura, senza modificarne la configurazione.

  • Reverse proxy: Caddy v2.11.4, immagine Docker ufficiale caddy:2.11.4

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

  • MPTCP Host: net.mptcp.enabled = 1

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

  • Rete Docker: caddy_default, driver bridge, opzioni {}

  • Ambiente Go: GODEBUG non impostato

  • Porte pubblicate: TCP 80, TCP 443 e UDP 443, su IPv4 e IPv6

L’nginx di Discourse rimane dietro Caddy, con Caddy che fornisce l’endpoint pubblico HTTPS e HTTP/3.

Questi controlli suggeriscono che il server abbia i prerequisiti di base per il supporto MPTCP, anche se non ho verificato la negoziazione MPTCP effettiva attraverso l’inoltro delle porte pubblicate di Docker.

Domande

  1. DiscourseHub: La sua rete iOS utilizza componenti in grado di richiedere MPTCP, o il suo contenuto web principale è gestito tramite API di rete che non espongono questa capacità?

  2. Safari e PWA installate: C’è qualche differenza tra l’accesso a Discourse tramite DiscourseHub, Safari e una PWA iOS installata? Il client deve richiedere esplicitamente MPTCP, o uno di questi metodi di accesso potrebbe beneficiarne in modo trasparente?

  3. Rete Docker: La configurazione bridge/NAT può preservare la negoziazione MPTCP iniziale e i subflussi aggiuntivi, o potrebbe causare il passaggio delle connessioni al normale TCP?

  4. HTTP/3 rispetto a MPTCP: Dato che HTTP/3 utilizza QUIC su UDP anziché TCP, la migrazione della connessione QUIC fornirebbe una continuità paragonabile quando si cambiano le reti? C’è una distinzione pratica tra HTTP/2 su MPTCP e HTTP/3 su QUIC in questa situazione?

  5. Recupero lato Discourse: Ci sono meccanismi esistenti in Discourse o nei suoi client iOS per recuperare le richieste interrotte quando la rete sottostante cambia? C’è un modo consigliato per stabilire quale trasporto sta effettivamente utilizzando un client iOS?

Non sto proponendo che Discourse stesso debba gestire più interfacce di rete. Sto cercando di capire dove risieda la responsabilità tra il client iOS, il protocollo di trasporto, Docker/Caddy e Discourse, e se ci siano capacità esistenti di cui potrei usufruire.

Sarei grato per qualsiasi indicazione o correzione alla mia comprensione.

Grazie!