5 ms·

SPDY for Rest of Us

40 points by laktek 14y ago

lucasgonze 14y ago
Google Chrome could not find laktek.com
- laktek 14y ago
  Really? Could you try again? I don't see an issue in accessing the site.
  - cleverjake 14y ago
    yep, the DNS doesn't seem to have propagated out to me. http://laktek.com.s3-website-us-east-1.amazonaws.com/ http://laktek.com.s3-website-us-east-1.amazonaws.com/ works though
    - laktek 14y ago
      Wonder whether its a problem with some DNS servers. http://www.downforeveryoneorjustme.com/laktek.com http://www.downforeveryoneorjustme.com/laktek.com
      - cleverjake 14y ago
        seems like it just isn't recodnized on comcast's DNS system ⚓ ~ dig laktek.com @75.75.75.75 +short ⚓ ~ google is working though ⚓ ~ dig laktek.com @8.8.8.8 +short laktek.com.s3-website-us-east-1.amazonaws.com. s3-website-us-east-1.amazonaws.com. 205.251.242.139 ⚓ ~ may want to contact comcast if that still fails after 24 hours of a creation/change
        pilif 14y ago
        Strangely, laktek.com does not seem to have a SOA record, nor NS records. How is something like this even possible? Does whoever runs .com these days create direct cname entries without delegation? Puzzled.
        mike-cardwell 14y ago
        Their DNS is broken. They have a CNAME at the root of their zone, which is forbidden. If you're using the "Unbound" DNS resolver (I am), and it's in DNSSEC validation mode, then it will SERVFAIL when it comes across broken DNS like this (even if the zone isn't using DNSSEC). I don't know about other DNS resolvers, but IIRC didn't Comcast switch to using resolvers which support DNSSEC for their customers recently? [edit] - Can you see http://imgur.com/ http://imgur.com/ on Comcast? That (well known) site has the same problem. I tried to alert them to this fact a few weeks ago but never heard back. I'd be surprised if Comcast users can't access that site.
bgruber 14y ago
"HTTP is stateless, which means for each request client has to create a new connection with the server." That's not what stateless means. And unless I am gravely mistaken, HTTP over SPDY is still stateless.
- laktek 14y ago
  Well actually the HTTP connections are stateless, but not the SPDY connection. SPDY connection keeps the session open between two endpoints and do have the knowledge about the other streams. That's what makes it possible to do server push or header augmentation.
  - mbelshe 14y ago
    BTW - TCP & SSL maintain connection level state too. This isn't anything new to SPDY and is transparent to the application above.
cr4zy 14y ago
App Engine will serve SPDY from https automagically.
- newman314 14y ago
  Link?
  - tonfa 14y ago
    Go to https://xxx.appspot.com https://xxx.appspot.com then go to chrome://net-internals/#spdy
MikeCapone 14y ago
Any expert ready to venture a guess on how fast SPDY could be adopted by most of the biggest websites on the net? Could it spread like wildfire when all the main browsers and web-hosting softwares adopt it, or are we talking about years and years (like getting rid of IE6)?
- arunoda 14y ago
  I hope it will be the same story as HTML5 (IE will took it after everyone) And SPDY will spread much more higher rate than HTML5. Because it is a little work to be performed at the website end not like HTML5. Hope within 1 year, it will be in a state where HTML5 today. BTW: I'm not a expert :)
  - pilif 14y ago
    SPDY requires SSL and SSL for all intents and purposes doesn't work with name based virtual hosting (it doesn't for all versions of IE under XP and on Android < 4) due to the lack of SNI. Aside of a noticable hit in performance for the encryption work (some say insignificant which is probably true if you are google), enabling SSL is a considerable additional administrative hurdle both because of getting certificates (and keeping them fresh) and because of the requirement of needing one IP per domain. The latter problem is going to get worse as more sites want to go SSL and we're already out of unassigned IP addresses. If only we could have widely supported SNI. Then we'd back at only the performance issue (which is going to get less and less noticeable as our hardware gets better) and the administrative overhead for the certificate.
    - ralph 14y ago
      I expect some at Google are cogitating over replacing the current certificate method.
    - buddhika 14y ago
      Yes, lack of SNI support in some browsers could pose a problem in wide adaptation if it keeps SSL mandatory.
CWIZO 14y ago
Could somebody clear this up for me (I've seem to forgotten it): I know you can run a HTTP and SPDY "versions" of your webpage in parallel. But how does the browser know which protocol to use (if it supports both)? Does it initially make a HTTP request and the server responds with some header that let's it know it can use SPDY or what?
- zxoq 14y ago
  The server tells the client it can handle SPDY through an Alternate-Protocol header. The client then makes subsequent requests over SPDY. http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2#TOC-Server-Advertisement-of-SPDY-through-the-HTTP-Alternate-Protocol-header http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-dra...
  - CWIZO 14y ago
    OK thanks. That cleared things up :) Too bad that this means that the first request (which is usually the most expensive one) is always done trough HTTP :/
    - laktek 14y ago
      Not really. The HTTPS requests can choose SPDY using the Next-Protocol-Negotiation(NPN). Alternate protocol header would matter only to HTTP requests to know this server is capable of supporting SPDY. However, as per the latest post by Opera Labs[1], all 3 major browsers supporting SPDY doesn't handles this header correctly. Also, it's not mentioned in SPDY draft 3. [1] http://dev.opera.com/articles/view/opera-spdy-build/ http://dev.opera.com/articles/view/opera-spdy-build/

