HTTP权威指南笔记

HTTP概述

HTTP-因特网的多媒体信使

Web客户端和服务器

媒体类型

URI

• URL
  统一资源定位符（URL,Uniform Resource Locator）是资源标识符最常见的形式。

  

大部分URL都遵循一种标准格式，这种格式包含三个部分。

1.URL的第一部分称为方案（scheme），说明访问资源所使用的协议类型。这部分通常是HTTP或者HTTPS（http://)。

2.第二部分给出了服务器的因特网地址（www.joes-hardware.com）。

3.其余部分指定了Web服务器上的某个资源（比如，/specials/saw-blade.gif）。

现在几乎所有的URI都是URL。

• URN
  URI的第二种形式就是URN（统一资源名）。URN是作为特定内容的唯一名称使用的，与目前的资源所在地无关。使用这些与>位置无关的URN，就可以将资源四处搬动。通过URN，还可以用同一个名字通过多种网络访问协议来访问资源。

  URN仍然处于试验阶段，还未大范围使用。除非特殊说明，否则这里的都是用URL来指定URI。

事务

• 方法
  HTTP支持几种几种不同的请求命令，这些命令被称为HTTP方法（HTTP method）。每条HTTP请求报文都包含一个方法。这个方法会告诉服务器要执行什么动作（获取一个Web页面、运行一个网关程序、删除一个文件等）。

  常见的HTTP方法：

HTTP方法	描述
GET	从服务器向客户端发送命名资源
PUT	将来自客户端的数据存储到一个命名的资源服务器中
DELETE	从服务器中删除命名资源
POST	将客户端数据发送到一个服务器网关应用程序
HEAD	仅发送命名资源响应中的HTTP首部

• 状态码
  每条HTTP响应报文返回时都会携带一个状态码。状态码是一个三位数字的代码，告知客户端请求是否成功，或者是否需要采取其他动作。

  常见的HTTP状态码：

HTTP状态码	描述
200	OK, 文档正确返回
302	Redirect（重定向）。到其他地方去获取资源
404	Not Found（没找到），无法找到这个资源

• Web页面可以包含多个对象
  应用程序完成一项任务时通常会发布多个HTTP事务。比如，Web浏览器会发布一系列的HTTP事务来获取并显示一个包含丰富图片的Web页面。浏览器会执行一个事务来获取描述页面布局的HTML”框架“，然后发布另外的HTTP事务来获取每个嵌入式图片、图像面板、Java小程序等。这些嵌入式资源甚至可能位于不同的服务器。因此，一个Web页面通常并不是单个资源，而是一组资源的集合。

报文

• 起始行
  报文的第一行就是起始行，在请求报文中用来说明要做些什么，在响应报文中说明出现了什么情况。
• 首部字段
  起始行后面有0个或者多个首部字段。每个字段都包含一个名字和一个值，为了便于解析，两者之间用冒号（：）分隔。首部以一个空行结束。添加一个首部字段和添加新行一样简单。
• 主体
  空行之后就是可选的报文主体了，其中包含了所有类型的数据。请求主体中包括了要发给Web服务器的数据，响应主体中装载了要返回给客户端的数据。起始行和首部都是文本形式且都是结构化的，而主体则不同，主体可以包含任意的二进制数据（图片、视频、音频、软件程序）。当然，主体还可以包含文本。

  连接

• TCP/IP
  HTTP是个应用层协议。HTTP无需关心网络通信的具体细节；它把联网的细节都给了通用、可靠的因特网传输协议TCP/IP。
  TCP提供了：
  • 无差错的数据传输。
  • 按序传输（数据总是按照发送的顺序到达）；
  • 分段的数据流（可以在任意时刻以任意大小将数据发送出去）。
  因特网自身是基于TCP/IP的，它是全世界计算机网络常用的层次化分组交换网络协议集。TCP/IP 隐藏了各种网络和硬件的特点及弱点，使各种类型的计算机和网络都能够进行可靠地通信。

  只要建立了TCP连接，客户端和服务器之间的报文交换就不会丢失、被破坏、也不会出现接收时乱序。HTTP协议位于TCP的上层。HTTP使用TCP来传输其报文数据。

  
