分享未来 ^Internet _Technology

"100" : Continue
"101" : witching Protocols
"200" : OK
"201" : Created
"202" : Accepted
"203" : Non-Authoritative Information
"204" : No Content
"205" : Reset Content
"206" : Partial Content
"300" : Multiple Choices
"301" : Moved Permanently
"302" : Found
"303" : See Other
"304" : Not Modified
"305" : Use Proxy
"307" : Temporary Redirect
"400" : Bad Request
"401" : Unauthorized
"402" : Payment Required
"403" : Forbidden
"404" : Not Found
"405" : Method Not Allowed
"406" : Not Acceptable
"407" : Proxy Authentication Required
"408" : Request Time-out
"409" : Conflict
"410" : Gone
"411" : Length Required
"412" : Precondition Failed
"413" : Request Entity Too Large
"414" : Request-URI Too Large
"415" : Unsupported Media Type
"416" : Requested range not satisfiable
"417" : Expectation Failed
"500" : Internal Server Error
"501" : Not Implemented
"502" : Bad Gateway
"503" : Service Unavailable
"504" : Gateway Time-out
"505" : HTTP Version not supported

-------------------------------------------------------------------------------------------------

HTTP协议状态码表示的意思主要分为五类 ,大体是 :  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
1×× 　　保留   
2×× 　　表示请求成功地接收   
3×× 　　为完成请求客户需进一步细化请求   
4×× 　　客户错误   
5×× 　　服务器错误   

100 Continue
指示客户端应该继续请求。回送用于通知客户端此次请求已经收到，并且没有被服务器拒绝。
客户端应该继续发送剩下的请求数据或者请求已经完成，或者忽略回送数据。服务器必须发送
最后的回送在请求之后。

101 Switching Protocols 
服务器依照客服端请求，通过Upgrade头信息，改变当前连接的应用协议。服务器将根据Upgrade头立刻改变协议
在101回送以空行结束的时候。

 

Successful 
=================================
200 OK 
指示客服端的请求已经成功收到，解析，接受。

201 Created 
请求已经完成并一个新的返回资源被创建。被创建的资源可能是一个URI资源，通常URI资源在Location头指定。回送应该包含一个实体数据
并且包含资源特性以及location通过用户或者用户代理来选择合适的方法。实体数据格式通过煤体类型来指定即content-type头。最开始服务 器
必须创建指定的资源在返回201状态码之前。如果行为没有被立刻执行，服务器应该返回202。

202 Accepted 
请求已经被接受用来处理。但是处理并没有完成。请求可能或者根本没有遵照执行，因为处理实际执行过程中可能被拒绝。

203 Non-Authoritative Information

204 No Content 
服务器已经接受请求并且没必要返回实体数据，可能需要返回更新信息。回送可能包含新的或更新信息由entity-headers呈现。

205 Reset Content 
服务器已经接受请求并且用户代理应该重新设置文档视图。

206 Partial Content 
服务器已经接受请求GET请求资源的部分。请求必须包含一个Range头信息以指示获取范围可能必须包含If-Range头信息以成立请求条件。

Redirection 
==================================
300 Multiple Choices
请求资源符合任何一个呈现方式。

301 Moved Permanently 
请求的资源已经被赋予一个新的URI。

302 Found 
通过不同的URI请求资源的临时文件。
303 See Other

304 Not Modified 
如果客服端已经完成一个有条件的请求并且请求是允许的，但是这个文档并没有改变，服务器应该返回304状态码。304
状态码一定不能包含信息主体，从而通常通过一个头字段后的第一个空行结束。

305 Use Proxy
请求的资源必须通过代理（由Location字段指定）来访问。Location资源给出了代理的URI。

306 Unused

307 Temporary Redirect

 

Client Error 
=====================
400 Bad Request 
因为错误的语法导致服务器无法理解请求信息。

401 Unauthorized 
如果请求需要用户验证。回送应该包含一个WWW-Authenticate头字段用来指明请求资源的权限。

402 Payment Required 
保留状态码

403 Forbidden 
服务器接受请求，但是被拒绝处理。

404 Not Found 
服务器已经找到任何匹配Request-URI的资源。

405 Menthod Not Allowed 
Request-Line 请求的方法不被允许通过指定的URI。

406 Not Acceptable

407 Proxy Authentication Required

408 Reqeust Timeout 
客服端没有提交任何请求在服务器等待处理时间内。

