HTTP

• Http概念
• 与 Http 相关的各种概念
• 与 Http 相关的各种协议
  • 代理的常见种类
  • 代理的一些作用
• 域名
  • 域名的形式
  • 域名的解析
  • 总结
  • 问题
• HTTP 实验环境
• HTTP请求响应的过程
  • 使用 IP 地址访问 Web 服务器
    • 抓包分析过程
  • 使用域名访问 Web 服务器
  • 真实的网络世界
  • 总结
• Http 协议核心 - 报文结构
  • 报文的基本结构
  • 请求行(请求报文)
  • 状态行(响应报文)
  • 头部字段
  • 常用头字段
  • 总结
• 请求头 - 请求方法
  • 标准请求方法
  • 请求方法详解
  • 扩展方法
  • 安全与幂等
  • 小结
• URI
  • URI 的完整格式
  • URI 的编码
  • 小结
• 状态码
  • 小结
• HTTP特点
  • 小结
• HTTP优缺点
  • 小结
• HTTP的实体数据
  • 数据类型与编码
  • 数据类型使用的头字段
  • 语言类型与编码
  • 语言类型使用的头字段
  • 内容协商的质量值
  • 内容协商的结果
  • 小结
• HTTP传输大文件
  • 数据压缩
  • 分块传输
  • 范围请求
  • 多段数据
  • 小结
• HTTP 的连接管理
  • 长连接和短链接
  • 连接相关的头字段
  • 队头阻塞
  • 性能优化
  • 小结
• HTTP 的重定向和跳转
• HTTP的Cookie机制
  • 小结
• HTTP 缓存控制
  • 服务器的缓存控制
  • 客户端的缓存控制
  • 条件请求
  • 小结
• HTTP的代理服务
  • 代理服务
  • 代理的作用
  • 代理相关头字段
  • 代理协议
  • 小结
• HTTP的缓存代理
  • 缓存代理服务
  • 源服务器的缓存控制
  • 客户端的缓存控制
  • 其他问题
  • 小结

Http

超文本传输协议：HTTP 是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范。

Http概念

1. HTTP 是一个用在计算机世界里的协议，它确立了一种计算机之间交流通信的规范，以及相关的各种控制和错误处理方式。
2. HTTP 专门用来在两点之间传输数据，不能用于广播、寻址或路由。
3. HTTP 传输的是文字、图片、音频、视频等超文本数据。
4. HTTP 是构建互联网的重要基础技术，它没有实体，依赖许多其他的技术来实现，但同时许多技术也都依赖于它。

与 Http 相关的各种概念

1. 互联网上绝大部分资源都使用 HTTP 协议传输；
2. 浏览器是 HTTP 协议里的请求方，即 User Agent；
3. 服务器是 HTTP 协议里的应答方，常用的有 Apache 和 Nginx；
4. CDN 位于浏览器和服务器之间，主要起到缓存加速的作用；
5. 爬虫是另一类 User Agent，是自动访问网络资源的程序。

与 Http 相关的各种协议

1. 四层模型：应用层、传输层、网际层、链接层
2. IP协议主要解决寻址和路由问题
3. ipv4，地址是四个用“.”分隔的数字，总数有2^32个，大约42亿个可以分配的地址
4. ipv6，地址是八个用“:”分隔的数字，总数有2^128个。
5. TCP协议位于IP协议之上，基于IP协议提供可靠的(数据不丢失)、字节流(数据完整)形式的通信，是HTTP协议得以实现的基础
6. 域名系统：为了更好的标记不同国家或组织的主机，域名被设计成了一个有层次的结构
7. 域名用“.”分隔成多个单词，级别从左到右逐级升高。
8. 域名解析：将域名做一个转换，映射到它的真实IP
9. URI：统一资源标识符；URL：统一资源定位符
10. URI主要有三个基本部分构成：协议名、主机名、路径
11. HTTPS：运行在SSL/TLS协议上的HTTP
12. SSL/TLS：建立在TCP/IP之上的负责加密通信的安全协议，是可靠的传输协议，可以被用作HTTP的下层
13. 代理(Proxy)：是HTTP协议中请求方和应答方中间的一个环节。既可以转发客户端的请求，也可以转发服务器的应答。
    
14. TCP/IP 是网络世界最常用的协议，HTTP 通常运行在 TCP/IP 提供的可靠传输基础上；
15. DNS 域名是 IP 地址的等价替代，需要用域名解析实现到 IP 地址的映射；
16. URI 是用来标记互联网上资源的一个名字，由“协议名 + 主机名 + 路径”构成，俗称 URL；
17. HTTPS 相当于“HTTP+SSL/TLS+TCP/IP”，为 HTTP 套了一个安全的外壳；
18. 代理是 HTTP 传输过程中的“中转站”，可以实现缓存加速、负载均衡等功能。

代理的常见种类

1. 匿名代理：完全“隐匿”了被代理的机器，外界看到的只是代理服务器；
2. 透明代理：顾名思义，它在传输过程中是“透明开放”的，外界既知道代理，也知道客户端；
3. 正向代理：靠近客户端，代表客户端向服务器发送请求；
4. 反向代理：靠近服务器端，代表服务器响应客户端的请求；

代理的一些作用

• 负载均衡：把访问请求均匀分散到多台机器，实现访问集群化；
• 内容缓存：暂存上下行的数据，减轻后端的压力；
• 安全防护：隐匿 IP, 使用 WAF 等工具抵御网络攻击，保护被代理的机器；
• 数据处理：提供压缩、加密等额外的功能。
  

四层/七层模型

TCP/IP 网络分层模型

• 链接层（link layer），负责在以太网、WiFi 这样的底层网络上发送原始数据包，工作在网卡这个层次，使用 MAC 地址来标记网络上的设备，所以有时候也叫 MAC 层。
• “网际层”或者“网络互连层”（internet layer），IP 协议就处在这一层。因为 IP 协议定义了“IP 地址”的概念，所以就可以在“链接层”的基础上，用 IP 地址取代 MAC 地址，把许许多多的局域网、广域网连接成一个虚拟的巨大网络，在这个网络里找设备时只要把 IP 地址再“翻译”成 MAC 地址就可以了。
• 第三层叫“传输层”（transport layer），这个层次协议的职责是保证数据在 IP 地址标记的两点之间“可靠”地传输，是 TCP 协议工作的层次，另外还有它的一个“小伙伴”UDP。
  • TCP和UDP区别：
    TCP 有状态 需要先建立连接才能发送数据 保证数据不丢失不重复 数据是连续的字节流，有先后顺序；
    UDP 无状态 不需要先建立连接也可以发送数据 不保证数据一定会发送到对方 数据是分散的小数据包，顺序发、乱序收；
• “应用层”（application layer），有各种面向具体应用的协议。例如 Telnet、SSH、FTP、SMTP 、HTTP。

MAC层的传输单位是帧（frame），IP层的传输单位是包（packet），TCP层的传输单位是段（segment），HTTP的传输单位是消息或报文（message）。统称为数据包。

OSI 网络分层模型(开放式系统互联通信参考模型)

1. 第一层:物理层，网络的物理形式，例如电缆、光纤、网卡、集线器等等;
2. 第二层:数据链路层，它基本相当于TCP/IP的链接层;
3. 第三层:网络层，相当于TCP/IP里的网际层;
4. 第四层:传输层，相当于TCP/IP里的传输层;
5. 第五层:会话层，维护网络中的连接状态，即保持会话和同步;
6. 第六层:表示层，把数据转换为合适、可理解的语法和语义;
7. 第七层:应用层，面向具体的应用传输数据。

