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

171–180 of 181 posts

Re: Some notes about HTTP/3

#171

Post by Dylan16807 »

tor_user wrote: post #154
Dylan16807 wrote: post #149

Earlier quoted context omitted.

Unless they lose 99% of their users, there's enough demand. Your level of pessimism on this specific detail is ridiculous. Tor might not last forever, but it won't be lack of HTTP support that kills it. If you wait a few years for HTTP/3 to settle, proxies will be available that could be glued into tor inside a weekend hackathon.

> If you wait a few years for HTTP/3 to settle, proxies will be available that could be glued into tor inside a weekend hackathon. In 16 years they have not managed to support UDP and now you say of a project (you are not familiar with...), that they can get it up over a weekend hackathon. And you are calling me ridiculous? This speaks volumes for your predictive ability. Good day, sir!

Do you have a contact address? I could mark my calendar for 2025. "some proxy with HTTP >= 3 and HTTP Tor doesn't have UDP support right now because it doesn't need it for anything. The last 16 years are not equal to the next 16 years, surprisingly enough.

Re: Some notes about HTTP/3

#172

Post by Dylan16807 »

ori_b wrote: post #166
netheril96 wrote: post #95

Earlier quoted context omitted.

Why would he start sending patches for them? He already benefits from BBR himself. He doesn’t need to lift everyone else to enjoy the benefits, unlike the IPv4 to IPv6 transition.

And I benefit from driving on the sidewalk, why should I have to care how my car interacts with those tcp-using pedestrians? If you break TCP, and your answer is that "we'd be ok if every system switched to it", then you'd better start working on switching every system.

Well I was responding to a claim that it would ruin all traffic, including the people that switched. It's not my job to defend against an entirely different argument.

And this kind of thing needs more numbers in general. Maybe in a large mix of traffic, outside the edge case of a saturated link with two streams, it doesn't dominate too badly. Maybe because TCP incorrectly blocks so often, the average 'victim' user still benefits overall because only some of their devices are unpatched.

Re: Some notes about HTTP/3

#173

Post by bb88 »

X-Istence wrote: post #152
bb88 wrote: post #68

Earlier quoted context omitted.

If the client side changes it's IP address, it's a lot easier say than if the server side does. Typically because the server won't reject new UDP packets coming in from the internet. The load balancer will route any ongoing sessions with the session id, and not the ip address.

Absolutely, but the original commenter was stating that it would allow either endpoint to their their IP easily (and thus making load balancing easier). I was disputing that.

Ah... apologies for my confusion. Thanks for the clarification.

Re: Some notes about HTTP/3

#174

Post by yy77 »

dharmab wrote: post #24
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.

>However, in those discussions, a related concern was identified; confusion between QUIC-the-transport-protocol, and QUIC-the-HTTP-binding. I and others have seen a number of folks not closely involved in this work conflating the two, even though they're now separate things. > >To address this, I'd like to suggest that -- after coordination with the HTTP WG -- we rename our the HTTP document to "HTTP/3", and using th…

why not just http/quic? using 3 seems strongly suggest that it is the next generation of http. They knew that but pretend it is not relavent.

Re: Some notes about HTTP/3

#175

Post by ori_b »

Dylan16807 wrote: post #172
ori_b wrote: post #166

Earlier quoted context omitted.

And I benefit from driving on the sidewalk, why should I have to care how my car interacts with those tcp-using pedestrians? If you break TCP, and your answer is that "we'd be ok if every system switched to it", then you'd better start working on switching every system.

Well I was responding to a claim that it would ruin all traffic, including the people that switched. It's not my job to defend against an entirely different argument. And this kind of thing needs more numbers in general. Maybe in a large mix of traffic, outside the edge case of a saturated link with two streams, it doesn't dominate too badly. Maybe because TCP incorrectly blocks so often, the average 'victim' user st…

Or maybe you shouldn't really be discussing actually deploying things that harm users of the most widely used protocol out there, but instead change the new thing to deal with the world that it lives in .

Re: Some notes about HTTP/3

#177

Post by jokoon »

jabl wrote: post #165
jokoon wrote: post #49

Not sure I understand it very well, but that mean http3 is going to use UDP, but does that mean there is going to be a new TCP named TCP/2?

