[TCP]大白话解释TCP的三次握手及四次挥手及为什么主动关闭方要等待2MSL

本文以通俗易懂的语言介绍了TCP的三次握手和四次挥手过程。三次握手是确认双方收发能力的过程,四次挥手是断开连接的过程。文中还解释了四次挥手中的一些问题,如第二次和第三次挥手为何不能合并、主动发起方为何要等待2MSL时间等,并抛出一个关于2MSL时间的问题供读者思考。

声明: 本文不保证每个定义绝对严谨, 只是通过更加通俗易懂的语言来让阅读者更好的理解三次握手及四次挥手的过程!!!

首先我们来明白几个定义:

1. FIN: 请求关闭报文

2. SYN: 请求建立连接

3. ACK: 确认收到

4. MSL: 最大报文生存时间

三次握手:

三次握手理解起来比较简单, 说白了就是一个确认双方都能发送且都能接收的一个过程.

第一步: 客户端想要与服务器建立连接, 于是向服务器发送SYN报文请求连接.

第二步: 服务器收到客户端的连接请求之后, 服务器向客户端发送确认报文ACK及请求连接报文SYN

第三步: 客户端收到服务器的连接请求, 向服务器发送确认报文ACK

然后我们用通俗易懂的话来说一下这三步都在做什么:

第一步让服务器知道客户端能够发送, 第二步让客户端知道服务器能够接收并且能够发送, 第三步在服务器接收到ACK之后,服务器知道了客户端能够发送, 至此双方都能确认了对方能够收和发, 接下来就是愉快的互相收发数据的过程啦~

四次挥手:

四次挥手是一个双方断开连接的过程, 这个过程中大家要理解的点有三个:

1. 为什么第二次挥手和第三次挥手不能合并为一次

2. 第二次挥手和第三次挥手之间的等待是在干什么

3. 主动发起方为什么要在第四次挥手之后等待2MSL的时间

我们逐步来解释:

第一步: 客户端做为主动发起方想要与服务器断开连接, 所以向服务器发送FIN报文

第二步: 服务器收到客户端的FIN报文, 向客户端发送ACK确认报文, 也就是说服务器告诉客户端说我收到你的关闭请求了

第三步: 服务器等待时间结束之后, 向客户端发送FIN报文, 告诉说客户端我请求关闭

第四步: 客户端收到服务器的FIN报文之后, 向服务器发送ACK确认报文, 告诉服务器说我也收到了你的关闭请求了. 此时如果服务器收到了ACK报文,服务器就关闭了, 而客户端还要等待2MSL的时间之后才能关闭

问题:

1. 为什么第二次跟第三次不能合并, 第二次和第三次之间的等待是什么?:

当服务器执行第二次挥手之后, 此时证明客户端不会再向服务器请求任何数据, 但是服务器可能还正在给客户端发送数据(可能是客户端上一次请求的资源还没有发送完毕), 所以此时服务器会等待把之前未传输完的数据传输完毕之后再发送关闭请求.

2. 主动发起方为什么最后要等待2MSL的时间:

上边我们说了服务器收到了最后一次的ACK报文之后就会关闭, 那客户端是不能知道服务器是否收到了这次ACK的, 所以客户端只能在这等待, 如果服务器在"超时时间"内真的没有收到最后一次的ACK,就会重新发送一次FIN, 那么在网络极端情况下(网络没断, 但是速度极慢, 需要整整1MSL的时间才能把报文发送过去),这次重发FIN需要1MSL的时间, 这一来一回需要的时间总和为:服务器超时时间+1MSL, 那为了保险起见,直接让客户端等待2MSL的时间, 如果2MSL之内客户端没有收到重发的FIN, 则默认为服务器收到了最后一次ACK,此时客户端就可以执行关闭了.

ps: 经阅读者反馈, 最后的四次挥手仍然不够通俗易懂, 那我在此给大家描述一个场景来跟四次挥手过程做个对照"

A: 主动发起方(客户端)

B: 被动关闭方(服务器)

A和B正在互相收发数据, 在B最后一次数据没发送完的时候, A突然说"FIN", B此时赶紧回复一句"ACK", 然后因为B之前的一次数据还没有发送完毕,所以要继续发送最后一次的数据, 等发完之后,B也对A说"FIN", A回复说"ACK", 此时A并不知道B有没有收到"ACK",A就会在此时开始等待, B也不知道B发的"FIN"A有没有收到, B会在发送完"FIN"之后等待一个"超时时间",如果超时之后仍然没有收到A发来的ACK,B就会认为他发的FIN并有有被A收到, 此时B就会重新发送FIN给A, 而在极端网络情况下一个报文可能需要一整个MSL才能发送成功, 那A的等待时间就是1个超时时间+1MSL, 为了更稳妥起见, 协议直接制定为主动发起方等待2MSL的时间, 如果A在2MSL的时间内都没有收到B重新发送的FIN, 则默认为B收到了最后一次ACK, 就可以执行关闭.

