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

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

又遇TCP协议栈异常问题

作者：易隐者发布于：2013-10-29 16:47 Tuesday 分类：案例讨论

大家还记得我以前写的《TCP确认机制异常案例》(链接为：http://www.vants.org/?post=200)吗？今天在一个用户那边再次遇到了一个TCP协议栈异常的问题。

用户反馈的问题现象是业务交互出现异常，难以定位异常出现的原因，我在用户现场分析了异常出现时的报文交互情况，如下图所示：

由F5设备主动向服务器发送SYN连接请求报文，服务器响应SYN/ACK报文，F5发送ACK报文确认后，向服务器连续发送3个大小分别为1514、1514、350大小的应用请求报文，但是1.199秒之后，F5重传了应用请求的第一个报文（该报文序列号为No7，该数据报其实是序号为No4的报文的重传），紧接着，2秒后，看到服务器的SYN/ACK的重传报文（该报文序列号为No8，该报文为No2报文的重传报文），后面数十秒的交互，基本是都是F5对应用请求报文的重传和服务器SYN/ACK报文的重传，在40秒之后，由F5主动发送RST报文释放该TCP连接。

由整个交互的过程，我们可以清晰的看到，服务器不断重传SYN/ACK报文，说明服务器没有正常处理F5的ACK报文（序列号为No3的报文），站在F5的角度，TCP连接已经建立成功，但是站在服务器的角度，却认为TCP连接未建立完成，因此服务器不断重传SYN/ACK报文，为什么服务器在明确收到了F5的三次握手的ACK报文，却没有正确处理呢？而且后续F5重传的应用请求报文（No7、No10、No11、No14、No17）都可以说是对服务器SYN/ACK报文的确认，但是服务器全部忽略了，因此，这基本上可以判断为服务器端系统的TCP协议栈出现异常，导致了应用出现了异常。

阅读全文>>

标签: TCP F5 应用故障 SYN 重传 TCP协议栈应用异常

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

服务器经网关地址映射访问时的注意事项

作者：易隐者发布于：2013-6-20 22:05 Thursday 分类：网络分析

有朋友在用户现场遇到一个故障无法定位，网上找我帮忙，大概情况是某内网用户将一台服务器端口映射出去供互联网访问，内部主机通过互联网地址进行访问测试时，发现无法正常连接。

我让其在服务器区域前端防火墙上抓客户端与服务器交互的报文，如下：

10:33:28.747771 R@eth3 IP 172.16.7.68.8525 > 172.16.2.146.3389: S 3134287530:31
34287530(0) win 58400 <mss 1460,nop,wscale 0,nop,nop,sackOK>
//客户端发起SYN请求
10:33:28.747786 X@eth4 IP 172.16.7.68.8525 > 172.16.2.146.3389: S 3134287530:313
4287530(0) win 58400 <mss 1460,nop,wscale 0,nop,nop,sackOK>
//防火墙内口转发客户端的SYN请求
10:33:28.748165 R@eth4 IP 172.16.2.146.3389 > 172.16.7.68.8525: S 3568427973:356
8427973(0) ack 3134287531 win 16384 <mss 1460,nop,wscale 0,nop,nop,sackOK>
//服务器响应客户端的SYN报文
g10:33:28.748172 X@eth3 IP 172.16.2.146.3389 > 172.16.7.68.8525: S 3568427973:356
8427973(0) ack 3134287531 win 16384 <mss 1460,nop,wscale 0,nop,nop,sackOK>
//防火墙转发服务器响应报文
10:33:28.749519 R@eth3 IP 172.16.7.68.8525 > 172.16.2.146.3389: R 3134287531:313
4287531(0) win 0
10:33:28.749523 X@eth4 IP 172.16.7.68.8525 > 172.16.2.146.3389: R 3134287531:313
4287531(0) win 0
//客户端发送RST报文

客户端发起SYN连接请求，防火墙转发，服务器响应SYN/ACK报文，这个过程都是正常的，但是紧接着却是客户端发送RST报文，异常释放了这个TCP连接。单从这个数据包交互的过程来看，大部分的人都会认为是客户端的问题。

但是其实跟客户端完全无关。我很早以前在天融信做工程师时曾今在用户处遇到过同类型的问题，当时解决完之后曾打算将其作为一个经典案例写下来供大家分享，后来由于时间问题，拖时间长了，原始报文找不到了，只能作罢，今天就这个案例，我来做一个简单的分析和说明，以供大家参考。

我们在用户现场经常会遇到这样的客户需求：

1，用户希望通过通过防火墙等设备的端口映射/地址映射功能实现内网服务器对互联网访问者提供服务的需求；

2，为了使用方便，用户一般都会同时要求内部客户端也可以直接通过服务器映射后的互联网地址进行访问。

第一点需求非常容易实现，在防火墙上做一个常规的地址映射/端口映射，再将服务器对外提供服务的端口放行即可。但是在实现用户第二点需求时，我们需要注意一个关键的问题，那就是客户端与服务器端的报文来回路径不一致问题。

我们先将故障发生时的报文交互过程跟大家一起分析一下，其交互过程大致如下图所示：

       这个交互的过程具体描述如下：
1）    客户端访问经网关设备映射出去的服务器的互联网地址，向其发送SYN报文；
2）    客户端访问的目的地址经网关转换为内网服务器真实地址之后，转发至内网服务器，此时报文的源IP地址是真实的内网地址（另外一种处理情况为出口网关将该报文经NAT后至转发出互联网接口，然后再匹配识别为内网服务器的映射的策略，再次将该报文转发至内网服务器，此时报文的原IP、目的IP地址均发生变化了，此种情况下由于报文原IP地址已经改变为NAT后的互联网地址，因此不在我们的讨论的范畴之内，这个跟网关设备对数据报文处理的流程有关,在此不详细讨论，有兴趣的同学可仔细思考思考。）；
3）    内网服务器在接受到这个报文之后，直接向客户端内网IP发送SYN/ACK报文；
4）    内网客户端接收到服务器的SYN/ACK报文,但是客户端的TCP连接表中并没有与之相应的信息（因为客户端是与服务器映射后的互联网地址发送SYN请求报文的），因此，客户端向服务器发送RST报文。

5）服务器端收到这个RST报文之后，其会将这个TCP连接释放，因此客户端连接服务器失败。

那么，在这种情况下，我们如何解决这个问题呢？

其实，解决的方式就是在网关处增加一条源地址转换策略，将访问服务器的客户端地址转换为一个互联网地址或网关内部接口地址，如此巧妙的让服务器回包给网关（防火墙），从而保证客户端、服务器的报文来回路径一致。

NAT在很多复杂环境下的确能够帮助我们巧妙的解决很多令人头疼的问题，我在博客文章《某公司业务系统经ISA防火墙访问正常而经硬件防火墙访问慢故障分析解决案例》中曾今在文章后面留下一个思考问题，至今无人应答，我也没给出答案，其实答案就是NAT。有兴趣的兄弟自行去查看那篇文章吧，在此我不做展开了，当然NAT也可能会带来一些意想不到的问题，以前遇到过一个案例，等我有空的时候再整理发布吧。

这个用户现场案例，我们通过在防火墙中增加一条源地址转化策略之后，再次以互联网地址访问服务器，正常，数据包交互如下：

10:37:54.637923 R@eth3 IP 172.16.5.253.9182 > 172.16.2.146.3389: S 223750126:
223750126(0) win 58400 <mss 1460,nop,wscale 0,nop,nop,sackOK>
10:37:54.637943 X@eth4 IP 172.16.5.253.9182 > 172.16.2.146.3389: S 223750126:223
750126(0) win 58400 <mss 1460,nop,wscale 0,nop,nop,sackOK>
//客户端发起SYN报文
10:37:54.638373 R@eth4 IP 172.16.2.146.3389 > 172.16.5.253.9182: S 892121112:892
121112(0) ack 223750127 win 16384 <mss 1460,nop,wscale 0,nop,nop,sackOK>
10:37:54.638379 X@eth3 IP 172.16.2.146.3389 > 172.16.5.253.9182: S 892121112:892
121112(0) ack 223750127 win 16384 <mss 1460,nop,wscale 0,nop,nop,sackOK>
//服务器响应SYN报文
10:37:54.639048 R@eth3 IP 172.16.5.253.9182 > 172.16.2.146.3389: . ack 1 win 584
00
10:37:54.639052 X@eth4 IP 172.16.5.253.9182 > 172.16.2.146.3389: . ack 1 win 584
00

//客户端确认，连接建立

这个案例就到这吧，大家自己多去体会。

阅读全文>>

标签: TCP RST SYN 防火墙 NAT 地址转换网关来回路径不一致映射

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

wireshark过滤器使用注意事项

作者：易隐者发布于：2013-4-26 15:23 Friday 分类：网络分析

以前一直认为各个网络分析产品的过滤器工作机制应该都是一样的，今天在协助分析定位一个故障的时候，我使用wireshark进行分析，用HTTP作为过滤条件，想仅查看HTTP交互的报文，其过滤后显示的内容如下图所示：

单看上图的显示内容，我们很容易的认为，这就是纯粹的HTTP交互，但是未看见三次握手连接建立的过程，一开始我心里是有点疑惑，但是并未往心里去，后来在合作伙伴的提醒下，我再尝试使用TCP作为过滤条件，方才看到大量的SYN报文，如下图所示：

实在想不通，难道HTTP的三次握手过程不属于HTTP报文？？？？不知道wireshark在这一块是如何设计和考虑的，总之个人认为这个设计不合常理。我们以后在使用wireshark过滤器的时候稍微注意一下，避免出现误解。

阅读全文>>

标签: TCP wireshark 过滤器 HTTP

评论(2) 引用(0) 浏览(9173)

《某公司QQ掉线分析案例》之我见

作者：易隐者发布于：2013-4-14 17:52 Sunday 分类：案例讨论

前段时间看到CSNA论坛上有一篇QQ掉线故障分析的案例，原文是PDF格式的，我就不转载其全文了，其链接如下： http://www.csna.cn/network-analyst-50520-1-1.html，大家可自行通过上述链接下载查看。

大致看了分析过程之后，觉得其中存在一些疑问，特地找时间针对这个案例做一个大致的分析，以便大家讨论参考。原本准备做相关交互图示的，由于个人时间问题，这次就免了，还望各位见谅。

1， QQ多人同时掉线，大约1秒就自动连上，浏览网页和其他应用没有问题

QQ属于一种终端的应用，一般情况下，局域网内某应用出现同时掉线、缓慢等问题，基本上可以排除是单个终端的问题，因为从这个现象上来看，这是一个全局问题，可能是业务应用本身、业务服务器或者承载业务的网络系统出现了问题。在此故障分析案例中，作者提到QQ同时掉线但是浏览网页和其他应用没有问题。通过这个故障现象的描述，我个人首先可能会想到整个互联网出口是否会出现网络瞬间中断的情况？这是我个人的猜想，因为如果真是互联网出口出现网络瞬间中断，那么HTTP等基于TCP的应用由于TCP的重传机制，在出口网络中断1秒左右的时间内，终端使用者不会有明显的异常感受，而基于UDP等应用，可能会出现掉线等现象，在网络出口恢复正常之后，QQ再次自动上线。这个猜想的原因至少可以很好的解释该案例作者一开始描述的故障现象。

2， QQ掉线是QQ服务器主动RST连接导致的，腾讯给出的解释是由于用户端IP地址出现了变化。

1），QQ大部分情况下应该是使用UDP协议的，少数情况下使用TCP协议。

QQ是一个较为复杂的应用，其为了满足使用者在各种复杂的环境对QQ的正常使用，其会存在多种模式和网络交互行为，大部分情况下，QQ默认会使用UDP协议进行交互，少数情况下会使用TCP甚至TCP的80端口、443端口进行交互，特殊情况下，根据需要和设置，其还可以通过代理的方式进行交互。

正是QQ这种特殊应用工作机制的多样性和复杂性，导致我们在遇到其故障时，给我们的分析定位带来了难度。在该案例中，由于QQ是大规模的出现掉线现象，我们在分析处理时，其实根本搞不清楚不同使用者的QQ到底是工作在何种模式之下，其网络行为特征千差万别，因此，我们很难通过某一台测试机来全面分析验证QQ故障的原因。

在该案例中，测试机的QQ似乎使用的是TCP443端口进行交互的，但其实绝大部分情况下，QQ都是基于UDP协议进行交互的。因此在此案例中，按照我个人较为严谨的分析习惯，测试机的选择非常值得做进一步的商榷。

2），就算这个客户网络中所有使用的QQ都是基于TCP协议的，如果真是如腾讯所说，是由于QQ服务器发现用户IP出现了变化，才向客户端发送RST报文的，那么：

其一，不同的QQ客户端与QQ服务器是单独建立连接的，暂且不论QQ服务器的多样性（不同的QQ客户端很可能会与网络中的N个不同的QQ服务器之间建立交互链接），不同的QQ客户端与QQ服务器之间建立不同的交互连接，那么即使防火墙在做NAT时出现BUG，突然改变了某些已有连接的源IP地址，也应该绝少出现同时改变N个不同QQ客户端与服务器之间已有连接的源IP，换句话说，如果原因真是如该案例作者所说，很难解释QQ同时掉线的现象。

其二，那么我们站在QQ服务器的角度来分析一下此种情况真的发生时，QQ服务器会作何处理？QQ服务器收到源IP地址变化的QQ客户端报文后，QQ服务器会把他作为一个新的TCP连接来处理（因为五元组不一样），而QQ服务器并没有这个TCP连接信息，因此服务器会直接RST该报文，而这种RST报文，其ACK位肯定不会置一的，但是我们看到这个案例中作者的截图如下：

该RST报文ACK位是置一的，因此这个RST报文并不是如作者想象的情况下产生的。

其三，我们再来看另外一张截图：

看此交互截图，QQ服务器已经对客户端的报文作出了确认（序号2230的包），紧接着（0.000045秒后），QQ服务器向客户端发送RST报文（序号 2232的包），这个报文可以肯定在服务器紧接着发出序号2230的包之后发出的，如果按照作者的说法，RST报文至少应该是序号为2231的客户端报文经防火墙源地址转换之后（源IP变化），到达QQ服务器，QQ服务器发现源地址变化，再向客户端发送RST报文，这样整个过程方才合理，但是上面这张截图已经充分说明：事实并非如此。

3，如果真的是防火墙的NAT出现了这种低级的错误和BUG，那么对用户影响最大的应该是HTTP等基于TCP应用。因为很多HTTP应用的动态口令、验证码等都需要通过数个不同的TCP连接与服务器进行交互，一旦出现该案例作者所说的防火墙处理BUG，将导致这些应用出现访问故障。而不会仅仅是无关紧要的QQ应用出现问题。

4，QQ掉线而其他TCP应用正常，很可能是防火墙的UDP会话保持时间过短导致的。

因为很多人挂QQ并不一直与好友聊天。而一般情况下，防火墙等为节约设备资源，会将UDP的会话超时时间设置为一个较短的数值，如60秒，那么如果用户在这个超时时间内无任何数据交互的话，防火墙会将这个UDP会话从防火墙连接表中删除，当QQ客户端再次尝试与QQ服务器交互时，其发送的QQ状态更新报文就会被防火墙丢弃，导致QQ客户端掉线。QQ掉线后，客户端会再次发起新的连接，此时防火墙将其作为一个新建的UDP连接进行处理，QQ因此再次成功上线。当然这个很难解释QQ同时掉线的现象。

另外一种情况是，如果防火墙的UDP连接表出现异常，防火墙突然清空其UDP连接表，也可能会导致该案例中故障现象的产生。

5，在NAT POOL情况下，NAT设备会根据不同的算法（基于源IP的、基于连接的等）实现NAT POOL的地址复用，大部分算法应该都是基于源IP等计算的，如果是基于数据包、连接等进行计算，则很可能会导致各种问题的产生，我以前有一个非常经典的案例——《移动无线VPN客户端隧道建立故障分析》，下次我发布到我的博客，大家可去参考。

简单总结：

防火墙在NATPOOL情况下，变化地址是正常的，关键看防火墙的NAT算法。QQ掉线应该跟这个无关，案例中分析来自于QQ服务器的RST报文跟NAT后源地址变化无关。

阅读全文>>

标签: TCP RST 五元组重传机制防火墙 BUG NAT QQ掉线

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

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%。这对移动互联网尤其意义重大。