• TCP/IP四层模型和OSI七层网络模型的映射关系
  • 第一层:物理层，TCP/IP里无对应;
  • 第二层:数据链路层，对应TCP/IP的链接层;
  • 第三层:网络层，对应TCP/IP的网际层;
  • 第四层:传输层，对应TCP/IP的传输层;
  • 第五、六、七层:统一对应到TCP/IP的应用层。
• 四层负载均衡：工作在传输层上，基于TCP/IP协议的特性，例如Ip地址，端口号等实现对后端服务器的负载均衡;
• 七层负载均衡：工作在应用层上，看到的是HTTP协议，解析HTTP报文里的URI、主机名、资源类型等数据，再用适当的策略转发给后端服务器;
• 二层转发：设备工作在链路层，帧在经过交换机设备时，检查帧的头部信息，拿到目标mac地址，进行本地转发和广播；
• 三层路由：设备工作在ip层，报文经过有路由功能的设备时，设备分析报文中的头部信息，拿到ip地址，根据网段范围，进行本地转发或选择下一个网关；
• dns 工作在应用层；
• cdn 工作在应用层

总结

• TCP/IP 分为四层，核心是二层的 IP 和三层的 TCP，HTTP 在第四层；
• OSI 分为七层，基本对应 TCP/IP，TCP 在第四层，HTTP 在第七层；
• OSI 可以映射到 TCP/IP，但这期间一、五、六层消失了；
• 日常交流的时候我们通常使用 OSI 模型，用四层、七层等术语；
• HTTP 利用 TCP/IP 协议栈逐层打包再拆包，实现了数据传输，但下面的细节并不可见。
  

域名

域名的形式

域名是一个有层次的结构，是一串用“.”分隔的多个单词，最右边的被称为“顶级域名”，然后是“二级域名”，层级关系向左依次降低。
最左边的是主机名，通常用来表明主机的用途，比如“www”表示提供万维网服务、“mail”表示提供邮件服务，不过这也不是绝对的，名字的关键是要让我们容易记忆。

域名的解析

就像 IP 地址必须转换成 MAC 地址才能访问主机一样，域名也必须要转换成 IP 地址，这个过程就是“域名解析”;

DNS 的核心系统是一个三层的树状、分布式服务，基本对应域名的结构：

• 根域名服务器（Root DNS Server）：管理顶级域名服务器，返回“com”“net”“cn”等顶级域名服务器的 IP 地址;
• 顶级域名服务器（Top-level DNS Server）：管理各自域名下的权威域名服务器，比如 com 顶级域名服务器可以返回 apple.com 域名服务器的 IP 地址；
• 权威域名服务器（Authoritative DNS Server）：管理自己域名下主机的 IP 地址，比如 apple.com 权威域名服务器可以返回 www.apple.com 的 IP 地址。
  

在这里根域名服务器是关键，它必须是众所周知的，否则下面的各级服务器就无从谈起了。目前全世界共有 13 组根域名服务器，又有数百台的镜像，保证一定能够被访问到。

如，你要访问“www.apple.com”，就要进行下面的三次查询：

• 访问根域名服务器，它会告诉你“com”顶级域名服务器的地址；
• 访问“com”顶级域名服务器，它再告诉你“apple.com”域名服务器的地址；
• 最后访问“apple.com”域名服务器，就得到了“www.apple.com”的地址。

减轻核心的 DNS 系统域名解析的压力的一些方法，基本思路就是“缓存”：

• 许多大公司、网络运行商都会建立自己的 DNS 服务器，被称为“非权威域名服务器”，作为用户 DNS 查询的代理，如果没有相应域名的缓存，则代替用户访问核心 DNS 系统。这些 DNS 服务器的数量要比核心系统的服务器多很多，而且大多部署在离用户很近的地方。如 Google 的“8.8.8.8”，Microsoft 的“4.2.2.1”，还有 CloudFlare 的“1.1.1.1”等等。
• 操作系统里也会对 DNS 解析结果做缓存。如果操作系统在缓存里找不到 DNS 记录，就会找系统 hosts 文件。
  

域名的一些玩法：

• 重定向。可以修改域名对应的映射ip，即改变域名对应的访问主机，实现逻辑上的业务不停机上线；
• 利用bind9 等开源软件搭建内部的DNS，这样我们开发的各种内部服务就都用域名来标记，如数据库服务都用域名“mysql.inner.app”，商品服务都用“goods.inner.app”；
• 基于域名实现的负载均衡
  • 因为域名解析可以返回多个 IP 地址，所以一个域名可以对应多台主机，客户端收到多个 IP 地址后，就可以自己使用轮询算法依次向服务器发起请求，实现负载均衡；
  • 域名解析可以配置内部的策略，返回离客户端最近的主机，或者返回当前服务质量最好的主机，这样在 DNS 端把请求分发到不同的服务器，实现负载均衡。
• 域名屏蔽，不解析域名；
• 域名劫持，也叫“域名污染”，你要访问 A 网站，但 DNS 给了你 B 网站。

总结

• 域名使用字符串来代替 IP 地址，方便用户记忆，本质上一个名字空间系统；
• DNS 就像是我们现实世界里的电话本、查号台，统管着互联网世界里的所有网站，是一个“超级大管家”；
• DNS 是一个树状的分布式查询系统，但为了提高查询效率，外围有多级的缓存；
• 使用 DNS 可以实现基于域名的负载均衡，既可以在内网，也可以在外网。

问题

• 在浏览器地址栏里随便输入一个不存在的域名，比如就叫“www. 不存在.com”，试着解释一下它的 DNS 解析过程
  1. 检查本地dns缓存是否存在解析"www.不存在.com"域名的ip；
  2. 如果没有找到继续查找本地hosts文件内是否有对应的固定记录；
  3. 如果hosts中还是没有那就根据本地网卡被分配的 dns server ip 来进行解析，dns server ip 一般是“非官方”的ip，比如谷歌的“8.8.8.8”，本身它也会对查找的域名解析结果进行缓存，如果它没有缓存或者缓存失效，则先去顶级域名服务器“com”去查找“不存在.com”的域名服务器ip，结果发现不存在，于是直接返回告诉浏览器域名解析错误，当然这两次查找过程是基于udp协议。
     

HTTP 实验环境

• 选择 Wireshark 作为抓包工具，捕获在 TCP/IP 协议栈中传输的所有流量；
• 我们选择 Chrome 或 Firefox 浏览器作为 HTTP 协议中的 user agent；
• 我们选择 OpenResty 作为 Web 服务器，它是一个 Nginx 的“强化包”，功能非常丰富；
• Telnet 是一个命令行工具，可用来登录主机模拟浏览器操作；
• 在 GitHub 上可以下载项目源码，只要把 OpenResty 解压到里面即可完成实验环境的搭建。

HTTP请求响应的过程

使用 IP 地址访问 Web 服务器

如，在浏览器访问：http://127.0.0.1/，Wireshark 抓包如下：

抓包分析过程

因为 HTTP 协议是运行在 TCP/IP 基础上的，依靠 TCP/IP 协议来实现数据的可靠传输。所以会先建立 tcp 连接，对应到 Wireshark 里，就是 No.1，No.2，No.3 三个抓包，浏览器使用的端口是 5354，服务器使用的端口是 80，经过 SYN、SYN/ACK、ACK 的三个包之后，浏览器与服务器的 TCP 连接就建立起来了。

随后浏览器按照 HTTP 协议规定的格式，通过 TCP 发送了一个“GET / HTTP/1.1”请求报文，对应 No.7 ；之后，Web 服务器回复了 No.8，在 TCP 协议层面确认：“刚才的报文我已经收到了”，不过这个 TCP 包 HTTP 协议是看不见的。

Web 服务器收到报文后在内部就要处理这个请求。同样也是依据 HTTP 协议的规定，解析报文，作出 HTTP 协议格式的响应，底层还是用的 TCP 协议，对应 No.9。同样的，浏览器也要给服务器回复一个 TCP 的 ACK 确认，“你的响应报文收到了，多谢”，即 No.10 包。同时，浏览器收到响应数据后，会根据数据格式作出解析。

