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

21–30 of 181 posts

Re: Some notes about HTTP/3

#21

Post by tyingq »

romed wrote: post #14
blitmap wrote: post #12

Earlier quoted context omitted.

setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, ...) setsockopt(fd, SOL_SOCKET, SO_SNDTIMEO, ...) ? I'm not dismissing QUIC, but it is in your control to redefine those defaults. Maybe in 2020 we'll be grappling back toward [sane] defaults.

Those do not affect TCP state machine parameters like RTO(min), ATO, and TLP timeout. These are internal to the kernel and are either static, or can only be set systemwide. For example the minimum delayed ack timeout in Linux is just 40ms and can't be changed except by recompiling the kernel. 40ms is a totally inappropriate number for ATO in a datacenter or other low-latency setting. Other numbers like RTO(min) are s…

You can tweak rto_min per route, with ip route.

Re: Some notes about HTTP/3

#22

Post by moderation »

rrdharan wrote: post #19
jasonhansel wrote: post #16

Wish we could just use SCTP instead: https://en.m.wikipedia.org/wiki/Stream_Control_Transmission_...

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

Lot's of discussion about SCTP in prior related thread at https://news.ycombinator.com/item?id=18427795

Re: Some notes about HTTP/3

#23

Post by pfschell »

>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 connection. This means that as you move around, you can continue with a constant stream uninterrupted from YouTube even as your IP address changes, or continue with a video phone call without it being dropped.

This is the ultimate dream of every surveillance company & gov't. Of course Google is solving this "problem."

Re: Some notes about HTTP/3

#24

Post by dharmab »

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 the final ALPN token "h3". Doing so clearly identifies it as another binding of HTTP semantics to the wire protocol -- just as HTTP/2 did -- so people understand its separation from QUIC.

https://mailarchive.ietf.org/arch/msg/quic/RLRs4nB1lwFCZ_7k0...

TL;DR the rename is to resolve the confusion.

Re: Some notes about HTTP/3

#25

Post by surak »

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

Re: Some notes about HTTP/3

#26

Post by dcbadacd »

romed wrote: post #14
blitmap wrote: post #12

Earlier quoted context omitted.

setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, ...) setsockopt(fd, SOL_SOCKET, SO_SNDTIMEO, ...) ? I'm not dismissing QUIC, but it is in your control to redefine those defaults. Maybe in 2020 we'll be grappling back toward [sane] defaults.

Those do not affect TCP state machine parameters like RTO(min), ATO, and TLP timeout. These are internal to the kernel and are either static, or can only be set systemwide. For example the minimum delayed ack timeout in Linux is just 40ms and can't be changed except by recompiling the kernel. 40ms is a totally inappropriate number for ATO in a datacenter or other low-latency setting. Other numbers like RTO(min) are s…

How does QUIC compare to HTTP/2 over SCTP?

Re: Some notes about HTTP/3

#27

Post by dochtman »

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.

Cloudflare is also already testing draft QUIC support.

Re: Some notes about HTTP/3

#28

Post by X-Istence »

Tuna-Fish wrote: post #18
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?

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.

Re: Some notes about HTTP/3

#29

Post by dcbadacd »

rrdharan wrote: post #19
jasonhansel wrote: post #16

Wish we could just use SCTP instead: https://en.m.wikipedia.org/wiki/Stream_Control_Transmission_...

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.

Re: Some notes about HTTP/3

#30

Post by skybrian »

surak wrote: 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 attacker do with a persistent connection?

Post reply on HN