DiscourseHub 和 iOS Safari PWA 在 Caddy 后端的 Multipath TCP (MPTCP)

支持 安装
, , , ,
1

继续之前关于 通过 Docker Compose 在应用的 Nginx 前部署 Caddy 的讨论：

在我之前关于在 Discourse 的 nginx 容器前运行 Caddy 以提供 HTTP/3 和 QUIC 0-RTT 的讨论之后，我一直在研究一个相关但独立的问题：多路径 TCP (MPTCP) 是否能在 iOS 用户在 Wi-Fi 和蜂窝网络之间切换时改善连接的连续性。

我之前的工作主要关注初始页面加载性能。而这个问题有所不同：我经常在移动中访问我的私人 Discourse 学习存档，连接中断或缓冲会延迟我获取重要信息。

我为什么提出这个问题

在某些地点，Wi-Fi 很稳定但蜂窝信号很差；而在其他地方，情况则相反。

普通的 iOS 网络切换并不总能提供我所需要的连续性。我已经使用独立的网络绑定/故障转移技术来增强连接韧性，但我感兴趣的是，是否可以在 iOS 客户端和我的 Discourse 服务器之间原生地实现部分这种连续性。

具体来说，我关注的是连接切换（handover）和避免请求停滞，而不一定是要聚合两个连接的带宽。

我目前的发现

Linux MPTCP 兼容性文档 列出了 Caddy v2.10.0 及更高版本默认支持 MPTCP，具体取决于操作系统的支持情况。

Apple 的 MPTCP 文档 描述了应用程序如何通过 URLSessionConfiguration 选择加入 MPTCP。

然而，我也找到了一个 Apple 开发者论坛的解释，指出 WKWebView 没有暴露等效的 MPTCP 配置选项。

这让我对 DiscourseHub、Safari 或已安装的 iOS PWA 是否能从 MPTCP 中受益感到不确定，尤其是在同时提供基于 QUIC 的 HTTP/3 的情况下。

已确认的服务器环境

我使用只读命令检查了生产 VPS，未修改其配置。

  • 反向代理： Caddy v2.11.4，官方 caddy:2.11.4 Docker 镜像

  • 主机： 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 上

Discourse 的 nginx 仍然位于 Caddy 之后，由 Caddy 提供公共的 HTTPS 和 HTTP/3 端点。

这些检查表明服务器具备 MPTCP 支持的基本前提条件，尽管我尚未通过 Docker 的发布端口转发验证实际的 MPTCP 协商。

问题

  1. DiscourseHub： 其 iOS 网络功能是否使用了能够请求 MPTCP 的组件，还是其主要网页内容通过不暴露此功能的网络 API 处理？

  2. Safari 和已安装的 PWA： 通过 DiscourseHub、Safari 和已安装的 iOS PWA 访问 Discourse 之间是否有区别？客户端是否必须显式请求 MPTCP，还是这些访问方式中的任何一种都可以透明地受益？

  3. Docker 网络： bridge/NAT 配置能否保留初始的 MPTCP 协商和额外的子流（subflows），还是这会导致连接回退到普通 TCP？

  4. HTTP/3 与 MPTCP： 由于 HTTP/3 使用基于 UDP 的 QUIC 而不是 TCP，当切换网络时，QUIC 连接迁移是否能提供类似的连续性？在这种情况下，基于 MPTCP 的 HTTP/2 和基于 QUIC 的 HTTP/3 之间是否有实际区别？

  5. Discourse 端恢复： Discourse 或其 iOS 客户端中是否存在现有机制，用于在底层网络变化时恢复中断的请求？是否有推荐的方法来确定 iOS 客户端实际使用的传输层？

我并不是建议 Discourse 本身应该管理多个网络接口。我试图理解责任在 iOS 客户端、传输协议、Docker/Caddy 和 Discourse 之间是如何分配的，以及是否有我可以利用的现有功能。

对于任何指引或对我理解的纠正，我将不胜感激。

谢谢！