409 Conflict

410 Gone

411 Length Required 
服务器拒绝接受请求在没有定义Content-Length字段的情况下。

412 Precondition Failed

413 Request Entity Too Large 
服务器拒绝处理请求因为请求数据超过服务器能够处理的范围。服务器可能关闭当前连接来阻止客服端继续请求。

414 Request-URI Too Long 
服务器拒绝服务当前请求因为URI的长度超过了服务器的解析范围。

415 Unsupported Media Type 
服务器拒绝服务当前请求因为请求数据格式并不被请求的资源支持。

416 Request Range Not Satisfialbe

417 Expectation Failed

 

Server Error 
===================================
500 Internal Server Error 
服务器遭遇异常阻止了当前请求的执行

501 Not Implemented 
服务器没有相应的执行动作来完成当前请求。

502 Bad Gateway

503 Service Unavailable 
因为临时文件超载导致服务器不能处理当前请求。

504 Gateway Timeout

505 Http Version Not Supported

今天看kevintang 写的关于运营规划师的博文，里面提到“cookie隔离”技术，这名词还是第一次听说，网上搜了半天也没有相关的文章，

思索了半天，自己做了下实验，理解了一下思路，遂整理一下：

 

cookie隔离技术和传统的多域名拆分请求，提高浏览器并发请求数有点类似，均是采用多域名来处理请求

 

传统做法是将css，js，图片等静态文件放在多个域名下面请求，这样就可以跨过浏览器对统一主机名并发连接数的限制，提高整体并发请求量。

 

cookie隔离技术则是通过使用多个非主要域名来请求静态文件，如果静态文件都放在主域名下，那静态文件请求的时候带有的cookie的数据提交给server是非常浪费的，还不如隔离开。

 

因为cookie有域的限制，因此不能跨域提交请求，故使用非主要域名的时候，请求头中就不会带有cookie数据，这样可以降低请求头的大小，降低请求时间，从而达到降低整体请求延时的目的。同时这种方式不会将cookie传入webserver，也减少了webserver对cookie的处理分析环节，提高了webserver的http请求的解析速度。

kevintang给出的测试结果是：

[code="plain"]
在做腾讯网加速的时候，启用了两个非qq.com的新域名，mat1.gtimg.com和img1.gtimg.com，隔离前10个cookie，185字节，约4KB，存在请求延时现象，隔离后无cookie，图片服务器速度由原来0.63秒提升到0.43秒，速度提升32%[/code]

浏览器缓存现象

浏览器通过URL地址访问一个网页，显示网页内容的同时会在用户的电脑上面缓存网页内容。如果网页没有更新的话，浏览器再次访问这个URL地址的时候，就不会再次下载网页，而是直接使用本地缓存的网页。只有当网站明确标识资源已经更新，浏览器才会再次下载网页。

一、HTTP缓存涉及的http头

1. Expires（过期时间）HTTP头信息

Expires属性是告诉缓存器缓存在多长时间内是有效的。过了该时间，缓存器就会向源服务器发送请求，检查文档是否被修 改。几乎所有的缓存服务器都支持Expires属性；

Web服务器设置Expires属性的方法有：

• 绝对时间间隔：基于客户最后查看副本的时间（最后访问时间）

• 根据服务器上文档最后被修改的时间

适用范围：

• 对于设置静态图片文件（例如导航栏和图片按钮）可缓存特别有用；因为这些图片修改很少，你可以给它们设置一个特别长的过期时间，这会使你的网站对 用户变得相应非常快；
• 对于控制有规律改变的网页也很有用。例如：你每天早上6点更新新闻页，你可以设置副本的过期时间也是这个时间，这样缓存 服务器就知道什么时候去取一个更新版本，而不必让用户去按浏览器的“刷新”按钮。

时间格式：

只能是HTTP格式的日期时间，其他的都会被解析成当前时间“之前”，副本会过期，记住：HTTP的日期时间必须是格林威治时 间（GMT），而不是本地时间。举例：Expires: Fri, 30 Oct 1998 14:19:41

注意：

• 确认你的Web服务器时间设置正确。
• Web服务器的时间和缓存服务器的时间必须是同步的，如果不同步， 要么是应该缓存的内容提前过期了，要么是过期结果没及时更新。
• 如果设置的过期时间是一个固定的时间，如果返回内容的时候又没有连带更新下次过期的时间，那么之后所有访问请求都会被发送给源Web服务器，反而增加了负载和响应时间；

