节约网站带宽

过去的三年中，CodingHorror的访问量大大超出了我的预期，我当然不是在抱怨，找到一位读者并且与之展开对话本是写博客的初衷。 

但是在网上，流行意味着费用，特别是带宽费用。上周当《为什么程序员不能...写程序？》这篇文章成为超级热门，网站一天的流量飙升到了近9GB：

 这足够塞满两条T1专线——接近300KB/S——并且几乎每天如此。为了让网站不至于宕机，我们甚至限制了部分内容的访问。从那以后，我们意识到该做点什么了。如何才能节约网站的带宽占用？

 

 

1、使用外部图片托管

图片是头号通缉犯，除非你的网站是纯文字的。即使是这个近乎简陋的网站，图片占用的字节也要比文字多得多，让我们看看我的上一篇文章的字节占用，一篇很典型的文章：

文字：  约4,900字节

图片： 约46,300字节

网站图片： 约4,600字节

文字只占了所有内容字节的10%，为了让带宽占用有所改观，我们必须首先处理占用了90%带宽的图片。

 

理想地说，我们其实不用在自己的服务器上放一张图片，而将所有图片寄放在外部网站，有许多免费的或近乎免费的图片网站：

 

Imageshack

Imageshack提供免费无限制的存储空间，但是每张图片每小时的流量不超过100MB，听起来似乎很多，但是算一下：等于1.66MB/分钟，28KB/秒，你的图片越大，意味着你的配额越快用完。但是这个网站非常好用——甚至不用注册，根据他们的说明，任何东西都可以放上去，只要不违法。

 

Flickr

Flickr对免费用户有容量和带宽限制，但是不限制下载带宽。花25美元升级到专业帐户则取消限制。但是Flickr的使用条款警告“禁止将Flickr用于职业用途和企业”，并且所有外部引用的图片都必须链回Flickr。

 

Photobucket

Photobucket免费帐户的流量限制为10GB/月（约14MB/小时），花25美元升级到专业帐户则取消带宽限制，我没有在他们的服务条款里面找到任何相关限制。

 

Amazon S3

Amazon S3服务允许你直接链接文件，空间费用15美分/GB，流量费用20美分/GB，至少有一个网站运行良好。

 

我很喜欢Imageshack，但因为带宽限制不能负载高访问量；Photobucket使用条款最宽松，但Flickr提供更好更成熟的工具包，不幸的是，我花钱升级到专业帐户后才发现Flickr使用条款上的限制说明，所以只能顺其自然了。补充：因为不少公司防火墙限制了图片网站，看来只有Amazon S3是最好的长期选择。

 

虽然我最后付出了25美元/年的代价，但物有所值，我仅用2美元/月就将90%的带宽负担转嫁给了外部网站。

从此以后我不必再用URL重写的方式阻止图片盗用，所有人都可以自由使用，用户也可以随心所欲地用阅读器查看我的文章。

 

对了，不要忘了favicon.ico也是一个图片，它正越来越多的被阅读器和浏览器读取，favicon.ico越小越好，因为它会出人意料地影响你的带宽。

 

 

2、开启HTTP压缩

搞定了图片，开始处理剩下的内容——文字，这事小菜一碟，启用WEB服务器的HTTP压缩就可以节约三分之二的文字带宽，同样以上一篇文章为例：

原始文字： 63,826字节

压缩后： 21,746字节

 

不费吹灰之力，我们就节约了66%的文字带宽，包括所有的文字内容：java***，HTML，CSS，在IIS6.0中开启HTTP压缩功能非常简单，Apache也一样。

永远不要提供未经HTTP压缩的内容，这可是唾手可得的免费午餐，如果不确定你的网站是否开启了HTTP压缩，试试这个HTTP压缩测试工具。

 

 

3、把RSS种子托管出去

许多网站提供RSS种子方便用户订阅，用户不必访问网站，RSS阅读器会帮用户定时获取网站的内容更新。用户可以更自由地阅读你的文章，离线也行。很不错，不是吗？

 

是很不错，除非你意识到RSS种子吞噬了你多少带宽。事实很惊人！Scott Hanselman告诉我他的一半带宽被RSS种子占去，Rick Klau说他的60%的页面浏览来自RSS种子。整个RSS体系决定于RSS阅读器是否合理，糟糕的阅读器会每隔一小时下载你未经压缩的RSS种子，即使没有更新。想象一下全世界数以千计糟糕的阅读器，实际上它们到处都是。

 

所以我有意要把这个大包袱外包出去，于是FeedBurner出现在我的视线中。虽然我很乐于把图片放到别的网站，但把RSS种子这样重要的东西交给别人，我仍然不太放心。Scott Hanselman不久前开始使用FeedBurner，所以我发了封邮件给他问问他的想法。他非常热情地给我打电话打消我的顾虑，甚至给我他的FeedBurner帐号试用。

 

我已经在今天下午3点将RSS种子放到了FeedBurner上，我依据ISAPI重写原则将原来的Feed URL重新定向到了新的地址。

惊喜的是带宽占用马上就有了改观，服务器每秒和每分的流量都少了许多。FeedBurner的状态页显示我的RSS种子每一秒就有一次下载，如此算来，即使经过压缩，RSS的数据量也有31KB/S。

除了节约带宽，FeedBurner还有很多别的好处。

 

 

4、优化java***和CSS，减小尺寸

最后要做的就是减小文字内容的尺寸了，特别是每个页面都会包含的共用内容，CSS和java***是首先需要优化的，也可以同样的方法优化HTML。

 

推荐一个方便的在线CSS压缩工具，它提供三个级别的CSS压缩，我用它压缩了这个页面的主CSS文件，结果如下：

原始CSS尺寸： 2,299字节

去掉无用空格后： 1,758字节

HTTP压缩后： 615字节

 

我们也同样可以用在线java***压缩工具优化java***，其基于Douglas Crockford的JSMin。在压缩之前，我重新看了一遍JS并重构了代码，使用更短的变量，删去冗余的代码：

原始JS尺寸： 1,232字节

重构之后： 747字节

去掉无用空格后： 558字节

HTTP压缩后： 320字节

 

可以将去除空格的办法同样用于HTML，但并不推荐。我试了一下，尺寸只是减少了10%，因此影响了可读性就不值得了。

事实上，去除空格和换行的工作都是压缩工具会帮我们做的，我们只是稍微动动手优化一下效率：

                              原始尺寸       压缩后

未优化的CSS      2,299字节       671字节

优化后的CSS      1,758字节       615字节

 

如果启用HTTP压缩，优化之后CSS只是小了10%。折衷方案是将格式打乱的代码复制到编辑工具，比如Visual Studio 2005，它会自动重新编排代码格式。

 

虽然这只是微小的优化，但却减小了每个页面的尺寸，我觉得还是值得的。其实我们还有更多的办法去榨干每一个多余的字节，但并不必要，因此略去了。

 

大功告成，非常高兴地看到带宽的使用情况有了明显改善，页面载入也从没有像现在这样顺畅。但是以上的建议并不一定就是灵丹妙药，如果访问量来得太集中，即使是最小化的，压缩过的文字内容也能瞬间堵塞一根300KB/S的专线。但我仍然希望这些措施能让我的网站应对下一次的Digg风暴，而不至于像上次那样狼狈。

本文由译言网的老困翻译。