当前位置:文档之家› Windows系统云服务器网络访问丢包延时高

Windows系统云服务器网络访问丢包延时高

Windows系统云服务器网络访问丢包延时高
Windows系统云服务器网络访问丢包延时高

Windows系统云服务器网络访问丢包延时高

【来源:小鸟云计算】

Ps.小鸟云,国内专业的云计算服务商

当网站访问很慢或无法访问时,若排除其它显著问题,而检测到ping 有明显丢包时,建议您作链路测试。Windows 环境下,您可以通过WinMTR 工具(优先使用)或TRACERT 命令行工具进行链路测试来判断问题来源。

通常情况下,请依照下述步骤进行处理:

1.利用链路测试工具探测网络状况和服务器状态。

2.根据链路测试结果分析处理。

WinMTR 工具(优先使用)

mtr(My traceroute)作为一款网络测试工具,集成了tracert 与ping 这两个命令的图形界面。ping 与tracert 通常被用來检测网络状况和服务器状态。

WinMTR 是mtr 工具在Windows 环境下的图形化实现,适合Windows 下做路由追踪及ping 测试。WinMTR 默认发送ICMP数据包进行探测,无法切换。

相比TRACERT 命令行工具,WinMTR 能避免节点波动对测试结果的影响,测试结果更正确。Windows 环境下,建议优先使用WinMTR 进行链路测试。

操作步骤

1.在官网下载WinMTR 后,直接解压运行。运行程序后,在Host 字段输入目标服务器域名或IP(前面不要包含空格)。

2.单击Start 开始测试。(开始测试后,相应按钮变成了Stop。)

3.运行一段时间后,单击Stop 停止测试。

说明:您可以多测试几分钟,测试结束后,将结果导出。

·Copy Text to clipboard:将测试结果以文本格式复制到粘贴板。

·Copy HTML to clipboard:将测试结果以HTML 格式复制到粘贴板。

·Export TEXT:将测试结果以文本格式导出到指定文件。

·Export HTML:将测试结果以HTML 格式导出到指定文件。

·Options:可选参数。具体包括:

Interval(sec):每次探测的间隔(过期)时间,默认为1 秒。

Ping size(bytes):ping 探测所使用的数据包大小,默认为64 字节。

Max hosts in LRU list:LRU 列表支持的最大主机数,默认值为128。

Resolve names:通过反查IP 以域名显示相关节点。

4.查看WinMTR 运行后的返回结果。

说明:默认配置下,WinMTR 测试结果说明如下

第一列(Hostname):到目的服务器要经过的每个节点主机IP 或域名。

第二列(Nr):节点编号。

第三列(Loss%):节点丢包率。ping 数据包回复失败的百分比,由此可判断那个节点(线路)出现故障,是服务器所在机房还是国际路由干路。

第四列(Sent):已发送的数据包数量。

第五列(Recv):已成功接收的数据包数量。

第六、七、八、九列(Best 、Avg、Worst、Last):分别是回应时间的最小值、平均值、最大值和最后一个数据包的回应时间。

TRACERT 命令行工具

TRACERT (Trace Route) 是Windows 自带的网络诊断命令行实用程序,用于跟踪Internet 协议(IP) 数据包传送到目标地址时经过的路径。

TRACERT 通过向目标地址发送ICMP 数据包来确定到目标地址的路由。在这些数据包中,TRACERT 使用了不同的IP 生存期(TTL) 值。由于要求沿途的路由器在转发数据包前至少必须将TTL 减少1,因此TTL 实际上相当于一个跃点计数器(hop counter)。当某个数据包的TTL 达到零(0) 时,相应节点就会向源计算机发送一个ICMP 超时的消息。

TRACERT 第一次发送TTL 为1 的数据包,并在每次后续传输时将TTL 增加1,直到目标地址响应或达到TTL 的最大值。中间路由器发送回来的ICMP 超时消息中包含了相应节点的信息。

操作步骤

1.在桌面底部单击开始菜单,选择运行。

2.打开运行框后,在框中输入cmd 并单击确定。

3.在命令运行界面中,输入tracert ,按回车键后,界面将显示tracert 的用法说明。

4.根据具体用法,输入待跟踪的目标地址。示例

分析链路测试结果

以如下链路测试结果示例图为基础进行阐述:

操作步骤

1.判断各区域是否存在异常,并根据各区域的情况分别处理。

区域A:客户端本地网络,即本地局域网和本地网络提供商网络。针对该区域异常,客户端本地网络相关节点问题,请对本地网络进行排查分析;本地网络提供商网络相关节点问题,请向当地运营商反馈。

区域B:运营商骨干网络。针对该区域异常,可根据异常节点IP 查询归属运营商,然后直接或通过阿里云售后技术支持,向相应运营商反馈问题。

区域C:目标服务器本地网络,即目标主机归属网络提供商网络。针对该区域异常,需要向目标主机归属网络提供商反馈问题。

2.结合Avg(平均值)和StDev(标准偏差),判断各节点是否存在异常。

·若StDev 很高,则同步观察相应节点的Best 和Wrst,来判断相应节点是否存在异常。·若StDev 不高,则通过Avg 来判断相应节点是否存在异常。

注意:上述StDev 高或者不高,并没有具体的时间范围标准。而需要根据同一节点其它列的延迟值大小来进行相对评估。比如,如果Avg 为30 ms,那么,当StDev 为25 ms,则认为是很高的偏差。而如果Avg 为325 ms,则同样的StDev(25 ms),反而认为是

不高的偏差。

3.查看节点丢包率,若Loss% 不为零,则说明这一跳网络可能存在问题。

导致节点丢包的原因通常有两种:

·人为限制了节点的ICMP 发送速率,导致丢包。

·节点确实存在异常,导致丢包。

4.确定当前异常节点的丢包原因。

·若随后节点均没有丢包,说明当前节点丢包是由于运营商策略限制所致,可以忽略。如前文链路测试结果示例图中的第2 跳所示。

·若随后节点也出现丢包,说明当前节点存在网络异常,导致丢包。如前文链路测试结果示例图中的第5 跳所示。

说明:前述两种情况可能同时发生,即相应节点既存在策略限速,又存在网络异常。对于这种情况,若当前节点及其后续节点连续出现丢包,而且各节点的丢包率不同,则通常以最后几跳的丢包率为准。如前文链路测试结果示例图所示,在第5、6、7 跳均出现了丢包。所以,最终丢包情况,以第7 跳的40% 作为参考。

