本文为《HTTP 权威指南》阅读笔记，主要包括 HTTP 概述、URL 与资源、HTTP 报文、连接管理、缓存、HTTP-NG、客户端识别与 Cookie 机制 几大内容。

HTTP 概述

HTTP 使用的是可靠的数据传输协议，确保数据在传输过程中不会被损坏或产生混乱
媒体类型(MIME type): 一种文本标记，表示一种主要的对象类型和一个特定的子类型，中间由一条斜杠来分隔:
- text/html
- text/plain
- image/jpeg
- image/gif
- video/quicktime
- application/vnd.ms-powerpoint
  常见的 MIME 类型有数百个，实验性或用途有限的则更多
统一资源标识符(URI): 在世界范围内唯一标识并定位信息资源，有两种形式，分别称为 URL 和 URN
- 统一资源定位符(URL): 描述了一台特定服务器上某资源的特定位置，包含三个部分:
  a. 方案(scheme): 说明协议类型，如 http://
  b. 服务器地址: 如 www.baidu.com
  c. 资源: 如 /specials/saw.gif
- 统一资源名(URN): 作为特定内容的唯一名称使用的，与目前的资源所在地无关，可以将资源四处搬移，仍然处于试验阶段，命名如 rn:ietf:rfc:2141
Telnet 程序可以将键盘连接到某个目标 TCP 端口，并将此端口的输出回送到显示屏上，Telnet 常用于远程终端会话，但它几乎可以连接所有的 TCP 服务器，包括 HTTP 服务器，使用以下命令即可进入:
1
telnet 主机名端口号
HTTP 协议版本:
- HTTP/0.9 1991年原型版本，严重设计缺陷，只支持 GET，不支持许多首部
- HTTP/1.0 广泛使用的 HTTP 版本
- HTTP/1.0+ 为满足需求，非官方添加许多新特性，如持久化连接、虚拟主机支持、代理支持等
- HTTP/1.1 校正结构性缺陷，明确语义，引入重要的性能优化措施，删除不好的特性，是当前使用的 HTTP 版本
- HTTP-NG(又名 HTTP/2.0) 是 HTTP/1.1 后继结构的原型建议，重点关注性能大幅优化，以及更强大的服务逻辑远程执行框架
Web 结构组件
- 代理 位于客户端和服务器之间的 HTTP 中间实体
- 缓存 HTTP 的仓库，使常用页面的副本可以保存在离客户端更近的地方
- 网关 连接其他应用程序的特殊 Web 服务器，通常用于将 HTTP 流量转换成其他的协议
- 隧道 对 HTTP 通信报文进行盲转发的特殊代理，如 SSL
- Agent 代理 发起自动 HTTP 请求的半智能 Web 客户端，所有发布 Web 请求的应用程序都是 HTTP Agent 代理

URL 与资源

URL 也可以通过 HTTP 之外的其他协议来访问资源，如个人邮箱: mailto:w19961009@126.com，再如文件传输协议: ftp://xxx.xxx.com/pub/xxx.xls
URL 语法:
1
<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>
- scheme 大小写无关，即 HTTP:// 与 http:// 等价
- 每个路径段都可以有自己的 params
相对 URL: 相对 URL 是 URL 的一种便捷缩略记法，处理 URL 的应用程序将它转换成绝对 URL 才可以使用，由以下步骤完成:
- 基础 URL: 可以选择从资源中获取显式指定的基础 URL，如 HTML 中的标签，还可以将所属资源的 URL 作为基础 URL
- 解析相对引用: 划分组件，并继承基础组件(方案、主机、端口等)
转义表示法 用来表示不安全字符(变体字符、一些二进制数据)，包含一个百分号，后面跟着两个表示字符 ASCII 码的十六进制数，如 %20 表示一个空格

HTTP 报文

