三次握手、四次挥手为什么

第一次握手： 建立连接。客户端发送连接请求报文段，将SYN位置为1，Sequence Number为x；然后，客户端进入SYN_SEND状态，等待服务器的确认；

为什么要三次握手？ “已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”

防止server一直等待，浪费资源…

为什么要四次挥手？

HTTP HTTPS原理

1) 客户端发出请求（ClientHello）：客户端提供以下信息：

a、支持的协议版本，比如TLS 1.0版 b、一个客户端生成的随机数，用于生成“对话密钥” c、支持的加密方法，比如RSA公钥加密。 d、支持的压缩方法。

2）服务器回应（ServerHello）

确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。 一个服务器生成的随机数，用于生成“对话密钥” 确认使用的加密方法，比如RSA公钥加密 服务器证书

注意：在有一些场景下，服务器也需要确认客户端的身份，就会再包含一项请求，要求客户端提供“客户端证书”。例如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包含了一张客户端证书。

3）客户端回应

验证服务器证书 取出服务器的公钥，向服务器发送以下信息： a、一个随机数，该随机数用服务器公钥加密，防止被窃听。 b、编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送 c、客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。 此时，整个握手阶段出现了三个随机数，第三阶段的随机数被称为“pre-master key”。客户端和服务端同时有了三个随机数，然后用事先商定的加密方法，各自生成本次会话所用的同一把“会话密钥”。

需要三个随机数的原因：

​”不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。 由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。 对于RSA密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。 pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么仅适用pre master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。”​

4）服务器的最后回应

使用pre-master key之后，计算生成本次会话所用的“会话密钥”。 向客户端最后发送以下信息： a、编码改动通知，标识随后的信息都将用双方商定的加密方法和密钥发送。 b、服务器端握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送 的所有内容的hash值，用来供客户端校验。 经过这4个过程，握手阶段全部结束，客户端与服务器进入加密通信。与普通的HTTP协议的区别在于，用了“会话密钥”加密内容。

重点在于 客户端进行了证书验证并获取了证书中的公钥、生成了3个随机数，并推导出了对称加密的秘钥，最后使用对称加密进行通信