欢迎关注: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) 浏览(14749)

带有应用层字段的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) 浏览(9816)

访问搜狐163时主页变为2008年某日主页面故障分析案例

作者：易隐者 发布于：2012-8-13 22:26 Monday 分类：网络分析

1 故障环境

        故障环境的拓扑结构示意图如下：
 

点击查看原图


        防火墙做NAT通过电信接入线路访问互联网，核心交换机上接入的设备和线路比较多，内部网络规模比较大。

2 故障现象

       故障现象主要体现在以下几个方面：
1，用户在内网访问搜狐和163主页时，页面变为2008年某日的主页面，所有连接均为2008年的新闻连接，如下图所示： 

点击查看原图


其他网站页面访问均正常。
2，使用笔记本配置为公网地址直接访问搜狐和163正常；
3，在防火墙的一个空闲端口设置地址，通过防火墙NAT地址转换后访问搜狐163主页正常；

       此故障已经持续了数周。

阅读全文>>

标签: 端口镜像 交换机 疑难故障 TCP 天融信 RST reset HTTP会话劫持 会话劫持 TTL

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

[转]F5负载均衡环境下某应用故障分析案例

作者：易隐者 发布于：2012-7-18 13:45 Wednesday 分类：案例讨论

       本文来自互联网，非我原创，原文章名为《高级TCP/IP网络排错》，该案例出自其第三节：用OmniPeek解决网络中的难题。

       如该案例作者看到我的转载请跟我联系，可以做个朋友，切磋一下技术问题，如果哪位网友知道该案例的原作者，也烦请留言告知。

【我的点评】：

1，充分运用了中间设备自带的抓包功能（对中间设备自带抓包功能感兴趣的兄弟，请参阅我的文章《常见系统和网关设备自带抓包功能介绍及操作指南》），提高了分析效率；

2，整个过程使用对比分析法（参见我的文章《疑难网络故障的分析方法和原理之对比分析法》），发现进出F5报文的差异，快速界定异常问题产生的原因是F5、客户端还是服务器；

3，在做数据包分析之前，确定了业务报文交互路径，明确可能的故障点，为下一步的排查提供了基础，但是从作者给的拓扑结构上看，出来F5之外，这个数据路径应该还会经过那台旁接的防火墙；

4，“F5日志中报端口无法到达”，此问题不太像是指物理端口不可达，个人感觉是指UDP端口不可达的可能性更大一些；

阅读全文>>

标签: 负载均衡 F5 omnipeek RST 应用故障 端口不可达

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

TCP异常终止（reset报文）

作者：易隐者 发布于：2012-4-25 21:42 Wednesday 分类：网络分析

TCP异常终止（reset报文）

TCP的异常终止是相对于正常释放TCP连接的过程而言的，我们都知道，TCP连接的建立是通过三次握手完成的，而TCP正常释放连接是通过四次挥手来完成，但是有些情况下，TCP在交互的过程中会出现一些意想不到的情况，导致TCP无法按照正常的四次挥手来释放连接，如果此时不通过其他的方式来释放TCP连接的话，这个TCP连接将会一直存在，占用系统的部分资源。在这种情况下，我们就需要有一种能够释放TCP连接的机制，这种机制就是TCP的reset报文。reset报文是指TCP报头的标志字段中的reset位置一的报文，如下图所示：

点击查看原图

阅读全文>>

标签: TCP异常终止 RST reset

评论(15) 引用(0) 浏览(59151)

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