HTTP

学习一下网络世界的基础 HTTP

HTTP 概述

web 的结构组件

• 代理
  位于客户端和服务器之间的 HTTP 中间实体

• 缓存
  HTTP 的仓库,常使用页面的副本可以保存在距离客户端更近的地方

• 网关
  连接其他应用程序的特殊 web 服务器

• 隧道
  对 HTTP 通信报文进行盲转发的特殊代理

• Agent 代理
  自动发起 HTTP 请求的半智能 Web 客户端

代理

代理比较好理解,就是位于客户端和服务端之间,接收所有客户端的 HTTP 请求,并将这些请求转发给服务器(也有可能会对请求尽心修改后转发),客户端无法感知代理的存在.

缓存

Web 缓存或者代理缓存,是一种特殊的 HTTP 代理服务器,可以将经过代理传送的常用文档复制保存起来(保存在距离客户端比较近的地方),这会客户端直接从比较远服务端传输快得多

网关

网关是一种特殊的服务器,它作为其他服务器的中间实体使用,通常用于将 HTTP 流量转化为其他的协议,同样客户端不可感知网关.

隧道

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

Agent 代理

用户 Agent 代理,是代表用户发起 HTTP 请求的客户端程序,所有发布 Web 请求的应用程序都是 HTTP Agent 代理

URL 与资源

URL 就是因特网资源的标准化名称,URL 指向一条点子信息片段,告诉你他们位于何处,以及如何进行交互

方案的世界

方案	描述
HTTP	超文本传输协议方案,除了没有用户名和密码之外与通用的 URL 格式相符,如果省略端口号那么默认就为 80 端口
HTTPS	方案 HTTPS 与方案 HTTP 是一堆,唯一区别是位于方案 HTTPS 使用了 SSL,SSL 为 HTTP 提供了端到端的加密价值,其语语法与 HTTP 相同默认端口为 443
mailto	Matilto URL 指向的是 email 地址
ftp	文件传输协议 URL,可以用来从 FTP 服务器上下载或者上载文件
rtsp,rtspu	RTSP URL 是可以通过实时流传输协议解析音频视频的标识符
file	方案 file 表示指定主机(通过本地磁盘网络文件系统或者其他)上可以直接访问文件
news	方案 news 用来访问一些特定的文章或者新闻组,他有一个特殊的性质:newsURL 自身包含的信息不足以对资源进行定位
telnet	方案 telnet 用于交互式访问业务,他表示的并不是对象本身,而是可以通过 telnet 协议访问的交互应用程序

HTTP 报文

讲解了以下概念:

• 报文是如何流动的
• HTTP 报文的组成部分(起始行,首部和实体的主体部分)
• 请求和响应报文之间的区别
• 请求报文支持的各种功能(方法)
• 和响应报文一起返回的各种状态码
• 各种各样的 HTTP 头部都是用来做什么的

报文流

HTTP 报文是在 HTTP 应用程序之间发送的数据块,这些数据块以文本形式的元信息开头,这些信息描述了报文的内容以及含义,后面跟着可选的数据部分,这些报文在客户端,服务器和代理之间流动,术语:流入,流出,上游,下游都是用来描述报文的方向

报文流入源端服务器

HTTP 使用术语流入和流出来描述事物处理的方向,报文流入源端服务器,工作完成之后,会流回用户的 Agrnt 代理中

报文的组成部分

HTTP 报文是简单的格式化数据块,每条报文都包含来自客户端的请求,或者来自服务端的响应,它们由三个部分组成:对报文进行描述的起始行,包含属性的头部块,以及可选的包含数据的主题部分.

报文的语法

所有的 HTTP 报文都可以分为两类: 请求报文和响应报文,请求报文会向 Web 服务器请求一个动作,响应报文将请求的结果返回给客户端,两者的结构基本相同(起始行,请求头/响应头和可选的包含数据的主题部分)

下面是报文的格式

<!-- 请求报文 -->
<method>
  <request-URL>
    <version>
      <headers> <entity-body> </entity-body></headers></version></request-URL
></method>

<!-- 响应报文 -->
<version
  ><status
    ><reason-phrase>
      <headers> <entity-body></entity-body></headers></reason-phrase></status
></version>

两者只有起始行的语法不太相同

