8 ms·

A 2x Faster Web

163 points by johns 17y ago

cakeface 17y ago
Is this basically an RFC for HTTP version 2?
- timf 17y ago
  It's mostly a session framework on top of SSL but under HTTP. From http://dev.chromium.org/spdy/spdy-whitepaper http://dev.chromium.org/spdy/spdy-whitepaper 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.
nixme 17y ago
The whitepaper has more information: http://dev.chromium.org/spdy/spdy-whitepaper http://dev.chromium.org/spdy/spdy-whitepaper Interesting parts: - "...make SSL the underlying transport protocol, for better security and compatibility with existing network infrastructure." Won't this break many caching models? - "...provides an advanced feature, server-initiated streams. Server-initiated streams can be used to deliver content to the client without the client needing to ask for it." Nice, push without comet-style hacks. EDIT: more items that stand out - "SPDY implements request priorities: the client can request as many items as it wants from the server, and assign a priority to each request" From the protocol document: http://dev.chromium.org/spdy/spdy-protocol http://dev.chromium.org/spdy/spdy-protocol - "Content-length is not a valid header" - "Clients are assumed to support Accept-Encoding: gzip. Clients that do not specify any body encodings receive gzip-encoded data from the server." - "The 'host' header is ignored. The host:port portion of the HTTP URL is the definitive host." I guess this supplants the need for SNI support. Edit: No it doesn't since SPDY sits above SSL. The host isn't known until the secure link has already been established.
- sp332 17y ago
  The future of the internet is ubiquitous encryption. Better to break caching models ASAP so that fixing them can be done incrementally.
  - timdorr 17y ago
    Provided we're using IPv6 exclusively. SSL removes the ability to do virtual hosting, which is why we didn't run out of IPs 5-10 years ago.
    - blasdel 17y ago
      Any client supporting SPDY would absolutely support the Server Name Indication extension from RFC4366
    - notauser 17y ago
      Given that IPv6 is a good thing(1) any technology change that brings forward the time line for IPv4 address exhaustion is a good thing. It is human nature that people don't do things that sound like hard work until they have to, and the continuing use of IPv4 with NAT and other hacks falls firmly into that camp. (1) Every device becomes addressable again - I remember when it was normal to assume that devices could be reached directly, and would be fire walled if required. That led to a much greater number of people running services from their machine. From the perspective of a startup the idea that a client can run data services without some horrible <nat-related> hack is really interesting.
  - buro9 17y ago
    I'm currently in the process of making a site with 130,000 monthly visitors 100% SSL. https://www.londonfgss.com/thread32727.html https://www.londonfgss.com/thread32727.html It's just a community forum, but things like ACTA and the erosion of privacy that our government is gradually executing all make me really question whether there are downsides. I'd originally made it available over SSL to help people access it from work without the proxies blocking it (works very well btw), but now it'll be everything. As part of this I'm doing a review of the styles, images, javascript, etc to ensure that I perform as few requests as possible due to the lack of caching. The software I'm using hasn't really considered requests. The view seems to have been "it's a one time hit and then it's cached", whereas in the SSL world you'll be good if you get a cached once-per-session model. It also complexifies things on the back-end, thinking of things like software load balancing and pass-through requests. All good stuff though, I get to learn about how to make this stuff work and scale at the same time as providing a great feature (privacy and security) to my users. Traditional models are worth breaking to gain these benefits.
neilc 17y ago
I'm impressed that they're able to get such good performance (and latency) while still running the traffic over SSL. For example, average page load time over SSL is 1899 ms ("SPDY basic single-domain / SSL"), compared to 3112 ms for plain HTTP -- they don't show HTTPS, but presumably that would be even slower.
jeremyw 17y ago
One imagines djb envisioning a single roundtrip for encrypted HTTP, built on top of DNSCurve. You have the public key via DNS, you send an encrypted request and receive a verifiable encrypted response that includes content and begins the multiplexed channel.
swombat 17y ago
Impressive, how Google are taking on challenges that pretty much no other company could possibly address... replacing email... enhancing HTTP, etc... They're the only company with the means to take on such massive, unprofitable projects, and at the same time enough street cred that everyone won't immediately assume they're trying to make the web proprietary. The fact that they tend to open up these things from the get go helps, too.
- symesc 17y ago
  Agreed. I think the important thing to note is that Google is the only large company whose business model depends almost completely on the success of the Internet. This is why we see them at bat for Net Neutrality as well as efficiencies within communication protocols. Microsoft, Apple, Oracle, HP, IBM . . . those companies make their livings in other ways. The only company comparable to Google would be Yahoo in this way. Their inability to keep engineering talent means their contribution to The-Internet-As-Platform is not as significant.
  - pavs 17y ago
    While I agree with you generally. MS, Apple, Oracle, HP, IBM or any personal computer or server related business would either not be as successful or their product as widely used if there was no internet. IE. Imagine a personal computer market with no way for computers to communicate with each other, would users be still buying computers as much as they do now or would it be just a small niche market? Even though there are several big players whose business model depends quite a bit on the internet, yet no other tech companies does as much as to improve the internet as Google does. The icing on the cake is that Google opens up and shares most of these projects to everyone for free.
    - ggrot 17y ago
      These other companies get more value by the internet existing and being useful. They don't get much value when people use the internet more. Google does. In a sense, google competes with other ways people spend their time, like television.
