admin 管理员组文章数量: 1184232
文章目录
- 一.应用层协议
- (二)HTTP协议[重点]
- 4.报头 header =>键值对结构
- Cookie 提供键值对存储机制
- 5. 请求正文(body)
- 状态码
- 6.通过Ajax构造HTTP请求
- 7.通过 Java socket 构造HTTP请求
- (三)HTTPS协议
- HTTPS是什么
- HTTPS的工作过程
- 对称加密
- 非对称加密
- 中间人攻击
- 引入证书
- 中间人有没有可能篡改证书?
- 中间人整个掉包证书?
- 总结
一.应用层协议
(二)HTTP协议[重点]
4.报头 header =>键值对结构
Cookie 提供键值对存储机制
Cookie就是浏览器允许网页在本地硬盘存储数据的一种机制
不是让网页代码(JS)直接访问文件系统,而是做了一层抽象
浏览器的Cookie提供了键值对存储机制
键值对 分号分割 键值对
键 等号分割 值
Cookie 到哪里去:最终发回给服务器
Cookie 从哪里来:也是从服务器这边来的(程序员可以自定义)
Cookie通用业务:登录+用户认证
比如我们在医院用的就诊卡, 医生把信息电脑,每一个科室都可以刷一下,相当于生成会话,就诊卡只存储一个会话id,你的客户端访问一次数据库服务器,这个中间过程也会称为一次会话
Cookie是可能会过期的,服务器返回Cookie的时候,是可以设置有效时间
如果Cookie中的sessionId过期了,此时就需要用户重新登陆了
对于安全性要求不高 => 过期时间就长
对于安全性要求很高 => 过期时间就短
比如,网银这样的网站,只要你把页面关闭/几分钟内不操作,就会自动过期,若在公共电脑上操作,人离开了一下,下一个拿到电脑,可能就会有损失,这也是为了保障用户安全
5. 请求正文(body)
状态码
200 OK
404 Not Found
表示访问资源没找到~~
过程:
URL
ip定位到主机
port定位到程序
path定位到程序管理的资源
path访问的资源,在服务器上没有 => 404
这种状态都是用户的使用方式不对,并不是程序员的bug
403 Forbidden
表示访问被拒绝(没有权限)
405 Method Not Allowed
网上找别人网站出现405,比较难找~~
但是咱们自己开发过程中,很容易出现405~~
请求方法和服务器这边声明的注解不匹配,就会出现405
就比如我们已经学习了HTTP中所支持的方法,有GET,POST,PUT,DELETE
但是对方的服务器不一定都支持所有的方法(或者不允许用户使用一些其他的方法)
500 Internal Server Error
服务器出现错误
服务器处理逻辑的代码中抛出异常,但是没有catch到
504 Gateway Timeout
当服务器负载比较大的时候,服务器处理单条请求的时候消耗的时间就会很长,就可能会导致出现超时的情况
比如"双十一"秒杀场景中容易出现,平时不太容易见到
Getway 就是网关 => 网络的入口 =>入口服务器,可能是一个软件,也可能是一个专门的机器
302 Move temporarily
临时重定向
重定向 => 换手机号 手机号码中有"呼叫转移"功能
我换手机号后,不需要朋友知道新手机号,只需要办理一个呼叫转移业务即可
登录页面经常能见到 302 ,用于实现登陆成功后自动跳转到主页 Location字段
状态码整体有很多
- 2XX 都可以视为成功
- 3XX 都是重定向
- 4XX 客户端出错,用户构造的请求有问题
- 5XX 服务器出错 我们主要关注这个,一定是服务器出问题了,大概率代码有bug!!
6.通过Ajax构造HTTP请求
从前端角度,除了浏览器地址栏能构造GET请求,form表单能构造GET和POST之外,还可以通过ajax的方式来构造HTTP请求,并且功能强大
JS 框架开始崛起.
Anglar
Vue
React
组织前端代码 js 代码
前端的三大框架
转而采用一些更轻量的方式来实现 ajax 封装
JS 标准里后面也添加 fetch 一套 api, (搭配 js 的 promise 等语法机制, 实现更简单的开发过程)
原生的 XMLHttpRequest 升级版~~
7.通过 Java socket 构造HTTP请求
所谓的"发送HTTP请求",本质上就是按照HTTP的格式往TCP Socket中写入一个字符串
所谓的 “接受 HTTP 响应”,本质上就是从 TCP Socket 中读取一个字符串,再按照 HTTP 的格式来解析.
我们基于 Socket 的知识,完全可以构造出一个简单的 HTTP 客户端程序,用来发送各种类型的 HTTP 请求.
Postman ,apifox这样的工具构造HTTP请求,EE进阶具体演示
(三)HTTPS协议
HTTPS是什么
HTTPS = HTTP + S (SSL / TLS)
其中SSL也是一个SSL也是一个应用层协议,专门负责加密
HTTPS 也是一个应用层协议.是在 HTTP 协议的基础上引入了一个加密层.
HTTP 协议内容都是按照文本的方式明文传输的.这就导致在传输过程中出现一些被篡改的情况. ------“运营商劫持”
由于我们通过网络传输的任何的数据包都会经过运营商的网络设备(路由器, 交换机等), 那么运营商的网络设备就可以解析出你传输的数据内容, 并进行篡改.
点击 “下载按钮”, 其实就是在给服务器发送了一个 HTTP 请求, 获取到的 HTTP 响应其实就包含了该 APP 的下载链接. 运营商劫持之后, 就发现这个请求是要下载天天动听, 那么就自动的把交给用户的响应给篡改成 “QQ浏览器” 的下载地址了.
运营商之所以能够劫持,主要是因为数据传输都是"明文"的,加密,通过密文来传输
明文 加密 得到密文
密文 解密
HTTPS的工作过程
1.对称加密:加密和解密使用同一个密钥
2.非对称加密:加密使用一个密钥;解密使用一个密钥
两个密钥之间,存在关联关系,很难猜
公钥公开出去
私钥自己保存好
对称加密
引入对称加密
客户端生成对称密钥
把密钥传输给服务器
客户端和服务器使用同一个密钥进行加密解密
每个人的密钥都是不同的,因此服务器就需要维护每个用户端和每个密钥之间的关联关系,这也是一件比较麻烦的事
所以比较理想的做法,就是客户端和服务器建立连接的时候,双方协商确定这次的密钥是啥~~ 来加密密钥
这时就要引入非对称加密
非对称加密
引入非对称加密,就是为了解决密钥传输的安全性问题~~,缺点就是运算速度非常慢
由于黑客手里没有私钥.所以黑客不能对888888加密后的数据,进行解密,此时数据到达服务器,服务器使用自己的私钥解密,就知道对称密钥是多少了
引入非对称加密 ->针对对称密钥进行加密传输
非对称加密,成本是比较高的,不适合加密大量的数据
业务数据(大量) ->仍然通过对称密钥加密(对称加密)
对称密钥(小) ->就通过非对称加密方式来传输
中间人攻击
上述这样的流程存在重大安全隐患,黑客可以通过中间人攻击,来获取对称密钥 =>破坏后续传输的安全性
客户端是唐三藏,无法区分 pub2是人是妖,只能选择相信
关键要点就是,给唐三藏配个孙悟空,区分出这个公钥是黑客生成的,还是服务器生成的
引入证书
引入校验机制,中间人攻击的关键,在于客户端无法区分收到的公钥是否是服务器真实的公钥,还是被黑客篡改的公钥,就需要想办法对公钥进行校验
服务端在使用HTTPS前，需要向CA机构申领一份数字证书，数字证书里含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明服务端公钥的权威性
这个证书可以理解成是一个结构化的字符串，里面包含了以下信息：
- 证书发布机构
- 证书有效期
- 公钥
- 证书所有者
- 签名
- ……
需要注意的是:申请证书的时候,需要在特定平台生成,同时生成一对儿公钥密钥,这对密钥就是用来在网络通信中进行明文加密以及数字签名的
数字签名本质上就是一个被加密的校验和 =>把要校验的数据部分代入一个固定的公式,算出一个数字
客户端收到证书,就要进行校验
- 1.客户端需要针对证书中的其他字段 =>使用同样的的算法,再算一次得到 校验和1 =>针对客户端收到的数据进行计算的
证书的颁布机构是谁
证书的有效期是啥时候
服务器的公钥是谁
服务器的拥有者(域名)是啥- 2.在通过公正机构的公钥pub2,对数字签名进行解密,得到校验和2 =>服务器申请证书的时候得到的原始校验和
- 3.对比校验和1 和 校验和2 是否相同,若相同=>没被篡改
若不同 => 证书无效,被篡改了(有内鬼,停止交易)
公正机构的公钥并不是通过网络传输的,而是操作系统中内置的,所以不用担心,pub2是黑客伪造的
中间人有没有可能篡改证书?
- 中间人篡改了证书的明文
- 由于他没有CA机构的私钥,所以无法hash之后私钥加密形成签名,那么也就没办法对篡改后的证书形成匹配的签名
- 如果强行篡改,客户端收到该证书后会发现明文和签名解密后的值不一致,则说明证书已被篡改,证书不可信,从而终止服务器传输信息,防止信息泄漏给中间人
中间人整个掉包证书?
- 因为中间人没有CA私钥,所以无法制作假的证书(为什么?)
- 所以中间人只能向CA申请真证书,然后用自己申请的证书进行掉包
- 这个确实能做到证书的整体掉包,但是别忘记,证书明文中包含了域名等服务端认证信息,如果整体掉包,客户端依旧能够识别出来
- 永远记住:中间人没有CA私钥,所以对任何证书都无法进行合法的修改,包括自己的
总结
HTTPS 工作过程中涉及到的密钥有三组
- 第一组(非对称加密):用于校验证书是否被篡改,服务器持有私钥(私钥在注册证书时获得),客户端持有公钥(操作系统包含了可信任的CA认证机构有哪些,同时持有对应的公钥)服务器使用这个私钥对证书的签名进行加密,客户端通过这个公钥解密获取到证书的签名,从而校验证书内容是否篡改过
- 第二组(非对称加密):用于协商生成对称加密的密钥,服务器生成这组 私钥-公钥对,然后通过证书把公钥传递给客户端,然后客户端用这个公钥给生成的对称加密的密钥加密,传输给服务器,服务器通过私钥解密获取到对称加密密钥
- 第三组(对称加密):客户端和服务器后续传输的数据都通过这个对称密钥加密解密
其实一切的关键都是围绕这个对称加密的密钥,其他的机制都是辅助这个密钥工作的
第二组是为了让客户端把这个对称密钥传给服务器
第一组是为了让客户端拿到第二组非对称加密的公钥
版权声明：本文标题：【EE初阶 - 网络原理】应用层协议(下) 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://www.roclinux.cn/b/1765177110a3355058.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。
发表评论