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

HTTP/2 and HTTP/3 explained

alexandrehtrb.github.io

Post reply on HN
Print view View original

121–130 of 155 posts

Re: HTTP/2 and HTTP/3 explained

#121

Post by pi-e-sigma »

bsdetector wrote: post #94
ithkuil wrote: 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…

SPDY's header compression allowed cookies to be easily leaked. This vulnerability was well known at the time so had they even asked an intern at Google Zero to look at it they would have been immediately schooled. https://bugzilla.mozilla.org/show_bug.cgi?id=779413 In their performance tests vs HTTP 1.1 the team simulated loading many top websites, but presumably by accident used a single TCP connection for SPDY acro…

another explanation - they did test it in other scenarios but the results were against their hopes so they 'accidentally' omitted such tests in the 'official' test suite. Very common tactic, you massage your data until you get what you want.

Re: HTTP/2 and HTTP/3 explained

#122

Post by a1369209993 »

pi-e-sigma wrote: post #39
WhitneyLand wrote: post #37

Earlier quoted context omitted.

It’s not an error in thinking to assume a good faith basis for someone’s efforts until there’s some reason to think otherwise. You can choose to start out with skepticism or cynicism if you like but there’s no defect in people who don’t.

[flagged]

> -highly accomplished and highly experienced engineers were actually too stupid

> -these highly experienced guys actually knew what they were doing

> What seems more likely?

Well, when you put it that way... the former. By a large margin.

Re: HTTP/2 and HTTP/3 explained

#123

Post by rstuart4133 »

Aloisius wrote: post #98
jsnell wrote: 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…

> Surely packet loss due to poor signal quality is rather common over mobile networks and that packet loss still affects TCP's congestion window.

Two points:

1. It's not commonly realised the TCP is terrible on lossy networks, where terrible means gets less than 10% of the potential throughput. It only becomes apparent when you try to use TCP over a lossy network of course, and most real networks we use aren't lossy. Engineers who try to use TCP over lossy networks end up replacing it with something else. FWIW, the problem is TCP uses packet loss as a congestion signal. It handles congestion pretty well by backing off. But packet loss can also mean the packet was actually lost. The right responses in that case are to reduce the packet size and/or increase error correction, but _not_ decrease your transmission rate. Thus two responses to the same signal conflict.

2. Because of that, the layer two networks the internet uses have evolved to have really low error rates, which is why most people don't experience TCP's problems in that area. As it happens just about any sort of wireless has really high error rates, so they have to mask it. And they do, by having lots of ECC and doing their own ACK/NAKs. This might create lots of fluctuations in available bandwidth - but that is what TCP is good at handling.

By the by, another reason we have come to depend on really low error rates on layer 2. That's because TCP's error detection is poor. It lets roughly one bad packet through in every 10,000. (Adler32 is very poor on small packets.) You can send 100,000 packets a second at 1Gb/sec, so you need to keep the underlying error rate very low to ensure the backup you are sending to Backblaze isn't mysteriously corrupted a few times a year. IMO, we should have switched to 64 bit CRC's decades ago.

Re: HTTP/2 and HTTP/3 explained

#124

Post by superkuh »

JackSlateur wrote: post #108
superkuh wrote: post #90

Earlier quoted context omitted.

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

Yes. And there's almost zero risk to such (ARP poisoning? dns poisoning? etc) MITM attacks when you turn off javascript and don't blindly execute all programs sent to you as an end user.

The problem with MITM attacks is when you execute programs or exchange money or other private information. The risks when viewing public documents that don't require execution is minimal. That's my point. One use case "web app stores" ruins everything for everyone by requiring the mindset you advocate for as browser defaults. But the entire justification goes away if the end user just turns off JS auto-execute. It's not intrinsic to all use cases for the web or even most.

EDIT: Mentioning wikipedia is missing the point. Of course there are cases where CA TLS should be used. I am not denying that. I am saying there are many cases with CA TLS makes things fragile and short lived and it is not needed: like personal websites run by a human person. And these use cases are not invalidated by the existence of yet another corporate person (wikimedia).

Re: HTTP/2 and HTTP/3 explained

#125

Post by rstuart4133 »

pi-e-sigma wrote: post #14
jeltz wrote: post #7

Earlier quoted context omitted.

You will need to back up that accusation, because now you are accusing Daniel Stenberg of being a liar. On paper HTTP shouldperform much better than HTTP 1.1 and especially HTTP 2 on links with high packet loss since TCP handles packet loss very poorly. https://http3-explained.haxx.se/en/why-quic

[flagged]

> Also TCP handles packet loss just fine

That's just plain wrong. I commented in more depth in https://news.ycombinator.com/item?id=39709591. In short, TCP treats packet loss as congestion signal and slows down. If the packet loss was due to congestion that's absolutely the correct response and it increases TCP's "goodput". But if the packet was lost due to noise then it has the opposite effect and goodput plummets to a fraction of what the link is capable of.

Re: HTTP/2 and HTTP/3 explained

#126

Post by JackSlateur »

superkuh wrote: post #124
JackSlateur wrote: post #108

Earlier quoted context omitted.

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

Yes. And there's almost zero risk to such (ARP poisoning? dns poisoning? etc) MITM attacks when you turn off javascript and don't blindly execute all programs sent to you as an end user. The problem with MITM attacks is when you execute programs or exchange money or other private information. The risks when viewing public documents that don't require execution is minimal. That's my point. One use case "web app stores…

You are wrong. Let's take a wikipedia, without TLS nor JS. I can modify that page and the end user won't even know it is now a bunch of crap.

MITM has nothing to do with read-only nor with local execution.

Re: HTTP/2 and HTTP/3 explained

#127

