蚂蚁网-多维人生，三实而立！

糟糕的业务网络行为

作者：易隐者 发布于：2012-12-11 15:40 Tuesday 分类：网络分析

       我之前在讲解业务应用分析评估时，重点分析业务应用的网络行为特征、业务基线、响应时间等内容。很多人认为：我的业务应用操作我们自己都是非常熟悉的，为什么还要这么复杂的来分析业务应用的网络行为呢？这是因为业务应用系统在开发的时候，由于各种原因，可能导致业务应用本身在交互的过程中，存在一些不合理的网络行为，进而影响业务运行的效率，造成网络资源的消耗和浪费。我们对业务应用系统进行网络交互行为的分析和评估，可以发现这些不合理的网络行为，帮助改进完善业务应用系统，提高业务应用交互的效率。

       近日正好在Laura Chappell的网站上下载了一个应用异常网络行为的数据包文件，这是一个FTP登录交互的报文，其交互过程如下： 

       客户端与服务器三次握手建立TCP连接之后，服务器端应用响应：220 FTP Service ，此时客户端发出应用请求“USER  FRED”，但我们可以清晰的看到其请求过程是：先将第一个字符发送过去，在收到服务器的确认之后，客户端再传输第二个字符，如此一个字符一个字符的传输。

       在后续的客户端密码传输过程中，客户端的网络行为跟传输用户名的网络行为一样。如下图所示： 

       服务器与客户端之间几十毫秒的RTT往返时间，加上客户端本身动辄数百毫秒甚至几秒的延时，造成整个FTP登录过程持续近14秒，如下图所示：

        我们再来一起看一个正常的FTP登录过程： 

       从这个FTP登录的过程我们可以清晰的看到，FTP客户端是将用户名、密码放在一个报文中一次性传送给服务器的。

       一个最为常见的FTP应用，一个最为普通的登录操作，正常情况下，数秒内完成，但是由于这个FTP应用不合理的网络行为，共消耗了近14秒的时间。

       什么是糟糕的应用网络行为？这个就是！为什么需要分析评估业务应用的网络行为特征，这个就是明证！

阅读全文>>

标签: FTP 行为特征 网络行为 应用分析 RTT 业务评估 往返时间

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

可能的URL超长导致丢包案例

作者：易隐者 发布于：2012-12-10 14:03 Monday 分类：案例讨论

       上周五，有网友兄弟给我发了一个报文，让我帮忙查看是否存在什么异常问题。我查看其TCP会话交互过程，如下图所示： 

       单从这个报文交互来看，客户端与服务器的TCP连接建立正常，客户端已经向服务器发送过get请求，并得到了服务器的确认，问题出在客户端向服务器发送的第二个get请求：“
http://192.168.0.12/Default_Login.aspxusercode=x6x9&password=81xx9xxx52x04xx20036xxx8313xx055&

MyCurrentCompany=&rdnum=0.5966797953405811”。

       客户端发出这个get请求之后，在37秒的时间内重传了5次，服务器端无应用数据需要主动的发给客户端，因此在这个时间段内我们未见来自于服务器的报文，而如果客户端的发送的这个get请求到达了服务器端，则服务器会根据其请求内容作出应用响应，最起码服务器端会对客户端的TCP报文发送ACK确认。但是这些都没有出现，这能够说明客户端的get请求报文根本未到达服务器端，即客户端的这个get请求报文被中间设备丢弃了，我们查看客户端的发送的第二个get请求报文的解码：

       我们发现这个报文除了其请求的URL长度较长（420字节）外，其他似乎也没什么特别的，因此，个人推测其被中间设备丢弃的原因可能是其URL超出了防火墙/负载均衡/WAF/IPS等设备的限制，或者是URL中包含“uesr”、“password”等敏感字段而被中间设备丢弃了。

阅读全文>>

标签: TCP 负载均衡 解码 ACK确认 防火墙 IPS get URL超长 get请求

评论(3) 引用(0) 浏览(6575)

TCP确认机制异常案例

作者：易隐者 发布于：2012-12-8 15:06 Saturday 分类：案例讨论

缘起
        一个好友通过Sina微博转发了一个兄弟的问题给我，其问题如下：
“AB机器tcp，A发送100字节给B，B返回数据但是其ACK=1，这期间A均正确ACK B的所有序列号，B置FIN位，A发 FIN+ACK 给B，此后B返回的ACK=2，那么此时A是应该重传之前的99字节，还是直接重传之前的FIN+ACK包给B？”。

       通过这样的描述我认为这在实际环境中应该不会存在，结果这个兄弟告诉我是在实际环境中发生的，并将交互的报文传一份给我。

       好奇之余，对这个报文进行了仔细的分析，接下来跟我一起来看一下整个分析的过程。

分析产生这个交互的原因

       选取其中一个TCP会话，查看其具体的报文交互情况，如下图所示： 

       这个报文交互的情况截图结合下面的TCP交互流图一起，看起来更清晰一些：

        通过交互报文的解码，我们可以清晰的看到，服务器192.168.104.229已经对客户端发送的get请求作出了应用层的响应，如下图所示：

       其响应为：HTTP/1.0 403 Forbdden
       但是其ACK号却为1，接收并处理了客户端的应用请求报文，但却并未对其进行确认，这充分证明服务器192.168.114.229的TCP确认机制出现了异常！

       我们再来一起看看客户端主动发送FIN报文之后的交互情况：
 
       客户端在发送FIN报文之后，服务器的ACK号变为2，这对于客户端来说，这是对其应用字段的确认，这说明服务器端仅收到客户端1字节的应用字段，因此客户端将剩下的303字节的应用字段放在FIN报文中一起发给服务器端，而服务器在收到这个报文后，回应客户端的ACK号变为3，客户端接着将剩下的302字节的应用字段放在FIN报文中再次重传给服务器端，如此反复。
       至此，我们已经能够意识到，服务器端的ACK确认并不是针对客户端的应用字段的，而是针对客户端的FIN报文的，服务器的确认机制出现了异常，服务器不再确认客户端的应用字段，而只确认客户端的SYN报文和FIN报文。

