Live data from Hacker News

HTTP/2 and HTTP/3 explained

alexandrehtrb.github.io

101–110 of 155 posts

Re: HTTP/2 and HTTP/3 explained

#101

Earlier quoted context omitted.

5-25% increase in loadtime (median), which caused a drop off in ongoing activity. Users also complained.

It doesn't matter. You can provide the numbers when asked by the proponents of HTTP2/3 'do you have proof of your claim??', they will just turn around and say your real world data is not valid or that they need peer-reviewed article in Science.

> (...) they will just turn around and say your real world data is not valid or that they need peer-reviewed article in Science.

This sounds like a bullshit conspiratorial excuse. If you have real world data and you aren't afraid of having peers looking through it, nothing prevents you from presenting it to peers.

So where is that data?

Instead, you just have vague unsupported unbelievable claims made by random people in the internet, as if that's any way to decide over policy, and any faint doubt raised over that claim is faced with conspiratorial remarks complemented by statements on how everyone around OP is incompetent except him.

I will go as far as to claim OP's assertion is unbelievable, to the point of sounding like bullshit. It's entirely unbelievable that people designing protocols for a multinational corporation whose bread and butter is stuff done over TCP connections were oblivious to how TCP works, and the most incompetent of them would bother to design the first major revision of HTTP. Unbelievable.

But hey, some random guy online said something, so it must be true!

Re: HTTP/2 and HTTP/3 explained

#102
post #101

Earlier quoted context omitted.

It doesn't matter. You can provide the numbers when asked by the proponents of HTTP2/3 'do you have proof of your claim??', they will just turn around and say your real world data is not valid or that they need peer-reviewed article in Science.

> (...) they will just turn around and say your real world data is not valid or that they need peer-reviewed article in Science. This sounds like a bullshit conspiratorial excuse. If you have real world data and you aren't afraid of having peers looking through it, nothing prevents you from presenting it to peers. So where is that data? Instead, you just have vague unsupported unbelievable claims made by random peopl…

[flagged]

Re: HTTP/2 and HTTP/3 explained

#103

Earlier quoted context omitted.

> you folks just don't even bother to learn TCP first before shitting on it. Let me stop you right there. I promise you you're not the only person who really knows how TCP works. The people who made HTTP2 and HTTP3 are clearly smart, knowledge folks who have a different perspective than you do. It's OK to disagree with them , but it's a bad look for you to assume that they're ignorant on the subject.

I didn't assume they are ignorant. I assumed that the are fraudulent. They knew they couldn't really improve existing protocols because it's simply not possible but moved forward anyway for personal gain. Just like everything from Google for the last 20 years. You make big splash with new and 'revolutionary' 6th version of instant messaging, get your promo and move on. And here we are, HTTP2 ran its course, time for…

Not to disagree but there is something to be learned from failing

Re: HTTP/2 and HTTP/3 explained

#105
post #100

Earlier quoted context omitted.

you are correct, but with keepalive, 10 connections over http1 will beat 1 connection over http2[1] even 4 connections will do better. [1] when there is high latency, or some packet loss, and the requests are batched evenly over all connections.

Each of those connections needs its own TCP and TLS handshake making a total of 6 trips. Also, although this didn't take off, h2 had push promise which could have been a big help.

Yeah HTTP/2 push is so great that Chrome removed it. Straight from the horse mouth: "However, it was problematic as Jake Archibald wrote about previously, and the performance benefits were often difficult to realize" https://developer.chrome.com/blog/removing-push

Re: HTTP/2 and HTTP/3 explained

#106
post #18

Earlier quoted context omitted.

I find it difficult to believe that the team that built the prototype for http/2 (SPDY), implemented it for chrome, tested it on gazillions of customers around the world, wasn't bothered to talk to anyone who did networking. Sure you can argue that the tradeoffs they selected were the wrong tradeoffs and that they may have been biased by their narrow domain specific goals (reducing latency to render an average web pa…

[flagged]

> Your error in thinking is that you assume that they really wanted to build something better instead of building something new that would propel their careers.

How do you explain that some HTTP/2 server implementations handle an order of magnitude more connections than their HTTP/1.1 implementations? Is this something you downplay as accidental benefits of doing something to propel their career?

https://http2benchmark.org/

You should talk less about conspiratorial accusations you are making up on the spot and more about hard data.

Re: HTTP/2 and HTTP/3 explained

#107
post #101

Earlier quoted context omitted.

> (...) they will just turn around and say your real world data is not valid or that they need peer-reviewed article in Science. This sounds like a bullshit conspiratorial excuse. If you have real world data and you aren't afraid of having peers looking through it, nothing prevents you from presenting it to peers. So where is that data? Instead, you just have vague unsupported unbelievable claims made by random peopl…

[flagged]

[flagged]

Re: HTTP/2 and HTTP/3 explained

#108

Earlier quoted context omitted.

But you can : you can do whatever horrors you want, privately. You want your own browser with specific compiled-options ? Then do it and deploy it on your private perimeter. However, if you want to expose something publicly, then your own ideas matters less than the interests of your clients (at least, this is how I see things) : so exposing to the internet something without TLS or with a self-signed / private CA cer…

These kinds of security mindsets exist because browsers have been made extremely insecure these days by encouraging and even setting the default behavior to automatically execute random programs downloaded from random places while at the same time exposing bare metal functionality for speed. This incredibly insecure business use case has made it so using a browser for merely surfing the web is dangerous and that's wh…

These kinds of security mindsets exist because, as a network architect, I know at least a couple of ways to put myself between you and your destination, and from there to read and/or rewrite your unencrypted data. Of course, if I manage any network between you and your destination, things get a lot more easier.

I do not want my coworkers to do that on any of my communications, nor my family, nor anybody.

The only known way to prevent this is encryption.

And no, it has nothing to do with browsers : the same applies to my emails, ssh, IRC and whatever.

Re: HTTP/2 and HTTP/3 explained

#109
post #48

Earlier quoted context omitted.

Here's a third option: the five month old anonymous HN account claiming to know what the H2 designers were thinking of is wrong. How would you compare the likelihood of that to your two options? The main problem you're talking of is head of line blocking due to packet loss. But packet loss as a congestion signal is nowhere near as common as people think, and that was already the case during the original SPDY design w…

> The main problem you're talking of is head of line blocking due to packet loss. But packet loss as a congestion signal is nowhere near as common as people think Surely packet loss due to poor signal quality is rather common over mobile networks and that packet loss still affects TCP's congestion window. Admittedly anecdotal, but I just connected to a 5G network with low signal strength and it certainly seems to be…

The parent is just moving goal posts. The whole idea behind multiplexing data streams inside a single TCP connection was that in case of a packet loss you don't lose all your streams. But it doesn't work in practice which is not really surprising when you think about it. When you have multiple TCP connections it's less likely that all of them will get reset due to connectivity issues. Whereas with data multiplexing when your single TCP connection is reset all your data flow stops and need to be restarted.

Re: HTTP/2 and HTTP/3 explained

#110

Earlier quoted context omitted.

I didn't assume they are ignorant. I assumed that the are fraudulent. They knew they couldn't really improve existing protocols because it's simply not possible but moved forward anyway for personal gain. Just like everything from Google for the last 20 years. You make big splash with new and 'revolutionary' 6th version of instant messaging, get your promo and move on. And here we are, HTTP2 ran its course, time for…

Not to disagree but there is something to be learned from failing

They didn't fail. They got their promotions. It's you, the end user, who is left holding the bag. But fear not, HTTP3 is on the horizon and this time it's going to be glorious!
Post reply on HN