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

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

某公司业务系统经ISA防火墙访问正常而经硬件防火墙访问慢故障分析解决案例

作者：易隐者发布于：2013-1-25 10:10 Friday 分类：案例讨论

1 故障环境

这个故障产生的环境较为简单，我们在不影响故障分析的前提下，简化分析网络环境，其故障发生的拓扑结构大致如下所示：

1.1 网络拓扑

故障发生的拓扑结构如下所示：

1，业务服务器的IP为16.66.252.249/24，网关为16.66.252.254；

2，测试客户端的IP为16.66.180.167/24，网关为16.66.180.1；

3，防火墙与服务器相连的接口地址为16.66.252.254，防火墙与测试客户端相连接口的地址为16.66.180.1；

4，防火墙工作在纯路由模式下；

1.2 业务访问流程

1，业务服务器的业务端口为TCP 211；

2，测试客户端将数据报文经过硬件防火墙转发至业务服务器端，业务系统根据测试客户端的相关请求，返回业务应用数据报文经硬件防火墙转发给测试客户端；

2 故障现象

经过与用户的交流和现场的测试，确定故障现象主要表现为以下几点：

1，客户端经过ISA访问业务服务器，测试连接速度非常快；

2，将ISA换成天融信硬件防火墙，硬件防火墙工作在纯路由模式下，测试发现客户端连接业务服务器的大概需要消耗20秒左右的延时；

3，用户反馈，测试过使用cisco的ASA和H3C的硬件防火墙，均有不同程度的较大的连接延时；

3 故障分析

3.1 分析过程

3.1.1 确认是否是硬件防火墙产生的延时

经过ISA防火墙，业务系统连接测试一切正常，速度很快，但是经过硬件防火墙（TOPSEC/CISCO/H3C）之后，就产生了较大的延时，那么看起来似乎是硬件防火墙产生的延时，我们先从这个角度入手，在测试客户端与业务服务器端同时抓包做对比分析，用于确认是否是硬件防火墙产生的转发延时。

1，我们分别在服务器、客户端上安装科来网络分析系统，并开启捕获界面；

2，在测试客户端上做应用连接测试，当测试客户端弹出连接成功窗口后，分别停止客户端与服务器端的捕包界面；

3，我们通过科来网络分析系统的“TCP会话”视图分析客户端上的测试连接建立的TCP会话过程，如下图所示：

客户端的这个数据交互过程充分说明了，在测试连接的过程中，产生了17秒左右的延时。

4，通过科来网络分析系统的“TCP会话”视图分析服务器端的应用连接建立的TCP会话交互情况，如下图所示：

上图清晰的反应了服务器端的应用层响应是在延迟了16.34秒后才发出了；

5，对比分析客户端与服务器端的数据交互过程，我们可以得出以下两点结论：

 经过硬件防火墙，应用连接的建立花费了17秒左右的时间；

 这个延时不是硬件防火墙产生的，而是业务系统应用产生的。

3.1.2 分析经过ISA防火墙时的业务交互情况

既然这个延时是业务应用本身产生的，跟硬件防火墙完全无关，那么为什么经过ISA访问的时候，连接测试一切正常呢？

我们还是在业务服务器上捕获客户端与服务器测试应用连接建立交互的数据报文，分析一下经过ISA访问业务系统时的数据交互情况，如下图所示：

其连接正常响应时的数据交互情况大致如下所述：

1，客户端与服务器通过TCP三次握手建立连接；

2，连接建立成功后，客户端立即向服务器端发送了应用层连接请求报文，该报文长度为150字节；

3，服务器在收到这个应用请求之后，在0.006645秒内，响应了客户端的应用层连接请求，这个报文长度为74字节，应用层字段长度为16字节；

4，客户端响应了服务器端的应用层响应报文，向服务器端发送应用层字段长度为16字节的报文确认；

5，应用测试连接成功，客户端主动通过TCP四次握手过程，正常释放TCP连接；

上述过程清晰的展示了客户端在经过ISA访问服务器时，应用连接建立的时间是非常短的，速度非常快。

3.1.3 分析经过硬件防火墙时的业务交互情况

在确认了经过ISA防火墙的业务系统网络交互行为之后，我们再来分析一下经过硬件防火墙时，业务系统的网络交互行为是怎么样的。

1，我们首先在服务器端开启科来网络分析系统捕获服务器交互的所有数据报文；

2，在测试客户端上做业务应用连接测试，当测试客户端弹出连接成功窗口后，停止服务器端的捕包界面；

3，我们通过科来网络分析系统的“数据包”视图，查看这个过程中业务服务器的数据交互情况，具体如下图所示：

交互过程说明：

 服务器端在接收到客户端的应用层请求报文后，没有立即向客户端发送带有应用层数据的连接响应报文，而是先向DNS反向解析客户端地址对应的域名；

 由于防火墙无法访问互联网，因此，硬件防火墙返回ICMP目的网络不可达差错报文；

 服务器端在尝试4次DNS反向解析失败后，发送NBNS名字解析报文；

 NBNS解析成功后，服务器端才向客户端发送应用层连接请求响应数据报文；

4，通过上图的数据交互情况分析，我们可以得出以下两点结论：

 服务器端在收到客户端的应用连接建立请求报文后，没有立即发送应用响应报文，而是首先做反向名字解析，解析不成功，再做NBNS解析；

 17秒的延时，就是服务器4次DNS反向解析失败产生的。