5.通过查看是否有明显的延迟,来确认节点是否存在异常。通过如下两个方面进行分析:·若某一跳之后延迟明显陡增,则通常判断该节点存在网络异常。如前文链路测试结果示例图所示,从第5 跳之后的后续节点延迟明显陡增,则推断是第5 跳节点出现了网络异常。注意:高延迟并不一定完全意味着相应节点存在异常,延迟大也有可能是在数据回包链路中引发的,建议结合反向链路测试一并分析。

ICMP 策略限速也可能会导致相应节点的延迟陡增,但后续节点通常会恢复正常。如前文链路测试结果示例图所示,第3 跳有100% 的丢包率,同时延迟也明显陡增。但随后节点的延迟马上恢复了正常。所以判断该节点的延迟陡增及丢包是由于策略限速所致。

其它建议

若主机掉包和延迟非常高,建议作WinMTR 双向测试,即本地到服务器的和服务器到本地的测试。无法远程登录时,请通过管理终端进行登录。

S12508由于配置URPF导致设备丢包案例分析

S12508由于配置URPF导致设备丢包案例分析 关键词: ?URPF ?丢包 ?0推荐,1495浏览 ?1收藏,我的收藏 问题现象 如下拓扑图:S12508-1和S12508-2做VRRP,现场发现从S12508-FW这台设备跨S12508-02去ping S12508-01有大量丢包,丢包很规律,每五个包只会通一个。S12508-FW直连ping S12508-2不会丢包,S12508-2与S12508-1直连互ping也不丢包。并且业务一直也不受影响,就如下两个地址互ping有丢包: 从S12508-FW的本地地址(211.138.35.34)到S12508-1(221.181.39.254) [12508-FW]ping -c 12 -a 211.138.35.34 221.181.39.254 Ping 221.181.39.254 (221.181.39.254): 56 data bytes, press CTRL_C to break Request time out Request time out Request time out Request time out Request time out 56 bytes from 221.181.39.254: icmp_seq=0 ttl=255 time=8.305 ms Request time out Request time out Request time out Request time out Request time out 56 bytes from 221.181.39.2549.1.1.2: icmp_seq=4 ttl=255 time=1.651 ms

rtcp丢包抖动时延计算原理

