知识梳理系列之六——HTTPS的握手过程

本文详细介绍了HTTPS的握手过程,包括使用RSA加密算法和DH加密算法的步骤。通过解析RSA算法的数学原理,解释了密钥交换的安全性。同时,提到了DH算法作为更安全的选择,用于HTTPS握手,确保通信的隐私和安全。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

面中金问到,记录下:

使用RSA加密算法的HTTPS握手过程

1. 先梳理下RSA算法:

了解下素数、互素、欧拉公式、费马小定理:

  • 如果一个正整数只能被自身和1整除,那么这个数是素数(或者称为质数);
  • 如果两个或两个以上的正整数的公因数只有1,那么称这些数互素(或者称为互质);
  • 已知两个素数P1、P2,它们的乘积: n = P 1 × P 2 ; n = P1 \times P2; n=P1×P2;欧拉公式: 欧拉函数的值是所有小于或等于n的正整数中与n互质的数的个数。 Φ ( n ) = ( P 1 − 1 ) ⋅ ( P 2 − 1 ) ; \Phi(n) = (P1-1) \cdot (P2-1); Φ(n)=(P11)(P21);
  • 费马小定理:假如m是一个整数,n是一个质数,那么 mn- mn的倍数,可以表示为:
    m n ≡ m   ( m o d n ) 或   m ( n − 1 ) ≡ 1   ( m o d n ) 又 ∵ n 是 质 数 , ∴ ( n − 1 ) = Φ ( n ) m Φ ( n ) ≡ 1   ( m o d n ) \begin{aligned} & m^n \equiv m \ (mod \quad n) \\ & 或 \ m^{(n-1)} \equiv 1 \ (mod \quad n) \\ & 又\because n是质数,\therefore (n-1) = \Phi(n) \\ & m^{\Phi(n)} \equiv 1 \ (mod \quad n) \\ \end{aligned} mnm (modn) m(n1)