2. Cache-Control（缓存控制） HTTP头信息

有用的 Cache-Control响应头信息包括：

• max-age=n  单位是秒：从请求时间开始到过期时间之间的秒数，是相对时间间隔，而不是绝对过期时间；

• s-maxage=n  类似于max-age属性，除了他应用于共享（如：代理服务器）缓存；

• public  标记认证内容也可以被缓存，经过HTTP认证才能访问的内容，输出是自动不可以缓存的；

• no-cache  强制每次请求直接发送给源服务器，而不经过本地缓存版本的校验；

• no-store  强制缓存在任何情况下都不要保留任何副本

• must-revalidate  告诉缓存必须遵循所有你给予副本的新鲜度的，HTTP允许缓存在某些特定情况下返回过期数据；

• proxy-revalidate和must-revalidate类似，除了他只对缓存代理服务器起作用

举例:
Cache-Control: max-age=3600, must-revalidate

注意：

• 给静态资源(HTML文件，图片文件等）的Repsone加上Expires/Cache-Control Header是很有效的一招。Expires的值只能是一个固定日期，比如“Thu 27 Nov 2008 07:00:00 GMT”，不能是一个类似“从现在开始之后10年”这样一个随机浮动的值，如果要这样的效果，可以用Cache-Control这样的Header，如果 HTTP Resposne中有这样的Header:“Cache-Control: max-age = 100”，表示这个资源在cache中的最大寿命是100秒。一般说来这种静态文件永远不应该过期，如果真的要给这个Cache加上一个期限，那我希望是 ——一万年，“Cache-Control: max-age = 315360000000”

• 其实就应该给Expires设一个永远不会过期的时间，比如你现在有一个文件叫logo.gif，需要用一个新的logo的时候，你不要去 覆盖原来的文件，而把新的logo存成logo_v2.gif，让相关网页引用新的logo_v2.gif，这样可以让新老网页同时工作，实在犯不上为了 节省存储空间覆盖原有文件。

配置：

对Apache服务器，使用mod_expires，在httpd.conf或者.htaccess中加上<FilesMatch “\\.(ico|gif|jpg|html)$”>ExpiresDefault “access plus 10 years”</FileMatch>

3.Last-Modified/If-Modified-Since

所有现代的浏览器都支持最近修改 (last-modified) 的数据检查。如果你曾经访问过某页，一天后重新访问相同的页时发现它没有变化，并奇怪第二次访问时页面加载得如此之快——这就是原因所在。你的浏览器首次 访问时会在本地缓存页面内容，当你第二次访问，浏览器自动发送首次访问时从服务器获得的最近修改日期。服务器简单地返回 304: Not Modified (没有修改)，因此浏览器就会知道从本地缓存加载页面。

4. ETag/If-None-Match

ETag 是实现与最近修改数据检查同样的功能的另一种方法：没有变化时不重新下载数据。其工作方式是：服务器发送你所请求的数据的同时，发送某种数据的 hash (在 ETag 头信息中给出)。hash 的确定完全取决于服务器。当第二次请求相同的数据时，你需要在 If-None-Match: 头信息中包含 ETag hash，如果数据没有改变，服务器将返回 304 状态代码。与最近修改数据检查相同，服务器仅仅 发送 304 状态代码；第二次将不为你发送相同的数据。在第二次请求时，通过包含 ETag hash，你告诉服务器：如果 hash 仍旧匹配就没有必要重新发送相同的数据，因为你还有上一次访问过的数据。

这几个http头可以作为meta标签发送到客户端，但是需要注意的是Http头中的设置优先级更高一些，例如：
<meta http-equiv=”Expires” CONTENT=” Fri, 30 Oct 1998 14:19:41″>
<meta http-equiv=”Cache-Control” CONTENT=”no-cache”>

我们来访问http://www.baidu.com的首页，通过firebug，我们来查看logo图片http://www.baidu.com/img/baidu_logo.gif的headers：

响应头信息

Date
Tue, 10 Aug 2010 09:31:36 GMT

Server
Apache

Last-Modified
Tue, 29 Jul 2008 16:00:00 GMT

Etag
"5d1-4532bbb6ca000"

Accept-Ranges
bytes

Content-Length
1489

Cache-Control
max-age=315360000

Expires
Fri, 07 Aug 2020 09:31:36 GMT

Connection
Keep-Alive

Content-Type
image/gif



请求头信息
Host
www.baidu.com

User-Agent
Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3

Accept
image/png,image/*;q=0.8,*/*;q=0.5

Accept-Language
zh-cn,zh;q=0.5

Accept-Encoding
gzip,deflate

Accept-Charset
GB2312,utf-8;q=0.7,*;q=0.7

Keep-Alive
115

Connection
keep-alive

Referer
http://www.baidu.com/

Cookie
BAIDUID=60A41CF3CE102AC479459D7202BC7C0C:FG=1; USERID=de28364425ea7fdbeb32a85ecb7beb; BD_UTK_DVT=1

Pragma
no-cache

Cache-Control
no-cache

F5刷新，第二次查看headers：

响应头信息查看源代码

Date
Tue, 10 Aug 2010 09:37:02 GMT

Server
Apache

Connection
Keep-Alive

Etag
"5d1-4532bbb6ca000"

Expires
Fri, 07 Aug 2020 09:37:02 GMT

Cache-Control
max-age=315360000



 请求头信息查看源代码 
Host
www.baidu.com

User-Agent
Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3

Accept
image/png,image/*;q=0.8,*/*;q=0.5

Accept-Language
zh-cn,zh;q=0.5

Accept-Encoding
gzip,deflate

Accept-Charset
GB2312,utf-8;q=0.7,*;q=0.7

Keep-Alive
115

Connection
keep-alive

Referer
http://www.baidu.com/

Cookie
BAIDUID=60A41CF3CE102AC479459D7202BC7C0C:FG=1; USERID=de28364425ea7fdbeb32a85ecb7beb; BD_UTK_DVT=1

If-Modified-Since
Tue, 29 Jul 2008 16:00:00 GMT

If-None-Match
"5d1-4532bbb6ca000"

Cache-Control
max-age=0

我们可以看到这个图片的最后修改时间和Etag。于是浏览器把这两个状态信息连同网页内容在本地进行缓存，当浏览器再次访问该图片的时候，浏览器会发送如下两个状态标识告诉服务器，我本地缓存的网页最后修改时间和Etag，请问服务器的资源有没有在我上次访问之后有更新啊？于是服务器会核对一下， 如果该用户上次访问之后没有更新过新闻，直接告诉浏览器：“没什么新东西，你还是看自己缓存的网页吧”，于是服务器就发 送一个304 Not Modified的消息，其他什么都不用干了。

二、HTTP缓存有什么用？

1.像Google这种比较智能的网络爬虫可以有效识别资源的状态信息，如果使用这 种缓存机制，可以大大减少爬虫的爬取次数。

2.很多内容更新不频繁的网页，尽管用户不会频繁的刷新，但是从一个比较长的时间段来看使用HTTP Cache，仍然可以起到很大的缓存作用。

3.对于历史帖子使用HTTP缓存。

• 例如，一些历史贴子，很少有人往后面翻页去看历史数据，也就无法被memcache缓存住，那有了http缓存，用户通过收藏夹保存或者其他方式过来，就不必去取数据了。另外爬虫也不会频繁爬去了。

三、如何在应用程序里面使用HTTP缓存

前两种就不说了，直接设置过期时间。重点说说ETAG吧。

1. 适用于新闻列表页，文章列表页等。拿最新一条数据做ETAG，该数据的最后更新时间做Last-Modified时间。

2. 适用于单篇文章页。拿文章最后修改时间和评论数做hash值作为ETAGE，最后更新时间做Lsdt-Modified时间。如果该文章作修改或多一条评论数的话，就认为该页有更新。

等等，具体应用可根据需求来定，发挥大家的思想。
总结
Expires/Cache-Control Header是控制浏览器是否直接从浏览器缓存取数据还是重新发请求到服务器取数据。只是Cache-Control比Expires可以控制的多一些， 而且Cache-Control会重写Expires的规则。

Last-Modified/If-Modified-Since和ETag/If-None-Match是浏览器发送请求到服务器后判断文件是否已经修改过，如果没有修改过就只发送一个304回给浏览器，告诉浏览器直接从自己本地的缓存取数据；如果修改过那就整个数据重新发给浏览器。

dn：一条记录的位置
dc：一条记录所属区域
ou：一条记录所属组织
cn/uid：一条记录的名字/ID

实际上更多时候我只把它看成数据库。我把它和我非常熟悉的MYSQL数据库做比较，通常会得到更好的理解：

MYSQL用“表”储存数据，LDAP用“树”
MYSQL指定一条记录要3个条件：DB、TABLE、ROW。
LDAP却更自由，为什么呢？因为LDAP数据是“树”状的，而且这棵树是可以无限延伸的，假设你要树上的一个苹果（一条记录），你怎么告诉园丁它的位置呢？当然首先要说明是哪一棵树（dc，相当于MYSQL的DB），然后是从树根到那个苹果所经过的所有“分叉”（ou，呵呵MYSQL里面好象没有这 DD），最后就是这个苹果的名字（uid，记得我们设计MYSQL或其它数据库表时，通常为了方便管理而加上一个‘id’字段吗？）。好了！这时我们可以清晰的指明这个苹果的位置了，就是那棵“歪脖树”的东边那个分叉上的靠西边那个分叉的再靠北边的分叉上的半红半绿的……，晕了！你直接爬上去吧！我还是说说LDAP里要怎么定义一个字段的位置吧，树（dc=waibo,dc=com)，分叉（ou=bei,ou=xi,ou=dong），苹果（cn=honglv），好了！位置出来了：
dn:cn=honglv,ou=bei,ou=xi,ou=dong,dc=waibo,dc=com