之后的两个回合重复 No.7 -> No 10。

TCP 关闭连接的“四次挥手”在抓包里没有出现，这是因为 HTTP/1.1 长连接特性，默认不会立即关闭连接。

其中，因为http/1连接传输效率低，所以浏览器一般会对同一个域名发起多个连接提高效率，这个 No4, No.5, No.6 就是开的第二个连接，但在抓包中只是打开了，还没有传输。

整个过程如下所示：

再简要叙述一下这次最简单的浏览器 HTTP 请求过程：

• 浏览器从地址栏的输入中获得服务器的 IP 地址和端口号；
• 浏览器用 TCP 的三次握手与服务器建立连接；
• 浏览器向服务器发送拼好的报文；
• 服务器收到报文后处理请求，同样拼好报文再发给浏览器；
• 浏览器解析报文，渲染输出页面。

使用域名访问 Web 服务器

先会有一个域名解析的过程，随后如果找到对应的 ip，过程同上。

真实的网络世界

解释：

• 通过交换机、蜂窝网络、WiFi 接入网络；
• 网络运行商分配一个 IP 地址，这个地址可能是静态分配的，也可能是动态分配的；
• 发出的 HTTP 请求首先会经过域名解析，如访问 Apple 网站，www.apple.com：
  • 用 DNS 协议开始从操作系统、本地 DNS、根 DNS、顶级 DNS、权威 DNS 的层层解析，当然这中间有缓存，可能不会费太多时间就能拿到结果。因为 CDN 的存在，DNS 解析可能会给出 CDN 服务器的 IP 地址，这样你拿到的就会是 CDN 服务器而不是目标网站的实际地址。因为 CDN 会缓存网站的大部分资源，比如图片、CSS 样式表，所以有的 HTTP 请求就不需要再发到 Apple，CDN 就可以直接响应你的请求，把数据发给你。
• CDN没有缓存的资源，发出的 HTTP 请求就要开始在互联网上的“漫长跋涉”，经过无数的路由器、网关、代理，最后到达目标服务器；
• 目标服务器为了高并发，通常在入口是负载均衡设备，如四层的 LVS 或者七层的 Nginx，在后面是许多的服务器，构成一个更强更稳定的集群。
• 负载均衡设备会先访问系统里的缓存服务器，通常有 memory 级缓存 Redis 和 disk 级缓存 Varnish，它们的作用与 CDN 类似，不过是工作在内部网络里，把最频繁访问的数据缓存几秒钟或几分钟，减轻后端应用服务器的压力。
• 如果缓存服务器里也没有，那么负载均衡设备就要把请求转发给应用服务器了。然后把执行的结果返回给负载均衡设备，同时也可能给缓存服务器里也放一份。
• 应用服务器的输出到了负载均衡设备这里，请求的处理就算是完成了，就要按照原路再走回去，还是要经过许多的路由器、网关、代理。如果这个资源允许缓存，那么经过 CDN 的时候它也会做缓存，这样下次同样的请求就不会到达源站了。
• 最后网站的响应数据回到了你的设备，它可能是 HTML、JSON、图片或者其他格式的数据，需要由浏览器解析处理才能显示出来，如果数据里面还有超链接，指向别的资源，那么就又要重走一遍整个流程，直到所有的资源都下载完。

总结

• HTTP 协议基于底层的 TCP/IP 协议，所以必须要用 IP 地址建立连接；
• 如果不知道 IP 地址，就要用 DNS 协议去解析得到 IP 地址，否则就会连接失败；
• 建立 TCP 连接后会顺序收发数据，请求方和应答方都必须依据 HTTP 规范构建和解析报文；
• 为了减少响应时间，整个过程中的每一个环节都会有缓存，能够实现“短路”操作；
• 虽然现实中的 HTTP 传输过程非常复杂，但理论上仍然可以简化成实验里的“两点”模型。

现在浏览器通常都会自动且秘密的发送 favicon.ico 请求

Http 协议核心 - 报文结构

报文的基本结构

HTTP 协议的请求报文和响应报文的结构基本相同，由三大部分组成：

• 起始行（start line）：描述请求或响应的基本信息；
• 头部字段集合（header）：使用 key-value 形式更详细地说明报文；
• 消息正文（entity）：实际传输的数据，它不一定是纯文本，可以是图片、视频等二进制数据。

这其中前两部分起始行和头部字段经常又合称为“请求头”或“响应头”，消息正文又称为“实体”，但与“header”对应，很多时候就直接称为“body”。
HTTP 协议规定报文必须有 header，但可以没有 body，而且在 header 之后必须要有一个“空行”，也就是“CRLF”，十六进制的“0D0A”。
如下图所示：

eg (请求报文):

• 第一行“GET / HTTP/1.1”就是请求行
• “Host”“Connection”等等都属于 header
• 报文的最后是一个空白行结束，没有 body。

请求行(请求报文)

请求行描述了客户端想要如何操作服务器端的资源，由三部分构成：

• 请求方法：是一个动词，如 GET/POST，表示对资源的操作；
• 请求目标：通常是一个 URI，标记了请求方法要操作的资源；
• 版本号：表示报文使用的 HTTP 协议版本。

这三个部分通常使用空格（space）来分隔，最后要用 CRLF 换行表示结束。

eg ： GET / HTTP/1.1

状态行(响应报文)

即服务器响应的状态，三部分组成：

• 版本号：表示报文使用的 HTTP 协议版本；
• 状态码：一个三位数，用代码的形式表示处理的结果，比如 200 是成功，500 是服务器错误；
• 原因：作为数字状态码补充，是更详细的解释文字，帮助人理解原因。

eg :

HTTP/1.1 200 OK
HTTP/1.1 404 Not Found

头部字段

请求行或状态行再加上头部字段集合就构成了 HTTP 报文里完整的请求头或响应头：

• 请求头和响应头的结构是基本一样的，唯一的区别是起始行
• 头部字段是 key-value 的形式，key 和 value 之间用“:”分隔，最后用 CRLF 换行表示字段结束。
• HTTP 头字段非常灵活，不仅可以使用标准里的 Host、Connection 等已有头，也可以任意添加自定义头

使用头字段需要注意下面几点：

• 字段名不区分大小写，例如“Host”也可以写成“host”，但首字母大写的可读性更好；
• 字段名里不允许出现空格，可以使用连字符“-”，但不能使用下划线“_”。
• 字段名后面必须紧接着“:”，不能有空格，而“:”后的字段值前可以有多个空格；
• 字段的顺序是没有意义的，可以任意排列不影响语义；
• 字段原则上不能重复，除非这个字段本身的语义允许，例如 Set-Cookie。

常用头字段

• 通用字段：在请求头和响应头里都可以出现；
• 请求字段：仅能出现在请求头里，进一步说明请求信息或者额外的附加条件；
• 响应字段：仅能出现在响应头里，补充说明响应报文的信息；
• 实体字段：它实际上属于通用字段，但专门描述 body 的额外信息。

eg :

