HTTP
请求头的关键属性
请求和响应
状态码
2xx，基本上是成功
200 ok这个是最常见的状态码，表示连接成功
-表示正在连接，需要等会
3xx，重定向
访问A的时候，A告诉你去找B
301Moved permanent永久迁移
302move temporarily短时间迁移
把服务器架设在新域名上，同时把旧域名设置重定向，访问旧域名，就会跳转到新域名。
4xx，客户端出错，客户构造的请求有问题
404NOTFound 这个是访问的资源没找到
url = 协议+ip+端口+路径，路径错了，在服务器上不存在这个资源
这个需要注意的是，即使出现了404，也可以在body中携带一些html之类的，会使404这个页面更好看
403forbidden
访问被拒绝，无权限
405MethodNotAllow
请求的方法和服务器的方法不一样，代码中易出现
5xx，服务器出错，代码有bug
500Internal Server Error
服务器出现错误，抛异常但是没有catch到
504Gateway Timeout
网关拒绝接入
网关就类似于门口，当资源紧张的时候，就容易触发，不给你进入
Ajax是js提供的api
因为非常难用，所以有XMLhttpRequest类
之后有个第三方库jQuery
后续js框架崛起
Anglar Vue React前端三大框架
Postman/apifox都是http请求的构造工具
HTTPS
HTTPS的加密
HTTPS = HTTP+S（SSL/TLS）
运营商劫持
因为数据在http的情况下都是使用明文传输的，所以很容易就会出现被篡改的情况
加密和解密：密钥
- 对称加密，加密和解密使用同一个密钥
- 非对称加密：加密使用一个，解密使用一个
在非对称加密中，会有一个公开的叫做公钥，另外一个自己保存的叫私钥，公钥加密，私钥解密，私钥加密，公钥解密
HTTP工作原理
在原先的http协议中，我们传输东西都是明文传输的，这个就意味着，只要路由器被侵入，那么所有的消息别人都能看到
引入对称加密
客户端和服务端开始通讯的时候，就需要其中一方生成密钥，然后传输给对方
这个时候，因为我们传输的过程还是明文传输，所以这个密钥还是会被黑客给拿到
后续的加密也是无意义的
非对称加密
私钥是服务器自己持有的，不会对外泄露，只有服务器自己持有
公钥 = 一把 "公开的锁"：可以随便发给任何人（比如客户端），谁都能用这把锁 "加密数据"（把数据锁起来）；
私钥 = 这把锁唯一对应的钥匙：只有服务器自己保管，其他人都没有，只有用这把钥匙才能 "解密被公钥加密的数据"（打开锁）。
客户端先用服务器的公钥加密对称密钥（888888），然后把密文发出去；
即使黑客截获了密文，因为他没有服务器的私钥，根本解不开这个密文，所以拿不到对称密钥；
只有服务器收到密文后，用自己的私钥解密，才能得到对称密钥 ------ 整个过程里，私钥只在服务器手里，不会给任何外部角色。
非对称加密的代价是很高的，不适合加密大数据
非对称的代价小，适合加密大数据
举例子：
第一步：朋友提前准备好 "非对称密钥对"（服务器预生成密钥）
朋友先去配锁店做了两件事：
打造一把 "专属钥匙"（私钥）：自己贴身保管，绝不交给任何人；
打造无数把 "公开锁"（公钥）：谁要都能给，锁的结构和专属钥匙完全匹配 ------只有这把专属钥匙能打开这个公开锁，其他钥匙都不行。
朋友把公开锁放在家门口，任何人来都能拿走。
第二步：用 "非对称加密" 安全传递 "对称密码锁的密码"（会话建立阶段）
你要给朋友寄贵重文件，担心文件在路上被人偷，需要用共享密码锁锁起来，但直接告诉朋友密码会被偷听。于是你按这个步骤操作：
你去朋友家门口拿了一把 公开锁（公钥）；
你自己买了一把 共享密码锁（对称密钥），设置了一个密码（比如123456）；
你把 共享密码锁的密码纸条 放进小盒子，用公开锁把小盒子锁死（用公钥加密对称密钥）；
你把锁好的小盒子寄给朋友 ------ 路上就算被小偷截获，小偷没有朋友的专属钥匙，根本打不开盒子，拿不到密码纸条。
朋友收到小盒子，用自己的 ** 专属钥匙（私钥）** 打开，拿到了共享密码锁的密码（123456）。
第三步：用 "对称加密" 快速传输大量文件（数据传输阶段）
现在你和朋友都知道了共享密码锁的密码，接下来的流程就简单高效了：
你把贵重文件放进大箱子，用共享密码锁锁死（用对称密钥加密隐私数据）------ 这个锁的速度特别快，就算箱子里有 100 份文件，也能瞬间锁好；
你把锁好的大箱子寄给朋友 ------ 小偷就算截获箱子，没有密码也打不开；
朋友收到箱子，用共享密码锁的密码（123456）打开，取出文件（用对称密钥解密数据）。
上述过程，同时也是存在这巨大的安全隐患
中间人攻击
假设现在路由器被黑了，虽然我们一开始引入了非对称加密和对称加密，但是在中间人攻击的情况下也是没有用的。
路由器被黑了，客户端发出请求，这个时候会进过路由器，然后转发到服务器，服务器会返回一个真正的公钥，但是会被黑的设备给拦截住，然后这个时候被黑的设备就会返回一个属于自己的公钥，然后客户端并不知道，就会把对称加密的放进去，到达被黑的设备的时候，就会被解密出来，然后再把这个对称加密通过真的公钥加密返回给服务器，那么之后所有的通讯，都是相当于没加锁
举例子
现在你和你远方的朋友寄东西，然后先让你朋友寄一个锁过来（这个锁的钥匙只有你朋友有），寄到驿站的时候，驿站把你朋友寄过来的锁换成了自己的，然后你并不知道，就把自己的密码放进去，这个时候寄回去的时候，驿站会打开锁，这个时候就看到了你们通讯的密码是啥，然后再把他放回到你朋友的锁里面去，这个时候你朋友也不知道，后续你们寄东西的时候，密码锁在驿站就会被打开，东西就会被盗取走了
校验机制
之所以会出现中间人攻击的情况，就是在于客户端无法识别这个公钥是否被篡改过
所以证书机制就是来解决这些问题的
证书机制
证书机制是由第三方可信任的机构给服务器颁发的证书
证书包括：
证书的颁布者机构是谁
证书的有效期是啥时候
服务器的公钥是谁
服务器的域名是啥
证书的数字签名是多少（核心）（本质是一个校验和，把上述的所有东西带入一公式计算的结果，用来验证身份的）
第三方的机构会把这些使用他独特的私钥进行加密，公钥会被内置在所有的操作系统中，公钥不是通过网络传输的，大部分知名的第三方权威机构的公钥都是内置在操作系统中的
现在当客户端发起请求的时候，虽然路由器被黑了也没事
因为当服务器返回证书的时候，虽然这个被黑的路由器也可以也可以通过操作系统内置的公钥进行查看内容，但是他没有办法进行修改，因为当他进行修改的时候，需要修改公钥和数字签名，这个时候加密怎么办，私钥不在他手上，这个时候返回客户端的时候，客户端会使用相同的算法进行解密，发现不对客户端就会报错，提示这个完整的证书过期，是否要访问
- 被黑的路由器修改证书可以吗？
不行，因为修改的情况下，就需要从新加密，私钥不在手上，修改不了
- 被黑的路由器可以申请一个合规的证书然后修改域名和签名吗？
不行，当你申请一个证书之后，你虽然有公钥和私钥，但是你的私钥和公钥是针对你这个证书的，只要改动这个证书里面的域名就作废，因为这里的东西是和第三方的是联动的，想用改动还是需要通过第三方的私钥进行改动
以上的行为都会被客户端拦截，所以中间人攻击就被阻拦了
这个时候SSL的握手流程就结束了
- 引入对称加密
- 引入非对称加密
- 防止中间人攻击
- 引入证书&数字签名