11.1 用户识别机制

• HTTP 最初是一个匿名、无状态的请求/响应协议，服务器无法判断用户，也无法记录来访用户的请求序列。
• 现代的 Web 站点希望能够提供个性化的接触。它们希望对连接另一端的用户有更多的了解，并且能在用户浏览页面时对其进行跟踪。比如亚马逊的实现方式有：
  
  • 个性化的问候
    专门为用户生成的欢迎词和页面内容，使购物体验更加个性化。
  • 有的放矢的推荐
    通过了解客户的兴趣，商店可以推荐一些它们认为客户会感兴趣的商品。商店还可以在临近客户生日或其他一些重要日子的时候提供生日特定的商品。
  • 管理信息的存档
    在线购物的用户不喜欢一次又一次地填写繁琐的地址和信用卡信息。有些站点会将这些管理细节存储在一个数据库中。只要他们识别出用户，就可以使用存档的管理信息，使得购物体验更加便捷。
  • 记录会话
    HTTP 事务是无状态的。每条请求/响应都是独立进行的。很多 Web 站点希望能在用户与站点交互的过程中(比如，使用在线购物车的时候)构建增量状态。要实现这一功能，Web 站点就需要有一种方式来区分来自不同用户的 HTTP 事务。
• 本章介绍的用户识别机制：
  
  • 承载用户身份信息的 HTTP 首部。
  • 客户端 IP 地址跟踪，通过用户的 IP 地址对其进行识别。
  • 用户登录，用认证方式来识别用户。
  • 胖 URL，一种在 URL 中嵌入识别信息的技术。
  • cookie，一种功能强大且高效的持久身份识别技术。

1. HTTP 首部

• 7 种最常见承载用户相关信息的HTTP首部

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

1. From 首部

• 包含了用户的 E-mail 地址。每个用户都有不同的 E-mail 地址，所以在理想情况下，可以将这个地址作为可行的源端来识别用户。
• 但由于担心那些不讲道德的服务器会搜集这些 E-mail 地址，用于垃圾邮件的散发，所以很少有浏览器会发送 From 首部。
• 实际上，From 首部是由自动化的机器人或蜘蛛发送的，这样在出现问题时，网管还有个地方可以发送愤怒的投诉邮件。

2. User-Agent 首部

• 可以将用户所用浏览器的相关信息告知服务器，包括程序的名称和版本，通常还包含操作系统的相关信息。
• 要实现定制内容与特定的浏览器及其属性间的良好互操作时，这个首部是非常有用的，但它并没有为识别特定的用户提供太多有意义的帮助。

3. Referer 首部

• 提供了用户来源页面的 URL。Referer 首部自身并不能完全标识用户，但它确实说明了用户之前访问过哪个页面。通过它可以更好地理解用户的浏览行为，以及用户的兴趣所在。

From、User-Agent 和 Referer 首部都不足以实现可靠的识别。后面四个首部用于更高级的识别技术，稍后讨论。

2. 客户端 IP 地址

• 早期的 Web 先锋曾尝试着将客户端 IP 地址作为一种标识形式使用。通常在 HTTP 首部并不提供客户端的 IP 地址，但 Web 服务器可以找到承载 HTTP 请求的 TCP 连接另一端的 IP 地址。
• 缺点：
  
  • 客户端 IP 地址描述的是所用的机器，而不是用户。如果多个用户共享同一台计算机，就无法对其进行区分了。
  • 很多因特网服务提供商都会在用户登录时为其动态分配 IP 地址。用户每次登录时，都会得到一个不同的地址，因此 Web 服务器不能假设 IP 地址可以在各登录会话之间标识用户。
  • 为了提高安全性，并对稀缺的地址资源进行管理，很多用户都是通过网络地址转换(Network Address Translation，NAT)防火墙来浏览网络内容的。这些 NAT 设备隐藏了防火墙后面那些实际客户端的 IP 地址，将实际的客户端 IP 地址转换成了一个共享的防火墙 IP 地址(和不同的端口号)。
  • HTTP 代理和网关通常会打开一些新的、到原始服务器的 TCP 连接。Web 服务器看到的将是代理服务器的 IP 地址，而不是客户端的。有些代理为了绕过这个问题会添加特殊的 Client-IP 或 X-Forwarded-For 扩展首部来保存原始的 IP 地址(下图)。但并不是所有的代理都支持这种行为。
    
