做网站相关人员,wordpress列表分页,利于seo的网站设计,深圳创业补贴10万1. 前言
随着互联网的普及和发展#xff0c;各行业的业务和应用越来越依赖于网络。然而#xff0c;网络环境的不稳定性和复杂性使得出现各种异常现象的概率变得更高了。这些异常现象会导致业务无法正常运行#xff0c;给用户带来困扰#xff0c;甚至影响企业的形象和利益。…1. 前言
随着互联网的普及和发展各行业的业务和应用越来越依赖于网络。然而网络环境的不稳定性和复杂性使得出现各种异常现象的概率变得更高了。这些异常现象会导致业务无法正常运行给用户带来困扰甚至影响企业的形象和利益。因此需要一种能够快速诊断和定位网络异常问题的解决方案。
网络抓包分析技术是一种常用的网络调试工具它可以捕获网络数据包并提供详细的数据分析和统计信息帮助用户快速定位网络问题。其中TCP RST报文是一种常见的网络异常现象它通常表示连接被重置或中断导致业务无法正常运行。
针对这种问题NetInside全流量回溯分析解决方案以下简称NetInside全流量通过探针设备旁路收集和存储指定链路的全部流量数据实现无人值守对关键业务系统、应用和网络链路进行7×24小时、全方位的流量监控智能学习关键性能指标的基线值当出现网络异常、业务或网络相关状态达到阈值时进行主动预警并可以实时/事后对需要的原始包进行下载和分析解码快速定位问题原因。
NetInside用以人为本的理念为信息部门量身打造了新一代全流量回溯分析系统充分利用网络数据包建立覆盖重要链路、关键设备端口、核心服务的全面监控视图并且按照网络部门的工作流程组织功能与操作使其能够广泛适用于各种需要场景。
以服务为导向的全流量方法使NetInside系统能够直接体现网络基础架构对业务应用的支撑能力提供实时故障诊断、告警触发、事后应用响应深度分析功能。整个系统从根本上简化了网络故障诊断、新应用和服务的部署以及降低了运营成本并提供快捷的方式来实现故障定位。为分析网络攻击、定位异常评估、判定用户体验、应用性能和网络服务质量提供可以信赖的数据依据。依托真实的网络流量快速发现、定义应用并提供数据正确性、变更结果验证能力大大提升网络流量的可视化覆盖率和工作效率。运用先进的数据统计分析技术发现、告警等功能极大简化了过去繁冗复杂的操作过程。
2. RST介绍
TCP RSTReset是一种TCP协议中的控制报文位于TCP协议的传输层用于终止TCP连接或拒绝非法连接。TCP RST通常由TCP连接的一方发送它可以立即终止TCP连接并通知另一方连接已经被重置。
TCP RST报文位于TCP报头中的控制位字段Control Bits Field该字段占据一个字节它的第6位RST用来表示TCP RST报文。下面是一个TCP报头的示意图 可以看到TCP报头中的第13个字节即控制位字段的第6位表示TCP RST报文。当该位被设置为1时表示发送TCP RST报文。
3. 常见产生RST的原因及确认方法
常见产生TCP重置数据包情况和原因有如下7种情况。需要注意的是TCP重置数据包可能会对正常的TCP连接产生影响因此应该谨慎使用。如果不确定是否应该发送TCP重置数据包请先咨询网络管理员或安全专家。
3.1. 防火墙或网络设备对TCP连接的干预
防火墙或网络设备对TCP连接进行干预时可能会发送TCP重置数据包来终止连接。
原因判断可以通过查看防火墙或网络设备的日志确认是否存在对TCP连接的干预行为。如果发现有TCP连接被终止且收到了TCP重置数据包那么很可能是防火墙或网络设备发送的。
3.2. 端点认为该连接已经失效或存在异常
当TCP连接的一个端点认为该连接已经失效或存在异常情况时它可以发送TCP重置数据包来终止连接。
原因判断可以通过查看TCP连接的日志或网络抓包工具确认是否存在TCP重置数据包。如果发现某一方发送了TCP重置数据包那么很可能是该方认为连接已经失效或存在异常情况。
3.3. 攻击者可能会发送TCP重置数据包
在某些攻击中攻击者可能会发送TCP重置数据包来终止连接或欺骗接收方。
原因判断可以通过查看网络抓包工具确认是否存在异常的TCP重置数据包。如果发现TCP重置数据包的源地址不明或与正常通信的IP地址不符那么很可能是遭受攻击了。
3.4. 网络拥塞
当网络拥塞时路由器或防火墙可能会丢弃部分数据包从而导致TCP连接超时或失效。此时连接的一方可能会发送TCP重置数据包来终止连接。
原因判断可以通过查看网络抓包工具确认是否存在丢失的数据包或TCP连接超时。如果发现TCP重置数据包是在网络拥塞期间发送的那么很可能是因为连接的一方认为连接已经失效。
3.5. 程序异常
当应用程序或操作系统出现异常时可能会导致TCP连接受损或失效。此时连接的一方可能会发送TCP重置数据包来终止连接。
原因判断可以通过查看应用程序或操作系统的日志确认是否存在异常行为或错误信息。如果发现某一方发送了TCP重置数据包那么很可能是由于程序异常导致的。
3.6. 超时
当TCP连接长时间没有活动时可能会被认为已经失效。此时连接的一方可能会发送TCP重置数据包来终止连接。
原因判断可以通过查看TCP连接的日志或网络抓包工具确认连接是否长时间没有活动。如果发现某一方发送了TCP重置数据包且连接长时间没有活动那么很可能是由于超时导致的。
3.7. 非法连接
当某些恶意程序或攻击者尝试建立非法的TCP连接时连接的一方可能会发送TCP重置数据包来阻止该连接。
原因判断可以通过查看网络抓包工具确认是否存在非法的TCP连接请求或连接行为。如果发现某一方发送了TCP重置数据包那么很可能是由于遭受非法连接请求导致的。
4. RST案例分析
下面将通过两个现场真实案例进行RST异常行为分析快速帮助用户解决疑难问题。
4.1. 某省公安案例
4.1.1. 背景
集成指挥平台中有定时任务定时传输数据到总队总队定时下发数据到市交警支队。市交警支队发现定时任务一直出现执行失败的错误。市交警支队和总队联系说需要市交警支队排查一下自身网络前两天在应用服务器上面抓了定时任务的数据包发现在连接过程中一直被RST。现在不能确认在哪个环节被RST。
本次分析采用NetInside流量分析系统已部署到业务环境使用流量分析系统提供实时和历史原始流量。本次分析重点针对集成定时任务故障排查以供设置取证、性能分析、网络质量监测以及深层网络分析。
4.1.2. 环境部署
市交警支队和交警总队采用专网专线方式互联在市交警支队安全域集成指挥平台的核心交换机位置将流量旁路方式镜像给NetInside流量分析系统通过NetInside对定时任务流量进行采集和分析。 4.1.3. 分析时间
报告分析时间范围为2023-05-19日白天工作时段。
4.1.4. 分析目的
针对集成指挥平台中定时任务出现执行失败原因进行分析找出问题的根本原因并采取相应的措施来解决这些问题。
通过分析可以确定哪些因素导致了定时任务执行失败如网络连接问题、系统故障、配置错误等。这样做可以帮助管理员及时发现和解决问题确保集成指挥平台的正常运行。查找并验证确认是否存在业务系统健康问题。
4.1.5. 详细分析
以下对本次故障详细分析。
4.1.5.1. 流量传输存在明显时间间隔
通过分析系统秒级数据分布趋势发现10.61.132.78以下简称78和服务器10.56.81.80以下简称80之间的数据传输存在明显的、有规律性的传输间隔现象。这极有可能受到某些未知因素的影响造成。 4.1.5.2. 数据传输间隔现象深入分析
从分析系统下载对应的数据包发现大量的RST报文如下图。 随机查看上图中一个会话信息基于5元组的对话发现存在异常现象。
下图中Frame 19695之前的所有报文是一个正常POST请求操作但Frame 20756和20757明显与前面的连接没有关系。 继续分析。
正常数据传输中80到78流向的数据包TTL为119如下图。 再看Frame 20756同样是80到78流向的数据包但TTL却为124。 同时这个RST包还含有更多的应用层信息可供参考。 而Frame 20757则是对上面这个RST报文的RST。
经过分析在时长约43分钟的时间范围内共出现了1846次类似的RST。 4.1.5.3. 异常RST对数据传输的影响
分析发现当出现上述RST后78会停滞一段时间才会再次向80发起TCP握手请求继而进行POST数据操作。
以下是随机查看的几个数据为证。
异常RST后78等待8.19秒才向80发起连接建立请求。 异常RST后78等待13.14秒才向80发起连接建立请求。 异常RST后78等待34.34秒才向80发起连接建立请求。 异常RST后78等待58.43秒才向80发起连接建立请求。 不再一一列举。
4.1.6. 分析结论
78与80之间数据传输时会出现大量的未知系统或节点的RST数据包该数据包同时会对78发起请求造成明显的时延作用。
4.1.7. 解决建议
由于异常数据包中含有地址及提示信息可以根据这个信息定位发送RST的设备。也可以根据TTL信息计算并定位该设备所处位置。
对发出异常RST的设备进行策略配置和优化。
4.1.8. 问题验证
针对异常RST进行分析确定是由终端管控软件发出管理人员对该软件做了相应设置让其不再发出RST报文。
从NetInside流量分析系统中下载策略修改后78与80之间的数据传输报文打开查看不再出现异常的RST报文。 同样在一段时间内一个异常RST都不再出现如下图。 这说明终端管控软件策略设置有效。
4.1.9. 异常前后效率对比
最后对异常前后流量传输特征进行分析和比较。
4.1.9.1. 流量传输状况对比
以下是策略调整前78和80之间的数据传输情况。 以下是策略调整后78和80之间的数据传输情况。 通过对比可以看到策略调整后数据传输明显加快且中间没有出现明显的间隔和空白等待时段。
4.2. 某电气化局案例
4.2.1. 背景
电气化局的用户反馈近期视频系统在使用过程中出现频繁中断的情况这种情况影响到用户的视频体验和工作效率。
针对此问题我们将NetInside流量分析系统部署到电气化局机房使用流量分析系统提供实时和历史原始流量。重点针对电气化局的视频系统进行故障分析找出视频系统中断的具体原因。
4.2.2. 故障现象
通过用户反馈2023年2月8日7点20分出现视频中断情况通过视频系统管理端看到视频流量有断开的情况如下图 4.2.3. 环境部署
在内网中心机房的视频区的汇聚交换机位置将相关流量旁路方式镜像给NetInside流量分析系统通过NetInside对所有视频流量进行采集和分析。 4.2.4. 故障分析
针对此问题我们来进行详细分析。
4.2.4.1. 分析设备流量采集图
与现场网络人员沟通了解真实网络结构以下是视频会议的流量采集图 流量采集图主要为1台视频系统客户端1台视频系统服务器1台核心交换机
视频系统客户端和视频系统服务器下方标注显示对应的MAC地址
核心交换机分别标注显示对应的两个口的MAC地址
核心交换机通过镜像方式将流量给到流量分析系统。
4.2.4.2. 分析思路
1、流量分析系统里找到异常数据包下载数据包。
2、打开数据包找到异常时间点的数据包内容。
3、分析视频数据包的协议和详细内容。
4.2.4.3. 详细分析
数据包下载
根据流量分析系统迅速找到异常节点对数据包进行下载。 流量分析
流量分析系统对镜像后的流量进行去重功能所以分析系统仅获取10.21.106.11发送到核心交换机的流量及10.21.30.106发送到核心交换机上的流量。
正常传输
通过数据包分析看到客户端10.21.106.11发给服务器10.21.30.106的mac地址为SrcHuaweiTe_XX:XX:26 ———— dstHuaweiTe_XX:XX:01。 通过数据包分析看到服务器10.21.30.106发给客户端10.21.106.11的mac地址为DstHuaweiTe_XX:XX:0f ———— srcEdgeCore_XX:XX:a8。
数据包内的TTL为64。
同时数据包带有VLAN协议VLAN ID为59。 异常传输
通过数据包分析看到视频中断时间点发现RST数据包MAC地址异常服务器10.21.30.106发给客户端10.21.106.11的mac地址为srcHuaweiTe_XX:XX:01dstHuaweiTe_XX:XX:26正常应为srcEdgeCore_XX:XX:a8dstHuaweiTe_XX:XX:0f。
数据包内的TTL为127。
未发现VLAN协议。 以上对比发现异常数据包MAC地址异常没有VLAN协议TTL跳数异常。
4.2.5. 分析结论
通过以上系统分析发现出现视频中断时网络里出现异常的RST的数据包致使通信双方TCP连接中断。
4.2.6. 建议
通过对电气化局的视频数据分析发现网络上存在异常报文建议结合网络实际情况做进一步分析。
5. 总结
除了网络抓包分析技术还有其他的方法可以帮助企业快速诊断和定位异常现象例如基于人工智能和机器学习的异常检测技术。这种技术可以通过对业务数据进行分析学习正常的业务模式和规律然后检测出异常数据并进行相应的处理。这种方法具有高精度和高效率的优势可以帮助企业快速发现和解决问题。
综上所述网络异常问题是各行业都可能遇到的问题需要一种能够快速诊断和定位的解决方案。网络抓包分析技术是一种常用的解决方案它可以帮助用户快速定位网络问题。除此之外还有其他的方法可以帮助企业快速诊断和定位异常现象例如基于人工智能和机器学习的异常检测技术。