• 连接、IP地址及端口号
  在HTTP客户端向服务器发送报文之前，需要用网际协议（Internet Prococol，IP）地址和端口号在客户端和服务器之间建立一条TCP/IP连接。

  建立一条TCP连接的过程与给公司办公室的某个人打电话的过程类似。首先，要拨打公司的电话号码。这样就能进入正确的机构了。其次，拨打要联系的那个人的分机号。

  最初怎么获取服务器的IP地址呢？当然是通过URL。

  先看几个URL:

  http://207.200.83.29:80/index.html

  http://www.netscape.com:80/index.html

  http://www.netscape.com/index.html

  第一个 URL 使用了机器的 IP 地址，207.200.83.29 以及端口.第二个 URL 没有使用数字形式的 IP 地址，它使用的是文本形式的域名，或者称为主机名（www.netscape.com） 。主机名就是 IP 地址比较人性化的别称。可以通过一

  种称为域名服务（Domain Name Service，DNS）的机制方便地将主机名转换为 IP地址，这样所有问题就都解决了。

  最后一个 URL 没有端口号。HTTP 的 URL 中没有端口号时，可以假设默认端口号是 80。有了 IP 地址和端口号，客户端就可以很方便地通过 TCP/IP 进行通信了。

  

• 使用Telnet实例
  Telnet程序可以将键盘连接到某个目标TCP端口，并将此TCP端口的输出回送到显示屏上。Telnet常用于远程终端会话，但它几乎可以连接所有的TCP服务器，包括HTTP服务器。

  可以通过Telnet程序直接与Web服务器进行对话。通过Telnet可以打开一条到某台机器上某个端口的TCP连接，然后直接向端口输入一些字符。Web服务器会将Telnet程序作为一个Web客户端来处理，然后回送给TCP连接的数据会显示在屏幕上。

  实际例子：Telnet获取URL http://www.joes-hardware.com:80/tools.html 所指向的文档

  

Telnet 会查找主机名并打开一条连接，连接到在 www.joes-hardware.com 的端口 80上监听的 Web 服务器。这条命令之后的三行内容是 Telnet 的输出，告诉我们它已经建立了连接。

然后我们输入最基本的请求命令 GET/tools.html HTTP/1.1 ，发送一个提供了源端主机名的 Host 首部，后面跟上一个空行，请求从服务器 www.joes-hardware.com 上获取资源 tools.html。随后，服务器会以一个响应行、几个响应首部、一个空行和最后面的 HTML 文档主体来应答。

要明确的是，Telnet 可以很好地模拟 HTTP 客户端，但不能作为服务器使用。而且对 Telnet 做脚本自动化是很繁琐乏味的。如果想要更灵活的工具，可以去看看 nc（netcat） 。通过 nc 可以很方便地操纵基于 UDP 和 TCP 的流量（包括 HTTP） ，还可以为其编写脚本。更多细节参见 http://www.bgw.org/tutorials/utilities/nc.php

协议版本

• HTTP/0.9
  HTTP 的 1991 原型版本称为 HTTP/0.9。这个协议有很多严重的设计缺陷，只应该用于与老客户端的交互。HTTP/0.9 只支持 GET 方法，不支持多媒体内容的MIME 类型、各种 HTTP 首部，或者版本号。HTTP/0.9 定义的初衷是为了获取简单的 HTML 对象，它很快就被 HTTP/1.0 取代了。
• HTTP/1.0
  1.0 是第一个得到广泛使用的 HTTP 版本。HTTP/1.0 添加了版本号、各种 HTTP首部、一些额外的方法，以及对多媒体对象的处理。HTTP/1.0 使得包含生动图片的 Web 页面和交互式表格成为可能，而这些页面和表格促使万维网为人们广泛地接受。这个规范从未得到良好地说明。在这个 HTTP 协议的商业演进和学术研究都在快速进行的时代，它集合了一系列的最佳实践。