HTTP 报文是在 HTTP 应用程序之间发送的数据块，这些数据块以一些文本形式的元信息开头，这些信息描述了报文的内容及含义，后面跟着可选的数据部分
HTTP 报文的行终止序列有两个字符组成: 回车符和换行符(CRLF)，注意有些 HTTP 应用程序并不总是既发送回车符也发送换行符
报文的语法
- 请求报文:
  1
  2
  3
  4
  <method> <request-url> <version>
  <headers>
  
  <entity-body>
- 响应报文:
  1
  2
  3
  4
  <version> <status> <reason-phrase>
  <headers>
  
  <entity-body>
- 首部可以有零个或多个可选，每个首部都包含一个名字，后面跟着一个冒号(:)，然后是一个可选的空格，接着是一个值，最后是一个 CRLF，有些 HTTP 版本，如 HTTP/1.1，要求报文中必须包含特定的首部
- 一组 HTTP 首部总是应该以一个空行(单个 CRLF)结束，甚至即使没有首部和实体的主体部分也应如此
常用的 HTTP 方法
- GET
- HEAD 与 GET 类似，但服务器在响应中只返回首部，可用于了解资源情况（如判断类型、查看资源是否存在）
- POST
- PUT 向服务器写入文档，如有些发布系统允许用户创建 Web 页面
- TRACE 对可能经过代理服务器传送到服务器上去的报文进行追踪，客户端发出的请求在经过传递中可能会被更改，TRACE 环回诊断可以查看报文最终变化后的结果（在响应体中携带服务器收到的请求报文）
- OPTIONS 决定可以在服务器上执行哪些方法
- DELETE
- 只有 POST 和 PUT 方法包含主体部分
- 并不是所有服务器都实现了这些方法，且由于 HTTP 设计得易于扩展，所以其他服务器可能还会实现一些自己的请求方法
- TRACE 方法用于诊断并不一定可靠，因为中间经过的代理服务器可能只对 POST 等请求做修改，而对 TRACE 不作处理
首部: 首部和方法配合工作，共同决定客户端和服务器做什么事情，首部可分为五个主要的类型:
- 通用首部 请求报文和响应报文都可以使用的，如 Date 首部
- 请求首部 为服务器提供一些额外信息，如客户端希望接收什么类型的数据用 Accept 首部
- 响应首部 为客户端提供信息，如告知客户端服务器的信息用 Server 首部
- 实体首部 用于对实体主体部分的首部，如 Content-Type
- 扩展首部 非标准的首部，由应用程序开发者创建

连接管理