Post by avianlyric »

pi-e-sigma wrote: post #76
avianlyric wrote: post #72

Earlier quoted context omitted.

Have you got any data to backup that claim? It’s also a specious argument anyway. The six connection limit isn’t purely artificial, opening and tracking TCP connection state is expensive, and happens entirely in the kernel. There’s a very real cap on how many TCP connections a machine can serve before the kernel starts barfing, and that cap is substantially lower than the number of multiplexed streams you can push ov…

Yes I do have data. You can have that data, too. Just do the testing yourself.

You’re making the claims, feel free to share the data you already have.

Oh and while doing that, also feel free to respond to the rest of comment that outlines why opening an unbounded number of TCP connections to a server might be a bad idea.

Re: HTTP/2 and HTTP/3 explained

#128

Post by 1vuio0pswjnm7 »

KaiserPro wrote: post #13

> This is called head-of-line blocking. In the diagram below, request 2 cannot be sent until response 1 arrives, considering that only one TCP connection is used. Thats not really head of line blocking, because in HTTP1.1 you'd just open up another connection. The issue with HTTP1.1 is that opening up lots of connections can introduce lots of latency, especially if you are doing Encryption. HTTP1.1 performs much much…

It is imposible to meaningfuly evaluate these different protocols against each other without considering the "use case". For example, if someone is requesting 100 pages from a site, all hosted on the same domain, and nothing else,1 then HTTP/1.1 is the best of the three. The requests can be sent over a single connection. HOL blocking is not an issue. I have tested this exhaustively outside the browser for over a decade. (People promoting HTTP/2 and HTTP/3, and HN commenters submitting snarky replies every time I mention the utility of HTTP/1.1 pipelining, apparently have not tested this at all.)

1. This is text retrieval. The www is not a handful of browsers controlled by companies that seek to profit from advertising. It was and still is a facility that provides for (hyper)text retrieval.

HTTP/2 and HTTP/3 come from an advertising commpany and a CDN that expect ads hosted on different domains in every page. That is what _they_ want. Is that want _www users_ want. We do not know because www users were never asked. We do know that www users do not like ads. When given the choice, they say, "No."

The advertising company keeps repeating this HOL blocking as a problem of HTTP/1.1, and now it gets parroted everywhere, and few even know what it means. HOL blocking is not a problem if the www user is not requesting ads and tracking from different domains. How many www users actually want to request ads and tracking and particpate in telemetry. The so-called "tech" company might try to argue that all of them do, or more commonly that, "They do not care." Meanwhile its own employees call ad blocking a "right of passage" (direct quote from a reply I got on HN).

The truth is that when evaluating these new HTTP protocols, it matters what the www user is trying to do. Many users are simply trying to retrieve information as text. But the advertising company believes that www users only want to do what is in the interest of the advertising company: let the advertising company's browser automatically send requests for ads, tracking and telemetry purposes. (Except for employees of so-called "tech" companies profiting from the sale of online ad services. They exempted and are free to block the ads and tracking.)

Re: HTTP/2 and HTTP/3 explained

#129

Post by avianlyric »

superkuh wrote: post #124
JackSlateur wrote: post #108

Earlier quoted context omitted.

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

Yes. And there's almost zero risk to such (ARP poisoning? dns poisoning? etc) MITM attacks when you turn off javascript and don't blindly execute all programs sent to you as an end user. The problem with MITM attacks is when you execute programs or exchange money or other private information. The risks when viewing public documents that don't require execution is minimal. That's my point. One use case "web app stores…

> The risks when viewing public documents that don't require execution is minimal.

If you’re living in a well developed country with strong privacy laws, you might have a point. But most of the people in the world don’t, and in many places simply looking at LGBT communities can land you in jail.

Then there’s places like the U.S. with multiple states currently doing their level best to criminalise so much as thinking about an abortion. I don’t see why those states would be above scanning people’s clear text browsing habits to any signs of a possible abortion, and using it as evidence of an illegal abortion having been committed or about to be committed. They’ve certainly jailed women for less (even while pregnant).

Just because you’re among a group of people that is lucky enough to have no worries about being oppressed, or discriminated against, doesn’t mean everyone has that luxury. Encryption is good for everyone, I don’t anyone being able to easily know what I do online, because I have no idea who those people, or what their motives might be, and quite frankly I don’t care. I just don’t want them rummaging around in my life looking for opportunities to exploit me or others.

Re: HTTP/2 and HTTP/3 explained

#130

Post by jsnell »

pi-e-sigma wrote: post #118
jsnell wrote: post #117

Earlier quoted context omitted.

In reality it's quite hard for somebody to observe that themselves using just their smartphone. The only way they can do it is by getting a packet trace, which they won't have the permissions to capture on the phone, nor the skill to interpret. (Ideally they'd want to get packet traces from multiple points in the network to understand where the anomalies are happening, but that's even harder.) In principle you could…

Modern mobile networks use exactly the same protocol to carry voice and data. Because voice is just data. When your call is fading or being intermittent then the packets are being dropped. In such situation packets of your mobile data for instance a web page being loaded by a browser are also being dropped. Mobiles drop packets left and right when reception deteriorates or there are too many subscribers trying to use…

But I am not saying that HTTP/2 or HTTP/3 are magic that fix packet loss in mobile networks.

I'm saying that from the point of view of either endpoint, there is very little packet loss in mobile networks, because of error correction and retransmissions being handled at the physical layer. This is the third time I've written it. Both previous times you've not answered that, and instead made up a strawman about HTTP/2 and magic. Why do you keep doing that?

Do you not believe that cellular radio protocols do error correction? Or that they do retransmissions at that level, rather than just try transmitting each packet once and then give up?

Post reply on HN