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

天融信防火墙报文处理流程

作者:易隐者 发布于:2012-11-21 13:12 Wednesday 分类:参考资料

       天融信作为国内知名的防火墙品牌,其拥有巨大的用户群体,因此天融信防火墙也是在实际工作环境中最为常见的防火墙之一,天融信防火墙的报文处理流程如下图所示:

点击查看原图

阅读全文>>

标签: 天融信 防火墙 报文处理流程

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

TCP/IP 数据包处理路径

作者:易隐者 发布于:2012-11-13 16:09 Tuesday 分类:参考资料

简介

       随着 Microsoft® Windows® XP Service Pack 2 和 Windows Server™ 2003 Service Pack 1 新增了 Windows 防火墙,以及 Internet 协议安全 (IPsec) 在公司 Intranet 中日益广泛的应用,信息技术 (IT) 专业人士需要了解 TCP/IP 协议及 Windows 中的相关组件处理单播 Internet 协议 (IP) 数据包的具体方式。有关 IP 数据包处理路径的详细知识,可以让您更轻松地掌握配置数据包处理和筛选组件,以及进行相关疑难解答的具体方法。

        本文所介绍的内容如下:

• 用于 IP 版本 4 的 TCP/IP 协议的基本体系结构以及其它一些用于处理数据包的组件。
• 基于 Windows 的计算机所发送、接收和转发的单播流量的数据包处理路径。

         注意:为了简要起见,本文将不讨论多播、广播、分段或隧道数据包。

用于数据包处理的 TCP/IP 体系结构

         下图为 TCP/IP 协议驱动程序 (Tcpip.sys) 及其用于在 Windows XP Service Pack 2 和 Windows Server 2003 Service Pack 1 中处理 IP 数据包的相关组件的简要示意图。 

点击查看原图

         下列组件可处理 IP 数据包:

• IP 转发 为发送或转发的数据包确定下一跃点接口和地址。
• TCP/IP 筛选 允许按 IP 协议、TCP 端口或 UDP 端口,指定可为传入的本地主机流量(发往主机的数据包)所接受的流量类型。可以在“网络连接”文件夹中,从 Internet 协议 (TCP/IP) 组件高级属性的“选项”选项卡,配置 TCP/IP 筛选。
• 筛选器挂钩驱动程序 该 Windows 组件可使用筛选器挂钩 API,筛选传入和传出的 IP 数据包。在运行 Windows Server 2003 的计算机上,筛选器挂钩驱动程序为 Ipfltdrv.sys,属于“路由和远程访问”的一个组件。启用后,“路由和远程访问”允许用户使用路由和远程访问管理单元,对每个接口配置单独的入站和出站 IP 数据包筛选器。Ipfltdrv.sys 会同时检查本地主机和中转 IP 流量(不发往主机的数据包)。
• 防火墙挂钩驱动程序 该 Windows 组件可使用防火墙挂钩 API,检查传入和传出的数据包。在运行 Windows XP 的计算机上,防火墙挂钩驱动程序为 Ipnat.sys,由 Internet 连接共享和 Windows 防火墙双方共享。Internet 连接共享是一种基础网络地址转换器 (NAT)。Windows 防火墙是一种基于主机的状态防火墙。Ipnat.sys 可同时检查本地主机和中转 IP 流量。在运行 Windows Server 2003 的计算机上,Ipnat.sys 由 Internet 连接共享、Windows 防火墙和路由和远程访问的 NAT/基本防火墙组件三方共享。如果启用了路由和远程访问的 NAT/基本防火墙组件,就不能再启用 Windows 防火墙或 Internet 连接共享了。
• IPsec IPsec 组件——Ipsec.sys——是 IPsec 在 Windows 中的实现,可对 IP 流量提供加密保护。Ipsec.sys 可同时检查本地主机和中转 IP 流量,并可允许、阻止或保护流量。

数据包处理路径

       下面几节介绍了针对以下流量的具体的数据包处理路径:
