基于知识图谱的协议转换方法研究

林映利 李红辉,2* 张 春,2 闫佳和 王梓博

1(北京交通大学计算机与信息技术学院 北京 100044)

2(高速铁路网络管理教育部工程研究中心 北京 100044)

互联网＋政务大数据来源于多种异构信息。一种政务应用场景往往涉及多种不同来源的信息，如在城市外围或地质灾害多发地区布置地质灾害监测传感器，采集监测数据并传输到应急指挥中心，从而实现地质灾害实时动态监测和预警。在信息采集与传输的过程中，涉及物联网多传感器多协议间的数据传递。

信息来源不同，信息传输协议也不同，互联网＋政务大数据呈现跨领域、多协议、难融合的特点。在大数据采集汇聚过程中，存在多种协议转换的需求。因此，要求网关能够实现统一协议适配转换，为异构数据关联和数据融合提供数据支持。

在传统协议转换研究方面，宗娜[1]和 Zhou等[2]研究了实现 HTTP 协议与 CoAP 协议转换的理论与方法；
赵小虎等[3]设计了面向煤矿井下的多协议融合网关，实现了 CAN、ZigBee 等协议到以太网协议的转换。在通用协议转换研究方面，Saito 等[4]提出一种物联网的应用协议转换方法，并制定了转换规则的语句和语法。

传统的协议转换方法通常针对特定的协议转换需求设计的，对于新的协议转换需求，需要重新设计新的协议转换方法。在不同的政务应用场景中，传统的协议转换方法并不能灵活满足多种协议转换的需求。

知识图谱是人工智能领域的重要分支技术，最早由谷歌公司于 2012 年提出。知识图谱按应用场景可分为通用知识图谱和领域知识图谱两大类[5]。其中，领域知识图谱以领域专业知识为主，不同领域知识图谱的构建与应用已有较多研究成果。在医学领域，张德政等[6]将知识图谱应用于中医知识领域，构建了中医核心知识图谱；
杨帅等[7]针对 COVID-19 构建了科学文献、中西药治疗等知识图谱，实现了知识图谱的融合。在网络安全领域，廉龙颖[8]和 Wang 等[9]分别构建了网络空间安全知识图谱和网络安全社会工程领域知识图谱，为网络安全分析与信息检索提供了依据。而在协议知识领域，协议知识图谱的相关研究较少。徐健[10]基于知识图谱构建了 5G 协议知识库，以解决 5G 协议知识面广、不易高效查询等问题。以字段为实体、字段映射关系为实体间关系构建知识图谱，可以体现协议转换过程中报文字段间的映射关系。但在协议转换领域，暂无协议转换相关知识图谱的研究。

本文拟通过研究协议报文结构及协议转换特点，提出一种协议转换知识图谱的构建方法。通过构建图谱的模式层及数据层，建立含有协议报文结构和报文字段映射关系的协议转换知识图谱。在此基础上，提出一种基于知识图谱的协议转换方法，以实现不同协议之间的报文转换，并通过协议转换应用实例、与已有协议转换方法的对比实验，验证本文方法的有效性。

2.1 知识图谱相关研究

知识图谱由知识及知识之间的关系组成[11]，其基本组成单位是“实体-关系-实体”三元组及“实体-属性-属性值”实体与属性值对。知识图谱能够将不同种类的信息连接，形成关系网络，提供从“关系”的角度分析问题的条件[12]。

知识图谱按应用场景可分为通用知识图谱(Universal Knowledge Graph，UKG)和领域知识图谱(Domain Knowledge Graph，DKG)。UKG 以百科知识图谱、常识知识图谱为主。常见的百科知识图谱有 DBpedia、YAGO、Freebase、Wikidata 等，常识知识图谱有 Cyc、ConceptNet、NELL 等[13]。DKG 以各领域的专业知识为主，典型的应用场景有国防、金融、公安、工业、医疗等。如在医疗领域，CPubMed-KG[14]是目前国内最大的全开放中文医学知识图谱，以疾病为中心的三元组规模达到了 390 万；
在网络安全分析领域，CyberTwitter[15]是用于发现和分析 Twitter 的网络安全情报，其作为一个开放情报来源，以 tweet 的形式分析实时信息并进行更新，提取关于各种可能威胁的情报；
但在通信协议领域，协议相关知识图谱研究和应用较少。

