
Google Modifies HTTP, Makes Chrome 50% Faster   - peternorton
http://www.conceivablytech.com/6696/products/google-chrome-gets-spdy-and-an-onscreen-keyboard
======
hk9565
A draft of the SPDY specification is here:

<http://dev.chromium.org/spdy>

Mike Belshe presented about SPDY in the IETF HTTP working group meeting at the
most recent IETF meeting:

<http://www.ietf.org/proceedings/80/slides/httpbis-7.pdf>

We'd love for more folks to implement SPDY, both clients and servers.

~~~
beza1e1
Sounds like HTTP 1.2?

Since Google servers and Chrome already support it, the chicken-egg problem
might be solved. Firefox has an incentive to implement it to make Google
search faster and other web service should implement this to provide a
smoother user experience.

~~~
silvestrov
HTTP 2.0 (1.2 would have to be backwards compatible)

~~~
Seth_Kriticos
Yes. And just to argument this, here is the relevant except of the FAQ:

Q: Is SPDY a replacement for HTTP?

A: No. SPDY replaces some parts of HTTP, but mostly augments it. At the
highest level of the application layer, the request-response protocol remains
the same. SPDY still uses HTTP methods, headers, and other semantics. _But
SPDY overrides other parts of the protocol, such as connection management and
data transfer formats._

------
carson
As much as SPDY is interesting there are a number of problems that are keeping
it from being adopted:

1) Only Chrome supports it and even there it isn't fully supported. One really
painful thing it is missing is support for switching from normal HTTP to SPDY
without using NPN.

2) It requires the TLS NPN extension to function seamlessly. This is something
that is just now being put into the OpenSSL package. It is why you need Chrome
to do anything with SPDY, it has a special patch it applies to its internal
version of OpenSSL.

It is good that people are taking interest but there is still a lot of work to
do.

After seeing [http://www.igvita.com/2011/04/07/life-beyond-
http-11-googles...](http://www.igvita.com/2011/04/07/life-beyond-
http-11-googles-spdy/) I decided to fiddle with doing the same with Node.js
<https://gist.github.com/911761> I'll be shoring it up into a real module but
it is going to require changes to the zlib compression module, the
bufferlist/binary module, the put module and to be really useful it will
require a special build of Node.js and OpenSSL.

~~~
bzbarsky
Chrome doesn't use OpenSSL. It uses NSS. At least on Linux and Mac; I believe
it uses the system-native crypto libraries on Windows.

~~~
carson
It doesn't use it in the browser but it does use it for tools relating to
SPDY. See:

