Enable HTTP/3 by default

[ghassanmas]

Is your feature request related to a problem? Please describe.

From caddy version 2.6 it allows/uses http3 by default, which was experimental.
To utilize http3, docker compose would need to bind to udp, given the http3/quic new protocal is built on top of UDP¹.

Describe the solution you'd like
Expected code change to allow such feature

tutor/tutor/templates/local/docker-compose.prod.yml

Lines 7 to 9 in 545d0f5

	ports:
	- "{{ CADDY_HTTP_PORT }}:80"
	{% if ENABLE_HTTPS and ENABLE_WEB_PROXY %}- "443:443"{% endif %}

 ports: 
   - "{{ CADDY_HTTP_PORT }}:80" 
   {% if ENABLE_HTTPS and ENABLE_WEB_PROXY %}- "443:443"{% endif %} 
   {% if ENABLE_HTTPS and ENABLE_WEB_PROXY %}- "443:443/udp"{% endif %} 

Which shall be rendered to assuming https is enabeld:

 ports: 
   - "80:80" 
   -"443:443"
   -"443:443/udp"

Describe alternatives you've considered

• Add a patch to be able to overide, caddy service prots section.

Additional context

• Caddy doc
• Why need to bind udp with docker compose; caddy forum
• The advantge of http3; http3 is fast
• Why QUIC by the author of curl
• https://domsignal.com/http3-test to test if a site support http3; https://palm.demo.overhang.io/ didn't pass

Footnotes

1. https://en.wikipedia.org/wiki/HTTP/3 ↩

[regisb]

Hi @ghassanmas! From a theoretical perspective, I understand the point of supporting http3. But what I do not know is the actual performance benefit that it will bring to Open edX. Did you run some tests to benchmark the impact?

[regisb]

Initial tests using Google's PageSpeed Insights show significant improvements with http/3.

Without http/3 (current implementation):

With http/3:

In particular, total blocking time is reduced by 55% (510 -> 230 ms), so this is pretty big.

Based on these figures, I agree with you that we should support http/3. But we will need to add support to Kubernetes as well, and we will need to add instructions for end users to make the most use of it.

[ghassanmas]

@regisb for your previous question, I think you were faster than me in doing plain tests ;), and for why we should enable HTTP/3, another point is that for IETF, HTTP/3 standard holds same status as for HTTP/2 which is proposed standrad.

• HTTP/2 RFC 9113 https://datatracker.ietf.org/doc/html/rfc9113
• HTTP/3 RFC 9114 https://datatracker.ietf.org/doc/html/rfc9114

Regarding meaning of proposed standard:

A Proposed Standard specification is generally stable, has resolved
known design choices, is believed to be well-understood, has received
significant community review, and appears to enjoy enough community
interest to be considered valuable. However, further experience
might result in a change or even retraction of the specification
before it advances. ref ¹

So my thinking was if we support HTTP/2 by default, then logically we shall support HTTP/3 assuming we follow the IETF criteria.

But we will need to add support to Kubernetes

I think probably it would need to add extra port for caddy options, where the protocol is specified, to my qick investagation k8s as well use TCP protocol by deafult², so propaly a new port entry for 443 while speciing the protocol is needed. Though I haven't tested this, nor do I have a matrue expirence in regard of tutor/k8s.

we will need to add instructions for end users to make the most use of it

Thinking about this, I think this would be relevant for people who won't be using the default deployment options for tutor, of which I can think of two main scinarios:

1. Running behind web proxy ref https://docs.tutor.overhang.io/tutorials/proxy.html
2. Using different k8s template for caddy than the default tutor/templates/k8s/deployments.yml

For the 1. I think it would depend which proxy server opreator would choose (caddy, nginx, apache..etc). i think http/3 is not supported using the deafult config for the latter as is the case of caddy. Nginx offcial doc recommend rebuilding the binary,³ Other than that, for nginx, there seems to be an nginx module built by cloudflare to support it ⁴.

For 2, I think I might not be in a good position to determine what/how, but I think if typically opreators use ingress for nginx, then probably the above note is relevant. For spefically ingress-nginx I found there is stalled issue here

• [FEATURE REQUEST] HTTP/3 support kubernetes/ingress-nginx#4760

Footnotes

1. RFC 2026 The Internet Standards Process https://datatracker.ietf.org/doc/html/rfc2026#section-4.1.1 ↩

2. Protocols for Services K8s docs https://kubernetes.io/docs/reference/networking/service-protocols/ ↩

3. Nginx support of HTTP/3 https://www.nginx.com/blog/our-roadmap-quic-http-3-support-nginx/ ↩

4. Cloudflare Nginx module for quic/http/3 https:/cloudflare/quiche/tree/master/nginx ↩