浏览器与服务器交互典型流程:
- 浏览器解析出主机名
- 浏览器查询这个主机的 IP 地址
- 浏览器获取端口号
- 浏览器发起 TCP 连接
- 浏览器发起请求报文
- 浏览器读取响应报文
- 浏览器关闭连接
每个 TCP 段都是由 IP 分组承载，从一个 IP 地址发送到另一个 IP 地址的，每个 IP 分则中都包括:
- 一个 IP 分组首部（通常为 20 字节）
- 一个 TCP 段首部（通常为 20 字节）
- 一个 TCP 数据块（0个或多个字节）
HTTP 事务的性能在很大程度上取决于底层 TCP 通道的性能，HTTP 事务的时延有以下几种主要原因:
- 客户端首先需要根据 URI 确定 Web 服务器的 IP 地址和端口号。如果最近没有对 URI 中的主机名进行访问，通过 DNS 解析系统将 URI 中的主机名转换成一个 IP 地址可能要花费数十秒的时间。幸运的是，大多数 HTTP 客户端都有一个小的 DNS 缓存，用来保存近期所访问站点的 IP 地址
- 接下来，是 TCP 连接的建立时延，通常最多只有一两秒，但如果有数百个 HTTP 事务的话，这个值会快速地叠加上去
- 连接建立起来后，会通过 TCP 管道发送 HTTP 请求，服务器对其处理，然后回送 HTTP 响应，需要花费一些时间
性能聚焦区域包括:
- TCP 连接建立握手 通常 HTTP 事务都不会交换太多数据，小的 HTTP 事务可能会在 TCP 建立上花费 50%，可以通过重用现存连接，来减少这种建立时延
- 延迟确认 很多 TCP 栈都实现了一种延迟确认算法，存放在缓冲区中，以寻找能够捎带它的输出数据分组一并发送，但 HTTP 具有双峰特征的请求-应答行为降低了捎带信息的可能，可以对该算法进行调整或禁止
- TCP 慢启动拥塞控制 由于慢启动特性，所以要尽量重用现存连接
- 数据聚集的 Nagle 算法 该算法试图在发送一个分组之前，将大量的 TCP 数据绑定在一起，以提高网络效率，一般会设置参数 TCP_NODELAY 来禁用
- 用于捎带确认的 TCP 延迟确认算法
- TIME_WAIT 时延和端口耗尽 可用客户端源端口有限，可能会产生端口耗尽问题
Connection 首部 可以承载 3 种不同类型的标签:
- HTTP 首部字段名，列出了只与此连接有关的首部，这些首部将会被删除，而不会被转发，可以防止无意中对本地首部的转发
- 任意标签值，用于描述此连接的非标准选项
- 值 close，说明操作完成之后需关闭这条持久连接
持久连接 有一些比 并行连接 更好的地方，持久连接降低了时延和连接建立的开销，将连接保持在已调谐状态，而且减少了打开连接的潜在数量，但是，管理持久连接要特别小心，不然就会累积出大量的空闲连接，耗费本地以及远程客户端和服务器上的资源。
持久连接 与 并行连接 配合使用可能是最高效的方式，现在，很多 Web 应用程序都会打开少量的并行连接，其中的每一个都是持久连接。持久连接有两种类型:
- 比较老的 HTTP/1.0+”keep-alive” 连接
- 现代的 HTTP/1.1+”persistent” 连接
Keep-Alive 参数:
- timeout 响应首部发送的，估计了服务器希望将连接保持在活跃状态的时间，并不是一个承诺值
- max 响应首部发送的，估计了服务器还希望为多少个事务保持此连接的活跃状态，并不是一个承诺值
- 未经处理的属性 可支持任意未经处理的属性，主要用于诊断和调试，语法为 name [=value]
如果一个代理收到了一个 Connection: Keep-Alive 首部，是不应该转发 Connection 首部，或所有名为 Keep-Alive 的首部的，另外还有几个不能作为 Connection 首部值列出，也不能被代理转发或作为缓存响应使用的首部，其中包括 Proxy-Authenticate、Proxy-Connection、Transfer-Encoding 和 Upgrade
HTTP/1.1 持久连接在默认情况下是激活的，除非特别指明，否则 HTTP/1.1 假定所有连接都是持久的，要在事务处理结束后将连接关闭，HTTP/1.1 应用必须向报文中显式添加一个 Connection: close 首部
管道化连接 HTTP/1.1 在持久连接上可选地使用请求管道，这是在 Keep-Alive 连接上的进一步性能优化，在响应到达时，可以将多条请求放入队列，按序发送，将得到与请求相同的顺序回送的 HTTP 响应

缓存

可以用已有的副本为某些到达缓存的请求提供服务，称为 缓存命中，其他一些到达缓存的请求可能会因为由于没有副本可用，而被转发给原始服务器，称为 缓存未命中
原始服务器的内容会发生变化，缓存要不时对其进行检测，看看它们保存的副本是否仍是服务器上最新的版本，称为 HTTP 再验证，即发送一个小的再验证请求（如 If-Modified-Since），如果没有发生变化，服务器会以一个小的 304 Not Modified 进行响应；否则向客户端发送一条普通的、带有完整内容的 HTTP 200 OK 响应

