2009年7月31日星期五

让Firefox更安全,禁用RC4加密

现在网络安全越来越受人重视了,建议大家在Firefox中用更高强度的SSL加密算法AES

默认状态下,HTTPS链接会使用128位证书(如果不提供128位,则使用256位),但是如果我们觉得128位证书不够安全,那就需要强迫站点使用256位加密。打开Firefox浏览器,在地址栏中键入about:config,点击"保证小心",然后在页面顶端的过滤器中输入rc4,将过滤到的结果的value值为true的全部变为false(双击每个结果就可以改变),效果如下图:


以后新打开的加密页面就不再使用RC4加密了,如果不行请尝试清空Firefox的缓存。

2009年7月24日星期五

CNNIC称已升级DNS系统 更改信息15分钟可生效

7月23日,记者从CNNIC获悉,该中心7月22日完成原有DNS系统升级,今后CNNIC运维的中英文域名解析生效时间将由之前的4个小时缩短至15分钟左右.
据了解,CNNIC此次升级的包括中央主节点在内的全球9个域名顶级节点的域名解析(DNS)系统,涉及由CNNIC运维的中英文域名(英文域名包括 CN英文顶级域、6个类别域名和34个行政区域域名,中文域名包括.CN、.中国、.公司、.网络四个顶级域),升级之后,解析生效时间将由之前的4个小 时,缩短至15分钟左右.

另据部分域名注册商透露,CNNIC还将于7月25日10:00至7月26日4:00再次进行系统维护,届时将停止提供CN域名注册、中文域名注册、通用网址注册服务和注册商对帐系统,其它业务不受影响.

文/DoNews

2009年7月22日星期三

Fwd: 今天GOOGLE的登录按钮您看见了么?

今天早上一打开GOOGLE首页
习惯性的向右上角一看...
登录按钮给我放哪啦?!
只有一个个性化首页了....
https://twitter.com/hiid/statuses/2752811305
RT @kaifulee: 当然不是,Google.com由美国团队运营,遵守美国法律,Google.cn由中国团队运营,遵守中国法律。欢迎用户选择。如果你对跳转或.cn不满,请理解:如果没有.cn,我们就无法在中国合法运营,那么.com服务可能更不稳定

2009年7月6日星期一

Last-Modified ETag

1) 什么是”Last-Modified”?
  在浏览器第一次请求某一个URL时,服务器端的返回状态会是200,内容是你请求的资源,同时有一个Last-Modified的 属性标记此文件在服务期端最后被修改的时间,格式类似这样:
Last-Modified: Fri, 12 May 2006 18:53:33 GMT
客户端第二次请求此URL时,根据 HTTP 协议的规定,浏览器会向服务器传送 If-Modified-Since 报头,询问该时间之后文件是否有被修改过:
If-Modified-Since: Fri, 12 May 2006 18:53:33 GMT
如果服务器端的资源没有变化,则自动返回 HTTP 304 (Not Changed.)状态码,内容为空,这样就节省了传输数据量。当服务器端代码发生改变或者重启服务器时,则重新发出资源,返回和第一次请求时类似。从而 保证不向客户端重复发出资源,也保证当服务器有变化时,客户端能够得到最新的资源。
2) 什么是”Etag”?
   HTTP 协议规格说明定义ETag为“被请求变量的实体值” (参见 —— 章节 14.19)。 另一种说法是,ETag是一个可以与Web资源关联的记号(token)。典型的Web资源可以一个Web页,但也可能是JSON或XML文档。服务器单 独负责判断记号是什么及其含义,并在HTTP响应头中将其传送到客户端,以下是服务器端返回的格式:
ETag: "50b1c1d4f775c61:df3"
客户端的查询更新格式是这样的:
If-None-Match: W/"50b1c1d4f775c61:df3"
如果ETag没改变,则返回状态304然后不返回,这也和Last-Modified一样。本人测试Etag主要在断点下载时比较有用。
Last-Modified和Etags如何帮助提高性能?
   聪明的开发者会把Last-Modified 和ETags请求的http报头一起使用,这样可利用客户端(例如浏览器)的缓存。因为服务器首先产生 Last-Modified/Etag标记,服务器可在稍后使用它来判断页面是否已经被修改。本质上,客户端通过将该记号传回服务器要求服务器验证其(客 户端)缓存。
过程如下:
  1. 客户端请求一个页面(A)。
  2. 服务器返回页面A,并在给A加上一个Last-Modified/ETag。
  3. 客户端展现该页面,并将页面连同Last-Modified/ETag一起缓存。
  4. 客户再次请求页面A,并将上次请求时服务器返回的Last-Modified/ETag一起传递给服务器。
  5. 服务器检查该Last-Modified或ETag,并判断出该页面自上次客户端请求之后还未被修改,直接返回响应304和一个空的响应 体。

