Live data from Hacker News

Some notes about HTTP/3

blog.erratasec.com

101–110 of 181 posts

Re: Some notes about HTTP/3

#101
post #25

Can we assume the main motivation for google is to be able to track mobile users better? Particullary as more users are using various blocking methods and the legal environment regarding 3rd party trackers I questionable. "With QUIC, however, the identifier for a connection is not the traditional concept of a "socket" (the source/destination port/address protocol combination), but a 64-bit identifier assigned to the…

I don't see any reason to assume that. As the article explains, portable network connections have been a goal in network research for many years. Also, Google benefits from a faster and more secure Internet and its employees have the freedom to pursue that in a wide variety of ways. They aren't all mustache-twirling villains. But I do think the security and privacy implications should be explored. What could an attac…

Nothing that a session cookie can't, probably - web servers aren't getting that much of a new tracking mechanism with a QUIC session id.

But a session cookie doesn't allow to transfer a stream to a new IP address during a long request/response.

Re: Some notes about HTTP/3

#102
post #91

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.

Indeed, nearly all FPS/MMO/RTS games are realtime and need UDP, only some messages need to be reliable/ACK'd or ordered and TCP is overkill except for turn based games.

Real-time games have to be UDP or more typically a variation of Reliable UDP (RUDP) [1]. Many networking kits are based on reliable UDP and common early implementations as the core/base of their network layers such as enet [2] or RakNet [3] (Unity, Unreal, Sony, Oculus and more). RUDP or variants are UDP with channels, ordering, priority as well as ACKs where needed for reliable/must deliver messages through the use of a return UDP ACK datagram for verification. Reliable UDP is a set of service enhancement such as congestion control, retransmission, thinning server algorithms that allow a Real-time Transport Protocol (RTP) for media broadcasts even in the presence of packet loss and network congestion.

Reliable UDP ACKS are used commonly in areas like global events such as game start, game end, player entered, player died, player hit etc, all other positioning/action is UDP broadcast with dropped packets lerped [5] and slerped [6] out with interpolation [7] and extrapolation to deal with lag compensation [8] and client prediction [9][10][11]. Sometimes this also involves channels and grid/graph areas where only messages to players around you or in that area are required to ACK when needed i.e. player hit/death.

Most large real-time games are just UDP broadcast for 99% of action. TCP is almost never used in real-time action games like FPS, MMO, RTS etc.

Rarely are TCP and UDP combined, rather RUDP or later something like SCTP, allows streaming/real-time capable broadcasts with enough verification/reliable messages where needed. Combining TCP and UDP can end up with queuing issues that affect both TCP and UDP traffic [4] so most games just go with reliable variant of UDP.

Gaffer on Games has a good section on why UDP is used in games [12]

> The web is built on top of TCP, which is a reliable-ordered protocol.

> To deliver data reliably and in order under packet loss, it is necessary for TCP to hold more recent data in a queue while waiting for dropped packets to be resent. Otherwise, data would be delivered out of order.

> This is called head of line blocking and it creates a frustrating and almost comedically tragic problem for game developers. The most recent data they want is delayed while waiting for old data to be resent, but by the time the resent data arrives, it’s too old to be used.

> Unfortunately, there is no way to fix this behavior under TCP. All data must be received reliably and in order. Therefore, the standard solution in the game industry for the past 20 years has been to send game data over UDP instead.

> How this works in practice is that each game develops their own custom protocol on top of UDP, implementing basic reliability as required, while sending the majority of data as unreliable-unordered. This ensures that time series data arrives as quickly as possible without waiting for dropped packets to be resent.

> So, what does this have to do with web games? The main problem for web games today is that game developers have no way to follow this industry best practice in the browser. Instead, web games send their game data over TCP, causing hitches and non-responsiveness due to head of line blocking.

> This is completely unnecessary and could be fixed overnight if web games had some way to send and receive UDP packets.

[1] https://www.ietf.org/proceedings/44/I-D/draft-ietf-sigtran-r...

[2] http://enet.bespin.org/

[3] https://en.wikipedia.org/wiki/RakNet

[4] https://web.archive.org/web/20180704154418/https://www.isoc....

[5] https://en.wikipedia.org/wiki/Linear_interpolation

[6] https://en.wikipedia.org/wiki/Slerp

[7] https://developer.valvesoftware.com/wiki/Interpolation

[8] https://developer.valvesoftware.com/wiki/Lag_compensation

[9] https://developer.valvesoftware.com/wiki/Prediction

[10] https://gafferongames.com/post/snapshot_compression/

[11] https://gafferongames.com/post/snapshot_interpolation/

[12] https://gafferongames.com/post/why_cant_i_send_udp_packets_f...

Re: Some notes about HTTP/3

#103

Earlier quoted context omitted.

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

Running old versions of HTTP requires nothing because people will need to support legacy devices for a long time, and it's obviously already implemented in all major components (Servers, CDNs, Clients, etc.)

Re: Some notes about HTTP/3

#104

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

They are seen as the top five tech giants. That's probably what the author meant.

Re: Some notes about HTTP/3

#105
I’m no web standards expert, but I’m surprised that this standard will be implemented in userspace rather than in the kernel. Seems like a rather odd choice: will there be a way to string together the requisite kernel calls together to achieve the same functionality, or will I be forced to link against a “priveleged” library that makes these calls for me?

Re: Some notes about HTTP/3

#106

Earlier quoted context omitted.

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

Running old versions of HTTP requires nothing because people will need to support legacy devices for a long time, and it's obviously already implemented in all major components (Servers, CDNs, Clients, etc.)

???? != 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.

Re: Some notes about HTTP/3

#107

I’m no web standards expert, but I’m surprised that this standard will be implemented in userspace rather than in the kernel. Seems like a rather odd choice: will there be a way to string together the requisite kernel calls together to achieve the same functionality, or will I be forced to link against a “priveleged” library that makes these calls for me?

It's not a privileged library. You can choose an HTTP/3 implementation like choosing an HTTP 1 implementation.

Re: Some notes about HTTP/3

#108
Microsoft owns a popular operating system, so it's innovations are driven by what it can do within that operating system.

its*

A fantastic article ruined by a nasty grammar mistake (I'm kidding, of course).

Re: Some notes about HTTP/3

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

Existing HTTP is not in the kernel. If you want to speak HTTP, you already need a library.

With existing HTTP, that library needs to handle portability concerns to use TCP on different operating systems.

With new HTTP, the library will need to do the same thing but with UDP.

Seems like the complexity is no higher, just a difference (TCP vs. UDP) in how your library will interface with the platform network stack API.

Re: Some notes about HTTP/3

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

Existing HTTP is not in the kernel. If you want to speak HTTP, you already need a library. With existing HTTP, that library needs to handle portability concerns to use TCP on different operating systems. With new HTTP, the library will need to do the same thing but with UDP. Seems like the complexity is no higher, just a difference (TCP vs. UDP) in how your library will interface with the platform network stack API.

Http is done in kernel on Windows http.sys is a kernel driver which IIS and some other windows servers use.

Some UNIX distros also have their kernel implementation, and Linux has/had TUX but I’m not sure if it’s in use anywhere.

Post reply on HN