3.2 分析结论

通过上面一系列的分析，我们可以确定，导致该故障产生的核心原因是业务系统程序的处理机制异常导致的。

4 故障解决

我们知道了经过硬件防火墙访问业务系统变慢的原因是因为业务服务器在接收到客户端的应用请求时，需要针对客户端的IP地址做一个反向名字解析，那么我们可以通过在业务服务器的hosts列表中添加客户端的IP对应的主机名，以此来避开服务器的反向DNS名字解析过程，从而解决了业务系统慢的问题。此方法已经现场测试验证有效。

阅读全文>>

标签: 疑难故障防火墙 DNS ISA

评论(7) 引用(0) 浏览(12071)

TCP Fast Open（TFO）

作者：易隐者发布于：2013-1-10 15:22 Thursday 分类：网络分析

【说在之前】：

我在之前的博客文章《非标准TCP三次握手建立连接过程一例》一文中提到了非标准的TCP三次握手行为，今天在微博上看到有人转发有关TCP Fast Open（TFO）的文章，大致看了一下，了解到所谓的TCP Fast Open（TFO）就是利用三次握手的SYN报文来传输应用数据，也就是说，允许SYN报文中包含应用数据。这样做的好处是在客户端与服务器的交互过程中减少一个RTT来提高交互的效率，如此来看，TCP Fast Open（TFO）就是一个最为典型的非标准TCP行为，但是这种非标准的TCP行为由于其特性优势使其将成为国际标准，其具体的交互过程和原理大家可参考下面的文章和相关链接。

【原文链接】：

http://blog.sina.com.cn/s/blog_583f42f101011veh.html

【原文全文】：

Google近日正式公布了TFO的paper，地址：http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/zh-CN/us/pubs/archive/37517.pdf

Google研究发现TCP三次握手是页面延迟时间的重要组成部分，所以他们提出了TFO：在TCP握手期间交换数据，这样可以减少一次RTT。根据测试数据，TFO可以减少15%的HTTP传输延迟，全页面的下载时间平均节省10%，最高可达40%。

目前互联网上页面平均大小为300KB，单个object平均大小及中值大小分别为7.3KB及2.4KB。所以在这种情况下，多一次RTT无疑会造成很大延迟。

在HTTP/1.1中，我们有了keep-alive。但实际应用并不理想，根据Google对一个大型CDN网络的统计，平均每次建连只处理了2.4个请求。

为了证实TCP三次握手是目前页面访问的重要性能瓶颈之一，Google工程师分析了Google的web服务器日志及Chrome浏览器统计数据。

2011年6月，对Google web服务器进行连续7天数十亿次针对80端口的请求分析，包括搜索、Gmail、图片等多个服务。其中第一次建连被称为cold requests，复用连接的请求称为warm requests。

图中描述了在cold requests及all requests中TCP握手时间在整个延迟时间中的占比。在cold requests中，TCP握手时间占延迟时间的8%-28%；即使统计所有的请求，TCP握手时间也占到了延迟时间的5%-7%。

对Chrome浏览器的统计持续了28天，当然仅限于愿意发送统计数据的用户。经过分析，即使打开了keep-alive，仍有33%的请求建立了新连接。主要原因可能为：为了加快下载速度，新版的浏览器对单个域名都会并行打开6-10个连接；而网页设计时也会把元素分配到多个域名上；NAT也可能关闭keep-alive；而手机端为了节省电源，也会尽快关闭空闲连接。

图中对比了三条线，一条为all requests；一条为cold request；而cold req no hsk代表去除了TCP握手时间的cold requests延迟数据。Y轴把所有采样数据按数值分布到各个百分比区间。

对比证明：cold requests基本比all requests慢50%，而TCP握手时间在cold requests延迟时间中往往占比了25%。

下面这幅图清楚的说明了TFO的设计：

1、用户向服务器发送SYN包并请求TFO cookie；

2、服务器根据用户的IP加密生成cookie，随SYN-ACK发给用户；

3、用户缓存住TFO cookie。

再次访问时：

1、用户向服务器发送SYN包并携带TCP cookie，同时请求实体数据；

2、服务器校验cookie。如果合法，向用户发送SYN+ACK，在用户回复ACK之前，便可以向用户传输数据；如果cookie校验失败，则丢弃此TFO请求，视为一次普通SYN，完成正常的三次握手。

因为用户使用DHCP，IP地址会改变；同时也为了防止攻击，服务器端会定期变换cookie。

建立了TFO连接而又没有完成TCP建连的请求在服务器端被称为pending TFO connection，当pending的连接超过上限值，服务器会关闭TFO，后续的请求会按正常的三次握手处理。

而一个带有TFO的SYN请求如果在一段时间内没有收到回应，用户会重新发送一个标准的SYN请求，不带任何其他数据。

在集群环境中，所有服务器会使用相同的key。

目前TFO被植入了Linux 2.6.34内核。

为了验证TFO的作用，Google分别测试了全页面的下载时间及开启TFO对服务器性能的影响。平均来看，页面一般会包含44个元素，分布在7个域名中。同时浏览器会支持并行下载。抽样的测试对象为：亚马逊、纽约时报、华尔街日报和维基百科。可以看到RTT时间越大，TFO的效果越明显。当RTT为200ms时，改善达到了11%-41%。这对移动互联网尤其意义重大。