> but that mean http3 is going to use UDP Yes. > there is going to be a new TCP named TCP/2 No. There is a new protocol called QUIC, which runs on top of UDP. That is, to routers/firewalls/middleboxes etc. that are not specifically aware of QUIC, it will just look like UDP traffic. QUIC provides TCP-like features (reliable streams, with retransmissions of dropped packets etc.) plus more. As to why QUIC instead of imp…

Thanks for the explanation, that's clearer now.

Just another question, are the "middleboxes" well prepared for a massive switch towards UDP traffic? I don't know the network hardware world very well.

Also I thought TCP traffic was benefitting from hardware implementation and optimization, I guess that's also wrong.

Re: Some notes about HTTP/3

#178

Post by Dylan16807 »

ori_b wrote: post #175
Dylan16807 wrote: post #172

Earlier quoted context omitted.

Well I was responding to a claim that it would ruin all traffic, including the people that switched. It's not my job to defend against an entirely different argument. And this kind of thing needs more numbers in general. Maybe in a large mix of traffic, outside the edge case of a saturated link with two streams, it doesn't dominate too badly. Maybe because TCP incorrectly blocks so often, the average 'victim' user st…

Or maybe you shouldn't really be discussing actually deploying things that harm users of the most widely used protocol out there, but instead change the new thing to deal with the world that it lives in .

The existing congestion control algorithms have flaws that make them slow down far too much in certain situations. I don't know if it's possible to make something that doesn't have those flaws and never outcompetes them. We can probably do better than BBR, but I don't know if we can do a perfect job.

Re: Some notes about HTTP/3

#179

Post by jabl »

jokoon wrote: post #177
jabl wrote: post #165

Earlier quoted context omitted.

> but that mean http3 is going to use UDP Yes. > there is going to be a new TCP named TCP/2 No. There is a new protocol called QUIC, which runs on top of UDP. That is, to routers/firewalls/middleboxes etc. that are not specifically aware of QUIC, it will just look like UDP traffic. QUIC provides TCP-like features (reliable streams, with retransmissions of dropped packets etc.) plus more. As to why QUIC instead of imp…

Thanks for the explanation, that's clearer now. Just another question, are the "middleboxes" well prepared for a massive switch towards UDP traffic? I don't know the network hardware world very well. Also I thought TCP traffic was benefitting from hardware implementation and optimization, I guess that's also wrong.

> Just another question, are the "middleboxes" well prepared for a massive switch towards UDP traffic? I don't know the network hardware world very well.

I'm not an expert either, but AFAIK QUIC development has been heavily influenced by the requirement to work on the "real" internet with various middleboxes of varying quality.

And it's not like it's going to be an instant change. QUIC is AFAIK already used between Chrome and google/youtube, and once QUIC & HTTP3 are official, it'll be a very long tail.

> Also I thought TCP traffic was benefitting from hardware implementation and optimization, I guess that's also wrong.

Well, going all the way (that is, TOE), hasn't been that popular, and e.g. the Linux kernel has refused to support such cards in the mainline kernel. What is common, and very useful, is checksum and segmentation offloads. Checksums are present in both TCP and UDP, and AFAIK NIC's capable of TCP checksum offload can also do UDP checksum offloading. Similarly for segmentation offloading, except in the UDP world it's called fragmentation offload. Though I guess for QUIC, receive fragmentation offloading won't work as long as the kernel and HW don't understand QUIC, as they won't understand that two incoming UDP packets can be merged.

Re: Some notes about HTTP/3

#180

Post by dharmab »

yy77 wrote: post #174
dharmab wrote: post #24

Earlier quoted context omitted.

>However, in those discussions, a related concern was identified; confusion between QUIC-the-transport-protocol, and QUIC-the-HTTP-binding. I and others have seen a number of folks not closely involved in this work conflating the two, even though they're now separate things. > >To address this, I'd like to suggest that -- after coordination with the HTTP WG -- we rename our the HTTP document to "HTTP/3", and using th…

why not just http/quic? using 3 seems strongly suggest that it is the next generation of http. They knew that but pretend it is not relavent.

Because there's a decent chance that it will be the next generation of HTTP.

If it doesn't pan out they'll just move on. Remember IPv5?

Post reply on HN