[http://src.chromium.org/viewvc/chrome/trunk/src/net/tools/fl...](http://src.chromium.org/viewvc/chrome/trunk/src/net/tools/flip_server/spdy_ssl.cc?revision=77383&view=markup)

Regardless, neither OpenSSL or NSS have NPN in a release version. NSS doesn't
seem to have merged the patch yet:
<https://bugzilla.mozilla.org/show_bug.cgi?id=547312>

~~~
bzbarsky
Ah, indeed. Thanks for the pointer!

------
powertower
You can enable SPDY on your Apache servers with mod_spdy...
<http://code.google.com/p/mod-spdy/>

~~~
ComputerGuru
How long until someone releases a module for nginx to do the same?

~~~
newman314
Might be a while.

Igor was asked about this a while ago and expressed his dislike for it. Not
sure if things have changed since.

------
xuhu
Unlike HTTP, SPDY is no longer plain-text (it uses a packet structure similar
to TCP headers).

While Wireshark's usability has been constantly improving, I will miss being
able to do:

    
    
      $ telnet google.com 80
      GET / HTTP/1.1
      Host: google.com

~~~
jrockway
This is a reasonable concern, but the reality is that:

    
    
      $ telnet google.com 80
      GET / HTTP/1.0
    

Is just going to become:

    
    
      >>> use SPDY;
      >>> SPDY->dump('http://www.google.com/);

~~~
gcb
Less true for tcp dumps

which I believe was the previous poster intention since he mentioned wire
shark..

Also piping bunch of unix command will suffer a little of they

~~~
mahmud
swig + libpcap should get you there for any mainstream language (assuming
you're on a real OS.)

------
lux
Be interesting to see how fast other browsers/servers start supporting this.
I'd love to see Google add it to App Engine sites, for one thing.

~~~
sern
App Engine already does.

~~~
lux
Interesting. I see it used on one of my python gae apps but not the other. One
uses .appspot.com and the other a custom domain.

Edit: The one at appspot.com has spdy.

~~~
abraham
Are you using SSL on the appspot.com app? IIRC SPDY requires SSL.

~~~
lux
Strangely, the one at appspot.com isn't using SSL, but it is going over SPDY
anyway according to Chrome.

------
obtino
About time! SPDY's been out for a while!

------
ck2
<http://news.ycombinator.com/item?id=2420201>

------
iguvnbiugb
Would be great, except I can't use Chrome anymore as Flash crashes every time,
and no one seems to know why.

~~~
trezor
I'm having the same issues and for that reason I've moved back to Firefox 4,
since it seems to have improved quite a bit since I moved to Chrome.

What seems rather ironical is that I only started having these issues with
Chrome _after_ they added the Flash-sandbox, which was supposedly made to stop
Flash from crashing the browser. With the result that Flash is always crashing
the browser, something it never did before.

Sometimes I think Google needs a bigger QA-team.

~~~
omellet
Try adding --disable-internal-flash to your chrome shortcut, it'll use regular
flash instead of the sandboxed version.

------
adrianwaj
Anyone seen:

<http://www.acceloweb.com/images/diagram_with.png>

<http://www.acceloweb.com/product_features.html> (note how quick pages load)

~~~
wmf
That sounds like a competitor to the page speed plugin, but anything running
over HTTP/1.x has fundamentally limited performance.

------
thepumpkin1979
It seems like Nginx Web Server is not going to implement SPDY anytime soon...
<http://forum.nginx.org/read.php?2,22517>

Too bad.

~~~
aeontech
Well, it didn't sound like a categorical "This will never happen!", more like
"Eh, I don't like this about it, so I'm not planning on it yet."

------
nickbp
_The result is a dramatically increased page load performance that only works
between Chrome (as it includes SPDY support) and Google’s servers (which
supports the features for Google sites.)_

Reminds me a lot of MS's strategy of adding incompatible features to existing
standards.

~~~
corin_
I'm a long way from being an expert in the area so I won't comment on this
exact situation, but an overall thought: the difference between MS and Google
is that MS wanted a monopoly and were generally quite sloppy, whereas it's in
Google's interest to have a faster internet for everyone, not just their
users, plus they have the ability to push for adoption of features developed
for their browser/servers, which could lead to other browsers, and servers
(would it be Apache/etc. that would have to implement it?) adding SPDY
support.

~~~
jamaicahest
How is that different? MS wants marketshare, Google wants marketshare, faster
internet for everyone is just a means to an end: more people using Google
services. I'm sorry for not buying into the Google-hype, but keep in mind
they're a business like everyone else and they are in it to make money. If you
ever need proof that Google is doing this for money like everyone else, just
take a look at the history of their advertising services.

~~~
corin_
I'm not saying that Google isn't doing this for business reasons - it just
happens that in Google's case, they benefit more from all browsers being
better than trying to make Chrome kill off other browsers.

~~~
roc
This is similar to Microsoft happily pushing and supporting new
bus/interface/port standards to allow many various hardware companies to bring
newer, better, faster hardware to the consumer.

It wasn't because they were nice or had the consumer's best interest at heart.
They just wanted PCs to be faster, because they had a monopoly that sat atop
PCs. So they benefit when PCs get faster, get replaced and stay ahead of
would-be competitors.

------
Rickasaurus
Is this why gmail in Chrome seems to be hanging on me a lot lately?

------
scrod
>Click on View live SPDY session to see all SPDY connections at a given time –
_all Google properties work with this technology._

This reminds me of Microsoft skipping part of the three-way handshake for IIS-
to-IE connections to reduce the latency to their servers as compared to
Apache.

~~~
robin_reala
Except this is within spec, given a particular (and different) spec.

~~~
gaius
That's the great thing about specs - so many to choose from!

~~~
michaelcampbell
The same can be said, and was originally coined, about standards.

~~~
winestock
The Unix Hater's Handbook attributes that quote to Admiral Grace Murray
Hopper, but without citing the source.

Wikiquote cites others as having said it, including Andrew Tanenbaum, Patricia
Seybold, and Ken Olsen.

<http://en.wikiquote.org/wiki/Grace_Hopper>

~~~
michaelcampbell
I'm sure it was independently thought of by many people (me not included; I
read it years and years ago...). Can't remember from whom, or if it was
attributed at all. It has, to me, the feel of a Henry Spencer-ism.

------
thegeekness
And what about the Bugs that Chrome encounters every now and then? Like not
displaying images sometime, problems with facebook chat? Please fix that.

~~~
ch0wn
<http://bugs.developers.facebook.net/>

<http://code.google.com/p/chromium/issues/list>

Here you go.

~~~
5l
The image loading issue the OP was referring to was already reported in
September 2009 [0] and is still to be resolved for everyone. Along with this
[1] infamous issue reported in October 2008. The Chromium team absolutely seem
to prioritise adding new features before dealing with serious long standing
issues in the browser. Not that they're entirely different from the
competition in this regard.

[0] <https://code.google.com/p/chromium/issues/detail?id=20960>

[1] <https://code.google.com/p/chromium/issues/detail?id=3543>

