欢迎关注: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)

网页打开慢但HTTP下载快故障分析案例

作者:易隐者 发布于:2012-10-10 16:06 Wednesday 分类:网络分析

【说在之前】:

1,用到了疑难杂症网络分析过程中最基本、最核心的两个分析方法:对比分析法关联分析法

2,该案例涉及到的知识点主要有SYN重传连接数限制等,大家可参考本博客中相关知识点的文章。

【我的案例】:

故障环境

       某单位大体的网络结构如下图所示: 

点击查看原图


内部办公人员通过交换机到流控设备,再通过防火墙做NAT访问互联网。

故障现象

1,在地矿局进行互联网时,打开网页的速度非常的慢,有的网页要刷新几次才可以正常显示;
2,但是使用下载工具或是基于HTTP的下载速度却很快。

故障分析

1 确认故障原因

        我们找一台主机,访问互联网的某网站,发现的确比较慢,我们抓取故障时的交互数据包,如下图所示: 

点击查看原图

       通过上图,我们可以发现,客户端在与服务器建立TCP连接时,其SYN请求报文被客户端重传了一次,这个重传导致了2.88秒的延时。TCP重传一般是中间设备丢包导致的,那么到底是在什么地方丢包的呢?我们首先需要界定一下可能丢包的故障关键点。

2 选择故障关键点

       该故障环境相对简单,在办公用户访问互联网时,数据包只通过了交换机、流控设备和防火墙,而交换机主要负责转发数据,不会对数据包进行深度的检测和过滤等操作,所以在该环境下主要的关键故障点是流控设备和防火墙,如下图所示:

点击查看原图

 

3分析流控设备是否丢包

       关键故障点确定之后,我们首先在流控设备的前后同时抓包做对比分析,以确定是否是流控设备丢包,如下图所示: 

点击查看原图


       通过我们还原故障现象时,在流控设备前后抓取数据包的对比分析,结论显示,流控设备前后数据包交互的过程是一样的(这个对比分析通过五元组关联同一会话之后,对比查看数据交互过程的差异即可,由于流控设备前后的数据交互过程完全一样,在此不做具体详细的分析说明),这说明,在打开页面较慢时,流控设备并未丢弃任何交互的数据报文。

4 分析防火墙是否丢包

       同样,我们再在防火墙的进出口同时抓包,通过比较防火墙前后数据包的交互情况来确定造成故障的原因,部署图如下所示: 

点击查看原图


1, 在访问某网站出现缓慢现象时,在防火墙前后同时抓取数据包,并保存,为下面的对比分析提供原始的数据报文。
2,我们先分析防火墙内网口抓取的数据,在科来网络分析系统的“TCP会话”视图,我们发现了一个web连接持续的时间为6秒,并且其在三次握手过程中,存在重传现象,如下图所示: 

点击查看原图


这个TCP会话的源端口是1124,目的地址为58.30.236.11,目的端口是80
3,我们通过关联分析法,在进行网页访问时,我们在防火墙前后同时进行抓包,下图就是在防火墙出口处抓取到的数据包: 

点击查看原图

       我们知道防火墙在网络运行中起到防护作用,会将未经授权的报文过滤,但是防火墙一般不会阻止正常的数据包,我们在比较上面两张图发现,在防火墙后捕获到的数据包第一次发送同步请求没有成功,然后又重传了一次同步数据包,才成功建立了连接;而在防火墙前面抓取到的数据包却没有看到重传的数据包(黑框标记的部分),这很清晰的说明,第一个SYN报文被防火墙丢弃了。

4 分析结论

       通过上面的分析,我们可以得出如下结论:

       由于防火墙在转发数据包时,随机丢弃了客户端发送的SYN报文而造成的。可能是防火墙配置不当(连接数限制)或防火墙BUG(在处理TCP新建连接时不稳定)导致的。

总结

       经过分析知道是由于防火墙不规律丢弃SYN报文导致的网页打开慢现象,但是为什么HTTP下载的速度却很快?这是因为防火墙仅随机丢弃SYN报文,而HTTP下载在刚开始建立TCP连接时,防火墙有可能会丢弃其SYN报文,但是下载行为决定其会不断发起SYN报文进行连接建立的尝试,而一旦连接建立成功,则防火墙不会丢包,给用户的感觉就是速度也非常快。

阅读全文>>

标签: TCP 对比分析法 关联分析法 丢包 SYN 防火墙 重传 BUG NAT 连接数限制 SYN报文

评论(4) 引用(0) 浏览(11839)

疑难网络故障的分析方法和原理之对比分析法

作者:易隐者 发布于:2012-7-4 12:04 Wednesday 分类:网络分析

       有一些故障,特别是业务应用的故障,客户端与服务器端在进行业务数据流交互时,中间会经过各种链路和中间设备。当客户端反馈业务应用存在故障,我们仅仅在某一个点(客户端、服务器端或者其他中间链路处)进行抓包,是无法真正反映故障真实面貌的,我们需要多点同步抓包,这样才能完整的反馈业务数据流在网络中交互的全部过程。在这个完整交互的过程中,我们通过对比分析,可以发现故障发生的位置和原因。

对比分析法的定义

       对比分析法就是在中间设备两端(数据包的进口、数据包转发口)同时抓包,并对进出口处所抓取到的数据包做相应的对比,从而发现中间设备对相应数据包的处理情况,包括更改、丢弃、转发以及经过中间设备后的延时等。

点击查看原图

对比分析法的原理

      网络中间设备的主要功能是对数据包的转发,当一个目的地址不是中间设备的数据包进入一个中间设备时,它必然会被中间设备转发到其某一个出口。如下图所示:

阅读全文>>

标签: 对比分析法 延时 丢包 中间设备对数据包的更改

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

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