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

爱被打了一巴掌 2022-09-23 03:57 173阅读 0赞

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

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

# 如何进行客户端识别 #

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

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

## HTTP首部 ##

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

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

\+ **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/`下的站点才能访问cookie`pref=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时，不可避免会有一些安全性问题。