一个有名的画家说过：“世上没有相同的2个鸡蛋”。当然也没有相同的2个苹果……，同样，在LDAP里也不可能存在2个相同的dn。

LDAP数据填充原理
一棵树的生长，要循序渐进，如果还没有长出某个分叉，就不可能在那个分叉里长出苹果（问：FT！苹果是长在分叉上的吗？答：为了便于理解，你就当它是吧），同样，LDAP数据库也要一步步的充实，举一个学校数据库的例子，我们将要把一个庞大的学生档案放到LDAP里，大致需要这么做：
---------------------------------------------
1、建立“树根”，这是通过修改“slapd.conf”来实现的，由于现在的目的是理解，所以具体步骤就不说了，反正就是在这一步建立了一个 “dc=ourschool,dc=org”这样一个“树根”。注意：我把它理解成“目录”，或者“容器”，甚至它本身也是文件（苹果）的特殊形式，熟悉 LINUX文件系统的朋友会更容易理解。
2、建立18个系，分别是“dn:ou=computer,dc=ourschool,dc=org”、“dn:ou=film,dc=ourschool,dc=org”……
3、当然是在每个系里面建立专业，比如“dn:ou=linux,ou=computer,dc=ourschool,dc=org”……
4、（开始长苹果吧！）加学生喽——“dn:cn=stan,ou=linux,ou=computer,dc=ourschool,dc=org”……
5、已经完成了吗？对了！学生的详细信息还没有呐！不过先这样吧，反正记录是可以编辑的。

