【认识状态码】
状态码最重要的目的，就是反馈给浏览器:这次请求是否成功，若失败，则出现失败原因
https://i-blog.csdnimg.cn/direct/997402d5a0984481a2438092f6cdb9d2.png" width="153" />
常见状态码:
200:OK，表示成功
404:Not Found，浏览器访问的资源在服务器上没有找到
403:Forbidden，访问被拒绝（没有权限）
405:Method Not Allowed，方法不支持
500:Internal Server Error服务器内部错误
504:Gateway TimeOut，超时，服务器出问题了，响应没有在规定的时间内返回
302:Found，特殊的状态码，重定向，访问A网站自动跳转到B网站，响应中就会返回302这样的状态码，并且在响应头中添加Location属性（包含了B网站的地址）
总结:
状态码中2开头的，都是成功
4开头的，都是客户端这边出问题
5开头的，都是服务器端这边出问题
【https】
【https概念】
也是一个应用层协议，http协议内容都是按照文本方式明文传输的，这就导致在传输过程中出现一些被篡改的情况，可能会出现「运营商劫持」，一些情况下想下载的内容被偷偷替换为别的内容
如何解决？进行加密
https，在http协议的基础上引入了一个加密层，传输时内容被进行了加密，也是通过密文传输的
【密码的核心概念】
明文:要传输的原始数据
密文:把明文进行加密后得到的一个让别人不能理解的数据
加密:明文—＞密文
解密:密文—＞明文
密钥:进行加密和解密的重要数据/辅助工具
【对称加密，非对称加密】
两类加密算法
对称加密:无论是加密还是解密，都使用同一个密钥
非对称加密:有一对密钥A和B，使用A加密，就使用B解密，或者使用B加密，就使用A解密
大多时候一对密钥有一个密钥是公开的
公开出来的密钥，称为“公钥”，私藏起来的密钥，称为“私钥”
【https基本工作过程】
首先要注意，https只是在http的基础上引入加密机制，所以除了加密部分其他部分和http一模一样
https://i-blog.csdnimg.cn/direct/7e22af0e962d40f6b96d3f977f9e41ea.png" width="616" />
如果中间的路由器被黑客入侵，此时黑客就可以通过路由器抓包明确地看到传输的数据是什么样子，一旦明确了数据，此时既可以知道数据要干什么，也可以篡改这里的数据
为了解决这样的问题，可以引入对称加密
https://i-blog.csdnimg.cn/direct/27901001e49a48f6a836b290d9743755.png" width="612" />
但客户端和服务器交互过程中，一个服务器对应多个客户端，多个客户端是使用同一个还是不同的密钥？
必须不用，若大家密钥都相同，黑客只需要自己搞一个客户端，就也能知道密钥是什么
https://i-blog.csdnimg.cn/direct/3f17730a218b45888be44e356f13692f.png" width="616" />
按照这样的方式，密钥明文传输给服务器，此时黑客就可能截获到这个密钥，后续的加密形同虚设，因此，通过对称加密，数据就是不安全的
为了让数据安全，可以引入非对称加密
通过非对称加密，对要传输的对称密钥进行加密，需要注意的是，非对称加密存在的目的不是为了取代对称加密，而是“辅助”
业务数据仍然是对称加密传输，而非对称加密只用来传输对称密钥
不取代是因为非对称加密的运算开销大，比较消耗性能，因此只用来加密运算开销小且很关键的对称密钥
https://i-blog.csdnimg.cn/direct/dadfb4f6986945dc97f699abad196e98.png" width="616" />
【中间人攻击】
上述流程中存在严重缺陷
1.服务器会生成一对公钥私钥pub1和pri1，其中pub1是公开的，pri1自己保存好
2.客户端这边首先给服务器发起一个请求，问服务器公钥是什么，服务器收到了请求，就返回了“公钥是pub1”
3.此时中间的黑客就可以自机生成一对非对称密钥pub2和pri2，然后黑客就会把服务器返回给客户端的响应替换成“公钥是pub2”，变成黑客自己的公钥了
客户端是不清楚当前这个公钥是不是真的，只能选择相信
4.客户端使用pub2针对对称密钥加密，于是就把加密后的数据传输给服务器
5.中间的黑客劫持到上述数据，就可以利用对称密钥的特性，使用自己的pri2针对数据进行解密，得到了对称密钥的内容
随后黑客把拿到的对称密钥内容通过服务器的pub1重新加密，进行伪装，发送给服务器
服务器也不知道这个数据是不是做了手脚，因此服务器就认为和客户端已经把密钥交流完毕了，接下来应该传输数据了
6.接下来双方传输的数据就都能被黑客以对称密钥解密出来
因此，黑客的设备可以在客户端面前假扮服务器，在服务器面前假扮客户端，演技足够好就可以骗过双方，获取到双方传输的业务数据
https://i-blog.csdnimg.cn/direct/d6f1e877ac1849b8a974de6533cf9c28.png" width="616" />
如何避免中间人攻击？
引入证书机制
产生中间人攻击主要是因为客户端不知道服务器发过来的公钥是不是被伪造的，问题的关键是，能让客户端识别出拿到的公钥是不是正确合理的，不是伪造的公钥
如何证明公钥合理？
引入第三方公证机构
在公证机构这里申请「证书」（是电子的一串数据）
申请的时候就需要提交一些资料（网站域名，备案号等，以及最重要的公钥）
公证机构可以根据这些信息生成一个「证书」
https://i-blog.csdnimg.cn/direct/3fed433d29d44e7ab4def2fe4b53646f.png" width="166" />
服务器申请到证书后，后续客户端从服务器拿公钥，就不是只拿公钥，而是拿整个证书
此时，客户端就可以凭借证书中的数字签名对证书的合法性进行验证
【客户端验证数字签名流程】
1.客户端把证书中各个字段，再算一次校验和，得到checksum1
2.客户端使用公证机构的公钥，对数字签名进行解密，得到checksum2
3.对比checksum1和checksum2
若相等，视为当前证书各个字段和服务器这边的证书相同，就可以认为这是合法证书
若不相等，意味着证书上的内容被中间的黑客篡改，此时浏览器往往会弹出警告页面，提示用户该网站不安全
当前客户端手里拿着公证机构的公钥，客户端如何确定这个公证机构的公钥是正确的，不是伪造的？
这个东西不是通过网络获取的，而是操作系统内置的，因此不会是伪造的
黑客可不可以篡改数据后，同时更新数字签名，让数字签名解密出来的checksum2，和篡改过的checksum1一致？
理论不可行，黑客篡改数据后，要想重新生成数字签名，就要使用公证机构的私钥来加密，这个私钥不是普通黑客能拿到的
黑客如果自己生成一个私钥也没用，这个时候客户端拿着公证机构的公钥也解密不了（不是一对的密钥）
此时客户端如果解密出错，也可以认为证书有问题
Fiddler等抓包工具为什么能解析https数据
这类抓包工具只有拿到对称密钥，才能对数据解密
换句话说，这种工具就是在进行被允许的中间人攻击
（开启这类抓包工具的https选项时，同意了「信任抓包工具提供的证书」的选项，因此就是允许了）
1.此时客户端已经信任了fiddler证书，客户端手里就拿着了fiddler的公钥，fiddler就相当于客户端认可的公正机构
2.在客户端询问服务器证书的时候，对于服务器返回的证书，fiddler会篡改证书中的数据，把证书中的公钥替换为自己的公钥，并且使用自己的私钥来加密，得到数字签名，并重新生成证书替换服务器的证书，发给客户
3.客户端验证fiddler证书，计算证书各个属性的校验和，得到checksum1，并从数字签名解密，得到checksum2
这个数字签名就是拿着刚才信任的fiddler公钥进行解密了，这就达成了中间人攻击
https://i-blog.csdnimg.cn/direct/ca75684e3e0a49068f57ccb3803a6e0d.png" width="616" />
这里与刚才的黑客攻击最大差别就是客户端验证fiddler证书的环节
因为对fiddler证书进行了信任，这就令客户端在后续把fiddler当成了公证机构，拿着它提供的公钥进行解密，自然也是没问题的
【重点掌握】
在浏览器输入url后，到最终展示出页面为止，这个过程中计算机都做了哪些事情呢？
基本思路:
站在网络原理的角度
a.DNS解析，我们输入的url里面一般都是一个域名，所以需要通过DNS服务器根据域名得到IP地址
b.https，接下来客户端要给服务器发送一个https请求，进入https的握手过程（对称加密，非对称加密，中间人攻击，证书等）
c.http，前面加密的准备工作完成了，接下来就要正式传输数据了，浏览器构造http请求，服务器返回http响应（http都有啥）
d.TCP，http基于TCP实现（TCP三次握手，核心机制等）
e.IP协议，TCP又是基于IP协议的（IP如何管理IP地址的，IP如何进行数据转发的？）
f.数据链路层（以太网知识）
