欢迎关注:1,欢迎关注本博客,你可点击右手边的【QQ邮件订阅】订阅本博客!2,本博客推出江湖救急计划,主要为工作中遇到疑难杂症的兄弟提供远程技术支持和分析,如有需要,请在江湖救急计划页面给我留言!

多层架构业务应用场景下的网络分析

作者:易隐者 发布于:2012-11-22 13:06 Thursday 分类:网络分析

       我们在日常工作中,最为常见的网络分析场景为针对简单的C/S或B/S架构的应用的分析,在简单环境中,C/S或B/S架构的应用主要是一层架构的,如下图所示: 

点击查看原图

       在这个架构的应用中,业务的交互仅仅涉及到客户端与服务器,这样的业务交互过程和报文交互路径都非常简单清晰,分析这种架构业务应用的性能问题、故障问题并不存在很大的难度,因为不会涉及过多的中间环节,但是在规模较大、应用较为重要和复杂的环境中,最为常见的是多层架构的业务应用系统。

三层/多层架构应用

       那么什么是多层架构的应用呢?我从网上找了一段文字,应该能够将其说明清楚:“所谓三层架构,是在客户/服务之间加入了一个"中间层",也叫组件层。它与客户层、服务器层共同构成了三层体系。这里所说的三层体系,不是指物理上的三层,不是简单地放置三台机器就是三层体系结构,也不仅仅有B/S应用才有三层体系结构,三层是指逻辑上的三层。通过引入中间层,将复杂的商业逻辑从传统的双层结构(Client-Server)应用模型中分离出来,并提供了可伸缩、易于访问、易于管理的方法,可以将多种应用服务分别封装部署于应用服务器,同时增强了应用程序可用性、安全性、封装复用性、可扩展性和可移置性,使用户在管理上所花费的时间最小化,从而实现了便捷、高效、安全、稳定的企业级系统应用。”

       三层架构主要分为表示层、业务逻辑层、数据访问层三层,每层主要负责的工作如下:

表示层:主要负责从用户收集信息,将用户信息发送到业务服务层做处理,从业务服务层接收处理结果,将结果显示给用户等;
业务逻辑层:主要负责从表示层接收输入,与数据层交互执行已设计的业务,操作(业务逻辑,系统服务等),将处理结果发送到表示层等;
数据访问层:主要负责数据存储,数据获取,数据维护,数据完整性等;

       下图为一个经典三层架构的应用示意图: 

点击查看原图

       在实际工作环境中,最为简单和常见的三层架构的应用为下图所示:

点击查看原图

       在这个架构中,其实是将表示层和业务逻辑层整合在一起,通过应用服务器统一对外提供业务访问界面和业务逻辑处理。
       我们遇到的大型、复杂的应用基本上都是基于多层架构开发的,针对多层架构应用的分析将是以后网络分析工作中无法回避的问题。

分析多层架构应用的难处

       针对多层架构应用的分析,可不像我们平时分析简单一层架构的B/S、C/S应用那样简单,分析多层架构的业务应用主要具有以下几点难度:

1, 业务数据交互路径更为复杂
       一个客户端访问多层架构的业务应用时,其业务数据交互路径一般如下图所示: 

点击查看原图

1, 客户端向Web服务器发送相关业务应用的操作
2, Web服务器将客户端的相关业务操作请求交由应用服务器处理
3, 应用服务器将业务操作涉及到的相关数据请求发往数据库服务器
4, 数据库服务器将相关数据操作结果反馈给应用服务器
5, 应用服务器根据数据库服务器反馈的数据结合业务逻辑,得出相关信息发往Web服务器
6, Web服务器将客户端相关业务操作的反馈数据显示给客户端

       纵观整个交互的过程,我们可以知道同样一个业务操作的交互,多层架构的应用跟简单的一层架构的应用相比,多出了数个中间环节,这导致业务交互路径变得复杂,我们需要在不同的环节分别抓包做关联分析。这些都会增加网络分析的工作量和难度。

2,数据加密问题:数据库加密
       基于数据安全的角度,现在很多涉及到数据库的交互,其在应用层将数据库应用字段加密,如下图所示: 

点击查看原图

       在这种情况下,我们站在网络交互的角度捕获的报文只能够提供三层和四层的相关信息,数据库应用数据信息均无法正常查看,因此我们无法分析到底哪一个报文是某个客户端的业务操作引发的应用服务器对数据库服务器的访问行为,这给我们的分析工作带来了巨大的不便。
       如果真的遇到加密的情况,那么站在网络层面对其报文进行分析已经无能为力了,建议在数据库服务器上站在业务应用的角度,调用其数据库日志进行辅助分析。

3,存在连接复用问题:连接复用
       一般情况下,如果客户端与服务器建立业务交互连接,那么可能涉及到的web服务器、应用服务器、数据库服务器之间都分别新建连接用于相关数据的交互,如下图所示: 

点击查看原图

       但是在这个情况下,一旦客户端的访问的数量非常巨大或者访问峰值时的连接非常巨大,将导致应用服务器与数据库服务器之间的连接数非常大,严重影响数据库服务器的性能,为了解决这种问题,应用服务器在与数据库服务器之间交互时,采用连接复用的方式以节省服务器的资源,提高交互的性能和效率,如下图所示: 

