状态码
| 整体范围 | 已定义范围 | 分类 |
| 100~199 | 100~101 | 信息提示 |
| 200~299 | 200~206 | 成功 |
| 300~399 | 300~305 | 重定向 |
| 400~499 | 400~415 | 客户端错误 |
| 500~599 | 500~505 | 服务器错误 |
300~399 重定向状态码
重定向状态码要么告诉客户端使用替代位置来访问他们感兴趣的资源，要么提供一个替代的响应而不是资源的内容。 如果资源已被移动，可以发送一个重定向状态码和一个可选的 Location 首部来告知客户端资源已被移走，以及现在在哪里可以找到它。这样，浏览器可以在不打扰使用者的情况下，透明地转入新的位置。
400~499 客户端错误状态码
有时客户端会发送一些服务器无法处理的东西，例如格式错误的请求报文、一个不存在的 URL。
500~599 服务器错误状态码
有时客户端发送了一条有效请求，服务器自身却出错了。
首部
首部和方法共同配合工作，决定了客户端和服务器能做什么事情。
首部分类：
- 通用首部，可以出现在请求或响应报文中。
- 请求首部，提供更多有关请求的信息。
- 响应首部，提供更多有关响应的信息。
- 实体首部，描述主体的长度和内容，或者资源自身。
- 扩展首部，规范中没有定义的新首部。
通用首部
有些首部提供了与报文相关的最基本信息，它们被称为通用首部。以下是一些常见的通用首部：
请求首部
请求首部是只在请求报文中有意义的首部，用于说明请求的详情。以下是一些常见的请求首部：
响应首部
响应首部让服务器为客户端提供了一些额外的信息。
实体首部
实体首部提供了有关实体及其内容的大量信息，从有关对象类型的信息，到能够对资源使用的各种有效的请求方法。
例如内容首部，提供了与实体内容有关的特定信息，说明了其类型、尺寸以及处理它所需的其他有用信息。
另外，通用的缓存首部说明了如何或什么时候进行缓存。实体的缓存首部提供了与被缓存实体有关的信息。
性能优化
1. 减少 HTTP 请求
每发起一个 HTTP 请求，都得经历三次握手建立 TCP 连接，如果连接只用来交换少量数据，这个过程就会严重降低 HTTP 性能。所以我们可以将多个小文件合成一个大文件，从而减少 HTTP 请求次数。
其实由于持久连接（重用 TCP 连接，以消除连接及关闭时延；HTTP/1.1 默认开启持久连接）的存在，每个新请求不一定都需要建立一个新的 TCP 连接。但是，浏览器处理完一个 HTTP 请求才能发起下一个，所以在 TCP 连接数没达到浏览器规定的上限时，还是会建立新的 TCP 连接。从这点来看，减少 HTTP 请求仍然是有必要的。
2. 静态资源使用 CDN
内容分发网络（CDN）是一组分布在多个不同地理位置的 Web 服务器。我们都知道，当服务器离用户越远时，延迟越高。CDN 就是为了解决这一问题，在多个位置部署服务器，让用户离服务器更近，从而缩短请求时间。
3. 善用缓存
为了避免用户每次访问网站都得请求文件，我们可以通过添加 Expires 头来控制这一行为。Expires 设置了一个时间，只要在这个时间之前，浏览器都不会请求文件，而是直接使用缓存。
不过这样会产生一个问题，当文件更新了怎么办？怎么通知浏览器重新请求文件？
可以通过更新页面中引用的资源链接地址，让浏览器主动放弃缓存，加载新资源。
具体做法是把资源地址 URL 的修改与文件内容关联起来，也就是说，只有文件内容变化，才会导致相应 URL 的变更，从而实现文件级别的精确缓存控制。什么东西与文件内容相关呢？我们会很自然的联想到利用数据摘要要算法对文件求摘要信息，摘要信息与文件内容一一对应，就有了一种可以精确到单个文件粒度的缓存控制依据了。
参考资料：
4. 压缩文件
压缩文件可以减少文件下载时间，让用户体验性更好。
gzip 是目前最流行和最有效的压缩方法。可以通过向 HTTP 请求头中的 Accept-Encoding 头添加 gzip 标识来开启这一功能。当然，服务器也得支持这一功能。
举个例子，我用 Vue 开发的项目构建后生成的 app.js 文件大小为 1.4MB，使用 gzip 压缩后只有 573KB，体积减少了将近 60%。
5. 通过 max-age 和 no-cache 实现文件精确缓存
通用消息头部 Cache-Control 其中有两个选项：
max-age: 设置缓存存储的最大周期，超过这个时间缓存被认为过期(单位秒)。在这个时间前，浏览器读取文件不会发出新请求，而是直接使用缓存。no-cache: 指定 no-cache 表示客户端可以缓存资源，每次使用缓存资源前都必须重新验证其有效性。
我们可以将那些长期不变的静态资源设置一个非常长的缓存时间，例如设置成缓存一年。
然后将 index.html 文件设置成 no-cache。这样每次访问网站时，浏览器都会询问 index.html 是否有更新，如果没有，就使用旧的 index.html 文件。如果有更新，就读取新的 index.html 文件。当加载新的 index.html 时，也会去加载里面新的 URL 资源。
例如 index.html 原来引用了 a.js 和 b.js，现在更新了变成 a.js 和 c.js。那就只会加载 c.js 文件。
具体请看 webpack + express 实现文件精确缓存。
HTTPS
HTTPS 是最流行的 HTTP 安全形式，由网景公司首创，所有主要的浏览器和服务器都支持此协议。 使用 HTTPS 时，所有的 HTTP 请求和响应数据在发送之前，都要进行加密。加密可以使用 SSL 或 TLS。
SSL/TLS 协议作用在 HTTP 协议之下，对于上层应用来说，原来的发送/接收数据流程不变，这就很好地兼容了老的 HTTP 协议。由于 SSL/TLS 差别不大，下面统一使用 SSL。
要想了解 HTTPS 为何安全，还得继续了解一下这些概念：加密算法、摘要算法、数字签名和数字证书。
加密算法
对称密钥密码体制
对称密钥密码体制，即加密密钥和解密密钥是使用相同的密码体制。对称密钥加密技术的缺点之一就是发送者和接收者在对话之前，一定要有一个共享的密钥，所以不太安全。
公钥密码体制
公钥密码体制使用不同的加密密钥与解密密钥。公钥密码体制产生的主要原因有两个：一是对称密钥密码体制的密钥分配问题，二是对数字签名的需求。
在公钥密码体制中，加密密钥是公开的，解密密钥是需要保密的，加密算法和解密算法也是公开的。
公钥密码体制的加密和解密有如下特点：
- 密钥对产生器产生出接收者 B 的一对密钥，即加密密钥 PK 和解密密钥 SK。
- 发送者 A 用 B 的公钥 PK 作为加密密钥来加密信息，B 接收后用解密密钥 SK 解密。
看上图，任何人都能用 A 的公钥 PK 对密文进行 E 运算后得到 A 发送的明文。可见这种通信并非为了保密，而是为了进行签名和核实签名，即确认此信息是 A 发送的（使用 A 的密钥进行加密的报文，只有使用 A 的公钥才能正确解密）。 但上述过程仅对报文进行了签名，对报文 X 本身却未保密，所以要采用下图的方法，同时实现秘密通信和数字签名。
数字证书
假如你想访问一个网站，怎么确保对方给你的公钥是你想访问的网站的公钥，而不是被中间人篡改过的？
数字证书的出现就是为了解决这个问题，它是由数字证书认证机构颁发的，用来证明公钥拥有者的身份。换句话说，数字证书的作用就相当于人的身份证，身份证证明了张三就是张三，而不是别人。
数字证书一般包含以下内容：
- 对象的名称（人、服务器、组织等）；
- 过期时间；
- 证书发布者（由谁为证书担保）；
- 来自证书发布者的数字签名；
- 对象的公钥；
- 对象和所用签名算法的描述性信息。
任何人都可以创建一个数字证书，但由谁来担保才是重点。
数字证书的数字签名计算过程：
- 用摘要算法对数字证书的内容计算出摘要；
- 用数字证书的私钥对摘要进行加密得到数字签名。
当浏览器收到证书时，会对签名颁发机构进行验证，如果颁发机构是个很有权威的公共签名机构，浏览器可能就知道其公开密钥了（浏览器会预装很多签名颁发机构的证书）。如果对签名颁发机构一无所知，浏览器通常会向用户显示一个对话框，看看他是否相信这个签名发布者。
因为数字证书的公钥是公开的，任何人都可以用公钥解密出数字证书的数字签名的摘要，然后再用同样的摘要算法对证书内容进行摘要计算，将得出的摘要和解密后的摘要作对比，如果内容一致则说明这个证书没有被篡改过，可以信任。
这个过程是建立在被大家所认可的证书机构之上得到的公钥，所以这是一种安全的方式。
