Tcp通信中服务器处理客户端意外断开
2015-08-31 22:02
267 查看
Tcp通信中服务器处理客户端意外断开
所谓意外断开,是客户端(多指支持3G的移动设备)并没有正常关闭socket,双方并未按照协议上的四次挥手去断开连接,一般的处理办法都是利用保活机制。而保活机制分又可以让底层实现也可自己实现。
一、双方拟定心跳(自实现)
一般由客户端发送心跳包,服务端并不回应心跳,只是定时轮询判断一下与上次的时间间隔是否超时(超时时间自己设定)。服务器并不主动发送是不想增添服务器的通信量,减少压力。
但这会出现三种情况:
情况1.
客户端由于某种网络延迟等原因很久后才发送心跳(它并没有断),这时服务器若利用自身设定的超时判断其已经断开,而后去关闭socket。若客户端有重连机制,则客户端会重新连接。若不确定这种方式是否关闭了原本正常的客户端,则在ShutDown的时候一定要选择send,表示关闭发送通道,服务器还可以接收一下,万一客户端正在发送比较重要的数据呢,是不?
情况2.
客户端很久没传心跳,确实是自身断掉了。在其重启之前,服务端已经判断出其超时,并主动close,则四次挥手成功交互。
情况3.
客户端很久没传心跳,确实是自身断掉了。在其重启之前,服务端的轮询还未判断出其超时,在未主动close的时候该客户端已经重新连接。
这时候若客户端断开的时候发送了FIN包,则服务端将会处于CLOSE_WAIT状态;
这时候若客户端断开的时候未发送FIN包,则服务端处还是显示ESTABLISHED状态;
而新连接上来的客户端(也就是刚才断掉的重新连上来了)在服务端肯定是ESTABLISHED;这时候就有个问题,若利用轮询还未检测出上条旧连接已经超时(这很正常,timer总有个间隔吧),而在这时,客户端又重复的上演情况3,那么服务端将会出现大量的假的ESTABLISHED连接和CLOSE_WAIT连接。
最终结果就是新的其他客户端无法连接上来,但是利用netstat还是能看到一条连接已经建立,并显示ESTABLISHED,但始终无法进入程序代码。个人最初感觉导致这种情况是因为假的ESTABLISHED连接和CLOSE_WAIT连接会占用较大的系统资源,程序无法再次创建连接(因为每次我发现这个问题的时候我只连了10个左右客户端却已经有40多条无效连接)。而最近几天测试却发现有一次程序内只连接了2,3个设备,但是有8条左右的虚连接,此时已经连接不了新客户端了。这时候我就觉得我想错了,不可能这几条连接就占用了大量连接把,如果说几十条还有可能。但是能肯定的是,这个问题的产生绝对是设备在不停的重启,而服务器这边又是简单的轮询,并不能及时处理,暂时还未能解决。
二、利用KeepAlive
在S和C建立连接后,若双方均不发送数据只保持连接,则再两小时后(这个时间我未测试过,但很多资料都显示是这个间隔,貌似是默认的)系统会自动启动保活机制向peer发送包,看对方是否回应ack,若可以收到则继续保持,否则无效。这也就能解释如下现象了:
现象1:
自己写的socket程序放在pc机上(2台),为了模拟意外断掉,将客户端的网线拔掉,点击任何一方去发送都发送不了(这肯定么),那么你认为这时连接已经断了吗?非也,tcp连接并没有断,因为双方还不知道对方是否已经断掉(保活机制还未启动呢),这时若查看netstat,发现状态很已然是ESTABLISHED;当过一段时间后将客户端的网线插好,则可以继续发送。
现象2:
根据现象1的描述,感觉当电脑意外断网的时候,在短时间内又恢复时,QQ的自动连接也应该是这样。
在C#中有关keepalive的资料连MSDN都说的轻秒淡写,如果不是搞C++的还真不知道咋弄,在网上看了很多文章,感谢以下文章的作者:
http://blog.csdn.net/kenkao/article/details/5415159 http://www.cnblogs.com/wzd24/archive/2007/05/22/755050.html http://blog.csdn.net/kenkao/article/details/5804539
其实实现keepalive在c#里就一句话,但又两种方式:
1.IOControl
public int IOControl(IOControlCode ioControlCode, byte[] optionInValue, byte[] optionOutValue);
//
// 摘要:
// 使用 System.Net.Sockets.IOControlCode 枚举指定控制代码,为 System.Net.Sockets.Socket
// 设置低级操作模式。
//
// 参数:
// ioControlCode:
// 一个 System.Net.Sockets.IOControlCode 值,它指定要执行的操作的控制代码。
//
// optionInValue:
// System.Byte 类型的数组,包含操作要求的输入数据。
//
// optionOutValue:
// System.Byte 类型的数组,包含由操作返回的输出数据。
//
// 返回结果:
// optionOutValue 参数中的字节数。
无论是看msdn还是这里的注释,都不知道这几个参数是什么意思,在上面的博客中楼主解释了其中的含义:
在C++中第二个参数不是数组而是结构体
struct tcp_keepalive
{
u_long onoff; //是否启用Keep-Alive
u_long keepalivetime; //多长时间后开始第一次探测(单位:毫秒)
u_long keepaliveinterval; //探测时间间隔(单位:毫秒)
};
这下就明白了,原来参数是在这里设置的
[csharp] view
plaincopyprint?
private byte[] GetKeepAliveByte()
{
uint dummy = 0;
byte[] inOptionValues = new byte[Marshal.SizeOf(dummy) * 3];
BitConverter.GetBytes((uint)1).CopyTo(inOptionValues, 0);//是否启用Keep-Alive
BitConverter.GetBytes((uint)5000).CopyTo(inOptionValues, Marshal.SizeOf(dummy));//多长时间开始第一次探测
BitConverter.GetBytes((uint)5000).CopyTo(inOptionValues, Marshal.SizeOf(dummy) * 2);//探测的时间间隔
return inOptionValues;
}
当然也可以写成有参数的,更好的去调用。
2.SetSocketOption
public void SetSocketOption(SocketOptionLevel optionLevel, SocketOptionName optionName, byte[] optionValue);
// 摘要:
// 将指定的 System.Net.Sockets.Socket 选项设置为指定的值,表示为字节数组。
//
// 参数:
// optionLevel:
// System.Net.Sockets.SocketOptionLevel 值之一。
//
// optionName:
// System.Net.Sockets.SocketOptionName 值之一。
//
// optionValue:
// System.Byte 类型的数组,表示选项值。
//
这个方法感觉和上面的调用的都是一样的,我所以我借鉴的第一种。
实现方式:
在accept成功后进行
e.AcceptSocket.IOControl(IOControlCode.KeepAliveValues, GetKeepAliveByte(),null);//开启keepalive机制
所谓意外断开,是客户端(多指支持3G的移动设备)并没有正常关闭socket,双方并未按照协议上的四次挥手去断开连接,一般的处理办法都是利用保活机制。而保活机制分又可以让底层实现也可自己实现。
一、双方拟定心跳(自实现)
一般由客户端发送心跳包,服务端并不回应心跳,只是定时轮询判断一下与上次的时间间隔是否超时(超时时间自己设定)。服务器并不主动发送是不想增添服务器的通信量,减少压力。
但这会出现三种情况:
情况1.
客户端由于某种网络延迟等原因很久后才发送心跳(它并没有断),这时服务器若利用自身设定的超时判断其已经断开,而后去关闭socket。若客户端有重连机制,则客户端会重新连接。若不确定这种方式是否关闭了原本正常的客户端,则在ShutDown的时候一定要选择send,表示关闭发送通道,服务器还可以接收一下,万一客户端正在发送比较重要的数据呢,是不?
情况2.
客户端很久没传心跳,确实是自身断掉了。在其重启之前,服务端已经判断出其超时,并主动close,则四次挥手成功交互。
情况3.
客户端很久没传心跳,确实是自身断掉了。在其重启之前,服务端的轮询还未判断出其超时,在未主动close的时候该客户端已经重新连接。
这时候若客户端断开的时候发送了FIN包,则服务端将会处于CLOSE_WAIT状态;
这时候若客户端断开的时候未发送FIN包,则服务端处还是显示ESTABLISHED状态;
而新连接上来的客户端(也就是刚才断掉的重新连上来了)在服务端肯定是ESTABLISHED;这时候就有个问题,若利用轮询还未检测出上条旧连接已经超时(这很正常,timer总有个间隔吧),而在这时,客户端又重复的上演情况3,那么服务端将会出现大量的假的ESTABLISHED连接和CLOSE_WAIT连接。
最终结果就是新的其他客户端无法连接上来,但是利用netstat还是能看到一条连接已经建立,并显示ESTABLISHED,但始终无法进入程序代码。个人最初感觉导致这种情况是因为假的ESTABLISHED连接和CLOSE_WAIT连接会占用较大的系统资源,程序无法再次创建连接(因为每次我发现这个问题的时候我只连了10个左右客户端却已经有40多条无效连接)。而最近几天测试却发现有一次程序内只连接了2,3个设备,但是有8条左右的虚连接,此时已经连接不了新客户端了。这时候我就觉得我想错了,不可能这几条连接就占用了大量连接把,如果说几十条还有可能。但是能肯定的是,这个问题的产生绝对是设备在不停的重启,而服务器这边又是简单的轮询,并不能及时处理,暂时还未能解决。
二、利用KeepAlive
在S和C建立连接后,若双方均不发送数据只保持连接,则再两小时后(这个时间我未测试过,但很多资料都显示是这个间隔,貌似是默认的)系统会自动启动保活机制向peer发送包,看对方是否回应ack,若可以收到则继续保持,否则无效。这也就能解释如下现象了:
现象1:
自己写的socket程序放在pc机上(2台),为了模拟意外断掉,将客户端的网线拔掉,点击任何一方去发送都发送不了(这肯定么),那么你认为这时连接已经断了吗?非也,tcp连接并没有断,因为双方还不知道对方是否已经断掉(保活机制还未启动呢),这时若查看netstat,发现状态很已然是ESTABLISHED;当过一段时间后将客户端的网线插好,则可以继续发送。
现象2:
根据现象1的描述,感觉当电脑意外断网的时候,在短时间内又恢复时,QQ的自动连接也应该是这样。
在C#中有关keepalive的资料连MSDN都说的轻秒淡写,如果不是搞C++的还真不知道咋弄,在网上看了很多文章,感谢以下文章的作者:
http://blog.csdn.net/kenkao/article/details/5415159 http://www.cnblogs.com/wzd24/archive/2007/05/22/755050.html http://blog.csdn.net/kenkao/article/details/5804539
其实实现keepalive在c#里就一句话,但又两种方式:
1.IOControl
public int IOControl(IOControlCode ioControlCode, byte[] optionInValue, byte[] optionOutValue);
//
// 摘要:
// 使用 System.Net.Sockets.IOControlCode 枚举指定控制代码,为 System.Net.Sockets.Socket
// 设置低级操作模式。
//
// 参数:
// ioControlCode:
// 一个 System.Net.Sockets.IOControlCode 值,它指定要执行的操作的控制代码。
//
// optionInValue:
// System.Byte 类型的数组,包含操作要求的输入数据。
//
// optionOutValue:
// System.Byte 类型的数组,包含由操作返回的输出数据。
//
// 返回结果:
// optionOutValue 参数中的字节数。
无论是看msdn还是这里的注释,都不知道这几个参数是什么意思,在上面的博客中楼主解释了其中的含义:
在C++中第二个参数不是数组而是结构体
struct tcp_keepalive
{
u_long onoff; //是否启用Keep-Alive
u_long keepalivetime; //多长时间后开始第一次探测(单位:毫秒)
u_long keepaliveinterval; //探测时间间隔(单位:毫秒)
};
这下就明白了,原来参数是在这里设置的
[csharp] view
plaincopyprint?
private byte[] GetKeepAliveByte()
{
uint dummy = 0;
byte[] inOptionValues = new byte[Marshal.SizeOf(dummy) * 3];
BitConverter.GetBytes((uint)1).CopyTo(inOptionValues, 0);//是否启用Keep-Alive
BitConverter.GetBytes((uint)5000).CopyTo(inOptionValues, Marshal.SizeOf(dummy));//多长时间开始第一次探测
BitConverter.GetBytes((uint)5000).CopyTo(inOptionValues, Marshal.SizeOf(dummy) * 2);//探测的时间间隔
return inOptionValues;
}
当然也可以写成有参数的,更好的去调用。
2.SetSocketOption
public void SetSocketOption(SocketOptionLevel optionLevel, SocketOptionName optionName, byte[] optionValue);
// 摘要:
// 将指定的 System.Net.Sockets.Socket 选项设置为指定的值,表示为字节数组。
//
// 参数:
// optionLevel:
// System.Net.Sockets.SocketOptionLevel 值之一。
//
// optionName:
// System.Net.Sockets.SocketOptionName 值之一。
//
// optionValue:
// System.Byte 类型的数组,表示选项值。
//
这个方法感觉和上面的调用的都是一样的,我所以我借鉴的第一种。
实现方式:
在accept成功后进行
e.AcceptSocket.IOControl(IOControlCode.KeepAliveValues, GetKeepAliveByte(),null);//开启keepalive机制
相关文章推荐
- 安捷伦网络分析仪使用教程
- OkHttp文件下载并通过Interceptor实现下载进度
- 网络编程
- 【总结】HTTP状态码
- LTE网络主要接口
- Android之网络编程之网络通信几种方式实例分享
- python下的复杂网络编程包networkx的安装及使用
- No repository found at http://m2eclipse.sonatype.org/sites/m2e
- 网络请求 4中请求方式
- 网络I/O函数
- GO1.5标准包http.FileServer的拔高用法.
- uCosii的OSInit();函数分析 转自匿名http://m.blog.csdn.net/blog/songhengli/19939469
- 网络第一天
- 使用HttpWebRequest的POST取得网页内容(异步操作)2篇集合
- TCP/IP三次握手,四次分手
- 网络编程
- ios开发进阶之网络06 网络安全 UIWebView
- Android OkHttp完全解析 是时候来了解OkHttp了
- TCP 的那些事儿(下)
- TCP 的那些事儿(上)