TCP连接中断实时检测.docVIP

TCP连接中断实时检测 　　摘要： 目前TCP/IP已经成为网络的主导技术。通过对TCP底层实现的分析，对TCP/IP编程中一个长期使人困惑的问题——网络连接中断的实时检测进行深入的分析，并提出相应的解决方案。 　　关键词： 网络编程；TCP/IP；实时监测 　　0 引言 　　作为现代网络的主导技术，TCP/IP编程看起来非常简单，但在经历了最初的高效率后，往往会在细节面前停滞不前，这常常是因为对TCP协议底层细节的缺乏了解所导致的。 　　TCP是面向连接协议，而UDP是无连接协议，许多初学者发现可以没有任何数据流通过一个空闲的TCP连接，如果TCP连接的双方都没有向对方发送数据，则在两个TCP模块之间不交换任何信息。这意味着可以启动一个客户与服务器建立一个连接，然后离去数小时至数个星期连接依然保持。中间路由器可以崩溃和重启，电话线可以被挂断再连通，只要两端的主机没有被重启，则连接依然保持建立?? 　　因此，初次接触TCP/IP协议组的程序员感到很迷惑：TCP中并没有可以在其他网络协议中发现的连接阶段的轮询，甚至发现TCP不给应用程序提供既时的网络连接中断的通知。一些程序员据此断定TCP不适用于一般的应用程序到应用程序的通信。TCP为什么不提供通知呢？ 　　1 原理分析 　　TCP通常被称为可靠的协议，即“TCP保证发送数据的传输”，这通常会产生误解：TCP不会出错。事实是只要双方保持连接，TCP就能保证数据的正确传输，但是当连接中断时，就会产生问题，原因有3个：1）永久的或暂时的网络紊乱；2）对等方应用程序崩溃；3）对等方主机崩溃，当出现以上问题时，会使双方应用程序不能互相通信，而其中一个应用程序却不能立刻意识到。发送数据给对等方的应用程序可能在知道TCP在放弃重发之前才会发现连接中断，如果应用程序没有发送数据，可能永远不会发现网络已经中断。例如应用程序可能是一个正在等待对等方发出下一个请求的服务器，因为客户端不能和服务器通信，下一个请求永远不会到达，甚至客户端的TCP放弃并撤销连接，导致客户端中断，服务器也没有意识到这一点。 　　其他的通信协议如SNA和X.25，当连接中断时会给应用程序提供通知。比如简单的直接点对点专有链接复杂的任何协议都必须使用一种轮询协议来连续地测试对等方是否存在。轮询-选择协议可能会采用显式地发送“你有要发送给我的任何数据吗?”诸如此类的消息的形式，或者它们会采用后台静态帧的形式来检测虚拟线路是否仍然存在。每一个轮询消息都会消耗网络资源，而这些资源本来可以用于“有效负载”数据的传输。 　　对可获得的网络带宽的消耗是TCP不提供网络中断立即通知的一个原因。因为大多数的应用程序不需要即时的通知，所以没有必要以降低带宽的代价来提供这个功能。需要以一种及时的方式知道对等方不可到达的应用程序可以实现它们自己的机制来发现网络中断，如后面介绍的那样。 　　TCP/IP设计中使用的一个基本原则是终端对终端参数[Saltzer el al.1984]，该参数应用到网络上时可以表述为所有的智能应当尽可能地接近连接的终端点，而网络本身应当相对没有智能。这就是为什么TCP自己处理错误控制而不是依靠网络来提供它的原因。当这个原则应用到监控对等应用程序之间的连接时，应用程序应当提供它自己需要的功能，而不是不管应用程序是否需要这个功能都由下层提供。 　　TCP不提供及时连接中断通知的最重要的原因是：网络突然中断时仍可以维持通讯的能力。TCP最早是美国国防部发起的一项研究的成果，它要求提供一个遇到战争或自然灾害引起的网络中断时仍然可以维持计算机之间可靠的通信的网络协议。通常网络紊乱是暂时的，路由器也可能找到连接的另一条路径。通过允许连接的暂时中断，甚至在终端应用程序意识到中断之前TCP就已经处理好了紊乱。 　　2 解决方案 　　2.1 方案一：使用TCP Keep-alive机制 　　人们希望知道连接是否中断了，因此许多TCP的具体实现提供了一个称作Keep-alive的机制用于检测死连接，但是它并不经常用于应用程序。如果应用程序启用Keep-alive机制时，TCP就会在连接已经空闲了一段时间间隔后发送一个特殊的段给对等方。如果对等方主机可到达而且对等方应用程序仍然运行，对等方TCP就会响应一个ACK应答。在这种情况下，TCP发送Keep-alive重置空闲时间为零，并且应用程序不会收到消息交换的任何通知。 　　如果对等方主机可以到达但是对等方应用程序没有运行，对等方TCP就响应RST消息，发送Keep-alive消息的TCP撤销连接并返回ECONNRESET错误给应用程序。这通常是对等方主机崩溃后重起的结果，因为如果仅仅是对等方应用程序中断或崩溃了，对等方TCP可能已经发送FIN消息了。 　　如果对等方主机没有响应ACK或