• 方法
  客户端希望服务器对资源执行的动作,是一个单独的动词,比如 GET/HEAD 或者 POST

• 请求 URL(request-URL)
  命名了所请求资源,或者 URL 路径的完整 URL,如果直接与服务器进行对话,只需要 URL 的路径组件是绝对路径

• 版本
  报文所使用的 HTTP 版本

• 状态码(status-code)
  三位数字描述了请求过程中所发生的情况,每个状态码的第一位都用于描述一般的类别(成功或者出错)

• 原因短语(reason-phrase)
  数字状态码的可读版本,包含了终止序列之前的所有文本,原因短语只对人类有意义,对程序而言并不会起作用

• 头部(header)
  可以有零个或者多个头部,每个首部都包含了一个名字,后面跟着一个冒号,然后是一个可选的空格接着是一个值,最后是一个 CRLF(换行符),首部是由一个空行(CRLF)结束的

• 实体的主体部分(entity-body)
  实体的主体部分包含一个由任意数据组成的数据块,这个是可选的

起始行

所有的 HTTP 报文都是以一个起始行作为开始的,请求报文的起始行说明了要做什么,响应报文的起始行说明发生了什么.

1. 请求行
   请求报文请求服务器对资源进行一些操作,请求报文的起始行,包括了一个方法和一个 URL,这个方法描述了服务器应该执行的操作,请求 URL 描述了要对那个资源执行这个方法,请求行中还包含了 HTTP 的版本,来告诉服务器使用的是那种 HTTP.

2. 响应行
   响应报文承载了状态信息和操作产生的结果数据,将其返回给客户端,响应报文的起始行,包含了响应报文使用的 HTTP 版本,数字状态码,以及描述操作状态的文本形式的原因短语

3. 方法
   请求的起始行以方法作为开始,方法用来告知服务器要做些什么

常用的 HTTP 方法

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

状态码

方法是客户端告诉服务器做什么事,而状态码则告诉客户端,发生了什么事

状态码是在每条响应报文的起始行中返回的,会返回一个数字状态和一个可读的状态码,数字码便于对程序惊醒差错处理,而原因短语则更便于人们理解

可以通过三位数字码对不同状态码进行分类,200-299 之间的状态码表示成功,300-399 之间的状态码表示资源已经被移走,400-499 之间的状态码表示客户端请求出错了,500-599 之间的状态码则表示服务器出错了

状态码分类

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

原因短语

原因短语是响应起始行中最后一个组件,它为状态码提供了文本形式的解释

原因短语和状态码是成对出现的,烟瘾短语是状态码的可读版本,应用程序开发者将其传递给用户,用于说明在请求期间发生了什么情况

HTTP 规范并没有提供任何硬性规定,要求原因短语以何种形式出现

版本号

版本号会以 HTTP/x.y 的形式出现在请求和响应的报文起始行中,为 HTTP 应用程序提供一种将自己所遵循的协议版本号告知对方的方式

使用版本号的目的是为了使用 HTTP 的应用程序提供一种线索,以便互相了解对方的能力和报文格式.

版本号说明了应用程序支持的最高 HTTP 版本,但在 HTTP1.0 应用程序在解析包含 HTTP1.1 的响应时会认为这个响应时 1.1 响应,而实际上只是响应应用程序所使用的协议等级,在这些情况下,版本号会在应用程序之间造成误解

头部

HTTP 头部字段向请求和响应添加了一些附加消息,本质上来说,它们只是一些名/值对的列表

1. 首部分类

HTTP 规范定义了集中首部字段,应用程序也可以随意发明自己所使用的首部,HTTP 的首部可以分为一下几类

• 通用首部
  既可以出现在请求报文中,也可以出现在响应报文中

• 请求首部
  提供更多关于请求的信息

• 响应首部
  提供更多关于响应的信息

• 实体头部
  描述主题的长度和内容,或者资源自身

• 扩展首部
  规范中没有定义的新首部

每个首部都有一个简单的语法: 名字后面跟着冒号:然后跟上可选的空格,再跟上字段值,最后是一个CRLF

** 常见的首部实例**

首部实例	描述
Date: Tue,30ct 1997 02:15:03 GMT	服务器产生响应的日期
Content-length:15040	实体的主题部分包含了 15040 字节的数据
Content-type:image/gif	实体的主题部分是一个 GIF 图片
Accept:image/gif,image/jpeg,text/html	客户端可以接收 GIF 图片和 JEPG 图片以及 HTML

