Web服务器可能会同时与数千个不同的客户端进行对话。这些服务器通常要记录下它们在与谁交谈，而不会认为所有的请求都来自匿名的客户端。
11.1个性化接触
HTTP最初是一个匿名、无状态的请求/响应协议。服务器处理来自客户端的请求，然后向客户端回送一条响应。Web服务器几乎没有什么信息可以用来判定是哪个用户发送的请求，也无法记录来访用户的请求序列。
现代的Web站点希望能够提供个性化的接触。它们希望对连接另一端的用户有更多的了解，并且能在用户浏览页面时对其进行跟踪。Amazon.com这样流行的在线商店网站可以通过以下几种方式实现站点的个性化。
·个性化的问候
专门为用户生成的欢迎词和页面内容，使购物体验更加个性化。·有的放矢的推荐
通过了解客户的兴趣，商店可以推荐一些它们认为客户会感兴趣的商品。商店还可以在临近客户生日或其他一些重要日子的时候提供生日特定的商品。
·管理信息的存档
在线购物的用户不喜欢一次又一次地填写繁琐的地址和信用卡信息。有些站点会将这些管理细节存储在一个数据库中。只要他们识别出用户，就可以使用存档的管理信息，使得购物体验更加便捷。
·记录会话
HTTP事务是无状态的。每条请求/响应都是独立进行的。很多 Web站点希望能在用户与站点交互的过程中（比如，使用在线购物车的时候）构建增量状态。要实现这一功能，Web站点就需要有一种方式来区分来自不同用户的HTTP事务。
本章对HTTP识别用户的几种技巧进行了总结。HTTP并不是天生就具有丰富的识别特性的。早期的Web站点设计者们（他们都是些注重实际的人)都有自己的用户识别技术。每种技术都有其优势和劣势。本章我们将讨论下列用户识别机制。
·承载用户身份信息的HTTP首部。
·客户端IP地址跟踪,通过用户的IP地址对其进行识别。·用户登录，用认证方式来识别用户。
·胖URL，一种在URL中嵌入识别信息的技术。
-cookie，一种功能强大且高效的持久身份识别技术。
11.5胖URL
有些Web站点会为每个用户生成特定版本的URL来追踪用户的身份。通常，会对真正的URL进行扩展，在URL路径开始或结束的地方添加一些状态信息。用户浏览站点时，Web服务器会动态生成-一些超链，继续维护URL中的状态信息。
改动后包含了用户状态信息的URL 被称为胖URL (fat URL)。下面是Amazon.com电子商务网站使用的一些胖URL 实例。每个URL后面都附加了一个用户特有的标识码（在这个例子中就是002-1145265-8016838)，这个标识码有助于在用户浏览商店内容时对其进行跟踪。
..-
ca href="/exec/obidos/tg/browse/-/229220/ref=gr_gifts/002-1145265-
8016838">All Gifts</a>
<a href="/exec/obidos/wishlist/ref=gr_p11_/002-1145265-8016838">wishList</a>
...
<a href="http://sl.amazon.com/exec/varzea/tg/armed-forces/-//ref=gr_af_/002-1145265-8016838">Salute our Troops</a>
<a href="/exec/obidos/tg/browse/-/749188/ref=gr_p4_/002-1145265-8016838"
Free shipping</ a>ebr>
<a href=" /exec/obidos/tg/browse/-/468532/ref=gr_returns/002-1145265-8016838
Easy Returns</a>
...
可以在用户浏览站点时，用胖URL对其进行识别。但这种技术存在几个很严重的问题。·丑陋的URL
浏览器中显示的胖URL会给新用户带来困扰。
无法共享URL
胖URL中包含了与特定用户和会话有关的状态信息。如果将这个URL发送给其他人，可能就在无意中将你积累的个人信息都共享出去了。
·破坏缓存
为每个URL生成用户特有的版本就意味着不再有可供公共访问的URL需要缓存了。·额外的服务器负荷
服务器需要重写HTML页面使URL变胖。·逃逸口
用户跳转到其他站点或者请求一个特定的URL时，就很容易在无意中“逃离”胖URL会话。只有当用户严格地追随预先修改过的链接时，胖 URL才能工作。如果用户逃离此链接，就会丢失他的进展（可能是一个已经装满了东西的购物车)信息,得重新开始。
·在会话间是非持久的
除非用户收藏了特定的胖URL，否则用户退出登录时，所有的信息都会丢失。
11.6.1cookie的类型
可以笼统地将cookie分为两类:会话cookie和持久cookie。会话cookie是一种临时cookie，它记录了用户访问站点时的设置和偏好。用户退出浏览器时，会话cookie就被删除了。持久cookie的生存时间更长一些,它们存储在硬盘上，浏览器退出，计算机重启时它们仍然存在。通常会用持久cookie维护某个用户会周期性访问的站点的配置文件或登录名。
11.6.2cookie是如何工作的
cookie就像服务器给用户贴的“嗨，我叫”的贴纸一样。用户访问一个Web站点时，这个Web站点就可以读取那个服务器贴在用户身上的所有贴纸。
用户首次访问Web站点时，Web服务器对用户一无所知（参见图11-3a)。Web服务器希望这个用户会再次回来，所以想给这个用户“拍上”一个独有的cookie，这样以后它就可以识别出这个用户了。cookie中包含了一个由名字=值(name=value)这样的信息构成的任意列表，并通过set-Cookie或set-Cookie2 HTTP响应（扩展)首部将其贴到用户身上去。
cookie中可以包含任意信息，但它们通常都只包含一个服务器为了进行跟踪而产生的独特的识别码。比如，在图11-3b中，服务器会将一个表示id="34294"的cookie贴到用户上去。服务器可以用这个数字来查找服务器为其访问者积累的数据库信息(购物历史、地址信息等)。
但是，cookie并不仅限于ID号。很多Web服务器都会将信息直接保存在cookie中。比如:
cookie: name="Brian Totty" ; phone-"555-1212"
浏览器会记住从服务器返回的set-Cookie或set-Cookie2首部中的cookie内容，并将cookie集存储在浏览器的cookie数据库中(把它当作一个贴有不同国家贴纸的旅行箱)。将来用户返回同一站点时（参见图11-3c)，浏览器会挑中那个服务器贴到用户上的那些cookie，并在一个cookie请求首部中将其传回去。
11.6.3cookie罐:客户端的状态
cookie的基本思想就是让浏览器积累一组服务器特有的信息，每次访问服务器时都将这些信息提供给它。因为浏览器要负责存储cookie信息，所以此系统被称为客户端侧状态（client-side state)。这个cookie规范的正式名称为HTTP状态管理机制(HTTP state management mechanism)。
11.6.6 cookies版本0 (Netscape)
最初的cookie规范是由网景公司定义的。这些“版本0”的cookie定义了set-Cookie响应首部、cookie请求首部以及用于控制cookie的字段。版本0的cookie看起来如下所示:
set-Cookie: name=value [;expires=date] [; path=path][; domain=domain][ ; secure]
Cookie: name1=value1 [; name2=value2] ...
1.版本0的set-cookie首部
set-Cookie首部有一个强制性的cookie名和 cookie值。后面跟着可选的cookie属性，中间由分号分隔。表11-3描述了set-cookie字段。
11.6.7cookies版本1（RFC 2965)
RFC 2965(以前的RFC 2109）定义了一个cookie的扩展版本。这个版本1标准引入了set-Cookie2首部和 Cookie2首部，但它也能与版本0系统进行互操作。RFC 2965 cookie标准比原始的网景公司的标准略微复杂一些，还未得到完全的支持。RFC 2965 cookie的主要改动包括下列内容。
·为每个cookie关联上解释性文本，对其目的进行解释。
允许在浏览器退出时，不考虑过期时间，将cookie强制销毁。用相对秒数,而不是绝对日期来表示 cookie的 Max-Age.
通过URL端口号，而不仅仅是域和路径来控制cookie的能力。通过cookie首部回送域、端口和路径过滤器（如果有的话)。·为实现互操作性使用的版本号。
·在Cookie首部从名字中区分出附加关键字的$前缀。
11.6.10cookie、安全性和隐私
cookie是可以禁止的，而且可以通过日志分析或其他方式来实现大部分跟踪记录，所以cookie自身并不是很大的安全隐患。实际上，可以通过提供一个标准的审查方法在远程数据库中保存个人信息，并将匿名cookie作为键值，来降低客户端到服务器的敏感数据传送频率。
