Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Status of HTTP/3

infoq.com

Post reply on HN
Print view View original

71–80 of 123 posts

Re: The Status of HTTP/3

#71

Post by toast0 »

Rusky wrote: post #38
whatsmyusername wrote: post #23

Yeah I'm not deploying this, pretty much ever. I'll gladly eat the overhead of TCP to be able to avoid the reflection and spoofing issues of UDP.

The only reason QUIC is built on top of UDP is because ossification prevents it from being built on top of IP. It's essentially at the same level as TCP- and provides similar mechanisms to avoid UDP's issues.

Google is building TCP over UDP because they're unwilling to fix TCP on Android.

Apple has shown that TCP is not ossified. They have innovative features like Path MTU probing/blackhole detection [1] and multipath TCP [2].

[1] This actually isn't innovative, but Android hasn't enabled it, even though it was widely available since before Android existed; maybe enabling it is an innovation?

[2] Initially for Siri only, but now available to applications if you make the right incantations. I haven't been able to actually use it, and I'm pretty sure there's some hidden performance issues. For example, there's no reasonable way to make all the substreams of a MPTCP connection go to the same network queue, and you probably want that for performance, but that would be a problem with QUICs multipath features as well; I haven't seen if anybody made reasonable configuration for MPTCP yet, either.

Re: The Status of HTTP/3

#72

Post by comex »

manigandham wrote: post #31
axaxs wrote: post #16

I hate to be a curmudgeon, but I can't help but think that designing a new service over UDP isn't the best idea. DNS has been fighting off wave after wave of attack vectors, some that realistically cannot even be fixed. Making it immune to these vectors is going to look a lot like a slapped together TCP over UDP...

Too bad no major internet company wants to implement a new version of TCP. We can’t even get IPv6 done after 15 years.

“A new version of TCP” is pretty much what QUIC (basis of HTTP/3) is. It’s just tunneled over UDP because existing Internet infrastructure likes to drop anything that’s not TCP or UDP.

Re: The Status of HTTP/3

#73

Post by taf2 »

axaxs wrote: post #16

I hate to be a curmudgeon, but I can't help but think that designing a new service over UDP isn't the best idea. DNS has been fighting off wave after wave of attack vectors, some that realistically cannot even be fixed. Making it immune to these vectors is going to look a lot like a slapped together TCP over UDP...

Isn’t the DNS issue unrelated to the protocol of UDP vs TCP but rather how DNS service communicate with each other... triggers an amplification of one request into 100s or maybe 1000s... not really a tcp vs udp issue?

Re: The Status of HTTP/3

#74

Post by generj »

baby wrote: post #51
NilsIRL wrote: post #49

Earlier quoted context omitted.

> All this to support more ads per page. I'm also very afraid of the future of Web Assembly. Both of these technologies i'm afraid aren't going to make things better, faster and more lightweight. They are just going to allow the bloat of the web to become worse without noticeable symptoms.

This made me think of the problem of highways: the more lane you add, the more cars come to use your road and congestion is not reduced. This is a problem with computers in general. For example IDEs and simple electron apps taking huge amounts of memory.

The problem with highways is called induced or latent demand. It’s a known problem in a lot of fields.

https://en.m.wikipedia.org/wiki/Induced_demand

Re: The Status of HTTP/3

#75

Post by axaxs »

taf2 wrote: post #73
axaxs wrote: post #16

I hate to be a curmudgeon, but I can't help but think that designing a new service over UDP isn't the best idea. DNS has been fighting off wave after wave of attack vectors, some that realistically cannot even be fixed. Making it immune to these vectors is going to look a lot like a slapped together TCP over UDP...

Isn’t the DNS issue unrelated to the protocol of UDP vs TCP but rather how DNS service communicate with each other... triggers an amplification of one request into 100s or maybe 1000s... not really a tcp vs udp issue?

There's two issues at play there. What you're talking about is called amplification. That means you get responses far larger than the query. So you send a small query for say, TXT, and the server may reply with KBs of TXT records.

However, that isn't useful by itself. Where it's useful is for attacking a third party. To do this, you spoof the source IP of your query to be the IP of the victim. This is called reflection. See, in TCP, every connection starts with a tiny three way handshake. So if you spoof the IP, the target would just get an unknown SYNACK which is tiny. It wouldn't respond, and nothing further happens. In UDP, there is no such handshake. So the target gets the entire response.

So in short, DNS amplification attacks are only useful with reflection, which doesn't work over TCP.

Re: The Status of HTTP/3

