Multipath TCP (MPTCP) para DiscourseHub e PWA do Safari iOS atrás do Caddy

Suporte Instalação
, , , ,
1

Continuando a discussão de Caddy na frente do Nginx do app via Docker Compose:

Após minha discussão anterior sobre a execução do Caddy na frente do contêiner nginx do Discourse para fornecer HTTP/3 e QUIC 0-RTT, tenho investigado uma pergunta separada, mas relacionada: se o Multipath TCP (MPTCP) poderia melhorar a continuidade da conexão para usuários do iOS que alternam entre redes Wi-Fi e celulares.

Meu trabalho anterior estava principalmente preocupado com o desempenho inicial de carregamento de páginas. Esta pergunta é diferente: acesso regularmente meu arquivo de estudo privado do Discourse enquanto me movo entre atividades, e conexões interrompidas ou buffering podem atrasar o acesso a informações importantes.

Por que estou perguntando

Em alguns locais, o Wi-Fi é confiável, mas a recepção celular é ruim; em outros, a situação é invertida.

A comutação de rede comum do iOS nem sempre forneceu a continuidade de que preciso. Já uso tecnologia separada de bonding/failover de rede para resiliência de conexão, mas estou interessado em entender se parte dessa continuidade poderia ser alcançada nativamente entre um cliente iOS e meu servidor Discourse.

Em particular, estou interessado na transferência de conexão (handover) e em evitar solicitações travadas, em vez de necessariamente agregar a largura de banda de duas conexões.

O que encontrei até agora

A documentação de compatibilidade do MPTCP para Linux lista o Caddy v2.10.0 em diante como suportando MPTCP por padrão, sujeito ao suporte do sistema operacional.

A documentação do MPTCP da Apple descreve como as aplicações podem optar pelo MPTCP através de URLSessionConfiguration.

No entanto, também encontrei uma explicação nos Fóruns de Desenvolvedores da Apple indicando que o WKWebView não expõe uma opção de configuração equivalente para MPTCP.

Isso me deixa incerto sobre se o DiscourseHub, o Safari ou um PWA iOS instalado poderiam se beneficiar do MPTCP, particularmente quando o HTTP/3 sobre QUIC também está disponível.

Ambiente de servidor confirmado

Verifiquei o VPS de produção usando comandos somente leitura, sem modificar sua configuração.

  • Proxy reverso: Caddy v2.11.4, imagem Docker oficial caddy:2.11.4

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

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

  • MPTCP do Contêiner: /proc/sys/net/mptcp/enabled = 1

  • Rede Docker: caddy_default, driver bridge, opções {}

  • Ambiente Go: GODEBUG não definido

  • Portas publicadas: TCP 80, TCP 443 e UDP 443, em IPv4 e IPv6

O nginx do Discourse permanece atrás do Caddy, com o Caddy fornecendo o endpoint público HTTPS e HTTP/3.

Essas verificações sugerem que o servidor tem os pré-requisitos básicos para suporte a MPTCP, embora eu não tenha verificado a negociação real de MPTCP através do encaminhamento de portas publicadas do Docker.

Perguntas

  1. DiscourseHub: Sua rede iOS usa componentes capazes de solicitar MPTCP, ou seu conteúdo web principal é tratado através de APIs de rede que não expõem essa capacidade?

  2. Safari e PWAs instalados: Existe alguma diferença entre acessar o Discourse através do DiscourseHub, do Safari e de um PWA iOS instalado? O cliente precisa solicitar explicitamente o MPTCP, ou algum desses métodos de acesso poderia se beneficiar transparentemente?

  3. Rede Docker: A configuração bridge/NAT pode preservar a negociação inicial de MPTCP e fluxos subadicionais, ou isso poderia causar que as conexões recuem para TCP comum?

  4. HTTP/3 versus MPTCP: Como o HTTP/3 usa QUIC sobre UDP em vez de TCP, a migração de conexão QUIC forneceria alguma continuidade comparável ao alternar redes? Há uma distinção prática entre HTTP/2 sobre MPTCP e HTTP/3 sobre QUIC nesta situação?

  5. Recuperação no lado do Discourse: Existem mecanismos existentes no Discourse ou em seus clientes iOS para recuperar solicitações interrompidas quando a rede subjacente muda? Existe uma maneira recomendada de estabelecer qual transporte um cliente iOS está realmente usando?

Não estou propondo que o próprio Discourse gerencie múltiplas interfaces de rede. Estou tentando entender onde reside a responsabilidade entre o cliente iOS, o protocolo de transporte, o Docker/Caddy e o Discourse, e se há capacidades existentes que eu poderia aproveitar.

Agradeceria por qualquer orientação ou correção ao meu entendimento.

Obrigado!