• 有些 Web 站点仍然使用客户端 IP 地址在会话之间跟踪用户的行为，但这种站点并不多。无法用 IP 地址确定目标的地方太多了。
• 少数站点甚至将客户端 IP 地址作为一种安全特性使用，它们只向来自特定 IP 地址的用户提供文档。在内部网络中可能可以这么做，但在因特网上就不行了，主要是因为因特网上 IP 地址太容易被欺骗(伪造)了。路径上如果有拦截代理也会破坏此方案。

3. 用户登录

• 要求用户通过用户名和密码进行认证(登录)来显式地询问用户是谁。
• 为了使 Web 站点的登录更加简便，HTTP 中包含了一种内建机制，可以用 WWW- Authenticate 首部和 Authorization 首部向 Web 站点传送用户的相关信息。一旦登录，浏览器就可以不断地在每条发往这个站点的请求中发送这个登录信息了，这样，就总是有登录信息可用了。
• 如果服务器希望在为用户提供对站点的访问之前，先行登录，可以向浏览器回送一条 HTTP 响应代码 401 Login Required。然后，浏览器会显示一个登录对话框，并用 Authorization 首部在下一条对服务器的请求中提供这些信息。为了不让用户每发送一条请求都要登录一次，大多数浏览器都会记住某站点的登录信息，并将登录信息放在发送给该站点的每条请求中。
  

4. 胖 URL

• 胖 URL(fat URL)：改动后包含了用户状态信息的 URL 被称为胖 URL。
• 有些 Web 站点会为每个用户生成特定版本的 URL 来追踪用户的身份。通常，会对真正的 URL 进行扩展，在 URL 路径开始或结束的地方添加一些状态信息。用户浏览站点时，Web 服务器会动态生成一些超链，继续维护 URL 中的状态信息。
• 可以通过胖 URL 将 Web 服务器上若干个独立的 HTTP 事务捆绑成一个“会话”或“访问”。用户首次访问这个 Web 站点时，会生成一个唯一的 ID，用服务器可以识别的方式将这个 ID 添加到 URL 中去，然后服务器就会将客户端重新导向这个胖 URL。不论什么时候，只要服务器收到了对胖 URL 的请求，就可以去查找与那个用户 ID 相关的所有增量状态(购物车、简介等)，然后重写所有的输出超链，使其成为胖 URL，以维护用户的 ID。
• 缺点：
  
  • 丑陋的 URL：浏览器中显示的胖 URL 会给新用户带来困扰。
  • 无法共享 URL：胖 URL 中包含了与特定用户和会话有关的状态信息。如果将这个 URL 发送给其 他人，可能就在无意中将你积累的个人信息都共享出去了。
  • 破坏缓存：为每个 URL 生成用户特有的版本就意味着不再有可供公共访问的 URL 需要缓存了。
  • 额外的服务器负荷：服务器需要重写 HTML 页面使 URL 变胖。
  • 逃逸口：用户跳转到其他站点或者请求一个特定的 URL 时，就很容易在无意中“逃离” 胖 URL 会话。只有当用户严格地追随预先修改过的链接时，胖 URL 才能工作。如果用户逃离此链接，就会丢失他的进展(可能是一个已经装满了东西的购物车)信息，得重新开始。
  • 在会话间是非持久的：除非用户收藏了特定的胖 URL，否则用户退出登录时，所有的信息都会丢失。