【51CTO.com独家特稿】编者按：本文为2009年首届网络分析技术大会的现场实录，演讲嘉宾为资深网络分析技术专家谢声涛先生。谢先生在大会上为我们详细讲解了金融行业的网络应用分析等问题。
金融行业在这几年发展特别快，特别是随着进瑞行业做数据大集中，相继在上海和北京做了数据中心，网商银行这个业务发展也是非常快的，相信在座各位都有使用过网上银行或者网上交易相关的经验，网商银行现在是非常方便的，不用跑到营业场所排队，站上一个小时，才能做相关的交易，网上银行和证券、第三方存款、期货等所有相关都是和银行有密切的关系，新业务系统也是快速增加，以前最早的业务系统，大家知道在银行存款和取款，没有其他的业务。
除此之外关联的业务系统有三百个，所有都是广域网，都是B/S架构和C/S架构，都是非常复杂的，这是对网络和业务系统非常有压力，因为数据大集中之后，对广域网或者说对所有的网络稳定运行要求是非常高的，针对这个业务系统发生故障的时候，我们要有一个快速响应的办法，同时要有一个实时的监控，对应用系统应用性能和实时监控有着有效的预警系统日趋紧迫。对网络管理的要求也要求越来越高，而且现在管理越来越复杂，因为网络规模是越来越大，中间有管理和分支机构，在数据中心也划分了多个区域，比如说网银区和外联区域，比如和人行或者外管局、期货商、证券商相关联的业务系统等各个区域越来越大，关键的网络应用也越来越多，现在有两百多套应用系统，重要的系统只有三四十套，这些都关于银行重要的生命线。网络用户越来越多，原来只是分行，包括网络用户，像大的银行，网银用户一天大概有一百多玩火者说相关的交易量，数据量都是特别大的。像分支机构，我们经常可以碰到响应时间特别慢，不响应，过上一分钟又恢复了，还有病毒攻击等。我们内部采用比较复杂的应用结构，比如IP、三层架构，多层网络拓扑下的应用性能做一个监控。广域网上网银对B2B和B2C的交易应用需要对应用性能进行监控，对带宽管理和广域网管理，我们需要有一个有效的规划，因为现在银行广域网一些大的银行向电信和网通租费都是五六亿，降低成本，实行高精度化的管理，我们需要有效的利用广域网能够尽量节省带宽，能够降低一些无效的流量。
应用是多重数据，比如数据、语音、视频，因为各个银行业有好多电话银行和呼叫中心，这些呼叫中心实际上并不是在一个地方，它可能是分散在多个地方，比如说像上海，有的可能在成都，有的在兰州，有的人在苏州，甚至是八个呼叫中心，但是后台语音的管理系统只有一套，就在数据中心，所有的数据都走聚合广域网线路，上到数据中心进行处理，这个就需要有一个非常有效的监控。IT故障业务，我们需要流量规划、管理，从被动到主动的管理模式，以及我们需要IT和业务的架构适当改变，又要适应网络的发展。最终的目标是要能够保证性能能够在客户不被影响情况下快速解决问题，减少MTTR。
案例分析：网络拓扑图。实际上是两个数据中心，桐城数据网，通过万兆城域网进行关联，在每一个数据中心里头，分了多个区域，这只是其中一个区域，也是三层的架构，在每一层交换机之间都有防火墙，还有负载均衡设备，客户端在另外一个数据中心。业务系统运行异常，服务器刚完成一次运维变更操作，交易成功率约为70%，并且失败的交易都发生在同一服务器上，发生问题的地方：网络设备、防火墙、均衡负载、服务器、系统配置，无法确认问题发生的所在。
我们还需要在服务器前端装设备，也需要进行采集。首先先看AF防火墙和AP SW1之间，为什么抓这个数据，进行前端数据捕获，到底异常是什么样的异常？同时有三个数据包是异常的，这三个数据包都是针对前面的序列号做得对比。看到这个应用的时候，我不知道大家对均衡负载设备工作原理也有相当的了解，也就是说，所有客户端，比如访问到均衡负载设备，均衡负载设备把数据流做相应的算法处理，分给两个服务器，服务器做了响应的响应之后，数据给负载均衡设备，负载均衡设备给客户端做相互的处理，也就是说咱们在这个点上看到的数据，看到两个地址，经常出现的102.10说明是有异常的，这个异常体现在几个地方，我们就需要分析，有可能是负载均衡设备异常，数据并没有做地址转换，或者说我们的服务器交换机上面端口处理出现了问题，需要看看在服务器前端的数据。
大家一定要注意的目标源地址和FW1地址。我们再看一看正常的交易，和10正常的交易，并不是所有交易都失败，是70%，即使在10失败，也是50%的失败率，肯定有正常的交易，正常交易的过程是什么样子的，这时候我们可以对照交换机，我们和网管员对照。失败交易地址是什么呢？我们查了一下，相当于服务器交换机网关，也就是说服务器配得末端网关，为什么会出现这个问题呢？正常情况下，所有数据都给F5设备，出现这个问题就出现在服务器配置，我们再联系前面服务器操作重启，导致配置的路由信息出现了异常，出现了双路由的情况出现，最后我们让系统管理员自己查主机的IP地址，最后确认确实因为最后一次变更重启导致主机出现双路由，正常的数据流进来客户端到负载均衡再到服务器再到给均衡负载设备，然后再到客户端，这是完整的过程。
因为108.10存在两条，致使交易数据和路径负载均衡，负载均衡到服务器，服务器直接由交换机网关传给客户端，导致这个链建立失败，最后导致交易失败，实际上这就是运维过程中配置信息管理不严格，导致重启之后变更操作使交易失败，最后把路由器改了，交易恢复正常。案例二现象描述。应用架构为WEB AP DB三层体系。高峰期时交易受到影响。WEB服务器上存在大量的CLOSE WAIT状态的TCP会话，而AP服务器存在大量的FIN WAIT 2状态的TCP会话。系统刚完成版本升级。发生问题的地方：服务器、系统配置。
我们也是看一下WEB和AP，防火墙控制时间是不是有一些限制，最后导致应用不正常。在TCP正常终止对应的状态图，在主动关闭这一端发出第一个命令时由1转为2，接收端在收到时，转到CLOESED状态。接收端这边收到之后，变成CLOSE WAT。WEB服务器存在大量的CLOSE WAIT状态的TCP绘画，而AP服务器存在大量的FIN WAIT 2状态。TCP正常终止时的数据76.98，是Web服务器，7.92是AP服务器，异常的时候77.92由AP服务器发出，发生断裂之前，IP服务器有一个主动的延迟31秒，我们问过应用部门，他们判断说，由服务器在断裂之前超过30秒没有数据传递的话，将由AP服务器主动发起断裂，客户端Web服务器发出下一个命令的时候，中间间隔时间是200多毫秒，我们只原则其中一个链，最长四百多秒。两百多秒导致AP服务器保持两百多秒状态，Web也保持了一定的时间。假设在业务量高峰期间，这个链正常可能是只有高低端只有十个用户，代表AP服务器足够资源给其他的连接分配，但是如果说是高峰期达到两百甚至上千个用户的时候，这个时候会导致AP服务器再也没有足够的资源供Web服务器使用，这就是交易量下降的原因。
最后再回到断裂的异常，刚才我们看到的是，断裂的时候由Web发出断裂都是正常的结束，AP服务器发出断裂的话，全部都是异常的，最后由应用部门主动追溯调用哪些程序，发现调用APR结束上面有一些问题，也就是说Web情况下不会发生断裂，部分情况会发生断裂，是由AP服务器发出断裂，就会造成长时间挂在上面，最终他们修改了ATI接口，调整为Web服务器强制发起断裂，这样的话，所有的现象就全部消失了，业务恢复了正常。
案例三：利用Sniffer解决某银行信用卡业务网络故障。大家都有刷卡购物的经历，也就是说大家拿着银行卡在POS刷卡，最后付帐，我不知道大家对信用卡网络有多少了解？商场POS机有建行、工行、农行，所有的POS都是通过电话线连到后面的POS PAD，可以看作POS的哈比，早期使用XL25网络，通过这个网络连到网控设备，网口设备也是比较特殊的，可以看成是路由器，上面有多块管理网卡，简称CID卡，后面有LET卡。网控做什么网络，把数据转成以太网数据。
信用卡网络故障描述：商场POS通过POS PAD连接X.25网络。IBM主机通过以太网与网控连接，进入X.25网络。银行信用卡业务与贷计卡业务通过以上网络进行处理。因更新POS程序，造成信用卡在商场刷卡时可以进行消费，但无法完成批上送消费结算。同时，贷计卡消费完全正常。有一笔应用完全正常，有一笔应用是失败交易，我们采取两个点来看，分别在网控前端和后端，广域网和局域网都做数据捕获，信用卡结算数据有可能是丢失，有可能数据到POS前端没有发送，或者数据有可能在网控阶段没有往后台IBM主机发送，也可能修改程序导致数据异常。
成功的交易，广域网的数据，数据包108个字节，HDLC数据包头2字节，X.25数据包头3字节，PAD封装交易数据105字节。贷计卡在后端130.25.1.193是LET的IP地址，目标是130.25.01.10是主机地址。信用卡成功的交易，因为信用卡交易并不是完全失败，包头是133个字节，PAD去掉2个字节，X.25包头数据是3字节，PAD封装交易数据是128个字节，里头有一个偏移位，数据封装分成两个，交易数据总厂178个字节，大于128字节，X.25协议规定进行分组传递，这个协议规定128个字节包，超过128字节就必须分包，分成两个包进行传递。信用卡交易失败的数据，在广域网数据是什么样子的？133个字节，128个字节的封装，在应用层看到，信用卡交易结算总包长就是128个字节，X.25网络中正好是一个分组的数据，广域网在以太网数据传输，数据到网控，并没有往后台以太网数据传送，所以交易失败了。只有交易包的长度128字节时才会出现问题，大于或者小于都是很正常的，我们更新了POS程序，信用卡交易批量传输长度是128个，该长度是固定的，不会随交易金额变化而变化。可能故障的原因，X.25网络规定大于128字节的数据应分组，如果说这个数据正好是128字节处于临界值，X.25通信设备再处理上存在偏差。也就是说，POS PAD也就是说在收到POS传送来的128字节长度数据包时，认为该数据不需要分组，直接组装成一个X.25数据包往网控发送。网控收到POS PAD传送来的128字节长度的数据包进行处理时，认为该数据包不符合规定，不向主机继续传送。解决方法：比较复杂的就是调整通信参数，找运营商调整参数，把峰值调整一下。再一个把程序修改一下，数据包增加填充位，使之大于128字节，强调数据包分组。最后我们采取的方法就是第一种简单的方法，强制填充5、6位数据，让它大于128，强制分组，使业务恢复正常。
前面几个案例大概总结一下，现在的网络越来越复杂，我们在做分析过程中，不仅仅对网络拓扑结构有相当的了解，对应用架构也有一些基础的知识，这样的话在做分析过程中，才能够举重若轻，才能得心应手。
【51CTO.com独家特稿，转载请注明出处】
【编辑推荐】
