HTTP和HTTPS握手流程详解

了解 HTTP 和 HTTPS 的通信流程有助于提升我们队通信严谨性、安全性的理解,同时也是一种解决方案的积累。

1.HTTP 连接的建立(基于TCP)

首先看握手部分:

第一次握手:Client 说 Server 你好,我想跟你建立连接

报文里携带有 seq=J 的请求确认信息 SYN=1,表示这是一次握手请求确认,seq=J 序列号是用来给对方做备份的,以防下次由于网络不好,再次发送一样的报文,如果发现序列号已经确认过了则直接丢弃

此时客户端的状态变化: CLOSED(关闭) => SYN_SENT(确认信息已发送)

此时服务端的状态变化:CLOSED(关闭) => SYN_RCVD(确认信息已接收)

第二次握手:Server 说 Client 你好,你可以建立连接

首先报文里有对第一次握手的确认信息 ACK = 1 和 序号确认 ack=J+1,也有 Server 请求与 Client 建立链接的 SYN=1和 seq=K标识

此时客户端的状态变化:SYN_SENT(确认信息已发送) => ESTABLISHED(连接建立)

此时服务端的状态变化:不变

第三次握手:Client 说 Server 我知道了,连接已建立

报文中携带有对 Server 端发来的 seq=K 消息的确认信息 ACK=1 和 ack=K+1

此时客户端的状态变化:不变

此时服务端的状态变化: SYN_RCVD(确认信息已接收)=> ESTABLISHED(连接建立)

到此,三次握手完成,客户端开始向服务端发起请求。

为什么不进行二次握手 ?为什么不进行四次握手 ?因为两次无法保证双方都知道能联系上对方,而四次+就没完没了了。

 

2.HTTPS连接的建立(基于 SSL\TSL 和 TCP)

由于 HTTPS 的目的是安全,所以会经过比 HTTP 连接更复杂的流程,一切为了安全,首先看一下连接建立流程:

这是比较常见的一张图,但是少了两部分,下面会详细说明:

第一步:服务端拿着 https://+IP 去请求服务端,同时携带有一个随机数 X

第二步:服务端收到后会记录下 X,服务端也生成一个随机数 Y,并且把公钥(证书)一并发给客户端

第三步:客户端收到随机数 Y,并进行公钥(证书)的验证,验证通过后会再生成一个随机数 Z,并用公钥进行加密,把加密后的随机数 Z' 发送给服务端,同时使用 X+Y+Z 共同加密生成 密钥K1

第四步:服务端收到加密后的 Z' 后使用私钥进行解密,得到 Z,再用 X+Y+Z 共同加密生成 密钥K2

第五步:客户端用公钥对 密钥K1 进行加密得到 K1',并传给服务端

第六步:服务端收到加密后的 K1' 用私钥解密得到 K1,与第四步生成的 密钥K2 进行比对,比对一致

第七步:服务端把密钥验证一致后的确认消息返回给客户端,连接建立完毕

HTTPS:一切为了安全

HTTPS 为了保证传输的安全,分别使用了非对称加密和对称加密两种方式,为什么要用这么复杂的加密方式呢 ?

1.对称加密已经够安全了,但是不能解决密钥传递的问题,如果服务端给客户端密钥,那相当于告诉全天下密钥是多少,那HTTPS就是摆设了(因为加密解密算法是公开的),如果客户端给服务端密钥,那如果被截获后,客户端的安全就会收到威胁

2.非对称加密也够安全吧,但是因为大家持有的公钥都是一样的,服务端没办法确认发送过来的消息是不是客户端的真实意愿

3.于是就有了对称加密与非对称加密结合的方式,首先客户端用非对称加密方式把密钥传给服务端,就算被截获,因为外部没有解密对应的私钥,所以是安全的;然后双方再使用约定好的对称密钥进行通信

但是 HTTPS 并不完美,因为存在加密解密的流程,所以性能上肯定不如 HTTP

发布了3 篇原创文章 · 获赞 3 · 访问量 122

猜你喜欢

转载自blog.csdn.net/epwqgdnbrh/article/details/105020866