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

应用响应时间（ART）

作者：易隐者 发布于：2012-9-13 18:38 Thursday 分类：网络分析

       在实际的业务应用操作中，客户端向服务器的操作主要分为两类，一类为客户端向服务器上传数据，如HTTP应用中的“post”操作，另一类为客户端从服务器取数据，如HTTP应用中的“get”操作。应用程序对这两个操作的处理机制不同，因此有必要把应用响应时间按照客户端的这两类操作进行划分，下面分别针对服务器端的这两种响应时间进行阐述。

“get ”操作应用响应时间

      “Get”操作主要是指客户端向服务器端发送取数据的请求。应用程序对“Get”操作的响应时间主要是指服务器收到get请求数据包至服务器响应第一个带有应用层数据的数据包的时间间隔。其响应时间的计算如下图所示： 

点击查看原图

Get操作应用响应时间计算示意图（一）

       应用程序在处理客户端请求的时候会消耗一定的时间，并不一定能够及时响应请求的数据，为了不让客户端等待过长的时间（时间过长，很可能导致客户端重传数据），服务器很可能首先对客户端的TCP数据段进行响应（Delay ACK）。在上面的图示中，第二个包是TCP层的响应，其应用层的数据的长度len=0，第三个包包含有应用层数据，其数据长度len=n，因此，该应用响应时间就是T3-T1。而下图中，应用程序很快的响应了客户端的请求，第二个包中就已经包含有应用层数据，其长度为len=n，其应用响应时间的计算就是从第二个数据包开始，为T2-T1。 

点击查看原图

Get操作应用响应时间计算示意图（二）

        我们再看一下实际应用中的get操作应用响应时间的计算。下图为web应用中某“get”操作的数据交互过程： 

点击查看原图

 web应用中GET 操作的交互过程

       在上图中，我们可以看到，当客户端向服务器发送取数据的get请求后，服务器的传输层首先针对客户端的TCP数据段进行了响应，其应用层数据长度为0，接下来第三个数据报是服务器应用程序对客户端get请求的响应，其包含应用数据。在这个过程中，“get”操作应用响应时间就是第三个数据包与第一个数据包的时间间隔，在该例子中为0.08149秒。

“Post”操作应用响应时间

       “post”操作主要是指客户端向服务器上传数据的操作。“Post”操作应用响应时间主要指服务器端接收到客户的post操作数据包与服务端处理完这些数据后对客户端做出相应响应的时间。关于这种应用响应时间计算的方法请参见本博客《关于client push操作应用响应时间的计算方式的讨论》一文。这篇文章较为详细的描述了客户端向服务器递交数据时的服务器应用响应时间测量的方法。

       在实际的应用中，存在两种常见的应用场景，一种是服务器端在收到客户端的数据，应用进程处理完毕后，需要向客户端发送响应数据；另外一种情况是服务器端接收并处理来自客户端的数据，但是应用进程并不会发送响应数据给客户端。下面我们分别针对这两种类型的应用进行描述。

1，有应用层响应数据的

       当客户端向服务器发送“post”操作数据后，应用层如果有应用数据的响应，那么计算应用响应时间的方法与计算“get”操作应用响应时间的方法一致。就是指服务器收到post请求数据包至服务器响应第一个带有应用层数据的数据包的时间间隔。下图展现的就是一个针对客户端的 “post”操作，应用进程产生应用层响应数据的交互过程：

点击查看原图

有应用层响应数据的“post”操作交互过程

       在这个“post”操作数据交互过程中，我们可以分析出应用响应时间为12.847148秒。

2，无应用层响应数据

       在客户端向服务器发送数据时，如果服务器端应用进程没有应用数据响应，那么服务端仅仅只在TCP层面响应客户端数据的ACK，如下图所示的应用层数据交互的过程： 

点击查看原图

无应用响应数据的“post”操作数据交互

       既然无应用数据响应，那么就说明站在网络数据交互的角度，无法测量应用程序的响应时间，即使测量了，也无法真正反映应用程序的响应时间，在实际应用中，我们就没有测量的必要了。

阅读全文>>

标签: 响应时间 应用响应时间 ART get client push delay ack POST

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

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

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

关于服务器端发送FIN报文之前的数秒等待时间行为的分析

作者：易隐者 发布于：2012-8-21 22:40 Tuesday 分类：网络分析

       就这个问题，我来简单分析一下基于TCP的应用，正常释放TCP连接的行为：

       在实际环境下，我们可以抓到各种FIN正常释放连接的报文，大部分交互完毕应用数据之后立即发送FIN报文释放连接，如下图所示：

点击查看原图

       有些交互完毕应用数据后，服务器端立即发送FIN报文，客户端在确认FIN报文之后，发送RST报文，释放TCP连接，这样做主要视为了提高交互的效率，省去了服务器确认客户端FIN报文和客户端等等服务器端确认的过程和时间，如下图所示：

点击查看原图

       有些则如上面兄弟遇到的那个情况，双方在建立TCP连接后，进行应用数据的交互，应用数据交互完毕之后，服务器端并不是立即发送FIN报文，正常释放该TCP连接，而是等待一段时间，看客户端是否有新的应用数据需要交互，如果有，则不需要再建立一个新的TCP连接，直接使用已有连接进行交互，如果超出时间客户端无应用数据交互，则服务器端主动发送FIN报文，正常释放该TCP连接。

       这个过程，是由应用程序控制的，跟操作系统无关。另这种机制一般情况下能够提高应用交互的效率，这个服务器端等待客户端是否有应用数据交互的时间不能算作是应用响应时间。

阅读全文>>

标签: TCP RST 延时 响应时间 应用响应时间 FIN 正常释放 TCP行为 长连接 短连接

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

关于“client push”应用响应时间测量方法的讨论

作者：易隐者 发布于：2012-4-28 9:27 Saturday 分类：网络分析

       在我们分析业务系统故障时，经常会涉及到应用响应时间的测量和分析，有很多网络分析产品都有对应用响应时间的统计测量，比如siniffer，netscout等，不同的产品对应用响应时间测量的方法应用有所差别，前段时间正好看到netscout关于应用响应时间测量的白皮书，里面提到了clinet pull与client push两种常见的基于TCP的应用响应时间测量方法，我在这篇文档中，针对netscout的client push的应用响应时间测量的方法提出了一些改进的建议，这个建议是拿来让大家讨论的，暂且不管这个改进建议在实际统计测量中的可行性，如果能够通过我的这篇文档，能够让大家对应用响应时间测量的方法有跟深入的认识，那么，我的目的就达到了。

阅读全文>>

标签: Netscout 响应时间 应用响应时间 ART get push client push

评论(1) 引用(0) 浏览(28026)

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