当前位置：首页 > news >正文

网络原理HTTP/HTTPS（2）

news 文章来源：https://blog.csdn.net/weixin_65476629/article/details/136105920 2025/5/17 18:48:46

文章目录

HTTP响应状态码
- 200 OK
- 3xx 表示重定向
- 4xx
- 5xx
- 状态码小结
HTTPS
HTTPS的加密
- 对称加密
- 非对称加密

HTTP响应状态码

状态码表⽰访问⼀个⻚⾯的结果.(是访问成功,还是失败,还是其他的⼀些情况…).以下为常见的状态码.

200 OK

这是⼀个最常⻅的状态码,表⽰访问成功
2xx都表示成功

3xx 表示重定向

请求访问的是A地址，响应返回一个重定向报文，告诉你应该访问B地址，很多时候页面跳转就可以通过重定向来实现，还有的时候，某个地址服务器迁移了，就会给旧地址挂一个重定向响应
301永久重定向
302临时重定向

4xx

404 Not Found
请求中的访问的资源在服务区上不存在
404这个状态码表示的是资源不存在，同时在body中也是可以返回一个指定的错误页面

403 Forbidden
表示访问地资源没有权限

418 状态码
是HTTP RFC文档中专门规定的一个状态码，没有实际意义，只是“开个玩笑”，称为“彩蛋”

5xx

表示服务器出错了

状态码小结

在这里插入图片描述

HTTPS

HTTPS也是一个应用层协议，是在HTTP协议的基础上引入一个加密层
HTTP协议内容是按照文本的方式明文传输的，这也就导致在传输过程中出现一些被篡改的情况
HTTPS就是一个重要的保护措施，之所以能够安全，最关键就在于“加密”
真正把密码学和计算机结合起来的，还是全靠以为大佬——图灵

HTTPS的加密

加密就是把明文（要传输的信息）进行一系列变换，生成密文
解密就是把密文再进行一系列变换，还原成明文
在这个加密和解密的过程中，往往需要一个或者多个中间的数据，辅助进行这个过程，这样的数据称为密钥

加密方式：
1.对称加密
加密和解密使用的密钥是同一个密钥
明文 + key --> 密文
密文 + key --> 明文

2.非对称加密
有两个密钥，一个称为“公钥”一个称为“私钥”（公钥就是可以公开的，私钥就是自己藏好的）
明文 + 公钥 --> 密文
密文 + 私钥 --> 明文
或者
明文 + 私钥 --> 密文
密文 + 公钥 --> 明文

对称加密

在这里插入图片描述
引⼊对称加密之后,即使数据被截获,由于⿊客不知道密钥是啥,因此就⽆法进⾏解密,也就不知道请求的真实内容是啥了.
但事情没这么简单.服务器同⼀时刻其实是给很多客⼾端提供服务的.这么多客⼾端,每个⼈⽤的秘钥都
必须是不同的(如果是相同那密钥就太容易扩散了,⿊客就也能拿到了).因此服务器就需要维护每个客⼾
端和每个密钥之间的关联关系，这也是个很⿇烦的事情
在这里插入图片描述
⽐较理想的做法,就是能在客⼾端和服务器建⽴连接的时候,双⽅协商确定这次的密钥是啥

但是如果直接把密钥明⽂传输,那么⿊客也就能获得密钥了，此时后续的加密操作就形同虚设了.
因此密钥的传输也必须加密传输!
但是要想对密钥进⾏对称加密,就仍然需要先协商确定⼀个"密钥的密钥".这就成了"先有鸡还是先有
蛋"的问题了。此时密钥的传输再⽤对称加密就行不通了.
就需要引⼊非对称加密.

非对称加密

⾮对称加密要用到两个密钥,⼀个叫做 “公钥”, ⼀个叫做 “私钥”.
公钥和私钥是配对的. 最⼤的缺点就是运算速度⾮常慢，比对称加密要慢很多.
• 通过公钥对明⽂加密, 变成密⽂
• 通过私钥对密⽂解密, 变成明⽂
也可以反着用
• 通过私钥对明⽂加密, 变成密⽂
• 通过公钥对密⽂解密, 变成明⽂
在这里插入图片描述
• 客⼾端在本地⽣成对称密钥, 通过公钥加密, 发送给服务器.
• 由于中间的⽹络设备没有私钥, 即使截获了数据, 也⽆法还原出内部的原⽂, 也就⽆法获取到对称密
钥
• 服务器通过私钥解密还原出客⼾端发送的对称密钥. 并且使⽤这个对称密钥加密给客⼾端返回的响
应数据.
• 后续客⼾端和服务器的通信都只⽤对称加密即可. 由于该密钥只有客⼾端和服务器两个主机知道, 其
他主机/设备不知道密钥即使截获数据也没有意义.

那么接下来问题⼜来了:
• 客⼾端如何获取到公钥?
• 客⼾端如何确定这个公钥不是⿊客伪造的?

中间⼈攻击
黑客可以使用中间人攻击，获取非对称密钥
假设服务器生成好的一对公钥（pub1）私钥（pri1）
黑客生成好的一对公钥（pub2）私钥（pri2）

在这里插入图片描述
客户端查询公钥pub1，服务器返回公钥pub1，被黑客收到，黑客替换pub1成pub2，发给了客户端，客户端返回给服务器，已经收到公钥，被黑客劫到，返回给服务器基于pub1的应答

如何解决中间人攻击问题
之所以能够进行中间人攻击，关键在于客户端没有辨别能力
就需要引入第三方的可以被大家信任的：公证机构
公证机构说这个公钥是正确的，不是被伪造的，就是可以信任的

服务器会向公证机构提交申请（提交一些材料，域名，公钥，厂商…)，公证机构就会对这些材料进行审核，审核通过就会给服务器颁发一个证书，公证机构就会针对证书的各个属性计算出一个校验和，并且针对校验和进行加密（这个加密也是非对称加密，公证机构，自己生成一对公钥和私钥），就得到了一个数字签名
在这里插入图片描述
客户端拿到了证书，也就拿到了证书中的公钥，客户端就是需要验证这个公钥是否是服务器最初的公钥
这个过程称为证书的校验（核心机制：数字签名，拿着数据的每个字节，带入公式，就能算出一个结果数字，称为校验和，把这个数据和校验和一起发送给对方，对方再按照同样的方式再算一遍校验和，如果对方算出来的校验和和收到的校验和一致，就认为数据在传输过程中没有改变过；