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

经受时延的确认（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) 浏览(114991)

TCP MSS与PMTUD

作者：易隐者 发布于：2012-9-6 19:16 Thursday 分类：网络分析

 

       一旦DF位置一，将不允许中间设备对该报文进行分片，那么在遇到IP报文长度超过中间设备转发接口的MTU值时，该IP报文将会被中间设备丢弃。在丢弃之后，中间设备会向发送方发送ICMP差错报文。
为了简单直观的展示这个交互的过程，我做了下面这个图示： 

点击查看原图


       我找了一个实际环境下捕获的ICMP需要分片但DF位置一的差错报文，下图为其解码格式： 

点击查看原图


       我们可以看到其差错类型为3，代码为4，并且告知了下一跳的MTU值为1478。在ICMP差错报文里封装导致此差错的原始IP报文的报头（包含IP报头和四层报头）。

       一旦出现这种因DF位置一而引起丢包，如果客户端无法正常处理的话，将会导致业务应用出现异常，外在表现为页面无法打开、页面打开不全、某些大文件无法传输等等，这将严重影响业务的正常运行。
那么客户端如何处理这种状况呢？
TCP主要通过两种方式来应对：
1， 协商MSS，在交互之前避免分片的产生
2， 路径MTU发现（PMTUD）

TCP MSS

       TCP在三次握手建立连接过程中，会在SYN报文中使用MSS（Maximum Segment Size）选项功能，协商交互双方能够接收的最大段长MSS值。
       MSS是传输层TCP协议范畴内的概念，顾名思义，其标识TCP能够承载的最大的应用数据段长度，因此，MSS=MTU-20字节TCP报头-20字节IP报头，那么在以太网环境下，MSS值一般就是1500-20-20=1460字节。
客户端与服务器端分别根据自己发包接口的MTU值计算出相应MSS值，并通过SYN报文告知对方，我们还是通过一个实际环境中捕获的数据报文来看一下MSS协商的过程：

点击查看原图

       这是整个报文交互过程的截图，我们再来看一下客户端的报文详细解码： 

点击查看原图

       上图为客户端的SYN报文，在其TCP选项字段，我们可以看到其通告的MSS值为1460；我们在看看服务器端的SYN/ACK报文解码： 

点击查看原图


       上图为服务器端给客户端回应的SYN/ACK报文，查看其TCP选项字段，我们可以发现其通告的MSS值为1440。

       交互双方会以双方通告的MSS值中取最小值作为发送报文的最大段长。在此TCP连接后续的交互过程中，我们可以清楚的看到服务器端向客户端发送的报文中，TCP的最大段长度都是1440字节，如下图解码所示：

点击查看原图

       通过在TCP连接之初，协商MSS值巧妙的解决了避免端系统分片的问题，但是在复杂的实际网络环境下，影响到IP报文分片的并不仅仅是发送方和接收方，还有路由器、防火墙等中间系统，假设在下图的网络环境下： 

点击查看原图

       中间路径上的MTU问题，端系统并不知道，因此需要一个告知的机制，这个机制就是路径MTU发现（PMTUD： Path MTU Discovery ）！

PMTUD

       说起PMTUD，我们必须在此回到上面讲到的ICMP需要分片但DF位置一差错报文，还记得那个ICMP差错报文中有一个字段是告知下一跳的MTU值的吗？PMTUD正是利用ICMP需要分片但DF位置一差错报文的这一特性来实现的。
       发送方在接收到该差错报文后，会根据该报文给出的下一跳的MTU值计算适合传输的最大段长度，从而在后续的发送报文过程中，避免在中间路径被分片的情况产生。
       这在端系统主要是通过在路由表里临时添加目的主机路由并将ICMP差错报文告知的下一跳MTU值跟该主机路由关联起来来实现。
       PMTUD的确是个非常不错的机制，但是在复杂的实际网络环境中，有时候会失效，因为为了安全起见，有些网络管理员会在路由器、防火墙等中间设备上设置过滤ICMP报文的安全策略，这将导致ICMP差错报文被这些中间设备丢弃，无法达到发送方，从而引起PMTUD的失效，网上有个宫一鸣前辈共享的案例——《错误的网络访问控制策略导致PMTUD 实现故障一例》，该案例正是说明这种情况绝好的例子，大家可以自行百度此文档学习参考。

       值得一提的是PMTUD仅TCP支持，UDP并不支持PMTUD。

       由于PMTUD可能存在ICMP差错报文被过滤的情况，很多中间设备的接口支持adjust tcp mss设置功能，思科路由器一般是在接口模式下使用命令“ip tcp adjust-mss 1400 ”来做设置，其他的品牌产品的相关设置大家可在实际工作环境下自查相关品牌和产品的使用手册。

        这个功能主要是通过由中间设备修改经过其转发的TCP SYN报文中的MSS值，让中间设备参与进TCP 三次握手时SYN报文的MSS协商来避免分片。

       需要注意的是，该功能不像MTU值，只针对出接口，此功能一旦开启，其将针对该接口的收发双向有效。