• 源流量 由基于 Windows 的发送主机发起。
• 目标流量 达到最终的基于 Windows 的目标主机。
• 中转流量 由基于 Windows 的 IP 路由器转发。
       这里只讨论 Windows Server 2003 或 Windows XP 所附带的组件,不涉及 Windows 套接字分层服务提供程序或 NDIS 中间微型端口驱动程序。

源流量

        源流量的数据包处理路径如下图所示。 

点击查看原图

1. IP 数据包形成后,Tcpip.sys 就会将其传递给防火墙挂钩驱动程序 (Ipnat.sys) 进行处理。

        Windows 防火墙检查该流量是否属于所要阻止的特定的 Internet 控制消息协议 (ICMP) 消息类型。如果 ICMP 消息被阻止,Windows 防火墙就将丢弃该数据包。
       Windows 防火墙检查该流量是否属于点对点隧道协议 (PPTP) 隧道维护流量。如果属于的话,Windows 防火墙将分析该流量,确定用于识别特定 PPTP 隧道的通用路由封装 (GRE) 调用 ID,从而允许 PPTP 隧道的基于 GRE 的传入流量。
       如果需要,Windows 防火墙会在例外列表中添加一个动态项目,来允许响应流量。
       处理完后,Ipnat.sys 会将该 IP 数据包传回给 Tcpip.sys,而后者会使用 IP 转发组件,确定下一跃点 IP 地址和接口。有关详细信息,请参阅认识 IP 路由表。

2. Tcpip.sys 将数据包传递给筛选器挂钩驱动程序 (Ipfltdrv.sys) 进行处理。

       Ipfltdrv.sys 根据下一跃点接口,将该数据包与已配置的出站 IP 数据包筛选器进行对比。
       若出站 IP 数据包筛选器不允许该数据包,Ipfltdrv.sys 就会在不给出提示的情况下,丢弃该数据包。若出站 IP 数据包筛选器允许该数据包,Ipfltdrv.sys 就会将该数据包传回给 Tcpip.sys。

3. Tcpip.sys 将该数据包传递给 Ipsec.sys 进行处理。

       Ipsec.sys 根据 IPsec 筛选器组,决定是否允许、阻止或保护该数据包。若允许的话,Ipsec.sys 会在不修改该数据包的情况下,将其发回给 Tcpip.sys。若阻止的话,Ipsec.sys 会在不发出任何提示的情况下,丢弃该数据包。若要进行保护的话,Ipsec.sys 会在将数据包传回给 Tcpip.sys 之前,对其添加适当的 IPsec保护。Tcpip.sys 随后会通过下一跃点接口,将该数据包发送到下一跃点 IP 地址。

目标流量

       目标流量的数据包处理路径如下图所示。 

点击查看原图

1. 接收到 IP 数据包后,Tcpip.sys 会将其传递给 Ipsec.sys 进行处理。

       若数据包带有 IPsec 保护(指示验证头 [AH] 或封装式安全措施负载 [ESP] 的 IP 协议字段值),将对其进行处理并加以移除。若对计算机应用了“Windows 防火墙:允许已验证的 IPSec 跳过”组策略设置,Ipsec.sys 将设置一个与该数据包相关联的 IPsec Bypass 标记。Ipsec.sys 将结果数据包传回给 Tcpip.sys。
若数据包不带有 IPsec 保护,Ipsec.sys 就会根据 IPsec 筛选器组,决定是否允许、阻止或保护该数据包。若允许的话,Ipsec.sys 会在不修改该数据包的情况下,将其发回给 Tcpip.sys。若数据包被阻止或需要保护,Ipsec.sys 就会在不发出任何提示的情况下,丢弃该数据包。

2. Tcpip.sys 将该数据包传递给 Ipfltdrv.sys 进行处理。

       Ipfltdrv.sys 根据接收数据包的接口,将该数据包与已配置的入站 IP 数据包筛选器进行对比。若入站 IP 数据包筛选器不允许该数据包,Ipfltdrv.sys 就会在不给出提示的情况下,丢弃该数据包。 若入站 IP 数据包筛选器允许该数据包,Ipfltdrv.sys 就会将该数据包传回给 Tcpip.sys。