知识图谱的构建技术包括知识抽取、知识融合、知识加工和知识更新等。其中，知识抽取是构建知识图谱的关键技术之一，包括实体识别、关系抽取和属性抽取。目前，在实体识别方面，主流方法是基于神经网络的命名实体识别。Li 等[16]提出了基于 BERT-BiLSTM-ATT-CRF 模型的中文命名实体识别方法，且性能较好；
谢腾等[17]提出了一种基于 BERT-BiLSTM-CRF 模型的中文实体识别方法。目前，命名实体识别(Named Entity Recognition，NER)常用的模型有BERT-CRF、BiLSTM-CRF 等。

2.2 协议转换相关研究

当使用不同协议的设备进行通信和数据交换时，需要进行协议转换。现有的协议转换方法可分为两种：具体的协议转换方法和通用的协议转换方法。因协议转换的多样性与复杂性，协议转换研究领域针对具体的协议转换方法的研究较多。例如，针对以太网 HTTP/HTTP2 协议与物联网 CoAP 协议间的转换，宗娜[1]与 Zhou 等[2]分别进行了相应的转换代理和互通特性的研究；
为克服物联网多协议领域的差异问题，Zainudin等[18]研究了一种多协议网关，以实现物联网中CoAP、MQTT 和 Websocket 的多协议域之间的通信。但上述协议转换方法都是针对具体协议具体转换设计的解决方案，适用场景单一，所支持的协议转换类型和转换方式无法更改[19]，程序不可扩展、泛化性差，无法满足政务大数据采集汇聚过程中的灵活需求。

目前，通用的协议转换方法的研究较少。Saito 等[4]提出一种物联网的应用协议转换方法，根据转换规则，将协议报文转换为 Middle format，从而实现 CoAP、MQTT、XMPP 和SMTP 等物联网应用层协议间的互相转换。Saito等提出的基于规则的协议转换，将各协议与Middle format 的映射关系体现在规则中，随着协议数量的增加，不同协议转换为 Middle format的规则也相应增加。

苗力心[19]结合软件定义思想，将协议转换研究重心下移至物理链路层，提出了基于通用描述符的协议转换方法。通过构建与所有异构协议存在映射关系的协议映射元作为协议转换的中间级，并存储协议关键字段与映射元的映射关系。该协议映射元方法需为每个字段构建一个映射关系表，当系统内有n种协议时，需构建k×n个映射表，其中，k为协议中关键字段的数量。

上述通用协议转换方法将协议信息转换为中间格式，用规则文件或映射关系表存储不同协议字段与中间格式的映射关系，其规则文件或映射关系表会随着新协议的加入而增加。而本文提出的基于知识图谱的协议转换方法，将字段作为实体，通过实体间的关系可直接体现不同协议字段间的映射关系，无须将协议转换为中间格式。协议间的映射关系通过知识图谱进行存储，可在原知识图谱的基础上，增加新的协议转换映射关系，从而对协议转换知识图谱进行扩展与更新。

3.1 构建目的与方法

本文从 HTTP 与 CoAP 的转换着手，针对应用层协议的转换进行研究。应用层协议报文一般由头部字段和可选的数据负载组成。协议转换是在保证报文功能不变的情况下，进行两种不同协议报文之间字段信息的等价转换。因此，协议转换知识图谱应该以字段为主要实体，以字段间的关系体现协议间的转换映射。

知识图谱的逻辑结构由模式层和数据层组成。模式层是知识图谱的核心层次，其位于数据层之上，作为构建知识图谱的实体及关系的知识框架。数据层存储具体知识，以“实体-关系-实体”三元组及“实体-属性-属性值”实体与属性值对作为知识的基本表达方式。

协议转换所需知识大多来源于协议相关文档，对相关知识的专业性和准确性要求较高。本文采用自顶向下的方式构建协议知识图谱。首先，确定协议本体的设计范围，根据协议转换的知识和经验设计协议本体，构建知识图谱模式层，所构建的模式层为知识图谱提供了数据框架。然后，从数据源中提取实体，根据数据框架确定实体间关系，构建得到知识图谱数据层。所构建的数据层为知识图谱的主要组成部分。协议转换知识图谱的构建方法如图 1 所示。

图1 自顶向下的协议知识图谱构建方法Fig. 1 Up-to-down construction method of knowledge graph of protocol

3.2 协议本体设计

本体侧重于概念及其相互关系之间的形式化表达，不涉及具体的实体与属性。协议本体架构作为协议知识图谱的知识框架，即协议知识图谱的模式层，规范了实体对象间的关系。为构建知识图谱的模式层，需确定协议本体的设计范围。协议转换涉及两个不同协议间报文信息的交换，本体类别层次结构应考虑协议、报文、字段以及负载数据等概念。