RTP/RTCP 丢包/抖动/时延计算原理 1.RTP/RTCP的基本功能介绍 实时传输协议RTP(A Transport Protocol for Real-Time Application)提供实时的端对端传输业务(如交互的语音和图象),包括负载类型标识,序列号,时间戳,传输监视。 实时传输协议(RTP)本身并不提供任何机制保证实时传输或业务质量保证,而是让底层协议去实现。 RTP包括两个紧密相关的部分: 实时传输协议(RTP-Real Time Transport Protocol),传输有实时特性的信息; RTP控制协议(RTCP-RTP Control Protocol),监视业务质量和传输对话中成员的信息。 RTP/RTCP报文封装格式为:DL+IP+UDP+RTP/RTCP 2.RTP报文统计方法介绍 RTP报文发送统计: NTP时间标志:64比特,指示了此报告发送时的壁钟(wallclock)时刻,它可以与从其它接收者返回的接收报告块中的时间标志结合起来,测量到这些接收者的环路时延。 RTP时间标志:32比特,与以上的NTP时间标志对应同一时刻,但是与数据包中的RTP时间标志具有相同的单位和偏移量。 发送包数:32比特,从开始传输到此SR包产生时该发送者发送的RTP数据包总数。 若发送者改变SSRC识别符,该计数器重设。 发送字节数:32比特,从开始传输到此SR包产生时该发送者在RTP数据包发送的字节总数(不包括头和填充)。若发送者改变SSRC识别符,该计数器重设。 RTP报文接收统计: 丢包率:8比特,自从前一SR包或RR包发送以来,从SSRC_n传来的RTP数据包的损失比例,以固定点小数的形式表示,小数点在此域的左侧,等于将丢包率乘256后取整数部分。该值定义为损失包数被期望接收的包数除。(对应RTCP消息中的丢

网络丢包分析案例、解决方案

网络丢包分析 数据在网络层以数据包的形式进行传输,由于各种原因,数据包在传输过程中总会存在些许损失,我们称之为丢包。 1.1. 造成丢包的原因有哪些 ?网络设备的故障 包括硬件方面的和软件方面的故障。硬件故障主要是物理层面的故障如:网卡故障,端口故障等。软件故障主要是在配置方面的问题,如错误的静态路由,主机默认网关配置错误等等。 ?网络拥塞 通常由于网络带宽过小或网络中存在异常流量时发生,比如ARP攻击,P2P等。 ?MTU配置不当 在关键设备上MTU设置不当,也会造成网络丢包(以太网:1500字节,IEEE 802.3/802.2 1492字节)。 1.2. 如何确定网络丢包的存在 通常我们利用PING x.x.x.x -t这个命令来进行测试网络中是否存在丢包 在上图中可以看到,在本机上向192.168.122.2这个不存在的地址进行长时间PING的时候,发送出去的ICMP包都丢失了,丢失率达到100%。即从本机到192.168.122.2这个实际不可达地址的路径上存在丢包。 1.3. 定位网络丢包的分析步骤 在网络丢包发生的情况下,用户会明显感受到网络速度变慢,这时候网管首先需要做的就是进行PING X.X.X.X –t来进行大致是哪个网段的诊断。在发现确实有丢失率存在的情况下,我们可以利用科来软件进行进一步分析。 在分析之前,我们有必要学习一下前置知识。 TCP协议的特点之一就是保障数据传输的可靠性,即确保数据能够正确完整传输。那么TCP究竟是如何来保障的?可以看到,TCP在传输时,有着传输确认—重传机制,即发送数据一方在传输数据时为每一个分段编制序列号(Sequence Number),接收方会向发送方发送接收到分段数据的确认(Acknowledgment),通过这种方式确认数据是否准确传送,在无法确认某分段数据被准确传送或确认某分段数据没有被准确传送时重新进行传输。

长时延丢包网络控制系统的分析与建模

长时延丢包网络控制系统的分析与建模 江卷,朱其新 华东交通大学电气学院,南昌(330013) E-mail:broading@https://www.doczj.com/doc/4e13771798.html, 摘要:本文分析了网络控制系统中的主要问题,在传感器为时间驱动,控制器和执行器为事件驱动的前提下,提出了在综合考虑网络诱导时延、时序错乱和数据包丢失时网络控制系统的建模方法,并得出了网络控制系统模型。 关键词:网络控制系统;长时延;数据包丢失;建模 1.引言 网络控制系统(networked control systems,简记为NCS)是指通过网络形成闭环的反馈控制系统,是控制科学和飞速发展的计算机网络、以及通讯技术相结合的产物。NCS与传统的点对点结构的系统相比,减少了复杂的物理连接、可以实现资源共享、实现远程操作与控制、具有高的诊断能力、安装与维护简便、能有效减少系统的重量和体积、增加了系统的灵活性和可靠性等诸多优点。正因为这些优点使得网络控制系统得到广泛的应用,网络控制问题也得到了国际控制科学界和计算机科学界的广泛关注。 网络控制系统由传感器、控制器和执行器三部分组成。传感器和控制器以及控制器和执行器之间是通过网络进行数据传输的。网络控制系统(NCS)的结构如图1所示。 图1 网络控制系统结构示意图 由于网络加入控制系统中,给控制系统带来优点的同时,也给控制系统的研究带来了新的机遇和挑战。在网络中由于不可避免地存在网络阻塞和连接中断,这又会导致网络数据包的时序错乱和数据包的丢失。NCS中的网络诱导时延会降低系统性能甚至引起系统不稳定,现在时延系统的分析和建模近年来已取得很大发展。文献【1, 2】提出了通过在系统的数据接收端设置一定长度的缓冲区的方法将ICCS的随机时延转化成一确定性时延,从而将一随机时变的系统转换成一确定性系统,并基于该确定性模型设计了ICCS的多步时延补偿器,并检验了系统模型中含有不确定参数时该补偿算法的鲁棒性。文献【3】出了一种多输入多输出ICCS的时延补偿算法,并将使用下一步预测的标准环路传递再生方法推广到多步预测的情况。由于NCS的确定性控制方法人为地扩大了网络诱导时延,从而降低了系统的性能因此很多学者研究了NCS的随机控制方法。文献【4】分析了ICCS的网络诱导时延,在时延分析中考虑了信号丢失(message rejection)和无效采样(vacant sampling),并基于控制器的离

Volte丢包率优化案例

Volte丢包率优化方案 一、概述 随着市场推广,移动VOLTE用户逐步增多,Volte丢包率对用户语音质量影响较大,为提升用户感知,现针对VOLTE上下行丢包进行优化,提升用户满意度。 二、Volte丢包率优化思路 1、影响Volte丢包率的因素 用户对语音质量的感知直接受语音编码、丢包、时延以及抖动影响。 语音编码:高速率编码消耗带宽大,低速率编码影响语音质量 丢包:数据包丢失,会显著地影响语音质量 时延:时延会带来语音变形和会话中断 抖动:效果类似丢包,某些字词听不清楚 2、Volte语音通话协议栈和接口映射 从协议上看,一个Volte语音通话的参与网元主要有:UE、eNB、SGW、IMS,既有RAN侧网元,又有传统EPC侧网元,还有IMS侧网元。其中在无线测我们需要重点关注的网元是UE和eNB以及UE 和eNB之间的Uu接口。即主要涉及的协议是PHY、MAC、RLC、PDCP。需要注意的是,IMS侧的控制面协议,在EPC是以用户面数据形式进行传输的,在IMS侧才会被拆分成控制面和用户面。 Volte语音通话涉及的协议图:

当前网络结构图: 三、Volte丢包率优化目标 梳理Volte语音通话中各设备的问题表现及对应的影响因素,即可明确无线优化手段:参数优化,覆盖优化,干扰优化,移动性能优化,邻区优化,容量优化,功能优化。

RLC 层参数优化 输承 载 传 序 大时延、抖动,丢包、乱 参数配置,容量或能力限制,传输 质量问题 1、Volte 丢包率参数优化 PDCP 层参数优化 PDCP 是对分组数据汇聚协议的一个简称。它是 UMTS 中的一个无线传输协议栈,它负责将 IP 头压 缩和解压、传输用户数据并维护为无损的无线网络服务子系统(SRNS )设置的无线承载的序列号。 涉及参数:pdb 、pdboffset 、aqmmode 、 UlPdcpSduTimerDiscardEnabled 涉及的功能:TcpOptimization 参数优化原理:通过修改相关参数,延长或缩短 PDCP 层的丢包定时器,从而控制丢包 具体步骤如 下 参数优化建议: RLC UM 接收实体设置了一个 RLC PDC 重新排列的定时器,当检测到有收到 PDU 时启动定时器,

案例-关于VoLTE丢包率高优化处理最佳实践总结

VOLTE关于丢包率高优化处理总结 一、问题描述 上下行语音丢包率是是表征VoLTE业务的一个重要指标,与时延,抖动是影响VOLTE 语音质量的三大因素之一。监控,优化,提升上下行语音丢包率可以辅助VOLTE用户语音感知质量的提升。 PDCP层丢包对语音感知影响 VOLTE业务与GU业务不同,LTE走PS域,通过不同QCI承载来进行QoS保障,影响其VOLTE语音质量的关键指标为丢包,时延,抖动,其中丢包对MOS值基本是线性分布,一般丢包率在1%以内,MOS分都比较好;一旦丢包率大于1%后,MOS分明显下降,语音质量将会受到影响。 提取指标发现LF_H_YY余舜宇集团voLTE语音下行丢包率高达5.27%,voLTE语音上行丢包率6.24%,严重影响网络指标。

二、问题分析 丢包率定义和影响因素指标定义: VOLTE语音包关联指标分析

举例如下:若出现PUSCH MCS0阶占比和PDSCH MCS0阶占比同时恶化,弱覆盖导致的可能性较大。 ?根据关键指标关联,分析用户数问题 根据如下话统信息,判断终端所处小区的负载情况,判断是否小区语音负载大,导致不能及时调度用户,带来PDCP层丢包;

?空口丢包原理 上行空口丢包统计原理: 主要影响因素:上行调度不及时,如图中的1,会导致UE PDCP层的丢弃定时器超时,但现网值是集团规范值,不存在该问题。空口传输质量差,如图中2,MAC层多次传输错误导致丢包。

?上行空口丢包统计原理: 主要影响因素:下行丢包基本上是用户处于小区弱覆盖区域。?常见PDCP层丢包原因总结 ?常见PDCP层丢包处理总体思路

经典案例_VoLTE上行丢包率优化思路研究

VOLTE上行丢包率优化思路研究

目录 1问题分析 (1) 1.1V oLTE网管丢包率指标定义 (1) 1.2上行丢包原理 (2) 1.3丢包优化流程与思路 (3) 2分场景优化 (5) 2.1弱覆盖场景 (5) 2.1.1VOLTE上行覆盖增强 (5) 2.1.2天馈调整及功率优化 (7) 2.2大话务场景 (7) 2.2.1PDCCH CCE初始比例优化 (7) 2.2.2ROHC功能开启 (9) 2.3上行干扰场景 (11) 2.3.1基于干扰的动态功控 (11) 2.4频繁切换场景 (13) 2.5其他功能及参数优化 (15) 2.5.1PDCP层参数优化 (15) 2.5.2RLC重排序定时器 (16) 2.5.3包聚合关闭 (16) 3总结 (19)

【摘要】随着VOLTE业务的快速普及,VOLTE用户数和业务量都进入了快速上涨期,用户对语音质量要求越来越高,单通、吞字、双不通等严重影响用户感知,制约着4G业务的发展。其中“空口丢包”和“基站丢包”指标可有效表征VOLTE 语音感知,减少“空口丢包”和“基站丢包”是VOLTE语音质量优化提升的重要方向。本文将对V olte上行QCI1丢包率优化展开全面论述。 【关键词】VOLTE全面商用、QCI1上行丢包率、语音质量 1问题分析 1.1VoLTE网管丢包率指标定义

1.2上行丢包原理 VOLTE高清语音编码速率为23.85kbps,终端每20ms生成一个VOLTE语音包(使用RTP实时流媒体协议传输),再加上UDP包头、IP包头、最终打包成IP 包进行传输。在无线空口,按照协议IP包进一步被转换成PDCP包,PDCP包就是空口传输的有效数据,PDCP包在终端和基站间传输异常会导致应用层RTP包的丢失,从而引起语音感知差。 eNodeB的PDCP层接收语音包时如果检测到语音包的SN号不连续,则认为出现丢包。 上行丢包主要原因: 1)大TA/PHR受限、SR漏检、DCI漏检、RLC分段过多、上行调度不及时(上 图① )会导致UE PDCP层丢弃定时器超时丢包; 2)空口传输质量(上图② )差,MAC层多次传输错误后,失败导致丢包;

