通过 Internet 保持 TCP/IP 连接的套接字 - 什么时候?如何?多少钱? [英] Keep Alive TCP/IP connected sockets over the Internet - when? how? and how much?

查看:25
本文介绍了通过 Internet 保持 TCP/IP 连接的套接字 - 什么时候?如何?多少钱?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

更新:如果您想省去冗长的序言,请跳到答案.

UPDATE: Skip to the answer if you want to save yourself the lengthy preamble.

TCP/IP 连接 KeepAlives 被指定为至少每两小时一次:https://www.rfc-editor.org/rfc/rfc1122#page-101.问题是这是 1989 年写的,担心发送额外的 KeepAlive 数据包的成本!然而,它仍然是大多数操作系统在一段时间不活动后根据规范向连接的套接字发送 KeepAlives 的默认时间!当然,现在大多数连接在此之前超时,如果处于非活动状态,并且如果通过 Internet 连接连接到对等方,那么在您不知情的情况下就会死掉(尽管将超时设置为高于该值 - 我怀疑是因为中间的路由器表不会打扰保持它活着 - 我一直想知道泄露的最后一条消息在哪里...... 更新: 原因是可能在您或远程主机端的路由器"是有状态的"并且连接感知和在一段时间不活动后断开连接 - 您通过互联网通过的路由器不能断开您的连接 - 他们不在乎 - 数据包只是发送到它必须去的地方).所以我看到了两种通过 Internet 保持连接活跃的常见解决方案:

TCP/IP connections KeepAlives are specified to be at least once every two hours: https://www.rfc-editor.org/rfc/rfc1122#page-101. The problem is this was written in 1989 and is concerned about the cost of sending the extra KeepAlive packet! Yet it still is the default time most OS's in accordance with the spec send out KeepAlives down a connected socket after a period of inactivity! Of course nowadays most connections timeout way before that if inactive, and if connected to a peer over the Internet connections die without your knowledge way before that (despite setting ones timeout higher than that - I suspect because router tables in between don't bother keeping it alive - I always wondered where the leaked last message goes... UPDATE: The reason for this is 'routers' that may be at your or the remote hosts end are 'stateful' and connection aware and drop the connection after some period of time of inactivity - the routers that your go through over the Internet cannot drop your connection - they they dont care - the packet is just send where it has to go). So I have seen 2 common solutions to keeping ones connection alive over the Internet:

  1. 无视(正如我所指出的,这不是无视规范,它只是更改默认值)规范并将系统范围的 KeepAlive 间隔更改为低于 2 小时,或2) 实施您自己的KeepAlive"系统,定期轮询对等方.
  1. Disregard ( as has been pointed out to me this is not disregarding the spec it is just changing the default) the spec and change your system wide KeepAlive interval to lower than 2 hours, or 2) implement your own 'KeepAlive' system polling the peer periodically.

不管怎样;什么是合适的时间(发送 KeepAlive 的不活动时间)?我已经看到了从 1 秒到默认 2 小时的所有内容.似乎这个数字已经被抽走了……如果我有一个客户端应用程序可能从世界任何地方连接,什么是安全和合理的时间段(我想要一个持久连接)?通过 Internet 连接到世界另一端许多跳的对等点,连接在 301 秒时断开(尽管您只有在尝试发送某些内容时才知道),因此将时间段设置为 300 秒似乎是一个神奇的数字 -我在死亡前 1 秒获得了 KeepAlive - 这个间隔从来没有让我失望过..但是它安全吗?

Either way; what is a suitable period (of inactivity at which to send your KeepAlive)? I have seen everything from 1 second to the default 2 hours. It seems the number is sucked out of thumbs... If I have a client application connecting from potentially anywhere in the world what is safe and reasonable period (I want a single persistent connection)? Connecting to a peer many hops away on the other side of the world over the Internet the connection dies on 301 seconds (though you only know about it when you try send something) so setting the period to 300 seconds seems to be the magic number - I get the KeepAlive 1 second before death - this interval has never failed me.. but is it safe?

这个特殊的连接是在 C# 3.0 中实现的,所以欢迎使用代码.

This particular connection im implementing in C# 3.0 so code in that welcome.

推荐答案

何时

当您想防止连接断开时.

When you want to prevent you connection being dropped.

如何

通过发送 TCP/IP KeepAlives 或自己发送一些东西(推荐因为设置发送 TCP/IP KeepAlives 的时间段将在系统级别应用于所有连接的套接字而不是在应用层).

By sending something after a period of inactivity possible by either sending TCP/IP KeepAlives or sending something yourself (reccomended since setting the period at which TCP/IP KeepAlives are sent will apply at the system level to all connected sockets instead of at the application level).