首部延续行

将长的首部行分为多行可以提高可读性,多出来的每行前面至少要有一个空格或者制表符

连接管理

HTTP 规范对 HTTP 报文解释的很清楚,但是对于 HTTP 连接介绍的并不多,HTTP 连接是 HTTP 报文传输的关键通道,编写 HTTP 应用程序员需要理解 HTTP 连接的来龙去脉,以及如何使用这些连接.

HTTP 连接管理有点像魔术,应当从经验以及实践,而不仅仅是出版文献中学习,本章学习如下内容:

• HTTP 是如何使用 TCP 连接的
• TCP 连接的时延瓶颈以及存在的障碍
• HTTP 的优化,包括并行连接 keep-alive(持久连接)和管道化连接
• 管理连接时应该以及不应该做的事情

TCP 连接

世界上几乎所有的 HTTP 通信都是由 TCP/IP 承载的,TCP/IP 是全球计算机以及网络设备使用的一种常用的分组交换网络分层协议集,客户端可以打开一条 TCP/IP 连接,连接到可能运行在世界任何地方的服务器应用程序,一旦连接建立,在客户端和服务器的计算机之间交还的报文就永远不会丢失,受损或失序(尽管报文不会丢失或者受损,但是如果网络崩溃,那么连接仍然会被断开,在这种情况下会通知客户端和服务端失去连接)

TCP 的可靠数据管道

HTTP 连接实际上就是 TCP 连接及其使用规则,TCP 连接是因特网上的可靠连接想要正确的快速的发送数据,就需要了解 TCP 知识.

TCP 为 HTTP 提供了一条可靠的比特传输管道,从 TCP 连接一端填入的字节会从另一端以原有的顺序,正确的传送出来

TCP 流是分段的,由 IP 分组传送

TCP 的数据是通过名为 IP 分组的小数据块来发送的,这样的话,HTTP 就是 HTTP over TCP over IP 这个协议栈中的最顶层了,其安全版本 HTTPS 就是在 HTTP 和 TCP 之间插入了一个密码加密层

HTTP 要传送一条报文时,会以流的形式将报文数据的内容通过一条打开 TCP 连接按序传输,TCP 收到数据流之后,会将数据流砍成被称作段的小数据块,并将段封装在 IP 分组中,通过因特网进行传输,所有的这些工作都是由 TCP/IP 软件来处理的,HTTP 程序员看不到.

每个 TCP 段由 IP 分组承载,从一个 IP 地址发送到另一个 IP 地址,每个 IP 分组中都包括:

• 一个 IP 分组头部(通常为 20 字节)
• 一个 TCP 头部(通常为 20 字节)
• 一个 TCP 数据块(0 个或者多个字节)

IP 首部包含了源和目的 IP 地址,长度和其他一些标记,TCP 段的首部包含了 TCP 端口号,TCP 控制标记,以及用于数据排序和完整性检查的一些数字

保持 TCP 连接持续不断的运行

TCP 是通过端口号来保持这些所有连接持续不断的运行.

源 IP 地址 - 端口号 - 目标 IP 地址 - 目的端口号

这四个值一起唯一地定义了一条连接,两个不同的 TCP 连接不能拥有 4 个完全相同的地址组件(但是不同的连接的部分组件可以拥有相同的值)

HTTP 事务的时延

HTTP 事务的时延有以下几种主要原因

1. 通过 DNS 解析系统将一个 URL 中的主机名转换成一个 IP 需要的时间
2. 每条 TCP 连接都会有连接建立时延
3. 链接建立之后,客户端就会通过新建立的 TCP 管道来发送 HTTP 请求,数据到大时候,会对报文进行处理

性能聚焦区域

下面了出了一些会对 HTTP 程序员产生影响的最常见的 TCP 相关时延:

• TCP 连接建立握手
• TCP 慢启动拥塞控制
• 数据聚集的 Nagle 算法
• 用于捎带确认的 TCP 延迟确认算法
• TIME_WALT 时延和端口耗尽

TCP 的连接

TCP 的连接握手需要经过以下步骤

