TCP/IOCP构架中出现的假死连接解决方案(error :10054)
如果在2台不同的公网机器，对TCP的c/s做过详细的压力测试，那么很不幸，会有很多人发现自己的server端会出现大量的假死连接。
假死连接具体表现如下：
1、在s端机器上，会有一些处于TCP_ESTABLISHED状态的“正常”连接；
2、但是在c端机器上，你的tcp客户端已经提示当前连接已经断开，比如10053/10054。
3、c端此时虽然可以断线重连s端，但是上一次的连接状态依然被s认为有效，并且得不到正确释放（例如IOCP构架中的套接字上下文及接收/发送缓冲区）。
这种情况虽然不常见，但是确实是存在的，具体造成的原因可以参考tcp/ip断开连接fin过程，如果你认为这种事情发生概率微不足道，不做任何处理的话，你的s长时间运行后，会面临大量假死连接得不到正常释放，然后服务器越来越慢，IO处理效率越来越低。
最常见诡异现象：采用IOCP的c/s构架中，明明c端closesocket了，但是s端的GCQS就是不会返回失败信息！
网上通常的解决方案：
1、对连接上的套接字做保活处理，即设置keeplive，此后如果在规定时间内无数据传输，那么tcp协议栈会自动发送keeplive探测包，以维护当前连接有效性。如果你在s端采用这个方案，那么很可惜，假死连接不会得到根本性的解决。常见现象：c端意外断电、网络异常终止、被第三方软件或防火墙干掉等。
2、c端定时发送用户层心跳包，s端针对每个已连接套接字记录最后一次收到心跳包的时间，同时开启线程定时检测：超过XX秒还未收到心跳包的套接字，kill掉，释放占用的上下文及收发缓冲区资源。
稳定的c/s构架可能不会用协议栈的keeplive（没办法100%干掉假死连接），但是一定会做用户层的心跳检测机制，当然我的项目也是这样处理的，目前反馈信息良好。
TCP/IP协议1卷，第188页。
18.7.3 检测半打开连接
如果一方已经关闭或异常终止连接而另一方却还不知道，我们将这样的TCP连接称之为半打开（HalfOpen）的。任何一端主机异常都可能导致发生这种情况。只要不打算在半打开连接上传输数据，仍处于连接状态的一方就不会检测另一方已出现的异常。
以上是原文，半打开状态很常见，因为基于性能的考虑，TCP被故意设计成一种无状态检测的协议。
而这种情况的处理，需要心跳信号（应用层）来解决。所有IO模式下都一样，不仅限于IOCP。
服务端主动心跳，如果客户端在给定时间未回复心跳，则客户端很可能挂了