(tcp protocol) 断开连接时候的状态迁移

假设A->B已建立了连接,A为c端,B为s端。目前两端的状态为established。同时走的是正常的fin流程,而不是reset(发送缓冲区中有数据,直接closesocket会造成此情况,此时的连接已经处于错误状态)。

c端主动关闭连接(s端一样的流程)。c端发出fin,同时c端的状态进行了改变。

C established->fin_wait_1 (send fin)

s端收到了fin后,返回fin ack,同时状态由established转为close_wait。

S established->close_wait (recv fin and send fin ack)

c端收到了fin ack后,转为fin_wait_2状态,等待s端的关闭。在这儿假如长久没有收到fin ack,则c端会重新发送fin来再次关闭连接。

C fin_wait_1->fin_wait_2 (recv fin ack)

至此由C端至S端的写通道已关闭。TCP是全双工的,所以各自的通道必须各自来关闭。发送了fin之后,C端将无法再次发送数据包至S,而S至C的通道没有被关闭,也就代表着S端可以继续向C端发送数据包,tcp处于半连接状态。

所以在此情况下,虽然c端已经关闭了自己的连接,但是s端仍然可以向c端发送数据包,这样是因为为了防止一段关闭后造成的数据丢失。也就是send函数是无法得知对方已经关闭了连接,仍旧可以向对方传输数据。而recv不一样,当对方关闭了连接后,那么recv会立刻返回0值,正常流程我们应该讲处于close_wait状态的socket关闭,那么就要走另一端的fin流程:

s端被动关闭连接,s段发出了fin,状态发生了改变。

S close_wait->last ack (send fin)

c端收到了s端的fin后,改变状态,同时发出fin ack。

C fin_wait_2->time_wait (recv fin and send fin ack)

s端收到了fin ack后,整个连接关闭

S last_ack->closed (recv fin ack)

仔细看以上的流程,3部中总有一个中间的状态,对于C,发出了fin后,s的状态转为了close_wait状态;对于S,发出了fin后,c转为了time_wait状态。这两个状态比较特殊,在某些情形下会长时间处于该状态,特别是在某些服务器程序上,假设有大量的连接处于这种中间状态,那么后果将是灾难性的。

为何要有这么两个中间状态?下面完全是个人的理解了,有可能有差错,再次仅仅是做个笔记。

首先,我们可以看出,上述2个状态均为收到了fin后的状态,而收到了fin后,自身的状态立刻发生改变,同时发出fin ack。也就是说,发出fin的一方,在正常的流程下,肯定会收到fin ack。那么我们仔细想想,假如该fin ack由于种种情况丢失了,那么主动关闭的一方会重发fin,如果没有上述两个中间状态,那么没法应付这种情况。

还有一个原因,仅仅是针对于time_wait状态。处于该状态的套接字,是主动关闭的一方收到了被动关闭一方的fin后产生的状态,将会持续2MSL的事件(最大分节生命期,数据包在互联网上最长的生存时间)。假设在被动关闭一方发送fin前,某个包超时了,主动方长久没有收到确认包,该包将会被重发,假设之前的套接字的相关信息被重用了,那么该数据将会被新连接收到,那么就错乱了。为了避免该情况,设置了time_wait状态。

一个正常连接在关闭后(closesocket),会有以下几种情况。

  1. 和上述流程一样的正常关闭流程
  2. 假设读缓冲区中数据没有读完后直接关闭,则将会重置连接。另外一端假设继续发送数据包,将会被回应rst。
共 0 条回复
暂时没有人回复哦,赶紧抢沙发
发表新回复

作者

sryan
today is a good day