• 请求新的 TCP 连接时候,客户端要向服务器发送一个小的 TCP 分组,这个分组中设置了一个特殊的 SYN 标记,说明这是一个连接请求
• 如果服务器接受了这个连接,就会对连接的一些参数进行计算,并想客户端回送一个 TCP 分组,这个分组中的 SYN 和 ACK 标记被置位,说明连接请求已经被接受
• 最后客户端向服务器发送一条确认信息,通知它连接已经建立成功,现代的 TCP 栈都允许客户端在这一个步骤中发送数据

并行连接

浏览器可以先完整的请求原始的 HTML 页面,然后请求第一个嵌入对象,然后请求第二三四…个,但是这样太慢了,所以 HTTP 允许客户端打开多条连接,并行的执行多个 HTTP 事务

并行连接可能会提高页面的加载速度,同时 并行连接也会占用可用宽带,如果宽带不足,可能导致每一个并行连接都会以较慢的速度加载,这样的话对性能提升就很小,甚至没有提升.

持久连接

web 客户端常常会打开到同一个站点的连接,HTTP1.1 允许 HTTP 设备在事务处理结束后将 TCP 连接保持在打开状态,以便为未来的 HTTP 请求重用现存的连接,在事务处理结束之后仍然保持在打开状态的 TCP 连接被称为持久连接,非持久连接会在每次事件结束后关闭,持久连接会在不同事务之间保持打开状态,直到客户端或者服务端决定将其关闭为止.(不太好用看书上写的)

代理

本章主要内容

• 对 HTTP 代理进行解释,将其与 Web 网关进行对比,并说明如何部署代理
• 给出一些代理所能提供的帮助
• 说明在现实网络中是怎样部署带来以及如何将挽网络流量导向代理服务器
• 说明如何配置浏览器来使用代理
• 展示 HTTP 的代理请求,说明它们与服务器请求的区别,以及代理是如何微妙的改变浏览器行为的
• 解释如何通过 Via 首部和 TRACE 方法来记录报文传输路径上的代理服务器链
• 描述基于代理的 HTTP 访问控制方法
• 解释代理如何与客户端和服务器进行交互,每个客户端和服务器支持的特性和使用的版本都可能有所不同

Web 的中间实体

Web 上的代理服务器是代表客户端完成事务处理的中间人,HTTP 代理服务器既是 Web 服务器又是 Web 客户端,HTTP 客户端向代理服务器发送请求报文,代理服务器必须像 Web 服务器一样,正确的处理请求和连接,然后返回响应,同时,代理自身要向服务器发送请求,这样,其行为必须像正确的 HTTP 客户端一样,要发送请求并接收响应.

代理和网管的对比

严格来说,代理连接的是两个或者多个使用协议相同协议的应用程序,而网关连接则是两个或多个使用不同协议的端点,网关扮演的是协议转换器的角色,即使客户端和服务端使用不同的协议,客户端也可以通过它完成与服务器之间的事务处理.

为什么使用代理

代理服务器可以实现各种有用的功能,它可以改善安全性,提高性能,节省费用,代理服务器可以看到并接触到所有流过的 HTTP 流量,所以代理可以简史流量并对其进行修改,可以实现很多有用的增值 web 服务.

代理层次结构的内容

代理服务器可以根据众多因素,将报文转发给一个不断变化的代理服务器和原始服务器集例如:

• 负载均衡
  子代理可能会根据当前父代理上的工作负载级别来决定如何选择一个父代理,以负载均衡

• 地理位置附近的路由
  子代理可能会选择负责原始服务器所在物理区域的父代理

• 协议/类型路由
  子代理可能会根据 URL 将报文转发到不同的父代理和原始服务器上去,某些特定类型的 URL 可能要通过一些特殊的代理服务器转发请求,以便进行特殊的协议处理

• 基于订购的路由
  如果发布者为了高性能服务器额外付费,它们的 URL 就会被转发到大型缓存或压缩引擎上去,以提高性能

缓存

Web 缓存是可以自动保存常见文档副本的 HTTP 设备,往 Web 请求抵达缓存时候,如果本地有已缓存副本,就可以从本地储存设备而不是原始服务器中提取这个文档,使用缓存有下列优点