缓存可以在任意时刻，以任意频率对副本进行再验证，但由于缓存中通常会包含数百万的文档，而且网络带宽是很珍贵的，所以大部分缓存只有在客户端发起请求，并且副本旧得足以需要检测时，才会对副本进行再验证
缓存命中率 是由缓存提供服务的请求所占的比例，命中率在 0 到 1 之间，但通常是用百分数来描述的

命中率很难预测，但对现在中等规模的 Web 缓存来说，40% 的命中率是很合理的
由于文档并不全是同一尺寸的，所以文档命中率并不能说明一切，有些大型对象被访问的次数可能较少，但由于尺寸的原因，对整个数据流量的贡献却更大，因此 字节命中率 某些时候作为度量值显得更为恰当

文档命中率 说明阻止了多少通往外部网络的 Web 事务，事务有一个通常都很大的固定时间成分（比如，建立一条到服务器的 TCP 连接），提高文档命中率对降低整体延迟（时延）很有好处；字节命中率说明阻止了多少字节传向因特网，提高字节命中率对节省带宽很有利
缓存的拓扑结构
- 私有缓存 个人的缓存，包含单个用户最常用的页面，如浏览器磁盘缓存
- 公有缓存 包含某个用户团体的常用页面，是特殊的共享代理服务器，称为”缓存代理服务器”或”代理缓存”，可以降低网络流量
- 代理缓存的层次结构 实现层次化缓存，在较小缓存中未命中的请求会被导向较大的父缓存，基本思想是: 在靠近客户端的地方使用小型廉价缓存，而更高层次中，则逐步采用更大、功能更强的缓存来装载多用户共享的文档
- 网状缓存 网状缓存中的代理缓存之间会以更加负责的方式进行对话，做出动态的缓存通信决策，决定与那个父缓存进行对话，或者决定彻底绕开缓存，直接连接原始服务器
服务端对缓存的处理步骤: （对一条 HTTP GET 报文）
- 接收 缓存接收报文
- 解析 缓存解析首部字段
- 查询 缓存查看是否有本地副本可用，如果没有就获取一份副本，并保存在本地
- 新鲜度检测 缓存查看已缓存副本是否足够新鲜，如果不是，就询问服务器是否有任何更新
- 创建响应 缓存会用新的首部和已缓存的主体来构建一条响应报文，缓存会向其中插入新鲜度信息（Cache-Control、Age以及Expires首部），而且通常会包含一个Via首部来说明请求是由一个代理缓存提供的
- 发送 缓存通过网络将响应发回给客户端
- 日志 缓存可选地创建一个日志文件条目来描述这个事务
HTTP 有一些简单的机制可以在不要求服务器记住有哪些缓存拥有其文档副本的情况下，保持已缓存数据与服务器数据之间充分一致，HTTP 将这些简单的机制称为 文档过期 和 服务器再验证
通过特殊的 HTTP Cache-Control 首部和 Expires 首部，HTTP 让原始服务器向每个文档附加了一个”过期日期”，在缓存文档过期之前，缓存可以以任意频率使用这些副本，而无需与服务器联系——当然，除非客户端请求中包含有阻止提供已缓存或未验证资源的首部。但一旦已缓存文档过期，缓存就必须与服务器进行核对，询问文档是否被修改过，如果被修改过，就要获取一份新鲜（带有新的过期日期）的副本
服务器用 HTTP/1.0+ 的 Expires 首部或 HTTP/1.1 的 Cache-Control: max-age 响应首部来指定过期日期，同时还会带有响应主体。Expires 首部和 Cache-Control: max-age 首部所做的事情本质上是一样的，但由于 Cache-Control 首部使用的是相对时间而不是绝对日期，所以倾向于使用 Cache-Control 首部，因为绝对日期依赖于计算机时钟的正确设置