<think>嗯,用户之前让我整理软件测试面试中的计算机网络知识,现在他们又专门问了TCP的三次握手和四次挥手。我需要先确认用户的需求是什么。可能他们正在准备面试,或者在实际工作中遇到了相关问题,需要深入理解这两个过程。 首先,用户之前得到了一个结构化的回答,里面提到了三次握手和四次挥手,但可能现在需要更详细的解释。用户可能希望了解这两个过程的每个步骤,为什么需要三次握手而不是两次,四次挥手又是为什么,以及这些过程在软件测试中的实际应用场景。 接下来,我需要考虑如何组织内容。应该分步骤解释三次握手和四次挥手,使用比喻或实际例子帮助理解。同时,结合软件测试的上下文,说明这些知识在测试中的实际应用,比如如何设计测试用例,或者如何排查网络问题。 另外,用户可能对状态转换和常见问题感兴趣,比如TIME_WAIT状态,或者半关闭状态。需要解释这些状态的原因和影响,以及测试时需要注意的地方,比如端口耗尽或资源泄漏。 还要注意用户提到的测试场景,比如验证连接稳定性或检测端口耗尽。可能需要给出具体的测试策略或工具使用建议,比如使用netstat或抓包工具来观察握手和挥手过程。 最后,确保回答结构清晰,逐步引导用户理解每个步骤,并关联到实际测试工作中。避免使用过于专业的术语,但保持准确性,必要时使用比喻或示例。同时,检查之前的回答是否覆盖了所有要点,避免重复,但补充更详细的信息。</think>以下是关于**TCP三次握手与四次挥手**的详细解析,结合测试场景与常见面试问题说明: --- ### **一、TCP三次握手(建立连接)** #### **核心过程** 1. **第一次握手**(客户端 → 服务器) - 客户端发送`SYN=1`(同步请求),随机生成初始序列号`seq=x` - **状态变化**: 客户端进入`SYN_SENT`状态 *测试关注点:客户端能否发出SYN包?网络是否可达?* 2. **第二次握手**(服务器 → 客户端) - 服务器返回`SYN=1, ACK=1`,确认号`ack=x+1`,并发送自己的初始序列号`seq=y` - **状态变化**: 服务器进入`SYN_RCVD`状态 *测试场景:服务器未响应SYN-ACK时,客户端重试机制验证* 3. **第三次握手**(客户端 → 服务器) - 客户端发送`ACK=1`,确认号`ack=y+1`,序列号`seq=x+1` - **状态变化**: 双方进入`ESTABLISHED`状态(连接建立) *测试工具:通过Wireshark抓包验证三次握手完整性* #### **为什么需要三次握手?** - **根本原因**:防止历史连接初始化导致的资源浪费 - **测试关联**: - 设计测试用例模拟网络延迟导致的旧SYN包干扰 - 验证服务端对重复SYN包的处理逻辑 --- ### **二、TCP四次挥手(断开连接)** #### **核心过程** 1. **第一次挥手**(主动关闭方 → 被动关闭方) - 发送`FIN=1`,序列号`seq=u` - **状态变化**:主动方进入`FIN_WAIT_1` - *测试关注点:主动关闭方是否触发FIN包?* 2. **第二次挥手**(被动关闭方 → 主动关闭方) - 返回`ACK=1`,确认号`ack=u+1` - **状态变化**:被动方进入`CLOSE_WAIT`,主动方进入`FIN_WAIT_2` - *测试场景:验证被动方在CLOSE_WAIT状态能否继续发送数据* 3. **第三次挥手**(被动关闭方 → 主动关闭方) - 发送`FIN=1`,序列号`seq=v` - **状态变化**:被动方进入`LAST_ACK` - *测试工具:使用`netstat`监控LAST_ACK状态数量* 4. **第四次挥手**(主动关闭方 → 被动关闭方) - 返回`ACK=1`,确认号`ack=v+1` - **状态变化**: 主动方进入`TIME_WAIT`(等待2MSL后关闭) 被动方收到ACK后关闭连接 - *测试问题:高并发下TIME_WAIT过多导致端口耗尽如何解决?* #### **为什么需要四次挥手?** - **本质原因**:TCP连接是全双工的,需双方独立关闭各自通道 - **测试关联**: - 模拟服务端未发送FIN包导致客户端长时间处于FIN_WAIT_2 - 验证`SO_REUSEADDR`参数对TIME_WAIT状态的优化效果 --- ### **三、关键测试场景与面试问题** #### **1. 连接建立失败分析** - **可能原因**: - 防火墙拦截SYN包(抓包验证) - 服务器backlog队列满(查看`ss -s`统计) - **测试方法**: 使用`telnet IP端口`或`nc`命令模拟连接尝试 #### **2. 半关闭状态(Half-Close)** - **场景**:一方发送FIN后仍可接收数据 - **测试用例**: 验证客户端FIN后服务端能否继续返回响应 #### **3. 网络延迟导致的重传** - **抓包分析**: 观察SYN/FIN包的重传次数与间隔(默认重试5次) #### **4. 高频面试题** - “TIME_WAIT状态为什么要等待2MSL?” **答案**: 1. 确保被动方的ACK丢失后能重传FIN包 2. 让旧连接的报文在网络中彻底消失 - “什么情况下会看到大量CLOSE_WAIT状态?” **答案**:服务端代码未正确调用`close()`(资源泄漏) --- ### **四、可视化辅助理解** ``` 三次握手: Client         Server   SYN(x) ———→             ←——— SYN(y)+ACK(x+1)   ACK(y+1) ———→ 四次挥手: Client         Server   FIN(u) ———→             ←——— ACK(u+1)           ←——— FIN(v)   ACK(v+1) ———→ ``` --- ### **总结** - **测试工程师需掌握**: 1. 通过抓包工具验证握手/挥手流程 2. 结合日志分析连接异常(如连接超时、重置) 3. 设计边界用例:快速重启服务、模拟网络闪断 - **典型故障**: `Too many open files`(文件描述符耗尽)、`Address already in use`(TIME_WAIT未释放)
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值