6 ms·

The whitepaper has more information: http://dev.chromium.org/spdy/spdy-whitepaper http://dev.chromium.org/spdy/spdy-whitepaper Interesting parts: - "...make S

by 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.
adamt 17y ago
These all sound like a step in the wrong direction to me: The reason HTTP has been so successful has been it's simplicity. HTTP with it's human readable format is not the most efficient, but this makes this it simple. Things like header compression to me are missing the point. SSL encryption will break all caching, and add latency in terms extra round-trip times. gzip encoding has minimal value on media data types (images, movies) that represent the majority of the data. This just sounds like a whole load of complexity for a relatively small one-off hit.
- olefoo 17y ago
  > SSL encryption will break all caching, and add latency in terms extra round-trip times. It won't break all caching, just intermediate caches. True this does raise bandwidth usage and initial page load latency (assuming static content is not already cached on the client), but to say it breaks all caching is off. That said, static image serving is not going to benefit from this new protocol all that much. It seems, like much of Google's other work in this area, to be focused on improving the performance of web-based applications.
  - Periodic 17y ago
    > It is designed specifically for minimizing latency through features such as multiplexed streams, request prioritization and HTTP header compression. They specifically say their goal is to minimize latency to make web based applications more responsive. They aren't interested in making you able to download movies faster, what they want to do is make the web more responsive so that they can develop more apps for the web that traditional would have required a desktop client.
  - ciupicri 17y ago
    > It won't break all caching, just intermediate caches. As far as I know, Firefox and maybe other browsers don't store on disk content delivered via https by default, which means that final caches will also be affected. Sure, the default can be changed, but it's an extra security risk. If it wouldn't be, the default setting wouldn't be like this.

by nixme 17y ago

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.

adamt 17y ago

These all sound like a step in the wrong direction to me: The reason HTTP has been so successful has been it's simplicity. HTTP with it's human readable format is not the most efficient, but this makes this it simple. Things like header compression to me are missing the point. SSL encryption will break all caching, and add latency in terms extra round-trip times. gzip encoding has minimal value on media data types (images, movies) that represent the majority of the data. This just sounds like a whole load of complexity for a relatively small one-off hit.

olefoo 17y ago
> SSL encryption will break all caching, and add latency in terms extra round-trip times. It won't break all caching, just intermediate caches. True this does raise bandwidth usage and initial page load latency (assuming static content is not already cached on the client), but to say it breaks all caching is off. That said, static image serving is not going to benefit from this new protocol all that much. It seems, like much of Google's other work in this area, to be focused on improving the performance of web-based applications.
- Periodic 17y ago
  > It is designed specifically for minimizing latency through features such as multiplexed streams, request prioritization and HTTP header compression. They specifically say their goal is to minimize latency to make web based applications more responsive. They aren't interested in making you able to download movies faster, what they want to do is make the web more responsive so that they can develop more apps for the web that traditional would have required a desktop client.
- ciupicri 17y ago
  > It won't break all caching, just intermediate caches. As far as I know, Firefox and maybe other browsers don't store on disk content delivered via https by default, which means that final caches will also be affected. Sure, the default can be changed, but it's an extra security risk. If it wouldn't be, the default setting wouldn't be like this.