这是我参加「第四届青训营 」笔记创作活动的的第13天
HTTP实用攻略
大家好，这里是收拾笔记的Vic，今日给大家带来HTTP实用攻略的笔记。在这部分中我将结合上课时分的内容对HTTP的相关知识进行讲解。
HTTP的相关概念
HTTP的全称是超文本传输协议（HyperTextTransferProtocol），它是一个基于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（存在诸多不便）。