点击查看原图

       在这种方式下,应用服务器与数据库服务器之间只需要建立很少的连接,并将这些连接长期保持(长连接),后续的所有应用服务器与数据库服务器之间的增、删、改、查询等操作均通过已有的数条连接进行应用交互。如此大大降低了应用服务器与数据库服务器之间的连接数。

       连接复用给网络分析带来的问题是,我们不得不在数条连接中查找某个客户端具体操作对应的数据库报文,而每个数据库的连接均包含大量的数据库语句,有些是相近甚至是相同的数据库语句,这些无疑会给网络分析工作带来巨大的工作量和难度,如果同时间访问的客户端数量很多的话,这样的分析工作无异于大海捞针,基本上变得不可行了。

       上述三大难点,给我们分析多层架构的应用带来了非常大的难度,虽然如此,但是好在并不是所有的多层架构应用都是连接复用的,也不是所有的数据库交互都是加密的,如果实际工作中真的遇到了多层架构的应用需要我们进行分析,我们往往没有什么太多的选择余地,我们能做的就是尽己所能、尽力而为了。

多层架构应用的分析

       针对多层架构的业务应用的分析,我们一般按照如下的思路开展网络分析工作:

1, 关键路径多点同时捕包
       要针对多层架构的业务应用进行分析,必须在业务数据交互路径中的每个关键点进行捕包,以便后续的关联分析和对比分析。这个在我的文章《疑难网络故障的分析方法和原理之对比分析法》中介绍得非常清楚,大家可以访问http://www.vants.org/?post=49参考。
       在多层架构的应用中,我们主要需要在客户端与Web服务器之间、Web服务器与应用服务器之间、应用服务器与数据库服务器之间同时进行业务交互报文的猜忌和捕获,如下图所示: 

点击查看原图

2, 捕包机器时间同步
       一般而言,我们可以通过NTP服务器将多台捕包机器的时间同步,但如果在条件不允许的情况下,大家可参考我的文章《如何保证中间设备两端捕获的数据包的时间同步性?》中提供的简单有效的方法来实现不同关键点捕包时间的同步,如下图所示: 

点击查看原图

       在各个关键路径上的捕包机器时间都同步了,那么在大部分的情况下,我们就可以根据连接或报文发生的时间段在海量业务交互报文中提取跟业务操作相关的报文进行关联分析,从而提高关联的分析的效率。

3, 关联分析
       一旦全部准备就绪,那么剩下的工作就是根据不同位置捕获到的业务交互报文,利用应用层字段,如cookie值、sessionID、用户名、帐号、Userid、业务号、单号、ProcessID等关键字实现客户端<->Web服务器、Web服务器<->应用服务器、应用服务器<->数据库服务器之间的关联。下面我选取了部分在实际工作中遇到的多层架构应用中可关联的关键字截图以供参考: 

点击查看原图

点击查看原图

点击查看原图

参考资料:
1,海万学——《多层结构应用性能分析与故障诊断》
       海万学是国内为数不多的网络分析方面的专家,其个人博客为:www.packetstory.com,就是更新有点慢,大家可关注。
2,gqming——《多层结构应用各层之间数据传递的问题》链接为http://bbs.csdn.net/topics/190123492

阅读全文>>

标签: 同步 日志 网络分析 对比分析法 应用字段 关联分析 C/S 多层架构 连接复用 cookie 时间同步 B/S 三层架构

评论(0) 引用(0) 浏览(12600)

如何跟踪分析数据经过中间设备后的变化以及这些变化给客户端与服务器带来的影响

作者:易隐者 发布于:2012-8-20 21:20 Monday 分类:网络分析

       中间设备会对经过它的数据报文进行修改、检测、丢弃等处理,这些操作对交互数据的客户端与服务器都会产生相应的影响,这些影响在客户端与服务器端可能会导致不同的外在表现。我们在实际分析定位疑难应用故障时,需要了解清楚中间设备对数据报文做了哪些处理以及这些处理动作对客户端与服务器产生了哪些影响。
       我们如何分析中间设备对数据报文的处理动作、报文进出中间设备的差异以及这些差异给客户端服务器带来的影响呢?一般情况下,我们可以按照下面的步骤来进行分析:

1,数据报文在中间设备的进口和出口同时抓包

      在数据报文进入中间设备前的位置以及数据报文被中间设备转发后的位置同时抓包。

2,将设备进出口的同一数据流关联起来

       如何将设备进出口的同一数据流关联起来?在中间设备未做NAT的情况下,我们一般根据五元组信息就可以直接关联了,此案例就是如此关联的;在做NAT的情况下,如果仅仅是源地址做了改变而源端口未改变的话,我们就可以利用源端口、目的地址、目的端口和协议类型来进行关联,如《某地矿局网页打开慢故障分析案例》就是利用四元组关联的;如果在做NAT时,数据流的源地址、源端口都变化了,我们还可以通过数据流的应用信息进行关联。
       具体到每个数据包的关联,则主要通过IP标识字段或数据包应用层数据进行关联。
       具体关联的原理请参见《疑难网络故障的分析方法和原理之关联分析法》一文。

3,根据数据交互情况,分别画出数据交互过程图

       在我们将中间设备进出口的同一数据流和具体数据包关联起来之后,我们就可以画出数据在中间设备前后的交互过程图示。
       这个交互过程,可以自己手动画出来,也可以利用工具自动生成,例如在wireshark中,我们可以使用“flow graph”生成数据交互视图,如下所示: 

点击查看原图


       在科来2010版本中,我们也可以利用“TCP会话”视图中的“时序图”功能,自动生成交互视图,如下所示: 

点击查看原图


        在分别生成了中间设备进出口的数据交互流图之后,我们就可以把他们关联起来一起做对比分析了。

4,通过设备进出口数据交互的图示的对比和具体数据包的关联,发现改动和影响

       通过设备进出口数据交互的图示的对比和具体数据包的关联,我们就可以查看出中间设备对数据报文的处理动作以及这些处理动作对客户端和服务器的具体影响了。下图为一个样例图: 

点击查看原图

阅读全文>>

标签: 关联分析 中间设备 数据包被更改

评论(0) 引用(0) 浏览(7737)

Powered by 易隐者 基于emlog 皖ICP备12002343号-1