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

由TCP保活引起的业务访问故障案例

作者:易隐者 发布于:2012-12-7 15:18 Friday 分类:网络分析

1 故障环境

1.1  故障拓扑

       故障发生的网络拓扑结构如下图所示: 

点击查看原图

1.2  业务报文交互路径

1,客户端通过网闸映射地址218.X.X.151访问内部业务服务器10.X.X.209;
2,客户端经过网闸后,源地址变为网闸内口地址10.X.X.160访问真实的业务服务器。

2  故障现象

       故障现象主要表现为:
 客户端访问业务服务器出现中断现象,并且故障基本都发生是在夜间12点以后;
 第二天重启网闸后,业务访问恢复正常,但是到夜间12点左右业务连接会再次中断;
 在业务访问出现中断以后,偶尔会不定时的可以成功进行连接,但是持续时间不长就再次中断;
 仅此业务应用存在这个异常,其他的业务基本正常。

3 故障分析

3.1 分析思路

       考虑到故障都发生在夜间12点左右,因此在网闸内外网口同时部署网络分析产品,对内外网口交互的报文进行长时间的捕获存储,第二天,我们分别选取故障发生时间内的报文进行关联分析和对比分析。

3.2 分析过程

3.2.1 异常出现时,网闸外口的报文交互情况
       我们选取故障发生时,网闸外网口的交互报文进行查看,我们在“TCP会话”视图中,发现了大量交互报文少、流量小、收发报文特征明显的TCP会话,如下图所示: 

点击查看原图

       我们选取其中任意一个TCP会话,查看其详细的报文交互情况,如下图所示: 

点击查看原图

       我们可以清楚地看到,客户端与服务器映射的外网地址通过三次握手建立TCP连接之后,服务器映射地址立即向客户端发送了FIN报文,主动释放TCP连接,后续的带有应用字段的客户端报文到达后,服务器直接向客户端回应RST报文。
       我们查看了其他的TCP会话的详细报文交互情况,基本与上述情况一样。由此来看,似乎是网闸主动发送FIN报文导致了业务应用出现异常,网闸为什么会在已经建立三次握手之后立即主动发送FIN报文呢?难道是服务器主动发送的FIN报文?或者是网闸的BUG导致网闸主动发送FIN报文?我们需要在内网端做个关联对比分析才能确定。

3.2.2 在网闸内口发现保活报文
       当我们取故障时内网的报文时,发现内网在做捕包存储时出现异常,抓包工具在故障出现之前崩溃了,并未将故障发生时的网闸内口报文捕获保存下来,而由于时间紧急,我们没有机会再花费一天的时间去捕获内网的报文,这些故障现场的不确定性现象发生了,我们只能抓取当下的网闸内口报文进行辅助分析。
       我们在网闸内网口抓包发现大量的特征明显的TCP会话,如下图所示:

点击查看原图

       这些TCP会话仅有几个报文的交互,不像正常的业务数据交互报文,我们选择其中一个TCP会话查看其具体的交互报文,如下图所示: 

点击查看原图

       这是服务器发给客户端的报文,下面是客户端给服务器的报文: 

点击查看原图

       结合这两个报文,我们可以肯定,这是一个TCP保活报文。这些仅交互2个报文的TCP会话是服务器发给客户端的TCP保活行为!

3.2.3合理推测
       这些数量众多的保活行为的TCP会话,引起了我们的关注,那么是否是保活行为导致业务应用出现问题呢?保活的功能之一是维持已有TCP连接,关于TCP保活的详尽描述大家可参考我博客的文章《TCP保活(TCP keepalive)》。
       TCP保活的这个特性很自然的让我们想到可能是TCP保活功能引起网闸连接表满从而导致业务异常。但是网闸作为一个网关类设备一般都支持几十万甚至数百万的连接数,在无异常攻击报文的情况下不至于24小时连接表就全部满了,并且也只有这个业务应用出现异常,其他应用都是正常的。
       我们发现外网的客户端访问到内网时,其源地址全部转换为网闸内口地址10.X.X.160,至此我们恍然大悟:源IP、源端口、目的IP、目的端口、协议类型等五元组信息决定一个连接,而在网闸内口,源IP、目的IP、目的端口、协议类型都已经确定,只有源端口是变换的,而端口范围只能在0-65535之间,还要去除一些常用的端口,如此一来,网闸内口跟服务器之间能够建立的TCP连接数只能在65535以内!
       在这种情况下,客户端访问业务服务器的TCP连接在24小时内达到近65535个,从而导致后续的客户端与业务服务器无法正常建立连接,引起业务访问故障。
       至于故障后又能偶尔连接正常但很快再次异常的原因也很好解释,那就是网闸内口在维护如此众多的连接时,总会由于各种原因导致几个连接异常释放,如此一来则紧接着的业务访问连接会正常建立,但是一旦用完为数不多的几个连接后,后续的业务连接将再次出现异常。
       整个交互过程涉及到的客户端、网闸外口、网闸内口、服务器的状态变化如下图所示: 

点击查看原图

3.2.4验证
       我们建议用户在下班后手动清空网闸内口已有连接,观察夜间12点故障是否出现来验证我们的推测。后经用户反馈,在清空连接后夜间12点左右故障未再现,如此充分证明我们上述的推测是正确的。

3.3 分析结论

       服务器端设置了TCP保活功能,对所有的TCP连接主动实行TCP保活探测,这导致网闸内口与服务器建立的TCP连接无法得到释放,在24小时以内,TCP连接数接近65535个,而此时客户端再次发起与服务器之间的业务连接之后,网闸内口已经无法再与服务器新建TCP连接,如此导致业务连接无法建立。

4 故障解决

       在找到导致此业务故障的真正原因之后,我们就可以对症下药,通过任意选择如下几种方式之一来彻底解决这个故障:
1, 可以在服务器上关闭TCP保活功能;
2, 在网闸内口关闭源地址转换(SNAT)功能;
3, 将网闸内口TCP连接释放时间调整至小于服务器发送TCP保活的间隔时间,这样可以在服务器发送保活报文之前,让网闸内口提前释放该连接;
4, 网闸内口使用TCP连接复用功能,让大部分的外网客户端访问连接仅通过少量的内部连接实现正常的业务交互,而服务器则可以与网闸内口之间少量连接保持保活。

阅读全文>>

标签: 疑难故障 五元组 连接表 TCP保活 TCP keepalive 连接复用 网闸 SNAT

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

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

作者:易隐者 发布于: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) 浏览(10104)

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