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

经受时延的确认(Delay ACK)

作者:易隐者 发布于:2012-9-12 21:05 Wednesday 分类:网络分析

       通常TCP在接收到数据时并不立即发送ACK,相反,它推迟发送,以便将ACK与需要沿该方向发送的数据一起发送(有时称这种现象为数据捎带ACK),这样做的目的是尽量减少发往网络的报文,以提高传输的效率,节省网络资源。

经受时延的确认工作过程

      下图清晰的展示了Delay ACK的工作过程:

点击查看原图


       我们一起来看一个实际环境中的Delay ACK实例: 

点击查看原图

 

Delay ACK响应时间

       在实际工作环境下,我们做应用性能分析时,有时会遇到应用程序处理时间较长(一般超过200ms)时,我们经常会看到服务器先向对端发送了TCP ACK报文(无应用层数据),这个确认的报文一般就是TCP的Delay ACK,如下图所示: 

点击查看原图

       我们在遇到此类现象时,千万不能简单的将此处的Delay ACK当成应用响应时间

Delay ACK的可能影响

       另外需要注意的是,Delay ACK虽然能够提高传输效率,节约网络资源,但是在某些情况下,其会给应用带来难以想象的延时问题(假想一下这样的场景:服务器单向向客户端间歇发送一些数据,但是客户端无应用数据需要提交给对方,此时,如果客户端每收到对端包含有应用字段的报文时,都等待200ms才对其进行确认,那么如果服务器与客户端的交互次数为1000的话,那么整个应用交易或应用会话将要持续1000*200=200S,而200秒对于绝大多数的应用来说是不可接受的)。

Delay ACK补充

1,绝大多数实现采用的时延为200ms,也就是说,TCP将以最大200ms的时延等待是否有数据一起发送,但是这个200ms的值并不是必须的,开发者可以根据自己的需要来设定这个数值,因此,我们在实际工作过程如果发现非200ms但是工作机制与Delay ACK一致的TCP交互过程,那基本上就是Delay ACK机制了。

2,如果连续收到对端两个数据段,则一般立即回应ACK数据包,如下图所示:

点击查看原图

阅读全文>>

标签: TCP 应用字段 延时 响应时间 应用响应时间 ART delay ack ACK 捎带ACK 经受时延的确认

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

TCP 的PUSH标志位

作者:易隐者 发布于:2012-8-31 15:32 Friday 分类:网络分析

       发送方使用该标志通知接收方将所收到的数据全部提交给接收进程。这里的数据包括接收方已经接收放在接收缓存的数据和刚刚收到的PUSH位置一的TCP报文中封装的应用数据。
还是看一个简单明了的图示吧:

点击查看原图

关于PUSH位的一些讨论和分析

       Long_323(龙的传人)兄弟曾跟我讨论:在无法解码应用层报文时,能否根据TCP  PUSH位来分析应用响应时间?

       我的回答是:不可以,我个人不会这么做,因为不够科学。

       所谓应用响应时间,是指客户端有发出请求,服务器端会针对该请求作出相应的响应,我们才可以分析计算其响应时间。如果我们无法解码应用层,那么我们就无法确定其到底是不是一个请求报文,如果不是请求报文(例如,我的《TCP交互交互式应用》一文中提到的互动游戏的报文、TCP keepalive保活的报文等)但是其TCP PUSH位是置一的,那么我们怎么能根据这一点就计算出应用的响应时间呢?

       也许有经常关注我的兄弟会问:你说不可以,那怎么在你写的文章《关于“client push”应用响应时间测量方法的讨论》中,建议说“从客户端带有PUSH标志位的数据包开始计算,至服务器端响应应用层数据停止计算”呢?如果真有这么问的兄弟,我会非常欣慰,因为能问出这个问题的人,说明他有认真仔细的研读过我的文章,那么他肯定会从中获得一些帮助和成长,我会为此而心生满足。言归正传,在我的《关于“client push”应用响应时间测量方法的讨论》一文里,全文的基础和基调都已经定在为“client push”的应用场景了,看标题你就会明白,不需要我多说了吧。

       言已至此,我想大家也会明白,我说的不可以并不是绝对不可以,而只是站在我个人的角度而说的,仅代表我的个人主观选择。

       在有些情况下,可以作为一个参考分析思路。那么到底在哪些情况下能这么做呢?我个人认为主要有以下几点:
1, 可以明确我们要分析的应用类型为请求-响应类的应用
2, 虽不能解码,但是我们在做分析时,需要将具体的请求操作和数据报文结合起来分析,以提高分析的科学性和准确性
3, 对分析的结果要求不是非常高、非常严谨的

       还有兄弟认为如果所有带有应用字段的TCP报文PUSH位都置一的话,会对服务器造成较为严重的性能影响。这个所谓的影响如果真的存在的话,我想应该是在服务器的内存、CPU等资源严重不足或应用程序本身处理存在严重性能问题时才会出现,是因为本来就有问题了,导致PUSH位都置一的报文加重了这种影响,而不是因为PUSH位置一的报文导致了服务器的性能问题的出现。

关于PUSH位的应用

        PUSH位就是用来通告接收方立即将收到的报文连同TCP接收缓存里的数据递交应用进程处理。一般会出现在发送方封装最后一个应用字段的TCP报文中,针对TCP交互式应用,则只要封装有应用字段的TCP报文,均会将PUSH位置一,当然,应用程序的开发者,可以根据需要,在某个应用功能模块或某个应用操作时,将所有封装应用字段的TCP报文PUSH位置一,以提高交互双方的处理效率,这在理论上应该也是可行的。

  

阅读全文>>

标签: TCP 应用字段 响应时间 应用响应时间 ART 保活 push 交互式应用 client push 接收缓存 keepalive

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

TCP交互式应用

作者:易隐者 发布于:2012-8-30 21:29 Thursday 分类:网络分析

       TCP交互式应用由于其交互的特性,一般对时延的要求较高,因此一旦有应用数据时便立即向对端发送并要求对端能够及时处理,其交互的报文基本上都是小包(小于MSS),常见的TCP交互式应用主要有telnet、rlogin、互动游戏等,我们先来看一个TCP交互应用的报文分析:

点击查看原图

其具有以下三个明显特点:

1,客户端与服务器端的数据传输是交互式进行的;

2,应用字段长度均较小;

3,带有应用字段的TCP报文PUSH位均置一。

TCP交互式应用的场景(以游戏为例):

       对于实时网络游戏这种交互应用,如果TCP接收方不立即将应用数据提交应用程序处理的话,很可能会导致游戏应用出现卡、客户端与服务器端不同步故障,严重影响游戏应用的正常运行。你想啊,你在玩CS,扮演警察,突然一个悍匪跟你正面冲突,悍匪那边快速操作已经移动位置了,但是悍匪移位这个应用信息却被你的TCP放在接收缓存里,你机器显示器上看到的悍匪还在原来的位置,然后你自然向悍匪原来的位置开枪,结果呢,肯定没伤到悍匪,却被早就移位的悍匪爆头击毙,这时候你会爽吗?肯定骂死这个游戏应用了,呵呵。
        那么交互式应用如何保证应用字段能够被立即处理呢答案就是将带有应用字段的TCP报文(不论应用字段大小)的PUSH位全部置一,虽是小包,但TCP一旦接收到便立即将其交付应用程序处理。

       我在08年做内部《TCPIP详解卷一》培训在讲到第19章《TCP的交互数据流》时,曾今专门捕获了WAR 3的局域网游戏的交互报文,用于讲解TCP交互式应用的特性,现在把这个报文一并放在此供各位参考。

WAR 3的局域网游戏的报文:

点击查看原图

        交互式应用并不是非常常见,因此经常被大家忽略,导致有时在遇到交互应用场景的分析时,将其当作HTTP等常见应用的特性来进行分析,可想而知,如此将走向错误的分析方向,望各位兄弟姐妹引以为鉴。

        这里提到了TCP报文的一个非常重要的标志位——PUSH,我下一篇文章将会针对PUSH位做一个详尽的讨论和分析,望大家关注。

阅读全文>>

标签: 同步 TCP 应用字段 故障 push 交互式应用 交互

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

带有应用层字段的TCP RST报文

作者:易隐者 发布于:2012-8-21 11:09 Tuesday 分类:网络分析

       今天在为一个朋友准备培训材料的时候,某个客户那边捕获的数据包文件中,无意中发现RST报文中竟然带有应用层字段,如下图所示:

点击查看原图

       这是一个SSH的TCP连接,一般而言,对端在收到TCP RST报文后,便会立即释放该TCP连接,这个是传输层控制的,即使RST报文中带有应用层字段,传输层也不会将这个应用层字段提交给应用进程。

       如此来看,这个TCP RST报文带有应用层字段“ Reset cause: Go away, we're not home ”,似乎也没什么意义。

      

阅读全文>>

标签: TCP RST reset 应用字段 培训 SSH

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

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