3. Tcpip.sys 将该数据包传递给 Ipnat.sys 进行处理。

       若启用了 Internet 连接共享或 NAT/基本防火墙,并且接收数据包的接口是连接到 Internet 的公共接口,Ipnat.sys 就会将该数据包与其 NAT 转换表进行对比。若找到了匹配项,就将转换该 IP 数据包,并将结果数据包视为源流量。
       Windows 防火墙检查与该数据包相关联的 IPsec Bypass 标记。若设置了 IPsec Bypass 标记,Windows 防火墙就会将该数据包传回给 Tcpip.sys。
       若未设置 IPsec Bypass 标记,Windows 防火墙就会将该数据包与其例外列表进行对比。若数据包与某个例外匹配,Ipnat.sys 就会将该 IP 数据包传回给 Tcpip.sys。若不匹配,Ipnat.sys 会在不发出提示的情况下,丢弃该 IP 数据包。

4. Tcpip.sys 将 IP 数据包与已配置的 TCP/IP 筛选允许的那组数据包进行对比。

       若 TCP/IP 筛选不允许该数据包,Tcpip.sys 将在不发出提示的情况下,丢弃该数据包。若 TCP/IP 筛选允许该数据包,Tcpip.sys 将继续对其进行处理,并最终将该数据包有效负载传递给 TCP、UDP 或其它上层协议。

中转流量

       中转流量的前半部分路径如下图所示。 

点击查看原图

1. 接收到 IP 数据包后,Tcpip.sys 会将其传递给 Ipfltdrv.sys 进行处理。

       Ipfltdrv.sys 根据接收 IP 数据包的接口,将该数据包与已配置的入站 IP 数据包筛选器进行对比。
若入站 IP 数据包筛选器不允许该数据包,Ipfltdrv.sys 就会在不给出提示的情况下,丢弃该 IP 数据包。若入站 IP 数据包筛选器允许该数据包,Ipfltdrv.sys 就会将该 IP 数据包传回给 Tcpip.sys。Tcpip.sys 将数据包传递给 IP 转发组件,由后者确定用于转发该数据包的下一跃点接口和地址。

       中转流量的后半部分路径如下图所示。 

点击查看原图

2. Tcpip.sys 将该数据包传递给 Ipnat.sys。

       若启用了 Internet 连接共享或 NAT/基本防火墙,并且接收数据包的接口是连接到 Intranet 的专用接口,Ipnat.sys 就会将该数据包与其 NAT 转换表进行对比。若 Internet 连接共享或 NAT/基本防火墙找到了匹配项,将转换该 IP 数据包,并将结果数据包当作源流量。若 Internet 连接共享或 NAT/基本防火墙未找到匹配项,将创建一个新的 NAT 转换表项,转换 IP 数据包,并将结果数据包当作源流量。若未启用 Internet 连接共享,Ipnat.sys 就会将 IP 数据包传回给 Tcpip.sys。

3. Tcpip.sys 将该数据包传递给 Ipfltdrv.sys。

       Ipfltdrv.sys 根据下一跃点接口,将该数据包与已配置的出站 IP 数据包筛选器进行对比。若出站 IP 数据包筛选器不允许该数据包,Ipfltdrv.sys 就会在不给出提示的情况下,丢弃该 IP 数据包。若出站 IP 数据包筛选器允许该数据包,Ipfltdrv.sys 就会将该 IP 数据包传回给 Tcpip.sys。

4. Tcpip.sys 将该数据包传递给 Ipsec.sys 进行处理。

       Ipsec.sys 根据 IPsec 筛选器组,决定是否允许、阻止或保护该数据包。若允许的话,Ipsec.sys 会在不修改该数据包的情况下,将其发回给 Tcpip.sys。 若阻止的话,Ipsec.sys 会在不发出任何提示的情况下,丢弃该数据包。若要进行保护的话,Ipsec.sys 会在将数据包传回给 Tcpip.sys 之前,对其添加适当的 IPsec保护。
       Tcpip.sys 随后会通过下一跃点接口,将该 IP 数据包发送到下一跃点地址。

       对于运行 Windows XP SP2 或 Windows Server 2003 SP1 并采取常规配置的客户端或服务器计算机(不充当路由器或 NAT,并禁用了 TCP/IP 筛选),源流量的数据包处理路径涉及以下组件:
1. Windows 防火墙
2. IPsec
       对于上述采用常规配置的基于 Windows 的计算机来说,目标流量的数据包处理路径涉及以下组件:
1. IPsec
2. Windows 防火墙

       若使用了 IPsec,并启用了 Windows 防火墙,那么可能需要配置这两个组件,以允许想要的流量。譬如,要是您正在配置一台 Web 服务器,并使用 IPsec 保护发往该服务器的 Web 流量,就必须配置以下项目:
1. 一个 IPsec 规则(要求发往和发自该服务器的 IP 地址和 TCP 端口 80 的安全性)。
2. 一个 TCP 端口 80 的 Windows 防火墙例外。
       该 IPsec 规则可确保发往 Web 服务器服务的流量受到保护。该 Windows 防火墙例外可确保 Windows 防火墙不会丢弃未经请求的传入请求,来通过 TCP 端口 80 创建到 Web 服务器的连接。由于 IPsec 和 Windows 防火墙都作为单独的组件处理 IP 数据包,因此必须同时配置这两个组件。要是不想让 Windows 防火墙处理受 IPsec 保护的数据包,请配置“Windows 防火墙:允许已验证的 IPSec 跳过”组策略设置。有关详细信息,请参阅对 Microsoft Windows XP Service Pack 2 部署 Windows 防火墙设置。

阅读全文>>

标签: TCP 防火墙 安全 IPS UDP NAT TCP/IP API IPsec Windows 数据包 数据包处理路径 路由转发 IP转发

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

异常流量分析方法——发现-定位-管控

作者:易隐者 发布于:2012-11-8 21:50 Thursday 分类:网络分析

       我们在实际工作环境中遇到各种影响网络系统和业务正常运行的异常流量的概率远远高于遇到疑难故障的概率,在我的博客里已经将疑难杂症的分析方法和思路做了非常深入的阐述(大家可参考《疑难故障分析常规流程和思路》、《疑难网络故障的分析方法和原理之关联分析法》、《疑难网络故障的分析方法和原理之对比分析法》等文),并且我为此撰写了大量的疑难故障的实际分析和解决的案例,我在《疑难故障分析常规流程和思路》一文中,仅仅简单的提到“全局捕包确认异常类型和源头”等寥寥数字,这并不是我疏忽,而是当这些异常流量足以对网络和业务应用产生较为严重影响的时候,其在流量的特性上往往具有较为明显的特征,因此站在网络分析技术的角度,我认为针对这些异常流量的分析是一件非常简单的事情,只要通过简单几个分析步骤和流程,即可快速的定位。
       但是这些看似简单的方法和流程,对于一些不了解网络分析技术或网络分析初学者来说,却是一件令人头疼的事情,我曾在工作中数次遇到朋友问我:为什么不把这些最常遇到的异常流量问题的分析方法和思路,简单明了的写出来,以助初学者快速入手呢?
       我想的确有道理,把这些东西写出来,让更多的朋友能够利用我写的分析方法和思路解决实际工作过程中遇到的问题,岂不是一件快事?但是考虑到高彦刚老师在其《实用网络流量分析技术》一书中,已经对蠕虫、P2P、环路、ARP病毒等常见异常流量的分析案例做了专业的介绍,在此我将不再将高老师已经做过的、非常优秀的事情再做一遍,我主要将异常流量分析的方法和思路总结为一个简单易懂的、通用的分析流程。据此流程,你可以快速的分析定位大部分的异常流量。
       该方法并不局限于任何一款具体的网络分析产品和工具,只要你熟练掌握某一种网络分析工具(wireshark、omnipeek、科来或其他),都可以按照这个分析方法,快速的分析定位大部分的异常流量。