实验3排队时延和丢包

实验三 一.实验名称:排队时延和丢包 二.实验目的 1.深入理解排队时延和丢包的概念 2.深入理解排队时延和丢包的关系 三.实验环境 1.运行Windows 2003 Server/XP操作系统的PC机一台。 2.每台PC机具有以太网卡两块,通过双铰线与局域网相连 3.java虚拟机,分组交换Java程序 四.实验步骤 1. 熟悉实验环境 实验之前先要设定好发送速率和传输速率 ●发送速率可选择350packet/s或500 packet/s ●传输速率可选择350 packet/s、500 packet/s或1000 packet/s。 2.设定参数:发送速率为500packet/s传输速率为500packet/s 传输速率等于发送速率时,一般不会发生丢包现象,如图3-1所示

图3-1缓存队列偶尔溢出 3.设定发送速率为500 packet/s,传输速率为350 packet/s 此时,分组一般在路由器缓存中会产生排队现象,从而导致排队时延。由于缓存器容量(队列)是有限的,当到达的分组发现排列队列已满时,将会被丢弃(参见图3-2)。 图3-2排队队列已满,到达分组被丢弃 4.设发送速率为500 packet/s,传输速率为1000 packet/s 当发送速率比传输速率小得多时,也不会产生排队时延(参见图3-3)

图3-3不会产生排队时延 五.实验现象及结果分析 1.传输速率等于发送速率时,一般不会发生丢包现象。但当实验的 时间较长时,缓存队列偶尔也会发生溢出,请分析其原因。 答:时延是指数据从网络的一端传送到另一端的所需时间。其由发送时延、传播时延、处理时延、排队时延这几个不同的部分组成的。排队时延分组在经过网络传输时,要经过许多路由器。但分组再进入路由器后要先在输入队列中排队等待处理。在路由器确定了转发接口后,还要在输出队列中排队等待转发,即产生了排队时延。排队时延的长短往往取决于网络当时的通信量。当网络的通信量很大时会发生队列溢出,使分组丢失,即发生了丢包现象。传输速率等于发送速率时,一般不会发生丢包现象。但当实验的时间较长时,缓存队列偶尔也会发生溢出,这主要是由于长时间后偶尔处理时延会比较长,队列容量有限,有可能出现堆满的情况,则数据会在缓存中等待处理。 2.你自己可以选定一系列参数组进行模拟实验,并分析其中原理和 呈现的规律性。并且,同学们可以查看程序代码分析实验的情况。 答:自己加350 1000 下面是实验图

精品案例_干扰导致的高丢包小区

干扰导致的高丢包小区

目录 一、问题描述 (3) 二、分析过程 (3) 三、解决措施 (7) 四、经验总结 (8)

干扰导致的高丢包小区 【摘要】本文分析于处理VoLTE高丢包小区,发现为该小区底噪水平异常升高导致,对该扇区进行干扰扫频分析,发现为用户私装放大器导致。 【关键字】VoLTE高丢包干扰放大器 【业务类别】优化方法 一、问题描述 5月处理VoLTE高丢包小区时,发现该扇区下行空口RTP丢包率(QCI=1)最高达35%,严重影响全网指标和用户使用体验。 图1:MA-市区-东方明珠东北-ZFTA-443809-55小区丢包情况 二、分析过程 对该扇区进行分析,查询该扇区的MR和站间距,该扇区覆盖情况正常,无弱覆盖情况。故对扇区质量进行分析,发现该扇区底噪水平较高,最高达-53dBm。

图2:MA-市区-东方明珠东北-ZFTA-443809-55MR覆盖图 图3:MA-市区-东方明珠东北-ZFTA-443809-55底噪情况

图4:MA-市区-东方明珠东北-ZFTA-443809-55底噪情况 对该问题扇区进行降功率和关断操作,底噪水平无明显变化,将MA-市区-东方明珠东北-ZFTA-443809-55方位角由290度调整到0度后,底噪消失。对周边站点底噪情况进行核查,发现仅仅MA-市区-东方明珠东北-ZFTA-443809-55底噪较高,其他扇区底噪正常。故问题定位为外部干扰导致,初步判断外部干扰如下图所在位置: 图5:初步判断干扰位置 对网管RB噪声水平进行统计,得到干扰波形如下所示,主要干扰前50个RB,尤其对前15个RB最为严重。

精品案例_容量受限导致VoLTE丢包率高分析优化

容量受限导致VOLTE丢包率高分析优 化案例

目录 一、问题描述 (3) 二、分析过程 (3) 三、解决措施 (6) 四、经验总结 (7)