我做一个简化环境下的工作过程图示以便于大家理解其工作过程：

点击查看原图

阅读全文>>

标签: TCP icmp差错 分片 SYN TCP选项 UDP MTU ICMP PMTUD MSS

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

某单位经过CA认证的业务应用访问缓慢故障分析案例

作者：易隐者 发布于：2012-9-3 9:47 Monday 分类：网络分析

【写在之前】：

1，此案例为业务应用系统客户端程序BUG问题导致的故障；

2，此案例可作为业务系统分析评估的应用场景，为业务系统正式上线前测试阶段通过网络分析技术手段发现业务系统稳定性问题的案例；

3，此案例中涉及到的知识点，请大家参考本博的《TCP重传》一文；

【我的案例】：

故障环境
      故障网络结构如下图所示： 

点击查看原图


       该单位的网络划分有办公区域和服务器区域，办公区域的机器经过防火墙的地址转换，访问服务器区域的相关服务器。

业务应用访问的流程

       业务应用是基于B/S架构的，客户端通过IE浏览器对服务器进行访问；进行访问时，在IE浏览器中输入认证服务器的地址，经过CA认证服务器认证成功后，在通过CA认证服务器的代理，访问业务应用服务器。

故障现象

1，客户端在访问应用服务器时，有时页面打开的速度非常的慢，要等好几分钟才能完全打开页面，打开页面后进行站内访问时，速度也很慢；
2，直接将客户端接在服务器区，访问正常；
3，其他的业务应用全部正常；
4，业务系统开发商与网络集成商均否认是自己维护的系统导致故障了出现。

故障分析

1 分析思路

       通过故障现象，我们可以明确这是单一的业务应用故障，问题应该跟该业务的数据交互有关，因此，我们应该将分析的重点放在该业务交互的详细过程。
       另外，由于这个故障并不是一直出现，因此，我们需要在故障出现时，捕获其数据报文的详细交互过程，从而发现故障原因所在。

2 分析过程

1， 在测试主机上开启网络分析工具，并在故障现象出现时，捕获其交互的数据报文。
2，分析故障时数据报文详细的交互过程，如下图所示： 

点击查看原图

        通过上图交互过程的分析，我们发现，第一个数据报文是客户端向服务器发送的SYN请求报文，第二个报文是服务器对客户端SYN报文的响应，其SYN标志和ACK标志位都置1了，下面5个报文都是第二个报文的重传。在这里我们没有看到正常的TCP三次握手建立连接的过程，客户端并没有响应来自服务器的SYN报文，服务器因此不断地重传SYN报文，正是这个原因导致了客户端与服务器业务交互异常缓慢。
3，由于该报文是在客户端直接捕获的，因此我们可以确定是客户端未响应服务器的SYN报文，而不是中间设备丢弃了客户端对服务器SYN报文的响应报文。那么为什么客户端不响应服务器的SYN报文呢？
4，将上述分析情况与业务系统开发商沟通之后，开发商才确认是自己的业务客户端出现了问题。 

3 分析结论

       通过上面的分析，可以得出该故障是由客户端本身不响应服务器的SYN报文导致的。

故障解决

       通过我们的分析定位，找到故障的源头是客户端，通过与CA认证程序提供厂商沟通后，发现程序中有一段代码编写存在一些问题，当客户端与服务端的IP地址不在同一网段时，有时会出现客户端不响应服务器SYN报文的情况，在业务开发商优化客户端的程序代码后，该故障得到解决。

阅读全文>>

标签: 疑难故障 TCP TCP重传 SYN 重传 SYN重传 CA BUG

评论(5) 引用(0) 浏览(11487)

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

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

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