• Host字段，它属于请求字段，只能出现在请求头里，它同时也是唯一一个 HTTP/1.1 规范里要求必须出现的字段，也就是说，如果请求头里没有 Host，那这就是一个错误的报文。
• User-Agent是请求字段，只出现在请求头里。它使用一个字符串来描述发起 HTTP 请求的客户端，服务器可以依据它来返回最合适此浏览器显示的页面；但由于历史的原因，User-Agent 非常混乱，每个浏览器都自称是“Mozilla”“Chrome”“Safari”，企图使用这个字段来互相“伪装”，导致 User-Agent 变得越来越长，最终变得毫无意义
• Date字段是一个通用字段，但通常出现在响应头里，表示 HTTP 报文创建的时间，客户端可以使用这个时间再搭配其他字段决定缓存策略。
• Server字段是响应字段，只能出现在响应头里。它告诉客户端当前正在提供 Web 服务的软件名称和版本号。不是必须要出现的，因为这会把服务器的一部分信息暴露给外界，如果这个版本恰好存在 bug，那么黑客就有可能利用 bug 攻陷服务器
• 实体字段Content-Length，它表示报文里 body 的长度，也就是请求头或响应头空行后面数据的长度。服务器看到这个字段，就知道了后续有多少数据，可以直接接收。如果没有这个字段，那么 body 就是不定长的，需要使用 chunked 方式分段传输。

总结

• HTTP 报文结构就像是“大头儿子”，由“起始行 + 头部 + 空行 + 实体”组成，简单地说就是“header+body”；
• HTTP 报文可以没有 body，但必须要有 header，而且 header 后也必须要有空行，形象地说就是“大头”必须要带着“脖子”；
• 请求头由“请求行 + 头部字段”构成，响应头由“状态行 + 头部字段”构成；
• 请求行有三部分：请求方法，请求目标和版本号；
• 状态行也有三部分：版本号，状态码和原因字符串；
• 头部字段是 key-value 的形式，用“:”分隔，不区分大小写，顺序任意，除了规定的标准头，也可以任意添加自定义字段，实现功能扩展；
• HTTP/1.1 里唯一要求必须提供的头字段是 Host，它必须出现在请求头里，标记虚拟主机名。

请求头 - 请求方法

标准请求方法

目前 HTTP/1.1 规定了八种方法，单词都必须是大写的形式：

• GET：获取资源，可以理解为读取或者下载数据；
• HEAD：获取资源的元信息；
• POST：向资源提交数据，相当于写入或上传数据；
• PUT：类似 POST；
• DELETE：删除资源；
• CONNECT：建立特殊的连接隧道；
• OPTIONS：列出可对资源实行的方法；
• TRACE：追踪请求 - 响应的传输路径。

请求方法详解

• GET：从服务器获取资源，搭配 URI 和其他头字段就能实现对资源更精细的操作。例如，在 URI 后使用“#”，就可以在获取页面后直接定位到某个标签所在的位置；使用 If-Modified-Since 字段就变成了“有条件的请求”，仅当资源被修改时才会执行获取动作；使用 Range 字段就是“范围请求”，只获取资源的一部分数据。
• HEAD：与 GET 方法类似，也是请求从服务器获取资源，服务器的处理机制也是一样的，但服务器不会返回请求的实体数据，只会传回响应头，也就是资源的“元信息”。
• POST：通常表示的是”新建“、 “create”的含义。
• PUT： “修改”“、update”的含义。
• DELETE方法指示服务器删除资源，因为这个动作危险性太大，所以通常服务器不会执行真正的删除操作，而是对资源做一个删除标记。当然，更多的时候服务器就直接不处理 DELETE 请求。
• CONNECT是一个比较特殊的方法，要求服务器为客户端和另一台远程服务器建立一条特殊的连接隧道，这时 Web 服务器在中间充当了代理的角色.
• OPTIONS方法要求服务器列出可对资源实行的操作方法，在响应头的 Allow 字段里返回。它的功能很有限，用处也不大，有的服务器（例如 Nginx）干脆就没有实现对它的支持。主要功能有两个：
  • 获取服务器支持的HTTP请求方法；也是黑客经常使用的方法。
  • 用来检查服务器的性能。例如：AJAX进行跨域请求时的预检，需要向另外一个域名的资源发送一个HTTP OPTIONS请求头，用以判断实际发送的请求是否安全。
• TRACE方法多用于对 HTTP 链路的测试或诊断，可以显示出请求 - 响应的传输路径。它的本意是好的，但存在漏洞，会泄漏网站的信息，所以 Web 服务器通常也是禁止使用。

扩展方法

虽然 HTTP/1.1 里规定了八种请求方法，但它并没有限制我们只能用这八种方法，这也体现了 HTTP 协议良好的扩展性，我们可以任意添加请求动作，只要请求方和响应方都能理解就行。例如著名的愚人节玩笑 RFC2324

安全与幂等

• “安全”是指请求方法不会“破坏”服务器上的资源，即不会对服务器上的资源造成实质的修改。

  • 按照这个定义，只有 GET 和 HEAD 方法是“安全”的

• “幂等”实际上是一个数学用语，被借用到了 HTTP 协议里，意思是多次执行相同的操作，结果也都是相同的，即多次“幂”后结果“相等”

  • GET 和 HEAD 既是安全的也是幂等的，DELETE 可以多次删除同一个资源，效果都是“资源不存在”，所以也是幂等的；
  • POST 是“新增或提交数据”，多次提交数据会创建多个资源，所以不是幂等的；而 PUT 是“替换或更新数据”，多次更新一个资源，资源还是会第一次更新的状态，所以是幂等的。

小结

• 请求方法是客户端发出的、要求服务器执行的、对资源的一种操作；
• 请求方法是对服务器的“指示”，真正应如何处理由服务器来决定；
• 最常用的请求方法是 GET 和 POST，分别是获取数据和发送数据；
• HEAD 方法是轻量级的 GET，用来获取资源的元信息；
• PUT 基本上是 POST 的同义词，多用于更新数据；
• “安全”与“幂等”是描述请求方法的两个重要属性，具有理论指导意义，可以帮助我们设计系统。
  

URI

URI，也就是统一资源标识符（Uniform Resource Identifier）。因为它经常出现在浏览器的地址栏里，所以俗称为“网络地址”，简称“网址”。包含两部分：

• URL：统一资源定位符（Uniform Resource Locator）
• URN：统一资源名称（英语：Uniform Resource Name，缩写：URN）

URI 的完整格式

• 第一个多出的部分是协议名之后、主机名之前的身份信息“user:passwd@”，表示登录主机时的用户名和密码，但现在已经不推荐使用这种形式了（RFC7230），因为它把敏感信息以明文形式暴露出来，存在严重的安全隐患。
• 第二个多出的部分是查询参数后的片段标识符“#fragment”，它是 URI 所定位的资源内部的一个“锚点”或者说是“标签”，浏览器可以在获取资源后直接跳转到它指示的位置。

URI 的编码

直接把非 ASCII 码或特殊字符转换成十六进制字节值，然后前面再加上一个“%”

小结

• URI 是用来唯一标记服务器上资源的一个字符串，通常也称为 URL；
• URI 通常由 scheme、host:port、path 和 query 四个部分组成，有的可以省略；
• scheme 叫“方案名”或者“协议名”，表示资源应该使用哪种协议来访问；
• “host:port”表示资源所在的主机名和端口号；
• path 标记资源所在的位置；
• query 表示对资源附加的额外要求；
• 在 URI 里对“@&/”等特殊字符和汉字必须要做编码，否则服务器收到 HTTP 报文后会无法正确处理。

状态码

• 1××：提示信息，表示目前是协议处理的中间状态，还需要后续的操作；
  • 如：“101 Switching Protocols”。它的意思是客户端使用 Upgrade 头字段，要求在 HTTP 协议的基础上改成其他的协议继续通信，比如 WebSocket。而如果服务器也同意变更协议，就会发送状态码 101，但这之后的数据传输就不会再使用 HTTP 了。
• 2××：成功，报文已经收到并被正确处理；
  • “204 No Content”是另一个很常见的成功状态码，它的含义与“200 OK”基本相同，但响应头后没有 body 数据。
  • “206 Partial Content”是 HTTP 分块下载或断点续传的基础，在客户端发送“范围请求”、要求获取资源的部分数据时出现，它与 200 一样，也是服务器成功处理了请求，但 body 里的数据不是资源的全部，而是其中的一部分。