• 缓存减少了冗余的数据传输,节省了你的网络费用
• 缓存缓解了网络瓶颈的问题,不需要更多的快带就能够更快的加载页面
• 缓存降低了对原始服务器的要求,服务器可以更快的相应,避免过载的出现
• 缓存降低了距离延时,因为从较远的地方架子啊页面会更慢一些

命中和未命中的

缓存是有所帮助的,但是无法缓存世界上每份文档的副本

可以使用已有的副本为某些达到缓存的请求提供服务,这被称为缓存命中,其他一些达到缓存的请求可能会由于没有副本可用,而被转发到原始服务器,这被称为缓存未命中

再验证

原始服务器的内容可能会发生变化,缓存要不时对其进行检测,看看它们保存的副本是否仍是服务器上的最新副本,这些新鲜度检测被称为 HTTP 在验证,为了有效的进行验证,HTTP 定义了一些特殊的请求,不用从服务器上获取整个对象,就可以快速检测出内容是否是最新

缓存对缓存的副本进行再验证时,会向原始服务器发送一个小的再验证请求,如果内容没有变化服务器会以一个小的 304 进行相应,只要缓存知道副本仍然有效,就会再次将副本标识为暂时新鲜,并将副本提供给客户端,这被称为在验证命中,或缓命中,这种方式确实要与原始服务器进行核对,所以会比单纯的缓存命中要慢,但他没有从服务器中获取对象数据,所以比缓存未命中要快一些

命中率

由缓存提供服务的请求占的比例被称为缓存命中率,或称为缓存命中比例,命中率在 0-1 之间,通常使用百分数来描述,缓存的管理者都希望缓存的命中率接近 100%,而实际得到的命中率则与缓存的大小,缓存用户兴趣的相似性,缓存数据的变化或者个性化频率,以及如何配置缓存有关,命中率很难预测,但对现在中等规模的 Web 缓存来说,40%的命中率是很合理的,缓存的好处是,即使中等规模的缓存,其包含的常见文档足以显著的提高性能,减少流量了,缓存会努力确保将有用的内容保存在缓存中

集成点:网关,隧道及中继

事实证明,Web 是一种强大的内容发布工具,随着时间的流逝,人们已经只在网络上发送静态的在线文档,发展到共享更为复杂的资源,比如数据库内容或者动态生成的 HTML 页面,Web 浏览器这样的 HTTP 应用程序为用户提供了一种统一的方式来访问英特网上的内容

本章主要简介一些开发者用 HTTP 访问不同资源的方法,展示了开发者如何将 HTTP 作为框架启动其他协议和应用通信

• 在 HTTP 和其他协议以及应用程序之间祈祷接口作用的网关
• 允许不同类型的 Web 应用程序互相通信的应用程序接口
• 允许用户在 HTTP 连接上发送非 HTTP 流量的隧道
• 作为一种简化的 HTTP 代理,一次将数据转发一跳的中继

网关

HTTP 扩展的和接口的发展是由用户需求驱动的,要在 Web 上发布更为复杂资源的需求出现时,人们很快就明确了一点:单个应用程序无法处理所有这些想到的资源

为了解决这个问题,开发者提出了网关的概念,网关可以作为某种翻译器使用,它抽象出了一种能够到达资源的方法,网关是资源和应用程序之间的粘合剂,应用程序可以(通过 HTTP 或其他已定义的接口)请求网关来处理某条请求,网关可以提供一条响应,网关可以向数据库发送查询语句,或者生成动态的内容,就像门一样:进去一条请求,出来一个响应

客户端和服务器网关

Web 网关在一侧使用 HTTP 协议,在另一侧使用另一种协议

可以用一个希尔盖来分隔客户端和服务器端协议,并一次对网关进行描述:

客户端协议 - 服务器端协议

因此,将 HTTP 客户端连接到 NNTP 新闻服务器的网关就是一个 HTTP/NNTP 网关,使用数据服务器端网关和客户端网关来说明对话是在网关的哪一侧进行的.

• 服务端网关通过 HTTP 与客户端对话,通过其他协议与服务器通信
• 客户端网关通过其他协议与客户端对话,通过 HTTP 协议与服务器通信

隧道

Web 隧道允许用户通过 HTTP 连接发送非 HTTP 流量,这样就可以在 HTTP 上捎带其他数据协议了,使用 Web 隧道最常见的原因就是在 HTTP 连接中嵌入非 HTTP 流量,这样,这类流量就可以穿过只允许 Web 流量通过的防火墙了