Cache-Control:max-age 定义了文档的最大使用期——从第一次生成文档到文档不再新鲜、无法使用为止，最大的合法生存时间（以秒为单位）
服务器再验证 仅仅是已缓存文档过期了并不意味着它和原始服务器上目前处于活跃状态的文档有实际的区别；这只是意味着到了要进行核对的时间了，这种情况被称为”服务器再验证”，说明缓存需要询问原始服务器文档是否发生了变化
- 如果变化，则获取新文档覆盖旧文档
- 如果没有发生变化，缓存只需要获取新的首部，包括一个新的过期日期，并对缓存中的首部进行更新就行了
HTTP 协议要求行为正确的缓存返回下列内容之一:
- “足够新鲜”的已缓存副本
- 与服务器进行过再验证，确认其仍然新鲜的已缓存副本
- 如果需要与之进行再验证的原始服务器出故障了，就返回一条错误报文
- 附有警告信息说明内容可能不正确的已缓存版本
用条件方法进行再验证 HTTP 的条件方法可以高效地实现再验证，HTTP 允许缓存向原始服务器发送一个”条件 GET”，请求服务器只有在文档与缓存中现有的副本不同时，才回送对象主体，通过这种方式，将新鲜度检测和对象获取结合成了单个条件 GET。向 GET 请求报文中添加一些特殊的条件首部，就可以发起条件 GET，只有条件为真时，Web 服务器才会返回对象
HTTP 定义了 5个条件请求首部，对缓存再验证来首最有用的 2个首部是 If-Modified-Since 和 If-None-Match，所有的条件首部都以前缀”If-“开头
- If-Modified-Since:<date> 发生变化，返回 200，未发生变化，返回 304
- If-None-Match:<tags> 用于防止日期不同，但文件内容一致的情况。HTTP 允许用户对被称为 实体标签 ETAG 的版本标识符进行比较，实体标签是附加到文档上的任意标签（引用字符串），它们可能包含了文档的序列号或版本名，或者是文档内容的校验和，及其他指纹信息
HTTP/1.1 支持 弱验证器，如果只对内容进行了少量修改，就允许服务器声明那是”足够好”的等价体
什么时候应该使用实体标签和最近修改时间？
如果服务器回送了一个实体标签，HTTP/1.1 客户端就必须使用实体标签验证器；如果服务器只回送了一个 Last-Modified 值，客户端就可以使用 If-Modified-Since 验证；如果实体标签和最后修改日期都提供了，客户端就应该使用这两种再验证方案，这样 HTTP/1.0 和 HTTP/1.1 缓存就都可以正确响应了。
服务器可以通过 HTTP 定义的几种方式来指定在文档过期之前可以将其缓存多长时间，按优先级递减的顺序，服务器可以指定:
- Cache-Control:no-store 禁止缓存对响应进行复制，直接向客户端转发一条 no-store 响应
- Cache-Control:no-cache 可以存储在本地缓存区，只是在与原始服务器进行新鲜度再验证之前，缓存不能将其提供给客户端使用
- Cache-Control:must-revalidate 可以配置缓存使其提供陈旧版本，该首部禁止这种配置，在实现没有跟原始服务器再验证的情况下，不能提供这个对象的陈旧版本，缓存仍然可以随意提供新鲜的副本
- Cache-Control:max-age 新鲜状态的秒数
- Expires 过期时间
- 不附加信息，让缓存确定自己的过期时间
如果响应中没有 Cache-Control:max-age 首部，也没有 Expires 首部，缓存可以计算出一个试探性最大使用期，如 LM-Factor 算法使用中很常用的 试探性过期 算法
客户端可以用 Cache-Control 请求首部来强化或放松对过期时间的限制:
- Cache-Control: max-stale = <s> 缓存可以随意提供过期的文件，如果指定参数 ~~，在这段时间内，文档就不能过期~~
- Cache-Control: min-fresh = <s> 至少在未来 ~~秒内文档要保持需不需新鲜~~
- Cache-Control: max-age = <s> 缓存无法返回缓存时间长于 ~~秒的文档~~
- Cache-Control: no-cache Pragma: no-cache 除非资源进行了再验证，否则这个客户端不会接受已缓存的资源
- Cache-Control: no-store 缓存应该尽快从存储器中删除文档的所有痕迹，因为其中可能会包含敏感信息
- Cache-Control: only-if-cached 只有当缓存中有副本存在时，客户端才会获取一份副本