容量受限导致VOLTE丢包率高分析优化案例 【摘要】无线问题导致丢包是影响VoLTE用户感知的关键因素之一,随着VoLTE业务的快速普及、VoLTE用户数和业务量进入了快速上涨期,为更加准确找到全网VOLTE语音感知差点,发现“空口丢包”和“基站弃包”两大关键统计指标可有效表征VoLTE语音感知,减少“空口丢包”和“基站(终端)弃包”是VoLTE语音质量优化提升的重要方向。 【关键字】VoLTE VoLTE上行丢包 【业务类别】参数优化 一、问题描述 日常监控中发现CZ-滁州-乌衣双语小区-ZFTA-435870-53丢包率较高,具体如下: 二、分析过程 1、丢包的原理机制 在基站(或终端)在空口发送PDCP SDU之前,由于容量或空口质量问题, PDCP discardtimer定时器(目前配置为100ms)超时后会发生主动弃包。例如基站调度了序列号为1/2/3/4/5共5个包,而4/5两个包因容量受限或空口质差在100ms内没有被调度出去,基站侧根据认为超过PDCP丢弃时长而主动丢弃,下行弃包率为2/5=40%。 在无线空口,按照协议IP包进一步被转换成PDCP包,PDCP包就是空口传输的有效数据。

PDCP包在终端和基站间传输异常会导致应用层RTP包的丢失,从而引起语音感知差。 2.无线空口丢包主要因素: 影响Volte丢包的因素有故障告警、无线环境、大话务、系统干扰等诸多因素,传输侧链路故障和干扰原因发重传都会大量消耗无线资源,若基站因为传输不及时或缺乏有效的无线资源无法完成对PDCP包的及时调度,会造成基站或终端主动丢弃VoLTE语音包。 针对VoLTE丢包可进行关联分析的指标有: ?无线环境包括TA占比、MR弱覆盖、干扰、RRC重建、切换、邻区漏配等; ?容量包括:PRB利用率、单板利用率、CCE利用率、小区用户数等; 3、处理步骤 1.异常告警及系统干扰核查: 网管核查CZ-滁州-乌衣双语小区-ZFTA-435870-53小区无任何异常告警,查询并统计小区上行干扰指标,系统上行每个PRB干扰噪声平均值为-118(毫瓦分贝),排除干扰原因导致。具体如下: 2.小区无线环境核查: 该小区主要覆盖居民区、学校及广场,该扇区主要覆盖用户距离基站约500米左右,且下倾角、功率设置合理,不存在超远覆盖,符合无线覆盖要求;核查小区MR覆盖率为95%,MR覆盖率波动正常,无线网络指标正常,如下所示:

【干货】典型网络故障案例及处理思路

【干货】典型网络故障案例及处理思路 很多朋友经常提到网络故障,其中在交换机组网时常见的故障比较多。为了便于大家排除这些故障,在此介绍一些常见的典型故障案例及处理思路。 故障1:交换机刚加电时网络无法通信 故障现象 交换机刚刚开启的时候无法连接至其他网络,需要等待一段时间才可以。另外,需要使用一段时间之后,访问其他计算机的速度才快,如果有一段时间不使用网络,再访问的时候速度又会慢下来。 故障分析 由于这台交换机是一台可网管交换机,为了避免网络中存在拓扑环,从而导致网络瘫痪,可网管交换机在默认情况下都启用生成树协议。这样即使网络中存在环路,也会只保留一条路径,而自动切断其他链路。所以,当交换机在加电启动的时候,各端口需要依次进入监听、学习和转发状态,这个过程大约需要3~5分钟时间。

如果需要迅速启动交换机,可以在直接连接到计算机的端口上启动“PortFast”,使得该端口立即并且永久转换至转发状态,这样设备可以立即连接到网络,避免端口由监听和学习状态向转发状态过渡而必须的等待时间。 故障解决 如果需要在交换机加电之后迅速实现数据转发,可以禁用扩展树协议,或者将端口设置为PortFast模式。不过需要注意的是,这两种方法虽然省略了端口检测过程,但是一旦网络设备之间产生拓扑环,将导致网络通信瘫痪。 故障2:5口交换机只能使用4口 故障现象 办公室中有4台计算机,但是只有一个信息插座,于是配置了一台5口(其中一口为UpLink端口)交换机。原以为4台计算机刚好与4个接口连接,1个UpLink端口用于连接到局域网,但是接入到网络之后,与UpLink端口相邻的1号口无法正常使用。 故障分析 UpLink 端口不能被看作是一个单独的端口,这是因为它与相邻端口其实就是一个端口,只是适用的连接对象不同而已。借助UpLink端口,集线设备可以使

网管员掌握丢包排错 两例网络丢包排错案例

远程商业窃密引发丢包 中天设计院是甘肃省建设厅直属单位,网络规模不大。152台主机根据单位职能部门分为5个子网,分别由Hub连接到交换机。由于公司内部的协同办公比较频繁,除了一个在线视频系统外还部署了一台文件服务器,单独为一个子网提供数据的共享和交流。单位对外的Internet需求不是很大,通过路由器连接到Internet,网络拓扑见图1。 故障现象 某天,该单位的网络突然出现严重堵塞,主机间的数据频频中断导致协同办公不能正常进行,在线视频系统经常掉线。另外,无论是从文件服务器上传还是下载文件都异常缓慢,有时会因超时而中断。主机能够连接到Internet,但是网速缓慢。 初步判断 首先在一台主机上用ping命令测试到网关的连通性,输入命令“ping 192.168.2.1 -n 1000”发送1000个Ping包测试网关。测试结果是可以ping通网关,但是掉包现象很严重:1000个包有720个包丢了,丢包率为72%,持续掉包时间也很长。运行arp -a命令,发现网关IP和网关MAC地址指向正确。通过上面的测试基本排除网络设置错误以及ARP欺骗。 监控分析 于是在核心交换机上做镜像,用Sniffer对整个内网(五个子网)进行监控。首先进入“dashboard”(仪表面板),发现网络利用率达到了97%,这是很不正常的现象。笔者判断以该单位的网络规模以及日常业务量,网络利用率应该在20%~30%之间,有较大的网络冗余。这样我们可以断定,造成网络丢包的根源应该是异常流量占用大量的网络带宽所致。那这些异常流量来自何处呢? 切换到“matrix”(矩阵面板),发现MAC为00-0A-E6-98-84-B7的主机占了整个网络流量的57.87%。于是初步把目标锁定在该主机上,然后切换到“hosttable”(主机列表)继续分析。从该面板中,没有发现大量的广播包,因此完全排除了广播风暴影响。找到00-0A-E6-98-84-B7,对此主机分析,发现该主机的网络活动非常可疑,进入该主机的数据包才700多个,而出去的数据包在10多分钟内就有了几十万个包。故障解决为了确认上述主机在进行什么网络活动,笔者在交换机上对它单独抓包分析。对数据包解码后发现,该主机通过UDP协议项向外网的一个IP为60.164.82.185主机进行数据拷贝。这个IP怎么这么眼熟,这不是本地的一个IP吗?另外,还发现该主机与文件服务器的连接也十分频繁。笔者根据网段和MAC地址,在交换机上对该主机隔离,断开其网络连接,整个网络马上就恢复了正常,丢包故障排除。 至此,我们通过层层排错找到了造成这次网络丢包的原因——该主机被黑客植了木马,然后远程控制通过8888端口向远程拷贝文件。另外,该主机正在从文件服务器上下载大量文件,估计攻击者正在通过该主机窃取文件夹服务器上的资料。 该主机本来安装了杀毒软件,但不报毒应该是攻击者做了免杀处理。手工清除木马,将该主机连接到网络,网络丢包再也没有发生。事后机主回忆可能是中了移动硬盘中的木马,因为当天他曾经将工程规划书拷贝到客户的移动硬盘中。丢包排错中引出商业窃密这是大家都没有想到的。 循环自动扫描攻击引起丢包 笔者所在地某中学的局域网约有电脑1000台,通常情况下同时在线的有600台左右,网络一直很稳定。期末放假前网络出现异常,具体症状为:整个校园网突然出现网络通信中断,内部用户均不能正常访问互联网。在机房中进行ping包测试时发现,中心机房客户机对中心交换机管理地址的ping包响应时间较长且出现随机性丢包,主机房客户机对二级交换机的通信丢包情况更加严重。深入分析

