Slashdot Mirror
Google's SPDY Could Be Incorporated Into Next-Gen HTTP
MojoKid writes "Google's efforts to improve Internet efficiency through the development of the SPDY (pronounced 'speedy') protocol got a major boost today when the chairman of the HTTP Working Group (HTTPbis), Mark Nottingham, called for it to be included in the HTTP 2.0 standard. SPDY is a protocol that's already used to a certain degree online; formal incorporation into the next-generation standard would improve its chances of being generally adopted. SPDY's goal is to reduce web page load times through the use of header compression, packet prioritization, and multiplexing (combining multiple requests into a single connection). By default, a web browser opens an individual connection for each and every page request, which can lead to tremendous inefficiencies."
Its a secret plot by Apple to fix the lag in IOS 5 Safari by getting Google to find a way to speed up web page loads to cover it up!
"Computers are a lot like Air Conditioners" "They both work great until you start opening Windows"
I realise that SPDY is about reducing the latency of HTTP connection handshakes -
but wouldn't using the already existing and even implemented HTTP 1.1 standards
for pipelining (requesting multiple resources in one request) and keep-alive (keeping
a once-established connection open for reuse) mostly remove the handshake latency
bottleneck?
... embedded links that activate scripts/contact other adservers, etc. There is so much junk embedded in modern web-pages that most users have no clue how bad their client is being raped of accumulating identifiable information.
"[T]he SPDY (pronounced 'speedy') protocol ....
No WAY am I pronouncing it 'speedy'. I'm a callin' it 'spidey'. That way, I can build wearable network monitors which vibrate at high frequencies when the web server gets bogged down.
And then.... I'll be able to interrupt my boss in mid-sentence and say, "Hang on, my spidey sensors are tingling..."
Crumb's Corollary: Never bring a knife to a bun fight.
Several mobile phone companies and some browsers offer special proxies nowadays to speed up browser experience on mobile phone and to reduce data usage for customers by serving prerendered or otherwise optimized/reduced pages. This might severely reduce Googles ability to collect user data from these users on the visited web pages (unless the user is logged in to google+ or alike with his browser, which might be unlikely given that for social networks there are usually separate apps).
Is this now a step to reduce the need for these proxies in order to protect their own business?
Trolling is a art!
By default, a web browser opens an individual connection for each and every page request, which can lead to tremendous inefficiencies
... SPDYs optimizations largely revolve around "pipelining", but without some of the issues that it causes.
No no no... You're using the wrong definition of "pipelining". First you must realize the Internet is a Series of Tubes. The Series part is important because TCP is a Serial protocol. If any Tube in the Series cracks and data is lost, endpoints start spewing packets all over the place in alarm! SPDY's optimizations revolve around "pipelining" -- That is: Lining the Pipes to prevent such events from happening in the first place.
HTTP1.1 is OLD! The pipes built around that time are OLD too. The HTTP1.1 "pipelining" is starting to wear through after 17 years... Connecting the Tubes is expensive too; If a Header is compressed there's less chance of part being lost in a data leak when it flows through the tubes.
There is an underground movement to get rid of the whole ridiculous idea of Tubes. I mean, Why would you take something as permeable as a NET and build a Series of Tubes out of it?! OF COURSE YOU NEED PIPELINING if you want it to be efficient!
However, what if you didn't need a "pipe" what if you could get your information from the Sea of Data by Casting about the Web and sorting out the results on your end? You could simply keep trying until you were satisfied with the data you had. Even better if relevant data could be naturally organized -- swarm together -- in a sort of BitTorrent so you could get the data in the Net with less Casting... One could even take the center out -- Decentralize it -- to help prevent conflicts about which data came from what side. I mean: Who cares if someone wants to DownLoad a car so much that it's undrivable from all the weight? It doesn't make your car any less usable! Besides, the naysayers are all Hypocrites: They have to participate in the things they say are wrong just to even see into what we're doing -- You have to Peer to Peer!
Don't even get me started on Cloud Computing! Seriously... It's VaproWare!
SPDY is a great example of someone thinking only of their own application.
By increasing the initial window size from 3 to 10 they add to the bufferbloat effect (at the microscopic level) and increase Jitter from tolerable 38 ms to intolerable 126 ms on a 1 Mbit/s ADSL line. This level of jitter severely affects VoIP sound quality. And for this calculation I have assumed that the web browser only uses one TCP connection to load the page; if it uses two TCP connections the Jitter may double.
But hey! What does any application developer care about other applications? They are only concerned about getting their own application sped up.
When you improve the performance of your application, you should think about how it degrades the performance of other applications. If someone recommended increasing the O/S priority level of the web browser to the maximum, so all your other applications slowed down to a halt while the web browser was running, you would probably object. The increased initial window size is a comparable recommendation, but at a network buffering level, so very few people understand its negative side effects.
We all want faster loading web pages, but we also want other applications to respond faster, and we also want perfect VoIP sound quality without the walkie talkie effect caused by high latency or jitter.
I have that option too, but I'm willing to allow Slashdot to make whatever meager income they can by my presence since they're kind enough to allow my positive (and negative) contributions.
That's a really poor way of describing SCTP. Firstly the relationship between TCP and UDP is such that TCP could be built entirely ontop of UDP, the only reason it isn't physically is so that the port numbers for UDP and TCP are distinct. On the other side the best description of UDP is actually "Bare IP packets with port numbers".
SCTP is not that, it would probably be most accurate to describe it as being a protocol with multiple TCP streams in both directions within one connection. Because it's within a single connection a 'stream' can be very small (ie a little message) and still be efficient and because there are multiple streams messages don't have to wait for each other; though they can if you want. It is probably simpler that TCP, but only because TCP has had so much bolted on.
But you are absolutely correct, this would be a very good protocol for throwing a load of tiny requests at a web server and getting the results back as soon as they're ready. BUT, mixing it with SSL would not be very simple, I guess you'd have to do what OpenVPN does.
I realize you guys are just kidding, but there's a very important and overlooked part of the SPDY protocol. Hopefully TPTB won't understand its implications before it's too late to stop SPDY adoption.
You see, the way I read the spec and the way it's currently implemented, SPDY requires every single connection to be encrypted. It's not optional.
Imagine that, a world where MITM attacks suddenly become much much harder, where your ISP doesn't inject ads in your search results, where your mobile provider cannot "help" you screwing up your HTTP connections with a transparent proxy, where the British government cannot censor a Wikipedia page, where even the small sites can be encrypted because web hosts save bandwidth money by offering this option to everyone.
Imagine a world where net neutrality becomes much harder to break because all big protocols are encrypted all (or at least most) of the time and the deep packet inspection shit that's used much more widely than people think just doesn't work anymore.
SSH, Freenet, Skype BitTorrent and other P2P protocols are already there. This is the chance to do it for HTTP.
Disclaimer: I speak only for myself and not anyone else. IANARE.
There's a hidden treasure in Python 3.x: __prepare__()
Go to about:config and switch network.http.spdy.enabled.
Mozilla has been quite critical of some Google technologies (Dart, Native Client, ...) that it saw as not truly open and closing down the internet to be the GoogleWeb. SPDY got implemented though. So I guess it's a a keeper and might see wider adoption.