3.2.1 协议本体类设计

基于协议核心概念，设计出 5 个核心类：Protocol，Message，Fields，Value，Payload Data。核心类还可进一步细化出更多的子类。本体中类的部分层次结构如图 2 所示。

图2 本体类别层次Fig. 2 Hierarchy of classes in ontology

Protocol 类用于描述协议转换知识图谱当前可支持的协议；
Message 类用于描述协议拥有的报文类型，其中报文类型根据报文结构进行划分；
Fields 类用于描述报文中包含的字段，Fields类实例之间的映射关系是协议转换的核心之一；
Value 类用于描述字段取值，某些字段可能拥有多个固定取值。在协议转换的过程中，Value 类的实例之间可能存在映射关系；
Payload Data 类用于描述报文中的负载数据信息。

3.2.2 协议本体属性设计

本体类的属性可分为对象属性与数据属性。对象属性用于描述类与类之间的关系，本文设计了 8 种协议核心概念之间的关系，8 种协议本体的对象属性设计如表 1 所示。由表 1 可知，协议本体的对象属性需体现两个方面：

表1 定义类的对象属性Table 1 Defines the object properties of the class

(1)核心概念间的包含关系。如 Protocol 类与 Message 类之间可建立“has_message”的对象属性，表示协议拥有哪些报文类型；
Message类与 Fields 类之间可建立“has_field”的对象属性，表示该报文与字段的包含关系。

(2)不同协议间转换的映射关系。如 Message类的内部可建立“message_mapping” (报文映射)的对象属性，表示不同协议间报文的映射关系；
Fields 类的内部可建立“direct_mapping”(直接映射)和“indirect_mapping”(间接映射)，表示协议转换时不同协议字段间的直接映射、间接映射关系。

数据属性用于描述类的内部属性，针对 5个核心类，本实验分别设计了相应的数据属性如表 2 所示。

表2 定义类的数据属性Table 2 Defines the data properties of the class

3.2.3 协议本体架构

通过定义协议本体类、类的对象属性与数据属性，可最终得到协议本体。协议本体类与类的对象属性组成了协议本体架构，如图 3 所示。将协议本体架构作为协议知识图谱的模式层，规范了不同类的实体对象间的关系，如Protocol 类的实例与 Message 类的实例间可建立“has_message”关系；
Message 类的实例之间可建立“message_mapping”关系；
Fields 类的实例之间可建立“direct_mapping”或“indirect_mapping”关系。

图3 协议本体架构Fig. 3 Protocol ontology architecture

3.3 协议知识抽取

协议转换相关知识主要来源于协议标准文档、协议转换标准文档及相关网页搜索结果等。本文构建协议知识图谱采用的数据属于半结构化数据和非结构化数据，部分数据来源如表 3所示。

表3 数据来源Table 3 Data sources

对于半结构化数据，采取 Request＋Xpath的方式，从 web 页面中提取；
对于非结构化数据，利用 label studio 对数据进行实体标注，选择 BiLSTM＋CRF 模型进行实体抽取。以 HTTP和 CoAP 协议为例，实体抽取的数据集如表 4 所示。本文对相关数据进行实体抽取，最终得到相关实体 1 079 个，将提取到的实体匹配填充到协议本体中，作为本体实例。

表4 协议实体数据集Table 4 The dataset of the protocol entity

3.4 知识图谱构建实现

由于 Protégé 用于数据分析和可视化的功能有限，而 Neo4j 可便捷地检索、遍历、导航连接数据，且 Neo4j CQL 易于阅读和学习，因此，本文采用基于图模型的 Neo4j 数据库作为数据存储层。将提取的实体及实体间的关系等数据信息整理成结构化数据，以三元组的形式存储在 CSV文件[24]中，并调用 py2neo 库将 CSV 文件数据存入 Neo4j 数据库中。

以 HTTP 与 CoAP 在协议转换知识图谱中的部分映射关系为例，图谱可视化如图 4 所示，节点颜色的图例在图中左上角。图 4 展示了HTTP、CoAP 及其部分字段、报文、值等实体和实体间的关系，如 HTTP 中的“status-code”字段实体与 CoAP 中的“code”字段实体存在“indirect_mapping”关系，“status-code”字段的值“201”与“code”字段的值“2.01”存在“value_mapping”关系。

图4 协议转换知识图谱(示例)Fig. 4 Knowledge graph of protocol conversion(example)

