Monthly Archives: March 2010

这是一篇译文,原文:http://blog.httpwatch.com/2009/01/15/https-performance-tuning/ 在网络性能优化中一个经常被忽略的问题是保障安全连接的https协议.随着应用从桌面转移到web,广泛被应用的https协议中安全和隐私的可靠性越来越重要. 下面的例子展示使用https过程中常见的问题. 例1:使用有效的响应 每当浏览器访问一个网站,它必须创建一个或多个tcp链接.既是在常见的http协议下,这也是个漫长的过程.使用tcp链接的有效的响应可以减少这中开销.下面来自httpwatch的图表显示在访问英国一网站时tcp连接时间大约130毫秒 使用https时,如果不是有效链接将会造成长时间的延迟.因为就算tcp已经连接,ssl链接也需要建立请求.浏览器和服务端会来回通信几次来建立加密的密钥.使用https链接相应时间是http的四倍以上. 在一个重复的https链接里tcp链接和ssl通信的开销是应该避免的.虽然现在有些浏览器允许重复使用ssl链接,但是你不能总指望每个服务器都作了这样的配置. 例2:避免混合内容警告 在前一篇博文中提到,如果一个https页面使用了任何http资源,就会出现令人迷惑和烦人的警告对话框. 为了避免这个警告提示,要确保这个页面包含的资源都是https. 例3:使用持久缓存的静态内容 如果你按照例子2,那么页面上所有的资源(图片,css,js)都在https下面了,你应该持续地使用静态缓存,来避免每次每个用户再次访问站点重复下载. 淡然你不会对所有东西缓存,账户信息和每月的饼图就不用.但是大多数资源还是要安全的存储,页面间分享和再次使用. 这里可能有一些混乱对于https下是否使用缓存. 例如在https下的gmail,确实访问速度要慢一些,因为浏览器不缓存这些页面. 虽 然，37Signals公司承认，在内存中缓存是可能的，他们说 ， 持 续的缓存是不可能的 ： 但在现实中https下持续缓存在ie和firefox下是可能的. 访问www.httpwatch.com,通过httpwatch我们可以看到,所有资源都是通过缓存来访问的. 如果你使用firefox3.0,并不修改请求头部,看到的是: 我们看到这里并没有缓存,这是因为头部设置的原因,firefox每次是请求的服务器.200代表静态内容是从服务器上求情成功的. 但是我们在firefox地址输入”about:cache”,找到这些缓存文件 这里修改一下设置就可以了,修改Cache-Control response header to Public. 这样我们就把https下的内容移动到了firefox的缓存空间.于是再次访问 这个方法只有在firefox3.0才可以(译者音:经过试验,3.0以后的都是可以的,也不需要该header信息) 例4:使用https警告探测器 译者音:作者说了那么多广告,我这里就不翻译了,这段话就一个意思,使用httpwatch可以给出https下的警告.使用方法和上面截图基本上一样的.