什么是异常流量

       严格的来讲,正常业务流量之外的流量,都应该归类为异常流量的范畴。但是,除了在工业控制系统等生产网络环境中,可以这样定义异常流量之外,其他的办公网络环境如此严格的定义异常流量都是不合适的。因为在普通的办公网环境下很难保证网内交互的都是业务流量。
       在办公网络环境下,办公端系统的应用和管理是非常丰富和复杂的,我们难以做到让每个办公终端在固定的时间内只运行某些固定的业务系统,相反,这些办公终端会根据不同的使用者特性和个人偏好,在不同的时段运行的大量的应用进程,这些进程中可能包含正常的办公应用的进程,也可能包含大量依托于互联网的非业务应用进程,甚至可能包含使用者自己都不知道的第三方插件、木马、病毒等进程。因此,我们还需要定义一个应用更为广泛的狭义上的异常流量。

       狭义范畴上的异常流量主要指:病毒、蠕虫、木马、垃圾应用(P2P下载/在线视频/在线游戏等)、攻击(各种DOS攻击流量)等影响网络和业务正常运行的流量。
       如此一来,我们便明确了我们需要分析的对象了,如果你是一个初学者,这样是不是感觉更具体一点?是不是有种找到靶心的感觉,哈哈。话不多说,还是跟我一起来开启这趟分析之旅吧。

异常流量分析方法和思路

       按照我个人的经验,我将异常流量的分析方法归纳为三大步骤和五个过程,分别为
发现-定位-管控三大步骤和Whether-Who-What -Where-How五个过程。如下图所示: 

点击查看原图

发现-定位-管控三大步骤

点击查看原图

Whether-Who-What -Where-How五个过程

发现-定位-管控三大步骤:
发现(Discovery):及时发现当前网络环境中是否存在异常流量。
定位(Location):通过分析定位出异常流量的根源、类型、运作模式以及具体的主机位置,为下一步的管控提供全面的信息。
管控(Control):利用现有资源,及时实现对异常流量的管理和控制,消除异常流量对网络和业务正常运转的影响。

Whether-Who-What -Where-How五个过程:
Whether:通过分析,大致判断网络内部是否存在异常流量?
Who:若存在异常流量,异常流量都与谁有关?
What:异常流量是什么类型的?异常流量的运作机制怎样?
Where:异常流量相关的主机都在什么位置?
How:如何实现对异常流量的及时管理和控制?
       这三大步骤和五个具体分析过程是相互关联的。下面我们将这三大步骤和五个具体分析过程关联起来进行阐述。

阅读全文>>

标签: 交换机 TCP wireshark omnipeek 防火墙 IPS 科来 中间设备 UDP 抓包 DOS 攻击 行为特征 发包频率 异常流量 蠕虫 木马 P2P 扫描 TCP会话 UDP会话 平均包长 平均每秒包数 利用率

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

TCP保活(TCP keepalive)

作者:易隐者 发布于:2012-10-15 11:30 Monday 分类:网络分析

TCP保活的缘起

       双方建立交互的连接,但是并不是一直存在数据交互,有些连接会在数据交互完毕后,主动释放连接,而有些不会,那么在长时间无数据交互的时间段内,交互双方都有可能出现掉电、死机、异常重启等各种意外,当这些意外发生之后,这些TCP连接并未来得及正常释放,那么,连接的另一方并不知道对端的情况,它会一直维护这个连接,长时间的积累会导致非常多的半打开连接,造成端系统资源的消耗和浪费,为了解决这个问题,在传输层可以利用TCP的保活报文来实现。

TCP保活的作用

1, 探测连接的对端是否存活
        在应用交互的过程中,可能存在以下几种情况:
(1), 客户端或服务器端意外断电、死机、崩溃、重启
(2), 中间网络已经中断,而客户端与服务器端并不知道
        利用保活探测功能,可以探知这种对端的意外情况,从而保证在意外发生时,可以释放半打开的TCP连接。

2, 防止中间设备因超时删除连接相关的连接表

       中间设备如防火墙等,会为经过它的数据报文建立相关的连接信息表,并为其设置一个超时时间的定时器,如果超出预定时间,某连接无任何报文交互的话,中间设备会将该连接信息从表中删除,在删除后,再有应用报文过来时,中间设备将丢弃该报文,从而导致应用出现异常,这个交互的过程大致如下图所示:

点击查看原图

       这种情况在有防火墙的应用环境下非常常见,这会给某些长时间无数据交互但是又要长时间维持连接的应用(如数据库)带来很大的影响,为了解决这个问题,应用本身或TCP可以通过保活报文来维持中间设备中该连接的信息,(也可以在中间设备上开启长连接属性或调高连接表的释放时间来解决,但是,这个影响可能较大,有机会再针对这个做详细的描述,在此不多说)。

常见应用故障场景:

       某财务应用,在客户端需要填写大量的表单数据,在客户端与服务器端建立TCP连接后,客户端终端使用者将花费几分钟甚至几十分钟填写表单相关信息,终端使用者终于填好表单所需信息后,点击“提交”按钮,结果,这个时候由于中间设备早已经将这个TCP连接从连接表中删除了,其将直接丢弃这个报文或者给客户端发送RST报文,应用故障产生,这将导致客户端终端使用者所有的工作将需要重新来过,给使用者带来极大的不便和损失。

TCP保活报文格式:

1, TCP keepalive probe报文

       我们看到,TCP保活探测报文是将之前TCP报文的序列号减1,并设置1个字节,内容为“00”的应用层数据,如下图所示:

点击查看原图

发送keepalive probe报文之前的TCP报文

点击查看原图

 TCP keepalive probe报文


2, TCP keepalive ACK报文

        TCP保活探测确认报文就是对保活探测报文的确认, 其报文格式如下:

点击查看原图

TCP keepalive ACK报文

TCP保活报文交互过程

        TCP保活的交互过程大致如下图所示:

点击查看原图


TCP保活可能带来的问题

1, 中间设备因大量保活连接,导致其连接表满

       网关设备由于保活问题,导致其连接表满,无法新建连接(XX局网闸故障案例)或性能下降严重
2, 正常连接被释放

       当连接一端在发送保活探测报文时,中间网络正好由于各种异常(如链路中断、中间设备重启等)而无法将该保活探测报文正确转发至对端时,可能会导致探测的一方释放本来正常的连接,但是这种可能情况发生的概率较小,另外,一般也可以增加保活探测报文发生的次数来减小这种情况发生的概率和影响。

TCP保活的设置

        一般而言,保活探测主要在服务器端实现,如果应用层有相应的保活机制时,传输层的TCP保活就可以不用。

        在windows系统中,我们可以通过修改注册表等来达到开启、调整保活相关
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
KeepAliveInterval
项:Tcpip\Parameters
数值类型:REG_DWORD - 时间(以毫秒为单位)
有效范围:1 - 0xFFFFFFFF
默认值:1000(1 秒)
说明:此参数确定在收到响应之前,保活重传之间的时间间隔。一旦收到一个响应,将由 KeepAliveTime 值重新控制在下一次保活传输之前的延迟。如果经过 TcpMaxDataRetransmissions 指定的重新传输次数后仍无响应,将放弃连接。
KeepAliveTime
项:Tcpip\Parameters
数值类型:REG_DWORD - 时间(以毫秒为单位)
有效范围:1 - 0xFFFFFFFF
默认值:7,200,000(两个小时)
说明:此参数控制 TCP 试图通过发送保活数据包来验证空闲连接是否仍然保持的次数。如果远程系统仍然可以连接并且正在运行,它就会响应保活传输。默认情况下不发送保活数据包。应用程序可以在连接上启用此功能。

       关于Linux、HP UNIX、IBM AIX、SUN solaris等系统keepalive参数的设置和修改,请大家自行百度谷歌,在此我就不做简单搬砖的事情了。

阅读全文>>

标签: 防火墙 保活 keepalive 连接表 TCP保活 TCP keepalive

评论(7) 引用(0) 浏览(75998)

网页打开慢但HTTP下载快故障分析案例

作者:易隐者 发布于:2012-10-10 16:06 Wednesday 分类:网络分析

【说在之前】:

1,用到了疑难杂症网络分析过程中最基本、最核心的两个分析方法:对比分析法关联分析法

2,该案例涉及到的知识点主要有SYN重传连接数限制等,大家可参考本博客中相关知识点的文章。

