这是我参与「第四届青训营 」笔记创作活动的的第10天,今天的课程是「HTTP实用指南」,老师主要讲解了 什么是HTTP 、 HTTP发展历程 、 报文与状态码的基本知识 、 HTTP与HTTP2 、 场景分析 、 内容补充 等内容。
初识HTTP
HTTP是什么
用户输入信息,浏览器根据输入信息的类型判断应该如何处理,例如输入toutiao.com是想访问这个网站,浏览器就会发起请求,经过网络到达服务器。浏览器读取到服务器的响应后,再进行渲染,最后呈现出我们看到的页面。
Hyper Text Transfer Protocol,HTTP,即超文本传输协议,是基于TCP协议的应用层协议。
每一个HTTP请求都会分为 请求 和 响应 两部分。HTTP请求是比较语义简单的请求,同时在设计上也提供了很多扩展能力。HTTP请求每一个之间都是互相独立的,彼此之间不知道对方携带过什么信息,因此说是无状态的协议。
协议分析
发展历程
HTTP0.9
单行协议
- 请求GET/mypage.html
- 响应只有HTML文档
HTTP1.0
构建可扩展性
- 增加了header
- 有了状态码
- 支持多种文档类型
- ...
HTTP1.1
标准化协议
- 链接复用
- 缓存
- 内容协商
- ...
HTTP2
更优异的表现
- 二进制协议
- 压缩header
- 服务器推送
- ...
HTTP3
草案
报文
Method取值有许多,如下:
| Method | 含义 |
|---|---|
| GET | 请求一个指定资源的表示形式。使用GET的请求应该只被用于获取数据 |
| POST | 用于将实体提交到指定的资源,通常导致在服务器上的状态变化或副作用 |
| PUT | 用请求有效载荷替换目标资源的所有当前表示 |
| DELETE | 删除指定的资源 |
| HEAD | 请求一个与GET请求的响应相同的响应,但没有响应体 |
| CONNECT | 建立一个到由目标资源标识的服务器的隧道 |
| OPTIONS | 用于描述目标资源的通信选项 |
| TRACE | 沿着到目标资源的路径执行一个消息环回测试 |
| PATCH | 用于对资源应用部分修改 |
在标准语义的定义中,通常认为那些 不会修改服务器的数据的方法 是安全的(Safe),比如GET,HEAD,OPTIONS等。
此外,同样的请求被执行一次与连续执行多次的效果是一样的服务器的状态也是一样的,这被称为幂等(Idempotent),如GET,HEAD,OPTIONS,PUT,DELETE等。另外,所有Safe的方法都是Idempotent的。
状态码
1xx
指示信息,表示请求已接收,继续处理。
2xx
成功,表示请求已被成功接收、理解、接受。
- 200 OK —— 客户端请求成功
3xx
重定向,要完成请求必须进行更进一步的操作。
- 301 —— 资源(网页等)被永久转移到其它URL
- 302 —— 临时跳转
4xx
客户端错误,请求有语法错误或请求无法实现。
- 401 Unauthorized —— 请求未经授权
- 404 —— 请求资源不存在,可能是输入了错误的URL
5xx
服务器端错误,服务器未能实现合法的请求。 500 —— 服务器内部发生了不可预期的错误 504 Gateway Timeout —— 网关或者代理的服务器无法在规定时间内获得想要的响应
RESTful API
RESTful API:一种API设计风格;REST-Representational State Transfer
1、每一个URI(Uniform Resource Identifier)代表一种资源。
2、客户端和服务器之间,传递这种资源的某种表现层。
3、客户端通过HTTP method,对服务器端资源进行操作,实现“表现层状态转化”
| 请求 | 返回码 | 含义 |
|---|---|---|
| GET /zoos | 200 OK | 列出所有动物园,服务器成功返回了 |
| POST /zoos | 201 CREATED | 新建一个动物园,服务器创建成功 |
| PUT /zoos/ID | 400 INVALID REQUEST | 更新某个指定动物园的信息(提供该动物园的全部信息),用户发出的请求有错误,服务器没有进行新建或修改数据的操作 |
| DELETE /zoos/ID | 204 NO CONTENT | 删除某个动物园,删除数据成功 |
报文常用请求头
| 请求头 | 含义 |
|---|---|
| Accept | 接受类型,表示浏览器支持的MIME类型(对标服务端返回的Content-Type) |
| Content-Type | 客户端发送出去实体内容的类型 |
| Cache-Control | 指定请求和响应遵循的缓存机制,如no-cache |
| If-Modified-Since | 对应服务端的Last-Modified,用来匹配看文件是否变动,只能精确到1s之内 |
| Expires | 缓存控制,在这个时间内不会请求,直接使用缓存,服务端时间 |
| Max-age | 代表资源在本地缓存多少秒,有效时间内不会请求,而是使用缓存 |
| If-None-Match | 对应服务端的ETag,用来匹配文件内容是否改变(非常精确) |
| Cookie | 有cookie并且同域访问时会自动带上 |
| Referer | 该页面的来源URL(适用于所有类型的请求,会精确到详细页面地址,csrf拦截常用到这个字段) |
| Origin | 最初的请求是从哪里发起的(只会精确到端口),Origin比Referer更尊重隐私 |
| User-Agent | 用户客户端的一些必要信息,如UA头部等 |
| Content-Type | 服务端返回的实体内容的类型 |
| Cache-Control | 指定请求和响应遵循的缓存机制,如no-cache |
| Last-Modified | 请求资源的最后修改时间 |
| Expires | 应该在什么时候认为文档已经过期,从而不再缓存它 |
| Max-age | 客户端的本地资源应该缓存多少秒,开启了Cache-Control后有效 |
| ETag | 资源的特定版本的标识符,ETags类似于指纹 |
| Set-Cookie | 设置和页面关联的Cookie,服务器通过这个头部把Cookie传给客户端 |
| Server | 服务器的一些相关信息 |
| Access-Control-Allow-Origin | 服务器端允许的请求Origin头部(譬如为*) |
缓存
强缓存
- Expires,时间戳
- Cache-Control
- 可缓存性
- no-cache:协商缓存验证
- no-store:不使用任何缓存
- 到期
- max-age:单位是秒,存储的最大周期,相对于请求的时间
- 重新验证※重新加载
- must-revalidate:一旦资源过期,在成功向原始服务器验证之前,不能使用
- 可缓存性
协商缓存
- Etag/If-None-Match:资源的特定版本的标识符,类似于指纹
- Last-Modified/If-Modified-Since:最后修改时间
cookie
Set-Cookie-response
| 属性 | 含义 |
|---|---|
| Name=value | 各种cookie的名称和值 |
| Expires=Date | Cookie的有效期,缺省时Cookie仅在浏览器关闭之前有效 |
| Path=Path | 限制当前Cookie的发送范围的文件目录,默认为当前 |
| Domain=domain | 限制cookie生效的域名,默认为创建cookie的服务域名 |
| secure | 仅在HTTPS安全连接时,才可以发送Cookie |
| HttpOnly | JavaScript脚本无法获得Cookie |
| SameSite=[None/Strict/Lax] | (1)None同站、跨站请求都可发送(2)Strict仅在同站发送(3)Lax允许与顶级导航一起发送,并将与第三方网站发起的GET请求一起发送 |
Cookie是一段不超过4KB的小型文本数据,由一个名称(Name)、一个值(Value)和其它几个用于控制Cookie有效期、安全性、使用范围的可选属性组成。
HTTP2.0
许多互联网大厂都已经切换到HTTP2版本,因为比起HTTP1,HTTP2有更优异的表现,在传输过程中更快、更稳定、更简单。
HTTPS概述
场景分析
静态资源
这个响应是从本地缓存中拿到的响应,并没有经过整个网络的大的链路。
登录场景
场景分析-登录:
1、向什么地址做了什么动作?
- 使用POST方法
- 目标域名sso.totiao.com
- 目标path/quick_login/v2/
2、携带了哪些信息,返回了哪些信息
- 携带信息
- Post body,数据格式为form
- 希望获取的数据格式为json
- 已有的cookie
- 返回信息
- 数据格式json
- 种cookie的信息
那么下一次进入页面为什么能记住登录态呢?
能记住登录态涉及到一个叫鉴权的方案,多为Session+Cookie的方案。就是说登录成功时会提交一个请求,把当前的用户名、密码等提交给Server,经过Server验证和处理后会生成一个Session,同时在这次请求的response中,Server会把Session借由Set——Cookie种到相应地址下面。等下一次再访问的时候,浏览器自动携带的策略会把之前种的Session携带出来,Server通过本地的存储并解析,等能正确识别当前用户,就可以返回信息了。
还有一种鉴权方案叫JWT(JSON Web Token),同样在用户提交之后,Server会生成token,然后在response中将token返回。然后在用户下一次访问的时候,浏览器会把token放到请求头相应的字段,然后提交给Server,Server会把这个token解析出来,看看是不是有效的token,解析验证后返回。
实战
浏览器篇
AJAX——XHR
AJAX——Fetch
Node篇
其他
用户体验
了解更多
通信方式