一种5G核心网HTTP2头部压缩解码的方法

技术领域

本发明属于通信技术领域，具体涉及一种5G核心网HTTP2头部压缩解码的方法。

背景技术

HTTP2.0是在SPDY基础上形成的下一代互联网通信协议，其目的是通过支持请求与响应的多路复用来减少延迟，通过压缩HTTP2头字段降低协议开销，同时增加请求优先级和服务器端推送的支持。5G核心网适应网络发展，以HTTP2为核心协议，在提高了网元交互能力的同时，HTTP2的头压缩对核心网信令的解析也提出了很大的挑战。

HTTP1.x的无状态特性导致巨大HTTP头部，由于报文HEADER一般会携带"UserAgent"、"Cookie"、"Accept"、"服务端"等许多固定的头字段，多达几百字节甚至上千字节，同时，成千上万的请求响应报文里有很多字段值都是重复的，非常浪费，在一定程度上增加了传输的成本。故此，HTTP2采用HPACK算法，通过维护一张静态表和一张动态表来对HTTP2的头部进行压缩。其中，静态表用来建立一些常见的头部名称，以及特别常见的头部名称与值的组合的索引；动态表则用于在客户端和服务器两端建立“动态索引”，用索引号表示重复的字符串，还采用哈夫曼编码来压缩整数和字符串，可以达到50％～90％的高压缩率。

HTTP2的头部压缩方案大大提供了传输效率，但是却给5G核心网的信令解析提出了挑战，因为获取不到动态索引号和相应字符串的对应关系，将没有办法对码流里传输的信令内容做正确解析。

发明内容

鉴于上述的分析，本发明旨在公开了一种5G核心网HTTP2头部压缩解码的方法，用于实现对核心网接口的HTTP2协议进行实时动态头解压缩，完成协议解析，提高现网的解压缩成功率。

本发明公开了一种5G核心网HTTP2头部压缩解码的方法，包括：第一解压缩方法和第一解压缩方法；其中，

第一解压缩方法；通过对采集到的完整HTTP2动态头部压缩协商数据，进行TCP流管理和HTTP2消息重组，经过查询和创建解码上下文得到静态表和动态表；根据头部字段模式在静态表和动态表中查询解码HTTP2头部字段，保存解码结果；

第二解压缩方法；对于获取不到动态索引号和相应字符串的对应关系的HTTP2动态头部压缩协商数据，通过修复动态表的方式，在动态表中可能存在问题的表项区间中插入空表项目后，再采用新的动态表进行解码，直到解码出来信息与根据3GPP协议规范推导出来的信息不冲突后，保存解码结果。

进一步地，第一解压缩方法中TCP流管理的IP分片重组中，根据分片报文的四元素结合一个随机数RAND计算一个哈希值，然后根据所述哈希值去查找分片队列，查找到分片队列后把IP报文插入分片队列，如果所有分片报文都集齐了则开始重组生成完成的IP报文；如果一直都无法集齐的话，这个分片队列内存就会被垃圾回收定时器回收。

进一步地，第一解压缩方法中TCP流管理的TCP乱序重传处理，包括：

1)按照四元素维护TCP流；所述四元素为源IP地址+目的IP地址+源端口+目的端口；

2)TCP流维护下一个TCP数据包的SEQ；

3)比较当前的数据包的SEQ和TCP流需要的下一个数据包的SEQ；

如果等于：表明正常，直接输出改TCP数据包；

如果小于：表明出现重传，直接丢弃该TCP数据包；

如果大于：表明出现乱序，缓存该TCP数据包，由于采集可能出现丢包，需要定义缓存数据包的大小，超过缓存限制后认为丢包，直接从缓存数据包中选择SEQ值最小的TCP数据包输出。

进一步地，第一解压缩方法中HTTP2消息重组，按照源IP地址+目的IP地址+源端口+目的端口维护TCP流，并从TCP流中切分出一个一个完成的HTTP2消息包。

进一步地，第一解压缩方法中采用FIFO算法维护动态表；在维护动态表时，

插入动态的顺序为后续该表项的索引；

对已有的表项不能修改；

只有消息中“01”头字段模式的IE字段才能插入动态表项到动态表。

进一步地，第二解压缩方法中，动态表的修复中，动态表项能够插入动态表的中间，判断已存在的表项目需要修改时，对所述表项目进行修改。

进一步地，第二解压缩方法中，动态表的修复中，插入只有ID的空条目，没有头字段名或者头字段值，用于同步核心网元与头部压缩解压程序对动态表的插入。

