网络分析 - 蚂蚁网-多维人生，三实而立！

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

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

带有应用层字段的TCP RST报文

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

今天在为一个朋友准备培训材料的时候，在某个客户那边捕获的数据包文件中，无意中发现RST报文中竟然带有应用层字段，如下图所示：

这是一个SSH的TCP连接，一般而言，对端在收到TCP RST报文后，便会立即释放该TCP连接，这个是传输层控制的，即使RST报文中带有应用层字段，传输层也不会将这个应用层字段提交给应用进程。

如此来看，这个TCP RST报文带有应用层字段“ Reset cause: Go away, we're not home ”，似乎也没什么意义。

阅读全文>>

标签: TCP RST reset 应用字段培训 SSH

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

如何跟踪分析数据经过中间设备后的变化以及这些变化给客户端与服务器带来的影响

作者：易隐者发布于：2012-8-20 21:20 Monday 分类：网络分析

中间设备会对经过它的数据报文进行修改、检测、丢弃等处理，这些操作对交互数据的客户端与服务器都会产生相应的影响，这些影响在客户端与服务器端可能会导致不同的外在表现。我们在实际分析定位疑难应用故障时，需要了解清楚中间设备对数据报文做了哪些处理以及这些处理动作对客户端与服务器产生了哪些影响。
我们如何分析中间设备对数据报文的处理动作、报文进出中间设备的差异以及这些差异给客户端服务器带来的影响呢？一般情况下，我们可以按照下面的步骤来进行分析：

1，数据报文在中间设备的进口和出口同时抓包

在数据报文进入中间设备前的位置以及数据报文被中间设备转发后的位置同时抓包。

2，将设备进出口的同一数据流关联起来

       如何将设备进出口的同一数据流关联起来？在中间设备未做NAT的情况下，我们一般根据五元组信息就可以直接关联了，此案例就是如此关联的；在做NAT的情况下，如果仅仅是源地址做了改变而源端口未改变的话，我们就可以利用源端口、目的地址、目的端口和协议类型来进行关联，如《某地矿局网页打开慢故障分析案例》就是利用四元组关联的；如果在做NAT时，数据流的源地址、源端口都变化了，我们还可以通过数据流的应用信息进行关联。
       具体到每个数据包的关联，则主要通过IP标识字段或数据包应用层数据进行关联。
       具体关联的原理请参见《疑难网络故障的分析方法和原理之关联分析法》一文。

3，根据数据交互情况，分别画出数据交互过程图

在我们将中间设备进出口的同一数据流和具体数据包关联起来之后，我们就可以画出数据在中间设备前后的交互过程图示。
这个交互过程，可以自己手动画出来，也可以利用工具自动生成，例如在wireshark中，我们可以使用“flow graph”生成数据交互视图，如下所示：