• HTTP/1.0+
  在 20 世纪 90 年代中叶，很多流行的 Web 客户端和服务器都在飞快地向 HTTP中添加各种特性，以满足快速扩张且在商业上十分成功的万维网的需要。其中很多特性，包括持久的 keep-alive 连接、虚拟主机支持，以及代理连接支持都被加入到 HTTP 之中，并成为非官方的事实标准。这种非正式的 HTTP 扩展版本通常称为 HTTP/1.0+。
• HTTP/1.1
  HTTP/1.1 重点关注的是校正 HTTP 设计中的结构性缺陷，明确语义，引入重要的性能优化措施，并删除一些不好的特性。HTTP/1.1 还包含了对 20 世纪 90 年代末正在发展中的更复杂的 Web 应用程序和部署方式的支持。HTTP/1.1 是当前使用的 HTTP 版本。
• HTTP-NG（又名 HTTP/2.0）
  HTTP-NG 是 HTTP/1.1 后继结构的原型建议，它重点关注的是性能的大幅优化，以及更强大的服务逻辑远程执行框架。HTTP-NG 的研究工作终止于 1998 年，编写本书时，还没有任何要用此建议取代 HTTP/1.1 的推广计划。

Web结构组件

• 代理
  代理位于客户端和服务器之间的HTTP中间实体。接收所有客户端的 HTTP 请求，并将这些请求转发给服务器（可能会对请求进行修改之后转发） 。对用户来说，这些应用程序就是一个代理，代表用户访问服务器。

  

• 缓存
  Web 缓存（Web cache）或代理缓存（proxy cache）是一种特殊的 HTTP 代理服务器，可以将经过代理传送的常用文档复制保存起来。下一个请求同一文档的客户端就可以享受缓存的私有副本所提供的服务了.

  

• 网关
  网关（gateway）是一种特殊的服务器，作为其他服务器的中间实体使用。通常用于将 HTTP 流量转换成其他的协议。网关接受请求时就好像自己是资源的源端服务器一样。客户端可能并不知道自己正在与一个网关进行通信。

  例如，一个 HTTP/FTP 网关会通过 HTTP 请求接收对 FTP URI 的请求，但通过 FTP协议来获取文档 。得到的文档会被封装成一条 HTTP 报文，发送给客户端。第 8 章将探讨网关。

  
• 隧道
  隧道（tunnel）是建立起来之后，就会在两条连接之间对原始数据进行盲转发的HTTP 应用程序。HTTP 隧道通常用来在一条或多条 HTTP 连接上转发非 HTTP 数据，转发时不会窥探数据。

  HTTP 隧道的一种常见用途是通过 HTTP 连接承载加密的安全套接字层（SSL，Secure Sockets Layer）流量，这样 SSL 流量就可以穿过只允许 Web 流量通过的防火墙了。如图所示，HTTP/SSL 隧道收到一条 HTTP 请求，要求建立一条到目的地址和端口的输出连接，然后在 HTTP 信道上通过隧道传输加密的 SSL 流量，这样就可以将其盲转发到目的服务器上去了。

  
• Agent代理
  用户 Agent 代理（或者简称为 Agent 代理）是代表用户发起 HTTP 请求的客户端程序。所有发布 Web 请求的应用程序都是 HTTP Agent 代理。到目前为止，我们只提到过一种 HTTP Agent 代理：Web 浏览器，但用户 Agent 代理还有很多其他类型。用fiddler抓包找头部信息会发现类似User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36

  比如，有些自己会在 Web 上闲逛的自动用户 Agent 代理，可以在无人监视的情况下发布 HTTP 事务并获取内容。这些自动代理的名字通常都很生动，比如“网络蜘蛛”（spiders）或者“Web 机器人” （Web robots） 。网络蜘蛛会在 Web 上闲逛，搜集信息以构建有效的 Web 内容档案，比如一个搜索引擎的数据库或者为比较购物机器人生成的产品目录。

  

URL和资源

因特网资源

URL语法

• scheme
  访问服务器以获取资源时要使用的协议 默认值 无
• user
  一些方案访问资源时需要的用户名 默认值 匿名
• password
  用户名后面可能要包含密码,中间由冒号分隔 默认值
• host
  资源宿主服务器的主机名或点分IP地址 默认值 无
