《HTTP权威指南》——客户端识别与cookie机制

什么是客户端识别与cookie机制

• 什么是客户端识别：
  HTTP服务器可能会同时与大量的客户端进行对话，这时就需要判断各个对话对应的客户端。这个判断识别对话客户端的过程，就是客户端识别了。
• 什么是cookie：
  功能强大且高效的持久身份信息识别技术
• 识别了客户端可用做什么：
  服务器识别了各个事务、会话对应的客户后，能够根据客户的分类保存于客户相关的信息、提供个性化的、有针对性的内容。

如何进行客户端识别

HTTP提供一些用以进行客户端识别的机制

• 承载客户身份信息的HTTP首部
• 客户端IP地址跟踪，通过用户的IP地址对其进行识别
• 用户登录，用认证方式来识别用户
• 胖URL， 在URL中嵌入识别信息
• cookie， 功能强大且高效的持久身份信息识别技术

HTTP首部

一些HTTP首部可以用来承载客户身份信息：

首部名称	首部类型	描述
From	请求	用户的E-mail地址
User-Agent	请求	用户的浏览器软件
Referer	请求	用户是从这个页面上依照链接挑战过来的
Authorization	请求	用户名和密码
Client-IP	拓展（请求）	客户端的IP地址
X-Forwarded-For	拓展（请求）	客户端的IP地址
Cookie	拓展（请求）	服务器产生的ID标签

+ From首部“
包含用户的Email，但为避免邮件地址被搜集导致用户收到过多垃圾邮件，一般用户不使用From首部。From首部通常用户Web机器人，一遍出现问题时服务器管理员能够发送投诉邮件。

• User-Agent：
  将用户所用浏览器的相关信息告知服务器，对客户端识别帮助有限。
• Referer：
  提供了用户来源页面的URL。来源页面的URL可以告知服务器用户（之前）对哪些内容感兴趣。
• Client-IP和X-Forwarded-For：
  　　在一定条件下，客户端的IP有助于进行客户端识别，我们可以通过getpername（TCP连接另一端的IP地址）来获取客户端的IP地址。
  　　有些HTTP会话经过了代理，这是getpeername等手段获取到的是代理的IP，不是客户端的IP，因此HTTP设计者提出用Client-IP和X-Forwarded首部来记录客户端的IP。
  　　客户端IP识别客户端有一定局限性， 因为它识别的是机器。同一机器上可能可能有多个用户在同时使用。
• Authorization：
  　　HTTP提出了用户登录机制，即HTTP服务器可以要求用户通过用户名和密码进行认证（登录）来显示询问用户是谁。用户先用WWW-Authenticate首部或者Authorization首部想Web站点提供用户的登录信息，一旦登录成功，浏览器在之后想改站点发出的请求中都会发送这个登录信息。
• Cookie：
  关于Cookie我们会后面着重介绍

胖URL

　　有些Web站点会向每一个用户生成特定版本的URL（通常是向真正的URL中添加一些客户端识别信息进行拓展）， 我们称之为胖URL。这看起来是一个不错的客户端识别机制，但是在实际使用中却至少有一下缺点：

• 无法共享URL： 由于胖URL包含的特定用户的状态信息，因而无法共享给他人。
• 破坏缓存： 胖URL是针对特定用户的，因而无法使用公共访问的缓存了。
• 额外的服务器负荷： 服务器需要重写HTML页面是得URL变胖
• 逃逸口： 用户在访问一些特定URL时，可能就无意中离开了胖URL会话。
• 在会话间是非持久的： 除非用户首次胖URL，否则用户退出时，所有信息也会消失。

Cookie

cookie是当前识别用户，实现持久会话的最好方式。

会话cookie和持久cookie

cookie有两种类型：

• 会话cookie： 临时cookie，记录用户访问站点时的设置和偏好，用户退出浏览器时，会话cookie被删除。设置Discard参数
• 持久cookie： 存储在硬盘上，计算机重启时仍然存在。 维护某个用户会周期性访问的站点的配置文件或登录名。设置了Expires或Max-Age参数。

cookie的工作机制

cookie是一些名字-值的信息列表，列表中会包含一些客户相关的信息（如识别码）。
在HTTP会话开始时，Web服务器对客户单一无所知，就为客户端生成cookie（如识别码）， 然后在HTTP响应中通过Set-Cookie或Set-Cookie2响应首部将Cookie贴到用户上去。
浏览器记住服务器返回的cookie内容，并存储到cookie数据库中。当将来用户重新访问之前的站点时，就可以找回保存的cookie内容，添加到请求首部中传会服务器。

不同的浏览器存储cookie的位置不同。
在访问站点时，浏览器不会把全部cookie发送给所有的站点，实际上浏览器一般只向每个站点发送2~3个cookie。毕竟存在网络开销与信息安全等问题。
一般而言，浏览器只会想服务器发送该服务器产生的cookie。

• cookie的域属性：
  　　产生cookie的服务器可以向Set-Cookie响应首部添加一个Domain属性来控制哪些站点可以看到该cookie。如下列首部：

Set-cookie: user="windeal"; domain="windeal.com"

　　该首部表示在域windeal.com下的站点才能看到Cookie首部Cookie: user="windeal"

• cookie的path属性：
  Cookie允许用户将cookie与部分Web站点（一个域下的某个路径）。

Set-cookie: pref=compact; domain="windeal.com"; path=/auto/

　　此处，只有windeal.com/auto/下的站点才能访问cookiepref=compact。

cookie的格式

目前cookie有两个版本

版本0的cookie

版本0的cookie有如下格式：

Set-Cookie: name=value  [; expires=date] [; path=path] [; domain=domain] [; secure]
Cookie: name1=value [; name2=value2]...

版本1的cookie

RFC 2965 定义了版本1的cookie， 版本1标准引入了Set-Cookie2首部和Cookie2首部， 同时兼容版本0的系统。
相对于版本0的cookie， 版本1的cookie功能强大、设计更加复杂。有些功能还没有得到完全的支持。
此处不详细介绍版本1的格式，等到需要用时在查阅不迟。

Cookie相关的 其他事项

• cookie与会话跟踪：
  利用cookie，可以在用户与某个Web站点进行多项事务处理时对用户进行跟踪。
• cookie与缓存：
  对于缓存来说，许多携带cookie数据的事务中缓存应该是不被允许的，以免将某些用户使用过的cookie（或者携带的私有文档）提供给其他用户。
• cookie、安全性和隐私：
  由于cookie传输了一些用户信息相关的 敏感数据， 在使用cookie时，不可避免会有一些安全性问题。