Will SPDY ever run over regular HTTP? Serving images or any other static/security-independant content over secure SSL connection is not something that is necessary I guess.
From http://dev.chromium.org/spdy/spdy-whitepaper "To make SSL the underlying transport protocol, for better security and compatibility with existing network infrastructure. Although SSL does introduce a latency penalty, we believe that the long-term future of the web depends on a secure network connection. In addition, the use of SSL is necessary to ensure that communication across existing proxies is not broken."
Yes, but nor Chrome or Firefox by default will run withouth SSL.
From the server, you can hint back to the HTTP client "Alternate-Protocol: 443:npn-spdy/2" as a header, and if it supports SPDY, it will switch to SSL/SPDY.
It's very rough, as in "Oh this is neat lets get something working!" but it's already working and ought to make it much easier to enable mod_spdy usage on Ubuntu. If anyone wants to help test/bang on this we're in #juju on freenode!
If you want to use it with Apache 1.3 I assume you have an application which requires that version. If so why not put an apache 2.2 instance in front of it and proxy the traffic to the current instance. You can even run this on the same machine if you need to.
[spdy-whitepaper] The kills-any-discussion-like-Godwin excuse "but homes don't support XYZ, therefore we don't" really blows. Recently, XYZ was IPv6, now it's SCTP.
Not at the moment, I was testing my site with Firefox 11 and I was able to toggle the usage of spdy by setting the right configs in about:config in another tab. I don't know why this didn't work for you. Maybe try another tutorial for enabling spdy in FF11?
Having an Apache module is nice, but forcing use of HTTPS is not. 99% of the content we serve is not over HTTPS, nor is there any reason to secure it. Further, the CA/Browser Forum is quite happy to force artificially inflated prices for digital certificates that can be generated in a split second and automatically. So, I need a bunch of certificates or a wildcard certificate? Both cost money.
We have several domains on the same machine. We still see lack of proper support for Server Name Indication (SNI), so forcing domains to use HTTPS presents issues for many non-SPDY clients.
Bottom line is that SPDY means problems for devices not supporting SNI and increased cost for digital certificates.
Google could help with the latter by selling wildcard domain certificates at a price that is on par with the actual cost of production. I think that's damn-near close to $0. Still not sure what to do about lack of SNI support, but we do see older browsers out there.
One cannot say visit https://www.example.com (if you support SPDY) and http://www.example.com (if you do not support SPDY). We need a single URL that all browsers can access.
Android 3.2 does not support SNI. Some older, but still used, browsers do not support SNI.
It's not only browsers on PCs, tablets, etc. We need to ensure server-to-server communication works, and not all servers support SNI, either. Some web services provided from my own machine are accessed by other servers. If I used SPDY, I'd require use of TLS and, since we have multiple domains on the server, SNI would be required.
I've found one CA that offers free certificates. The certificates are not wildcard (unless there is one I do not know about) and expire after one year. Managing a gaggle of certificates like that is a pain.
I'd rather CAs actually do the checking they're supposed to do and charge money for it, than discard all checking for the sake of cost and have someone else be able to get an SSL certificate for my website.
Carefully checking every request takes time and costs money. It makes the certificate business less profitable.
There are "Extended Validation" certificates, as you know. Those cost more money and are more carefully validated, I assume.
I'm here arguing I rarely have need for TLS for most content, so I sure as heck don't need EV certificates. Some people do, though. It's good that PayPal uses EV.
A reasonable balance is to only issue certificates to a specific email address (e.g., hostmaster@). If everyone agreed to a single address, then we could agree on a way to prove domain ownership. Sure, somebody could compromise your email address, just as they could steal your EV certificate, too.
No system is perfect, but what I do know is that the current system is nothing but a profit engine. Certificates are produced at virtually no cost, but the price charged is relatively high. EV works fine for businesses that hold customer data, process credit cards, etc. For the rest of us, EV and even regular certificates are expensive and a hassle. For me, it's mostly about cost (especially for wildcard certs) and period of validity. I can get a 5 year cert, but at well over $100/yr. That's simply too high knowing how trivial it is to produce.
Matt, StartSSL provides free certs that are not wildcard and only valid for one year. I do not necessarily require a certificate to be free, but I want a reasonable balance between price and "pain". Dealing with 10 or 20 different certificates every year is a pain. Likewise, paying $100+ per certificate per year for wildscard domains is too expensive.
Now, keep in mind why I'm complaining about this: because SPDY requires TLS. One cannot get benefits of SPDY without TLS.
Perhaps this does not matter. Does SPDY provide any performance benefits over non-TLS HTTP? All of the comparisons I've seen I assume are compared only against TLS. If so, perhaps most of the web will not move to SPDY because of the TLS requirement.
Anyway, if Google wants SPDY adopted for use on all web sites, the certificate cost / handling issues need to be addressed. Having had to mess with this, it's hard to convince me that I should waste a day of my life every year dealing with those.
Before mod_spdy was labelled experimental and not necessarily suitable for production yet. I don't see if that is still called out anywhere. Any thoughts on that?
The Apache version required for SPDY is 2.2.4 and version 2.2 of mod_ssl is needed, but the latest Apache version available from CentOS 5 x64 repositories is 2.2.22.
mod_ssl is not installed on the server at all and yum can't find it either.
Looks like some dirty upgrades are needed for CentOS 5.6 x86_64 before to get hands on SPDY :)
Thanks for sharing your info. I really appreciate your efforts and I will be waiting for your further write ups thanks once again. flash to html5 converter| html5 development
What will it take to have 2 apache instances communicate via SPDY? I have video/ audio/ image serving site which has nginx talking to apache at the incoming side (both on same machine). And then this apache instance talks to one more service running another apache over the network (within same data center, though). I would like to use SPDY to communicate between nginx <--> apache (same machine) and then apache <--> apache (different machines). I am assuming this can be achieved. Possible? And does it make sense?
haveing mod_spdy installed and working on centos6!
i've also tested with CAS (http://www.jasig.org/cas/protocol) and get redirect and authentication errors on CAS.
can i disable mod_spdy per vhost or per "request" url?https://sslserver/cas/*
my workaround is to buy a second certificate on an seperate apache vhost to get this working, but now i disabled mod_spdy for getting authentication to work fine.
any ideas? (maybe with apache RequestHeader unset / set ?)
Will SPDY ever run over regular HTTP? Serving images or any other static/security-independant content over secure SSL connection is not something that is necessary I guess.
ReplyDeleteFrom http://dev.chromium.org/spdy/spdy-whitepaper "To make SSL the underlying transport protocol, for better security and compatibility with existing network infrastructure. Although SSL does introduce a latency penalty, we believe that the long-term future of the web depends on a secure network connection. In addition, the use of SSL is necessary to ensure that communication across existing proxies is not broken."
DeleteSSL is basically to tunnel through proxies.
Yes, but nor Chrome or Firefox by default will run withouth SSL.
DeleteFrom the server, you can hint back to the HTTP client "Alternate-Protocol: 443:npn-spdy/2" as a header, and if it supports SPDY, it will switch to SSL/SPDY.
Regards
Wow - it works !!!!
ReplyDeleteYes i would have the same question too. It would be nice if it would be run over HTTP and not HTTPS
ReplyDeleteClint Byrum has hacked together a quick juju charm for those of you deploying on Ubuntu servers:
ReplyDelete- http://jujucharms.com/~clint-fewbar/precise/mod-spdy
It's very rough, as in "Oh this is neat lets get something working!" but it's already working and ought to make it much easier to enable mod_spdy usage on Ubuntu. If anyone wants to help test/bang on this we're in #juju on freenode!
Any plans to do this for nginx? I abandoned Apache a while back and now pretty much use nginx exclusively.
ReplyDeletehttps://twitter.com/#!/nginxorg/status/150112670966747137
DeleteNeat. +1 for Nginx support.
ReplyDelete+1 for Nginx support
ReplyDeleteApache. Meh. Wake me up when Nginx has support for it.
ReplyDeleteI'm guessing Apache 1.3 is out of the question? We, unfortunately, are stuck on that :(
ReplyDeleteIf you want to use it with Apache 1.3 I assume you have an application which requires that version. If so why not put an apache 2.2 instance in front of it and proxy the traffic to the current instance. You can even run this on the same machine if you need to.
ReplyDelete[spdy-whitepaper] The kills-any-discussion-like-Godwin excuse "but homes don't support XYZ, therefore we don't" really blows. Recently, XYZ was IPv6, now it's SCTP.
ReplyDeleteIf you want to test if your browser supports SPDY you may do so here: https://www.isspdyenabled.com/
ReplyDeleteI have FF 11, and enabled spdy per the instructions, but still your test page says it is not spdy enabled.
DeleteChrome works fine.
Suggestions?
Not at the moment, I was testing my site with Firefox 11 and I was able to toggle the usage of spdy by setting the right configs in about:config in another tab. I don't know why this didn't work for you. Maybe try another tutorial for enabling spdy in FF11?
DeleteIf your splitting off threads after the SPDY connection handler, does this mean it only works with "Worker" and not "Prefork" apache mode?
ReplyDeleteHaving an Apache module is nice, but forcing use of HTTPS is not. 99% of the content we serve is not over HTTPS, nor is there any reason to secure it. Further, the CA/Browser Forum is quite happy to force artificially inflated prices for digital certificates that can be generated in a split second and automatically. So, I need a bunch of certificates or a wildcard certificate? Both cost money.
ReplyDeleteWe have several domains on the same machine. We still see lack of proper support for Server Name Indication (SNI), so forcing domains to use HTTPS presents issues for many non-SPDY clients.
Bottom line is that SPDY means problems for devices not supporting SNI and increased cost for digital certificates.
Google could help with the latter by selling wildcard domain certificates at a price that is on par with the actual cost of production. I think that's damn-near close to $0. Still not sure what to do about lack of SNI support, but we do see older browsers out there.
If clients don't support SNI they will not support SPDY anyway. Just serve them the page through HTTP then.
DeleteAlso certificates are available for free from at least one CA and have been for a few years now.
One cannot say visit https://www.example.com (if you support SPDY) and http://www.example.com (if you do not support SPDY). We need a single URL that all browsers can access.
DeleteAndroid 3.2 does not support SNI. Some older, but still used, browsers do not support SNI.
It's not only browsers on PCs, tablets, etc. We need to ensure server-to-server communication works, and not all servers support SNI, either. Some web services provided from my own machine are accessed by other servers. If I used SPDY, I'd require use of TLS and, since we have multiple domains on the server, SNI would be required.
I've found one CA that offers free certificates. The certificates are not wildcard (unless there is one I do not know about) and expire after one year. Managing a gaggle of certificates like that is a pain.
I'd rather CAs actually do the checking they're supposed to do and charge money for it, than discard all checking for the sake of cost and have someone else be able to get an SSL certificate for my website.
DeleteCarefully checking every request takes time and costs money. It makes the certificate business less profitable.
DeleteThere are "Extended Validation" certificates, as you know. Those cost more money and are more carefully validated, I assume.
I'm here arguing I rarely have need for TLS for most content, so I sure as heck don't need EV certificates. Some people do, though. It's good that PayPal uses EV.
A reasonable balance is to only issue certificates to a specific email address (e.g., hostmaster@). If everyone agreed to a single address, then we could agree on a way to prove domain ownership. Sure, somebody could compromise your email address, just as they could steal your EV certificate, too.
No system is perfect, but what I do know is that the current system is nothing but a profit engine. Certificates are produced at virtually no cost, but the price charged is relatively high. EV works fine for businesses that hold customer data, process credit cards, etc. For the rest of us, EV and even regular certificates are expensive and a hassle. For me, it's mostly about cost (especially for wildcard certs) and period of validity. I can get a 5 year cert, but at well over $100/yr. That's simply too high knowing how trivial it is to produce.
Try a cert for free: http://www.startssl.com/ :D
DeleteMatt, StartSSL provides free certs that are not wildcard and only valid for one year. I do not necessarily require a certificate to be free, but I want a reasonable balance between price and "pain". Dealing with 10 or 20 different certificates every year is a pain. Likewise, paying $100+ per certificate per year for wildscard domains is too expensive.
DeleteNow, keep in mind why I'm complaining about this: because SPDY requires TLS. One cannot get benefits of SPDY without TLS.
Perhaps this does not matter. Does SPDY provide any performance benefits over non-TLS HTTP? All of the comparisons I've seen I assume are compared only against TLS. If so, perhaps most of the web will not move to SPDY because of the TLS requirement.
Anyway, if Google wants SPDY adopted for use on all web sites, the certificate cost / handling issues need to be addressed. Having had to mess with this, it's hard to convince me that I should waste a day of my life every year dealing with those.
Before mod_spdy was labelled experimental and not necessarily suitable for production yet. I don't see if that is still called out anywhere. Any thoughts on that?
ReplyDeleteThe Apache version required for SPDY is 2.2.4 and version 2.2 of mod_ssl is needed, but the latest Apache version available from CentOS 5 x64 repositories is 2.2.22.
ReplyDeletemod_ssl is not installed on the server at all and yum can't find it either.
Looks like some dirty upgrades are needed for CentOS 5.6 x86_64 before to get hands on SPDY :)
At least you're on Linux.
DeleteBuilding it on FreeBSD systems is a major pain.
+1 for Nginx support.
ReplyDelete+1 for Building it on FreeBSD.
Thanks for sharing your info. I really appreciate your efforts and I will be waiting for your further write ups thanks once again.
ReplyDeleteflash to html5 converter| html5 development
Will this be added into Google Pagespeed Module?
ReplyDeleteWhat will it take to have 2 apache instances communicate via SPDY? I have video/ audio/ image serving site which has nginx talking to apache at the incoming side (both on same machine). And then this apache instance talks to one more service running another apache over the network (within same data center, though). I would like to use SPDY to communicate between nginx <--> apache (same machine) and then apache <--> apache (different machines). I am assuming this can be achieved. Possible? And does it make sense?
ReplyDeletehi!
ReplyDeletehaveing mod_spdy installed and working on centos6!
i've also tested with CAS (http://www.jasig.org/cas/protocol) and get redirect and authentication errors on CAS.
can i disable mod_spdy per vhost or per "request" url?https://sslserver/cas/*
my workaround is to buy a second certificate on an seperate apache vhost to get this working, but now i disabled mod_spdy for getting authentication to work fine.
any ideas?
(maybe with apache RequestHeader unset / set ?)
regards from austria,
josy