该系列博客是记录自己的学习笔记，若有错误请大佬们指出
狗头声明，本文适用于：新手学习进步，老鸟回顾消遣
该系列以《图解HTTP》为基本路线，该书有11章节，所以本系列也决定编写11篇水文技术博客进行适当的拓展和补充，希望可以帮助大家。
状态码（Status Code）了。它是一个十进制数字，以代码的形式表示服务器对请求的处理结果
状态码的位置处于：响应报文由响应头+响应实体组成，响应头又由状态行+头字段构成，状态行是由协议版本+状态码+状态码的原因短句组成。
状态码
RFC 标准把状态码分成了五类
- 1××：提示信息，表示目前是协议处理的中间状态，还需要后续的操作；
- 2××：成功，报文已经收到并被正确处理；
- 3××：重定向，资源位置发生变动，需要客户端重新发送请求；
- 4××：客户端错误，请求报文有误，服务器无法处理；
- 5××：服务器错误，服务器在处理请求时内部发生了错误。
在 HTTP 协议中，正确地理解并应用这些状态码不是客户端或服务器单方的责任，而是双方共同的责任。客户端作为请求的发起方，获取响应报文后，需要通过状态码知道请求是否被正确处理，是否要再次发送请求，如果出错了原因又是什么。这样才能进行下一步的动作，要么发送新请求，要么改正错误重发请求。服务器端作为请求的接收方，也应该很好地运用状态码。在处理请求时，选择最恰当的状态码回复客户端，告知客户端处理的结果，指示客户端下一步应该如何行动。特别是在出错的时候，尽量不要简单地返 400、500 这样意思含糊不清的状态码。
目前 RFC 标准里总共有 41 个状态码（学习下列常用的状态码即可，不用41个都记住），但状态码的定义是开放的，允许自行扩展。所以 Apache、Nginx 等 Web 服务器都定义了一些专有的状态码。如果你自己开发 Web 应用，也完全可以在不冲突的前提下定义新的代码。
1、1xx类状态码
1××类状态码属于提示信息，是协议处理的中间状态，实际能够用到的时候很少。
运用：偶尔能够见到的是“101 Switching Protocols”。
它的意思是客户端使用 Upgrade 头字段，要求在 HTTP 协议的基础上改成其他的协议继续通信，比如 WebSocket。而如果服务器也同意变更协议，就会发送状态码 101，但这之后的数据传输就不会再使用 HTTP 了。
2、2xx类状态码
2××类状态码表示服务器收到并成功处理了客户端的请求，这也是客户端（浏览器）最愿意看到的状态码。
200 OK
是最常见的成功状态码，表示一切正常，服务器如客户端所期望的那样返回了处理结果，如果是非 HEAD 请求，通常在响应头后都会有 body 数据。
204 No Content
是另一个很常见的成功状态码，它的含义与“200 OK”基本相同，但响应头后没有 body 数据。所以对于 Web 服务器来说，正确地区分 200 和 204 是很必要的
206 Partial Content
是 HTTP 分块下载或断点续传的基础，在客户端发送“范围请求”、要求获取资源的部分数据时出现，它与 200 一样，也是服务器成功处理了请求，但 body 里的数据不是资源的全部，而是其中的一部分。
通常还会伴随着头字段“Content-Range”，表示响应报文里 body 数据的具体范围，供客户端确认，例如“Content-Range: bytes 0-99/2000”，意思是此次获取的是总计 2000 个字节的前 100 个字节。
3、3xx类状态码
3××类状态码表示客户端请求的资源发生了变动（一般发生在用户点击收藏栏的网址），客户端必须用新的 URI 重新发送请求获取资源，也就是通常所说的“重定向”，包括著名的 301、302 跳转。
301 Moved Permanently
“永久重定向”，含义是此次请求的资源已经不存在了，需要改用新的 URI 再次访问。
302 Found
“临时重定向”，意思是请求的资源还在，但需要暂时用另一个 URI 来访问。
相同点：
301 和 302 都会在
响应头里使用字段 Location 指明后续要跳转的 URI，最终的效果很相似，浏览器都会重定向到新的 URI。两者的根本区别在于语义，一个是“永久”，一个是“临时”，所以在场景、用法上差距很大。
不同点：
比如，你的网站升级到了 HTTPS，原来的 HTTP
不打算用了，这就是“永久”的，所以要配置 301 跳转，把所有的 HTTP 流量都切换到 HTTPS。浏览器也会缓存新的URI，作为这个收藏链接的新URI.再比如，今天夜里网站后台要系统维护，服务
暂时不可用，这就属于“临时”的，可以配置成 302 跳转，把流量临时切换到一个静态通知页面，浏览器看到这个 302 就知道这只是暂时的情况，不会做缓存优化，第二天还会访问原来的地址。
304 Not Modified
304用于 If-Modified-Since 等条件请求，表示资源未修改，用于缓存控制。它不具有通常的跳转含义，但可以理解成“重定向已到缓存的文件”（即“缓存重定向”）。所以“缓存重定向”也归类到3xx系列。
提示：301、302的
HTTP重定向和跳转，以及304的HTTP缓存控制，内容较多且重要，放在本文最后单独两节学习。
4、4xx类状态码
遇到4xx，5xx那就是真正有错误了，这才是“错误码”，“状态码” != “错误码”，是包含关系。
4××类状态码表示客户端发送的请求报文有误，服务器无法处理
400 Bad Request
通用错误码，表示请求报文有错误，但具体是数据格式错误、缺少请求头还是 URI 超长它没有明确说，只是一个笼统的错误，客户端看到 400 只会是“一头雾水”“不知所措”。所以，在开发 Web 应用时应当尽量避免给客户端返回 400，而是要用其他更有明确含义的状态码。
403 Forbidden
实际上不是客户端的请求出错，而是表示服务器禁止访问资源。原因可能多种多样，例如信息敏感、法律禁止等，如果服务器友好一点，可以在 body 里详细说明拒绝请求的原因，不过现实中通常都是直接给一个“闭门羹”。
404 Not Found
可能是我们最常看见也是最不愿意看到的一个状态码，它的原意是资源在本服务器上未找到，所以无法提供给客户端。但现在已经被“用滥了”，只要服务器“不高兴”就可以给出个 404，而我们也无从得知后面到底是真的未找到，还是有什么别的原因，某种程度上它比 403 还要令人讨厌。
4xx系列还有405、406、408等等，不是很常用，遇到去谷歌瞅瞅即可。
5、5xx类状态码
5××类状态码表示客户端请求报文正确，但服务器在处理时内部发生了错误，无法返回应有的响应数据，是服务器端的“错误码”。
500 Internal Server Error
与 400 类似，也是一个通用的错误码，服务器究竟发生了什么错误我们是不知道的。不过和400对于客户端不一样，500对于服务器来说这应该算是好事，通常不应该把服务器内部的详细信息，例如出错的函数调用栈告诉外界。虽然不利于调试，但能够防止黑客的窥探或者分析。
501 Not Implemented
表示客户端请求的功能还不支持，这个错误码比 500 要“温和”一些，和“即将开业，敬请期待”的意思差不多，不过具体什么时候支持也不知道。
502 Bad Gateway
通常是服务器作为网关或者代理时返回的错误码，表示服务器自身工作正常，访问后端服务器时发生了错误，但具体的错误原因也是不知道的。
503 Service Unavailable
表示服务器当前很忙，暂时无法响应服务，我们上网时有时候遇到的“网络服务正忙，请稍后重试”的提示信息就是状态码 503。
503 是一个“临时”的状态，很可能过几秒钟后服务器就不那么忙了，可以继续提供服务，所以 503 响应报文里通常还会有一个“Retry-After”字段，指示客户端可以在多久以后再次尝试发送请求。
拓展1：HTTP的重定向和跳转（重定向前置知识 + 301/302）
（1）、主动跳转与被动跳转
前面学习过，“超文本”里含有“超链接”，可以从一个“超文本”跳跃到另一个“超文本”，从而由线性结构的传统文档变为了网状结构。
它把分散在世界各地的文档连接在一起，形成了复杂的网状结构，用户可以在查看时随意点击链接、转换页面。再加上浏览器又提供了“前进”“后退”“书签”等辅助功能，让用户在文档间跳转时更加方便，有了更多的主动性和交互性。
点击页面“链接”时的跳转是怎样的呢？
浏览器首先要解析链接文字里的 URI。再用这个 URI 发起一个新的 HTTP 请求，获取响应报文后就会切换显示内容，渲染出新 URI 指向的页面。这样的跳转动作是由浏览器的使用者主动发起的，可以称为“
主动跳转”
但还有一类跳转是由服务器来发起的，浏览器使用者无法控制，相对地就可以称为“被动跳转”，这在 HTTP 协议里有个专门的名词，叫做“重定向”（Redirection）。
（2）、重定向的过程
301 是“永久重定向”，302 是“临时重定向”，浏览器收到这两个状态码就会跳转到新的 URI。
“重定向”实际上发送了两次 HTTP 请求，第一个请求返回了 301/302以及新的URI；然后第二个请求就被重定向到了这个新的URI资源。但如果不用开发者工具的话，你是完全看不到这个跳转过程的，也就是说，重定向是“用户无感知”的。
在第一次请求中，响应报文里会有一个响应字段“Location: 新的URI”，“Location”字段属于响应字段，必须出现在响应报文里。但只有配合 301/302 状态码才有意义，它标记了服务器要求重定向的 URI，这里就是要求浏览器跳转到“新的URI”。
然后，浏览器收到 301/302 报文，会检查响应头里有没有“Location”。如果有，就从字段值里提取出 URI，发出新的 HTTP 请求，相当于自动替我们点击了这个链接。
（3）、使用重定向的注意点
- 第一个问题是“性能损耗”。很明显，重定向的机制决定了一个跳转会有两次请求 - 应答，比正常的访问多了一次。
- 第二个问题是“
URI循环跳转”。由于在重定向中，服务器端拥有主动权，浏览器是被动接受直接拿着新URI跳转。如果服务器的重定向的策略设置欠考虑，可能会出现“A=>B=>C=>A”的无限循环，不停地在这个链路里转圈圈，后果可想而知。
拓展2：HTTP的缓存控制（缓存的前置知识 + 字段 + 304）
缓存（Cache/kæʃ/）是计算机领域里的一个重要概念，是优化系统性能的利器。
浏览器使用 HTTP 获取资源的成本较高。所以，非常有必要把“来之不易”的数据缓存起来，下次再请求的时候尽可能地复用。这样，就可以避免多次请求 - 应答的通信成本，节约网络带宽，也可以加快响应速度。
因为HTTP基于“请求 - 应答”模式的特点，可以分为
强制缓存和协商缓存
<1>、强制缓存（即只由响应报文中使用Cache-Control字段控制缓存）
- 1、浏览器发现缓存无数据，于是发送请求，向服务器获取资源；
- 2、服务器响应请求，返回资源，同时标记资源的有效期；
- 3、浏览器缓存资源，等待下次重用。
服务器标记资源有效期使用的头字段是“Cache-Control”，例如“Cache-Control: max-age=30”表示服务器告诉浏览器，“这个页面只能缓存 30 秒，之后就算是过期，不能用。”注意：时间的计算
起点是响应报文的创建时刻（即 Date 字段，也就是离开服务器的时刻），而不是客户端收到报文的时刻，也就是说包含了在链路传输过程中所有节点所停留的时间。
比如，服务器设定“max-age=5”，但因为网络质量很糟糕，等浏览器收到响应报文已经过去了 4 秒，那么这个资源在客户端就最多能够再存 1 秒钟，之后就会失效。
响应报文中的Cache-Control字段
注意：Cache-Control字段是通用的首部字段，即响应头和请求头中都可用
- 1、上述的
max-age是“生存时间” - 2、
no-store：不允许缓存，用于某些变化非常频繁的数据，例如秒杀页面； - 3、
no-cache：实际的意思并不是不允许缓存，而是可以缓存，但在使用之前必须要去服务器验证是否过期，是否有最新的版本； - 4、
must-revalidate：缓存不过期就可以继续使用，但过期了如果还想用就必须去服务器验证。
强制缓存流程图：
还有其他属性用到的时候搜索查阅就好。
<2>、协商缓存（请求报文和响应报文一起通过字段协商怎么缓存，不再是服务器说了算，所以是协商缓存）
不止服务器可以发“Cache-Control”头，浏览器也可以发“Cache-Control”，也就是说请求 - 应答的双方都可以用这个字段进行缓存控制，互相协商缓存的使用策略。
刷新与强制刷新
“F5刷新”的时候，浏览器会在请求头里加一个“Cache-Control: max-age=0”。因为 max-age 是“生存时间”，max-age=0 的意思就是“我要一个最新的资源”，而本地缓存里的数据至少保存了几秒钟，所以浏览器就不会使用缓存，而是向服务器发请求。服务器看到 max-age=0，也就会用一个最新生成的报文回应浏览器。Ctrl+F5 的“强制刷新” 本质是
请求头中“Cache-Control: no-cache”，含义和“max-age=0”基本一样，就看后台的服务器怎么理解和处理，通常两者的效果是相同的。
所以刷新往往不适用缓存
什么时候浏览器才会利用缓存？
浏览器的“前进”“后退”按钮、看网络会有“from disk cache”的字样，意思是没有发送网络请求，而是读取的磁盘上的缓存。
浏览器用“Cache-Control”做缓存控制只能是刷新数据，不能很好地利用缓存数据，又因为缓存会失效，使用前还必须要去服务器验证是否是最新版。
所以，缓存是需要双方协作的。
HTTP的缓存详解（协商缓存）
为了使用缓存，最早有个方案是：
浏览器可以用两个连续的请求组成“验证动作”：先是一个 HEAD，获取资源的修改时间等元信息，然后与缓存数据比较，如果没有改动就使用缓存，节省网络流量，否则就再发一个 GET 请求，获取最新的版本。
这样虽然利用了HEAD请求方法减少了数据包的大小，请求次数反而多了一次，如果数据包本身就不大，那就反而浪费时间
所以 HTTP 协议就定义了一系列“If”开头的“条件请求”字段，专门用来检查验证资源是否过期，把两个请求才能完成的工作合并在一个请求里做。而且，验证的责任也交给服务器，浏览器不用管。
上面说了喔，“条件请求”字段，共有5个，都是请求头部独有字段。
这里学习常用的两个：
if-Modified-SinceIf-None-Match[mætʃ]
而响应报文需要的字段也是两个：
Last-modified：文件的最后调整时间，即文件调整了这个值就会变（资源不一定改变）ETag：资源的一个唯一标识，当资源真正改变的时候才会变
ETag就是补充Last-modified的不足：
- 1、Last-modified的时间值只是秒级，如果一个文件在一秒内修改了多次，这一秒内的新版本无法区分。
- 2、一个文件定期更新，但有时会是同样的内容，实际上没有变化，但是Last-modified值会改变，就会误以为发生了变化，传送给浏览器，没有利用到缓存。
使用 ETag 就可以精确地识别资源的变动情况，让浏览器能够更有效地利用缓存。
了解这些后，协商缓存就很好理解了：
Last-Modified & If-Modified-Since
服务器通过Last-Modified字段告知客户端，资源最后一次被修改的时间
例如：Last-Modified: Mon, 10 Nov 2018 09:10:11 GMT
浏览器将这个值和内容一起记录在缓存数据库中。 下一次请求相同资源时时，浏览器从自己的缓存中找出“不确定是否过期的”缓存。因此在请求头中将上次的 Last-Modified 的值写入到请求头的 If-Modified-Since 字段
服务器会将 If-Modified-Since 的值与 Last-Modified 字段进行对比。如果相等，则表示未修改，响应 304；反之，则表示修改了，响应 200 状态码，并返回数据。
但是他还是有一定缺陷的：
- 如果资源更新的速度是秒以下单位，那么该缓存是不能被使用的，因为它的时间单位最低是秒。
- 如果文件是通过服务器动态生成的，那么该方法的更新时间永远是生成的时间，尽管文件可能没有变化，所以起不到缓存的作用。
Etag & If-None-Match
为了解决上述问题，出现了一组新的字段 Etag 和 If-None-Match
Etag 存储的是文件的特殊标识(一般都是 hash 生成的)，服务器存储着文件的 Etag 字段。之后的流程和 Last-Modified 一致，只是 Last-Modified 字段和它所表示的更新时间改变成了 Etag 字段和它所表示的文件 hash，把 If-Modified-Since 变成了 If-None-Match。服务器同样进行比较，命中返回 304, 不命中返回新资源和 200。Etag 的优先级高于 Last-Modified
Etag & If-None-Match流程图：
