本文主要探究tcp连接建立和释放过程中的状态演变

TCP连接的建立

三次握手

其实这张图已经说得很清楚了，客户端应用程序调用connect导致TCP发送一个SYN报文段，服务器端有一个监听套接字，该监听套接字收到SYN后，在待连接套接字队列中插入一项，然后发送SYN和对客户端确认的ACK(注意到ACK序列号总是和目前等待接收的序列号相同，此图中客户端发送的数据仅仅只有SYN 1个字节，所以在SYN的序列号J的基础上加1得到ACK的序列号，如果是其他数据报文段，那么报文段实际长度为多少，确认序列号就在该报文段的序列号基础上加多少)。客户端接收到该SYN和ACK以后,connect调用就成功返回，同时向服务端发送ACK。服务端接收到客户端发送的ACK之后，就将该连接从待连接套接字队列移到已连接套接字队列，等待accept调用从已连接套接字队列中取出。注意到accept总是对已连接套接字队列执行pop操作，因此accept得到的总是三路握手已完成，连接已建立的套接字，可以说即使不调用accept，这个已连接的套接字也已经存在于系统中。那么如果客户端在三路握手完成之后，accept调用之前crash掉怎么办，有些系统对accept之前crash掉的连接在内核层面已经解决，所以accept不会看到这种状态的出现，另一些对已经crash掉的连接调用accept则返回ECONNABORT错误，因此，最保险的做法是检查ECONNABORT错误，如果检查到该错误，直接进行下一次accept就行。

TCP连接的释放

四次挥手

从这个图可以看到客户端调用close，导致内核发送FIN主动发起结束连接的第一次挥手，同时进入FIN_WAIT1状态，服务器端接收到这个FIN之后发送ACK同时进入到CLOSE_WAIT状态，客户端接收到服务器对自己发送的FIN确认之后进入FIN_WAIT2状态，直到服务器程序也调用close导致TCP发送FIN，服务器进入LAST_ACK状态，客户端接收到这个FIN之后，发送对服务器端ACK的确认，同时进入TIME_WAIT状态。注意到由于TCP的延迟确认机制，如果服务器接收到客户端的FIN后，及时调用close，会使得对客户端的确认ACK和服务器自己的FIN同时发送，四次挥手变为三次。

首先看这个TIME_WAIT状态的必要性，第一，假定客户端发送给服务器的最后一个ACK丢包（这是完全有可能的），此时服务器会不断重传最后一个FIN，而客户端已经没有关于这个连接的任何信息，因此
会导致服务器处于错误状态。第二，如果客户端另一个进程马上占用掉刚刚关闭的套接字端口号，此时服务器在上一个连接中发送的数据由于网络拥塞发生延时，刚好到达该端口，被新的连接读取，就会出现串话现象。因此，这个TIME_WAIT状态一般持续2MSL时长，以保证上一个连接的所有报文都已发送完毕。和连接
操作永远是由客户端来主动发起的不同，主动关闭操作也可以由服务器来进行(例如WEB服务器)，因此当服务器应当避免TIME_WAIT的出现，或者缩短TIME_WAIT的时延，因为每一个TIME_WAIT都是没有释放资源的连接，此状态过多会导致服务器资源消耗严重，而且由于服务器必要时需要极短时间内重启，TIME_WAIT也会使得服务器由于端口仍被占用导致短时间内重启失败。

TCP连接中的一些临界情况

(1) A,B两个主机上的进程a,b已经通过TCP建立连接c，然后主机A,B之间的网络硬件连接出现故障，此时a进程会处于何种状态？

如果网络发生故障期间a进程永远不通过c连接对b进程发送数据，那么a进程就永远不会知道这件事的发生，A主机上为a,b两个进程建立的连接将会永远存在，这就好像a,b两个人只能通过有线电话联系，突然有一天连接到b的电话线断了，那么只要a不给b打电话，他就永远不知道b的电话线断了。这里有一个服务器编程中需要注意的问题是，如果服务器程序一直只是监听客户端的请求并作出回复，那么如果客户端在连接建立之后出现这种网络硬件故障导致连接实际不可用的情况，服务器将永远不会觉察到这种状态，实际不可用的连接c将会永远存在，其所占有的资源也就永远不会释放。那么如果故障期间a进程通过c给b进程发送数据呢？这时候TCP发送该数据，由于收不到b的确认，因此不断重传直到超时，(或者收到某个中间路由器回复的目的不可达），此时TCP就知道b已经挂了或者到b之间的网络硬件出现故障了，就可以通知应用程序处理这个事件。这也是TCP中KEEPALIVE存在的意义（如果一个连接上较长时间没有接受和发送数据，设置了KEEPALIVE选项的TCP会发送保活报文段，收到确认就当什么事儿也没有，如果超时或者收到destination unreachable，就通知应用程序处理该事件。那么如果拔掉网线后马上连接，而且保证此时a，b两个进程没有互相发送数据，会发生什么？答案是一切正常，就好像a,b两个人在电话线路断掉的时候互相之间没有打过电话，等到他们打电话时，电话线路已经被电信部门修好了，那么a，b就永远不知道电话线断掉的这个事情。

(2) A,B两个主机上的进程a,b已经通过TCP建立连接c，b进程一直在忙别的事情（比如阻塞在别的IO上面)，在此期间a进程调用了close，会发生什么？

如果b进程在忙完别的事情后马上读取c连接上的数据，那么读到FIN并调用close正常关闭连接。如果b进程还要往c连接上写数据会发送什么？第一次写数据是可以正常进行的，因为TCP是双向连接，因此b接收到a的FIN会认为a不会再发送数据，但并不以为着不能向a写数据，a进程接收到b发送来的（非期望的）数据后，会给b进程发送一个RST，只要b进程的下一次写操作发生在接收到a的RST之前，写操作一直会正常进行。直到接收到a的RST之后，在对a进行写操作，会返回返回EPIPE错误，同时出发SIG_PIPE信号（默认终止进程），因此服务器程序一般要忽略SIG_PIPE信号，并对EPIPE错误进行处理。

(3) A,B两个主机上的进程a,b已经通过TCP建立连接c,此时B主机突然断电宕机，然后马上重启（假定b程序是开机自动启动的服务器程序），此时a进程往b进程写数据会发生什么？

由于B的宕机，b进程不会再crash时给a发送FIN，所以a进程在给b进程写数据之前是不会感知到这一现象，等到B主机接收到a进程发来的数据时（这是可以的，因为B主机已经重启），b进程由于crash导致关于a，b之间的连接c的任何信息都已不存在，所以B主机找不到这样一个连接，因此会让a进程重新连接，a进程返回ECONNREST错误。