TCP连接管理
目录
- TCP连接
- TCP连接释放
TCP连接
上图为TCP连接建立的过程
B的TCP服务器进程首先创建传输控制块,准备接收客户端进程的连接请求.
A的TCP客户端进程首先创建传输控制块, 然后向B发送连接请求的报文段,此时首部SYN = 1,同时选择一个seq = x. TCP规定,SYN报文段不能携带数据,但要也要消耗一个序号.这次TCP客户端进程进入SYN-SEND状态.
B收到连接请求后, 如同意连接, 则向A发送确认. 在确认的报文段中应把SYN和ACK都置为1,确认号ack = x + 1, 同时也为自己选定一个序号seq = y.注意:这个报文段也不能携带数据,但是要消耗一个序号.此时TCP服务器进入SYN-RCVD状态.
TCP客户端收到B的确认后, 还要向B确认.确认的报文段的ACK置1,确认号ack = y+1,而自己的序号seq = x + 1.注意:ACK报文可以携带数据.如果不携带数据就不用消耗序号.此时TCP连接已经建立.A进入ESTALISHED状态.
当B收到A的确认后, 也进入ESTABLISHED状态.
上面的连接建立过程叫做三次握手.
三次握手的原因是为了防止已失效的连接请求报文段突然又传送到B,因此产生错误.
现在假定A发送出去的第一个连接请求报文段在某些网络结点长时间滞留了,以致延误到连接释放后的某个时间才到达B.本来这个是一个已经失效的报文段.但是B收到此有效的报文段后, 就误认为A又发出了
一次连接请求.于是向A发送确认报文段,同意建立连接.如果假设不采用三次握手, 那么B发出确认,新的连接就建立了.由于A并没有发出建立连接的请求, 因此不理睬B的确认,也不会向B发送数据.但B却以为新的连接已经建立,一直等待A发送数据.这样B的许多资源就白白浪费了.
如果采用三次握手的话, A不会向B发出确认.B由于收不到确认,就不知道A并没有要求建立连接.
TCP连接释放
上图为TCP连接释放过程
A的应用首先让其TCP发出连接释放的报文段, 并停止发送数据,主动关闭连接.A把连接释放报文段首部FIN置为1,其序号seq = u.这时A进入FIN-WAIT-1状态,等待B的确认.注意:FIN报文段即使不携带数据也要消耗一个序号.
B收到连接释放的请求后即发出确认,确认号为ack = u + 1,而这个报文段的序号为v.然后B进入CLOSE-WAIT状态.TCP服务器此时通知应用进程, 因此A到B的连接已经释放掉了.这时TCP连接处于半释放状态.即A已经没有要传送数据了.但A仍然接收数据,因为B到A的连接还没有释放.
A收到B的确认后.进入FIN-WAIT-2状态,等待B发送连接释放报文段.
若B已经没有数据要发送了, 其应用进程会通知TCP释放连接.这时B发出的来连接释放报文段必须时FIN = 1.这时B就进入了LAST-ACK状态,等待A的确认.
A收到B的连接释放报文后,必须对此报文发出确认.然后进入TIME-WAIT状态.现在TCP连接还没有释放.必须经过时间等待计时器设置的时间2MSL后, A才进入CLOSED状态.
TIME-WAIT必须等待两个MSL的原因:
- 保证A的最后一个确认报文段能够到达B
- 防止已失效的连接请求报文段出现在本地连接中.
参考资料
计算机网络