【我的案例】:

故障环境

       某单位大体的网络结构如下图所示: 

点击查看原图


内部办公人员通过交换机到流控设备,再通过防火墙做NAT访问互联网。

故障现象

1,在地矿局进行互联网时,打开网页的速度非常的慢,有的网页要刷新几次才可以正常显示;
2,但是使用下载工具或是基于HTTP的下载速度却很快。

故障分析

1 确认故障原因

        我们找一台主机,访问互联网的某网站,发现的确比较慢,我们抓取故障时的交互数据包,如下图所示: 

点击查看原图

       通过上图,我们可以发现,客户端在与服务器建立TCP连接时,其SYN请求报文被客户端重传了一次,这个重传导致了2.88秒的延时。TCP重传一般是中间设备丢包导致的,那么到底是在什么地方丢包的呢?我们首先需要界定一下可能丢包的故障关键点。

2 选择故障关键点

       该故障环境相对简单,在办公用户访问互联网时,数据包只通过了交换机、流控设备和防火墙,而交换机主要负责转发数据,不会对数据包进行深度的检测和过滤等操作,所以在该环境下主要的关键故障点是流控设备和防火墙,如下图所示:

点击查看原图

 

3分析流控设备是否丢包

       关键故障点确定之后,我们首先在流控设备的前后同时抓包做对比分析,以确定是否是流控设备丢包,如下图所示: 

点击查看原图


       通过我们还原故障现象时,在流控设备前后抓取数据包的对比分析,结论显示,流控设备前后数据包交互的过程是一样的(这个对比分析通过五元组关联同一会话之后,对比查看数据交互过程的差异即可,由于流控设备前后的数据交互过程完全一样,在此不做具体详细的分析说明),这说明,在打开页面较慢时,流控设备并未丢弃任何交互的数据报文。

4 分析防火墙是否丢包

       同样,我们再在防火墙的进出口同时抓包,通过比较防火墙前后数据包的交互情况来确定造成故障的原因,部署图如下所示: 

点击查看原图


1, 在访问某网站出现缓慢现象时,在防火墙前后同时抓取数据包,并保存,为下面的对比分析提供原始的数据报文。
2,我们先分析防火墙内网口抓取的数据,在科来网络分析系统的“TCP会话”视图,我们发现了一个web连接持续的时间为6秒,并且其在三次握手过程中,存在重传现象,如下图所示: 

点击查看原图


这个TCP会话的源端口是1124,目的地址为58.30.236.11,目的端口是80
3,我们通过关联分析法,在进行网页访问时,我们在防火墙前后同时进行抓包,下图就是在防火墙出口处抓取到的数据包: 

点击查看原图

       我们知道防火墙在网络运行中起到防护作用,会将未经授权的报文过滤,但是防火墙一般不会阻止正常的数据包,我们在比较上面两张图发现,在防火墙后捕获到的数据包第一次发送同步请求没有成功,然后又重传了一次同步数据包,才成功建立了连接;而在防火墙前面抓取到的数据包却没有看到重传的数据包(黑框标记的部分),这很清晰的说明,第一个SYN报文被防火墙丢弃了。

4 分析结论

       通过上面的分析,我们可以得出如下结论:

       由于防火墙在转发数据包时,随机丢弃了客户端发送的SYN报文而造成的。可能是防火墙配置不当(连接数限制)或防火墙BUG(在处理TCP新建连接时不稳定)导致的。

总结

       经过分析知道是由于防火墙不规律丢弃SYN报文导致的网页打开慢现象,但是为什么HTTP下载的速度却很快?这是因为防火墙仅随机丢弃SYN报文,而HTTP下载在刚开始建立TCP连接时,防火墙有可能会丢弃其SYN报文,但是下载行为决定其会不断发起SYN报文进行连接建立的尝试,而一旦连接建立成功,则防火墙不会丢包,给用户的感觉就是速度也非常快。

阅读全文>>

标签: TCP 对比分析法 关联分析法 丢包 SYN 防火墙 重传 BUG NAT 连接数限制 SYN报文

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

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