这是我参与「第四届青训营 」笔记创作活动的的第13天
HTTP实用指南
大家好，这里是整理笔记的Vic，今天给大家带来HTTP实用指南的笔记。在这部分中我将结合上课时候的内容对HTTP的相关知识进行讲解。
HTTP的相关概念
HTTP的全称是超文本传输协议（HyperText Transfer Protocol），它是一个基于TCP协议的应用层协议，其特点是简单可扩展且每个请求独立。
HTTP协议分析
HTTP的发展经过很多的版本变更，目前来说最泛用的版本是1.1版本，这也是HTTP的标准化协议。现在也已经推出了HTTP/2，其相对于之前的1.1版本来说具有更优异的表现，很多大厂的应用也在支持HTTP2协议。目前HTTP协议也在不断地更新中，HTTP/3现在正处于草案阶段。
如图所示，是一个HTTP/1.1的请求和响应报文，对于请求的首行由方法、路径、版本组成，对于响应，其首行由版本、状态码、状态信息组成。
常见的HTTP请求方法如下：
| 方法名称 | 解释 |
|---|---|
| GET | 请求一个指定资源的表现形式，需要注意的是GET请求应只用于获取数据 |
| POST | 用于将实体提交到指定的资源，通常导致在服务器上的状态变化或副作用 |
| PUT | 用请求有效载荷替换目标资源的所有当前表示 |
| DELETE | 删除指定的资源 |
| HEAD | 请求一个与GET请求的响应相同的响应，但没有响应体 |
| CONNECT | 建立一个到由目标资源标识的服务器的隧道 |
| OPTIONS | 用于描述目标资源的通信选项 |
| TRACE | 沿着到目标资源的通信选项 |
| PATCH | 用于对资源应用部分修改 |
HTTP请求方法有两个重要的概念，即Safe(安全的)和Idempotent（幂等）。Safe表示方法不会修改服务器数据，包括 GET、HEAD、OPTIONS这三种方法。Idempotent则表示同样的请求在执行一次与多次的情况下效果是一样的，服务器状态也是一样的。很明显，所有的safe方法都是idemponent的。idemponent方法有如下几个：GET、HEAD、OPTIONS、PUT（替换一次和多次没区别）、DELETE（删除一次之后后面就没有对应的指定资源了）。
HTTP状态码
状态码分类：
- 1xx：指示信息，表示请求已接收，继续处理；
- 2xx：成功，表示请求已被成功接收、理解、接受；
- 3xx：重定向，要完成请求必须进行更进一步的操作；
- 4xx：客户端错误，请求有语法错误或请求无法实现；
- 5xx：服务器端错误，服务器未能实现合法的请求。
常见状态码：
- 200：客户端请求成功；
- 301：资源被永久转移到其他URL；
- 302：临时跳转；
- 401：请求未经授权；
- 403：没有权限访问请求资源；
- 404：请求资源不存在；
- 500：服务器错误；
- 504：网关超时。
RESTful API
这是一种API设计风格，REST表示“Representational State Transfer”，即表现层状态转移。这种设计风格并不针对于某一种语言，其特点是：
- 每一个URI代表一种资源；
- 客户端和服务器之间传递这种资源的表现形式；
- 客户端通过HTTP方法对服务器端资源进行操作，实现“表现层状态转化”。
常用请求头
下面列举几个常用的请求头：
| 请求头 | 含义 |
|---|---|
| Accept | 接收类型，表示浏览器支持的MIME类型（对标服务端返回的Content-Type） |
| Content-Type | 客户端发送出去实体内容的类型 |
| Cache-Control | 指定请求和响应遵循的缓存机制 |
| If-Modified-Since | 对应服务端的Last-Modified，用来匹配看文件是否变动，只能精确到1s之内 |
| Expires | 缓存控制，在这个时间内不会请求，直接使用缓存，服务端时间 |
| Max-age | 代表资源在本地缓存多少秒，有效时间内不会请求，而是使用缓存 |
| If-None-Match | 对应服务端的ETag，用来匹配文件内容是否改变（非常精确） |
| Cookie | 有cookie并且同域访问会自动带上 |
| Referer | 该页面的来源URL |
| Origin | 最初的请求是从哪里发起的，Origin比Referer更尊重隐私 |
| User-Agent | 用户客户端的一些必要信息 |
常用响应头
| 响应头 | 含义 |
|---|---|
| Content-Type | 服务端返回的实体内容的类型 |
| Cache-Control | 指定请求和响应遵循的缓存机制 |
| Last-Modified | 请求资源的最后修改时间 |
| Expires | 应该在什么时候认为文档已经过期，从而不再缓存它 |
| Max-age | 客户端的本地资源应该缓存多少秒，开启了Cache-Control后有效 |
| ETag | 资源的特定版本的标识符，Etags类似于指纹 |
| Set-Cookie | 设置和页面关联的cookie，服务器通过这个头部把cookie传给客户端 |
| Server | 服务器的一些相关信息 |
| Access-Control-Allow-Origin | 服务器端允许的请求Origin头部 |
在这里要重点讨论缓存，缓存分为两种：强制缓存与协商缓存。
首先讲解一下强制缓存：
强制缓存的过程是浏览器在第一次访问服务器时向服务器发送请求，服务器返回资源，之后浏览器再请求资源之前先通过max-age判断缓存有没有过期，没有过期的话直接从缓存里拿资源。其具体流程如图所示：
通过Cache-Control来进行强制缓存的控制，其控制分为三个方面：第一个方面为可缓存性，通过no-cache设置协商缓存验证，通过no-store不使用任何缓存；第二个方面为缓存到期时间，通过max-age进行设置，单位为秒，表示存储的最大周期，相对于请求的时间；第三个方面为重新验证与重新加载，通过must-revalidate进行设置，一旦资源过期，在成功向原始服务器验证之前，不能使用。
接下来讲一下协商缓存，这是一种服务端的缓存策略，其过程是浏览器向服务器发送请求，服务器返回资源和资源标识，浏览器再次请求资源时需向服务器发送请求和资源标识，服务器对资源标识进行判定，如果不是最新资源返回200状态码和最新资源与新的资源标识，如果是最新资源，服务器返回304状态码，直接从缓存中拿资源。其流程如下图所示（需要注意的是图中后续返回中没有写200状态码，心中有数就好）：
协商缓存的资源标识符有两个，分别为Etag/If-None-Match与Last-Modified/If-Modified-Since。Etag是资源的唯一标识，为一个字符串，可以类比理解为人类的指纹。Last-Modified是最后修改时间。对于这两个标识符的使用过程参考下面两张图片即可：
Last-Modified：
Etag：
在实际使用中应优先使用Etag，这是由于Last-Modified只能精确到秒级，如果资源被重复生成而内容不变，则Etag更为精确。
缓存的整体流程图如下图所示，其实可以看到就是上面几个流程的合并。
现在来讲解一下浏览器中的cookie。可以在响应中通过Set-Cookie进行设置，其具体参数如下：
| 选项 | 解释 |
|---|---|
| Name=value | 各种cookie的名称和值 |
| Expires=Date | Cookie的有效期，缺省时Cookie仅在浏览器关闭之前有效 |
| Path=Path | 限制指定Cookie的发送范围的文件目录，默认为当前 |
| Domain=domain | 限制cookie生效的域名，默认为创建cookie的服务域名 |
| secure | 仅在HTTPS安全连接时，才可以发送cookie |
| HttpOnly | JavaScript脚本无法获得Cookie |
| SameSite=[None|Strict|Lax] | None 同站、跨站请求都可以发送 Strict 仅在同站发送 Lax 允许与顶级导航一起发送，并将与第三方网站发起的GET请求一起发送 |
HTTP/2概述
特点是：更快、更稳定、更简单
主要特点有如下几个：
- 在HTTP/2中使用帧（frame）作为通信的最小单位，每个帧都包含帧头，帧头会标识出当前帧所属的数据流。
- 用二进制进行传输。
消息：与逻辑请求或响应消息对应的完整的一系列帧。
数据流：已建立的双向字节流，可以承载一条或多条消息。
- 发送时采用交错发送，接收方重组织的方式。
- HTTP/2连接都是永久的，而且仅需要每个来源一个连接。
- 采用流控制：阻止发送方向接收方发送大量数据的机制。（可以用来防止DDOS攻击）
- 服务器进行推送。
HTTPS概述
HTTPS的全称是“Hypertext Transfer Protocol Secure”，其采用TSL/SSL加密。其加密流程如下图所示：
场景分析
在这一部分，主要解答几个上课时期的问题。
状态码200，一定发起了请求吗？
很明显，这个问题的答案是状态码200不一定发起了请求，通过之前的学习，我们知道浏览器中存在缓存机制，当使用强制缓存的时候，不需要发送请求到服务器，会直接读取浏览器本地缓存，在Chrome的Network中显示的HTTP状态码就为200。
缓存策略是怎么样的？
强制缓存中默认的Cache-Control为一年。
静态资源方案
缓存 + CDN + 文件名hash
CDN的全称是“Content Delivery Network”，其通过用户就近性和服务器负载的判断，确保内容以一种极为高效的方式为用户的请求提供服务。
同源/跨域
只要协议、域名、端口号三者中有一个不一样就是跨域，否则就是同源。
对于跨域问题的解决方案有：CORS、代理服务器、Iframe（存在诸多不便）。
