抓包分析

实验主要两个内容：

1. TCP三次握手和四次挥手过程
2. 分析HTTPS的TLS握手过程

TCP三次握手

windows10下wireshark工具，浏览器访问47.93.242.17端口443，即HTTPS协议，源端口54407

过滤规则 ip.dst ==47.93.242.17 or ip.src == 47.93.242.17 过滤ip tcp.port == 80 过滤端口，无论是源端口还是目的端口 三次握手过程

1. 第一次握手tcp报文段 报文段分析： 源端口：54407 目的端口：443 sequence number：229919303 SYN标志为1 窗口大小：64240 校验和 可选项 时间戳
2. 第二次握手 报文段分析： 源端口：443 目的端口：54407 sequence number： 311700020 ackonwledgment number： 229919304 flags：SYN=1 ACK=1 窗口大小：29200 校验和 可选项 时间戳
3. 第三次握手 报文段分析： 源端口：54407 目的端口：443 sequence number： 229919304 ackonwledgment number： 311700021 flags：ACK=1 窗口大小：513 校验和 可选项 时间戳
4. **总结：**第一次握手客户端向服务端发送SYN报文段，其中包含了自己的seq=x；第二次握手服务端向客户端发送SYN+ACK报文段，其中seq=y，ack=x+1；第三次握手客户端向服务端发送ACK报文段，其中seq=x+1，ack=y+1.

TCP四次挥手

四次挥手 这里惊奇的发现，四次挥手实际上只进行了三次，第二次和第三次合并了！ 第一次挥手 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hb5o14s6-1645970090549)( )] 第二次、第三次挥手 第四次挥手

总结 第一次挥手，客户端向服务端发送ACK+FIN报文段，包含了seq=x，ack=上一次发送ack；第二、三次挥手，服务端向客户端发送FIN+ACK报文段，包含了seq=y，ack=x+1；第四次挥手，客户端向服务端发送ACK报文段，seq=x+1，ack=y+1，客户端进入TIME_WAIT状态，服务端接收到ACK后CLOSE 三次挥手的原因 因为Linux的延迟ACK机制？感觉不对 实际原因是，服务端实现过程是，在接收到到客户端的断开连接请求之后，马上调用close，因此ACK和FIN合并了。

HTTPS过程分析

TLS协议 TLS协议本身可以分为上下两层：TLS握手层协议 TLS记录层协议 TLS握手协议 基于ECDHE（椭圆曲线diffie-hellman秘钥交换） 第一次握手 client hello 客户端发送client Random 第二次握手 server hello、Certificate、Server Key Exchange、Server Hello Done；服务端发送server random，服务端公钥 第三次握手client key exchange、 change cipher spec、 encryted Handshake Message客户端收到了服务端的证书后，自然要校验证书是否合法，如果证书合法，那么服务端的身份就是没问题的。客户端会生成一个随机数作为客户端椭圆曲线的私钥，然后再根据服务端前面给的信息，生成客户端的椭圆曲线公钥，然后用「Client Key Exchange」消息发给服务端。至此，双方都有对方的椭圆曲线公钥、自己的椭圆曲线私钥、椭圆曲线基点 G。于是，双方都就计算出点（x，y），其中 x 坐标值双方都是一样的，前面说 ECDHE 算法时候，说 x 是会话密钥，但实际应用中，x 还不是最终的会话密钥。最终的会话密钥，就是用「客户端随机数 + 服务端随机数 + x（ECDHE 算法算出的共享密钥） 」三个材料生成的。 然后发送[ Change Cipher Spec] 消息，告诉服务端后续改用对称算法加密通信。 最后把之前发送的数据做一个摘要，再用新生成的对称密钥加密一下，让服务端做个验证，即[ Encrypted Handshake Message] 第四次握手发「Change Cipher Spec」和「Encrypted Handshake Message」消息，如果双方都验证加密和解密没问题，那么握手正式完成。于是，就可以正常收发加密的 HTTP 请求和响应了。