ZXUN xGW-ToB业务延迟的问题处理

某企业用户使用终端访问企业内网的内部管理APP时，在选择APP内部的相应服务后，发现打开页面非常卡顿，大约持续20 s左右页面才能正常打开，影响用户体验。企业组网如下图所示。

结合客户反馈的问题，进行多次测试，故障现象汇总如下：

a.终端使用TOC卡经公网现路访问APP时延正常。而使用TOB卡在5G专网下，登录APP页面很快，但每次打开里面部分应用时延极大，大约为10~20 s。

b.其余5G专网业务时延正常（AGV小车）。

c.在UPF网元进行抓包测试，发现在终端打开此APP的部分应用期间，出现了超时响应问题，此时APP应用的界面反应极慢。

排查思路

针对打开APP应用或网页反应慢的问题，多数由网络质量不稳定引起，因此需要排查整个转发链路，定位故障点的位置。

1.梳理所有转发路径上可以抓包的点，进行一次抓包测试，目的是在故障复现期间明确各个转发节点的处理报文情况，用于初步分析页面卡顿是丢包还是时延导致。

2.针对第一次抓包的结果再进行抓包，具体定界转发链路有问题的范围。

问题定位

1.测试业务时，在UPF网元进行抓包，根据HTTP报文初步分析，APP提供的URL访问无异常，其中请求报文和响应基本是毫秒级，只有一次达到2 s，如下图所示。

2.通过UPF数据跟踪和UPF业务交换机抓包分析，业务媒体流经UPF并未发生丢包与时延增长。但发现一个现象：终端在进行APP业务中，会不停的新建码流进行DNS查询，如下图所示。

3.由于该企业暂未放通至公网的地址（5G专网数据不出园区，物理隔离），因此该终端发送的所有DNS报文必然不会获得回复，终端在等待DNS查询回复超时后，会再次更换端口进行DNS查询（向114.114.114.114的DNS服务器查询未获得响应，会向180.76.76.76发起DNS请求）。 4.所有查询均失败后，才会继续本地业务。在整个过程中大约查询几十个不同域名，在终端频繁向公网进行DNS查询时，会引入等待时延。

5.经过多次测试及抓包核对，一次业务所消耗在查询上的时间大约为20 s，是终端打开APP业务卡顿的主要原因。

1.终端在查询DNS等待超时后更换端口，再次查询DNS是终端发起的行为，和核心网并无关系，核心网只是接受终端命令的执行者。因此，针对该问题，有以下解决方案：

方案一：需要终端或APP修改公网DNS寻址行为，在实现业务时，不再向公网DNS发送频繁查询的请求。

优点：从根本上解决此问题。

缺点：需要终端应用修改代码，部分厂家不易实现。

方案二：在企业客户侧搭建DNS服务器，配置采用APP自带DNS列表排第一位的IP地址和端口，模拟公网DNS访问及寻址，且能第一时间匹配终端的DNS请求。

优点：能有效解决访问企业内网时延问题。

缺点：需要协调增加服务器或电脑主机资源。

2.每台设备都对流表有一定限制，当流表刷爆后，新流只会在老流老化后才会激活。为了解决流表限制问题，遇到此问题也可以尝试在UPF调整相关流参数，相关命令如下： ADD DIMFLOWCONTOL:DIMFLOWCTLNAME="",DIMFLOWCTLTYPE=,MAXFLOW=600,MAXFLOWPERSEC=200

SET FLOWRATECONTROL:DIMFLOWCTLSWITCH=ENABLE

审核编辑 ：李倩