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

111–120 of 181 posts

Re: Some notes about HTTP/3

#111

Post by ysleepy »

saagarjha wrote: post #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?

Part of the advantage is that you can update the protocol implementation independently of the OS. So google does not have to lobby OS vendors to implement TCP fast-open and other extensions to make their stack faster.

Re: Some notes about HTTP/3

#112

Post by freediver »

owaislone wrote: post #104
freediver wrote: post #94

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

Define the criteria please.

Re: Some notes about HTTP/3

#113

Post by zamadatix »

chuhnk wrote: post #8
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?

Disagree. There's more incentive to move considering the advantages it offers. If anything it feels like people were reluctant to adopt http2 and http3 is a bigger leap that we'll all want to move forward with.

The challenge for http/3 will be middleboxes not endpoints. Put another way: it won't be hard to break 50% of traffic on http/3 but you will still be running 2 10 years from now if you want to reach the last 10% of users.

Re: Some notes about HTTP/3

#114

Post by Dylan16807 »

tor_user wrote: post #98
Dylan16807 wrote: post #69

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

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.

Re: Some notes about HTTP/3

#115

Post by Dylan16807 »

tor_user wrote: post #106
penagwin wrote: post #103

Earlier quoted context omitted.

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.

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

Re: Some notes about HTTP/3

#116

Post by zamadatix »

piannucci wrote: post #61
aaaaaaaaaab wrote: post #56

Interesting comment under the post: >The problem is fairness in the presence of network congestion. To a large extent it depends on most TCP implementations using the same congestion control algorithm, or at least algorithms that have the same general behavior. Google's developed a new algorithm called BBR that is robust, but also unfair. When a TCP connection implementing the NewReno algorithm shares a congested lin…

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…

Otoh your connection is already doing pretty good if the main source of congestion is the wireless link.

Re: Some notes about HTTP/3

#117

Post by wpietri »

ris wrote: post #80
nly wrote: 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.

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

Is that death for a protocol? Or success?

I get why Google, which controls a great deal of the software on both ends of a very large number of connections, finds a settled standard inconvenient.

But from my perspective, as somebody who uses Google software but does a lot of other things too, I like when we have standards that are implemented by many different people and aren't controlled by a single vendor that is eager to maintain or extend their large market shares in many areas. Can that be slow to change? Sure. But the speed is proportional to how much the change benefits people besides Google.

Personally, I hope that QUIC is a first step toward taking the lessons learned and implementing them widely, rather than something that will evolve at a rapid pace precisely as long as Google needs it to and then stop.

Re: Some notes about HTTP/3

#118

Post by lucb1e »

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.

Re: Some notes about HTTP/3

#119

Post by neopallium »

nly wrote: post #74
detaro wrote: post #72

Earlier quoted context omitted.

HTTP requests are small, and a read() call only gets you the data from a single connection, so you get one to few packet(s) worth of data per syscall. In contrast, recvmmsg can get you a large bunch of packets across all "connections" in a single syscall.

Good point. Only that makes sense for servers though since for clients (web browsers etc) sockets will be 'connected' and they will still have lots of sockets anyway. They'll still be epoll()ing or similar. Not withstanding the other benefits of QUIC, the UDP vs TCP thing wrt to crossing the kernel-userspace boundary doesn't seem that significant.

The client doesn't have to use a "connected" UDP socket either. The client can bind to a random local port and use "sendto" to talk to many servers.

Re: Some notes about HTTP/3

#120

Post by zamadatix »

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

It's not so much just because "tcp will freak out" as much as it is understanding no transport layer retransmission algorithms operating on the scale of 100+ms can be a replacement for 100us+ link layer reliability mechanisms like FEC and retransmission.
Post reply on HN