SPDY for Rest of Us(laktek.com)
laktek.com
SPDY for Rest of Us
http://laktek.com/2012/07/10/spdy-for-rest-of-us
5 comments
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.
BTW - TCP & SSL maintain connection level state too. This isn't anything new to SPDY and is transparent to the application above.
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?
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-dra...
http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-dra...
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 :/
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/
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/
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)?
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 :)
Hope within 1 year, it will be in a state where HTML5 today.
BTW: I'm not a expert :)
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.
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.
Google Chrome could not find laktek.com
Really? Could you try again?
I don't see an issue in accessing the site.
I don't see an issue in accessing the site.
yep, the DNS doesn't seem to have propagated out to me.
http://laktek.com.s3-website-us-east-1.amazonaws.com/ works though
http://laktek.com.s3-website-us-east-1.amazonaws.com/ works though
Wonder whether its a problem with some DNS servers.
http://www.downforeveryoneorjustme.com/laktek.com
http://www.downforeveryoneorjustme.com/laktek.com
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
⚓ ~ 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
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/ 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.
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/ 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.
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.
How is something like this even possible? Does whoever runs .com these days create direct cname entries without delegation?
Puzzled.
App Engine will serve SPDY from https automagically.
That's not what stateless means. And unless I am gravely mistaken, HTTP over SPDY is still stateless.