某企業用戶使用終端訪問企業內網的內部管理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

審核編輯 ：李倩