SPDY for Rest of Us

40 points by laktek 14y ago

lucasgonze 14y ago

Google Chrome could not find laktek.com

laktek 14y ago
Really? Could you try again? I don't see an issue in accessing the site.
- cleverjake 14y ago
  yep, the DNS doesn't seem to have propagated out to me. http://laktek.com.s3-website-us-east-1.amazonaws.com/ http://laktek.com.s3-website-us-east-1.amazonaws.com/ works though
  - laktek 14y ago
    Wonder whether its a problem with some DNS servers. http://www.downforeveryoneorjustme.com/laktek.com http://www.downforeveryoneorjustme.com/laktek.com
    - cleverjake 14y ago
      seems like it just isn't recodnized on comcast's DNS system ⚓ ~ dig laktek.com @75.75.75.75 +short ⚓ ~ google is working though ⚓ ~ dig laktek.com @8.8.8.8 +short laktek.com.s3-website-us-east-1.amazonaws.com. s3-website-us-east-1.amazonaws.com. 205.251.242.139 ⚓ ~ may want to contact comcast if that still fails after 24 hours of a creation/change
      - pilif 14y ago
        Strangely, laktek.com does not seem to have a SOA record, nor NS records. How is something like this even possible? Does whoever runs .com these days create direct cname entries without delegation? Puzzled.
      - mike-cardwell 14y ago
        Their DNS is broken. They have a CNAME at the root of their zone, which is forbidden. If you're using the "Unbound" DNS resolver (I am), and it's in DNSSEC validation mode, then it will SERVFAIL when it comes across broken DNS like this (even if the zone isn't using DNSSEC). I don't know about other DNS resolvers, but IIRC didn't Comcast switch to using resolvers which support DNSSEC for their customers recently? [edit] - Can you see http://imgur.com/ http://imgur.com/ on Comcast? That (well known) site has the same problem. I tried to alert them to this fact a few weeks ago but never heard back. I'd be surprised if Comcast users can't access that site.

bgruber 14y ago

"HTTP is stateless, which means for each request client has to create a new connection with the server." That's not what stateless means. And unless I am gravely mistaken, HTTP over SPDY is still stateless.

laktek 14y ago
Well actually the HTTP connections are stateless, but not the SPDY connection. SPDY connection keeps the session open between two endpoints and do have the knowledge about the other streams. That's what makes it possible to do server push or header augmentation.
- mbelshe 14y ago
  BTW - TCP & SSL maintain connection level state too. This isn't anything new to SPDY and is transparent to the application above.

cr4zy 14y ago

App Engine will serve SPDY from https automagically.

newman314 14y ago
Link?
- tonfa 14y ago
  Go to https://xxx.appspot.com https://xxx.appspot.com then go to chrome://net-internals/#spdy

MikeCapone 14y ago

Any expert ready to venture a guess on how fast SPDY could be adopted by most of the biggest websites on the net? Could it spread like wildfire when all the main browsers and web-hosting softwares adopt it, or are we talking about years and years (like getting rid of IE6)?

arunoda 14y ago
I hope it will be the same story as HTML5 (IE will took it after everyone) And SPDY will spread much more higher rate than HTML5. Because it is a little work to be performed at the website end not like HTML5. Hope within 1 year, it will be in a state where HTML5 today. BTW: I'm not a expert :)
- pilif 14y ago
  SPDY requires SSL and SSL for all intents and purposes doesn't work with name based virtual hosting (it doesn't for all versions of IE under XP and on Android < 4) due to the lack of SNI. Aside of a noticable hit in performance for the encryption work (some say insignificant which is probably true if you are google), enabling SSL is a considerable additional administrative hurdle both because of getting certificates (and keeping them fresh) and because of the requirement of needing one IP per domain. The latter problem is going to get worse as more sites want to go SSL and we're already out of unassigned IP addresses. If only we could have widely supported SNI. Then we'd back at only the performance issue (which is going to get less and less noticeable as our hardware gets better) and the administrative overhead for the certificate.
  - ralph 14y ago
    I expect some at Google are cogitating over replacing the current certificate method.
  - buddhika 14y ago
    Yes, lack of SNI support in some browsers could pose a problem in wide adaptation if it keeps SSL mandatory.

CWIZO 14y ago

Could somebody clear this up for me (I've seem to forgotten it): I know you can run a HTTP and SPDY "versions" of your webpage in parallel. But how does the browser know which protocol to use (if it supports both)? Does it initially make a HTTP request and the server responds with some header that let's it know it can use SPDY or what?

zxoq 14y ago
The server tells the client it can handle SPDY through an Alternate-Protocol header. The client then makes subsequent requests over SPDY. http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2#TOC-Server-Advertisement-of-SPDY-through-the-HTTP-Alternate-Protocol-header http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-dra...
- CWIZO 14y ago
  OK thanks. That cleared things up :) Too bad that this means that the first request (which is usually the most expensive one) is always done trough HTTP :/
  - laktek 14y ago
    Not really. The HTTPS requests can choose SPDY using the Next-Protocol-Negotiation(NPN). Alternate protocol header would matter only to HTTP requests to know this server is capable of supporting SPDY. However, as per the latest post by Opera Labs[1], all 3 major browsers supporting SPDY doesn't handles this header correctly. Also, it's not mentioned in SPDY draft 3. [1] http://dev.opera.com/articles/view/opera-spdy-build/ http://dev.opera.com/articles/view/opera-spdy-build/