HTTP-NG

HTTP-NG 协议化为三层:
- 报文传输层 WebMUX 协议，此层负责端点间报文的不透明传输，管道化、重用连接、并行复用、有效分段
- 远程调用层 二进制连接协议，定义请求、响应的功能，提供一种标准的方法来调用服务器上所有的操作，只关心允许客户端远程调用服务器操作的接口
- Web 应用层 提供大部分的内容管理逻辑，所有的 HTTP/1.1 请求方法以及首部参数都是在这里定义的，同时将其映射到一个可扩展的分布式框架中去
WebMUX 协议 高性能保温系统，可以在一个复用的 TCP 连接上并行地传输报文，可以对以不同速度产生和消耗的独立报文流进行高效的分组，将其复用到一条或少数几条 TCP 连接上去
二进制连接协议 通过一条有状态的连接承载了从客户端发往服务器的操作调用请求，以及从服务器发往客户端的操作结果应答，有状态的连接可以提供更高的效率。请求报文中包含操作、目标对象和可选的数据值，应答报文带回了操作的最终状态、所对应请求的序列号（允许以任意顺序传递并行的请求和响应），以及可选的返回值。除了请求和应答报文以外，这个协议还定义了几种内部控制报文，用来提高连接的效率和健壮性

承载用户身份信息的 HTTP 首部 主要有以下几种:
- From 用户的 E-mail 地址，一般不会发送
- User-Agent 用户的浏览器软件，包括程序的名称和版本，通常还包含操作系统的相关信息
- Referer 用户是从这个页面上依照链接跳转过来的
- Authorization 用户名和密码
- Client-IP 客户端的 IP 地址
- X-Forwarded-For 客户端的 IP 地址
- Cookie 服务器产生的 ID 标签
客户端的 IP 地址 用来识别用户存在着很多缺点，限制了将其作为用户识别技术的效能:
- IP 地址描述的是所用的机器，而不是用户，如果多个用户共享同一台计算机，就无法对其进行区分了
- 很多因特网服务提供商都会在用户登录时为其动态分配 IP 地址
- 为提高安全性，并对稀缺的地址资源进行管理，很多用户都是通过网络地址转换（NAT）防火墙来浏览网络内容的，这些 NAT 设备隐藏了防火墙后面那些实际客户端的 IP 地址，将实际的客户端 IP 地址转换成了一个共享的防火墙 IP 地址（和不同的端口号）
- HTTP 代理和网关通常会打开一些新的、到原始服务器的 TCP 连接。Web 服务器看到的将是代理服务器的 IP 地址，而不是客户端的。有些代理为了绕过这个问题会添加特殊的 Client-IP 或 X-Forwarded-For 扩展首部来保存原始的 IP 地址，但并不是所有的代理都支持这种行为
用户登录 可以通过 WWW-Authenticate 首部和 Authorization 首部向 Web 站点传送用户的相关信息。一旦登录，浏览器就可以不断地在每条发往这个站点的请求中发送这个登录信息了（Authorization），这样，就总是有登录信息可用了。（服务器会发送 401 Login Required 请求用户登录后访问）
胖 URL 有些 Web 站点会为每个用户生成特定版本的 URL 来追踪用户的身份，通常，会对真正的 URL 进行扩展，在 URL 路径开始或结束的地方添加一些状态信息。用户浏览站点时，Web 服务器会动态（在首次访问时，生成一个 ID，服务器重写 HTML 扩展带 ID 的 URL）生成一些超链，继续维护 URL 中的状态信息
Cookie 是当前识别用户，实现持久会话的最好方式；Cookie 的存在也影响了缓存，大多数缓存和浏览器都不允许对任何 Cookie 的内容进行缓存；Cookie 可以笼统地分为两类:
- 会话 Cookie 临时，记录用户访问站点时的设置和偏好，退出浏览器时就被删除
- 持久 Cookie 生存时间更长，存储在硬盘上，重启时仍然存在，通常维护某个用户会中期访问的站点的配置文件或登录名
Cookie 中包含了一个由 名字=值 （name=value）这样的信息构成的任意列表，并通过 Set-Cookie 或 Set-Cookie2 HTTP 响应（扩展）首部将其贴到用户身上去，浏览器会记住从服务器返回的 Set-Cookie 或 Set-Cookie2 首部中的 Cookie 内容，并将 Cookie 集存储在浏览器的 Cookie 数据库中
不同的站点使用不同的 Cookie
- Cookie 的域属性 Set-Cookie 响应首部可以添加 domain 属性来指定域
- Cookie 路径属性 可通过 path 属性来将 Cookie 与部分 Web 站点关联起来

