HTTP各版本
HTTP的特点：
- 无状态：对事物处理没有“记忆”能力
- 通信使用明文，请求和响应不会对通信方进行确认、无法保护数据的完整性
- 基于请求和响应：基本的特性，由客户端发起请求，服务端响应
- 简单快速、灵活
缺点：
- 通信使用明文，内容可能被窃听
- 不验证通信方身份，可能遭遇伪装
HTTP/1.0
- 默认使用短连接；每次请求都需要建立TCP连接，即每次发送数据都需要三次握手、四次挥手，传输完成立即断开，开销大，效率低。可以设置 Connection：keep-alive，强制开启长连接
- 错误状态响应码少
- 不支持断点续传。每次都会传全部的页面和数据。
HTTP/1.1
- 默认长连接（持久连接），即TCP连接默认不关闭，可以被多个请求复用
- 分块传输编码，即服务端每产生一块数据，就发送一块，用“流模式”取代“缓存模式”
- 管道机制（客户端可以将多个请求放入队列，当第一条请求发往服务器，第二第三条也可以发送了，可以降低网络的环回时间，提高性能），即在同一个TCP连接里面，客户端可以同时发送多个请求
会引起队头阻塞：http管道机制要求服务端必须按照请求发送的顺序返回响应，如果第一个响应延迟了，后续的响应都会被延迟
HTTP/2.0
-
二进制格式，1.1版本的头信息是文本（ASCII编码），数据体可以是文本和二进制；2.0中，头信息和数据体都是二进制，实现方便，健壮性更好
-
多路复用，在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应（解决队头阻塞问题）
-
报头压缩：因HTTP协议是无状态的（不对通信状态进行保存），每次请求都必须附上所有信息。HTTP/2.0引入了头信息压缩机制，使用gzip或compress压缩后再发送，同时通信的双方各自缓存一份header fields表，即避免了header的重复传输，又减少了传输的大小
-
服务器推送：允许服务器未经请求，主动向客户端发送资源（还没有收到浏览器的请求，服务器就把各种资源推送给浏览器）
推送资源必须对应一个请求，请求由服务端 PUSH_PROMISE 发送，响应在Stream ID 的 Stream 中发送，Stream ID 是偶数，服务器基于 PUSH_PROMISE 帧告诉client，css，js资源即将推送
HTTPS
HTTPS其实就是在HTTP的基础上加了SSL协议
HTTPS特点：
- 内容加密：采用混合加密，中间者无法直接查看明文内容
- 验证身份：通过证书认证客户端访问的是自己的服务器
- 保护数据完整性：防止传输的内容被中间人冒充或者篡改
HTTPS是怎么保证安全的
HTTPS用了证书、非对称加密来验证身份和内容加密
服务器用证书来保证自己是合法的，就相当于身份证，用来证明自己的身份，不用担心有人冒充自己，让用户放心发请求。
通过公钥加密，私钥解密（私钥只有服务器知道），来保证密文的传输，就算传输的信息被拿到也不担心信息泄露。
流程如下：
- 客户端向服务器发送https请求，
- 服务器把证书、公钥发给客户
- 客户通过证书验证身份之后，会随机生成一个对称密钥
- 用公钥加密该对称密钥，发送给服务器
- 服务器用私钥解密得到该对称密钥
- 之后客户端与服务器之间的通信，都使用该对称密钥加密后在传输
cookie、session、jwt
因为HTTP是无状态的，所有引入了cookie、session、jwt来保存历史请求，总不能每次请求都输入一遍账号密码吧
cookie、session
当server收到client请求后，会生成一个session，请求返回会将sessionid也返回给client。client收到会保存到cookie中，在之后的请求中会把cookie也发送给server，server会读取cookie中的sessionid与自身存储的sessionid是否相同，相同就通过了身份验证，响应请求。
jwt
由三部分组成
- Header，包括类型和加密使用的算法
- Payload，包括registered，public，private
| registered | |
|---|---|
| iss（issuer） | 签发人 |
| exp（expiration time） | 过期时间 |
| sub（subject） | 主题 |
| aud（audience） | 受众 |
| nbf（not before） | 生效时间 |
| iat（issued at） | 签发时间 |
| jti（jwt id） | 编号 |
public：可以添加任何信息，但该部分可以在客户端进行解密，不要添一些敏感信息
private：自定义声明
- Signature，防止前两部分被篡改，用密钥进行签名
- header(加密后)
- payload(加密后)
- secret
可以去官网试试：jwt.io/#debugger-io
token是发放给客户端的，发放之后，客户端会把它存起来
- 存在localStorage，每次请求把token放在HTTP请求头Authorization字段，存在web，可以通过javascript访问，容易收到XSS攻击
XSS：跨站脚本攻击，攻击者通过在目标网站注入恶意脚本，在用户浏览器上运行，可以获取到用户的敏感信息 - 存在cookie，让它自动发送，可以设定HttpOnly来防止被javascript读取，也可以设定secure保证token只在HTTPS传输。但不能跨域，容易遭受CSRF攻击。
CSRF：跨站请求伪造，攻击者用已经认证过的用户信息去进行一些操作。由于身份已经认证过，目标网站会认为这些都是用户的正常操作。
