Discourse가 이미 http3를 지원하나요?
주요 네트워크 문제라는 점은 알고 있지만, 예를 들어 DigitalOcean에서 Discourse를 실행하는 경우, Discourse가 실행되는 Docker 컨테이너가 http3를 지원할 수 있어야 합니다.
모르겠지만, http3가 Discourse에 어떻게 도움이 될 수 있을까요?
현재는 지원하지 않습니다
2개의 좋아요
기술적으로 HTTP3는 HTTP 프로토콜의 또 다른 버전일 뿐입니다. 따라서 누군가가 현재 자신의 Discourse 인스턴스를 HTTP3로 제공하려면, HTTP3를 지원하는 별도의 리버스 HTTP 프록시를 Discourse 인스턴스 앞에 배치하면 됩니다. 이 작업은 discourse 도커 이미지를 변경하지 않아도 가능합니다.
여기서 일부 추측을 하고 있으므로 참고하시기 바랍니다. 도커 이미지 내부에서 Discourse의 리버스 프록시로 Nginx를 사용하고 있는 것으로 보입니다. Nginx는 HTTP3를 네이티브로 지원하지만, 현재 해당 구현은 실험적 단계로 간주되고 있습니다. 이것이 도커 이미지에서 HTTP3 지원이 아직 구현되지 않은 이유가 아닐까 싶습니다?
2개의 좋아요
네, 실험적 기능이지만 다른 사이트에서 진행한 테스트를 보면, 오늘 바로 http3를 선택하는 프로젝트에는 이미 충분히 안정적이라는 것을 알 수 있습니다.
http3 지원을 선택적 기능으로 추가할 수 있다면, 이 기능에 관심이 있는 프로젝트를 위해 제가 호스팅할 수 있는 Discourse의 Docker 유지보수자가 있을까요?
Discourse의 이점에 대해 알아볼 수 있는 아주 좋은 기사가 여기 있습니다: What Is HTTP/3 and How Does It Differ from HTTP/2? | Gcore
HTTP/3에 대한 일반적인 이해는 있으며, WordPress/LAMP 환경에서 왜 그리고 어떻게 유용한지도 알고 있지만, Discourse에서는 왜 차이가 나는지 이해가 되지 않습니다.
Http3은 서버와 클라이언트 간 연결을 설정할 때 지연 시간을 최대 150ms까지 줄여줍니다. 또한 HTTP 통신을 설정하는 것이 더 경제적이라 서버 리소스도 절약할 수 있습니다.
따라서 사용자는 더 나은 커뮤니티 경험을, 서버 운영자는 낮은 부하를 경험하게 됩니다. 서로에게 이로운 결과입니다.
아쉽게도 현재는 지원하지 않습니다.
저는 (메모를 확인해 보니) 2019년부터 컨테이너의 HTTP/3 대응을 위한 브랜치를 유지해 왔으며, GitHub - discourse/discourse_docker at http3 · GitHub 에서 확인할 수 있습니다.
이를 광범위하게 배포하지 않은 이유는 전체 생태계의 여러 문제들 때문입니다:
- Nginx 개발이 극도로 느려졌으며, HTTP/3이나 Early Hints와 같은 새로운 웹 기술을 따라가지 못하고 있습니다.
- Nginx의 모듈형 아키텍처 덕분에 모듈을 통해 추가할 수 있었으며, 제 브랜치는 이를 위해 Cloudflare의 nginx 모듈인 quiche를 사용합니다. 그러나 Cloudflare 역시 nginx에서 손을 뗐고, 해당 모듈은 프로덕션 레디(Production-ready)로 간주된 적이 없습니다.
- Caddy와 같이 더 현대적인 웹 서버로 마이그레이션을 고려해 보았지만, 사용자가 직접 커스터마이즈하는 셀프호스팅 소프트웨어를 배포하는 상황에서 이러한 변경은 매우 어렵습니다.
- HAProxy로의 전환은 더 수월할 수 있지만, 우리는 정적 파일 서빙에 nginx를 사용하는데 HAProxy는 이를 지원하지 않습니다.
- OpenSSL 유지보수자들이 기본적으로 QUIC를 방해하여 생태계 전체의 진전을 10년치만큼 중단시켰다는 사실입니다.
위 모든 사항과 TCP → UDP 전환에 수반되는 고유한 문제들로 인해, 우리는 이러한 변경을 감수하기에는 리스크가 너무 크다고 판단했습니다.
이는 매우 안타까운 일입니다. 지난 4년간 평균적인 가정에서 대부분의 트래픽이 이미 HTTP/3를 사용하는데, YouTube, Amazon, Shopify, Instagram, Twitch.tv 등 모든 대형 플레이어가 수년 전부터 이를 채택했기 때문입니다. 이는 빅테크와 소규모 사이트 간의 격차를 더욱 벌리게 만들며, 우리는 SPDY, HTTP/2, Brotli에서 그랬던 것처럼 초기 채택자가 될 수 없었던 점이 아쉬움으로 남습니다.
이 모든 점을 고려할 때, 이 복잡한 문제를 1클릭으로 해결하기 원하신다면 Cloudflare를 Discourse 인스턴스 앞에 배치하여 사용하실 수 있습니다.
12개의 좋아요
그 말을 듣자니 마음이 아픕니다. 몇 가지 아이디어를 검토해 볼 수 있을 것 같습니다. 함께 논의해 보시겠어요?
- Nginx에 모듈을 설치하는 것을 고려해 볼 수 있습니다. 예를 들어 http3를 지원하는 모듈 같은 것 말이죠.
- Caddy 커뮤니티에 작성자분이 운영하시는 Discourse를 기반으로 하고 있다는 점을 전달하고, Caddy로의 전환을 도와줄 수 있는지 문의해 보시는 것도 좋습니다. 서로에게 이로운 협력 관계가 될 수 있을 것 같습니다
QUIC is not supported - Help - Caddy Community
1개의 좋아요
이것을 구축하는 가장 깔끔한 방법이자, 최종적으로 배포할 수 있는 잠재력을 가진 방법은 web.ssl.template.yml의 대안으로 새로운 템플릿을 추가하는 것입니다. 이를 web.ssl2.template.yml이라고 부르겠습니다.
이 템플릿에서는 nginx를 수정하는 대신, Caddy와 같은 대체 웹 서버를 시작하여 모든 트래픽을 처리하고 nginx로 프록시합니다. 이를 통해 다양한 실험이 가능해지고, 여러 웹 서버를 테스트할 수 있으며, 궁극적으로는 신규 설치 시 기본값으로 설정할 수 있는 형태로 발전할 수 있습니다.
4개의 좋아요
훌륭하네요. 테스트에 참여하고 싶습니다. 다음 단계는 무엇인가요?
2개의 좋아요
작업을 수행하는 것입니다 
5개의 좋아요
또 다른 접근 방식은 Docker 이미지 내에 HTTP3 트래픽만 처리하도록 설계된 전용 HTTP 리버스 프록시를 추가하는 것입니다. 예를 들어, HTTP3 인그레스를 지원하는 Envoy Proxy를 임베드하고, h3 트래픽을 위해 443/udp 포트에서만 리스닝하도록 구성한 뒤, 모든 수신된 h3 요청을 h2 또는 h1.1로 변환하여 Nginx 인스턴스로 전달하는 방식이 있습니다.
다소 해킹적인 방법이라 좋은 아이디어라고는 말하지 않겠습니다.
2개의 좋아요
어떤 방향으로 진행하시든, http3은 좋은 한 걸음이라고 생각하며 전체 생태계에 도움이 될 것입니다. 다음 단계가 기대됩니다.
[공개: 저는 1월부터 OpenSSL 재단의 커뮤니티 매니저로 일하고 있습니다.]
사실상 OpenSSL 3.5는 4월에 QUIC 서버 지원과 함께 출시될 예정입니다. 또한 OpenSSL QUIC API를 nghttp3와 함께 사용하는 HTTP3 서버 데모도 있습니다.
(해당 링크에서 거버넌스 문제가 언급되었으므로, OpenSSL이 작년에 새로운 거버넌스 구조를 채택했다는 점을 지적할 필요가 있습니다. 저는 신중하게 낙관적이며, 이것이 마침내 QUIC을 출시하는 데 도움이 되었다고 생각합니다.)
nginx가 OpenSSL의 QUIC API를 채택할 것으로 보입니다. 그러나 아직 시간표에 대한 신호는 없습니다.
4개의 좋아요