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

Some notes about HTTP/3

blog.erratasec.com

Post reply on HN
Print view View original

81–90 of 181 posts

Re: Some notes about HTTP/3

#81

Post by the8472 »

ris wrote: post #80
nly wrote: post #65

I hope we get in-kernel implementations of QUIC at some point because having to find a portable third-party library for userspace sounds about as appealing as installing Winsock on Windows 95.

But the whole point of QUIC is that it is a userspace implementation. From the QUIC viewpoint (and I take no sides in this) kernel implementation is death for a protocol because it freezes its specification and behaviour in slow-to-update systems. This is why they found they couldn't "just improve TCP".

There have been plenty of improvements to TCP over time. New congestion controllers, new extension headers, fast open, ECN, etc.

Re: Some notes about HTTP/3

#82

Post by detaro »

popee wrote: post #20

> Their second upgrade they called QUIC (pronounced "quick"), which is being standardized as HTTP/3. Isn't QUIC new transport layer protocol based on UDP and, if I remember correctly, HTTP/3 will be HTTP bindings for QUIC? You might think this is nitpicking, but HTTP is application layer protocol, so it's little bit confusing to me.

Google didn't make the distinction between transport layer and HTTP-layer on top when they called their development "QUIC", it was one thing. IETF decided to split these during the standardization.

Re: Some notes about HTTP/3

#83

Post by tyingq »

jandrese wrote: post #77
tyingq wrote: post #21

Earlier quoted context omitted.

You can tweak rto_min per route, with ip route.

For a webserver won't that just be the default route most of the time? It's effectively a systemwide tune at that point.

The shorter timeout would likely be for downstream app servers in the same datacenter, not for the general internet. That is, adding a route for a specific network not because the default route doesn't work, but for tuning that setting only for that network.

Re: Some notes about HTTP/3

#84

Post by paulddraper »

CharlesW wrote: post #76
nly wrote: post #65

I hope we get in-kernel implementations of QUIC at some point because having to find a portable third-party library for userspace sounds about as appealing as installing Winsock on Windows 95.

I don't know much about this, so do you mind elaborating? Wouldn't userspace implementations be safer and easier to update as we spend the next few years sussing out security and performance issues?

IDK about "safer", but they will be more numerous and harder to update. (It's not as simple as making sure your kernel is up-to-date.)

Re: Some notes about HTTP/3

#85

Post by the8472 »

aaaaaaaaaab wrote: post #56

Interesting comment under the post: >The problem is fairness in the presence of network congestion. To a large extent it depends on most TCP implementations using the same congestion control algorithm, or at least algorithms that have the same general behavior. Google's developed a new algorithm called BBR that is robust, but also unfair. When a TCP connection implementing the NewReno algorithm shares a congested lin…

AQM is smarter than it was in the nineties. At worst network admins will have to deploy cake with triple-isolate to ensure fairness between hosts. It is even part of the mainline kernel now.

Re: Some notes about HTTP/3

#86

Post by cortesoft »

jgh wrote: post #5
meddlepal wrote: post #4

I feel like the adoption of HTTP/3 is going to be much much slower than HTTP/2... Besides Google Cloud do any of the major cloud providers have UDP load balancers?

I believe Akamai has implemented QUIC but I haven't heard of any other CDNs that have.

EdgeCast supports QUIC as well

https://www.verizondigitalmedia.com/blog/2018/05/quic-announ...

Re: Some notes about HTTP/3

#87

Post by ori_b »

Dylan16807 wrote: post #62
aaaaaaaaaab wrote: post #56

Interesting comment under the post: >The problem is fairness in the presence of network congestion. To a large extent it depends on most TCP implementations using the same congestion control algorithm, or at least algorithms that have the same general behavior. Google's developed a new algorithm called BBR that is robust, but also unfair. When a TCP connection implementing the NewReno algorithm shares a congested lin…

> and Internet brown-outs as in the 1980s and 1990s would come back. That part definitely needs more justification. An algorithm playing badly with NewReno doesn't mean that we'd be worse off if every system switched to it.

Eagerly waiting for you to start sending patches for every system, including proprietary and unmaintained ones, and ensuring that those get included by default.

Re: Some notes about HTTP/3

#89

Post by netheril96 »

the8472 wrote: post #81
ris wrote: post #80

Earlier quoted context omitted.

But the whole point of QUIC is that it is a userspace implementation. From the QUIC viewpoint (and I take no sides in this) kernel implementation is death for a protocol because it freezes its specification and behaviour in slow-to-update systems. This is why they found they couldn't "just improve TCP".

There have been plenty of improvements to TCP over time. New congestion controllers, new extension headers, fast open, ECN, etc.

How long does each improvement achieve widespread adoption?

Re: Some notes about HTTP/3

#90

Post by amaccuish »

X-Istence wrote: post #28
Tuna-Fish wrote: post #18

Earlier quoted context omitted.

The protocol has been designed so that both the endpoints of a stream can seamlessly change IP addresses. This ought to make load balancing easier?

Not unless you want to get through firewalls seamlessly. UDP "state" tracking is a thing, and if my firewall sees a UDP packet destined for it without knowing the remote IP address it's going to drop it.

I think it's more about the client changing their IP, i.e. moving wifi networks or from wifi to mobile. Not so much the server changing.
Post reply on HN