• port
  资源宿主服务器正在监听的端口号,很多方案都有默认端口号(HTTP默认端口号为80) 默认值 每个方案特有
• path
  服务器上资源的本地名,由一个"/"将其与前面的URL组件分隔开来.路径组件的语法与服务器和方案有关 默认值 无
• params
  一些方案会用这个组件指定输入参数. 参数为名/值对. URL中可以包含多个参数字段,它们相互以及与路径的其余部分之间用分号(;)分隔 默认值 无
• query
  一些方案会用这个组件传递参数以激活应用程序.查询组件的内容没有通用格式.用符号"?"将其与URL的其余部分分隔开来 默认值 无
• frag
  一小片或一部分资源的名字.引用对象时,不会将frag字段传送给服务器。这个字段是在客户端内部使用的.通过字符"#"将其与URL其余部分分隔开来 默认值 无

HTTP报文

报文流

• 报文流入源端服务器
  HTTP使用术语流入（inbound）和流出（outbound）来描述事务处理（transaction）的反向。
  流入：客户端->服务器
  流出：服务器->客户端
  
• 报文向下游流动
  不管是请求报文还是响应报文，所有报文都会向下游（downstream）流动。所有报文的发送者都在接收者的上游（upstream）。对请求报文来说，代理1位于代理3上游，但对于响应报文来说，它就位于代理3的下游。
  

报文的组成部分

• 报文的语法

请求报文

响应报文

• method
  客户端希望服务器对资源执行的动作。是一个单独的词，比如GET、HEAD或POST。
• request-URL
  命名了所请求资源或者URL路径组件的完整URL。如果直接与服务器进行对话，只要URL的路径组件是资源的绝对路径，通常不会有什么问题。
• version
  报文所使用的HTTP版本
• status-code
  这三位数字描述了请求过程中所发生的情况。
• 原因短语 reason-phrase
  数字状态码的可读版本，包含行终止序列之前的所有文本。
• header
  可以有0个或多个首部。每个首部都包含一个名字，然后跟着一个冒号（：），然后是一个可选的空格，接着是一个值，最后是一个CRLF(回车换行)。首部是由一个空行（CRLF）结束的。表示首部列表的结束和实体主体的开始。
  注意，一组HTTP首部总是应该以一个空行（CRLF）结束，甚至即使没有首部和实体的主体部分也应该如此。

  起始行

• 请求行
  包含一个方法和一个请求URL，这个方法描述服务器该执行的操作，请求URL描述了要对哪个资源执行这个方法。所有这些字段都是由空格符分隔。
• 响应行
  响应报文承载了状态信息和操作产生的所有结果数据，将其返回给客户端。响应报文的起始行称为响应行。
  常用HTTP方法

方法	描述	是否包含主体
GET	从服务器获得一份文档	否
HEAD	只从服务器获得响应报文的首部	否
POST	向服务器发送需要处理的数据	是
PUT	将请求的主体部分存储在服务器上	是
TRACE	对可能经过代理服务器传送到服务器上去的报文进行追踪	否
OPTIONS	决定在服务器上可以执行哪些方法	否
DELETE	从服务器上删除一份文档	否

• 状态码
  状态码是在每条响应报文的起始行总返回的。会返回一个数字状态和一个可读的状态。数字码便于程序进行差错处理，而原因短语则更便于人们理解。
  状态码分类

整体范围	已定义范围	分类
100~199	100~101	信息提示
200~299	200~206	成功
300~399	300~305	重定向
400~499	400~415	客户端错误
500~599	500~505	服务器错误

状态码	原因短语	含义
200	ok	成功，请求的所有数据都在响应主体中
401	unauthorized（未授权）	需要输入用户名和密码
404	not found	服务器无法找到所请求的URL对应的资源

• 首部分类
  1.通用首部：既可以出现在请求报文中，也可以出现在响应报文中。
  2.请求首部：提供更多有关请求的信息
  3.响应首部：提供更多有关响应的信息
  4.实体首部：描述主体的长度和内容，或者资源本身
  5.扩展首部：规范中没有定义的新首部。
  具体的每个首部用法，可以参考HTTP权威指南