进一步地，第二解压缩方法中，通过HTTP2的HEADER+DATA+3GPP协议规范得到DATA的消息类型，进行动态表内容的推导；并通过HTTP2的响应+3GPP协议规范得到响应的消息类型和响应的结构，推导出部分动态表内容。

进一步地，第二解压缩方法中，根据3GPP文档对在HEADER中的服务操作和在DATA中操作携带的信息存在的强约束；通过DATA携带的信息推导出HEADER中确定携带的大部分信息；利用推导出来的HEADER中携带的信息与依赖动态表解码出来的信息做对比分析，当推导出来的需要携带的信息与动态表解码出来的信息出现冲突时启动修复机制，利用推导出来的信息修复动态表。

进一步地，动态表修复的过程包括：

1)缓存动态表；

2)判断解码出来信息与根据3GPP协议规范推导出来的信息是否冲突；是则进入3)，否则进入步骤7)；

3)恢复缓存的动态表；

4)分析动态表内容，确定出冲突发生的动态表表项区间；

5)在动态表可能的位置插入空白项，生成新的动态表；

6)用新的动态表再次对当前数据包解压缩；返回步骤2)进行判断；

7)使用修改后的动态表作为最新的动态表。

本发明可实现以下有益效果：

本发明公开的5G核心网HTTP2头部压缩解码的方法，考虑到现网的实际环境及采集方式，在HTTP2头部压缩的协商过程被完整采集到，按照RFC标准进行头压缩解码；在没有被完整采集到时，考虑到TCP长连接的情况，对按照RFC标准进行头压缩解码的方式进行补充和升级，利用码流中的其他特征字结合3GPP规范、及5G核心网的业务场景，大大地提高了现网的解压缩成功率。

附图说明

附图仅用于示出具体实施例的目的，而并不认为是对本发明的限制，在整个附图中，相同的参考符号表示相同的部件。

图1为本发明实施例中的5G核心网HTTP2头部压缩解码的方法流程图；

图2为本发明实施例中的第一解压缩方法流程图；

图3为本发明实施例中的TCP流管理的处理逻辑流程图；

图4为本发明实施例中的对TCP乱序重传的处理逻辑流程图；

图5为本发明实施例中的对HTTP2消息重组的处理流程图；

图6为本发明实施例中的HTTP2的流状态示意图；

图7为本发明实施例中的动态表修复过程流程图。

具体实施方式

下面结合附图来具体描述本发明的优选实施例，其中，附图构成本申请一部分，并与本发明的实施例一起用于阐释本发明的原理。

本发明的一个实施例公开了一种5G核心网HTTP2头部压缩解码的方法，如图1所示，包括：

步骤S1、第一解压缩方法；通过对采集到的完整HTTP2动态头部压缩协商数据，进行TCP流管理和HTTP2消息重组；再经过查询和创建解码上下文得到静态表和动态表；根据头部字段模式在静态表和动态表中查询解码HTTP2头部字段，保存解码结果；

步骤S2、第二解压缩方法；对于获取不到动态索引号和相应字符串的对应关系的HTTP2动态头部压缩协商数据，通过修复动态表的方式，在动态表中可能存在问题的表项区间中插入空表项目后，再采用新的动态表进行解码，直到解码出来信息与根据3GPP协议规范推导出来的信息不冲突后，保存解码结果。

具体的，如图2所示，第一解压缩方法包括：

S101、TCP流管理；

S102、HTTP2消息重组；

S103、查询解码上下文；

S104、创建解码上下文；

S105、解码Encoder HEADER。

具体的，S101中的所述TCP流管理，包括IP分片重组、TCP乱序重传处理；

其中，IP分片重组中，根据分片报文的四元素(使用源IP地址+目的IP地址+IP报文ID标+传输层协议号)结合一个随机数RAND计算一个哈希值，然后根据所述哈希值去查找分片队列，查找到分片队列后把IP报文插入分片队列，如果所有分片报文都集齐了则开始重组生成完成的IP报文；如果一直都无法集齐的话，这个分片队列内存就会被垃圾回收定时器回收。

更为具体的，TCP流管理的处理逻辑如图3所示。

其中，TCP乱序重传处理包括：

1)按照四元素维护TCP流；所述四元素为源IP地址+目的IP地址+源端口+目的端；

2)TCP流维护下一个TCP数据包的SEQ；