• 3××：重定向，资源位置发生变动，需要客户端重新发送请求；
  • “301 Moved Permanently”俗称“永久重定向”，含义是此次请求的资源已经不存在了，需要改用改用新的 URI 再次访问。
  • 与它类似的是“302 Found”，曾经的描述短语是“Moved Temporarily”，俗称“临时重定向”，意思是请求的资源还在，但需要暂时用另一个 URI 来访问。浏览器看到这个 302 就知道这只是暂时的情况，不会做缓存优化。
  • “304 Not Modified” 是一个比较有意思的状态码，它用于 If-Modified-Since 等条件请求，表示资源未修改，用于缓存控制。它不具有通常的跳转含义，但可以理解成“重定向已到缓存的文件”（即“缓存重定向”）。
• 4××：客户端错误，请求报文有误，服务器无法处理；
  • “400 Bad Request”是一个通用的错误码，表示请求报文有错误，但具体是数据格式错误、缺少请求头还是 URI 超长它没有明确说，只是一个笼统的错误
  • “403 Forbidden”实际上不是客户端的请求出错，而是表示服务器禁止访问资源。
  • “404 Not Found”可能是我们最常看见也是最不愿意看到的一个状态码，它的原意是资源在本服务器上未找到，所以无法提供给客户端。
  • 405 Method Not Allowed：不允许使用某些方法操作资源，例如不允许 POST 只能 GET；
  • 406 Not Acceptable：资源无法满足客户端请求的条件，例如请求中文但只有英文；
  • 408 Request Timeout：请求超时，服务器等待了过长的时间；
  • 409 Conflict：多个请求发生了冲突，可以理解为多线程并发时的竞态；
  • 413 Request Entity Too Large：请求报文里的 body 太大；
  • 414 Request-URI Too Long：请求行里的 URI 太大；
  • 429 Too Many Requests：客户端发送了太多的请求，通常是由于服务器的限连策略；
  • 431 Request Header Fields Too Large：请求头某个字段或总体太大；
• 5××：服务器错误，服务器在处理请求时内部发生了错误。
  • “500 Internal Server Error”与 400 类似，也是一个通用的错误码，服务器究竟发生了什么错误我们是不知道的。
  • “501 Not Implemented”表示客户端请求的功能还不支持
  • “502 Bad Gateway”通常是服务器作为网关或者代理时返回的错误码，表示服务器自身工作正常，访问后端服务器时发生了错误
  • “503 Service Unavailable”表示服务器当前很忙，暂时无法响应服务，我们上网时有时候遇到的“网络服务正忙，请稍后重试”的提示信息就是状态码 503

小结

• 状态码在响应报文里表示了服务器对请求的处理结果；
• 状态码后的原因短语是简单的文字描述，可以自定义；
• 状态码是十进制的三位数，分为五类，从 100 到 599；
• 2××类状态码表示成功，常用的有 200、204、206；
• 3××类状态码表示重定向，常用的有 301、302、304；
• 4××类状态码表示客户端错误，常用的有 400、403、404；
• 5××类状态码表示服务器错误，常用的有 500、501、502、503。

HTTP特点

• 灵活可扩展
• 可靠传输
• 应用层协议
• 请求 - 应答
• 无状态

小结

• HTTP 是灵活可扩展的，可以任意添加头字段实现任意功能；
• HTTP 是可靠传输协议，基于 TCP/IP 协议“尽量”保证数据的送达；
• HTTP 是应用层协议，比 FTP、SSH 等更通用功能更多，能够传输任意数据；
• HTTP 使用了请求 - 应答模式，客户端主动发起请求，服务器被动回复请求；
• HTTP 本质上是无状态的，每个请求都是互相独立、毫无关联的，协议不要求客户端或服务器记录请求相关的信息。
  

HTTP优缺点

• 简单、灵活、易于扩展
• 应用广泛、环境成熟
• 无状态
• 明文传输，对比 TCP、UDP 这样的二进制协议，它的优点显而易见，不需要借助任何外部工具，用浏览器、Wireshark 或者 tcpdump 抓包后，直接用肉眼就可以很容易地查看或者修改。明文的缺点也是一样显而易见，HTTP 报文的所有信息都会暴露在“光天化日之下”，在漫长的传输链路的每一个环节上都毫无隐私可言，不怀好意的人只要侵入了这个链路里的某个设备，简单地“旁路”一下流量，就可以实现对通信的窥视。
• 不安全，明文只是“机密”方面的一个缺点，在“身份认证”和“完整性校验”这两方面 HTTP 也是欠缺的。
• 性能，HTTP 协议基于 TCP/IP，并且使用了“请求 - 应答”的通信模式，而“请求 - 应答”模式则加剧了 HTTP 的性能问题，这就是著名的“队头阻塞”（Head-of-line blocking），当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一并被阻塞，会导致客户端迟迟收不到数据。

小结

• HTTP 最大的优点是简单、灵活和易于扩展；
• HTTP 拥有成熟的软硬件环境，应用的非常广泛，是互联网的基础设施；
• HTTP 是无状态的，可以轻松实现集群化，扩展性能，但有时也需要用 Cookie 技术来实现“有状态”；
• HTTP 是明文传输，数据完全肉眼可见，能够方便地研究分析，但也容易被窃听；
• HTTP 是不安全的，无法验证通信双方的身份，也不能判断报文是否被窜改；
• HTTP 的性能不算差，但不完全适应现在的互联网，还有很大的提升空间。
  

HTTP的实体数据

数据类型与编码

多用途互联网邮件扩展”（Multipurpose Internet Mail Extensions），简称为 MIME。MIME 是一个很大的标准规范，但 HTTP 只“顺手牵羊”取了其中的一部分，用来标记 body 的数据类型，这就是我们平常总能听到的“MIME type”。
HTTP 里经常遇到的几个类别(“MIME type”)：

• text：即文本格式的可读数据，我们最熟悉的应该就是 text/html 了，表示超文本文档，此外还有纯文本 text/plain、样式表 text/css 等。
• image：即图像文件，有 image/gif、image/jpeg、image/png 等。
• audio/video：音频和视频数据，例如 audio/mpeg、video/mp4 等。
• application：数据格式不固定，可能是文本也可能是二进制，必须由上层应用程序来解释。常见的有 application/json，application/javascript、application/pdf 等，另外，如果实在是不知道数据是什么类型，像刚才说的“黑盒”，就会是 application/octet-stream，即不透明的二进制数据。

HTTP 在传输时为了节约带宽，有时候还会压缩数据，为了不要让浏览器继续“猜”，还需要有一个“Encoding type”，告诉数据是用的什么编码格式，这样对方才能正确解压缩，还原出原始的数据。
常用的只有下面三种：

• gzip：GNU zip 压缩格式，也是互联网上最流行的压缩格式；
• deflate：zlib（deflate）压缩格式，流行程度仅次于 gzip；
• br：一种专门为 HTTP 优化的新压缩算法（Brotli）。

数据类型使用的头字段

HTTP 协议为此定义了两个 Accept 请求头字段和两个 Content 实体头字段，用于客户端和服务器进行“内容协商”。

Accept字段标记的是客户端可理解的 MIME type，可以用“,”做分隔符列出多个类型，让服务器有更多的选择余地，例如下面的这个头：

Accept: text/html,application/xml,image/webp,image/png

相应的，服务器会在响应报文里用头字段Content-Type告诉实体数据的真实类型：

Content-Type: text/html
Content-Type: image/png

Accept-Encoding字段标记的是客户端支持的压缩格式，例如上面说的 gzip、deflate 等，同样也可以用“,”列出多个，服务器可以选择其中一种来压缩数据，实际使用的压缩格式放在响应头字段Content-Encoding里。

