Google Cuts Chrome Page Load Times In Half w/ SPDY 310
An anonymous reader writes "It appears as if Google has quietly implemented the SPDY HTTP replacements in Chrome (well, we knew that), and its websites. All its websites were recently updated with SPDY features that address some of the HTTP latency issues. The result? Google says the pageload times were cut about in half. SPDY will be open source, so there is some hope that other browser manufacturers will add SPDY as well."
Most obvious use (Score:2)
Re: (Score:2)
Re: (Score:2)
HTTP Protocol? Uh-oh...better get some money out of the ATM Machine for a new NIC Card.
Re: (Score:2)
I think I see a problem with your CRC check.
Re: (Score:2)
You know, HTTP IS a protocol, even if it does have the word "protocol" as part of its name. I dont think it is incorrect to refer to it as one, any more than it is incorrect to refer to TCP as a protocol of IP.
Re: (Score:2)
Yes, I am aware that HTTP is a protocol. People often use it for transferring HTML language.
Re: (Score:2)
Sure, just enter it in on the touchscreen LCD display.
And this... (Score:2)
is the "extend" part. Let's hope they don't get any temptation to become incompatible.
Re: (Score:2)
Yeah. Because SPDY is a protocol that's worse than HTTP, and not open to boot... :p
Re: (Score:3)
They're releasing the implementation under a BSD license. And unlike that other giant software company back in the old days, they don't have an overwhelming market share, so they can't just ram new standards down everyone's throats. If they make it incompatible, then nobody will use it. So it looks pretty good so far.
Re: (Score:2)
And unlike that other giant software company back in the old days, they don't have an overwhelming market share
Google's position in search is pretty overwhelming I'd say (except maybe in China). If Chrome is suddently twice as fast on Google websites then all other browsers, then gives the combination of Chrome+Google websites a huge advantage.
If they make it incompatible, then nobody will use it.
It is incompatible with all other websites and all other browsers - it only works with the combination of Chrome+Google's own websites.
If this were not open source, it would be totally evil. But is it fully open source right now, though, both client and server? There appear
Mod Parent down (Score:3)
It is incompatible with all other websites and all other browsers - it only works with the combination of Chrome+Google's own websites.
This is flat out wrong. Just this morning I used Chrome to connect to a test server that was running a node.js implementation of SPDY [github.com]. I verified the connection using chrome://net-internals. It worked well.
There is nothing in chrome that prevents this from working on other domains/websites.
There is nothing stopping anyone from implementing their own server.
End of FUD.
Re:And this... (Score:4, Interesting)
What would be even better though, especially given that SPDY is really an extension to HTTP akin to using GZ compressed data, is if Google were also to write up and submit an RFC or whatever mechanism it is that W3 uses to get HTTP extensions added to the standard, such as it is. SPDY seems very much like a win for both content providers and content consumers to me, so once the details are out there I'd like to think that we'd see fairly rapid adoption by the browsers over the next several months, followed by backend support from Apache, IIS et al with their next major releases.
Re: (Score:2)
Not releasing it to the W3C isn't as big a deal as it was, they'll just throw it into HTML and people will have to guess whether or not it's supported.
Re: (Score:3)
Actually there are people working on submitting to the IETF as a RFC, it takes time.
It just uses an extra header to get it started/switch to the SPDY-protocol. Not only that, but the extension for HTTP to make the switch is already gone through most of the IETF-process.
I wouldn't be surprised if the biggest hold up is actually websockets. Because the new 'HTML5' websockets where found to be insecure, atleast in combination with transparant caching proxies that didn't implement HTTP properly. Java and Flash
Re:And this... (Score:4, Insightful)
Re: (Score:2)
With Honeycomb, doesn't Google have a history of saying things will be released as open source, and then not releasing the source?
Troll much? No such history exists. You made that up.
Google has repeatedly stated when honeycomb is completed, thought to be the merge of 2.x and 3.x code base, it will be released to the public for general consumption.
How does Google saying something entirely different than you present, and a long, long history of them following through on exactly what they said, with Android itself in complete disagreement with your delusion, imply they have a history of doing what they've never done?
My SPDY sense is tingling (Score:4, Funny)
:-)
Use in HTTP Servers (Score:3)
When can we expect the SPDY protocol to be implemented in HTTP servers like Apache or Nginx? Does anything need to be done? The summary only talks about adding support to the client portions.
Re:Use in HTTP Servers (Score:5, Informative)
http://code.google.com/p/mod-spdy/ [google.com]
Have no page load problems (Score:5, Interesting)
Re: (Score:3, Informative)
Re: (Score:3)
That's just bad code. The author of the page should at the very least be putting the call to Google Analytics below the footer. Preferably, they'd make it a callback to document.ready().
Re: (Score:2)
Not sure how you're on slashdot and don't yet know about it.
Re:Have no page load problems (Score:4, Insightful)
Re: (Score:3)
We choose not to block polite ads, that don't slow the system down or distract. I don't want sympathy; I want technology that makes polite advertising feasible so that web sites I like can support themselves without having to charge me.
Re: (Score:2)
I also notice much of my latency is due to DNS lookup. I've never understood why DNS lookups aren't locally cached by default. Even a cache with a 10-minute timeout would speed things up a lot (and, really, how often does any web site change their IP address?).
Re: (Score:2)
You can run a local cacheing DNS server.
Re:Have no page load problems (Score:4, Informative)
Normally, DNS lookups *are* locally cached by default....... if you're on Windows, try running ipconfig /displaydns
The problem might be with your upstream resolver(s). If you use your ISPs resolvers, maybe they are are overloaded? Or if you are using a non-ISP upstream cache, maybe it's sparsely populated? Either of these would make initial lookups slow.
You could give Google's public resolvers a try and see if they improve your lookup times: 8.8.8.8 and 8.8.4.4
Re: (Score:3)
Win7 already does this. The DNS Client service performs caching of queries.
Re: (Score:2)
You mean Windows 2000 already does this.
Re: (Score:2)
I have noticed the same thing in my house. Our DNS server that we get from Qwest can take as much as 10-15 seconds to resolve DNS queries sometimes (this is not all the time but when it happens its a major pain). I have dnsmasq running on my Ubuntu box (which will use OpenDNS to resolve cache misses instead of the Qwest DNS server). This makes cache misses faster than they would have been anyway, and cache hits take 0ms. I have switched over all of the computers in the house (both Windows and Linux boxe
Re: (Score:2)
>Does anyone here know if there is a way to tell it to keep all entries for at least some length of time (e.g. 1 day) before considering the info stale?
AFAIK, you can only override TTL values if you use a broken or modified resolver. Also, it is generally a bad idea to second guess the domain owners intention (e.g. upping the TTL will probably screw up their load balancing/maintenance assumptions).
Re: (Score:2)
"I've never understood why DNS lookups aren't locally cached by default."
As far as I know, they are. Are you using a web proxy? Because if so, unless you are also using a proxy autoconfig ("PAC") javascript file, you are implicitly delegating DNS lookups to that proxy. That may be why you're seeing some DNS lookup latency.
"(and, really, how often does any web site change their IP address?)."
Among other things, websites hosted by CDNs (Akamai, etc.) give different IP addresses to different clients (or even t
Re: (Score:3)
google "namebench". It's a google code project. I think current version is 1.3.1 Download it, run it, and be amazed. You can speed those DNS lookups significantly if you only know which servers to use. Don't expect it to be a ten second operation, though. Plan on spending ten minutes, minumum, with it. More reasonably, give it thirty minutes. Use namebench's recommendation, or modify it as you see fit. My own latency with the default ISP server was out of this world. In fact, I couldn't find a
Sources of page load delay (Score:2)
What I notice is that when the page goes to google analytics that load process stops while waiting for the server. There was a time when pages would load partial content, and then go for the ads. Now, many pull the ads and analytics first. This would be good if the ad servers were fast, but the seem to be getting slower.
Right. I've commented on this before. If a page loads slowly today, it's usually for one of three reasons.
The SPDY approach won't fix any of these problems. Client side last-mile bandwidth usually isn't the bottleneck. It
Re: (Score:3)
My rule is that if a script from an external site slows down my page loading long enough that I can see it saying "Waiting for ..." in the status bar, then that site gets added to my hosts file.
I'm 120 miles away from my powered off laptop, otherwise I'd post you the worst offenders here.
Detailed info on SPDY (Score:5, Informative)
http://www.chromium.org/spdy/spdy-whitepaper [chromium.org]
Re: (Score:2)
Interesting. I see nothing in the technical documentation that would lead it to be significantly faster than modern HTTP.
It has exactly the same overhead for establishing connections, since it uses TCP, and HTTP has no additional connection overhead. It compresses HTTP-headers which might helps a few procent on small requests, but not much. It allows multiple requests within the same TCP connection, but then so does HTTP 1.1 by pipelining.
I only see sources of more bugs. The short version is that SPDY is HT
Re: (Score:2)
Actually you don't even gain compressed headers. Since SPDY (which is a made up initialism just to be "cute") uses SSL to bypass proxies you could already compress with deflate or whatever else people want to standardize on.
And why hasn't SCTP caught on? Because like SPDY it doesn't solve an actual problem people have.
Re: (Score:2)
1. SPDY uses 1 TCP-connection, instead of many. Which makes it faster. The time to establisch a new TCP-connection is a lot of overhead when you visit a webpage which has many small elements on it. It also has a big advantage when using HTTPS. Again because you just use the one TCP-connection (no extra SSL-connections to establish):
http://www.chromium.org/spdy/spdy-whitepaper [chromium.org]
2. It is backwardscompatible and doesn't need any operating system changes like SCTP or different firewall settings and so on.
Yes, I k
Re: (Score:3)
This is what is called pipelining in HTTP 1.1. It is not required by HTTP, but even 10 years ago when I last checked only Microsoft didn't support it. They do add the ability to
Re: (Score:2)
You mean, pipelining is actually used somewhere? Most browsers (but Chrome) have support for it, but it is disabled by default.
Compressed headers are a major thing. Have you noticed all the bloat browsers send by default? Heck, I tried to disable them in Firefox -- you can alter but not remove junk completely, you need something like privoxy. This includes headers that are harmful (Accept-Language[3]) or utterly useless (Accept-Charset[2], Accept[1]). All that crap has no chance to fit into a single pa
Re: (Score:2)
Pipelining isn't used because it is incompatible with some older servers and I think some proxy servers.
Also TCP/SSL/TLS handshakes are per connection, not request. But SPDY just needs the one connection, a modern browser when visiting some sites can open up to 20+ connections. That is a lot of unneeded overhead. Although you only get 20+ when you use something like 5 different domains, so with SPDY you would still be using 5 connections one per domain.
(the numbers are a bit made up, but gets the point acro
Re: (Score:2)
I can see how they can cut a round-trip with server-push. You request foo.html, and besides giving you that file, it also sends img1.jpg and img2.jpg, that you would likely request anyway.
And doing this over TCP is quite nice. In the ideal world, SCTP would be better, but NAT routers en masse would need an upgrade, so it probably wouldn't happen until the whole world uses IPv6.
Why people is not upgrading standards all the time (Score:2)
Well.. creating standards or changing standards is bad. You break things, stuff stop working, people get angry.
Theres always some ways to cut corners and optimize everything withouth touching the standard.
Then you see that the standard is really unappropiate for the problem, and that a simple change on the standard coud unlock freedom and speed.
So you create a new protocol. But you find that such protocol break a lot of routers and proxys (very old, buggy, crappy, undocumented using, proxies).
Then you see
Re: (Score:2)
Where the hell do you come up with this?
Standards are always being tweaked/change, but it's up to the companies seeking to make those changes doing it in an ethical way that matters most. While a lot of companies do a lot of unethical shit, the standards (and requirements of standards) do tend to speak for themselves. If this was some "Chrome-only" feature they wouldn't document it and/or open source it. If this is truly anti competitive you would hear the world shouting about it by now.
Re: (Score:2)
I don't know why you are rambling on about this.
The people working on SPDY submitted or working on atleast 3 different drafts for different changes to the IETF for backwardcompatible changes (SSL/TLS False start, HTTP-header for upgrade-to-SPDY and SPDY) that I know of.
"will be open source" (Score:2)
Why wasn't it open source from the start?
Look what happened to symbian...
(Well, maybe I should rtfa but I'm already killing precious time by reading slashdot so that wouldn't be nice..)
Re: (Score:2)
Yea, and look what happened to Chromium!
Oh wait...
Re: (Score:2)
Actually the article and summary are wrong, this has been part of the Chromium project from the start and always was.
thank you, finally (Score:4, Informative)
Finally a story for us geeks that want geek stories....I guess cmdtaco is slowly waking up....
Re: (Score:2)
It isn't the browser that has problems with pipelinging, it is some old (proxy)servers.
Wait a Minute (Score:2)
Re: (Score:2)
Because one company has done things like that before, the other has not. Actions speak louder than words.
Re: (Score:3)
No. Not everyone. Somebody would be saying "If Google had done that you wouldn't be complaining".
Re: (Score:3)
It is however still a draft because the protocol is not finished yet.
Re: (Score:2)
You'll not find very many organizations on the web that can equal MS proven track record for evil. Sure, there's SCO, but how many others can you name? To date, all of the evil attributed to Google is so much "What if" and "They could have done better" and "Look, they have money, they MUST be evil!"
Google does alright with "dumb" and "stupid" now and then, but as has already been pointed out by other posters, they just suck at "evil".
Embrace, extend... (Score:2)
n/t
SPDY means what? (Score:3, Funny)
I am thinking Google did not learn the lesson from the SCSI acronym. Initially, the creator of SCSI wanted it to be pronounced "Sexy" and we ended up saying "Skuzzy." Obviously, Google wants this to be pronounced as "Speedy" but I can easily see this becoming "Spoddy."
And I have looked around a bit... I still can see where SPDY is defined anywhere as to what the letters mean? I can imagine a lot of meanings... except for the Y. (Standard Protocol no aDopted Yet)?
SPDY - server push (Score:5, Insightful)
My favorite part of the SPDY is server push: now advertisers can clog my internet channel and hog the browser with ads long before the AdBlock kicks in. Or a hacked site would host malware and load it onto potential victims harddrives in parallel to normal surfing. Imagination is the only limit - of how it can go wrong.
For the security reasons, I think SPDY is a bad thing.
And I'm personally not bothered with 1-2s loading times.
P.S. The Chrome guys instead would have invested more times in the bookmarks, to make them useful. They could start by integrating Chrome with the Google Bookmarks.
Re: (Score:2)
I'm not sure there's really a security issue here. From the spec [chromium.org], all its doing is letting the server send back multiple items in response to a request for one item. So if you request X, and the server knows you're going to need Y too, it can send both at once.
It's not like the server can connect to you out of nowhere and start firing stuff at you. And since a server can already send malicious content back in response to a request, the security aspect isn't really worse then it already is.
Re:SPDY - server push (Score:5, Informative)
I'm not sure there's really a security issue here. From the spec [chromium.org], all its doing is letting the server send back multiple items in response to a request for one item. So if you request X, and the server knows you're going to need Y too, it can send both at once.
If server "knows" that I "need" 2MB of flash ads to see the 40K html page, it would send them to me. IOW browser is out of control what server sends, browser can only discard the content which has wasted my bandwidth and isn't going to be displayed.
It's not like the server can connect to you out of nowhere and start firing stuff at you. And since a server can already send malicious content back in response to a request, the security aspect isn't really worse then it already is.
With HTTP, there is no way server can send me something my browser didn't asked for. It can send something bad *instead* of what my browser asked - but only once and with user visible effect. With SPDY, server can send me loads of junk *silently*, still appearing to be serving legit content.
For static content, it is even worse: first time I visit the page it is cached and then a cached copy used. With SPDY, bandwidth is going to be always wasted for transferring the static content. Yes, I need it to display the page - but no, I have already local cached copy.
Re:SPDY - server push (Score:4, Interesting)
Yeah, and by their own testing [chromium.org], the push features only resulted in an additional -1% to +3% improvement (yes it made things slightly slower in one case). The additional complexity added by those features is not justified by their benefits. They should just drop them.
SPDY clarifications (Score:5, Informative)
Thanks for all the kind words on SPDY; I wish the magazine authors would ask before putting their own results in the titles!
Regarding standards, we're still experimenting (sorry that protocol changes take so long!). You can't build a new protocol without measuring, and we're doing just that - measuring very carefully.
Note that we aren't ignoring the standards bodies. We have presented this information to the IETF, and we got a lot of great feedback during the process. When the protocol is ready for a RFC, we'll submit one - but it's not ready yet.
Here are the IETF presentations on SPDY:
http://www.ietf.org/proceedings/80/slides/tsvarea-0.pdf [ietf.org]
and
https://www.tools.ietf.org/agenda/80/slides/httpbis-7.pdf [ietf.org]
I've also answered a few similar questions to this here: http://hackerne.ws/item?id=2420201 [hackerne.ws]
We love help- if you're passionate about protocols and want to lend implementation help, please hop onto spdy-dev@google.com Several independent implementations have already cropped up and the feedback continues to be really great.
Re:SPDY clarifications (Score:4, Interesting)
Since we've got it direct from the horse's mouth -
- Why server push? Nobody seems to think it's a good idea and it makes things more complicated for everybody involved, including proxies. What is the rationale for this feature.
- Why did you name it "SPDY" to show "how compression can help improve speed" when SSL already supports compression?
- In the performance measurements in the whitepaper, what HTTP client did you use and what multiple connection multiplexing method was used if any? How were the results for HTTP obtained? For instance the whitepaper says an HTTP client using 4 connections per domain "would take roughly 5 RTs" to fetch 20 resources, implying theory math. Were situations like 10 small requests finishing in the time it takes to transfer 1 large request taken into account? (ie in practice multiple requests can be made without increasing total page load time)
- The main supposed benefit seems to be requesting more than one resource at once. Then a request could stall the connection while being processed (ie doubleclick ad) and hold up everything after it, so then you add multiplexing, priorities, canceling requests, and all that complication. Why not just send a list of resources and have the server respond back in whatever order they are available? This provides the same bandwidth and latency with superior fault handling (if the connection closes the browser has only one resource partially transferred instead of several).
- The FAQ kind of reluctantly admits that HTTP pipelining basically has the same benefits in theory as SPDY except if a resource takes a while and holds up the remaining ones. So what benefit would SPDY have over just fixing pipelining so that the server can respond in whatever order it chooses? The only real problem with HTTP tunneling is fixed-order and bad implementations (ie IIS), correct?
Barring really good explanations it looks to me like SPDY is just very complicated and increases speed basically as a side-effect of solving other imaginary problems.
Re: (Score:3)
I'm one of the other people who works on SPDY.
server push: We have some debates about this internally, but it seems the market is deciding that push is important-- e.g. image inlining into the HTML. Server push allows you to accomplish the same, but gives the benefit of having them known as individual resources by a single name, and thus cacheable. I believe it may be particularly beneficial for people on high-rtt devices like mobile. If you look at data just about anywhere, you can see that RTT is the real
Re: (Score:3)
The one thing I appreciate, is your not selling this as "Chrome makes the web faster" the way Microsoft did back in the 90's. By creating their own extensions, and trying to sell everybody on how much better IE5 with IIS was then Netscape with Apache.
You have added it to chrome and to google sites. Some may notice a speed difference, some may not. Meanwhile the protocol, such as it is, is free to use and implement without anyone having to reverse engineer it. Which is a pretty decent earnest money down to c
Setting off warning bells (Score:3)
As part of the "Let's make the web faster" initiative, we are experimenting with alternative protocols to help reduce the latency of web pages.
This smells very close to the "embrace extend and extinguish" technique of Microsoft. Unless Google follows it by keeping the technology open, work on getting it certified into the next version of the standards, this would become the first step in Google becoming the next Microsoft.
Re: (Score:2)
It is kind of funny, because this is in Chrome. Thus it is in Chromium, thus it is already in the open.
And the website has a whitepaper trying to explain it and lists all the drafts being worked on for submissing to the IETF:
http://www.chromium.org/spdy [chromium.org]
http://www.chromium.org/spdy/spdy-whitepaper [chromium.org]
http://www.chromium.org/spdy/spdy-protocol [chromium.org]
BAD (Score:3, Insightful)
I cannot be the only person to think this is not a good thing. So now we'll have sites that have to run both technologies with regular HTTP/TCP as fallback and we fragment the web browser ecosystem even more.
Thanks Google. As much as I want HTTP to be faster, I think this way is a bit degrading to the web... There was no standards process. It will probably now be rushed as a standard.
Basically its a fake way of making Google look faster, so you either adopt Google's tech to get ahead. It reeks of a Microsoft strategic move to me. Can't optimize the browser? Change the browser and make an incompatible change! Well done...
Re:BAD (Score:5, Informative)
Actually, you should read the spec as to how it is implemented. The TLS/NPN mechanism for switching to SPDY has no "fallback".
And there is no intent to rush - heck - we've been working on it for over a year. You think that's rushed? If you're an engineer, I hope you'll appreciate that protocol changes are hard. You can't use pure lab data (although we started out with lab data, of course). Now we need real world data to really figure it out. We changed it in a way which *nobody noticed* for about 4 months. So, I don't think we hurt the web at all, but we are accomplishing the goals of learning how to build a better protocol.
Seriously, if you have a better way to figure out new protocols, we'd love to hear them at spdy-dev@google.com, and if you want to lend a hand implementing, that is even better!
Re: (Score:2)
Browsers and javascript have come ridiculously far in the last couple of years. It would seem taht they're no longer the bottleneck, but now the protocol is. I actually doubt that you can squeeze that much more performance gains out of the browser at this point. I have no problem with now optimizing the protocol as long as the results of that process are open.
Re: (Score:2)
How is it a fake way? SPDY really is faster. Also there is nothing proprietary about this so your Microsoft comparison is wrong too.
Re: (Score:2)
I see it more as a typical google-thing, with massive open betas.
But I can't see how this would make the browser incompatible. It still serves HTTP(S), and Google's servers work as they've done always (seen from the perspective of a competing browser). And the specs are out there, and documented.
Re: (Score:2)
The answer was simple: NoScrip
Re: (Score:3)
I cannot be the only person to think this is not a good thing. [...] As much as I want HTTP to be faster, I think this way is a bit degrading to the web... There was no standards process. It will probably now be rushed as a standard
Actually, this is an example of how standardisation should work. They thought about a good way to fix a problem (including consideration of past problems); chose an approach that was upwardly compatible and harmless to older clients; released a working implementation and source code.
How could anyone do better? This is the classic path to "rough consensus and running code" [wikipedia.org].
There are plenty of criticisms appropriate to SPDY and Google in general, but how they have proceeded in this case is not one of them.
Re: (Score:2)
It's not the innovation in technology that is the problem. I praise this much. It's the 'politics'.
It's a ploy to get people to use Chrome, it acts as a marketing move and it only damages the (para)stability that we have now. This sort of thing should be going through standards bodies. You can now advertize that Chrome is now faster than every other browser! Great but of course users don't realize that you've cheated the process. They think other browsers are slow and stupid when in fact you've now added di
for Srware Iron users (Score:2)
I notice they're on version 10 since March 27...does that mean this is included in their latest build?
http://www.srware.net/en/software_srware_iron_download.php [srware.net]
Re: (Score:2)
Who knows what's included in their build, they only provide outdated code as archive fragments on rapidshare... whether it's because of malice or ineptitude, I wouldn't run any software those guys produce. Publishing a project on github or similar service is not rocket science.
I once tried asking what the deal was on their forums, but my post didn't make it through moderation.
Kinda sad for the BEEP guys (Score:2)
I thought BEEP was a great concept that seemed to die on the vine. When I saw "multiplexing," I figured Google had resurrected the protocol but it looks like BEEP just doesn't go far enough.
As for that 6 socket connections per client connection...wow! Never knew those kinds of resources were being devoured for every network connection.
Possible security problem? (Score:2)
SPDY also allows the server to communicate with a client without a client request
Could this possibly be used to attack client computers?
I don't think so (Score:2)
The client has to initiate the connection with the server, these features just allow the sever to send back more data than was requested. If there was a bug in how the client processed the data then it could be exploited as a security request. However that is already true today of the data the client is requesting. This extra data will be in the same format as if the client directly requested it (except with the X-Associated-Content header added), so the same code should be used to parse it.
Like I mentioned
Interesting, but somewhat developer-hostile (Score:3)
This is an interesting wrapper around MIME, but it is not HTTP in any way. Honestly, it's more like an "embrace-and-extend" in the Microsoft sense. It is backward-incompatible in ways that are inconsistent with its stated philosophy of bandwidth savings (and in ways which break the most basic HTTP semantics), and it throws gratuitous binary into the wrapper while using FUD to justify its presence (notably the specter of "security problems"). This is sad, because it actually does contain some much-needed improvements to HTTP, such as TLS-only, compression-by-default, and header compression. But it's not an extension, because that implies backward-compatibility: it's a replacement, and one with certain other design decisions that are questionable at best.
Some questions in particular:
1) Why break the request-line and status-line? This is the major compatibility-killer, and it adds to the bandwidth consumed by the protocol in ways directly counter to the concept of saving bandwidth. To call requests and responses "virtually unchanged" from HTTP is disingenuous when the most basic syntactic requirements for both of these things is completely different: they are in fact completely different, not virtually unchanged: what you've unchanged is MIME.
2) Why binary for the wrappers? The specter of security issues via incorrect parsing is true as far as it goes, but by no means insurmountable, and the bandwidth savings are minimal at best. In exchange, the spec becomes considerably harder to debug (and thus to implement) and to extend further as needed by future requirements.
Re:Embrace, Extend, ? (Score:5, Insightful)
No, because the Microsoft way to embrace, extend, extinguish was to keep the "how to extend" part to itself and secret, like what they did with Kerberos.
This is open sauced. You are free to implement it in your own stuff.
You would have known that if you read the article.
--
BMO
Re: (Score:3)
This is open sauced.
And it's a damn good sauce too!
Re: (Score:2)
Re: (Score:2)
like what they did with Kerberos.
The way MS extended Kerberos was 100% within the specifications of Kerberos. It was designed to do EXACTLY what Microsoft did.
The problem is that most implementations of Kerberos in the unix world were based off the same broken implementation that didn't actually deal with the specification properly. Get your facts straight.
Re: (Score:3)
Actually the article is wrong about this, the code is open source (Chrome or alteast Chromium which it is based on is an open source project after all) and their are drafts for the RFC.
Re: (Score:2)
A lot of people knew that when they decided to hide the http:/// [http] portion of the URL bar, the real reason was to be able to push SPDY without users noticing, the problem: they told the user do not need to see that, bla bla bla, Not that I have something against an efficient enhancement to HTTP, but please, no need to hide the real reason
Re: (Score:2)
If theyre using SPDY on google.com, its STILL an HTTP GET. Dont believe me? Go there with Chrome's developer tools open to the network tab. Check the headers.
Re: (Score:2)
SPDY just multiplexes HTTP-requests over TLS ('SSL' as used by HTTPS) or in theory TCP.
Re: (Score:2)
Re:Let's get this out of the way (Score:4, Insightful)
I'll take a stab at it :
Everything is sent through an encrypted channel making it difficult to filter out ads before they hit the client (like with privoxy for example.)
No cashing ("Since we're proposing to do almost everything over an encrypted channel, we're making caching either difficult or impossible." -Protocol Draft [chromium.org]) means you'll be served "fresh" ads every time.
So it looks like this would be good news for Google's core business.
Re: (Score:2)
SPDY does not make ads cache more or less, any browser that does or would implement SPDY already does caching for HTTPS correctly (it adheres to what the creator of the webpage specied in the headers).
Re: (Score:2)
Yeah, I was thinking about that later.
I actually think not that many people actually still use proxies.
Re: (Score:2)
It does help that Google controls the client and server, which Mozilla does not. That said, Mozilla did just come out with "Do not track" feature that is being adopted by the other browsers now.
My problem with these extensions is that they are reminiscent of the race to make up features outside any spec back in the day when Internet Explorer and Netscape duked it out. Javascript, AJAX, SSL and zillions of HTML tags all came from the browser companies making it up as they went along. Some of this was good, o
Re: (Score:2)
That is why they are working with the IETF, not on their own. They have had a few draft on their site for over atleast one and a half year.
Re: (Score:2)
It is the summary and article that are wrong.
SPDY has a draft and they already sumitted to other drafts to the IETF.
Re: (Score:2)
You'll find a newer, more powerful Amiga, or you'll replace your Amiga, or you'll be left behind. And, no one will notice. No problem, my freind. Really, do you think someone will post on /. five years from now, "Whatever happened to that orange cretin? Is he still stuck with that old paperweight of a computer?"