#76

Post by jiggawatts »

manigandham wrote: post #31
axaxs wrote: post #16

I hate to be a curmudgeon, but I can't help but think that designing a new service over UDP isn't the best idea. DNS has been fighting off wave after wave of attack vectors, some that realistically cannot even be fixed. Making it immune to these vectors is going to look a lot like a slapped together TCP over UDP...

Too bad no major internet company wants to implement a new version of TCP. We can’t even get IPv6 done after 15 years.

It's a common misconception that routers handle TCP. They strictly handle only the IP headers (and lower-level headers).

The TCP protocol is implemented only by endpoints, at least in principle.

It's the "security appliances", also known as "middleboxes" that are the problem. Think web proxies, antimalware scanners, firewalls, and inline IDS systems.

These things are the bane of the Internet, because they ossify protocols, blocking any further development.

Re: The Status of HTTP/3

#77

Post by 3xblah »

"HTTP/1.1 keep-alive connections, though, do not support sending multiple requests out at the same time, which again resulted in a bottleneck due to the growing complexity of Web pages."

Is this true.

Below we use HTTP/1.1 pipelining to send multiple requests (30) over a single TCP connection in order to print short descriptions of the last 30 infoq.com articles posted to HN.

   http11 ()
   { 
   while read x;do case $x in https://*)x1=${x#https://*/};;http://*)x1=${x#http://*/};;*)x1=${x#*/};esac;[ $x1 != $x ]||x1="";x2=${x#*//};x3=${x2%%/*};printf "GET /$x1 HTTP/1.1\r\nHost: $x3\r\nConnection: keep-alive\r\n\r\n";done|sed '/^$/d;N;$!P;$!D;$d';printf "Connection: close\r\n\r\n";
   }
   curl https://news.ycombinator.com/from?site=infoq.com|grep -o "https://www.infoq[^\"?]*"|   http11   |openssl s_client -connect www.infoq.com:443 -ign_eof -quiet 2>/dev/null|sed -n '/@id/p;/^  \"description\": \"/p'

Re: The Status of HTTP/3

#78

Post by detaro »

jiggawatts wrote: post #76
manigandham wrote: post #31

Earlier quoted context omitted.

Too bad no major internet company wants to implement a new version of TCP. We can’t even get IPv6 done after 15 years.

It's a common misconception that routers handle TCP. They strictly handle only the IP headers (and lower-level headers). The TCP protocol is implemented only by endpoints , at least in principle. It's the "security appliances", also known as "middleboxes" that are the problem. Think web proxies, antimalware scanners, firewalls, and inline IDS systems. These things are the bane of the Internet, because they ossify pro…

Although what a consumer considers a "router" is actually a middlebox doing a bunch of things and does care. (CG-NAT in provider networks is probably another example of a common problematic middlebox)

Re: The Status of HTTP/3

#79

Post by pdimitar »

baby wrote: post #50
Animats wrote: post #36

All this to support more ads per page. All this is only a win mostly if you have a huge number of little assets from different sources. Ads, trackers, icon buttons, malware, etc. If it's all coming from one source, HTTP/2 is good enough. If it's mostly one big file, HTTP/1 is good enough.

You are wrong. If you understand how browsers behave when they query a page that contains different resources from one source, and how head-of-line blocking works, you understand why so much effort was put into this protocol. (Any introduction on QUIC will explain you these if you are interest.)

So, as a guy who is hellbent on not losing their ad blocking, are you telling me that QUIC allows the client (the browser in this case) to read from the stream up to a point, find a resource with a well-known name (or crypto hash) that is an ad/tracker, and the client is then allowed to just skip ahead in the stream, not downloading and never parsing the said ad/tracker?

If no, then QUIC has failed its purpose, for the tech-savvy browser users at least.

If yes, I'd be happy.

Re: The Status of HTTP/3

#80

Post by pdimitar »

Animats wrote: post #36

All this to support more ads per page. All this is only a win mostly if you have a huge number of little assets from different sources. Ads, trackers, icon buttons, malware, etc. If it's all coming from one source, HTTP/2 is good enough. If it's mostly one big file, HTTP/1 is good enough.

I suspect more ads per page with less ability to block them is Google's endgame indeed.

But if browsers like Firefox find a way to skip ahead in the stream (through the ads/trackers while never downloading/parsing them in the first place) then things could be back to normal (for us the ad-blocker users).

Still though, if used for good, QUIC (or HTTP/3) seems like a pretty good piece of tech.

Post reply on HN