Hacker News Reader

Comment by ithkuil | Hacker News Reader

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 page). Perhaps they thought that people with really horrible packet loss will just fallback to http or use amp or whatever.

But I cannot believe that the mistakes were caused by them just not being aware of how networks work or, worse, failing to talk with somebody that did

View on HN

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 across the entire test suite (this was visible in their screenshots of Chrome's network panel, no connection time for SPDY).

They also never tested SPDY against pipelining - but Microsoft did and found pipelining performed the same. SPDY's benefit was merely a cleaner, less messy equivalent of pipelining.

So I think it's fair to say these developers were not the best Google had to offer.

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.

> But I cannot believe that the mistakes were caused by them just not being aware of how networks work or, worse, failing to talk with somebody that did

As someone who was part of the rollout of HTTP2 for a $large_website, I can confirm that "this will harm mobile performance" was outright and flatly rejected. This included people who were our reps on the w3c. I just had to sit there and wait for the real world metrics to come in

"multiplexing will remove bottlenecks!"

"benchmarks prove that its faster!"

"you just don't understand how TCP works"

"the people at google are very smart, what do you know?"

"server push will reduce latency"

etc etc etc.

We even had the graphs of page size over time (going ever up) and average usable bandwidth (not keeping up, especially on mobile) None of that mattered until the rollout had a real world effect on our performance.

So what was that real world effect?

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!

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

Seeing early QUIC development not account for the DDoS potential of choosing UDP makes it pretty clear that networking is not top-of-mind.

Are you saying there's ddos potential because UDP itself doesn't have a connection handshake? There's still one on top of UDP. The initial packet could be forged, but so could one from TCP (a SYN flood).

SYN flood cookies are probably older than me at this point

Reply on news.ycombinator.com