C/C++教程

TCP三次握手与四次挥手

本文主要是介绍TCP三次握手与四次挥手,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

三次握手?

什么是三次握手?

一般情况下,连接是由客户端向服务端发起的。

第一次,客户端发送一个TCP数据报并将SYN同步位置为1,表示要建立连接,此时客户端会从CLOSED状态变为SYN_SEND状态;

第二次是服务端向客户端发送ACK,并且也将SYN置为1,一是表示自己收到了客户端建立连接的请求,并且从LISTEN状态变为SYN_RCVD,二是表示自己要建立连接;

当客户端收到服务端的ACK + SYN后,便会处于ESTABLISHED状态,并且发送第三次握手,表示自己收到了客户端的SYN。当服务端收到客户端的ACK后,便会从SYN_RCVD状态变为ESTABLISHED状态。

此时,双方的连接才算真正的建立。

为什么需要三次握手,而不是两次握手或者四次握手?

1.双方之所以进行多次握手,本质上还是因为信道是不可靠的。

由于TCP本身的要求是可靠连接,因此,客户端和服务端都必须确认,对方的收发能力都是正常的。因此,当第二次握手结束,客户端就可以确保服务端的收发能力正常,建立起连接,但是,服务端只能确保客户端的发送能力正常,因此必须等收到第三次握手的ACK后才会建立连接。

理论上四次五次都可以,但是三次就可以保证,所以是三次握手。

2.最好是奇数次握手

在socket编程时,服务端一般是先listen再accept。也就是说,发起连接的都是客户端。

谁发送最后的ACK,谁就会先建立连接。如果是偶数次,那么最后一次发送ACK的就是服务端。一般情况下,服务器比客户端的数量是1:n,众所周知,维护连接是需要付出时间和空间成本的,比如需要在内核建立相关结构体,如果服务器建立连接而客户端未建立,那么服务端可能会有多个空连接,这其实是不利于服务器的。

奇数次的握手是一种成本转移,即便出现空连接的现象,成本也会分摊在多个客户端身上,而不至于给服务端太大压力。

四次挥手

什么是四次挥手?

四次挥手与三次握手对应,是断开连接的过程。

由于双方之前进行了大量数据的交互,因此通过发送与确认机制就可以保证双方连接的断开。

首先断开的一方会发送FIN,便会处于FIN_WAIT_1状态,只要收到ACK后,便会处于FIN_WAIT_2状态。表示自己关闭了发送缓冲区,不再发送数据,但依然具有接受数据的能力。

而另一方收到FIN后,便会处于CLOSE_WAIT状态,即半关闭状态。它还可以继续发送数据,当数据发送完毕后,又会发送FIN,当收到ACK后便关闭自己的发送缓冲区。

这就是四次挥手。

为什么是四次?

我们在写客户端或者服务端时,都有一个close(fd),即关闭文件描述符的操作。每一个close代表的就是两次挥手。

如果说只有两次,也就是说一方在执行代码逻辑时没有执行close(fd),第一,会造成文件描述符泄露,第二,会发现这一端存在CLOSE_WAIT状态的连接,即半关闭状态。这种状态并没有释放连接相关的数据和结构体,其实也会造成内存泄漏。

为什么四次挥手后,主动断开连接的一方会先进入TIME_WAIT状态?

四次挥手的前三次,由于超时重传机制的存在,可以保证一定被对方收到,但是最后一次的ACK,是可能丢失的。如果四次挥手后,主动断开的一方直接CLOSED,那么将无法保证最后一个ACK被对方收到。

如果ACK丢失,对方就会重新发送FIN,如果处于CLOSED状态,将不会收到FIN,使得对方长时间处于LAST_ACK状态,并且多次发送FIN消耗资源。因此,通过TIME_WAIT,可以较大概率地保证最后一个ACK被对方收到。

另一个原因是可以保证信道上的数据尽可能的消散,防止断开连接后又立马重新建立连接后,产生的数据错误等问题。

为什么TIME_WAIT是2MSL?

2MSL是两个最大报文段寿命,ACK丢失最多是一个MSL,再次收到重传的FIN最多是一个MSL,因此2MSL可以尽可能的保证在CLOSE之前收到对方重传的FIN。

这篇关于TCP三次握手与四次挥手的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!