抓包分析
实验主要两个内容：
- TCP三次握手和四次挥手过程
- 分析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过滤端口，无论是源端口还是目的端口
-
三次握手过程
-
第一次握手tcp报文段
报文段分析：
源端口：54407 目的端口：443 sequence number：229919303 SYN标志为1 窗口大小：64240 校验和 可选项 时间戳 -
第二次握手
报文段分析：
源端口：443 目的端口：54407 sequence number： 311700020 ackonwledgment number： 229919304 flags：SYN=1 ACK=1 窗口大小：29200 校验和 可选项 时间戳 -
第三次握手
报文段分析：
源端口：54407 目的端口：443 sequence number： 229919304 ackonwledgment number： 311700021 flags：ACK=1 窗口大小：513 校验和 可选项 时间戳 -
**总结：**第一次握手客户端向服务端发送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 请求和响应了。
-