案例-某局PING网关丢包分析、解决方案

某局PING网关丢包分析 某局的网管人员最近遇到了奇怪的事情,就是在PING网关的时候时常会出现严重的丢包,却始终无法找到丢包的原因,通过科来技术交流版抓包之后发给我看了一下,我来说一下分析的过程。 首先看到概要之中,发现平均包长只有88.76字节,远远小于正常时候的500-800字节,,再看大小包分布,1024以上的大包没有几个,但是64字节一下的数据包占了将近一半,明显是不正常的,通常小包多的情况,都会伴随有病毒或者攻击的出现。 再来看地址:物理地址数188个,IP地址数69080!差了好几百倍!本地的IP地址数居然有35000多个,实际上该局的主机不超过200台,怎么算都对不上。如此多的地址,那么很有可能是分布式的方式。

再往下看,找到大概的原因了:TCP同步发送高达28161次,但是同步确认发送只有可怜的668个,难道是有蠕虫!我们可以进一步进行分析。DNS查询也高达864次,却没有回应。 打开安全分析界面,来初步确定TCP同步发送的源头在哪儿。 发现了172.16.20.3、21.7、21.224、22.217、22.220、22.71、22.218这几台疑似中了蠕虫病毒,再回到全面分析内,进行取证。 拿20.3来进行观察:

发现了,20.3在不停地使用随机端口对各主机的445端口进行TCP SYN包的发送,每次都只有发送2个数据包,没有回应。这也就导致了大量的TCP SYN包和大量的IP地址的出现。 通过对数据包的解码发现,基本上所有的数据包都是有同步位的数据包。 由此证明,该机中了蠕虫病毒,需要及时查杀。 类似的,在其他几台主机上也发现了蠕虫病毒。这些蠕虫病毒大量的发包,导致了网络的拥塞,使得用户体验就是网速很慢,表现出来的症状就是PING网关大量丢包。

精品案例_高速场景高丢包分析优化

高速场景高丢包分析优化

目录 一、问题描述 (3) 二、分析过程 (3) 三、解决措施 (7) 四、经验总结 (8)

高速场景高丢包分析优化 【摘要】为完成VoLTE百日大会战高速VoLTE语音丢包率考核指标,日常优化分析中发现问题徐明高速丢包率较高,分析优化LOG时发现五河头铺花园附近丢包率较高,通过调整扇区接反,优化邻区,加快切换优化调整,此路段丢包率得到大大改善。 【关键字】丢包率接反 CIO 【业务类别】VoLTE、参数优化 一、问题描述 在进行徐明高速丢包分析时,发现头铺花园附近出现长段高丢包,如下图(左侧路线为丢包率,中间为RSRP,右边为SINR)。 图1:高丢包截图 二、分析过程 1、查询周边小区故障告警,无故障,小区运行正常。 2、进行覆盖分析时发现,头铺花园1,2小区接反,导致BB-五河-头铺花园-HFTA- 440550-50向南覆盖与BB-五河-五河徐明高速18站-HFTA-440612-53小区

MOD 3干扰,SINR质差,疑似导致丢包高。 图2:1小区覆盖截图 图3:2小区覆盖截图 扇区接反调整后,复测丢包情况并未改善,此段丢包非扇区接反导致。3、重新对此段LOG进行分析,发现高丢包路段SINR质差为频繁切换导致,如下 图所示。需重点解决频繁切换问题。

图4:切换详情 三、解决措施 分析LOG发现周边小区BB-五河-五河冯刘-HFTA-440448-52,BB-五河-五河孙坪-HFTA-440398-55,BB-五河-移动西环路大桥4-HFTA-440616-54越区覆盖严重,导致高速上信号复杂频繁切换,优化调整这3个小区越区覆盖,减小对高速覆盖干扰。 由于此路段处于县城高速路口,信号繁杂,无法做到高速路上信号绝对纯净,调整BB-五河-五河徐明高速18站-HFTA-440612-53小区向邻区BB-五河-头铺花园-HFTA-440550-51切换CIO由0调整为3,保证尽快切换至目标小区,减少周边扇区的干扰影响。

2排队时延和丢包

计算机网络设计实验报告 09012211 孙磊 实验二:排队时延和丢包 实验目的 1.深入理解排队时延和丢包的概念 2. 深入理解排队时延和丢包的关系 实验步骤 1、熟悉实验环境 实验之前先要设定好发送速率和传输速率 发送速率可选择350packet/s或500 packet/s 传输速率可选择350 packet/s、500 packet/s或1000 packet/s。 2、设定参数:发送速率为500packet/s传输速率为500packet/s 传输速率等于发送速率时,一般不会发生丢包现象。 3、设定发送速率为500 packet/s,传输速率为350 packet/s 此时,分组一般在路由器缓存中会产生排队现象,从而导致排队时延。由于缓存器容量(队列)是有限的,当到达的分组发现排列队列已满时,将会被丢弃。

