TCP拆连时状态迁移分析

从TCP协议角度来看，一个已建立的TCP连接有两种关闭方式，一种是正常关闭，即四次挥手关闭连接；还有一种则是异常关闭，我们通常称之为连接重置（RESET)。

首先说一下正常关闭时四次挥手的状态变迁，关闭连接的主动方状态变迁是FIN_WAIT_1-> FIN_WAIT_2 ->TIME_WAIT，而关闭连接的被动方的状态变迁是CLOSE_WAIT->LAST_ACK->TIME_WAIT。在四次挥手过程中ACK包都是协议栈自动完成的，而FIN包则必须由应用层通过closesocket或shutdown主动发送，通常连接正常关闭后，recv会得到返回值0，send会得到错误码10058。

除此之外，在我们的日常应用中，连接异常关闭的情况也很多。比如应用程序被强行关闭、本地网络突然中断(禁用网卡、网线拔出)、程序处理不当等都会导致连接重置，连接重置时将会产生RST包，同时网络络缓冲区中未接收（发送）的数据都将丢失。连接重置后，本方send或recv会得到错误码10053(closesocket时是10038)，对方recv会得到错误码10054，send则得到错误码10053(closesocket时是10054)。

操作系统为我们提供了两个函数来关闭一个TCP连接，分别是closesocket和shutdown。通常情况下，closesocket会向对方发送一个FIN包，但是也有例外。比如有一个工作线程正在调用recv接收数据，此时外部调用closesocket，会导致连接重置，同时向对方发送一个RST包，这个RST包是由本方主动产生的。

shutdown可以用来关闭指定方向的连接，该函数接收两个参数，一个是套接字，另一个是关闭的方向，可用值为SD_SEND,SD_RECEIVE和SD_BOTH。方向取值为SD_SEND时，无论socket处于什么状态(recv阻塞，或空闲状态)，都会向对方发送一个FIN包，注意这点与closesocket的区别。此时本方进入FIN_WAIT_2状态，对方进入CLOSE_WAIT状态，本方依然可以调用recv接收数据；方向取值为SD_RECEIVE时，双发连接状态没有改变，依然处于ESTABLISHED状态，本方依然可以send数据，但是，如果对方再调用send方法，连接会被立即重置，同时向对方发送一个RST包，这个RST包是被动产生的，这点注意与closesocket的区别。

从函数调用上来分析（msdn)：一旦完成了套接字的连接，应当将套接字关闭，并且释放其套接字句柄所占用的所有资源。真正释放一个已经打开的套接字句柄的资源直接调用closesocket即可，但要明白closesocket的调用可能会带来负面影响，具体的影响和如何调用有关，最明显的影响是数据丢失，因此一般都要在closesocket之前调用shutdown来关闭套接字。

shutdown:为了保证通信双方都能够收到应用程序发出的所有数据，一个合格的应用程序的做法是通知接受双发都不在发送数据！这就是所谓的“正常关闭”套接字的方法，而这个方法就是由shutdown函数，传递给它的参数有SD_RECEIVE,SD_SEND,SD_BOTH三种，如果是SD_RECEIVE就表示不允许再对此套接字调用接受函数。这对于协议层没有影响，另外对于tcp套接字来说，无论数据是在等候接受还是即将抵达，都要重置连接（注意对于udp协议来说，仍然接受并排列传入的数据，因此udp套接字而言shutdown毫无意义）。如果选择SE_SEND,则表示不允许再调用发送函数。对于tcp套接字来说，这意味着会在所有数据发送出并得到接受端确认后产生一个FIN包。如果指定SD_BOTH，答案不言而喻。

closesocket:对此函数的调用会释放套接字的描述，这个道理众所周知（凡是经常翻阅msdn的程序员），因此，调用此函数后，再是用此套接字就会发生调用失败，通常返回的错误是WSAENOTSOCK。此时与被closesocket的套接字描述符相关联的资源都会被释放，包括丢弃传输队列中的数据！！！！对于当前进程中的线程来讲，所有被关起的操作，或者是被挂起的重叠操作以及与其关联的任何事件，完成例程或完成端口的执行都将调用失败！另外SO_LINGER标志还影响着closesocket的行为，但对于传统的socket程序，这里不加解释。因此可以可以看出shutdown对切断连接有着合理的完整性。

下面从tcp协议上来分析shutdown和closesocket的行为（behavior)：closesocket或shutdown(使用SD_SEND当作参数时）,会向通信对方发出一个fin包，而此时套接字的状态会由ESTABLISHED变成FIN_WAIT_1，然后对方发送一个ACK包作为回应，套接字又变成FIN_WAIT_2，如果对方也关闭了连接则对方会发出FIN，我方会回应一个ACK并将套接字置为TIME_WAIT。因此可以看出closesocket,shutdown所进行的TCP行为是一样的，所不同的是函数部分，shutdown会确保windows建立的数据传输队列中的数据不被丢失，而closesocket会冒然的抛弃所有的数据，因此如果你愿意closesocket完全可以取代shutdown,然而在数据交互十分复杂的网络协议程序中，最好还是shutdown稳妥一些！

关闭时状态转变:

client:   Fin_wait_1 ->Fin_wait_2 -> Time_wait -> closed

server: Close_wait -> Last_ack ->closed

 

Fin_wait_1 发生在client 发出Fin包后, 并等待server 回 ack 时.

Fin_wait_2 发生在client收到ack包后, 并等待server发出Fin包时.

Time_wait 发生在client收到Fin包并发出ack包后, 在等待2msl的时间时.

Close_wait 发生在server收到client的fin包并且发出ack包后以及自己主动关闭发出fin包前.

Last_ack发生在server发出fin包后, 并等待client回ack时.

 

经常出现的状态组合:

·client:fin_wait_2;  server: close_wait

原因: 当client close了,但是server忘记close的时候, 即server在收到client的fin后并没有发送fin包给client, 导致自己处于close_wait状态, 而client在等待server的fin包,处于fin_wait_2状态.

 

· client:time_wait;server: closed

原因: 当client, server都close了, client必须处于time_wait状态等待2msl时间. 于是如果server是处于高并发短连接的状态, 就会有大量的time_wait的连接霸占着. 使得其他的连接连接不了.

 

解决方法:用linger强制关闭可以解决此问题(用rst代替fin)，但是linger会导致数据丢失，linger值为0时是强制关闭,无论并发多少多能正常连接上,如果非0会发生部分连接不上的情况!（可调用setsockopt设置套接字的linger延时标志，同时将延时时间设置为0。）

TCP/IP的RFC文档。TIME_WAIT是TCP连接断开时必定会出现的状态。是无法避免掉的，这是TCP协议实现的一部分。在WINDOWS下，可以修改注册表让这个时间变短一些，time_wait的时间为2msl,默认为4min。你可以把它缩短到30s。