• options
  options方法请求Web服务器告知其支持的各种功能。可以询问服务器支持哪些方法，或者对某些特殊资源的支持方法。这为客户端应用程序提供了一种手段，使其不用实际访问那些资源就能判定访问各种资源的最优方式。
  
• 重定向状态码
  重定向状态码要么告知客户端使用替代位置来访问他们所感兴趣的资源，要么就提供了一个替代的响应而不是资源的内容。如果资源已被移动，可发送一个重定向状态码和一个可选的location首部来告知客户端资源已被移走，以及现在在哪里可以找到它。
  

连接管理

TCP连接

TCP的可靠数据管道

TCP流是分段、由IP分组传送

• 一个IP分组首部（通常为20字节）
• 一个TCP段首部（通常为20字节）
• 一个TCP数据块（0或者多个字节）
  IP首部包含了源和目的IP地址、长度和其他一些标记。TCP段的首部包含了TCP端口号、TCP控制标记，以及用于数据排序和完整性检查的一些数字值。

  保持TCP连接的正确运行

  在任意时刻计算机都有几条TCP连接处于打开状态。TCP是通过端口号来保持这些连接正确运行。
  端口号类似分机号。IP能让你连接到正确的计算机，端口号则可以将你连接到正确的应用程序上。TCP连接通过4个值来识别：

   

  <源 IP 地址、 源端口号、 目的IP地址、目的端口号>

   

  这四个值一起唯一定义了一条连接。两条不同的TCP连接不能拥有4个完全相同的地址组件值。
  

TCP套接字编程

HTTP连接的处理

串行事务处理时延

• 并行连接：多条TCP连接发起并发的HTTP请求
• 持久连接：重用TCP连接，以消除连接及关闭时延
• 管道化连接：通过共享的TCP连接发起并发的HTTP请求。
  具体细节可看HTTP权威指南

代理

代理和网关对比

共有代理缓存

代理缓存的层次结构

缓存的处理步骤

保持副本的的新鲜

• 文档过期
  通过特殊的HTTP cache-control首部和expires首部，HTTP协议让原始服务器向每个文档附加了一个过期日期。在缓存文档过期之前，缓存可以任意使用副本，而无需与服务器联系。除非客户端请求中包含阻止提供已缓存或者未验证资源的首部。一旦过期，缓存必须和服务器核对。一旦修改过，就要获取一份新的副本。
• 过期日期和使用期
  cache-control：max-age 是用的使用期。只这个副本可用使用多久 Cache-Control: max-age=484200
  expires 用的是绝对时间，到这个时间之前，都可以用这个副本。Expires: Fri, 05 Jul 2002, 05:00:00 GMT
• 服务器再验证
  缓存文档过期不意味着服务器文档已改变，只意味着到了要核对的时间了。这种情况称为服务器再验证。

   

  如果再验证时发生了变化，缓存会获取一份新的文档副本，并将其存储在旧文档位置，然后将其发送给客户端。

  如果没有发生变化，缓存只需要获取新的首部，包括一个新的过期日期，并对缓存中首部进行更新。

  条件法进行再验证

• if-modified-since:Date再验证
• if-none-match：实体标签再验证
  有些情况仅使用最后修改日期进行再验证是不够的。
  1.有些数据会周期性重写，实际包含数据一样。数据没变，但是修改日期变了
  2.有些可能做了修改，但是修改不重要
  3.有些服务器无法准确判断其页面的最后修改日期
  4.有些服务器文档在亚秒之间发送变化（如实时监视器）。对这些服务器来说，秒为粒度的修改日期不够用。
  为了解决这个问题，HTTP允许用户对被称为实体标签（ETag）的版本标识符进行比较。实体标签是附加到文档上的任意标签。他们可能包含了文档的序列号或者版本名。或者是文档内容校验和其他指纹信息。
  
