Some notes about HTTP/3 • Hacker News Board

Re: Some notes about HTTP/3

#91

Post by Brybry » Fri, Nov 23, 2018, 10:27 PM UTC

john37386 wrote: post #73

baby wrote: post #45

Earlier quoted context omitted.

Or let's actually read about QUIC before quickly commenting on it. QUIC uses two mechanism to make sure you cannot do such attacks: * it requires a proof of IP ownership (exactly like TCP sequence numbers) to setup a connection ID (pretty much, you're able to receive the server's response to finalize the connection) [1] * it requires the client's first message (client hello) to be padded to at least the size of the s…

Quic is secure and doesn't allow spoofing. But, since it runs on UDP, a hacker could attack few DNS servers and amplify a UDP attack toward a Quic server. This is true for all reflection and amplification attacks. Hence, Quic is vulnerable to receive huge amplification attacks +100Gb and soon 1Tbps. It will not make internet a safer and better place. Even video game companies used to use UDP and they move away becaus…

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.

Re: Some notes about HTTP/3

#92

Post by piannucci » Fri, Nov 23, 2018, 10:30 PM UTC

richardwhiuk wrote: post #64

piannucci wrote: post #61

Earlier quoted context omitted.

Race to the bottom is one thing. Yes, so-called “TCP unfriendly” protocols will muscle out any protocol that reacts to probability p random packet drops by a one-over-root-p reduction in throughput. But that does NOT mean that BBR will fail to avoid congestive collapse. The one-over-root-p behavior is outdated and actually harmful on wireless links, anyway; it was designed for the assumption that all losses are conge…

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

Re: Some notes about HTTP/3

#93

Post by gsich » Fri, Nov 23, 2018, 10:41 PM UTC

dcbadacd wrote: post #29

rrdharan wrote: post #19

Earlier quoted context omitted.

I'm curious, how does SCTP tunneled over UDP compare to QUIC? https://tools.ietf.org/html/rfc6951

It compares in the way that there's not a single SCTP web server implementation compared to QUIC. People here say that we should use HTTP/2 over SCTP, no protocol will be adopted if there's no good implementations of it.

Linux has one. But Windows doesn't, so you instantly lose more then 90%.

Re: Some notes about HTTP/3

#94

Post by freediver » Fri, Nov 23, 2018, 10:54 PM UTC

“The top 5 corporations in the world are, in order, Apple-Google-Microsoft-Amazon-Facebook”

I literally can not find a criteria that would support this claim.

Market cap - no. Revenue - no. Customer satisfaction? Employee satisfaction? Contribution to society? No.

Re: Some notes about HTTP/3

#95

Post by netheril96 » Fri, Nov 23, 2018, 10:54 PM UTC

ori_b wrote: post #87

Dylan16807 wrote: post #62

Earlier quoted context omitted.

> 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.

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.

Re: Some notes about HTTP/3

#96

Post by ris » Fri, Nov 23, 2018, 10:55 PM UTC

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.

I'm not saying that they don't happen, but they are extremely slow to gain traction because of various things including OS support.

Re: Some notes about HTTP/3

#97

Post by adzm » Fri, Nov 23, 2018, 10:56 PM UTC

gsich wrote: post #93

dcbadacd wrote: post #29

Earlier quoted context omitted.

It compares in the way that there's not a single SCTP web server implementation compared to QUIC. People here say that we should use HTTP/2 over SCTP, no protocol will be adopted if there's no good implementations of it.

Linux has one. But Windows doesn't, so you instantly lose more then 90%.

This is literally what has killed any work on sctp in my experience.

Re: Some notes about HTTP/3

#98

Post by tor_user » Fri, Nov 23, 2018, 11:09 PM UTC

Dylan16807 wrote: post #69

tor_user wrote: post #53

Earlier quoted context omitted.

like websites without javascript?

Working without javascript requires development time. Running old versions of HTTP doesn't. Version 1.1 is going to be fully supported for a long time.

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

Re: Some notes about HTTP/3

#99

Post by penagwin » Fri, Nov 23, 2018, 11:11 PM UTC

john37386 wrote: post #73

baby wrote: post #45

Earlier quoted context omitted.

Or let's actually read about QUIC before quickly commenting on it. QUIC uses two mechanism to make sure you cannot do such attacks: * it requires a proof of IP ownership (exactly like TCP sequence numbers) to setup a connection ID (pretty much, you're able to receive the server's response to finalize the connection) [1] * it requires the client's first message (client hello) to be padded to at least the size of the s…

Quic is secure and doesn't allow spoofing. But, since it runs on UDP, a hacker could attack few DNS servers and amplify a UDP attack toward a Quic server. This is true for all reflection and amplification attacks. Hence, Quic is vulnerable to receive huge amplification attacks +100Gb and soon 1Tbps. It will not make internet a safer and better place. Even video game companies used to use UDP and they move away becaus…

Games like agar.io and slither.io use websockets over TCP because browsers don't allow you to use UDP packets. The author of one of them (sorry I forget which) blogged about their adventure, and IIRC they still have lag issues, and there isn't a way to resolve them without switching to UDP.

I've personally worked on multiplayer game engine code and I assure you that UDP is far superior for VOIP and game state packets. TCP requires far too much overhead, requires packets be received in order, etc.

These make no sense for a game engine. If we have a sequence of player movements, lets say their X position [1, 2, 3], but we miss a packet [1, -, 3] we're fine, we only want their most recent packet. But the protocol will require acknowledgment and that packet to be resent, so it will require 8 different packets be sent, instead of 3! We don't even need the packet!

A lot of games are implementing web based technologies for their UIs (Panorama for example) and those will of course use TCP but that's not what the actual game server uses for VOIP/game state

Re: Some notes about HTTP/3

#100

Post by penagwin » Fri, Nov 23, 2018, 11:14 PM UTC

Brybry wrote: post #91

john37386 wrote: post #73

Earlier quoted context omitted.

Quic is secure and doesn't allow spoofing. But, since it runs on UDP, a hacker could attack few DNS servers and amplify a UDP attack toward a Quic server. This is true for all reflection and amplification attacks. Hence, Quic is vulnerable to receive huge amplification attacks +100Gb and soon 1Tbps. It will not make internet a safer and better place. Even video game companies used to use UDP and they move away becaus…

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)