4.1 基于知识图谱的通用协议转换框架

如图 5 所示，基于知识图谱的通用协议转换框架由知识层和转换层组成。其中，转换层负责将接收到的协议报文转换成另一种协议的报文，包括报文解析、协议转换及报文生成等步骤，该协议转换过程需要知识层提供相关知识，以辅助实现协议转换；
知识层由协议转换知识图谱组成，协议转换知识图谱以协议标准文档等作为数据源，存储各协议报文结构、字段信息和字段间映射规则等知识，该层负责为转换层提供知识、数据支撑。

图5 基于知识图谱的应用层协议转换框架Fig. 5 Application layer protocol conversion model based on knowledge graph

4.2 基于知识图谱的协议转换方法

本节将介绍一种基于知识图谱的协议转换方法。为方便描述，本文将被转换的报文称为原报文，原报文对应的协议称为原协议，转换后得到的报文称为目标报文，目标报文对应的协议称为目标协议。

4.2.1 转换流程设计

协议转换流程如图 6 所示，接收到原报文后，首先，通过解析得到含原报文信息的 JSON数据；
然后，对 JSON 数据中的字段进行映射，得到对应的目标报文字段以及字段值，对目标报文剩下的固定字段进行缺省值补全，得到含有目标报文信息的 JSON 数据；
最后，根据含有目标报文信息的 JSON 数据生成目标报文并发送。

图6 协议转换流程Fig. 6 Process of protocol conversion

4.2.2 数据格式设计

在网关上进行协议转换，网关接收原报文后，解析得到原报文字段值和负载数据(若报文存在负载数据)等原报文信息，将原报文信息以JSON 格式进行保存。其中，储存协议报文信息的 JSON 数据格式由协议名称键值对、字段与值的键值对及可选的切分标记键值对、负载数据键值对组成，具体内容如下：

4.2.3 协议转换方法设计

协议转换实现方法的具体步骤如下：

(1)原报文解析

网关接收原报文并对其进行解析，得到原报文字段值等原报文信息后，按照规定的 JSON 格式进行保存。

(2)原协议与目标协议的映射

在协议转换知识图谱中，若原报文的类型与目标报文的类型存在“message_mapping”关系，则原报文与目标报文之间的转换成立，原协议字段与目标协议字段间可能存在两种映射：“direct_mapping”与“indirect_mapping”。

对于原协议字段与目标协议字段，若存在直接映射关系，则其原协议字段值即目标协议字段值，如图 7 所示；
若存在间接映射关系，则其字段值之间存在“value_mapping”(值映射)关系，由原协议字段值可以得到对应的目标协议字段值，如图 8 所示。

图7 字段间直接映射关系Fig. 7 Direct mapping between fields

图8 字段间间接映射关系Fig. 8 Indirect mapping between fields

由协议转换知识图谱可知目标协议的最大负载信息。若原报文存在负载，且实际负载小于目标协议最大负载，则原报文负载即目标协议报文负载。同理，若实际负载大于目标协议最大负载，则按照目标协议最大负载的大小，将原报文负载切割成多段，分别作为目标报文负载。

从国内看，多线多梯级船闸联合调度管理做得比较好的主要有长江干线和京杭运河苏北段。其中长江干线三峡、葛洲坝船闸（升船机）由长江三峡通航管理局统一管理，按照建立的两坝通航“统一调度、联合运行”调度体系，采取“一次申报、统一计划、分坝实施”的调度程序，对通过三峡、葛洲坝船闸（升船机）的过往船舶实现统一的指挥、调度管理。京杭运河苏北段10个梯级、28座船闸是由苏北航务管理处统一管理，通过船闸智能运行系统，实现智能排档、优化闸次、全线联合调度。水上ETC，“一票通”、“船迅通”APP的运用，实现了船岸信息互通、远程报到、快速缴纳过闸费、“一次登记、全程服务、无缝调度”的过闸服务。

(3)目标报文生成

根据协议转换知识图谱中字段间的映射关系，可以得到目标报文中与原协议有映射关系的字段与字段值。但一般情况下，原报文字段与目标报文字段并非都存在映射关系，仅通过字段映射得到的目标协议报文信息并不完整。因此，需在协议转换知识图谱中，查询该目标协议报文中所有字段属性为固定字段的字段，检查目标协议报文信息中是否包含所有固定字段，若缺少某固定字段，则将其缺省值作为字段值，补充相应键值对。由此可以得到含有目标报文信息的 JSON数据，网关根据其携带的目标协议报文信息生成目标报文并发送。