分析结论

       此问题产生的原因为：服务器的TCP确认机制出现异常，其只确认SYN报文和FIN报文而不对应用数据进行确认。

       另外，我们还留意到一个有意思的现象：正常情况下，端系统一般都会在发送的数据段获得对端确认之后，才会主动发送FIN报文，释放TCP连接，如果在多次重传之后仍未得到对端的确认，通常会向对端发送RST报文，异常释放TCP连接，但是此处可能为了提高交互的效率，客户端与服务器在发送的数据段未收到对端的确认报文就主动发送FIN报文释放TCP连接。

阅读全文>>

标签: TCP SYN FIN ACK TCP确认机制

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

由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) 浏览(6520)

更换设备后业务访问故障案例

作者：易隐者 发布于：2012-12-5 19:18 Wednesday 分类：网络分析

故障环境

网络拓扑

       故障环境下的拓扑结构如下图所示： 

1，分公司与中转区域通过互联网建立VPN隧道；
2，中转区域通过专线与总部业务服务器区域互联；

业务访问流程

       中转区域机器通过专线直接访问总部业务服务区域的服务器，而分公司则先通过互联网与中转区域建立VPN隧道，经中转区域CISCO VPN设备后，再访问总部业务服务区域的服务器。

故障现象

       此次故障现象主要表现为：
1，分公司只有极少数机器可以正常访问总部的业务服务器，绝大部分机器都不能访问总部的服务器；
2，中转区域全部无法正常访问总部业务服务器；
3，出现上述故障现象时，使用ping命令做连通性测试，都是正常的，无较大延时也无丢包现象；
4，上述现象发生在中转区域更换新的CISCO VPN设备之后，使用以前老的CISCO VPN设备未出现任何问题；
5，新的CISCO VPN设备的配置是从老设备上的配置导入的，因此可以肯定配置完全一致。

故障分析

1 分析过程

       根据故障现象以及前期的测试情况来看，该故障属于业务应用故障，我们认为站在数据报文交互的角度进行分析比单纯猜测和毫无根据的做各种测试更有效率。

 故障重现
       我们首先选择一台IP地址为10.18.3.22的机器作为测试机，并在测试机器上使用IE浏览器访问10.3.3.21服务器，以便在故障现象出现时，我们捕获测试机与服务器业务交互的报文。

近故障点抓包，分析交互过程
       考虑到服务器端在总部，在服务器近端抓包难度很大，我们决定先在客户端近端抓包。
在测试机访问服务器故障重现时，我们在测试机近端捕获了测试机与服务器间的业务交互报文，如下图所示：  

测试机与服务器的交互报文
 
对应的TCP数据流图

       通过对这个报文交互过程的分析，我们发现，测试机与服务器的TCP三次握手建立连接正常，客户端向服务器发送“GET”请求也正常，问题出现在服务器给测试机的响应报文，我们在测试机近端抓包，只看到了服务器向客户端发送的28字节的报文，而我们通过该TCP报文的Seq=1433可以计算出，在这个报文之前，还有一个载荷长度为Len=1433-28-1=1404字节的TCP报文未正常到达测试机。测试机在等待45秒后，由于一直未收到该报文，其主动向服务器发送FIN报文，正常释放了这个TCP连接。
       纵观整个过程，我们可以自然的得出结论：服务器端的报文在网络中被中间设备丢弃，导致了故障的产生。
一般而言，偶尔丢包是正常的，TCP会通过重传机制，保证应用正常交互，但是在这个故障交互的报文中，我们仅看到有报文被丢弃，并且这个报文在45秒的时间内，一直未到达测试机，这不符合TCP重传的工作机制，只有一种情况可以解释这种现象，那就是这个一直未到达测试机的报文，其原始报文和重传报文都被中间设备丢弃了。
       结合故障现象是在更换为新的CISCO VPN设备后出现的，我们很自然的想到，应该是新更换的CISCO VPN设备丢弃这个报文。那么CISCO VPN设备并未做特殊的设置，一般不会丢弃特定报文，联想到这个被丢弃的报文应用字段长度为1404字节，加上20字节的TCP报头和20字节的IP报头，其IP报文长度应该有1444字节，是否有可能是其超出了CISCO VPN设备的某些接口的MTU呢？
       对CISCO VPN设备的特性并不了解，那么我们还是做一个简单的测试，验证我们的分析和推论是否正确。

验证
       将测试机网卡的MTU值修改为1400之后，再次尝试通过IE访问总部的服务器，访问完全正常，下面为修改MTU值之后的测试机与总部服务器之间正常交互的报文： 

       上述正常交互的报文，充分验证了我们前面的推论。

2 分析结论

       老CISCO VPN设备的tunnel接口MTU等属性并没有保存在配置文件里，因此虽然将老设备的配置直接导入到新设备中，但是新更换的CISCO VPN设备VPN tunnel接口MTU较小，导致服务器发给客户端的TCP大包报文被丢弃，引发业务访问故障的产生。
       而分公司极少数机器在更好新设备后仍然能够正常访问服务器，是因为这些机器本身网卡的MTU值较小，因此虽然新的设备上线，但并不影响这些机器对服务器的正常访问。

故障解决

      调整CISCO VPN设备相关tunnel口MTU值，此故障解决。

阅读全文>>

标签: 疑难故障 丢包 MTU VPN

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