Web 机器人(爬虫)

爬虫及爬行方式

Web 爬虫是一种机器人,他会递归对各种信息性的 Web 站点进行遍历,获取第一个 Web 页面,然后获取那个页面指向的所有 Web 页面,然后是那些页面指向的所有 Web 页面以此类推,递归地追踪这些 Web 连接的机器人会沿着 HTML 超链接创建的网络爬行,所以也称为爬虫或者蜘蛛

Web 站点和 robots.txt 文件

如果一个 Web 站点有 robots 文件,那么访问这个站点的爬虫在访问任何 URL 之前必须获取这个文件,并且对齐处理,以阅读这个文件上的限制(防君子不防小人)

客户端识别与 cookie 机制

个性化接触

HTTP 最初是一个匿名,无状态的请求/相应协议,服务端处理来自客户端的请求,然后向客户端回送一条响应,Web 服务器几乎没什么信息可以用来判定是那个用户发送的请求,也无法记录来访用户的请求序列

下面介绍用户识别机制

• 承载用户身份信息的 HTTP 首部
• 客户端 IP 地址跟踪,通过用户地址的 IP 地址对其进行识别
• 用户登陆,用户认证方式来识别用户
• 胖 URL,一种在 URL 中嵌入识别信息的技术
• cookie,一种功能强大且高效的持久身份识别技术

HTTP 首部

下面是七种最常见的哦拿过来承载用户相关信息 HTTP 请求首部

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

不常见的就不做笔记了

用户登陆

为了使 Web 站点的登陆更加简单,HTTP 中包含了一种内建机制,可以使用 www-Authenticate 首部和 Authorization 首部向 Web 站点传送用户相关信息,一旦登陆,浏览器就可以不断地在每条发往这个站点的请求中发送了这个登陆信息了

就是在请求头中附加这个 Authorization 头部来向服务端发送请求,从而完成用户识别

胖 URL

有些 Web 站点会为每个用户生成特定版本的 URL 来追踪用户身份,通常,会对真正的 URL 进行扩展,在 URL 路径开始或结束的地方添加一些状态信息,用户浏览站点时,Web 服务器会动态生成一些连接,继续维护 URL 中的状态信息

例如,验证注册,会向邮箱中发送一个邮件,邮件包含一个 URL 点击 URL 进行之后的步骤

首先这个 URL 无法共享,因为这个 URL 中包含了与特定用户和会话有关的状态信息

cookie

cookie 是识别当前用户,实现持久会话的最好方式,前面各种技术中存在的很多问题对它们都没什么影响,但是通常会将它们与那些技术共享,以实现额外的价值,cookie 最初是由网景公司开发的,但是现在所有的主要浏览器都支持它

cookie 的类型

可以笼统的讲 cookie 分为两类:会话 cookie 和持久化 cookie 会话 cookie 是一种临时 cookie,它记录了用户访问站点时的设置和偏好,用户退出浏览器时,会话 cookie 就被删除了,持久 cookie 的生存时间更长,他们储存在硬盘上,浏览器退出时仍然存在.

不同站点使用不同的 cookie

浏览器内部 cookie 罐中可以有成百上千个 cookie,但是浏览器不会将每个 cookie 都发给所有站点,实际上,他们通常向每个站点发送 2-3 个 cookie,原因如下:

• 对于所有这些 cookie 字节传输会严重降低性能,浏览器实际传输的 cookie 字节数要比实际的内容字节数要多
• cookie 中包含的服务器特有的名值对,所以对大部分站点来说,大多数 cookie 都只是无法识别的无用数据
• 将所有的 cookie 发送的所有站点会引发潜在的隐私问题,那些你不信任的站点也会获取你指向发送给其他站点的信息

总之浏览器只会向服务器发送服务器产生的 cookie

1. cookie 的域属性
   产生 cookie 的服务器可以向 Set-Cookie 响应头部添加一个 Domain 属性来控制那些站点看到那个 cookie

2. cookie 路径属性
   cookie 规范甚至允许用户将 cookie 与部分 Web 站点关联起来,可以通过 Path 属性来实现这个功能,在这个属性列出的 URL 路径前缀所有 cookie 都是有效的