• 强弱验证器
  有时，服务器希望文档的一些非实质性更改不要使所有的已缓存副本都失效。HTTP/1.1支持弱验证器。服务器会使用"W/"来标识弱验证器。

  控制缓存的能力

  cache-control：no-store
  cache-control：no-cache
  cache-control：must-revalidate
  cache-control：max-age
  附加Expires日期到响应中
  不附加过期信息，缓存自己确定自己的过期日期
  no-store和no-cahce首部可以防止缓存提供未经证实的已缓存的对象。标识未no-store的响应会禁止缓存对响应进行复制。缓存通常像非缓存代理服务器一样，向客户端转发一条no-store响应，然后删掉对象。
  no-cache的响应其实是可以存储在本地缓存区中。只是与原始服务器进行新鲜度再验证前，缓存不能将其提供给客户端用。
  max-age认为此文档处于新鲜度的秒数。expires和max-age类似，只不过expires使用绝对日期。建议使用max-age，因为很多服务器时钟不同步。
  可以配置缓存，使其提供一些陈旧（过期）的对象，以提高性能。如果原始服务器希望缓存严格遵守过期信息，可以在原始响应中附加一个cache-control:must-revalidate首部。
  must-revalidate告诉缓存，在事先没有和原始服务器进行再验证情况下，不能提供这个对象的副本。缓存仍然可以随意提供新鲜的副本。如果缓存进行must-revalidate新鲜度检查时，原始服务器不可用，缓存就必须返回一条504Gateway Timeout错误。
  理解
  I believe that must-revalidate means "once the cache expires, refuse to return stale responses to the user even if they say that they are acceptable". Whereas no-cache implies must-revlidateplus the fact the response becomes stale right away.
  If a response is cacheable for 10 seconds, then must-revalidate kicks in after 10 seconds, whereas no-cache implies must-revalidate after 0 seconds.

  客户端新鲜度
  

网关、隧道和中继

网关

协议网关

资源网关

• 收到客户端A的请求，根据URI将其通过API发送到一个数码相机应用程序。将得到的图片绑定到一条HTTP响应报文中，再回传给客户端，在客户端的浏览器中显示。
• 客户端B的URI请求是一个电子商务应用程序。客户端B的请求是通过服务器网关API发送给电子商务软件的，结果会被回送给浏览器。电子商务软件与客户端进行交互，引导用户通过一系列HTML页面来完成购物。
  第一个流行的应用程序网关API就是通用网关接口（Common Gateway Interface，CGI）。CGI是一个标准接口集，Web服务器可以用它来装载程序以响应对特定URL的HTTP请求，并收集程序的输出数据，将其放在HTTP响应中回送。
  具体实现方式：请求需要使用网关资源时，服务器会请辅助应用程序来处理请求。服务器会将辅助请求数据所需的数据给它。通常就是整条请求，或者用户想在数据库上运行的请求之类的东西。
  然后，它会向服务器返回一条响应或响应数据，服务器则会将其转发给客户端。服务器和网关是相互独立的应用程序，因此他们的责任分的很清楚。这个简单的协议（输入请求，转交，响应）就是最古老、最常用的服务器扩展接口CGI的本质。
  

CGI

CGI学习（扩展）

服务器扩展API

应用程序接口和Web服务

隧道

• 用connect建立HTTP隧道
  Web隧道是用HTTP的connect方法建立起来的。connect方法并不是HTTP/1.1核心规范的一部分，但却是得到广泛应用的扩展。connect方法请求隧道网关创建一条到达任意目的服务器和端口的TCP连接，并对客户端和服务器之间的后继数据进行盲转发。
  

客户端识别与cookie机制

个性化接触

客户端ip地址

• 客户端ip地址描述的是机器，而不是用户。
• 因特网服务商提供动态分配ip，用户每登陆一次，都是一个新地址。
• 为了提高安全性，并对稀缺资源进行管理，很多用户都是通过网络地址转换（Network Adress Translation，NAT）防火墙来浏览网络内容的。这些NAT设备隐藏了防火墙后面实际的客户端地址。将实际的客户端IP地址转换成一个共享的防火墙IP地址（和不同的端口号）。
• HTTP代理和网关通常会打开一些新的、到原始服务器的TCP连接。Web服务器看到的将是代理服务器的IP地址，而不是客户端的。有些代理为了绕过这个问题会添加特殊的Client-IP或X-Forwarded-For扩展首部来保存原始地址。但并不是所有代理都支持这种行为。
  用户登陆
  Web服务器无需被动的根据用户IP来猜测身份，可以要求通过用户名密码来显式的询问用户是谁。
  为了是Web站点的登陆更加简便，HTTP中包含了一种内建机制，可以用WWW-Authenticate首部和Authorization首部向Web站点传送用户的相关信息。一旦登陆，浏览器就可以不断的在每条发往这个站点的请求中发送这个登陆信息了。
  