4、设发送速率为500 packet/s,传输速率为1000 packet/s 当发送速率比传输速率小得多时,也不会产生排队时延。 实验分析 1. 传输速率等于发送速率时,一般不会发生丢包现象。但当实验的时间较长时,缓存队列偶尔也会发生溢出。 2.到达先后次序不同的分组在分组丢弃和排队时延方面的表现也有所不同。如果有多个分组依次到达一个空队列,那么传输的第一个分组将不会经受任何排队时延,而最后一个分组将经受相对大的排队时延,甚至有可能被丢弃。发送速率和传输速率之间的关系对于分组的丢失和排队时延也起到重要作用,当发送速率小于传输速率时,分组不会有排队时延,更不会丢失;当发送速率等于传输速率时,分组也不会丢失;当发送速率大于传输速率时,分组产生排队时延,队列容量有限,当队列满时,到达的分组就被丢弃。在本实验中,发送方是以恒定的速率发送分组的。在实际网络环境下,发送方通常是依据某种概率分布来发送分组的,这样会导致发送速率比较快时可能发生丢包现象,发送速率慢时不会发生丢包现象。

经典案例_VoLTE丢包优化提升用户感知

PDCP层丢包处理提升VOLTE业务感知 【摘要】随着VoLTE用户规模的提升,网络VoLTE语音质量对网络整体的影响越来越大,影响VoLTE用户感知的一个重要的指标FDD小区上行PDCP SDU丢包率,因而把控该项指标对于VOLTE业务感知具有必要性。 【关键字】VoLTE FDD小区上行PDCP SDU丢包率 【故障现象】 随着4G覆盖逐渐普及,网络技术日趋成熟,中国电信将推进VoLTE成为终端默认语音方案,预计到成熟商用期后,新增终端将会为纯VoLTE,语音全部采用VoLTE模式。 VoLTE技术带给4G用户最直接的感受就是接通等待时间更短,以及更高质量、更自然的语音视频通话效果。VoLTE与2G、3G语音通话有着本质的不同。VoLTE是架构在4G网络上全IP条件下的端到端语音方案。VoLTE相较2G、3G语音通话,语音质量能提高40%左右,因为它采用高分辨率编解码技术。VoLTE为用户带来更低的接入时延(拨号后的等待时间),比3G降50%,大概在2秒左右,而2G时代在6-7秒。对运营商而言,部署VoLTE意味着开启了向移动宽带语音演进之路。从长远来看,这将给运营商带来两方面的价值,一是提升无线频谱利用率、降低网络成本。因为对于语音业务,LTE的频谱利用效率远远优于传统制式,达到GSM的4倍以上。 另一个价值就是提升用户体验,VoLTE的体验明显优于传统CS语音。首先,高清语音和视频编解码的引入显著提高了通信质量;其次,VoLTE的呼叫接续时长大幅缩短,测试表明VoLTE比CS呼叫缩短一半以上。

影响VoLTE用户感知的一个重要的指标FDD小区上行PDCP SDU丢包率。滁州市区的L800M 频段的FDD小区已大量建设且已开通VoLTE功能,现网L800M的FDD小区上行PDCP SDU丢包率2%。 指标定义 该指标定义为高丢包小区与整体小区的占比。 高丢包小区占比=高丢包小区数 整体小区数 ×100% 其中,高丢包小区是指丢包率>1%,且QCI为1的DRB业务PDCP SDU上行期望收到的总包数>1000的小区; 【原因分析】 VoLTE业务的语音包大小固定且具有周期性。每个语音包具有时效性,通话期语音包在空口的传输时延需要小于等于20ms。如果单个语音包在空口的传输时延超出20ms,会造成语音包丢包,影响MOS值和用户体验。 图 1-1 影响Volte丢包的因素有故障告警、无线环境、大话务、传输、核心网、参数等多因素,详细如下:

PING大包丢包网络故障分析案例、解决方案

PING大包丢包故障分析 1.1. 故障描述 1. 故障环境 网络结构如下图所示: 如上图所示,两边网络通过光纤相连,中间设备只有光电转换器,到单位B的内部网络有一台防火墙 2. 故障描述 单位B在进行网络测试时,在单位B的出口路由器处PING单位A的出口路由器时,PING大包会出现丢包现象,但是PING小包正常。 1.2. 故障分析 1. 分析方法 主要通过专有的网络分析工具(科来网络分析系统)将故障时相应的数据包捕获下来进行深度分析,并通过分析发现相应的异常,从而定位故障原因的方法。 2. 部署科来网络分析系统 我们在单位B的光电转换器和路由器之间串连一个交换机,利用交换机的端口镜像功能,镜像两个端口的流量,并将科来网络分析系统部署在交换机的镜像口,如下图所示: 3. 分析数据包 通过故障重现,即在路由器接口处进行PING测试,并同时捕获数据包,得到的数据包如下图所示:

如上图所示,我们在使用大包PING对端时,对端返回了一个超时的数据包,查看它具体的数据包解码,如下图: 造成该故障的原因是因为,我们在网络中传输大包时,由于网络中“最大传输单元”的限制,大数据包会发生分片,当分片数据包都到达目的端时会发生重组,一旦有一个分片丢失就会造成数据报重组超时,所以会发送超时的差错提示。 4. 分析结论 我们在进行PING测试时,数据包只经过了光电转换器和中间链路,所以造成该故障的原因就是光电转换器或中间链路丢包造成的。 1.3. 总结 当我们在分析数据包时,发现通信的数据包中有异常的数据包,那么我们就需要关注它是何种应用的数据包,通过分析异常的数据包可以帮助我们快速的找到故障原因,从而解决故障。

网络丢包经典分析案例

网络丢包,请离我远去 1 网络丢包-烦恼 网络是多种设备的集合体,一个较为完善的网络除去网络终端大量的客户机以外,有众多的设备穿插集中,包括二层交换机、三层交换机、DSLAM、BAS、路由器、服务器、存储设备等。而涉及到的网络协议、技术更为繁杂,要维护这么庞大以及技术复杂的网络,很多时候是雾里看花,总是看不清楚问题的实质,尤其是网络丢包问题,让多少网络专家为之彻夜难眠却又束手无策。本案例汇集了经常遇到的网络丢包案例,希望这些小的案例能够为我们的日常网络维护提供一些启发。 2 网络丢包惨案-案例1 某客户的服务器端局部网络连接图(图中略去了交换机上行连接设备)如下: 两台服务器连在分别连接在S5100交换机的g1/0/3和g1/0/4端口。服务器是第三方网管服务器,两台服务器之间有数据调用。客户反馈访问网管服务器速度很慢,两台服务器之间ping大包时有大量丢包。 网络故障范围已经缩小至两台服务器之间的丢包,问题就变得比较简单,这种情况下,首先确认是故障点,那么我们看两台服务器PING报文的转发流程,总体上可以分为三部分:有两部分是服务器与交换机之间的转发、另外一部分是交换机之间的数据转发。那么要排除该问题我们采取逐段分析排查的方法: 1:首先在两台交换机之间互相Ping各自的管理IP地址,测验结果为不丢包,因此这两台交换机之间的问题可以排除在外; 2:排查服务器与交换机之间问题:这部分的问题又可以细分为三个点:服务器、网线、交换机端口。而这三个点的排查难度是由难到易,因此我们先排查交换机端口的问题; 3:首先更换左端服务器与交换机连接的端口,更换后,丢包问题依然存在,可以排除左端交换机端口的问题,用同样的办法测试右端服务器与交换机端口,依然可以排除交换机端口的问题; 4:那么接下来排查网线的问题,如果是线路的问题,那么在交换机的端口一定会产生大量的CRC错误,那么首先登录到左边交换机上查看端口G1/0/3的状态,没有发现有CRC错误,然后等到右边交换机上