3)比较当前的数据包的SEQ和TCP流需要的下一个数据包的SEQ；

如果等于：表明正常，直接输出改TCP数据包；

如果小于：表明出现重传，直接丢弃该TCP数据包；

如果大于：表明出现乱序，缓存该TCP数据包，由于采集可能出现丢包，需要定义缓存数据包的大小，超过缓存限制后认为丢包，直接从缓存数据包中选择SEQ值最小的TCP数据包输出。

更为具体的，对TCP乱序重传的处理逻辑如图4所示。

具体的，步骤S102对HTTP2消息重组中按照源IP地址+目的IP地址+源端口+目的端口维护TCP流，并从TCP流中切分出一个一个完成的HTTP2消息包。

更为具体的，对HTTP2消息重组的处理流程如图5所示。

具体的，步骤S103的查询解码上下文中，按照源IP地址+目的IP地址+源端口+目的端口维护解码上下文，解码上下文包括静态表和动态表内容。

具体的，步骤S104的创建解码上下文中，分配解码上下文内存；初始化解码上下文，保存创建完整的静态表和空的动态表。

具体的，步骤S104的解码Encoder HEADER，得到头字段模式，解码过程的逻辑如下：

1)模式“1”(由带索引的头部字段表示)；

带索引的头部字段为“1”；

则解码index，直接用index查询动态表或者静态表得到头字段的字段名和字段值。

2)模式“01”(由带增量索引的文字头字段表示)；

如果名字是索引：解码索引字段名称的索引值并使用索引查询动态表得到头字段的字段名；

如果名字是字符串：解码字符串得到头字段的字段名；

解码字符串得到头字段的字段值；

最后把头字段插入动态表。

2)模式“0000”(由不带索引的文字头字段表示)；

如果名字是索引：解码索引字段名称的索引值并使用索引查询动态表得到头字段的字段名；

如果名字是字符串：解码字符串得到头字段的字段名；

解码字符串得到头字段的字段值。

3)模式“0001”(由不带索引的文字头字段表示)；

如果名字是索引：解码索引字段名称的索引值并使用索引查询动态表得到头字段的字段名；

如果名字是字符串：解码字符串得到头字段的字段名；

解码字符串得到头字段的字段值。

4)模式“001”(更新动态表大小)；

如果是减少动态表大小，如果当前动态表大小比需要更新的动态表大小还要小，那么需要逐出动态表中的条目。

5)保存解码结果；

是指修改HEADERs的原始数据包，动态表查询部分修改为0000的头字段模式(不带索引的文字头字段表示)。便于信令回溯后信令的解码。

具体的，第一解压缩方法中采用FIFO算法维护动态表；在维护动态表时，

插入动态的顺序为后续该表项的索引；

对已有的表项不能修改；

只有消息中“01”头字段模式的IE字段才能插入动态表项到动态表。

具体的，S2的第二解压缩方法更适用于现网的实际场景。第二解压缩方法的方法作为第一解压缩方法的补充和升级，考虑到现网数据的复杂性，在不能够完整采集到的HTTP2动态头部压缩协商数据的时候，如何利用码流中的其他特征字结合3GPP规范、及5G核心网的业务场景，以提高头部压缩的解码率进行高精度的业务识别和特征提取。

如前所述第一解压缩方法的解码流程，在实际的现网数据中，因HTTP2长连接而增加了其复杂性，故此，对SBI接口的信令解析，还需考虑到长连接的特殊性。

所谓长连接，是指客户端向服务端发起连接，服务端接受客户端连接，双方建立连接，客户端与服务端完成一次请求后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。

5GC设备之间的HTTP2链路多为长连接，而信令采集的数据源往往是在长连接已经建立之后，这就意味着进入到采集设备的数据，大量是从接入那一刻起就已经是进行过头部压缩的数据了，这时候解码程序将得不到程序启动之前通信网元协商的动态表。

当携带了带增量索引的头字段表示字段的HEADER消息丢失，将导致动态表与实际不一致，可能导致后续HEADERs解码丢失解码信息和得到错误解码结果。

为了减少上述因素对解码准确性的影响，需要通过一些别的机制补充动态表学习，尽可能短时间的与核心网设备维护的动态表进行同步；且通过HTTP2的流状态的状态转换以及仅影响这些转换的帧和标志，来得到动态表。

HTTP2的流状态如图6所示。

具体的，S2的第二解压缩方法相比于第一解压缩方法进行了以下优化，包括：

1)增加动态表修复机制；