Accept-Encoding: gzip, deflate, br
Content-Encoding: gzip

不过这两个字段是可以省略的，如果请求报文里没有 Accept-Encoding 字段，就表示客户端不支持压缩数据；如果响应报文里没有 Content-Encoding 字段，就表示响应数据没有被压缩。

语言类型与编码

• 语言类型与字符集 - Unicode 和 UTF-8
• 遵循 UTF-8 字符编码方式的 Unicode 字符集成为了互联网上的标准字符集。

语言类型使用的头字段

HTTP 协议也使用 Accept 请求头字段和 Content 实体头字段，用于客户端和服务器就语言与编码进行“内容协商”。
Accept-Language字段标记了客户端可理解的自然语言，也允许用“,”做分隔符列出多个类型，例如：

Accept-Language: zh-CN, zh, en

相应的，服务器应该在响应报文里用头字段Content-Language告诉客户端实体数据使用的实际语言类型：

Content-Language: zh-CN

字符集在 HTTP 里使用的请求头字段是Accept-Charset，但响应头里却没有对应的 Content-Charset，而是在Content-Type字段的数据类型后面用“charset=xxx”来表示，这点需要特别注意。
例如，浏览器请求 GBK 或 UTF-8 的字符集，然后服务器返回的是 UTF-8 编码，就是下面这样：

Accept-Charset: gbk, utf-8
Content-Type: text/html; charset=utf-8

不过现在的浏览器都支持多种字符集，通常不会发送 Accept-Charset，而服务器也不会发送 Content-Language，因为使用的语言完全可以由字符集推断出来，所以在请求头里一般只会有 Accept-Language 字段，响应头里只会有 Content-Type 字段。

内容协商的质量值

在 HTTP 协议里用 Accept、Accept-Encoding、Accept-Language 等请求头字段进行内容协商的时候，还可以用一种特殊的“q”参数表示权重来设定优先级，这里的“q”是“quality factor”的意思。
权重的最大值是 1，最小值是 0.01，默认值是 1，如果值是 0 就表示拒绝。具体的形式是在数据类型或语言代码后面加一个“;”，然后是“q=value”。
eg:

