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

第三方延时

作者:易隐者 发布于:2012-9-14 16:46 Friday 分类:网络分析

       在实际的网络应用中,有一些应用需要第三方服务器的配合或者从第三方服务器调用相关的数据,在这种业务应用交互的过程中,就存在端系统与第三方服务器交互的延时,这种延时我们称之为第三方延时。以我们最常见的互联网WEB访问过程为例,在访问真正的web应用之前,首先要向第三方的DNS服务器请求解析域名,这个解析的过程可能产生较大的延时,从而导致我们打开web页面很慢。下图为一个访问互联网域名的数据交互流图: 

点击查看原图

访问互联网域名的交互数据流图(wireshark)

       在上面的图示中,我们可以看到,客户端与第三方DNS服务器交互花费了0.046秒的时间,也就是产生了0.046秒的第三方延时。

       除了DNS解析之外,实际环境中,还有很多应用可能需要跟第三方服务存在关联,比如某些业务交互前的认证、业务数据通过数据库的存取等。需要结合具体的应用数据交互流量做具体的分析,在此不做进一步的介绍。

阅读全文>>

标签: 延时 第三方延时 DNS 认证延时 数据库延时 应用性能

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

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

关于服务器端发送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) 浏览(14715)

疑难网络故障的分析方法和原理之对比分析法

作者:易隐者 发布于:2012-7-4 12:04 Wednesday 分类:网络分析

       有一些故障,特别是业务应用的故障,客户端与服务器端在进行业务数据流交互时,中间会经过各种链路和中间设备。当客户端反馈业务应用存在故障,我们仅仅在某一个点(客户端、服务器端或者其他中间链路处)进行抓包,是无法真正反映故障真实面貌的,我们需要多点同步抓包,这样才能完整的反馈业务数据流在网络中交互的全部过程。在这个完整交互的过程中,我们通过对比分析,可以发现故障发生的位置和原因。

对比分析法的定义

       对比分析法就是在中间设备两端(数据包的进口、数据包转发口)同时抓包,并对进出口处所抓取到的数据包做相应的对比,从而发现中间设备对相应数据包的处理情况,包括更改、丢弃、转发以及经过中间设备后的延时等。

点击查看原图

对比分析法的原理

      网络中间设备的主要功能是对数据包的转发,当一个目的地址不是中间设备的数据包进入一个中间设备时,它必然会被中间设备转发到其某一个出口。如下图所示:

阅读全文>>

标签: 对比分析法 延时 丢包 中间设备对数据包的更改

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

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