在动态表修复机制下不再遵循第一解压缩方法中采用FIFO算法维护动态表的模式。

动态表的修复中，动态表项能够插入动态表的中间，判断已存在的表项目需要修改时，对所述表项目进行修改。

2)动态表的修复中，插入只有ID的空条目，没有头字段名或者头字段值，用于同步核心网网元与头部压缩解压程序对动态表的插入。

动态表是通过收到消息中头字段模式方式维护，并且维护的时候是采用FIFO算法。那么在通过复制消息还原动态表的信令解析场景中，可能会出现由于复制时候丢失个别消息导致维护的动态表和通信时实际情况有所差别，即可能出现下面的场景：由于丢失了携带‘01’头字段模式的消息，通过镜像消息还原的动态表表项比实际通信时使用的动态表表项少，即可能收到‘1’头字段模式携带的index比还原动态表的最大索引数还要大。在常规的方案中，遇到这种情况是直接解码异常；高级方案中会启动修复机制：在动态表中插入空表项作为占位项，保证‘1’等需要通过index查询动态表的头字段模式一定能通过携带的index在动态表中查询到记录(可能查询到的是空记录)。

3)通过HTTP2的HEADER+DATA+3GPP协议规范得到DATA的消息类型，进行动态表内容的推导；并通过HTTP2的响应+3GPP协议规范得到响应的消息类型和响应的结构，推导出一部分动态表内容。

举例来讲，如果HEADER的uri中携带/registrations字符串就可以判断是和UDM服务有关，可能包含/registrations/amf-3gpp-access、/registrations/smf-registrations、/registrations/smsf-3gpp-access等，则代表分别对应的是N8接口(AMF-UDM)、N10接口(SMF-UDM)、N21接口(SMSF-UDM)。相应的可以记录和学习到对应的NE的IP地址，用于后续的接口判断；

进一步如果HTTP2的URI包含/registrations/amf-3gpp-access data，且DATA消息中出现了amfInstanceId、deregCallbackUri、guami、ratType等attribute名称，则可以判断该消息所包含的内容为Amf3GPPAccessRegistration消息体，则可以判断，这是AMF发往UDM的3GPP接入的注册流程，HTTP2请求的method应该为PUT；如果相同的URI，但是DATA消息中没有amfInstanceId、deregCallbackUri、ratType，只有guami、purgeFlag等attribute名称，则可以判断该消息所包含的为Amf3GPPAccessRegistrationModification消息体，故而可以判断，HTTP2请求的method应该为PATCH。

由于3GPP文档对服务操作(在HEADER中)和操作携带的信息(在DATA中)存在强约束，所以可以通过DATA携带的信息推导出HEADER中肯定携带的大部分信息。再用推导出来的HEADER中携带的信息与依赖动态表解码出来的信息做对比分析。如果推导出来的需要携带的信息与动态表解码出来的信息出现冲突启动高级接压缩方案中的修复机制(如例一：推导出来的Method为PATCH，但是通过动态解码出来的Method为PUT，那么动态表肯定异常，需要启动修复机制)

修复机制主要是认为推导出来的信息肯定是准确的，在通过分析动态表内容确定冲突发生的动态表表项区间，在可能存在问题的表项区间中插入空表项目后再按照新动态表解压缩数据包，直到解码出来信息与推导出来的信息不冲突。

具体的，修复过程如图7所示，包括：

1)缓存动态表；

2)判断解码出来信息与根据3GPP协议规范推导出来的信息是否冲突；是则进入3)，否则进入步骤7)；

3)恢复缓存的动态表；

4)分析动态表内容，确定出冲突发生的动态表表项区间；

5)在动态表可能的位置插入空白项，生成新的动态表；

6)用新的动态表再次对当前数据包解压缩；返回步骤2)进行判断；

7)使用修改后的动态表作为最新的动态表。

综上所述，本实施例中的5G核心网HTTP2头部压缩解码的方法，适用了HTTP2数据完整采集和HTTP2长连接建链后采集设备接入两种场景；通过第一解压缩方法和第二解压缩方法的相互补充，第一解压缩方法中，HTTP2头部压缩的协商过程被完整采集，按照RFC标准进行头压缩解码；第二解压缩方法中在没有被完整采集到时，考虑到TCP长连接的情况，对按照RFC标准进行头压缩解码的方式进行补充和升级，利用码流中的其他特征字结合3GPP规范、及5G核心网的业务场景，大大地提高了现网的解压缩成功率。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。