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

81–90 of 123 posts

Re: The Status of HTTP/3

#81

Post by gsnedders »

3xblah wrote: post #77

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

With HTTP/1.1 pipelining, you can't reliably start sending the second request until the first response is complete. As such, you can't have multiple requests out at the same time. It's also very much linear.

Re: The Status of HTTP/3

#82

Post by detaro »

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

How does QUIC lead to "less ability to block them"?

Re: The Status of HTTP/3

#83

Post by pdimitar »

detaro wrote: post #82
pdimitar wrote: post #80

Earlier quoted context omitted.

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.

How does QUIC lead to "less ability to block them"?

I am not sure. But seems like the nature of the encrypted connection and the stream utilisation (akin to HTTP/2) would make it harder for something like e.g. your home PiHole to block ads at the DNS level -- or any other lower-level in your network before stuff hits the browser.

I should have worded my comment better. It wasn't a claim, it was more like a "I think Google wants this protocol to succeed for their own ulterior motives (serve ads and impede blockers), but is that what is actually going to happen?".

Re: The Status of HTTP/3

#84

Post by judge2020 »

pdimitar wrote: post #83
detaro wrote: post #82

Earlier quoted context omitted.

How does QUIC lead to "less ability to block them"?

I am not sure. But seems like the nature of the encrypted connection and the stream utilisation (akin to HTTP/2) would make it harder for something like e.g. your home PiHole to block ads at the DNS level -- or any other lower-level in your network before stuff hits the browser. I should have worded my comment better. It wasn't a claim, it was more like a "I think Google wants this protocol to succeed for their own u…

I mean, not directly. The ad team didn't get a team together and say "make a protocol that will get our ads to the browser quicker", it's likely a team made to "make the internet faster by solving problems with TCP", and it just happens that A. they're funded by ads and B. this speedup also happens to work in favor of ad delivery. Same for the other parts of the internet, like dynamic content [chrome, JS] and OS speed [android], they're making the entire internet faster which ends up including how fast they can push an ad.

Re: The Status of HTTP/3

#85

Post by 3xblah »

gsnedders wrote: post #81
3xblah wrote: post #77

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

With HTTP/1.1 pipelining, you can't reliably start sending the second request until the first response is complete. As such, you can't have multiple requests out at the same time. It's also very much linear.

"With HTTP/1.1 pipelining, you can't reliably start sending the second request until the first response is complete."

In the example, all 30 requests were sent at the same time. openssl did not wait for any responses.

This example can be repeated again and again and every time, all the responses are received, in order. It is reliable.

Not sure who "you" refers to in the above statement, however if it applies to me then that statement is incorrect. I have been using HTTP/1.1 pipelining outside the browser for decades.

HTTP/1.1 was written for HTTP clients. Browsers are just one type of client, not the only type. More than half the traffic on the internet is initiated by non-interactive clients. Besides headless, that excludes browsers.

From RFC 2616:

user agent

The client which initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end user tools.

Re: The Status of HTTP/3

#86

Post by AgentME »

pdimitar wrote: post #79
baby wrote: post #50

Earlier quoted context omitted.

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

QUIC is just a way for a browser to make more HTTP-like connections in parallel more efficiently. It doesn't affect ad-blocking browser extensions. The browser can still implement the APIs for extensions the same way regardless of whether QUIC or a previous version of HTTP is used.

Re: The Status of HTTP/3

#87

Post by mholt »

PhilippGille wrote: post #28
teruakohatu wrote: post #21

Earlier quoted context omitted.

Caddy's strange official binary licencing did them no favours. The licensing makes more sense now but they are off people's radar.

This might change with Caddy 2.0.

It changed months ago. It's all Apache licensed.

Re: The Status of HTTP/3

#88

Post by skrowl »

SquareWheel wrote: post #20
_khhm wrote: post #3

Seems more verbose than https://caniuse.com/#feat=http3 TLDR - No browsers support it (without flag / config changes) yet.

In the age of evergreen browsers, it's possible to go from 0% to 85% in just a few weeks time. Upgrading web servers will be the real bottleneck.

This guy has clearly never heard of mobile Safari / iOS

Re: The Status of HTTP/3

#89

Post by profmonocle »

wahern wrote: post #65
profmonocle wrote: post #47

Earlier quoted context omitted.

> I am afraid that businesses that will host HTTP/3 will be less secure in terms of availavility. Presumably most HTTP/3 implementations will gracefully fall back to HTTP/2 (or 1.1) if UDP is filtered. Chrome's existing QUIC implementation already does this. Every Google property has had QUIC enabled for quite a while now (at least 4-5 years), so if UDP blocking would cause availability issues, affected businesses wo…

In 2017 Google reported that "4.4% of clients are unable to use QUIC". See sec. 7.2 of https://static.googleusercontent.com/media/research.google.c... .

Sure, but that doesn't mean those clients are unable to connect to QUIC-enabled domains. Chrome detects that the UDP packets are being lost, disables QUIC, and falls back to HTTP/2.
Post reply on HN