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"
Things that get refreshed often dont get cached anyways. AJAX interactions mostly.
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.
What about alternatives like UDT, and SCTP?
Shai Schticks:"You don't make peace with friends, you make peace with enemies"
"[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!
We have other protocols, like FTP for example, that handle things besides web pages. HTTP is a pretty wide open protocol and allows all sorts of things to be jammed in to it, which is why it's worked so well in the past.
Also, as they say, "if it ain't broke, don't fix it".
moox. for a new generation.
Says it all. The connection setup isn't the problem, it's being bounced to 10 different sites other than the one you wanted to visit, half of which are overloaded at any given time.
Fix that instead Google and there's no need to mess with the standards anyway.
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.
HTTP's inception predates the scale at which the Internet is used today, and like IPv4, the failure to anticipate the shifts in use and data access within the Internet make it far less efficient than it could otherwise be. SPDY, along with many of the streaming protocols, identify more with the modern Internet practices than, "Get this page now," technique of HTTP.
I'm on the second tier of my ISP's access rate, and even though many pages should load in the theoretical second, they don't due to modern styling and plugin/include/addon calls. I honestly would have thought that what SPDY does would already have been more commonly implemented, and that data access in general would be moving to a peer/metapeer networking solution to save on demand of resources in general. Some of the assumptions of its design come out of the late-eighties and early-nineties anticipation of the large-first to small-second distribution common among universities, government installations and large commercial systems of the time, where maintaining a large lan with few nodes possessing Internet access in both directions.
HTTP1.1 is as not broken compared to HTTP2.0 as a protocol as XFree86 4.x isn't anymore broken than any of its successors (irregarding explicit bug fixes, as that's not applicable relative to a protocol...usually), but regardless of where you came down on the forks and licensing, you probably aren't running it on any *Nix under 5 years old.
"Yeah...it was the numbers that were irrational, not the murderous cult of vegetarians...." -- Hippasus of Metapontum
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
Opera (offering Opera Turbo), Nokia (http://www.developer.nokia.com/Develop/Series_40/Nokia_Browser_for_Series_40/) etc. are not the network providers, so your argument is moot. They neither save any bandwidth on their side by offering the proxy, quite the opposite, not do they just cache the traffic.
Trolling is a art!
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.
We have other protocols, like FTP for example, that handle things besides web pages. HTTP is a pretty wide open protocol and allows all sorts of things to be jammed in to it, which is why it's worked so well in the past.
Also, as they say, "if it ain't broke, don't fix it".
With all the NAT going around, FTP is becoming less and less useable.
The biggest pro for HTTP is it's universal support, not its openness.
As far as your last sentence is concerned, we'd still be fighting for a little fire if we followed it all along...
Write boring code, not shiny code!
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?
Change your TCP/IP congestion algorithm to something like Compound TCP (CTCP).
Change is certain; progress is not obligatory.
This posting quotes an unreliable news report, and claims that IETF HTTP working group head Mark Nottingham, "called for it [SPDY] to be included in the HTTP 2.0 standard". Nonsense. It's easy enough to find the actual announcement from Mark which says, in part:
Indeed, the proposed formal charter for the new work that's included in Mark's note doesn't mention SPDY at all. I've been in meetings with Mark about this, and SPDY is no doubt at or near the top of the list in terms of interesting candidate technologies to look at, but it's incorrect to say that Mark is calling for its use in HTTP 2.0. At the very least, the Slashdot post on which this is a comment would do a much better service to the community if it linked and quoted Mark's actual announcement, rather than some hyped up misinterpretation from the press. All the conspiracy theorists should calm down a little while, and subscribe to the IETF working group mailing list if they really want to see how this plays out.
Given how long these processes take, by the time the standard is finalised both XP and Android 2 will be outside any promised support window so they should not be used as a reason to hamper this new version of the standard. If people are still using those clients by then they will (or should) have far greater worries than a few "invalid certificate" warnings. Heck, hopefully IPv6 support will be common place by then (while people saying it'll all hit the fan this year are being a bit premature IMO, I can't see IPv4 lasting until the endof XP's life) making the IPv4 based limitations irrelevant anyway.
Even if XP is still around and causing trouble, the only browsers affected are IE variants or similarly old hat code: recent (anything from the last two years or more IIRC) Firefox, Chrome and Opera versions support SNI even on XP as does Firefox on Android (I don't know about others like Opera Mobile).
Interestingly enough, Windows XP and Android 2 also don't support HTTP 2.0, so they're largely irrelevant in this context...
I am TheRaven on Soylent News
As one of the creators of SPDY I can say: SPDY as specified today requires TLS and is only deployed using TLS.