shimon 17y ago
Am I missing their explanation of how a SPDY-capable client and server discover and make use of SPDY instead of HTTP? For this to take hold in the wild, it has to be possible for me to run a combined HTTP+SPDY server, and for a client connecting to it to automatically make use of SPDY if it is capable. This must happen without user intervention (i.e. we don't expect people to type spdy:// instead of http:// http://). It seems like this should be possible. Perhaps there could be a special server response that instantly "upgrades" a TCP session from HTTP into SPDY. But I'm not seeing anything about that in the docs; is this part of the SPDY plan (yet)?
- shykes 17y ago
  You could browse to the page the regular way, then load a Javascript or Flash library which would use SPDY for all further communications. In your typical web app the user experience could be visibly improved. You can already do this with Flash today, and it would be much easier for Google to push it into the DOM than to touch the transport protocol.
  - drusenko 17y ago
    I'm missing how javascript has the abilities to touch the transport layer in such a fundamental way -- could you explain?
    - shykes 17y ago
      It doesn't - but one could imagine adding support for raw sockets in the DOM. It's easier to change things at the document level rather than at the discovery and transport level.
- wmf 17y ago
  HTTP supports protocol upgrades although this has never been used in the wild.
- teej 17y ago
  This is merely the spec doc for the DVD. The combo VHS-DVD players will come next.
dkubb 17y ago
I love that Google is focusing on how to speed up the web, but they are missing the most obvious thing they could do that would have a dramatic impact on the speed of the web: Update their PageRank algorithm to take into account website speed, and then publish this as a fact. The idea would be that they would have GoogleBot measure the latency, and overall page load time and rank sites higher that respond faster, and slow sites lower. One of the problems with PageRank is that most of how they measure site quality is a mystery, but making it plain that speed is used in ranking would bring website performance to the front of everyone's minds. They could use similar metrics as YSlow and PageSpeed use, and tell everyone to optimize their sites using those tools as a starting point.
- rubymaverick 17y ago
  Unless they want to make the web faster for their properties, which SPDY would do. They can only optimize their own sites up to a point and then they need to make the whole web infrastructure more efficient to realize any more speed gains, across all clients.
- timdorr 17y ago
  Except your network connection to a site is going to be drastically different than Google's. Case in point: My datacenter directly peers with Comcast, so I get <7ms pings from home. Google gets around 35ms. It would be like comparing the drive to a particular location using completely different starting points. Plus, people would start doing all sorts of tricks to boost their ranking. Serving static, cached files for Google and giving everyone else a slow, dynamic site. It's way too easy to abuse.
  - mseebach 17y ago
    It's a challenge, but one that can be overcome. Google just needs to figure out a reasonable baseline latency to subtract - for that, there's ping, ping the previous host on the route, latency to other hosts with close IPs, GeoIP+a database of baseline latency to sites in the same area etc. And the tricks will be dealt with the same way as now: If you're caught doing them, you're blacklisted. But this will be less of an issue in this case: If you've taken the trouble to set up caches that you can direct Google to -- why not direct your actual users to that too?
bensummers 17y ago
Regarding the use of SSL by default, they better require the use of the SSL mode which sends the hostname before the crypto negotiation. Otherwise that's a lot of IP addresses required for virtual hosting!
- agl 17y ago
  We will.
  - drusenko 17y ago
    Even so, the current certificate issuing process is lengthy and expensive. Requiring SSL would be a major hit to the mom-and-pop type websites that just want a simple webpage on their own domain for their business. They'd now have to pony up for an SSL cert, which at least doubles the website ownership cost, as well as potentially go through a very complex process to get the certificate issued. It also completely eliminates the possibility of them having a free website on their own domain, unless an easy and free method to obtain an SSL cert becomes available. The gain to them in these circumstances is negligible, if they aren't doing any e-commerce.
    - ams6110 17y ago
      mom and pop brochure sites are not the sort who would be using spdy anyway, they'd just use http.
      - cameldrv 17y ago
        Why? If this is successful, everyone should use it, and the whole web would be faster with default server configuration.
9oliYQjP 17y ago
Am I missing something? How does "55% faster" translate into a 2x speed-up?
- timdorr 17y ago
  2x = Goal 55% = Reality so far
antirez 17y ago
I've a bad feeling of this potentially making the web layer more complex. Also the encryption bit may not be a good idea if you are not Google... In general I'm more happy with web standards. Google doing research on this is great, but if they unilaterally push solutions that will anyway hit the mass market because they are Google is not good. All the web, the idea of HTTP APIs and so on are based on the fact that HTTP may not be perfect but it's trivial to use, implement, and so forth. Please don't break this fact.
- drusenko 17y ago
  I wouldn't be so afraid of Google being able to unilaterally effect change without consensus. Even getting adoption for their Chrome browser seems to be an extreme uphill battle.
EugeneG 17y ago
Wouldn't faster internet connections make this whole effort moot?
- MikeCapone 17y ago
  No, because they would be even faster when combined with this.
- stevejohnson 17y ago
  No, because this would make internet faster over those faster internet connections.
dedalus 17y ago
http://www.w3.org/Protocols/HTTP-NG/http-ng-scp.html http://www.w3.org/Protocols/HTTP-NG/http-ng-scp.html had some similar ideas which when combined with http://www.faqs.org/rfcs/rfc998.html http://www.faqs.org/rfcs/rfc998.html gives you this SPDY. But how do you gain adoption of such a tech across clients and servers (which was the problem with pipelining) will be an interesting question to see
- dedalus 17y ago
  http://tools.ietf.org/html/draft-natarajan-http-over-sctp-00 http://tools.ietf.org/html/draft-natarajan-http-over-sctp-00 also had similar ideas but SPDY is better because of Resource Prioritization
Towle 17y ago
I can't help but read "SPDY" as "Spidey"... :(

A 2x Faster Web

163 points by johns 17y ago

cakeface 17y ago

Is this basically an RFC for HTTP version 2?

timf 17y ago
It's mostly a session framework on top of SSL but under HTTP. From http://dev.chromium.org/spdy/spdy-whitepaper http://dev.chromium.org/spdy/spdy-whitepaper 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.

nixme 17y ago

The whitepaper has more information: http://dev.chromium.org/spdy/spdy-whitepaper http://dev.chromium.org/spdy/spdy-whitepaper Interesting parts: - "...make SSL the underlying transport protocol, for better security and compatibility with existing network infrastructure." Won't this break many caching models? - "...provides an advanced feature, server-initiated streams. Server-initiated streams can be used to deliver content to the client without the client needing to ask for it." Nice, push without comet-style hacks. EDIT: more items that stand out - "SPDY implements request priorities: the client can request as many items as it wants from the server, and assign a priority to each request" From the protocol document: http://dev.chromium.org/spdy/spdy-protocol http://dev.chromium.org/spdy/spdy-protocol - "Content-length is not a valid header" - "Clients are assumed to support Accept-Encoding: gzip. Clients that do not specify any body encodings receive gzip-encoded data from the server." - "The 'host' header is ignored. The host:port portion of the HTTP URL is the definitive host." I guess this supplants the need for SNI support. Edit: No it doesn't since SPDY sits above SSL. The host isn't known until the secure link has already been established.

sp332 17y ago
The future of the internet is ubiquitous encryption. Better to break caching models ASAP so that fixing them can be done incrementally.
- timdorr 17y ago
  Provided we're using IPv6 exclusively. SSL removes the ability to do virtual hosting, which is why we didn't run out of IPs 5-10 years ago.
  - blasdel 17y ago
    Any client supporting SPDY would absolutely support the Server Name Indication extension from RFC4366
  - notauser 17y ago
    Given that IPv6 is a good thing(1) any technology change that brings forward the time line for IPv4 address exhaustion is a good thing. It is human nature that people don't do things that sound like hard work until they have to, and the continuing use of IPv4 with NAT and other hacks falls firmly into that camp. (1) Every device becomes addressable again - I remember when it was normal to assume that devices could be reached directly, and would be fire walled if required. That led to a much greater number of people running services from their machine. From the perspective of a startup the idea that a client can run data services without some horrible <nat-related> hack is really interesting.
- buro9 17y ago
  I'm currently in the process of making a site with 130,000 monthly visitors 100% SSL. https://www.londonfgss.com/thread32727.html https://www.londonfgss.com/thread32727.html It's just a community forum, but things like ACTA and the erosion of privacy that our government is gradually executing all make me really question whether there are downsides. I'd originally made it available over SSL to help people access it from work without the proxies blocking it (works very well btw), but now it'll be everything. As part of this I'm doing a review of the styles, images, javascript, etc to ensure that I perform as few requests as possible due to the lack of caching. The software I'm using hasn't really considered requests. The view seems to have been "it's a one time hit and then it's cached", whereas in the SSL world you'll be good if you get a cached once-per-session model. It also complexifies things on the back-end, thinking of things like software load balancing and pass-through requests. All good stuff though, I get to learn about how to make this stuff work and scale at the same time as providing a great feature (privacy and security) to my users. Traditional models are worth breaking to gain these benefits.

neilc 17y ago

I'm impressed that they're able to get such good performance (and latency) while still running the traffic over SSL. For example, average page load time over SSL is 1899 ms ("SPDY basic single-domain / SSL"), compared to 3112 ms for plain HTTP -- they don't show HTTPS, but presumably that would be even slower.

jeremyw 17y ago

One imagines djb envisioning a single roundtrip for encrypted HTTP, built on top of DNSCurve. You have the public key via DNS, you send an encrypted request and receive a verifiable encrypted response that includes content and begins the multiplexed channel.

swombat 17y ago

Impressive, how Google are taking on challenges that pretty much no other company could possibly address... replacing email... enhancing HTTP, etc... They're the only company with the means to take on such massive, unprofitable projects, and at the same time enough street cred that everyone won't immediately assume they're trying to make the web proprietary. The fact that they tend to open up these things from the get go helps, too.

symesc 17y ago
Agreed. I think the important thing to note is that Google is the only large company whose business model depends almost completely on the success of the Internet. This is why we see them at bat for Net Neutrality as well as efficiencies within communication protocols. Microsoft, Apple, Oracle, HP, IBM . . . those companies make their livings in other ways. The only company comparable to Google would be Yahoo in this way. Their inability to keep engineering talent means their contribution to The-Internet-As-Platform is not as significant.
- pavs 17y ago
  While I agree with you generally. MS, Apple, Oracle, HP, IBM or any personal computer or server related business would either not be as successful or their product as widely used if there was no internet. IE. Imagine a personal computer market with no way for computers to communicate with each other, would users be still buying computers as much as they do now or would it be just a small niche market? Even though there are several big players whose business model depends quite a bit on the internet, yet no other tech companies does as much as to improve the internet as Google does. The icing on the cake is that Google opens up and shares most of these projects to everyone for free.
  - ggrot 17y ago
    These other companies get more value by the internet existing and being useful. They don't get much value when people use the internet more. Google does. In a sense, google competes with other ways people spend their time, like television.

shimon 17y ago

Am I missing their explanation of how a SPDY-capable client and server discover and make use of SPDY instead of HTTP? For this to take hold in the wild, it has to be possible for me to run a combined HTTP+SPDY server, and for a client connecting to it to automatically make use of SPDY if it is capable. This must happen without user intervention (i.e. we don't expect people to type spdy:// instead of http:// http://). It seems like this should be possible. Perhaps there could be a special server response that instantly "upgrades" a TCP session from HTTP into SPDY. But I'm not seeing anything about that in the docs; is this part of the SPDY plan (yet)?

shykes 17y ago
You could browse to the page the regular way, then load a Javascript or Flash library which would use SPDY for all further communications. In your typical web app the user experience could be visibly improved. You can already do this with Flash today, and it would be much easier for Google to push it into the DOM than to touch the transport protocol.
- drusenko 17y ago
  I'm missing how javascript has the abilities to touch the transport layer in such a fundamental way -- could you explain?
  - shykes 17y ago
    It doesn't - but one could imagine adding support for raw sockets in the DOM. It's easier to change things at the document level rather than at the discovery and transport level.
wmf 17y ago
HTTP supports protocol upgrades although this has never been used in the wild.
teej 17y ago
This is merely the spec doc for the DVD. The combo VHS-DVD players will come next.

dkubb 17y ago

I love that Google is focusing on how to speed up the web, but they are missing the most obvious thing they could do that would have a dramatic impact on the speed of the web: Update their PageRank algorithm to take into account website speed, and then publish this as a fact. The idea would be that they would have GoogleBot measure the latency, and overall page load time and rank sites higher that respond faster, and slow sites lower. One of the problems with PageRank is that most of how they measure site quality is a mystery, but making it plain that speed is used in ranking would bring website performance to the front of everyone's minds. They could use similar metrics as YSlow and PageSpeed use, and tell everyone to optimize their sites using those tools as a starting point.

rubymaverick 17y ago
Unless they want to make the web faster for their properties, which SPDY would do. They can only optimize their own sites up to a point and then they need to make the whole web infrastructure more efficient to realize any more speed gains, across all clients.
timdorr 17y ago
Except your network connection to a site is going to be drastically different than Google's. Case in point: My datacenter directly peers with Comcast, so I get <7ms pings from home. Google gets around 35ms. It would be like comparing the drive to a particular location using completely different starting points. Plus, people would start doing all sorts of tricks to boost their ranking. Serving static, cached files for Google and giving everyone else a slow, dynamic site. It's way too easy to abuse.
- mseebach 17y ago
  It's a challenge, but one that can be overcome. Google just needs to figure out a reasonable baseline latency to subtract - for that, there's ping, ping the previous host on the route, latency to other hosts with close IPs, GeoIP+a database of baseline latency to sites in the same area etc. And the tricks will be dealt with the same way as now: If you're caught doing them, you're blacklisted. But this will be less of an issue in this case: If you've taken the trouble to set up caches that you can direct Google to -- why not direct your actual users to that too?

bensummers 17y ago

Regarding the use of SSL by default, they better require the use of the SSL mode which sends the hostname before the crypto negotiation. Otherwise that's a lot of IP addresses required for virtual hosting!

agl 17y ago
We will.
- drusenko 17y ago
  Even so, the current certificate issuing process is lengthy and expensive. Requiring SSL would be a major hit to the mom-and-pop type websites that just want a simple webpage on their own domain for their business. They'd now have to pony up for an SSL cert, which at least doubles the website ownership cost, as well as potentially go through a very complex process to get the certificate issued. It also completely eliminates the possibility of them having a free website on their own domain, unless an easy and free method to obtain an SSL cert becomes available. The gain to them in these circumstances is negligible, if they aren't doing any e-commerce.
  - ams6110 17y ago
    mom and pop brochure sites are not the sort who would be using spdy anyway, they'd just use http.
    - cameldrv 17y ago
      Why? If this is successful, everyone should use it, and the whole web would be faster with default server configuration.

9oliYQjP 17y ago

Am I missing something? How does "55% faster" translate into a 2x speed-up?

timdorr 17y ago
2x = Goal 55% = Reality so far

antirez 17y ago

I've a bad feeling of this potentially making the web layer more complex. Also the encryption bit may not be a good idea if you are not Google... In general I'm more happy with web standards. Google doing research on this is great, but if they unilaterally push solutions that will anyway hit the mass market because they are Google is not good. All the web, the idea of HTTP APIs and so on are based on the fact that HTTP may not be perfect but it's trivial to use, implement, and so forth. Please don't break this fact.

drusenko 17y ago
I wouldn't be so afraid of Google being able to unilaterally effect change without consensus. Even getting adoption for their Chrome browser seems to be an extreme uphill battle.

EugeneG 17y ago

Wouldn't faster internet connections make this whole effort moot?

MikeCapone 17y ago
No, because they would be even faster when combined with this.
stevejohnson 17y ago
No, because this would make internet faster over those faster internet connections.

dedalus 17y ago

http://www.w3.org/Protocols/HTTP-NG/http-ng-scp.html http://www.w3.org/Protocols/HTTP-NG/http-ng-scp.html had some similar ideas which when combined with http://www.faqs.org/rfcs/rfc998.html http://www.faqs.org/rfcs/rfc998.html gives you this SPDY. But how do you gain adoption of such a tech across clients and servers (which was the problem with pipelining) will be an interesting question to see

dedalus 17y ago
http://tools.ietf.org/html/draft-natarajan-http-over-sctp-00 http://tools.ietf.org/html/draft-natarajan-http-over-sctp-00 also had similar ideas but SPDY is better because of Resource Prioritization

Towle 17y ago

I can't help but read "SPDY" as "Spidey"... :(