Live data from Hacker News

HTTP/2 and HTTP/3 explained

alexandrehtrb.github.io

131–140 of 155 posts

Re: HTTP/2 and HTTP/3 explained

#131
post #57

Earlier quoted context omitted.

Wouldn't it be more likely that maintaining backwards compatibility (an important Windows trait, after all) while also implementing all of Powershell would be a considerably more difficult task than just making a new scripting environment?

yes, too much to ask for a multi-trillion company, especially that this company was until recently well known for maintaining crazy level of backward compatibility

But… this is backwards compatibility. The command prompt is backwards compatible. Sometimes the best way to ensure that is to preserve in amber and replace.

Re: HTTP/2 and HTTP/3 explained

#132

Earlier quoted context omitted.

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

In wireshark logs that I saw TCP almost immediately resends the lost packet and exponentially slows down after the resent packet is lost.

Re: HTTP/2 and HTTP/3 explained

#133

Earlier quoted context omitted.

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.

You can just put a bunch of crap in wikipedia itself, TLS doesn't help much here.

Re: HTTP/2 and HTTP/3 explained

#135

Earlier quoted context omitted.

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…

TLS doesn't hide destination address, if you connect to LGBT site whose IP is known, you land in jail anyway.

Re: HTTP/2 and HTTP/3 explained

#136

Earlier quoted context omitted.

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.

You can just put a bunch of crap in wikipedia itself, TLS doesn't help much here.

This was an example..

Re: HTTP/2 and HTTP/3 explained

#138
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…

I should have made clear that this is mobile performance. Desktop performance was broadly good

Re: HTTP/2 and HTTP/3 explained

#140

So we squeeze a tiny bit more performance out of existing networks, then that immediately becomes normal again. Except now we have protocols that are difficult to implement, debug and understand.

Implementing concurrency in network protocols seems to be more than just a tiny improvement
Post reply on HN