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 wonder what this means for caching proxies?
No more max-connections increase every new browser (although I must say we noticed when it went from 256 back to 48 on firefox). Multiply 3000+ users, x 48 max-connections per tab, x say 5 tabs, and there's an unhappy proxy cluster... workstations are more multi-threaded than network link/proxy can keep up!
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?
They could at least make it a single one - but as someone already pointed out, there's so many cross-site and domain requests on a single page, and they all want to get their own google analytics report as well :)
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.
We haven't done that yet? Wasn't that a late nineties thing? We're still on a 10 and 20 year old protocol!? Why isn't slashdot using html 1.1? Tables not good enough? As someone who still catches up on the IEEE from time to time, this is actually surprising. No wonder lynx hasn't needed much upgrading for connections beyond bug fixes.
That means all advantages have been the physical pathways (that includes wireless) and TCP! Wow! Based on the fact psychics made it to the front page of slashdot without James Randi popping up, I can only presume most of slashdot has no idea how bizarre that is.
"Yeah...it was the numbers that were irrational, not the murderous cult of vegetarians...." -- Hippasus of Metapontum
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!
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.
of something... i cant remember it right now, because, well, my text reading program has been optimized for ARM NEON, but my smart phone doesn't have NEON, or at least, this version of the driver i'm using doesn't work with NEON, and i tried to port it, but its like i can't find a good way to work around the specialized vectorization code inside of the Eigen2 library because it doesnt work on certain platforms. but if it did work, my text editor would be like 75% faster than some luser running it on a single CPU machine with no NEON optimization.
what im trying to say is, imagine a beowulf cluster, and then imagine you fill it with sand, and drain the sand out, and you film it.
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.
No they don't. They transparently proxy everything to reduce the amount of traffic through their upstreams and peers - because Telcos rape either other with bills in the same way they rape their own customers. That customers get a faster, more responsive connection to popular sites is only an unintended side effect.
At least it's not SPYW..thanks God.
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.
Secret plot by Apple.
Evil Apple, Evil Apps.
GOOG snowed in by Them.
Do you know any methods to improve tethering? I use my 3G phone as a WiFi hotspot. It seems that when the connection is idle for a while, it takes some time to kick it up to full speed. Sometimes when I try to post a message to some forum, I have to load some another page in the background to wake up the link.
Does the TCP slow-start make things worse here, would the connection run better if I encapsulate it to some single tunnel, should I send some constant keep-alive data, can I force an Android phone to stay in full network speed, and so on.
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
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!
That's what my brain translated!
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.
Uuum, that’s why there is the multipart mime type! Also, if you do AJAX, you can request as much stuff as you want over a single HTTP connection. ;)
This is not new guys! I’m using it since 2003! That’s 9 years! (Yes, there was no AJAX when I started. But a <object> tag with a <form>, did just fine for a packet-based tunnel of "Whatever The Fuck I Want (TM)".
Also, all style pictures can be incorporated in one common image anyway. Also done since back then.
The header compression Well, I always thought that should be its own layer right ontop of TCP., or even IP. Encryption already is, so this is a no-brainer.
At least we're finally getting those things at all. Could’ve been solved better though. Luckily I don’t have to care, and can just continue to use my own, better, solution.
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?
In most cases when a web page takes a long time to load, it is not the HTTP connection to the web page's home server itself that is too slow, but ... that the page is waiting for responses from various ad-servers, counters, social networking sites, etc before it can fully render.
I experience that the biggest slowdown on the sites that I visit, have often been caused by connections to Google Analytics.
Thanks Google for making the web faster!
"We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
I realize there is probably a really good reason why they are not using the builtin compression tools available. What are they again?
This is brilliant news!
I was just wondering about this a few weeks ago and how far along it was.
Seems that, very, was the answer.
Finally we are going to go a level beyond the current hack of a standard we have now. Now if only we replaced TCP while we were at it... that's worse in every way possible.
Stupid Microsoft not supporting anything because it requires effort! They sure wasted effort on destroying the common UI for Windows, where did all that enthusiasm go?!
Nothing in the SPDY spec says that connections are encrypted. The only reference to encryption anywhere is that TLS may be the underlying transport rather than TCP. SPDY can be implemented over TCP just as well. Which is a good idea seeing as encryption adds a significant CPU load on the server side. YouTube doesn't want to encrypt everyone's video on the way out.
It's not about "upstreams and peers", Internet transit is only a few dollars per month per megabit nowadays and due to the increasing dynamics of the web you can't cache all that much anyway. That is why proxies are so rare at fixed line providers nowadaysdays.
Afaict the main reason mobile providers run proxies is so that they can recompess images at lower quality and hence save bandwidth on the wireless side (aiui wireless bandwidth is FAR more expensive than internet bandwidth).
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
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.
I'm being genuine; I would like to read about this more. My initial guess would be that increasing the initial window size will have minimal effect on the jitter for both that stream and others it is sharing bandwidth with. First because any TCP connection that is open for for more than a few round trips will quickly grow to a window size greater than 10 anyway, and secondly because it will be broken into MTU sized chunks at the router level regardless of the window size. If I am wrong about this, I would really like to understand.why so I don't remain ignorant.
Can anyone tell me what the chart in the article is actually measuring? The x-axis is labeled "Packet Loss Rate" and goes from 0% to 2.5% and the y-axis is labeled "AvgPLT" and goes from 500 to 3,500. I'm assuming the testers introduced artificial packet loss at the percentages on the x-axis and then measured how each protocol (HTTP and SPDY) responded to these conditions. But what the heck is "AvgPLT" and what exactly was their test? Was it requesting one page with 30 components each around 500KB, or 100 page requests with 20 components of 100KB, or 5,000 requests for 5MB files? or what?
We always knew Comcast was corrupt, here's the proof: http://tech.slashdot.org/comments.pl?sid=1909890&cid=34545432
SNI won't work on BlackBerry devices, old iPhones or iPods, Windows Mobile devices, Android 2 devices, or the browser included with Windows XP. But it works on iOS 4 and newer, which runs on the iPhone 3GS, all retina display iPhones and iPods, and all iPads. It also works on Android 3 and 4 and Windows Phone 7. So we can't rely on SNI until April 2014, when Windows XP reaches its end of life, or two years after carriers stop selling Android 2 phones, whichever is later.
Windows XP and Android 2 can see only the first certificate on a given IP address. With shared hosting providers packing upwards of a thousand HTTP sites on a single IP address, this can pose a problem.
they don't include results for pipelining
Here's a result for pipelining: It causes page loads to fail when used with some servers that have never been thoroughly tested with various pipelining scenarios.
I fail to understand the argument that http 1.1 was just implemented buggy but SPDY will magically be better implemented by the same groups that have failed to get http 1.1 over all these years.
Knowledge of how to build a test suite with better coverage has improved. Knowledge of "tech evangelism", or how to reach out to server operators, has improved since the "if you don't use IE we don't want you as a customer" days.
A good citation on buffer bloat is Jim Getty's ACM Queue article on Buffer Bloat, in which he says:
I've also spoken with Jim about this, and he definitely views SPDY as potentially part of the solution, not part of the problem. In fact, he was the person who first pointed out the existence of SPDY to me.
BTW: the reason SPDY does relative well with respect to bufferbloat is that it multiplexes a lot of traffic over a single TCP stream, and most lower level TCP software and hardware, including routers, tends to bound the number of packets they'll queue from a single stream. Trouble comes when the same application opens a ton of parallel streams, each of which gets to queue several packets; the result is that together they clog the buffers, add to latency, and prevent other application streams from progressing.
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.
How about the spdy:// call routes to a media-light version of a site? You know, one that doesn't try to send the requester 100MB of Flash ads, videos, music, and other nonsense, and 50kB of actual content?
Here's a link to the actual discussion on the HTTPbis mailing list.
Give me some black helicopters, man! Won't someone think of the black helicopters?
HA! I just wasted some of your bandwidth with a frivolous sig!
Even with the whole "web"-"spidey" association, I think they're calling it "speedy" because "spidey" might raise the hackles of Marvel Entertainment, a Walt Disney company.
If the server to which you're connecting is authoritative for all of the redirected sites, and you're using server push with SPDY... actually you could eliminate the RTTs for the redirects even if they were still there (by server pushing them all in sequence). ... but that is just too cute. Getting rid of the redirects would be better :)
That's a good one. Server operators in internal Enterprise IT has by and large not progressed beyond the "you must use browser X". Much of the complaints around buggy HTTP 1.1 revolve around buggy 'enterprise' products that no one with more sense than money would ever elect to use. Nothing stops those buggy implementations from being fixed. The same forces that you may need to rely upon for SPDY to get rolled out would have been the same forces that would have forced existing technology to be fixed.
Face it, the same people afflicted with broken HTTP 1.1 will either see SPDY blocked entirely or tortured into a hideous proxy. Maybe someone can explain how it is easier to get SPDY 'right' and therefore less likely to be bug ridden even coded by random kindergartners, but I've seen even the most straightforward concepts in the world completely screwed over by 'enterprise' IT vendors.
I have seen enough to be convinced there is more to SPDY than HTTP 1.1 enhancements can provide, but blind faith that people implementing it will implement the architecture correctly is not a good bet.
XML is like violence. If it doesn't solve the problem, use more.
Then let me rephrase: Knowledge of "tech evangelism", or how to reach out to operators of web servers available to the public, has improved. And don't businesses big enough to use "enterprise" software need penetration testing anyway? A test suite of attacks on known defects in SPDY servers could be rolled into a pen test package, just as they may already be for HTTP.
Irregard is a state outside of consideration, -ing creates a verb transition to present perfect, and a lack of -less makes it non-self-contradictory. I could have used irrespective, but the term brain dumped at the second, "r," and I continued, regardless.
How you got a score of two for an offtopic comment, that's something we could be discussing, but I'm about to get 0, so, I couldn't really care. Karma to burn for trolls and 'tards.
"Yeah...it was the numbers that were irrational, not the murderous cult of vegetarians...." -- Hippasus of Metapontum