cookies版本0（Netscape）

1 2	Set-Cookie: name=value [; expires=date] [; path=path] [; domain=domain] [; secure] Cookie: name1=value1 [; name2=value2] ...

键值对除非包括在双引号内，否则不包括分号、逗号、等号和空格
Domain 指定的域至少要有两个或三个句号，以防止出现 .com 等形式的域，如果没有指定域，默认为产生 Set-Cookie 响应的服务器的主机名
Path 如果未指定，默认为产生 Set-Cookie 响应的 URL 路径
Secure 只有一个单词，没有值，包含该属性则只有在 HTTP 使用 SSL 安全连接时才会发送 Cookie

在发送请求时，会将所有与域、路径和安全过滤器相匹配的未过期 Cookie 都发送给这个站点。所有 Cookie 都被组合到一个 Cookie 首部中

cookies版本1（RFC 2965）
该标准引入 Set-Cookie2 首部和 Cookie2 首部，但它也能与版本0 系统进行互操作，主要改动如下:
- 为每个 Cookie 关联上解释性文本，对其目的进行解释
- 允许在浏览器退出时，不考虑过期时间，将 Cookie 强制销毁
- 用相对秒数，而不是绝对日期表示 Cookie 的 Max-Age
- 通过 URL 端口号，而不仅仅是域和路径来控制 Cookie 的能力
- 为实现互操作性使用的版本号
- 在 Cookie 首部从名字中区分出附加关键字的 $ 前缀
发送 Cookie 首部的时候会连同过滤器（关键字附上 $ 前缀）一同与键值对传输
Cookie 版本协商
如果服务器理解新形式的 Cookie，就能够识别出 Cookie2 首部，并在响应首部发送 Set-Cookie2（而不是 Set-Cookie）。如果客户端从同一个响应中即获得了 Set-Cookie 首部，又获得了 Set-Cookie2 首部，就会忽略老的 Set-Cookie 首部
如果客户端既支持版本 0，又支持版本 1，但从服务器获得的是版本 0 的 Set-Cookie 首部，就应该带着版本 0 的 Cookie 首部发送 Cookie。但客户端还应该发送 Cookie2: $Version=”1” 来告知服务器它是可以升级的
Cookie 与缓存
- 如果无法缓存文档，要将其标示出来，如除了 Set-Cookie 首部之外文档是可缓存的，就使用 Cache-Control:no-cache=”Set-Cookie”
- 缓存 Set-Cookie 首部时要小心，主体内容通常会被缓存，但 Set-Cookie 首部不被缓存，但服务器预期不希望 Cookie 丢失
- 小心处理带有 Cookie 首部的请求，因为服务器可能没有将此内容标记为不可缓存
实际应用中，可以通过提供一个标准的审查方法在远程数据库中保存个人信息，并将匿名 Cookie 作为键值，在数据库中查找，以避免网络中传输的 Cookie 是敏感数据