什么是客户端识别与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时,不可避免会有一些安全性问题。