5.1 HTTP 客户端与 CoAP 服务器的通信过程

实现协议转换的网关等同于原协议服务器，负责接受来自原协议客户端的请求，并作为目标协议的客户端，将请求发送至目标协议服务器；
或等同于原协议客户端，接收原协议服务器的响应，并作为目标协议的服务器，将响应发送至目标协议客户端。

以 HTTP 协议与 CoAP 协议的转换为例。首先，HTTP 客户端向网关发送 POST 请求，网关将 HTTP 请求报文转换为 CoAP 协议报文，并发送给 CoAP 服务器；
然后，CoAP 服务器向网关发送 CoAP 响应，网关将 CoAP 协议报文转换为HTTP 响应报文，并发送给 HTTP 客户端。在上述过程中，CoAP 端均采用 CON 模式进行传输。HTTP 客户端通过网关与 CoAP 服务器通信的过程如图 9 所示。

图9 HTTP 客户端与 CoAP 服务器通信过程Fig. 9 Communication between HTTP client and CoAP sever

5.2 协议转换过程

基于知识图谱的协议转换算法流程图如图 10所示。

图10 基于知识图谱的协议转换算法流程图Fig. 10 The flow chart of protocol conversion algorithm based on knowledge graph

将 HTTP 请求报文转换为 CoAP 报文的过程如下：

(1)HTTP 请求报文解析

从 HTTP 客户端接收报文后，解析得到由协议类型的键值对、字段名与字段值的键值对和负载键值对组成的 HTTP 请求报文信息的 src.json。HTTP 请求报文示例与解析结果如图 11 所示。

图11 HTTP 请求报文与解析结果Fig. 11 HTTP request message and parsing result

(2)HTTP 到 CoAP 的映射

分别查询该 HTTP 请求报文中的字段与目标协议 CoAP 的字段，是否存在直接映射或者间接映射的关系。例如，Content-Type 字段与 Content-Format 选项存在间接映射关系，Content-Type 字段的值为“text/plain”，值映射后得到 Content-Format 选项的值为“text/plain;charset=utf-8”。由协议转换知识图谱可知CoAP 的最大负载信息，若 HTTP 请求报文负载小于 CoAP 的最大负载，则 HTTP 请求报文负载即为 CoAP 报文负载；
若 HTTP 请求报文负载大于 CoAP 的最大负载，则将原负载内容按 CoAP最大负载的大小切割成多段，分别作为 CoAP报文负载。HTTP 到 CoAP 的映射结果如图 12所示。

图12 HTTP 到 CoAP 的映射结果Fig. 12 Mapping result of HTTP to CoAP

(3)CoAP 报文生成

查询该 CoAP 报文中所有字段属性为固定字段的字段。若缺少某固定字段，则将其缺省值作为字段值，补充相应键值对，得到含有 CoAP 协议报文信息的 dst.json。如转换后的中间结果缺少 CoAP 的 Ver 字段，其缺省值为 1，补全后得到协议转换结果如图 13 所示。根据解析 dst.json得到的 CoAP 报文信息，生成 CoAP 报文并发送给 CoAP 服务器。

图13 协议转换结果Fig. 13 Protocol conversion result

5.3 性能评估

5.3.1 实验环境

通过分析 HTTP 与 CoAP 协议转换执行时间与内存占用，对本文方法进行性能评估，实验环境如表 5 所示。

表5 实验环境Table 5 Experimental environment

5.3.2 实验过程设计

从接收 HTTP 客户端请求到返回请求响应为一个协议转换周期。HTTP 客户端分别执行 100次 PUT、GET、POST 请求，统计实验过程中周期平均执行时间、最大执行时间、最小执行时间，并统计每个周期中 HTTP 请求转换为 CoAP请求和 CoAP 响应转换为 HTTP 响应的平均执行时间、最大执行时间、最小执行时间。执行时间通过 Wireshark 抓取到的每个周期 HTTP、CoAP协议的请求报文和相应响应报文时间之间的差值进行计算。

通过使用 python 第三方库 memory_profiler，监控 HTTP 客户端连续发送 PUT 请求时转换程序的内存占用情况。由 memory_profiler 生成内存占用随时间变化的曲线图，可直观地观测到协议转换程序的内存占用情况。

5.3.3 实验结果及分析

(1)执行时间