• 客户端对站点www.joes-hardware.com 发起请求。
• 站点并不知道用户身份，服务器返回401 login required HTTP状态码。并添加到WWW-Authentication首部，要求用户登陆。这样浏览器就会弹出一个登陆对话框。
• 只要用户输入了用户名和密码（对其身份进行了完整性检查），浏览器就会重复原来的请求。这次它会加一个Authentication首部，说明用户名和密码并对用户名和密码加密，防止有意无意的窥探者。
• 今后的请求要使用用户名和密码时，浏览器会自动将存储下来的值发送出去，甚至在站点没有要求发送时都会发送。
  cookie
  大多数缓存和浏览器都不允许对任何cookie的内容进行缓存。
  cookie的类型
  可以笼统的将cookie分成两类：会话cookie和持久cookie。会话cookie是一种历史cookie，它记录用户访问站点时的设置和偏好。用户退出浏览器是，会话cookie就会被删除。持久cookie生存时间长一点。他们存储在硬盘上，浏览器退出，计算机重启时他们如仍然存在。通常持久性cookie维护某个用户会周期性访问的站点的配置文件或登录名。
  会话cookie和持久cookie之间唯一的区别就是它们的过期时间。

  cookie是任何工作

  cookie就像是服务器给用户贴的”嗨，我叫"的贴纸一样。用户访问一个Web站点时，站点就可以读取服务器贴在用户身上所有的贴纸。
  用户首次访问Web站点时，Web服务器对用户一无所知。Web服务器希望这个用户会再回来，所以想给这个用户拍上一个独有的cookie，这样以后就能识别这个用户了。cookie包含了一个有name=value这样的信息构成的任意列表，并通过Set-Cookie或Set-Cookie2 HTTP响应（扩展）首部将其贴到用户身上。
  

cookie罐：客户端状态

不同站点使用不同cookie

• 对所有这些cookie字节进行传输会严重降低性能。浏览器实际传输的cookie字节数要比实际内容节数多
• cookie中包含的是服务器特有的名字和值对，所以对大部分站点来说，大多数cookie都只是无法识别的无用数据。
• 将所有cookie发送给所有站点会引发潜在的隐私问题，那些你并不信任的站点也会获得你只想发给其他站点的信息。
  总之，浏览器只向服务器发送服务器产生的cookie。joes-hardware.com产生的cookie会被发送到joes-hardware.com，不会发送到bobs-books.com。

   

  • cookie的域属性
    产生cookie的服务器可以向Set——Cookie响应首部添加一个Domain属性来控制哪些站点可以看到那个cookie。
    Set-cookie: user="mary17"; domain="airtravelbargains.com";
  • cookie路径属性
    cookie规范甚至允许用户将cookie与部分Web站点关联起来。可以通过path属性来实现这一功能，在这个属性列出的URL路径前缀下所有的cookie都是有效的。
    例如，某个Web服务器是由两个组织共享的。每个组织有独立的cookie。站点www.airtravelbargains.com 可能将部分Web站点用于汽车租赁，例如 www.airtravelbargains.com/autos/ 用一个独立的cookie来记录用户喜欢的汽车尺寸。
    Set-cookie: pref=compact; domain="airtravelbargains.com"; path=/autos/
    如果用户访问 www.airtravelbargains.com/autos/specials.html 就会获得这个cookie：
    cookie=“mary17"
    但是如果访问www.airtravelbargains.com/autos/cheapo/index.html 就会获得两个cookie：
    cookie:user="mary17"
    cookie: pref=compact

cookie成分