TCP是一种可靠的、面向连接的协议,用于实现可靠的数据传输。它通过确认机制、重传机制和流量控制机制等机制来保证数据的可靠传输。
那么TCP连接的销毁,为何是四次挥手,而不是三次挥手呢?今天我们一起聊一聊。
为何不使用三次挥手
我们来看看,采用如下的方式,进行三次挥手操作:
我们知道TCP握手是三次,那么挥手为何不采用三次的方式呢。
看上图,我们按照服务端ACK和FIN合并一起发送至客户端的方式,即在服务端收到客户端的FIN请求后,服务端一次性发起数据请求,确认客户端的FIN请求已收到,同时向客户端发起FIN请求。
此时,若服务端仍存在数据需要发送至客户端,因服务端已准备关联,不能再发数据,所以数据是无法发到客户端的。
例如:服务端需要给客户端的数据有三部分:A部分、B部分、C部分,在A部分和B部分发到客户端后,C部分还未发送,收到了客户端的FIN请求,服务端回复了客户端ACK确认和FIN请求,那么C部分的数据,是无法发送至客户端的,此时,客户端仅收到了A部分和B部分的数据,收到的数据不完整。
可见,直接采用三次挥手的方式,是存在明显的问题的。
四次挥手
先看看四次挥手的图示:
发起方:主动发起链路关闭的一方,一般为客户端,但也可能为服务端,上图是以客户端为发起方举例。
接收方:被动接受链路关闭的一方,一般为服务端,但也可能为客户端,上图接收方为服务端举例。
第一次挥手:发起方发起链路关闭请求,seq=a,代表发起方使用的请求序号为a,FIN请求发送后,发起方不能再发送数据到接收方,此时发起方状态变为FIN-WAIT1。
第二次挥手:接收方在收到发起方的第一次挥手后,向发起方发起第二次挥手操作,seq=b,代表接收方使用的请求序号为b;ack=a+1,即值为发起方请求序号+1。接收方发送第二次挥手后,状态变为CLOSE-WAIT状态,此时接收方仍可以发送数据到发起方。发起方在收到第二次挥手后,状态变为FIN-WAIT2。
第三次挥手:接收方等待一定的时长,一般最大时间TCP_DELACK_MAX=200MS,最短时间TCP_DELACK_MIN=40MS,具体时间根据何时有数据需发送而定。延时确认结束后,接收方向发起方发起第三次挥手,seq=b,代表接收方使用的请求需要序号为b;ack=b+1,即值为发起方请求序号+1。接收方在发起第三次挥手后,状态变为LASK-ACK。
第四次挥手:发起方在收到接收方的第三次挥手后,向接收方发起第四次挥手,seq=a+1,代表发起方使用的请求序号为a+1,即第一次发起挥手序号+1;ack=b+1,接收方第三次挥手的请求序号为b,所以确认时值为b+1。发起方发送完ACK请求后,状态变为TIME-WAIT,在等待两个MSL的时间后,状态再变为CLOSE。接收方在收到发起方的第四次挥手后,状态变为CLOSE。
ESTABLISHED状态:链路是正常的,可以发送数据和接收数据。发起方和接收方均有这个状态。
CLOSE状态:链路已关闭,原来占用的端口,可以被回收,重新使用。发起方和接收方均有这个状态。
发起方的三个专属状态:
FIN-WAIT1状态:发起方发送FIN请求后的状态,此时,发起方不能再向接收方发送数据。
FIN-WAIT2状态:发起方在收到接收方第二次挥手后的状态。
TIME-WAIT状态:发起方发起第四次挥手后的状态。接收方两个专属状态:
CLOSE-WAIT状态:接收方在收到发起方的第一次挥手,即接收到FIN请求后的状态。
LAST-ACK状态:接收方在发起第三次挥手,即发起FIN请求后的状态。另外还有个状态:
CLOSING状态:CLOSE之前的状态,时间较短,很难看到。此状态有种特殊的场景下会出现,即客户端和服务端同时发起第一次挥手操作的情况下,两边均进入FIN-WAIT1状态,期待接收到对方的ACK包,进入FIN-WAIT2状态,但却先接收到了对方的FIN包,这时就会进入CLOSING状态,然后给对方一个ACK,在收到对方的ACK包后,直接进入CLOSE状态。
四次挥手抓包
TCP延时处理机制
tcp存在延时确认机制,默认情况下,是开启的。
在使用没有带数据的ACK包时,网络效率是很低的,因为只有TCP的报文头20个字节和IP数据报的20个字节,没有携带数据报文。
为了解决网络效率低的问题,就有了TCK延时确认机制。
TCP的延时确认策略:
- 当有响应数据要发送时,ACK会随着响应数据一起立刻发送给对方。
- 当没有响应数据要发送时,ACK会延时一段时间,以等待是否有响应数据要一起发送。
- 当在延时等待发送ACK期间,对方第二个数据报文又到了,这时就会立刻马上发送ACK。
TCP延时确认机制的优点:
- 减少不必要的确认包:通过延迟发送确认包,TCP可以合并多个数据包到一个确认包中,减少了网络中不必要的确认包数量,降低了网络拥塞。
- 提高网络传输效率:通过减少不必要的确认包,TCP延迟确认机制提高了网络传输的效率,降低了网络延迟,提高了应用程序的性能。
- 自动适应网络环境:TCP延迟确认机制能够根据网络环境的变化自动调整延迟时间,适应不同的网络环境和数据传输需求。
TCP延时确认机制的缺点:
- 可能会增加延迟:由于延迟确认机制的存在,接收端可能会延迟发送确认包,从而导致应用程序的响应时间增加。对于对延迟要求较高或实时性要求较高的应用程序,TCP的延迟确认机制可能不太适用。
- 不适合所有场景:TCP的延迟确认机制适用于数据量较大、数据传输速率较慢或网络环境较差的场景。对于数据量较小、数据传输速率较快或网络环境较好的场景,该机制可能不太适用。
- 需要合理配置:TCP的延迟确认机制需要合理配置延迟时间,如果延迟时间设置过长或过短,可能会影响网络传输性能。
TCP的延迟确认机制是一种有效的优化技术,可以显著提高网络传输的效率和性能。但在实际应用中,需要根据具体场景和需求进行合理配置和使用。
现实中看到的三次挥手
现实场景中,是否会存在三次挥手的情况呢?我们假定一种场景:
- 使用了TCP的延时确认机制
- 没有要发送的数据
在发起方发起第一次挥手后,接收方存在以上的场景,接收方准备发起ACK请求(第二次挥手),在接收方开启了TCP延时确认机制下,接收方等待了200MS,仍没有数据要发送,此时原接收方第三次挥手的FIN请求,会和ACK请求合并后,一次性发送至接收方。
在实际应用中,是否会存在直接使用一次挥手,直接关闭链接呢?
如客户端在正确接收服务端的响应后,直接发送RST,ACK的挥手请求?
遇到这种情况,是否属于存在问题?又应当如何应对呢?
欢迎私信或留言讨论。
暂无评论内容