了解TCP的三次握手四次挥手

说明

TCP的连接使用三次握手的方式，释放是使用四次挥手的方式，本文通过图文说明连接和释放的过程。

正文

连接

创建连接时，客户端A主动打开连接，服务器B被动打开连接。

B的TCP服务器进程先创建传输控制块TCB，准备接收客户进程A的连接请求。此时服务器就处于LISTEN（收听）状态，等待客户的连接请求。

A的TCP客户进程也是首先创建TCB，然后向B发送连接请求报文段。即发送SYN=1的报文段，TCP规定，SYN报文段不能携带数据，但要消耗掉一个序号，所以seq=u。此时A进入SYN-SENT（同步已发送）状态。

B收到A的连接请求报文段时，若同意连接，则向A发送确认，在确认报文段中将SYN和ACK都置为1，确认号为ack=x+1,这个报文段也不能携带数据，但同样也消耗掉一个序号，seq=y。此时B进入SYN-RCVD（同步收到）状态。

A收到B的确认后，还要向B给出确认，确认报文段的ACK置为1，确认号ack=y+1,序号seq=x+1.TCP规定，ACK报文段可以携带数据，不携带则不消耗序号。 这时，TCP连接已经建立，A进入SETABLISHED（已建立连接）状态。

B收到A的确认后，也进入SETABLISHED状态。

为什么A还要发送一次确认？
    这主要是为了防止已失效的连接请求报文段突然又传送到了B，产生错误。
    ex: A发出到第一个连接请求报文段，因在某些网络节点长时间滞留，A没有收到确认，于是A再重传一次连接请求，这次建立了连接。传输完成后释放连接，而之前滞留的请求在之后的某个时间到达B，此时B误认为A又发出一次新的连接，于是向A发出确认报文段，同意建立连接。假定不采用三次握手， 那么只要B发出确认，连接就建立，但A没有发出请求，不会对B的确认做出响应，也不会向B发送数据，但B一直在等待A发送数据，此时造成了B的资源的极大浪费。
    采用三次握手可以防止上述现象的发生。

释放

A应用进程先向其TCP发出连接释放报文段，并停止再发送数据，主动关闭TCP连接。

A发送释放报文段，FIN置为1，seq=u,（等于前面已传送过的数据最后一个字节的序号加1）。此时,A进入FIN-WAIT-1（终止等待1）状态。

B收到连接释放报文段后即发出确认，ack=u+1,seq=v，B进入CLOSE-WAIT（关闭等待状态）。TCP服务器进程通知高层应用进程，A到B方向连接释放，这时TCP出于半关闭状态，即A不再发送数据到B，但仍要接收B发送的数据，也就是说B到A的连接并未关闭。

A收到B的确认后，进入FIN-WAIT-2（终止等待2）状态，等待B发出释放连接。

B若无数据发送，则发送连接释放报文段，FIN=1，B进入LAST-ACK（最后确认）状态，等待A确认。

A收到B的连接释放报文段时后，必须对此发出确认，ACK=1，A进入TIME-WAIT（时间等待）状态。
此时，TCP连接并没有释放掉，必须经过时间等待计时器设置的时间2MSL后，A才能进入CLOSED状态。

为什么A必须等待2MSL的时间？
    第一，为了保证A发送的最后一个确认ACK报文段能够到达B。若ACK报文段丢失，B无法接收确认就重传了释放报文段，而此时如果没有等待就立即释放连接，A就无法接收B重传的FIN+ACK报文段，无法做出响应，B就无法按正常步骤进入CLOSED状态。
    第二，防止“已经失效的连接请求报文段”出现在本链接中。A发送完最后一个确认报文段后，再经过2MSL时间，就可以使本链接持续的时间内所产生的所有报文段都从网络中消失。这样可以使下一个新的连接中不会出现这种旧的连接请求报文段。

B只要收到A发出的确认，就进入CLOSED状态。B结束TCP连接的时间比A早一些。

若客户端和服务器已经建立连接，而客户端突然发生故障，这种情况的处理方式？
    TCP设有一个保活计时器（keepalive timer),服务器每收到一次客户的数据，就重新设置保活计时器，时间的设置通常是两小时，若两小时没有收到客户数据，就发送一个探测报文段，以后每隔75分钟发送一次，若一连发送10个探测报文段后仍无客户的响应，服务器就认为客户端处理故障，关闭连接。