Hacker News new | past | comments | ask | show | jobs | submit login

Where's the research that says that the connection overhead is destroying humanity?

Back when we I had a 14.4k SLIP dialup and RTT of 200ms+ connection overhead and TCP channel overhead was a major drag on throughput but it's not like that now. I'd be surprised if there was a tangible difference to the end user.




> Where's the research that says that the connection overhead is destroying humanity?

It's destroying big business who push lots and lots of resources to the browser:

- From an admin POV, you have to shard your domain => more work, more maintenance.

- From a browser POV, you have to open multiple TCP connections => you take slow start and TLS handshake in your face for each connection + the connections have to fight each other because the OS wants to be fair among TCP connections

- From a web admin POV, you want to inline your content to reduce round trips => you have more work to do on your resources

SPDY is certainly not necessary for everyone (it mostly benefits those who push lots of different resources), that's true. We're talking about businesses who lose a month worth of revenue if the latency to their site explodes from 50 ms to 500 ms.

But it still is interesting because the actual usage _on top of HTTP_ doesn't change: you still have your websockets or your Server-Sent events, you still have your keepalive, you can do a simple-stupid "one HTTP call per resource" and it will be handled efficiently, sometimes SPDY will work underneath to push content so that the next HTTP call will actually hit the cache without you knowing about it... all at the cost of changing (or updating) your library. Because you certainly don't write HTTP text directly to your TCP socket.

The interesting point will be for those library developers. The added complexity will certainly make it harder, but on the other hand the binary format and strict rules will make it easier to parse the messages... I'd like to see where it goes here.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: