Google has tested its speedy QUIC internet protocol on YOU – and the early results are in Google says its homegrown QUIC networking protocol can speed up web browsing – enough so that it's planning to propose it to the IETF standards body to make it part of the next-generation internet. The online advertising giant has been quietly working on QUIC since 2013, after successfully having its work on the SPDY protocol …
Beat me to it,
I too have avoided Google for a long while. As AC says use Duckduckgo and keep away from Google's prying eye. As for Chrome, forget it, I'll stick to Palemoon, all the Firefox goodness without the Australis crap.
"So when do we all get to benefit from this?"
That made me chuckle, Google doing something altruistic or in the public interest? Might be in another reality but not this one sadly.
Thanks for the Palemoon reference. While I have no strong preference for/against Australis, I'm not a fan of the new sync mechanism. There's no way I'd store my sensitive data and related encryption key at someone's server (no matter how much I trusted them). Old/roll your own scheme was much better (if cumbersome for some) and should remain an option for these that care, especially that mobile platforms removed the secure offline "copy profile folder" option. Palemoon's sync seems nice compromise between security and convenience (and I may give it a try).
Well, once the VCs decide to monetize DuckDuckGo, then I guess you are out of luck. DuckDuckGo just needs 30 days to "substantial update" their privacy policy, per their existing policy. And I guess no time at all, if it is not a "substantial" change. And since DuckDuckGo is apparently not making money, that is just a matter of time. I guess at that point, all of the Freetards will flee DuckDuckGo, and go to the next startup.
DDG only gets better. That being said, I'm wondering how much longer it can mature without Google, MS, or Yahoo stepping all over it. It's turning into a beast, and I'm sure that is not being ignored by the other players.
If you've used DuckDuckGo over the last 6 months or so, then you've seen how it's starting to "learn". If you've been shopping with DuckDuckGo recently, then I seriously doubt you'll be using anything else for the time being. For a search engine that is not fully frontal commercialized, it's ironic how great it is at shopping. For non-shopping, it still needs some more learn'n, but it's happening.
Building a transport protocol on top of UDP is usually a red flag. The 2RTT TCP handshake is there for a reason. There have been proposals to simplify it, e.g. T/TCP, but those have not been widely deployed, nor have extensions to TCP like SACK (RFC 2018) or Quick-start (RFC 4782) that address other shortcomings in TCP.
Many of the proposed "fixes" to TCP over the years were designed by people who do not understand the issues, work only in best-case scenarios and lead to severe failure modes or even affect the stability of the network. Considering all the proponents of QUIC are browser engineers and there has been little to no review by protocol design specialists like Sally Floyd, I would err towards assuming this is an illustration of the Dunning-Kruger effect at work and yet another half-baked idea from Google with the potential to do real damage.
SPDY runs over TCP
And it's not very good.
It largely "form[s] the groundwork for the IETF's HTTP/2 standard" because the IETF tries to standardized existing practice, not invent new; and even more so because the IETF was scrambling to get something onto the standards track. The HTTPbis Working Group was apparently going to take forever to get an RFC together, and Google was in effect threatening to do to the IETF what WHAT-WG did to the W3C - impose a de facto standard by force of numbers and undermine the standardization process.
But SPDY did not win on technical merit, nor on innovation, nor because it addresses most of the more-pressing issues with HTTP/1.1. It addresses precisely what Google cared about, which is lowering their costs.
The ever-controversial Poul-Henning Kamp has a decent piece about it in ACM Queue. While I can't (ever) agree with everything Kamp says (in this case, for example, that HTTP hasn't changed since 1989; that's just a silly claim), I tend to agree overall with this piece. I wasn't impressed with SPDY, and I'm not impressed with HTTP/2.0.
And I can claim a little expertise in this area. I've been working with a wide range of comms protocols, including the prominent IP-based ones, since the '80s. I've written client and server implementations for several, including HTTP/1.0 and 1.1. I've debated niggling details of HTTP/1.1 in places like comp.protocols.tcp-ip, where other folks with some expertise hung out. I'm not an HTTP specialist, but I've had my hands in its guts more than once.
Have you ever read the amount of criticism about SPDY and its offspring? Now Google is in the position and with the weight to enforce its own protocols.
Another stupid Google protocol is WebSocket, basically TCP over HTTP, just for the need of Google to bypass firewalls to be able to access and gather more and more data.
The very difference is that protocols like the TCP/IP suite were designed to be application agnostic and serve any kind of application present and future. Google is designing protocols around its browser needs. Very, very different approaches and drivers.
Well...it doesn't really matter if it's half baked, it can still be used for non-internet functions (if it functions as advertised). But, even if it is half baked and everyone knows it, it might not matter because they are proposing this spec to a panel of people who just might consider Google as the almighty (or at least an employer!).
I truthfully don't know WTF Fazal is talking about, he's clearly informed. I just fear that the people who will ultimately accept this spec also don't know WTF Fazal is talking about. But then again, maybe Fazal doesn't know WTF Fazal's talking about (had too, it was just 'there'! :-) ).
No, it's just someone at Google has just discovered "stateful connections"...
No, as others have already noted, they discovered DTLS (ugh), TLS session resumption (moderately ugh), and reinventing TCP over UDP (a crime against nature).
I'm not particularly worried, though, since I never use Chrome; and if Mozilla insist on putting this in Firefox, it'll almost certainly be easy to disable (as SPDY and HTTP/2 are).
I thought they had done that... oh wait, that's just me & my browser extensions....
+1 regarding pushing things out over UDP. UDP over a WAN seems like a really bad when you need all the data. You're just shifting the reliability problem elsewhere.
Personally, I like simple protocols. All these optimisations may benefit companies like google, but there's little for the end-user which can't be solved in a better manner and it raises the barriers to entry to the market and makes troubleshooting really quite hard.
It's like complaining about map load times on gmaps. The better way is not to load them at the very last minute. You could, pre-download them into some sort of portable device...
Wow! Just imagine, over the course of the rest of my life I might save.... an entire HOUR! Just think of all the things I can do in one whole second. I could sniff, or blink, or maybe burp or even perhaps fart. But wait, these are things I can do anyway, while I'm waiting that second for the page to load. In fact, they're things that are *better* done in dead time while waiting for a page to load.
Seriously though, are people really *that* busy that saving a second on a page that takes 3 seconds to load really makes a difference to them? They need to be forced to use 33K dialup for a month. In my day we used t'use a piece o' wet string wi' two plastic cups....
It's more relevant in places where bandwidth is crap. In my experience (sample size 1) Bangalore's mobile data networks spend about 2 hours a day being so congested they barely function and a further 4 or so taking more than 5 times as long to load sites as at off-peak times.
Because users are being added at a higher rate than bandwidth capacity (I confidently assume, though I have no hard evidence) anything that can help to mitigate that will be extremely positive for my mental wellbeing and for the prospects of the many online web 2.0 apps that would be really useful but which barely function for long periods of the day.
Which would be all well and dandy if this proposal had anything what so ever to do with reducing bandwidth. It doesn't - at best you would save some control headers which are tiny - so if you network is bandwidth congested you're still screwed.
OK, I searched for some data and here's some. 2012, 1.2 trillion Google searches. Obviously that's a tiny proportion of the number of internet page loads in that year, but even that number, improved by one second each equals 38000 years of time saved.
Obviously, individually none of us can feel that time being saved. That doesn't mean it isn't real.
block UDP at their firewalls?
I use UDP for SNMP. No need for it to get routed out onto the Interwebs. As has been said, using UDP is fast but IMHO that is because no one in their right mind wants to route it.
Savvy Net Admins will already be dreaming up blocking rules for Google's little tricks.
Some posts have talked about DuckDuckGo. I use 'Startpage'.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
