Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTTP/3 is everywhere but nowhere

httptoolkit.com

Post reply on HN
Print view View original

71–80 of 504 posts

Re: HTTP/3 is everywhere but nowhere

#71

Post by lemagedurage »

ralferoo wrote: post #47

For me, I think the biggest issue with large scale deployment of HTTP 3 is that it increases the surface area of potentially vulnerable code that needs to be kept patched and maintained. I'd far rather have the OS provide a verified safe socket layer, and a dynamically linked SSL library, that can be easily updated without any of the application layer needing to worry about security bugs in the networking layer. Addi…

A "few extra ms" is up to 3 roundtrips difference, that's easily noticeable by humans on cellular.

For all the CPU optimisations we're doing, cutting out a 50ms roundtrip for establishing a HTTP connection feels like a great area to optimize performance.

Re: HTTP/3 is everywhere but nowhere

#72

Post by cyanmagenta »

ralferoo wrote: post #47

For me, I think the biggest issue with large scale deployment of HTTP 3 is that it increases the surface area of potentially vulnerable code that needs to be kept patched and maintained. I'd far rather have the OS provide a verified safe socket layer, and a dynamically linked SSL library, that can be easily updated without any of the application layer needing to worry about security bugs in the networking layer. Addi…

> I'd far rather have the OS provide a verified safe socket layer

There is work going on right now[1] to implement the QUIC protocol in the linux kernel, which gets used in userspace via standard socket() APIs like you would with TCP. Of course, who knows if it’ll ultimately get merged in.

[1] https://github.com/lxin/quic

Re: HTTP/3 is everywhere but nowhere

#73

Post by xxs »

ralferoo wrote: post #47

For me, I think the biggest issue with large scale deployment of HTTP 3 is that it increases the surface area of potentially vulnerable code that needs to be kept patched and maintained. I'd far rather have the OS provide a verified safe socket layer, and a dynamically linked SSL library, that can be easily updated without any of the application layer needing to worry about security bugs in the networking layer. Addi…

>saving a few ms per request, or more likely just on the first request.

That's not given, either as UDP is normally not prioritized under congestion.

Re: HTTP/3 is everywhere but nowhere

#74

Post by bheadmaster »

CharlieDigital wrote: post #61
pjc50 wrote: post #55

Earlier quoted context omitted.

Are you sure? https://learn.microsoft.com/en-us/dotnet/core/deploying/nati... "Since there's no standardized way to obtain native macOS SDK for use on Windows/Linux, or Windows SDK for use on Linux/macOS, or a Linux SDK for use on Windows/macOS, Native AOT does not support cross-OS compilation. Cross-OS compilation with Native AOT requires some form of emulation, like a virtual machine or Windows WSL." Now, you don't…

> Native AOT does not support cross-OS compilation > ...runtime-dependent and self-contained are fine This certainly reads like you moved the goal posts and recognized it.

Native AOT compilation is definitely not the same as self-contained package. With that logic, every Docker container could be considered AOT compiled static executable.

Re: HTTP/3 is everywhere but nowhere

#75

Post by lemagedurage »

dubcanada wrote: post #68
huijzer wrote: post #65

Very interesting. The article states that > Really it's hard to point to any popular open-source tools that fully support HTTP/3: rollout has barely even started. But isn’t Caddy a widely used reverse proxy with HTTP/3 support? Or what features are missing?

I don't think I'd call Caddy "widely used" it is used, but nowhere near nginx, apache, haproxy, squid, etc.

Make sense. Nowadays, for a new project, I would like to use Caddy where I would otherwise use Apache or nginx, but I would be even more inclined to use a cloud provider's load balancer.

Re: HTTP/3 is everywhere but nowhere

#76

Post by lemagedurage »

dadrian wrote: post #50

It's not clear to me that HTTP/3 is relevant to anyone who isn't already using it. It's most useful for large-scale hosting providers and video. And these people have already adopted it, and don't necessarily use out-of-the-box web servers for their infrastructure.

Small websites gain from reducing roundtrips on connection too. Fast websites are nice

Re: HTTP/3 is everywhere but nowhere

#77

Post by eptcyka »

cyanmagenta wrote: post #72
ralferoo wrote: post #47

For me, I think the biggest issue with large scale deployment of HTTP 3 is that it increases the surface area of potentially vulnerable code that needs to be kept patched and maintained. I'd far rather have the OS provide a verified safe socket layer, and a dynamically linked SSL library, that can be easily updated without any of the application layer needing to worry about security bugs in the networking layer. Addi…

> I'd far rather have the OS provide a verified safe socket layer There is work going on right now[1] to implement the QUIC protocol in the linux kernel, which gets used in userspace via standard socket() APIs like you would with TCP. Of course, who knows if it’ll ultimately get merged in. [1] https://github.com/lxin/quic

Yea, but does the kernel then also do certificate validation for you? Will you pin certs via setsockopt? I think QUIC and TLS are wide enough attack surfaces to warrant isolation from the kernel.

Re: HTTP/3 is everywhere but nowhere

#78

Post by eptcyka »

xxs wrote: post #73
ralferoo wrote: post #47

For me, I think the biggest issue with large scale deployment of HTTP 3 is that it increases the surface area of potentially vulnerable code that needs to be kept patched and maintained. I'd far rather have the OS provide a verified safe socket layer, and a dynamically linked SSL library, that can be easily updated without any of the application layer needing to worry about security bugs in the networking layer. Addi…

>saving a few ms per request, or more likely just on the first request. That's not given, either as UDP is normally not prioritized under congestion.

But that will change, as more and more clients will rely on UDP on port 443.

Re: HTTP/3 is everywhere but nowhere

#79

Post by hubabuba44 »

ralferoo wrote: post #47

For me, I think the biggest issue with large scale deployment of HTTP 3 is that it increases the surface area of potentially vulnerable code that needs to be kept patched and maintained. I'd far rather have the OS provide a verified safe socket layer, and a dynamically linked SSL library, that can be easily updated without any of the application layer needing to worry about security bugs in the networking layer. Addi…

If the initial tcp 3 way handshake fails it can be quite a bit longer you would have to wait than a few ms. Depending on OS it is a second or more.

Re: HTTP/3 is everywhere but nowhere

#80

Post by surajrmal »

hylaride wrote: post #36
artyom wrote: post #10

Every single project mentioned in the article is to some extent either open source and/or community driven. So nobody considered HTTP/3 interesting enough to rush and add support for it very quickly. It'll get there, but fast? I don't think so, see IPv6. Also, nobody considered HTTP/3 worth enough of paying for maintainers to add support for it.

99% of the benefit of HTTP/3 is on distributed web serving where clients are connecting to multiple remote ends on a web page (which lets be honest, is mostly used for serving ads faster). Why would the open source community prioritize this?

The open source community is full of companies who make money from things like ads.
Post reply on HN