在实际应用中,我可以期望客户端/服务器TCP连接能够持续多久?
我希望连接能够一直保持,但是有些意外情况不可避免,所以客户端将需要重新连接。何时才能认为代码出现了问题而不是某些外部设备出现了问题呢?
在实际应用中,我可以期望客户端/服务器TCP连接能够持续多久?
我希望连接能够一直保持,但是有些意外情况不可避免,所以客户端将需要重新连接。何时才能认为代码出现了问题而不是某些外部设备出现了问题呢?
我同意Zan Lynx的观点。假设没有连接或带宽问题,通过向连接发送数据,可以几乎无限期地保持连接。
通常我使用应用程序级别的保持连接方式,尽管这通常是因为客户端规范要求我这样做。只需每一两分钟发送一小段数据,并期望得到某种确认即可。
你可以自行决定是否将未收到确认视为连接失败。通常我过去的做法是这样做,尽管有一次我必须等待连续三次未获得响应才放弃连接,因为连接另一端的应用程序对“你在那里吗?”请求的响应非常不稳定。
如果连接失败(即使是在同一网络上的机器也可能会出现这种情况),则尝试重新建立连接。如果重连失败了一定次数,则有问题。如果连接在连接一段时间后始终失败,则同样存在问题。在大多数情况下,这可能是某个网络问题,而不是您的代码,或者可能是您计算机上的TCP/IP堆栈出现问题(已知:我在旧版本的QNX上遇到过此类问题 - 它会随机崩溃)。话虽如此,您可能会遇到软件问题,唯一确定的方法通常是附加调试器或进行一些日志记录。例如,如果您始终可以成功连接,但是一段时间后停止收到确认,即使重新连接后仍然如此,则可能是您的服务器死锁或卡在某个循环中。
真正有用的是在各种负载条件下建立一系列长期运行的测试,从仅发送保持连接请求和响应到彻底攻击服务器。这通常会让您对软件组件更加自信,并且可以在摆脱一些不会必然影响您的连接但可能导致交易出现问题的非常奇怪的问题时非常有用。例如,我曾经编写过一个电信应用服务器,提供号码转换等服务,我们只需让它连续运行几天。问题是,每当周六来临时,一整天内它都会拒绝每个呼叫请求,这相当于数百万个呼叫,而我们不知道原因。结果发现是由于某个日期转换代码中的单个笔误,仅在星期六才会出现问题。
希望能对你有所帮助。
我认为这里最重要的观点是理论与实践之间的区别。
最初的理论是连接没有生命周期。如果你建立了一个连接,即使没有流量,它也会一直保持打开状态,直到某个事件导致其关闭。
新的理论是大多数操作系统版本都已经开启了保持活动计时器。这意味着只要另一端的系统偶尔响应TCP级别交换,连接就会持续存在。
事实上,许多连接会因各种标准和情况而在一段时间后终止。
两个非常好的例子是:远程客户端使用DHCP,租约到期,IP地址更改。
另一个例子是防火墙,看起来越来越智能化,可以识别保持活动流量与真正的数据,并根据任何高级标准(特别是空闲时间)关闭连接。
如何实现重新连接逻辑在很大程度上取决于您的架构、工作环境和性能目标。
这并不重要,你应该设计你的代码以自动重新连接,如果这是所期望的行为。
实际上没有办法确定。TCP协议本身并不会导致连接在一定时间后突然中断。一个可靠的网络连接可以保持数年连续性,而另一个网络连接可能每5分钟就需要重新连接。因此,无法确定或猜测。
选择一个值。每小时一次的掉线可能是正常的。5分钟内出现10次意外连接断开可能表示存在问题。
TCP连接通常会持续大约两个小时,没有任何流量。任何一端都可以发送保持活动数据包,我认为这只是对最后接收到的数据包进行确认。这通常可以针对每个套接字设置,或默认应用于每个TCP连接。
还可以进行应用程序级别的保持活动。对于类似FTP、SMTP、POP或IMAP的telnet样式协议,可以发送回车、换行并获取命令提示符之类的内容。