网络丢包现象分析处理指导书一

网络丢包现象是常见的网络故障,但引起丢包的原因却多种多样、千奇百怪。因此对于此类故障的解决,要求处理人员洞悉网络基础理论、了解不同厂家产品特性,有耐心、深入地进行分析定位。”---《网络丢包现象分析处理指导书》摘录 从今天开始,本站将陆续发布系列网络丢包问题分析处理的技术文章。该系列文章来源于《网络丢包现象分析处理指导书》,主要分成三大部分: 第一部分:讲解从产生网络丢包问题的原因来看,网络丢包问题大致可以分为六大类因素,1、网络设备软、硬件问题;2、线路传输质量差引起丢包;3、网络设备配置不合理导致丢包;4、网络设计不合理导致丢包;5、人为攻击、广播泛滥造成的丢包;6、网络环境造成的丢包。对于每类丢包原因配置以大量的案例进行详细的说明。 第二部分:主要有三方面的内容,一是深入剖析网络丢包现象并加以总结;二是网络丢包的一般处理步骤;最后就是讲解网络故障处理中相关工具使用的注意事项。 第三部分:四个故障案例处理过程分析。应该说是对前面两部分内容的一个综合应用。 该系列文章的原始版本是原GW的HB老大当年的手稿,经过与原作者协商,同意在https://www.doczj.com/doc/4e13771798.html,网站上发布。为此非常感谢HB,对HB的无私精神表示深深的感谢。

网络丢包问题往往是没有规律的故障,对于没有固定规律的故障,咱们技术工程师往往有吃力不讨好的痛苦!如本手稿中环境因素导致丢包案例中的电源浪涌,时值北方的冬季,加之故障这个魔鬼出现的时间是晚上7:00-9:00这个时段,现场工程师在用户单元楼道可以用饥寒交迫来形容!在此感谢为本手册付出了无数心血的原GW技术资源部的XDJM,正是他们的加班熬夜,将经历过故障进行总结,才能有今天这份珍贵的手册。 本手册是在原《网络丢包现象分析处理指导书》基础上进行部分的改动,谨此献给所有原GW技术资源部的XDJM,献给那段美好的光阴!献给那段偶们一起共同奋斗的岁月! 网络丢包现象分类:网络设备软、硬件问题导致丢包 首先对出现过丢包的案例进行描述并给出解决办法,同时对丢包问题进行分类,主要加强大家对丢包现象的感性认识。在后续的章节中再做深入的剖析,并提供问题的解决思路。 1、uHammer24百兆光口/电口模块问题 问题描述:uHammer24 芯片为C版且PCB为2.33版的设备百兆端口模块第25口,在高温及常温下会出现严重丢包,高温条件下尤为明显。 C版(PCB v2.33)uHammer24 port 25丢包示意图

经典案例-传输CN2设备拥塞导致用户丢包速率恶化问题定位与处理

传输CN2设备拥塞导致用户丢包速率恶化 问题定位与处理 1 问题描述 自6月30日起,华为区域除武汉外其他地市(恩施、襄阳、宜昌、十堰、荆门、江汉均发现该问题)网速慢投诉量突增,从之前的日均30次提升至57次左右。通过绿网DPI平台对这些地市TCP时延进行分析,发现整网TCP时延趋势随时间变化明显,其中一二次握手时延基本无变化,二三次握手时延变化明显,如下图所示: 图1全网TCP握手时延变化趋势 2 原理介绍 2.1 DPI数据说明 DPI 全称为“Deep Packet Inspection”,称为“深度包检测”。所谓“深度”是和普通的报文分析层次相比较而言的,“普通报文检测”仅分析IP包的层4 以下的内容,包括源地址、目的地址、源端口、目的端口以及协议类型,而DPI 除了对前面的层次分析外,还增加了应用层分析,识别各种应用及其内容。 一般情况下,DPI技术在LTE网络数据的应用可分为3类:基于特征字的识别技术、应用层网关识别技术和行为模式识别技术。

基于特征字的识别技术:现阶段DPI数据解析中最主要的DPI技术,其原理就是不同的业务或应用通常有特殊的“指纹”,这些指纹可能是特定的字符串或者比特流,例如URL就是典型的特征字,依此可以确定该用户业务流承载的具体应用和业务类型; 应用层网关识别技术:部分业务的业务流和控制流是分开的,从业务流中无法找到相应的特征字,所有特征信息及控制流与业务流的关联信息都存在于控制流中,,和这种情况下就使用应用层网关识别技术,其实就是控制流识别技术,受限识别出控制流,从控制流信息中提取出业务流信息,再基于此对业务流进行识别。使用应用层网关识别技术进行包检测的典型协议就是FTP协议。 行为模式识别技术:基于对对终端已经实施的行为的分析,判断出用户正在进行的动作或者即将实施的动作。通常用于无法根据特征字判断的业务的识别。比如路测仪表模拟生成业务流和普通的业务流从内容上看是完全一致的,只有通过对用户行为的分析,才能够准确的识别出路测业务行为。一般可以通过构建包含发送请求的速率、间隔的时延、重复的周期等参数的行为模型来进行识别。 图2 传统IP数据包检测与DPI深度数据包检测 2.2 DPI技术在电信网络的应用 目前运营商在部署DPI设备时一般有两种方式,一种为串联式,即把DPI解析设备串联在业务流的通路上,另一种为并联式,即通过分光器或者路由器镜像的方式。当前中国电信使用的为方式2,将DPI探针部署在S1-U口上,如下图所示:

相关主题
相关文档 最新文档