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

31–40 of 181 posts

Re: Some notes about HTTP/3

#31

Post by romed »

tyingq wrote: post #21
romed wrote: post #14

Earlier quoted context omitted.

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.

Yep, but it would be inadvisable to set it lower than the peer’s delayed ACK timeout, unless you want to just always resend every packet.

Re: Some notes about HTTP/3

#32

Post by vertex-four »

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.

Which is yet another reason to migrate to IPv6, which doesn’t require stateful NAT.

Re: Some notes about HTTP/3

#33

Post by moderation »

dcbadacd wrote: post #26
romed wrote: post #14

Earlier quoted context omitted.

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?

IETF - A Comparison between SCTP and QUIC [0]

0. https://tools.ietf.org/html/draft-joseph-quic-comparison-qui...

Re: Some notes about HTTP/3

#34

Post by popee »

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…

Aha, thanks for clearing that up

Re: Some notes about HTTP/3

#35

Post by blitmap »

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…

Again, as someone who does not completely grok QUIC I am not dismissing it. I was hoping if some parameters were not exposed work would be put toward making these available through existing interfaces.

Re: Some notes about HTTP/3

#36

Post by blitmap »

pfschell wrote: post #23

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

This is definitely a risk. There are valid needs to wanting to resume a connection as it hops between gateways, but I definitely see abuse for this. The identifier doesn’t necessarily tie you to a location or name, but once you can associate that it is a risk.

Re: Some notes about HTTP/3

#37

Post by tyingq »

john37386 wrote: post #17

Most of the deadliest DDoS attacks happen over UDP. Spoofing, reflection and amplification just to name a few. Many businesses just deny UDP to protect themself against the on going DDoS threats. I feel this move won't make internet a better and safer place, but let's see.

That's because other UDP based protocols don't have tcp like sequence numbers or other anti-spoofing measures. Quic has a source address token that makes it hard to spoof.

Re: Some notes about HTTP/3

#38

Post by derefr »

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.

A WebRTC "RTCDataChannel" is an SCTP-over-DTLS-over-UDP stack, and webservers exist to stream to these. They're just mostly proprietary, existing as part of vertically-integrated stacks like that of Google Hangouts (i.e. its "app sharing" feature.)

Re: Some notes about HTTP/3

#39

Post by sgentle »

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…

A more likely reason is that Google and other internet companies see internet infrastructure as an economic complement: the better and cheaper the internet is, the better and cheaper the total internet + Google services package is. That's why they do so much web performance advocacy, make their own browser, keep trying to kill off ISPs etc. Every dollar you spend on internet service is a dollar you don't spend on digital subscriptions, and every second you spend waiting for pages to load is a second you're not consuming content and watching ads.

Re: Some notes about HTTP/3

#40

Post by derefr »

john37386 wrote: post #17

Most of the deadliest DDoS attacks happen over UDP. Spoofing, reflection and amplification just to name a few. Many businesses just deny UDP to protect themself against the on going DDoS threats. I feel this move won't make internet a better and safer place, but let's see.

See https://blog.cloudflare.com/the-road-to-quic/#deflectingrefl...
Post reply on HN