11–20 of 118 posts
Note how SPDY has proven to have limited benefits in the realworld vs a lab. Not that I want to stop their brilliant minds from looking at these problems and trying to solve them, especially on their dime.
I'm all for innovation, but I become wary when a company that controls a sizeable proportion of the browser market-share and also serves a not insignificant proportion of all web traffic makes extensions like this. SPDY, Dart and now this.
why does google need to come up with protocols? does the IETF and other processes in place for over a decade not work for them? I know nothing of the protocol (the link only mentions the 'cheeky' naming scheme and the source in the chrome tree); I'm merely commenting on googles motives...
why does google need to come up with protocols? does the IETF and other processes in place for over a decade not work for them? I know nothing of the protocol (the link only mentions the 'cheeky' naming scheme and the source in the chrome tree); I'm merely commenting on googles motives...
That's what Google is doing, and they're using Google Chrome as their test bed (along presumably, with a bunch of non-Chrome stuff internally).
This is the same thing they did with SPDY. See http://en.wikipedia.org/wiki/SPDY#Relation_to_HTTP for details.
If what you're hinting at is that they should first start some wider discussion about what a next-gen UDP should look like before they start doing anything, then I suggest you look up "bikeshedding". Such a process would never get anywhere.
Can any boffins please explain what impact this might have in practice? Is this just going to mean faster and more secure data transfer, or are there wider implications?
Low uptake as routers will not have built-in support, and admins will be slow to enable it when and if it becomes available (unless its tunneled over another protocol). Why not just push IPv6 adoption?
Note how SPDY has proven to have limited benefits in the realworld vs a lab. Not that I want to stop their brilliant minds from looking at these problems and trying to solve them, especially on their dime.
Care to point me to some sources on these limitations? I'm just curious.
Not as SPDY as you thought:
http://www.guypo.com/technical/not-as-spdy-as-you-thought/
The guy seems to know what he's talking about, and has actually run some tests but the test setup seems kind of weird.
Effectively he's saying "if you only change HTTP to SPDY and make no other changes, then it's 3% slower (though more secure)" or "if you only change HTTPS to SPDY and make no other changes, then it's only 4% faster" assuming your site looks like some kind of average of the top 500 sites.
And his conclusion is much more positive than most of the 3rd party coverage of it:
"I believe SPDY is still awesome, and is a step in the right direction. This study and its conclusions do not mean we should stop working on SPDY, but rather that we should work on it more, and make it even faster."
There would potentially be huge benefits to be had from replacing TCP, but of course that's something the people have been trying to do for a long time and failed. Google has a huge advantage in achieving this thanks to controlling a significant proportion of clients and servers.
I'm all for innovation, but I become wary when a company that controls a sizeable proportion of the browser market-share and also serves a not insignificant proportion of all web traffic makes extensions like this. SPDY, Dart and now this.
Say, you want to design a protocol with reliable delivery and/or loss detection. You will then have ACKs, send window and retransmissions. Guess what? If you don't follow windowing semantics of TCP, then one of two things will happen on saturated links - either TCP will end up with all the bandwidth or you will.
So - surprise! - you have no choice but to design a TCP clone.
[ EDIT ]
That said, there is a fundamental problem with TCP, when it's used for carrying secure connections. Since TCP acts as a pure transport protocol, it has no per-packet authentication and so any connection can be trivially DoS'd with a single fake FIN or RST packet. There are ways to solve this, e.g. by reversing the TCP and security layers and running TCP over ESP-over-UDP or TLS-over-UDP (OpenVPN protocol). This requires either writing a user-space TCP library or doing some nasty tunneling at the kernel level, but even as cumbersome as this is, it's still not a reason enough to re-invent the wheel. Also, if you want compression, it's readily available in TLS or as a part of IPsec stack (IPcomp). If you want FEC, same thing - just add a custom transform to TLS and let the client and server negotiate if to use it or not.
I mean, every network programmer invents a protocol or two in his lifetime. It's like a right of passage and it's really not a big deal. Unless it ends up attached to a brand name, in which case it starts attracting snarky remarks like this one :)