Multipath TCP (MPTCP) для DiscourseHub и PWA в iOS Safari за Caddy

Поддержка Самостоятельное хостинг
, , , ,
1

Продолжение обсуждения из Caddy перед Nginx приложения через Docker Compose:

После моего предыдущего обсуждения о запуске Caddy перед контейнером nginx Discourse для обеспечения HTTP/3 и QUIC 0-RTT, я занимаюсь отдельным, но связанным вопросом: может ли Multipath TCP (MPTCP) улучшить непрерывность соединения для пользователей iOS, переключающихся между Wi-Fi и сотовой сетью.

Моя предыдущая работа была в основном посвящена производительности начальной загрузки страницы. Этот вопрос иной: я регулярно обращаюсь к моему частному архиву исследований на Discourse, перемещаясь между различными местами, и прерывания соединения или буферизация могут задерживать доступ к важной информации.

Почему я задаю этот вопрос

В некоторых местах Wi-Fi работает стабильно, а прием сотовой связи плохой; в других — ситуация обратная.

Обычное переключение сетей в iOS не всегда обеспечивает необходимую мне непрерывность. Я уже использую отдельные технологии связывания/резервирования сетей (bonding/failover) для устойчивости соединения, но мне интересно понять, можно ли достичь части этой непрерывности нативно между клиентом iOS и моим сервером Discourse.

В частности, меня интересует передача соединения (handover) и избегание зависших запросов, а не обязательно агрегация пропускной способности двух соединений.

Что я выяснил пока

Документация о совместимости Linux MPTCP указывает, что Caddy версии 2.10.0 и выше поддерживает MPTCP по умолчанию, при условии поддержки со стороны операционной системы.

Документация Apple по MPTCP описывает, как приложения могут подключить MPTCP через URLSessionConfiguration.

Однако я также нашел объяснение на форумах разработчиков Apple, согласно которому WKWebView не предоставляет аналогичного параметра конфигурации MPTCP.

Это оставляет меня в неопределенности относительно того, смогут ли DiscourseHub, Safari или установленное iOS PWA воспользоваться преимуществами MPTCP, особенно когда также доступно HTTP/3 поверх QUIC.

Подтвержденная серверная среда

Я проверил производственный VPS с помощью команд только для чтения, не изменяя его конфигурацию.

  • Обратный прокси: Caddy v2.11.4, официальный Docker-образ caddy:2.11.4

  • Хост: 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 не установлен

  • Опубликованные порты: TCP 80, TCP 443 и UDP 443, по IPv4 и IPv6

Nginx Discourse остается за Caddy, при этом Caddy предоставляет публичные точки доступа HTTPS и HTTP/3.

Эти проверки свидетельствуют о том, что сервер имеет базовые предпосылки для поддержки MPTCP, хотя я не проверял фактическое согласование MPTCP через проброс портов Docker.

Вопросы

  1. DiscourseHub: Использует ли его сетевой стек для iOS компоненты, способные запрашивать MPTCP, или его основное веб-содержимое обрабатывается через сетевые API, которые не предоставляют такую возможность?

  2. Safari и установленные PWA: Есть ли какая-либо разница между доступом к Discourse через DiscourseHub, Safari и установленное iOS PWA? Должен ли клиент явно запрашивать MPTCP, или любой из этих способов доступа может получить от этого пользу прозрачным образом?

  3. Сетевая инфраструктура Docker: Может ли конфигурация bridge/NAT сохранить начальное согласование MPTCP и дополнительные подпотоки (subflows), или это может привести к откату соединений на обычный TCP?

  4. HTTP/3 против MPTCP: Поскольку HTTP/3 использует QUIC поверх UDP, а не TCP, обеспечит ли миграция соединения QUIC сопоставимую непрерывность при переключении сетей? Существует ли практическая разница между HTTP/2 поверх MPTCP и HTTP/3 поверх QUIC в этой ситуации?

  5. Восстановление на стороне Discourse: Существуют ли в Discourse или его iOS-клиентах механизмы для восстановления прерванных запросов при изменении базовой сети? Есть ли рекомендуемый способ установить, какой транспорт фактически использует iOS-клиент?

Я не предлагаю, чтобы сам Discourse управлял несколькими сетевыми интерфейсами. Я пытаюсь понять, где проходит граница ответственности между iOS-клиентом, транспортным протоколом, Docker/Caddy и Discourse, и есть ли существующие возможности, которыми я мог бы воспользоваться.

Буду благодарен за любые подсказки или исправления моего понимания.

Спасибо!