多少

一根绳子有多长?首先,您必须了解连接断开的原因:

How long is a piece of string? First you have to understand why the connection is dropped:

断开连接的原因是:

具有状态"和连接感知的家庭/商业路由器"和防火墙在一段时间不活动后往往会断开外部 TCP 连接

因此它与您的应用程序或 TCP/IP 本身无关,而是与您的连接所经历的硬件或软件有关.您可以对您可能通过的家庭/商业设备/软件断开连接的典型不活动时期进行一些研究(请参阅下面的列表).但是,如果对等点可能是 Internet 上的任何用户:

So it has nothing to do with your application or TCP/IP per se, but to do with the hardware or software your connection goes through. You could do some research into typical periods of inactivity at which home/commercial devices/software you may go through drop a connection (see lists below). However if the peer could be potentially any user on the Internet:

最终,如果您不知道他们通过什么设备/软件:允许客户端设置自己的不活动时间(在此期间发送一些内容以保持连接有效).

以较短的时间间隔(不活动)发送 KeepAlives(或您的等效项)以适应所有情况(尽管不必要的流量是一件坏事,现在每隔几秒钟不活动就会增加一个额外的数据包海洋,移动网络除外).但是请注意,根据 TCP/IP 的规范,它应该可以在临时中断中幸存下来,因此将其设置得太低可能会产生无法幸免于临时中断的不良影响,来自 http://aplawrence.com/Bofcusm/2426.html:

Or send KeepAlives (or your equivalent) at short intervals (of inactivity) to accommodate all cases (though unnecessary traffic is a bad thing an extra packet every few seconds of inactivity nowadays is a drop in the ocean, except mobile networks still). But be warned as per the specification on TCP/IP it is supposed to survive temporary outages so setting it too low could have the undesirable affect of not surviving a temporary outage, from http://aplawrence.com/Bofcusm/2426.html:

收紧 keepalive 参数的缺点是您还严重限制了 TCP 在电缆中断时的恢复能力.一个会话其两端都活着并准备好正常运行,即使中间电缆或路由器断开几分钟.如果你已经告诉服务器疯狂地发送 keepalives,它会注意到否则会幸存下来的电缆断开和断开会话很好.

The down side of tightening the keepalive parameters is that you also sharply limit TCP's resilience in the face of cable outages. A session whose both ends are alive and ready to run normally stays alive even if an intermediate cable or router is disconnected for a few minutes. If you've told the server to frantically send keepalives, it will notice a cable break and disconnect sessions that would otherwise have survived nicely.

但是,如果您无论如何都在进行一些通信,那么您会遇到中断,因此您必须处理这个问题,我认为这种担忧已经过时了,因为今天人们不会暂时中断(它们更有可能是永久性的 - 电缆已拔掉)持久连接(与狡猾的拨号相反).如果出现中断,您可能希望重新建立连接(例如 RDP)或不重新建立连接(例如 Telnet).

But you would have an outage if your was doing some comms anyway so you have to handle this and I think this concern is outdated as one does not get temporary outages (they are more likely to be permanent - cable unplugged) with todays persistent connections (as opposed to dodgy dial-up say). Should you have an outage you may want to re-establish your connection (such as RDP does) or not (such as Telnet).

对常见应用程序使用的一些研究:

Some research into what common applications use:

App    |    KeepAlive sent after    |    configurable    | ref
--------------------------------------------------------------
Telnet |    600 seconds             |          Y         | http://www-01.ibm.com/support/docview.wss?uid=nas14adccb91a24d9ed28625694900513857
MS RDP |    ?

还有一些关于哪些设备/软件会丢弃非活动连接以及何时丢弃的研究:

And some research into what devices/software drop inactive connections and when:

Device/SW                |    dropped after    |    configurable    | ref
--------------------------------------------------------------
Windows 2003 Firewall    |    24 hours         |          ?         | http://technet.microsoft.com/en-us/library/cc755604(WS.10).aspx
SonicWall TZ100/200      |     5 mins          |          Y         |  http://www.sonicwall.com/downloads/SonicWALL_TZ_100_200_Series_Getting_Started_Guide.pdf
Netgear FR114P           |     5 mins          |          N         | http://www.broadbandreports.com/forum/remark,4182300
Cisco ASA                |     1 hour          |          Y         | http://www.cisco.com/c/en/us/td/docs/security/asa/asa91/configuration/firewall/asa_91_firewall_config/conns_connlimits.html

为了所有人的利益,请编辑/完善这些列表.

Please edit to/refine these lists for the benefit of all.

这篇关于通过 Internet 保持 TCP/IP 连接的套接字 - 什么时候?如何?多少钱?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