协议管理分散设备怎么进行运作

lmy456

在大型网络中，了解有哪些东西连接到了网络是非常重要的。网络越大，逻辑上和物理上都是——其拓扑越难理清。再加上还有冗余链路和链路聚合，会大大增加理清网络中设备互连情况的难度。而且，问题还不止于此。混合使用来自不同供应商的网络产品，会让设备发现协议无所适从。但是，想要理清环境也并非没有可能。且听我细细道来。 　　首先，我要讲一个背景故事：我曾经在一个团队中，我们管理的环境中大部分是思科设备。“大部分”这个词对于设备发现而言有重要意义。与其他网络供应商一样，思科提供了一种私有协议，允许网络管理员查看有哪些设备直接连接了某一台设备，当然你要有这台设备的管理员访问权限。很多读者肯定都熟悉下面这个思科发现协议(CDP)的截图：执行命令“show CDP neighbors”，会得到一个直观显示所连接设备的表格。执行“show CDP neighbors details”，则可以展开表格，查看交换机之间的详细连接信息(截图里有一个 VLAN匹配错误，对吧?)，以及各个设备的详细信息，包括其管理IP地址信息。 　　我在前面提到，我的环境中大部分是思科设备，但是我们也在一些特殊位置使用了其他供应商的产品。我们在美国及海外的大部分分支网络中使用了Meraki的产品，但是与其他第三方设备一样，Meraki接入端(AP)无法通过CDP查看到交换机的连接情况。换言之，“show CDP neighbors”命令无法查看到它们的信息。如果TCP连接被对方正常关闭，也就是说，对方是正确地调用了closesocket(s)或者shutdown(s)的话，那么上面的Recv或Send调用就能马上返回，并且报错。这是由于close socket(s)或者shutdown(s)有个正常的关闭过程，会告诉对方“TCP连接已经关闭，你不需要再发送或者接受消息了”。但是，如果意外断开，客户端(3g的移动设备)并没有正常关闭socket。双方并未按照协议上的四次挥手去断开连接。 　　那么这时候正在执行Recv或Send操作的一方就会因为没有任何连接中断的通知而一直等待下去，也就是会被长时间卡住。像这种如果一方已经关闭或异常终止连接，而另一方却不知道，我们将这网络运维管理样的TCP连接称为半打 的。解决意外中断办法都是利用保活机制。而保活机制分又可以让底层实现也可自己实现 自己编写心跳包程序简单的说也就是在自己的程序中加入一条线程，定时向对端发送数据包，查看是否有ACK，如果有则连接正常，没有的话则连接断开 启动TCP编程里的keepAlive机制。 　　一)双方拟定心跳(自实现)一般由客户端发送心跳包，服务端并不回应心跳，只是定时轮询判断一下与上次的时间间隔是否超时(超时时间自己设定)。服务器并不主动发送是不想增添服务器的通信量，减少压力。但这会出现三种情况：情况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其实keepalive的原理就是TCP内嵌的一个心跳包,以服务器端为例，如果当前 server 端检测到超过一定时间(默认是 7,200,000 milliseconds ，也就是 2 个小时)没有数据传输，那么会向 client 端发送一个 keep-alive packet (该 keep-alive packet 就是 ACK和 当前 TCP 序列号减一的组合)，此时 client 端应该为以下三种情况之一：1client 端仍然存在，网络连接状况良好。此时 client 端会返回一个 ACK 。server 端**到 ACK 后重置计时器(复位存活定时器)，在 2 小时后再发送探测。如果 2 小时内连接上有数据传输，那么在该时间基础上向后推延 2 个小时。 　　2客户端异常关闭，或是网络断开。在这两种情况下， client 端都不会响应。服务器没有收到对其发出探测的响应，并且在一定时间(系统默认为 1000 ms )后重复发送 keep-alive packet ，并且重复发送平安城市视频监控运维一定次数( 2000 XP 2003 系统默认为 5 次 , Vista 后的系统默认为 10 次)。. 客户端曾经崩溃，但已经重启。这种情况下，服务器将会收到对其存活探测的响应，但该响应是一个复位，从而引起服务器对连接的终止。对于应用程序来说，2小时的空闲时间太长。因此，我们需要手工开启Keepalive功能并设置合理的Keepalive参数。