다음은 Caddy in front of app’s Nginx via Docker Compose 토론의 이어서입니다:
이전에 Discourse의 nginx 컨테이너 앞에 Caddy를 실행하여 HTTP/3와 QUIC 0-RTT를 제공하기 위한 논의를 진행한 바 있습니다. 이번에는 이와 관련이 있지만 별개의 질문을 조사해 보고 있습니다. 즉, Wi-Fi와 셀룰러 네트워크 간에 이동하는 iOS 사용자의 연결 연속성을 개선하기 위해 Multipath TCP(MPTCP)가 도움이 될 수 있는가 하는 것입니다.
이전 작업은 주로 초기 페이지 로딩 성능에 초점을 맞추었습니다. 이번 질문은 다릅니다. 저는 다양한 활동을 전환하면서 개인 Discourse 학습 아카이브에 정기적으로 접근하는데, 연결이 끊기거나 버퍼링이 발생하면 중요한 정보에 접근하는 데 지연이 생길 수 있습니다.
질문 배경
일부 장소에서는 Wi-Fi가 안정적이지만 셀룰러 수신 상태가 나쁘고, 다른 장소에서는 그 반대인 경우가 있습니다.
일반적인 iOS 네트워크 전환은 항상 제가 필요한 수준의 연속성을 제공하지는 못했습니다. 저는 이미 연결 회복력을 위해 별도의 네트워크 본딩/페일오버 기술을 사용하고 있지만, iOS 클라이언트와 제 Discourse 서버 간에 이러한 연속성의 일부가 네이티브로 달성될 수 있는지 이해하는 데 관심이 있습니다.
특히 대역폭을 두 개의 연결로 합산하는 것보다는, 연결 핸드오버와 요청 정체를 피하는 것에 관심이 있습니다.
지금까지 발견한 내용
Linux MPTCP 호환성 문서에 따르면, 운영체제 지원 여부에 따라 Caddy v2.10.0 이후 버전은 기본적으로 MPTCP를 지원합니다.
Apple의 MPTCP 문서는 애플리케이션이 URLSessionConfiguration을 통해 MPTCP를 선택적으로 사용할 수 있는 방법을 설명합니다.
그러나 Apple Developer Forums의 설명에서 WKWebView는 동등한 MPTCP 구성 옵션을 노출하지 않는다는 점을 발견했습니다.
이로 인해 HTTP/3 over QUIC가 사용 가능한 경우에도 DiscourseHub, Safari 또는 설치된 iOS PWA가 MPTCP의 혜택을 받을 수 있는지 불확실합니다.
확인된 서버 환경
읽기 전용 명령을 사용하여 프로덕션 VPS를 확인했으며, 구성은 변경하지 않았습니다.
-
리버스 프록시: Caddy v2.11.4, 공식
caddy:2.11.4Docker 이미지 -
호스트: 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미설정 -
게시된 포트: IPv4 및 IPv6에서 TCP 80, TCP 443, UDP 443
Discourse의 nginx는 Caddy 뒤에 위치하며, Caddy가 공개 HTTPS 및 HTTP/3 엔드포인트를 제공합니다.
이러한 확인 결과 서버에는 MPTCP 지원의 기본 전제 조건이 갖춰져 있는 것으로 보이지만, Docker의 게시 포트 포워딩을 통한 실제 MPTCP 협상이 검증되지는 않았습니다.
질문
-
DiscourseHub: iOS 네트워킹이 MPTCP를 요청할 수 있는 구성 요소를 사용합니까, 아니면 주요 웹 콘텐츠가 이 기능을 노출하지 않는 네트워킹 API를 통해 처리됩니까?
-
Safari 및 설치된 PWA: Discourse에 DiscourseHub, Safari, 설치된 iOS PWA를 통해 접근하는 것 사이에 차이가 있습니까? 클라이언트가 MPTCP를 명시적으로 요청해야 하는지, 아니면 이러한 접근 방식 중 어떤 것이 투명하게 혜택을 받을 수 있는지 궁금합니다.
-
Docker 네트워킹: 브리지/NAT 구성이 초기 MPTCP 협상 및 추가 서브플로우를 유지할 수 있습니까, 아니면 이것이 연결을 일반 TCP로 되돌리게 할 수 있습니까?
-
HTTP/3 대 MPTCP: HTTP/3가 UDP 기반의 QUIC를 사용하므로, 네트워크 전환 시 QUIC 연결 마이그레이션이 동등한 수준의 연속성을 제공할 수 있습니까? 이 상황에서 MPTCP 기반 HTTP/2와 QUIC 기반 HTTP/3 사이에 실질적인 차이가 있습니까?
-
Discourse 측 복구: 기본 네트워크가 변경될 때 중단된 요청을 복구하기 위한 Discourse 또는 iOS 클라이언트 내 기존 메커니즘이 있습니까? iOS 클라이언트가 실제로 어떤 전송 프로토콜을 사용 중인지 확인하는 권장 방법이 있습니까?
Discourse 자체가 여러 네트워크 인터페이스를 관리해야 한다고 제안하는 것이 아닙니다. iOS 클라이언트, 전송 프로토콜, Docker/Caddy, Discourse 간에 책임이 어디에 있는지, 그리고 활용할 수 있는 기존 기능이 있는지 이해하려고 노력하고 있습니다.
제 이해에 대한 지적이나 교정해 주시면 감사하겠습니다.
감사합니다!