协议转换执行时间的统计结果如表 6 所示，协议转换周期的平均执行时间约 32 ms，最小执行时间约 17 ms，最大执行时间＜48 ms；
HTTP 请求转换为 CoAP 请求的平均执行时间＜6 ms，最小执行时间约 4 ms，最大执行时间＜20 ms；
CoAP响应转换 HTTP 响应的平均执行时间约 27 ms，最小执行时间约 12 ms，最大执行时间＜33 ms。

表6 协议转换平均、最大、最小执行时间Table 6 Average, maximum, minimum execution time of protocol conversion

宗娜[1]给出了 HTTP 与 CoAP 转换代理实现100 次 GET、POST 请求的平均执行时间，其与本方法实现 HTTP 与 CoAP 协议转换周期的平均执行时间的对比如表 7 所示。由表 7 可知，本方法所实现的 HTTP 与 CoAP 的协议转换用时更少，转换效率更高。84.59%，HTTP 请求转换为 CoAP 请求的平均执行时间占总转换执行时间的 17.02%、15.12%、15.41%。CoAP 响应转换为 HTTP 响应的过程中，调用 HTTP 相关外部库进行报文的发送，占用了大量时间，导致 CoAP 响应转换 HTTP 响应的平均执行时间占比较高。

表7 平均执行时间对比Table 7 Comparison of average execution time

图14 请求与响应的平均执行时间占比Fig. 14 Proportion of average execution time of requests and responses

(2)内存占用情况

协议转换程序执行过程中内存占用变化情况如图 15 所示。由图 15 可知，程序开始执行时，内存占用首先上升至 80 MiB 左右，随着请求次数的增加，内存占用最终保持在 90 MiB 左右，占系统总运行内存的 0.55%。由此可知，运行协议转换程序对于系统内存的占用不高，系统性能良好。

图15 协议转换程序内存占用情况Fig. 15 Memory usage of protocol conversion

互联网＋政务大数据来源于多种异构信息，具有跨领域、多协议、难融合的特点。在大数据采集汇聚的过程中，存在多种协议转换需求，需要网关实现统一的协议适配转换。本文提出了一种协议转换知识图谱的构建方法，建立含有协议报文结构和报文字段映射关系的协议转换知识图谱。并在此基础上，提出了一种基于知识图谱的协议转换方法，以实现不同协议之间的报文转换。

在协议转换研究领域，基于知识图谱的协议转换是一个较新的研究方向。将知识图谱、协议转换等作为关键词，在 CNKI、Google Scholar、IEEE 等数据库中进行搜索，发现国内外暂无类似研究成果和参考文献。

本文对协议的结构层级进行研究与分析，依据含义将其划分为 5 类核心概念：Protocol、Message、Fields、Value 和 Payload Data，并依此设计了协议本体。本文提出的基于知识图谱的协议转换方法，可在已有的协议转换知识图谱的基础上，增加新协议的报文字段信息与新的协议转换映射关系，对协议转换知识图谱进行扩展与更新，具有良好的泛用性和可扩展性，能够灵活适应多种应用层协议转换需求。在协议转换执行时间与内存占用方面，将本文提出的方法与现有案例方法进行性能测试与评估分析，验证了本文方法的有效性。但本文仍存在以下不足：(1)解析与生成报文受到具体程序实现的限制；
(2)缺少对应的成熟数据集，图谱构建较为困难。

本文创新性地提出了一种协议转换知识图谱的构建方法和一种基于知识图谱的协议转换方法。这些方法基于 HTTP、CoAP 协议转换，可能存在一定的局限性，未来将研究更多的应用层协议的报文结构与映射关系，以完善协议转换知识图谱，并对利用协议转换知识图谱解析和生成应用层协议报文开展相关研究。

猜你喜欢字段报文本体基于J1939 协议多包报文的时序研究及应用汽车电器(2022年9期)2022-11-07图书馆中文图书编目外包数据质量控制分析江苏科技信息(2022年16期)2022-07-17CTCS-2级报文数据管理需求分析和实现铁道通信信号(2020年4期)2020-09-21浅析反驳类报文要点中国外汇(2019年11期)2019-08-27基于本体的机械产品工艺知识表示制造业自动化(2017年2期)2017-03-20ATS与列车通信报文分析铁道通信信号(2016年8期)2016-06-01《我应该感到自豪才对》的本体性教学内容及启示文学教育(2016年27期)2016-02-28CNMARC304字段和314字段责任附注方式解析图书馆建设(2015年10期)2015-02-13无正题名文献著录方法评述新世纪图书馆(2014年7期)2014-09-19">关于CNMARC的3--字段改革的必要性与可行性研究
图书馆建设(2014年3期)2014-02-12