关于最后为什么要等待2MSL, 再次做个补充:

首先我们要明白主动关闭方是在等待什么? 是在等待服务器可能会重发过来的FIN, 那这个FIN在极端网络情况下需要多久才能发过来呢? 1. 服务器的超时时间(超时时间内服务器等不到ACK就会重发FIN), 2. 重发FIN所需要的最长时间(1MSL), 那这么算就是1个超时+1个MSL, 为了更稳妥直接为2MSL的时间.

不知道以上文字有没有更好的帮助你理解了tcp的三次握手及四次挥手, 有写的不对的地方欢迎评论指正交流.

最后我再抛出一个问题给诸位读者:

当2MSL时间内主动发起方收到了服务器重新发送的FIN, 那么主动发起方是否会重置2MSL,即重新等待2MSL的时间?

再次补充:

查阅了一些资料, 有的资料写着某些情况下只有三次挥手, 即第二次确认报文和第三次请求关闭报文合并为一次了,这种情况发生在服务器方的数据确认全部发送完毕时.此次补充不做真实性保证,诸位看看就行~

 

 

<think>嗯,用户的问题是关于AOP中为什么所有类的所有法都被认为是连接点,需要简单易懂的解释。之前已经给过一个比较详细的回答,现在用户可能希望更简洁的理解。首先,我需要回顾之前的资料和引用内容,确保准确。根据引用[1],连接点是AOP中的一个关键概念,指的是程序执行中的特定点,比如法调用或执行。用户可能已经知道这些定义,但需要更直观的解释。用户提到的execution表达式(引用[2])可能涉及如何选择连接点,但这里的问题是为什么所有法都是潜在的连接点。首先,我需要从AOP的设计目标出发。AOP旨在处理横切关注点,比如日志、事务等,这些可能影响多个类和法。为了灵活性,AOP框架需要预先允许所有法作为可能的连接点,但实际是否应用通知则由切入点决定。这就像城市规划中预设所有路口可能需要信号灯,但实际只在需要的地安装。 然后要考虑动态代理的机制,如引用[1]提到的织入过程。动态代理在运行时拦截法调用,所以从技术角度看,所有法都可以被拦截,但只有匹配切入点的法会被增强。这解释为什么所有法都是连接点,但实际生效的只是被筛选的那部分。用户可能需要类比来理解。比如,所有电话都是潜在的接听对象,但只有特定号码会被转接到客服。这样,用户能明白连接点的“潜在”特性,而切入点才是实际筛选的条件。还要注意用户可能混淆连接点和切入点的区别。需要明确连接点是程序固有的执行点,而切入点是开发者定义的规则。所有法都是连接点,但只有部分被切入点选中,才会应用通知。引用[3]中的通知类型,说明通知是在这些连接点上执行的。最后,确保用简单语言,避免术语过多。比如,用“监控摄像头”比喻AOP框架,所有路口(法)都有摄像头,但只有违规行为(切入点匹配)会被记录(应用通知)。这样用户更容易理解为什么所有法都是连接点。</think>### 简单解释为什么所有法都是连接点? 想象你给整栋楼的每个房间都装了**监控摄像头**(比喻AOP框架),但只有特定房间会触发报警(比喻实际被增强的法)。所有法都是连接点的原因可以这样理解: --- #### 1. **监控摄像头原理** AOP框架像一套**全覆盖监控系统**: - **每个房间的门** = 每个类的法 - **开门动作** = 法被调用(天然存在的程序行为) - **摄像头安装** = 连接点的定义(所有门都默认有监控能力) 虽然所有门都有摄像头,但只有满足条件的门(如VIP房间、危险品仓库)才会真正触发报警(即执行通知逻辑)[^1]。 --- #### 2. **摄像头开不开由你决定** 用`@Pointcut`表达式(如`execution(* com.service.*.*(..))`)就像设置**报警规则**: ```java // 伪代码示例:只监控"com.service"包下的所有法 if (法属于com.service包) { 触发日志记录(); // 执行通知 } ``` **所有法**理论上都能被监控(都是连接点),但只有符合规则的法才会被实际处理[^2]。 --- #### 3. 举个生活例子 - **连接点**:超市所有商品(所有法) - **切入点**:收银员扫码枪(只扫描贴了条形码的商品) - **通知**:"嘀"一声响(增强行为) 所有商品都能被扫描(都是连接点),但只有被扫码枪扫到的商品会触发"嘀"声[^3]。 --- ### 关键总结 | 概念 | 比喻 | 说明 | |------------|--------------------|-------------------------------| | 连接点 | 所有商品/所有门 | 程序固有的执行节点 | | 切入点 | 扫码枪/报警规则 | 开发者定义的筛选条件 | | 通知 | "嘀"声/报警动作 | 在匹配的连接点执行增强逻辑 | --- ###
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值