HTTP提供匿名、无状态的请求/响应 服务，为了给用户个性化的服务，有必要识别用户，主要的方式有：
- HTTP首部承载用户身份信息
HTTP请求首部有From （用户的email地址）、user-agent（用户的浏览器软件）、Referer（用户是从这个页面跳转过去的）、Authorization（用户名和密码）等字段，利用这些字段可以识别用户。
以下是首部承载的信息：
跟踪客户端IP地址，通过IP地址识别用户。
IP识别有弊端，（1）它识别的是及其，不是用户 （2）网络服务提供商可能会提供动态的IP （3）如果使用了代理，那获取到的IP可能只是代理的IP.
（4）为了安全，用户可能通过网络地址转换（Network Address Translation， NAT） 防火墙来浏览网络内容，这些NAT设备隐藏了防火墙后面的那些实际客户端的IP。用户登录，用认证方式识别用户。
如果服务器希望在为用户提供对站点的访问前先登录，则可以返回 401 Login Required ,然后浏览器会弹出登录框。这样就能显式地询问用户是谁。
胖UTL，在URL中嵌入识别信息的技术
有些web站点会为每个用户生成特定版本的URL来追踪身份，用户浏览站点时，web服务器会动态生成一些超链，继续维护URL中的信息。但是，这种方案有几点问题：
- 无法共享URL，包含了特定用户的信息，如果分享出去，无意中将积累的个人信息共享出去了
- 需要对每个用户动态生成胖URL，额外的服务器负荷
- 破坏缓存。为每个URL生成用户特有的版本，意味着不再有供公共访问的URL缓存了。
- cookie
是目前识别用户，实现持久会话的最好方式。包括 会话cookie 和 持久cookie ，他们之间的唯一区别就是他们的过期时间。浏览器会记住从服务器返回的set-cookies或者set-cookie2首部中的cookie内容，并将cookie存储在cookie数据库，将来用户访问同一站点时，浏览器会按照某些规则将cookie放在
cookie请求首部中将其传回去。
以下是为用户设置cookie的情形：
cookie的域属性：
产生cookie的服务器可以向set-cookie响应首部添加一个Domain属性来控制哪些站点可以看到那个cookie，比如，下面的HTTP响应首部告知浏览器将 cookie user=”haha” 发送给域 “.baidu.com”中的所有站点：
set-cookie: user=”haha”;domain=”baidu.com”
如果访问的是www.baidu.com 、news.baidu.com 或其他任何以 .baidu.com 结尾的站点，下列的cookie都会被发布出去；
Cookie :user=”haha”
cookie 规范甚至允许用户将cookie域部分web站点关联起来，可以通过path属性来实现：
例如，某个web服务器可能是由两个组织共享的，每个组织都有独立的cookie，站点 www.baidu.com 可能会将部分web站点用于外卖，如 www.baidu.com/waimai/ ，可以用一个独立的cookie来记录用户喜欢的外卖口味，如：
Set-cookie: taste=hot; domain=”baidu.com”; path=/waimai/
如果用户访问 http://www.baidu.com/waimai/bj/index.html 时就会获得两个cookie：
Cookie: user=”haha”
Cookie: taste=”hot”
因此，可以理解为：cookie就是由服务器贴到客户端上，由客户端维护的状态片段，只会回送给那些合适的站点。
我们有Set-Cookie 和 Set-Cookie2 两种，后者属于更新的版本。Cookie2首部告知服务器，用户Agent代理理解新形势的cookie，病提供了所支持的cookie标准版本，：
Cookie2： $Version=”1”
如果服务器理解新形式的cookie，就能识别出Cookie2首部，并在响应首部发送Set-Cookie2（而不是Set-Cookie），如果客户端从同一个响应中既获得了Set-Cookie 首部又获得了 Set-cookie2首部，就会忽略老的 Set-cookie首部。
