HTTP与HTTPS
HTTP与HTTPS
参考连接:
1.https://kamranahmed.info/blog/2016/08/13/http-in-depth/
2.https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
3.https://tools.ietf.org/html/rfc1945
4.https://http2.github.io/http2-spec/
5.https://www.zhihu.com/question/34074946
6.https://blog.csdn.net/xiaoming100001/article/details/81109617
HTTP
发展历程
HTTP目前为止一共四个版本,分别是HTTP/0.9,HTTP/1.0,HTTP/1.1,HTTP/2.
HTTP/0.9不涉及数据包传输,规定了客户端与服务器之间的通信格式,只能get请求
HTTP/1.0传输内容格式不限制,增加PUT.PATCH,HEAH,OPTIONS,DELETE命令,为RESTful风格的基础
HTTP/1.1增加持久连接,长连接
HTTP/2.0 多路复用 就是不用等上一个请求完成,直接发送上一个请求
| 版本 | 产生时间 | 内容 | 发展现状 |
|---|---|---|---|
| HTTP/0.9 | 1991年 | 不涉及数据包传输,规定客户端和服务器之间通信格式,只能GET请求 | 没有作为正式的标准 |
| HTTP/1.0 | 1996年 | 传输内容格式不限制,增加PUT、PATCH、HEAD、 OPTIONS、DELETE命令 | 正式作为标准 |
| HTTP/1.1 | 1997年 | 持久连接(长连接)、节约带宽、HOST域、管道机制、分块传输编码 | 2015年前使用最广泛 |
| HTTP/2 | 2015年 | 多路复用、服务器推送、头信息压缩、二进制协议等 | 逐渐覆盖市场 |
特点
-
超文本传输协议,
-
基于请求与响应,
-
无状态:HTTP协议对客户端没有状态存储,对事物处理没有“记忆”能力,比如访问一个网站需要反复进行登录操作,就像一个路一样,不知道通过的都是什么,只是通道
-
无连接:HTTP/1.1之前,每次请求需要通过TCP三次握手四次挥手,和服务器重新建立连接。比如某个客户机在短时间多次请求同一个资源,服务器并不能区别是否已经响应过用户的请求,所以每次需要重新响应请求,需要耗费不必要的时间和流量。
-
处于应用层的协议
-
基于TCP传输,所以通信前需要三次握手,结束后四次挥手
-
简单快速灵活
-
使用明文通信不安全
解决无状态
利用cookie/session,保存用户的登录状态
HTTPS
在HTTP的基础上增加SSL/TLS,建立安全信道,加密数据包,使用非对称加密传输对称密钥,对称密钥用来加解密数据包
PS:TLS是SSL的前身
特点
-
内容加密:采用混合加密技术,中间过程无法直接查看明文内容
-
验证身份:通过证书认证,客户端访问的是自己的服务器
-
保护数据完整性:防止传输的内容被篡改
混合加密:结合对称与非对称加密技术.客户端使用对称加密生成的密钥对传输的数据进行加密.然后使用非对称密钥对对称密钥进行加密,所以网络上传输的是对称密钥加密过的数据与非对称密钥加密的对称密钥.因此如果没有私钥无法获取对称密钥,也就无法查看明文
数字摘要: 通过单向hash函数对原文进行哈希,将需要加密的明文摘要成一段固定长度(如128bit)的密文,不同的文明摘要也不一样,相同的明文摘要一定相同.但是不能通过摘要反向解析出正文内容
数字签名技术: 数字签名建立在公钥加密体制基础上,是公钥加密技术的另一类应用,他把公钥机密技术和数字摘要结合起来.形成了实用的数字签名技术,它有以下特点
- 接收方能够证实发送方的身份
- 发送方时候不可否认发送过的报文
- 接收方或非法者不能伪造篡改报文
公钥来源
非对称加密需要公钥加密,但是公钥从何而来呢。其实公钥包含在数字证书里
HTTP通信传输
客户端发送一次请求的经过(在分层协议上过程)
浏览器输入URL后首先经过封装成为HTTP报文,然后传递给下一个再封装成TCP数据传输,如果内容过长会进行分包,然后在网络层再次进行封装,数据链路层再包。具体如图
HTTPS实现的原理
SSL建立连接的过程

下面以https://baidu.com为例,简要介绍一下基本流程
1.client向server端发送请求https://baidu.com,然后连接到server的443端口,发送的信息主要包括一个随机值1和client支持的算法集。
2.server接受到client的信息后,给与响应信息,包括随机值2和匹配好的协商加密算法,这个算法一定是client发送给server的子集,也就是说这个算法是客户端与服务器都支持的
3.接着server给client发送第二个响应报文是数字证书。这套数字证书是存储在服务器上的,可以自己制作,也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过,才可以继续访问,而机构发布的不需要。这套证书就是公钥和私钥,传送的证书其实就是公钥,只是包含了很多信息,如证书的颁发机构、过期时间、服务端的公钥,第三方认证机构的签名,服务端的域名信息等。
4.客户端解析证书,验证的是否有效,比如颁发机构,过期时间等等,如果发现一异常,则会弹出一个警告框,提示证书存在问题过期或其他问题,。如果没有问题,那么就生成一个随机值(预主密钥)。
5.客户端认证证书通过后,接下来通过随机数1(第一步发给服务器的)和随机数2(第二步服务器响应的)以及预主密钥(第三步证书没问题生成的)组装会话密钥(assemble session secret key)。然后通过证书的公钥加密预主密钥。
6.通过公钥加密后,传送加密信息,这一步是为了让服务器使用私钥解密得到预主密钥。
7.服务器通过随机值1与随机值2以及预主密钥组装会话密钥
8.客户端通过会话密钥加密一条信息发送给服务端,验证服务端是否可以正常接受加密信息
9.收到客户端的消息后,服务端也会通过会话密钥加密一条消息回给客户端。如果客户端可以正常接受则索命SSL层连接建立完成
大致如此吧
本文来自博客园,作者:小鸡小鸡快点跑,转载请注明原文链接:https://www.cnblogs.com/clion/p/14121447.html

浙公网安备 33010602011771号