LDAP记录的详细信息
dn:cn=stan,ou=linux,ou=computer,dc=ourschool,dc=org
objectClass：organizationalPerson
cn:stan
cn:小刀
sn:小刀
description:agoodboy
（以上是一条记录的信息，如果把他保存成LDIF文件，可以导入到LDAP数据库中）
上面不是说没有学生详细信息吗？怕你着急，就马上写出来了，只是还没有导入到LDAP里，那是以后的事。这里我先就你可能会产生的疑问做回答。
---------------------------------------------
Q1：“cn”不是在“dn”里定义了吗，怎么又在后面重新定义了？答：你要把“cn=stan,ou=linux,ou=computer,dc=ourschool,dc=org”看成是一个整体，它只是属性dn的值。
Q2：怎么后面有2个“cn”，我以哪个为准？答：区别于普通数据库，LDAP每个属性一般可以具有多个值，这样不好吗？你在学校数据库里找我的时候，只要记得我的一个cn就可以了，用“cn=stan”或“cn=小刀”都可以找到我！
Q3：就这些属性了吗？我都不知道你是男是女。答：先声明，偶是男地。LDAP对记录的属性做了严格的限制（这一点我不太喜欢），也就是说，你可以用哪些属性，哪些属性不能为空，哪些属性最多只能有一个值等，他们都给你规定好了。幸好你有选择的权利，比如这次我们是储存学生信息，那么我们就定义一个 “objectClass：organizationalPerson”，这样“organizationalPerson”这个类所规定的所有属性我们都可以用了，而且确实很适合我们。虽然这个类中没有“sex”这个属性，不过你完全可以用一个“空闲”的属性来顶替。