------------------------------
我们都知道,HTTP/1.1中有一个Etag,用来判断请求的文件是否被修改。
为什么要使用Etag呢?Etag主要为了解决Last-Modified无法解决的一些问题
1、一些文件也许会周期性的更改,但是他的内容并不改变(仅仅改变的修改时间),这个时候我们并不希望客户端认为这个文件被修改了,而重新GET;
2、某些文件修改非常频繁,比如在秒以下的时间内进行修改,(比方说1s内修改了N次),If-Modified-Since能检查到的粒度是s级的,这 种修改无法判断(或者说UNIX记录MTIME只能精确到秒)
3、某些服务器不能精确的得到文件的最后修改时间;

为此,HTTP/1.1引入了Etag(Entity Tags).Etag仅仅是一个和文件相关的标记,可以是一个版本标记,比如说v1.0.0或者说"2e681a-6-5d044840"这么一串看起来 很神秘的编码。但是HTTP/1.1 标准并没有规定Etag的内容是什么或者说要怎么实现,唯一规定的是Etag需要放在""内。

Etag由服务器端生成,客户端通过If-Match或者说If-None-Match这个条件判断请求来验证资源是否修改。我们常见的是使用If- None-Match.请求一个文件的流程可能如下:
====第一次请求===
1.客户端发起HTTP GET请求一个文件;
2.服务器处理请求,返回文件内容和一堆Header,当然包括Etag(例如"2e681a-6-5d044840")(假设服务器支持Etag生成和 已经开启了Etag). 状态码200

====第二次请求===
1.客户端发起HTTP GET请求一个文件,注意这个时候客户端同时发送一个If-None-Match头,这个头的内容就是我们第一次请求时服务器返回的 Etag:2e681a-6-5d044840
2.服务器判断发送过来的Etag和计算出来的Etag匹配,因此If-None-Match为False,不返回200,返回304,客户端继续使用本 地缓存;

流程很简单,问题是,如果服务器又设置了Cache-Control:max-age和Expires呢,怎么办?
答案是同时使用,也就是说在完全匹配If-Modified-Since和If-None-Match即检查完修改时间和Etag之后,服务器才能返回 304.(不要陷入到底使用谁的问题怪圈)

我们来看Apache中的Etag实现。
1.Apache首先判断是不是弱Etag,这个留在下面讲。如果不是,进入第二种情况:

强Etag根据配置文件中的配置来设置Etag值,默认的Apache的FileEtag设置为:
FileEtag INode Mtime Size
也就是根据这三个属性来生成Etag值,他们之间通过一些算法来实现,并输出成hex的格式,相邻属性之间用-分隔,比如:
Etag "2e681a-6-5d044840"
这里面的三个段,分别代表了INode,MTime,Size根据算法算出的值的Hex格式,(如果你在这里看到了非Hex里面的字符(也就是0-f), 那你可能看见神了:))

当然,我们可以改变Apache的FileEtag设置,比如设置成FileEtag Size,那么得到的Etag可能为:
Etag "6"
总之,设置了几个段,Etag值就有几个段。(不要误以为Etag就是固定的3段式)