Accept: text/html,application/xml;q=0.9,*/*;q=0.8

它表示浏览器最希望使用的是 HTML 文件，权重是 1，其次是 XML 文件，权重是 0.9，最后是任意数据类型，权重是 0.8。服务器收到请求头后，就会计算权重，再根据自己的实际情况优先输出 HTML 或者 XML。HTTP “,” 的断句语气要强于";"。

内容协商的结果

内容协商的过程是不透明的，每个 Web 服务器使用的算法都不一样。但有的时候，服务器会在响应头里多加一个Vary字段，记录服务器在内容协商时参考的请求头字段，给出一点信息，例如：

Vary: Accept-Encoding,User-Agent,Accept

这个 Vary 字段表示服务器依据了 Accept-Encoding、User-Agent 和 Accept 这三个头字段，然后决定了发回的响应报文。Vary 字段可以认为是响应报文的一个特殊的“版本标记”。每当 Accept 等请求头变化时，Vary 也会随着响应报文一起变化。也就是说，同一个 URI 可能会有多个不同的“版本”，主要用在传输链路中间的代理服务器实现缓存服务。

小结

• 数据类型表示实体数据的内容是什么，使用的是 MIME type，相关的头字段是 Accept 和 Content-Type；
• 数据编码表示实体数据的压缩方式，相关的头字段是 Accept-Encoding 和 Content-Encoding；
• 语言类型表示实体数据的自然语言，相关的头字段是 Accept-Language 和 Content-Language；
• 字符集表示实体数据的编码方式，相关的头字段是 Accept-Charset 和 Content-Type；
• 客户端需要在请求头里使用 Accept 等头字段与服务器进行“内容协商”，要求服务器返回最合适的数据；
• Accept 等头字段可以用“,”顺序列出多个可能的选项，还可以用“;q=”参数来精确指定权重。
• content-*字段也可以用在请求报文里，说明请求体的数据类型。

HTTP传输大文件

数据压缩

通常浏览器在发送请求时都会带着“Accept-Encoding”头字段，里面是浏览器支持的压缩格式列表，例如 gzip、deflate、br 等，这样服务器就可以从中选择一种压缩算法，放进“Content-Encoding”响应头里，再把原数据压缩后发给浏览器。
缺点是gzip 等压缩算法通常只对文本文件有较好的压缩率，而图片、音频视频等多媒体数据本身就已经是高度压缩的。
例如，在 Nginx 里就会使用“gzip on”指令，启用对“text/html”的压缩。

分块传输

在 HTTP 协议里就是“chunked”分块传输编码，在响应报文里用头字段“Transfer-Encoding: chunked”来表示，意思是报文里的 body 部分不是一次性发过来的，而是分成了许多的块（chunk）逐个发送。
“Transfer-Encoding: chunked”和“Content-Length”这两个字段是互斥的，也就是说响应报文里这两个字段不能同时出现，一个响应报文的传输要么是长度已知，要么是长度未知（chunked）。

分块传输的编码规则：

• 每个分块包含两个部分，长度头和数据块；
• 长度头是以 CRLF（回车换行，即\r\n）结尾的一行明文，用 16 进制数字表示长度；
• 数据块紧跟在长度头后，最后也用 CRLF 结尾，但数据不包含 CRLF；
• 最后用一个长度为 0 的块表示结束，即“0\r\n\r\n”。

范围请求

范围请求不是 Web 服务器必备的功能，可以实现也可以不实现，所以服务器必须在响应头里使用字段“Accept-Ranges: bytes”明确告知客户端：“我是支持范围请求的”。
服务器可以发送“Accept-Ranges: none”，或者干脆不发送“Accept-Ranges”字段，这样客户端就认为服务器没有实现范围请求功能。
请求头Range是 HTTP 范围请求的专用字段，格式是“bytes=x-y”，其中的 x 和 y 是以字节为单位的数据范围。x、y 表示的是“偏移量”，范围必须从 0 计数，如前 10 个字节表示为“0-9”。
服务器收到 Range 字段后，需要做四件事：

• 第一，它必须检查范围是否合法，比如文件只有 100 个字节，但请求“200-300”，这就是范围越界了。服务器就会返回状态码416，意思是“你的范围请求有误，我无法处理，请再检查一下”。
• 第二，如果范围正确，服务器就可以根据 Range 头计算偏移量，读取文件的片段了，返回状态码“206 Partial Content”，和 200 的意思差不多，但表示 body 只是原数据的一部分。
• 第三，服务器要添加一个响应头字段Content-Range，告诉片段的实际偏移量和资源的总大小，格式是“bytes x-y/length”，与 Range 头区别在没有“=”，范围后多了总长度。例如，对于“0-10”的范围请求，值就是“bytes 0-10/100”。
• 最后剩下的就是发送数据了，直接把片段用 TCP 发给客户端，一个范围请求就算是处理完了。

不仅看视频的拖拽进度需要范围请求，常用的下载工具里的多段下载、断点续传也是基于它实现的，要点是：

• 先发个 HEAD，看服务器是否支持范围请求，同时获取文件的大小；
• 开 N 个线程，每个线程使用 Range 字段划分出各自负责下载的片段，发请求传输数据；
• 下载意外中断也不怕，不必重头再来一遍，只要根据上次的下载记录，用 Range 请求剩下的那一部分就可以了。

多段数据

范围请求还支持在 Range 头里使用多个“x-y”，一次性获取多个片段数据。
这种情况需要使用一种特殊的 MIME 类型：“multipart/byteranges”，表示报文的 body 是由多段字节序列组成的，并且还要用一个参数“boundary=xxx”给出段之间的分隔标记。

每一个分段必须以“- -boundary”开始（前面加两个“-”），之后要用“Content-Type”和“Content-Range”标记这段数据的类型和所在范围，然后就像普通的响应头一样以回车换行结束，再加上分段数据，最后用一个“- -boundary- -”（前后各有两个“-”）表示所有的分段结束。

如：

GET /16-2 HTTP/1.1
Host: www.chrono.com
Range: bytes=0-9, 20-29

HTTP/1.1 206 Partial Content
Content-Type: multipart/byteranges; boundary=00000000001
Content-Length: 189
Connection: keep-alive
Accept-Ranges: bytes


--00000000001
Content-Type: text/plain
Content-Range: bytes 0-9/96

// this is
--00000000001
Content-Type: text/plain
Content-Range: bytes 20-29/96

ext json d
--00000000001--

小结

• 压缩 HTML 等文本文件是传输大文件最基本的方法；
• 分块传输可以流式收发数据，节约内存和带宽，使用响应头字段“Transfer-Encoding: chunked”来表示，分块的格式是 16 进制长度头 + 数据块；
• 范围请求可以只获取部分数据，即“分块请求”，实现视频拖拽或者断点续传，使用请求头字段“Range”和响应头字段“Content-Range”，响应状态码必须是 206；
• 也可以一次请求多个范围，这时候响应报文的数据类型是“multipart/byteranges”，body 里的多个部分会用 boundary 字符串分隔。

要注意这四种方法不是互斥的，而是可以混合起来使用，例如压缩后再分块传输，或者分段后再分块。

HTTP 的连接管理

长连接和短链接

Http/1.1 默认长连接。

Http协议基于tcp协议，短连接相较于长连接，每次http请求都需要建立新的tcp连接，所以耗时长，性能不佳。

连接相关的头字段

"Connection: keep-alive”：如果服务器支持长连接，它总会在响应报文里放一个“Connection: keep-alive”字段。

长连接的缺点：因为 TCP 连接长时间不关闭，服务器必须在内存里保存它的状态，这就占用了服务器的资源。如果有大量的空闲长连接只连不发，就会很快耗尽服务器的资源，导致服务器无法为真正有需要的用户提供服务。

关闭长连接的一些方法：

• 在客户端，可以在请求头里加上“Connection: close”字段；
• 服务器端通常不会主动关闭连接，但也可以使用一些策略。拿 Nginx 来举例，它有两种方式：
  • 使用“keepalive_timeout”指令，设置长连接的超时时间，如果在一段时间内连接上没有任何数据收发就主动断开连接，避免空闲连接占用系统资源。
  • 使用“keepalive_requests”指令，设置长连接上可发送的最大请求次数。比如设置成 1000，那么当 Nginx 在这个连接上处理了 1000 个请求后，也会主动断开连接。
• 客户端和服务器都可以在报文里附加通用头字段“Keep-Alive: timeout=value”，限定长连接的超时时间。但这个字段的约束力并不强，通信的双方可能并不会遵守，所以不太常见。

队头阻塞

“队头阻塞”与短连接和长连接无关，而是由 HTTP 基本的“请求 - 应答”模型所导致的。

性能优化

因为“请求 - 应答”模型不能变，所以“队头阻塞”问题在 HTTP/1.1 里无法解决，只能缓解。

• 并发连接”：客户端同时对一个域名发起多个长连接，用数量来解决质量的问题。
• 域名分片”：用数量来解决质量，多个域名指向同一个服务器，请求指向多个域名中的一个，这样也可以建立 tcp 长连接而不影响服务器的性能。

小结

• 早期的 HTTP 协议使用短连接，收到响应后就立即关闭连接，效率很低；
• HTTP/1.1 默认启用长连接，在一个连接上收发多个请求响应，提高了传输效率；
• 服务器会发送“Connection: keep-alive”字段表示启用了长连接；
• 报文头里如果有“Connection: close”就意味着长连接即将关闭；
• 过多的长连接会占用服务器资源，所以服务器会用一些策略有选择地关闭长连接；
• “队头阻塞”问题会导致性能下降，可以用“并发连接”和“域名分片”技术缓解。
  

HTTP 的重定向和跳转

• 重定向是服务器发起的跳转，要求客户端改用新的 URI 重新发送请求，通常会自动进行，用户是无感知的
• 301/302 是最常用的重定向状态码，分别是“永久重定向”和“临时重定向”, 301会通知浏览器和搜索引擎更新到新地址，这也是搜索引擎优化（SEO）要考虑的因素之一；
• 响应头字段 Location 指示了要跳转的 URI，可以用绝对或相对的形式，没有值会找不到资源而报错；
• 重定向可以把一个 URI 指向另一个 URI，也可以把多个 URI 指向同一个 URI，用途很多；
• 使用重定向时需要当心性能损耗，还要避免出现循环跳转。
• 重定向的用途比如：sso
  
  

HTTP的Cookie机制

小结

• Cookie 是服务器委托浏览器存储的一些数据，让服务器有了“记忆能力”；
• 响应报文使用 Set-Cookie 字段发送“key=value”形式的 Cookie 值；
• 请求报文里用 Cookie 字段发送多个 Cookie 值；
• 为了保护 Cookie，还要给它设置有效期、作用域等属性，常用的有 Max-Age、Expires、Domain、HttpOnly 等；
  • Expires、Max-Age，浏览器会优先采用 Max-Age 计算失效期
  • “Domain”和“Path”指定了 Cookie 所属的域名和路径，浏览器在发送 Cookie 前会从 URI 中提取出 host 和 path 部分，对比 Cookie 的属性。如果不满足条件，就不会在请求头里发送 Cookie。
  • 属性“HttpOnly”会告诉浏览器，此 Cookie 只能通过浏览器 HTTP 协议传输，禁止其他方式访问，浏览器的 JS 引擎就会禁用 document.cookie 等一切相关的 API，脚本攻击也就无从谈起了。
• Cookie 最基本的用途是身份识别，实现有状态的会话事务。

Cookie 并不属于 HTTP 标准（RFC6265，而不是 RFC2616/7230），所以语法上与其他字段不太一致，使用的分隔符是“;”，与 Accept 等字段的“,”不同

HTTP 缓存控制

服务器的缓存控制

一个 HTTP 请求：

• 浏览器发现缓存无数据，于是发送请求，向服务器获取资源；
• 服务器响应请求，返回资源，同时标记资源的有效期；
• 浏览器缓存资源，等待下次重用。
  
  服务器缓存控制策略：
  

客户端的缓存控制

• ”Cache-Control: max-age=0”
• “Cache-Control: no-cache“等

条件请求

条件请求一共有 5 个头字段，我们最常用的是“if-Modified-Since”和“If-None-Match”这两个。需要第一次的响应报文预先提供“Last-modified”和“ETag”，然后第二次请求时就可以带上缓存里的原值，验证资源是否是最新的。
如果资源没有变，服务器就回应一个“304 Not Modified”，表示缓存依然有效，浏览器就可以更新一下有效期，然后放心大胆地使用缓存了。

小结

• 缓存是优化系统性能的重要手段，HTTP 传输的每一个环节中都可以有缓存；
• 服务器使用“Cache-Control”设置缓存策略，常用的是“max-age”，表示资源的有效期； max-age 是“生存时间”（又叫“新鲜度”“缓存寿命”，类似 TTL，Time-To-Live），时间的计算起点是响应报文的创建时刻（即 Date 字段，也就是离开服务器的时刻），而不是客户端收到报文的时刻，也就是说包含了在链路传输过程中所有节点所停留的时间。除了 max-age 在响应报文里还可以用其他的属性来更精确地指示浏览器应该如何使用缓存：
  • no-store：不允许缓存，用于某些变化非常频繁的数据，例如秒杀页面；
  • no-cache：它的字面含义容易与 no-store 搞混，实际的意思并不是不允许缓存，而是可以缓存，但在使用之前必须要去服务器验证是否过期，是否有最新的版本；
  • must-revalidate：又是一个和 no-cache 相似的词，它的意思是如果缓存不过期就可以继续使用，但过期了如果还想用就必须去服务器验证。
• 浏览器收到数据就会存入缓存，如果没过期就可以直接使用，过期就要去服务器验证是否仍然可用；
• 验证资源是否失效需要使用“条件请求”，常用的是“if-Modified-Since”和“If-None-Match”，收到 304 就可以复用缓存里的资源；
• 验证资源是否被修改的条件有两个：“Last-modified”和“ETag”，需要服务器预先在响应报文里设置，搭配条件请求使用；
• 浏览器也可以发送“Cache-Control”字段，使用“max-age=0”或“no_cache”刷新数据。
  
  

HTTP的代理服务

代理服务

“代理服务”就是指服务本身不生产内容，而是处于中间位置转发上下游的请求和响应，具有双重身份：面向下游的用户时，表现为服务器，代表源服务器响应客户端的请求；而面向上游的源服务器时，又表现为客户端，代表客户端发送请求。

代理的作用

• 负载均衡
  
• 健康检查：使用“心跳”等机制监控后端服务器，发现有故障就及时“踢出”集群，保证服务高可用；
• 安全防护：保护被代理的后端服务器，限制 IP 地址或流量，抵御网络攻击和过载；
• 加密卸载：对外网使用 SSL/TLS 加密通信认证，而在安全的内网不加密，消除加解密成本；
• 数据过滤：拦截上下行的数据，任意指定策略修改请求或者响应；
• 内容缓存：暂存、复用服务器响应。

代理相关头字段

• Via，每当报文经过一个代理节点，代理服务器就会把自身的信息追加到字段的末尾。
  
• “X-Forwarded-For”,形式上和“Via”差不多，也是每经过一个代理节点就会在字段里追加一个信息。但“Via”追加的是代理主机名（或者域名），而“X-Forwarded-For”追加的是请求方的 IP 地址。所以，在字段里最左边的 IP 地址就客户端的地址。
• “X-Real-IP”是另一种获取客户端真实 IP 的手段，它的作用很简单，就是记录客户端 IP 地址，没有中间的代理信息，相当于是“X-Forwarded-For”的简化版。如果客户端和源服务器之间只有一个代理，那么这两个字段的值就是相同的。

代理协议

因为通过“X-Forwarded-For”操作代理信息必须要解析 HTTP 报文头，这对于代理来说成本比较高；“X-Forwarded-For”等头必须要修改原始报文，而有些情况下是不允许甚至不可能的（比如使用 HTTPS 通信被加密）。

所以就出现了一个专门的“代理协议”（The PROXY protocol），它由知名的代理软件 HAProxy 所定义，也是一个“事实标准”，被广泛采用（注意并不是 RFC）。

“代理协议”有 v1 和 v2 两个版本，v1 和 HTTP 差不多，也是明文，而 v2 是二进制格式。今天只介绍比较好理解的 v1，它在 HTTP 报文前增加了一行 ASCII 码文本，相当于又多了一个头。这一行文本其实非常简单，开头必须是“PROXY”五个大写字母，然后是“TCP4”或者“TCP6”，表示客户端的 IP 地址类型，再后面是请求方地址、应答方地址、请求方端口号、应答方端口号，最后用一个回车换行（\r\n）结束。

例如下面的这个例子，在 GET 请求行前多出了 PROXY 信息行，客户端的真实 IP 地址是“1.1.1.1”，端口号是 55555。

PROXY TCP4 1.1.1.1 2.2.2.2 55555 80\r\n
GET / HTTP/1.1\r\n
Host: www.xxx.com\r\n
\r\n

小结

• HTTP 代理就是客户端和服务器通信链路中的一个中间环节，为两端提供“代理服务”；
• 代理处于中间层，为 HTTP 处理增加了更多的灵活性，可以实现负载均衡、安全防护、数据过滤等功能；
• 代理服务器需要使用字段“Via”标记自己的身份，多个代理会形成一个列表；如果想要知道客户端的真实 IP 地址，
• 可以使用字段“X-Forwarded-For”和“X-Real-IP”；
• 专门的“代理协议”可以在不改动原始报文的情况下传递客户端的真实 IP。
• 常见的负载均衡算法
  • 随机
  • 轮询
  • 一致性hash
  • 最近最少使用
  • 链接最少
    

HTTP的缓存代理

HTTP 的服务器缓存功能主要由代理服务器来实现（即缓存代理）。

缓存代理服务

源服务器的缓存控制

服务器端的“Cache-Control”属性：max-age、no-store、no-cache 和 must-revalidate，这 4 种缓存属性可以约束客户端，也可以约束代理。
代理的一些约束属性：

• private”和“public”，“private”表示缓存只能在客户端保存，是用户“私有”的，不能放在代理上与别人共享。而“public”的意思就是缓存完全开放，谁都可以存，谁都可以用。
• 缓存失效后的重新验证也要区分开（即使用条件请求“Last-modified”和“ETag”），“must-revalidate”是只要过期就必须回源服务器验证，而新的“proxy-revalidate”只要求代理的缓存过期后必须验证，客户端不必回源，只验证到代理这个环节就行了。
• 缓存的生存时间可以使用新的“s-maxage”（s 是 share 的意思，注意 maxage 中间没有“-”），只限定在代理上能够存多久，而客户端仍然使用“max-age”。
• “no-transform”。代理有时候会对缓存下来的数据做一些优化，比如把图片生成 png、webp 等几种格式，方便今后的请求处理，而“no-transform”就会禁止这样做。

下面的流程图是完整的服务器端缓存控制策略，可以同时控制客户端和代理：

客户端的缓存控制

• “max-stale”的意思是如果代理上的缓存过期了也可以接受，但不能过期太多，超过 x 秒也会不要。
• “min-fresh”的意思是缓存必须有效，而且必须在 x 秒后依然有效。
• “only-if-cached”属性，表示只接受代理缓存的数据，不接受源服务器的响应。如果代理上没有缓存或者缓存过期，就应该给客户端返回一个 504（Gateway Timeout）。

其他问题

• 第一个是“Vary”字段，同一个请求，经过内容协商后可能会有不同的字符集、编码、浏览器等版本。比如，“Vary: Accept-Encoding”“Vary: User-Agent”，缓存代理必须要存储这些不同的版本。当再收到相同的请求时，代理就读取缓存里的“Vary”，对比请求头里相应的“ Accept-Encoding”“User-Agent”等字段，如果和上一个请求的完全匹配，比如都是“gzip”“Chrome”，就表示版本一致，可以返回缓存的数据。
• 另一个问题是“Purge”，也就是“缓存清理”，它对于代理也是非常重要的功能，例如：
  • 过期的数据应该及时淘汰，避免占用空间；
  • 源站的资源有更新，需要删除旧版本，主动换成最新版（即刷新）；
  • 有时候会缓存了一些本不该存储的信息，例如网络谣言或者危险链接，必须尽快把它们删除。

清理缓存的方法有很多，比较常用的一种做法是使用自定义请求方法“PURGE”，发给代理服务器，要求删除 URI 对应的缓存数据。

小结

• 计算机领域里最常用的性能优化手段是“时空转换”，也就是“时间换空间”或者“空间换时间”，HTTP 缓存属于后者；
• 缓存代理是增加了缓存功能的代理服务，缓存源服务器的数据，分发给下游的客户端；
• “Cache-Control”字段也可以控制缓存代理，常用的有“private”“s-maxage”“no-transform”等，同样必须配合“Last-modified”“ETag”等字段才能使用；
• 缓存代理有时候也会带来负面影响，缓存不良数据，需要及时刷新或删除。