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

141–150 of 181 posts

Re: Some notes about HTTP/3

#141

Post by algesten »

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.

You can solve that with STUN which is how WebRTC does it. Each end sends a STUN packet to get the NAT statefullness going.

Granted, it requires transferring of ICE connection candidates out of band (via the horrors of SDP)

Re: Some notes about HTTP/3

#142

Post by tor_user »

Dylan16807 wrote: post #114
tor_user wrote: post #98

Earlier quoted context omitted.

Working without javascript requires money . Running old versions of HTTP requires ???? .

The first one requires money be spent on every site . The second one requires that the feature be maintained in major web servers. Which it will be. On a per-site basis, the developer needs to do nothing .

Still not getting it. Every site is hosted. The hosting company needs to spend money on HTTP/2, and be allowed to use it. The networks need to allow TCP through. All the steps down to the transport layer now require legacy maintenance.

Lots of things need to happen for HTTP/2 to 'stay alive'.

Your use of the future tense does not convince me.

Re: Some notes about HTTP/3

#143

Post by tor_user »

Dylan16807 wrote: post #115
tor_user wrote: post #106

Earlier quoted context omitted.

???? != nothing. Why run HTTP/3 if HTTP/1 costs nothing? Where I work legacy gets dropped sooner rather than later. I hope this bombs, er tanks.

If it becomes the dominant way of serving web pages, you should realize that tor will add support.

How can I realise something that may or may not happen?

Everything that goes over UDP is not supported as of 2018 and some volunteer project is going to figure this out?

Hubris.

Re: Some notes about HTTP/3

#144

Post by tor_user »

int_19h wrote: post #136
tor_user wrote: post #106

Earlier quoted context omitted.

???? != nothing. Why run HTTP/3 if HTTP/1 costs nothing? Where I work legacy gets dropped sooner rather than later. I hope this bombs, er tanks.

You (will) run HTTP/3, because it is more efficient, meaning that your servers will be able to service more request. You run HTTP/2 and HTTP/1, because a lot of people are still using that, and you don't want to lose them. This especially applies to mobile devices, many of which are stuck with software that cannot be updated for various reasons. There's no threat of the majority of websites going HTTP/3 anytime soon.…

"Will" - are you from the future?

Re: Some notes about HTTP/3

#145

Post by tor_user »

lucb1e wrote: post #118
tor_user wrote: post #50

have any of you geniuses figured out this will break websites for tor users yet?

Downvoted because of the "you geniuses". You're making a fair point that I hadn't thought of yet (I'm also a fan of Tor), but the delivery method is just plain rude.

The oppressed people of the world salute your endeavours.

Re: Some notes about HTTP/3

#146

Post by gsich »

penagwin wrote: post #100
Brybry wrote: post #91

Earlier quoted context omitted.

I'm curious, what games have moved exclusively to TCP? Most (all?) multiplayer games I play still seem to use UDP, though there is definitely more mixed TCP use than there used to be.

Slither.io and Agar.io use exclusively TCP but that's only because browsers don't allow you to send/receive UDP packets. If you've ever played those games on any network or device with shaky internet then you'll know those games have lag issues, and the only way to optimize it more would be to switch to UDP (Which they can't)

I am not sure if that is what your parent meant by "games". If you want to talk about browsergames, you usually add the term "browser".

Re: Some notes about HTTP/3

#147

Post by gsich »

piannucci wrote: post #92
richardwhiuk wrote: post #64

Earlier quoted context omitted.

WiFi generally doesn't drop packets - it's usual failure mode is for latency to spike horribly for a clump of packets.

Under the hood, what's happening is that the physical layer is reporting that a packet failed to decode, and the link layer is attempting retransmission at a series of lower and lower fallback rates. It's designed this way because if it fails to deliver a packet, TCP will freak out. There's an RFC about the general case of designing link layers to hide random losses: https://tools.ietf.org/html/rfc3366

Packet loss is an essential part of TCP to determine max. throughput.

Re: Some notes about HTTP/3

#148

Post by Dylan16807 »

tor_user wrote: post #142
Dylan16807 wrote: post #114

Earlier quoted context omitted.

The first one requires money be spent on every site . The second one requires that the feature be maintained in major web servers. Which it will be. On a per-site basis, the developer needs to do nothing .

Still not getting it. Every site is hosted. The hosting company needs to spend money on HTTP/2, and be allowed to use it. The networks need to allow TCP through. All the steps down to the transport layer now require legacy maintenance. Lots of things need to happen for HTTP/2 to 'stay alive'. Your use of the future tense does not convince me.

The hosting company needs to spend basically nothing, because it's built into the software.

It's built into the software because enough sites will still be using it fifty years from now, even if it's a minority of traffic.

I seriously doubt you'll ever see TCP blocked.

Re: Some notes about HTTP/3

#149

Post by Dylan16807 »

tor_user wrote: post #143
Dylan16807 wrote: post #115

Earlier quoted context omitted.

If it becomes the dominant way of serving web pages, you should realize that tor will add support.

How can I realise something that may or may not happen? Everything that goes over UDP is not supported as of 2018 and some volunteer project is going to figure this out? Hubris.

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.

Re: Some notes about HTTP/3

#150

Post by X-Istence »

amaccuish wrote: post #90
X-Istence wrote: post #28

Earlier quoted context omitted.

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.

Client changing their IP address is fine, the comment I was replying to was stating that it would allow both sides to change their IP at will (and allow for better load balancing). I was disputing that.
Post reply on HN