说明
这里说的都是Apache 2.2里面的Etag实现,因为HTTP/1.1并没有规定Etag必须是什么样的实现或者格式,因此,你也可以修改或者完全编写自己的算法得到 Etag,比如 "2e681a65d044840",客户端会记住并缓存下这个Etag(Windows里面保存在哪里,我还没找到:(), 下次访问的时候直接拿这个值去和服务器生成的Etag对比。

注意
不管怎么样的算法,在服务器端都要进行计算,计算就有开销,会带来性能损失。因此为了榨干这一点点性能,不少网站完全把Etag禁用了(比如 Yahoo!),这其实不符合HTTP/1.1的规定,因为HTTP/1.1总是鼓励服务器尽可能的开启Etag。

弱校验(弱Etag)
重新考虑前面提到的3个问题:
问题1、一些文件也许会周期性的更改,但是他的内容并不改变(仅仅改变的修改时间),这个时候我们并不希望客户端认为 这个文件被修改了,而重新GET;

解决办法:如果使用强Etag,每次得会要求重新GET页面,如果使用Etag,比方说设置成FileEtag Size等,就可以忽略MTime造成的Last-Modified时间修改从而影响了If-Modified-Since(IMS)这个校验了。这点和 弱Etag无关。

问题2、某些文件修改非常频繁,比如在秒以下的时间内进行修改,(比方说1s内修改了N次),If- Modified-Since能检查到的粒度是s级的,这种修改无法判断(或者说UNIX记录MTIME只能精确到秒)

解决办法:如果是这种情况,Apache会自动判断请求时间和修改时间之间的差值,如果小于1s,Apache会认为 这个文件在这1秒内可能会再次被修改,因此生成一个弱Etag(Weak Etag),这个Etag仅仅基于MTime来生成,因此MTime只能精确到s,所以1s内生成的Etag总是一样,这样就避免了使用强Etag造成的 1s内频繁的刷新Cache的情况。(貌似不用Etag,仅仅使用Last-Modified就可以解决,但是这针对的仅仅是修改超级频繁的情况,很多文 件可能同时也使用强Etag验证)。弱Etag以W/开始,比如:W/"2e681a"

问题3、某些服务器不能精确的得到文件的最后修改时间;

解决办法:生成Etag,因为Etag可以综合Inode,MTime和Size,可以避免这个问题

2009年7月4日星期六

High Performance Web Sites: The Importance of Front-End Performance

In 2004, I started the Exceptional Performance group at Yahoo!. We're a small team chartered to measure and improve the performance of Yahoo!'s products. Having worked as a back-end engineer most of my career, I approached this as I would a code optimization project - I profiled web performance to identify where there was the greatest opportunity for improvement. Since our goal is to improve the end-user experience, I measured response times in a browser over various bandwidth speeds. What I saw is illustrated in the following chart showing HTTP traffic for http://www.yahoo.com.

In the figure above, the first bar, labeled "html", is the initial request for the HTML document. In this case, only 5% of the end-user response time is spent fetching the HTML document. This result holds true for almost all web sites. In sampling the top ten U.S. websites, all but one spend less than 20% of the total response time getting the HTML document. The other 80+% of the time is spent dealing with what's in the HTML document, namely, the front-end. That's why the key to faster web sites is to focus on improving front-end performance.
There are three main reasons why front-end performance is the place to start.
  1. There is more potential for improvement by focusing on the front-end. Cutting it in half reduces response times by 40% or more, whereas cutting back-end performance in half results in less than a 10% reduction.
  2. Front-end improvements typically require less time and resources than back-end projects (redesigning application architecture and code, finding and optimizing critical code paths, adding or modifying hardware, distributing databases, etc.).
  3. Front-end performance tuning has been proven to work. Over fifty teams at Yahoo! have reduced their end-user response times by following our performance best practices, often by 25% or more.
Our performance golden rule is: optimize front-end performance first, that's where 80% or more of the end-user response time is spent.
Steve Souders
[Steve Souders is Yahoo!'s Chief Performance Yahoo!. This is one in a series of Best Practices for Speeding Up Your Web Site. This article is based on Steve's book High Performance Web Sites, published by O'Reilly.]
Posted at March 20, 2007 9:16 AM

2009年7月1日星期三

Google Hosts文件

研究了一晚上google的域名,自己从位于加利福尼亚的谷歌总部DNS服务器上扒出来的。
把下面的内容添加到C:\Windows\System32\drivers\etc\hosts文件中就行了

#Search
64.233.189.147 www.google.com
64.233.189.104 www.google.com
64.233.189.99 www.google.com
64.233.189.147 www.l.google.com

#Mail(POP3/SMTP)
209.85.147.109 pop.gmail.com
209.85.147.109 smtp.gmail.com

#WebMail
64.233.189.18 mail.google.com
64.233.189.19 mail.google.com
64.233.189.83 mail.google.com
64.233.189.18 www.gmail.com
64.233.189.19 www.gmail.com
64.233.189.83 www.gmail.com
64.233.189.19 googlemail.l.google.com

#Docs
64.233.189.101 writely-china.l.google.com
64.233.189.101 writely.l.google.com
64.233.189.102 docs.google.com
64.233.189.101 docs.google.com
64.233.189.100 docs.google.com

#Map
64.233.189.104 map.google.com
64.233.189.99 map.google.com
64.233.189.147 map.google.com
64.233.189.104 maps.google.com
64.233.189.99 maps.google.com
64.233.189.147 maps.google.com
64.233.189.99 maps.gstatic.com
203.208.39.93 khm.google.com
203.208.39.91 mt0.google.com
203.208.39.93 mt1.google.com
203.208.39.91 mt2.google.com
203.208.39.91 mt.l.google.com
64.233.189.99 maps.l.google.com

#Scholar
64.233.189.99 scholar.google.com
64.233.189.104 scholar.google.com
64.233.189.147 scholar.google.com
64.233.189.104 scholar.l.google.com

#Group
64.233.189.102 groups.google.com
64.233.189.100 groups.google.com
64.233.189.101 groups.google.com
64.233.189.101 groups.l.google.com

#Misc
64.233.189.101 id.google.com
64.233.189.102 id.google.com
64.233.189.100 id.google.com
64.233.189.100 id.l.google.com