# APP及协议识别功能的相关需求

| ID | Creation Date | Assignee | Status |
|----|----------------|----------|--------|
| OMPUB-992 | 2023-08-07T18:27:57.000+0800 | 刘洋 | 已关闭 |


---

# TSG 23.01版本之后不再单独发送common_l7_protocol字段，协议和应用程序识别结果在common_app_full_path中统一组织，难以进行区分（如图1所示，common_app_label中填写的最细粒度的识别结果可能为dns等应用层协议）。
为满足不同业务场景下的流量分析需求（如[Application NPM分析|https://www.sandvine.com/hubfs/Sandvine_Redesign_2019/Downloads/2022/Solution%20Briefs/Analytics/Sandvine_SB_Performance%20Monitoring%20Analysis.pdf]，[IP端口/协议画像|https://x.threatbook.com/v5/ip/85.194.197.13]）等，建议应用层协议识别和应用程序识别结果分开提供，或增加类别标识以区分。
!图1-识别为dns.png|thumbnail!
 # common_app_label识别结果的层级关系容易造成困惑，如图2、3出现不同app (qq_web, tencent, tencent_map) 互为父级的情况，图4显示识别的APP粒度不一致（tencent和tencent_map）
!图2.png|thumbnail!!图3.png|thumbnail!!图4.png|thumbnail!**liuyang** commented on *2023-08-14T11:33:22.935+0800*:

计划TSG23.09版本支持，[~yangwei] [~doufenghu]



---

**yangwei** commented on *2023-08-20T20:22:57.151+0800*:

issue中提及两个问题回应如下：
 # 不再提供common_l7_protocol是因为在多种引擎共同识别的前提下，功能端缺乏清晰的对于协议和应用之间的定义边界，如果数据消费方有对“应用层协议识别和应用程序识别结果”的清晰划分需求，建议提供“应用层协议”和“应用程序”的列表供功能端进行划分，或者在大数据处理侧进行预处理
 # 识别结果的层级关系目前是由第三方DPI提供，提供的文档中有更详细的层次关系定义，如果对结果产生困惑，是否考虑组织跟第三方DPI技术支持进行对接？



---

**yangwei** commented on *2023-08-29T10:14:38.012+0800*:

讨论结果如下：

1、参照sandvine applogic的两级分类，在界面展示侧，对appid的属性进行重新划分

2、功能端保持不变，输出完整的app_full_path，由OLAP或者CN对appid根据所属分类进行属性填充，例如dns的分类为infrastructure protocol.OtherContent

!image-2023-08-29-10-09-32-436.png|width=552,height=276!



---



## Attachments

**43630/image-2023-08-29-10-09-32-436.png**

---

**42428/图1-识别为dns.png**

---

**42431/图2.png**

---

**42430/图3.png**

---

**42429/图4.png**

---