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"
Microsoft has announced their implementation, DirectSPEW.
It's going to kill SPDY when it debuts in a few months with Windows Phone 7.1.
Hi bonch
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.
Maybe Google could remove all the useless Google Adsense ads first because the main reason why pages load so slow is because of the million ad calls to Google?
By default, a web browser opens an individual connection for each and every page request, which can lead to tremendous inefficiencies
HTTP1.1 which is supported by everything newer than IE5 (at least) utilizes persistent connections. You can verify this yourself with Wireshark in seconds. SPDYs optimizations largely revolve around "pipelining", but without some of the issues that it causes.
"[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!
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).
I'd like to see SCTP getting some love, which sadly enough seems unlikely if it hasn't happened so far. It's a very simple protocol mixing the good parts of both TCP and UDP, plus it supports multiplexing and priorization off the bat.
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.
Great! But will it do anything to speed up pages that refuse to display until the advertisements do? Even Slashdot takes longer to display because of some third-party ad server.
XHTML largely fixed that by banning document.write(). Unfortunately the "industry" didn't like that and produced the enormous brain-fart known as HTML5, which went back to allowing all the crazy shit that XHTML had banned for a good reason.
http://blog.nexusuk.org
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.
The speed benefits provided by this new protocol will rapidly be negated by the ability to cram more shit into each connection.
By choosing TLS as the underlying transport, inspecting traffic for debugging or monitoring purposes becomes nigh on impossible. It will only be possible to capture traffic at the application level, after decryption and decapsulation (which, depending on the nature of any given bug, may be too late), or if it originates from servers you own (i.e. the server's private key is available to you). SPDY proxies will become dumb pipes, unable to perform any sort of content caching, unless users are willing to accept that the proxy may perform MITM on their traffic. For such MITM to be feasible, users need to trust a CA certificate associated with the proxy, and rely on the proxy performing upstream certificate checks on their behalf, because the browser no longer has a single end-to-end TLS session with the origin server. In corporate and other "managed" environments, people often find this acceptable in moderation*, but I would be worried if this became the norm - it creates a mind-set whereby it's acceptable to breach users' privacy, and the more proxy vendors have incentive to implement the necessary (proprietary) code, the more scope there is for them to get it wrong, completely undermining security.
Not to mention that introducing a mux/demux layer in between the network traffic and the individual requests/responses greatly increases the complexity needed to implement a proxy compared to plain-old HTTP.
Losing the functionality of caching proxies would seem counter to Google's goal of speeding up the Web. Losing the ability to monitor and filter network traffic will greatly diminish the ability of schools, employers, public hotspot providers etc. to enforce acceptable usage policies, to the extent that some - especially employers - may simply resort to blocking web access outright.
IMHO, the behaviour of SPDY proxies needs to be tightly specified, if they are going to exist. Standardise MITM behaviour, so that users and admins are aware of the pros and cons. Make it mandatory that end users are warned when MITM is taking place. Perhaps introduce new extensions, such as the ability for the proxy to establish TLS with the browser using its own certificate, but transmit a copy of any origin server certificates corresponding to proxied requests, so that the browser isn't entirely at the proxy's mercy WRT certificate verification. Perhaps introduce the ability to multiplex requests to different domains on the same connection, something a browser can't do when talking directly to distinct origin servers.
Note that similar concerns apply to reverse proxies, used by website providers themselves to speed up their own infrastructure. It may seem desirable for both front-end caching and back-end servers to use SPDY, but establishing TLS sessions between two halves of the same infrastructure, over the LAN, will be detrimental to resource usage.
* Bear in mind that currently, MITM is only necessary for HTTPS sites, which means that there are vast swathes of in-the-clear HTTP traffic for which caching doesn't introduce any inherent security concerns. By making *everything* use TLS, MITM becomes a consideration if you want to perform *any* caching/filtering at all, not just caching/filtering of secure sites. If there is no longer any distinction between secure and insecure sites, how does even a responsible admin know where to draw the line?
As one of the creators of SPDY I can say: SPDY as specified today requires TLS and is only deployed using TLS.