CN115883682A - 一种基于http2协议的数据传输方法和装置 - Google Patents
一种基于http2协议的数据传输方法和装置 Download PDFInfo
- Publication number
- CN115883682A CN115883682A CN202111122426.0A CN202111122426A CN115883682A CN 115883682 A CN115883682 A CN 115883682A CN 202111122426 A CN202111122426 A CN 202111122426A CN 115883682 A CN115883682 A CN 115883682A
- Authority
- CN
- China
- Prior art keywords
- header field
- header
- decoding
- index
- encoding
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明涉及一种基于HTTP2协议的数据传输方法和装置，属于通信技术领域，解决了现有技术中遇到解码错误会直接错误返回和数据重传而导致数据传输效率和速率降低等的问题。该方法包括：生成多个发送端请求，其中，每个发送端请求包括报头帧和请求数据帧，报头帧包括多个报头字段；按照编码格式对多个报头字段中的每个报头字段进行编码以形成多个编码报头字段作为压缩的报头帧；将每个发送端请求中的压缩的报头帧和请求数据帧分别地顺序发送至接收端；以及对每个发送端请求中的每个编码报头字段按照编码格式分别地顺序进行解码，并且当解码失败时启动解码异常修复机制。在解码失败时，启动单报头字段解码异常修复机制，避免直接错误返回和数据重传。
Description
技术领域
本发明涉及通信技术领域，尤其涉及一种基于HTTP2协议的数据传输方法和装置。
背景技术
在一般情况下HTTP/2传输层采用TCP协议，TCP提供了面向连接的、可靠的、基于字节流的传输层通信协议，即能保证客户端和服务都收到的数据不会存在乱序、丢失等异常情况，这也是HAPCK协议对底层传输的要求。即只要能保证收到的数据包不存在乱序和丢失等异常情况下，头部压缩的解密率肯定能达到百分之百。
但是在网络协议监测分析技术应用领域一般采用的是分光等旁路手段得到HTTP2的数据包，在旁路方式下应用系统得到的数据不可避免的会出现如下异常：
1、HTTP2长连接导致丢失连接开始到采集解析设备启动之间的数据包：
所谓长连接，是指客户端向服务端发起连接，服务端接受客户端连接，双方建立连接，客户端与服务端完成一次请求后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。5G核心网(5GC)设备之间的HTTP2链路多为长连接，而信令采集的数据源往往是在长连接已经建立之后，这就意味着进入到采集设备的数据，是从接入那一刻起就已经是进行过头部压缩的数据，这时候解码程序将得不到程序启动之前通信网元协商的动态表。
2、消息丢失：如果携带了带增量索引的报头文字HTTP/2头部帧丢失，将导致动态表与实际不一致，可能导致后续头部帧解码丢失解码信息或得到错误解码结果。
下面参考图1，举例说明丢包对HTTP2解码的影响：场景为HADER_1发送六个报头字段：1)method：GET；2)：scheme：https；3)：host：example.com；4)：path：/resource；5)accept：image/jgeg；6)user-agent：Mozilla/5.0。其中3、4、5、6四个报头字段会加入动态表，该消息后动态表为以下表1所示。
表1
| 62 | user-agent | Mozilla/5.0 |
| 63 | accept | image/jgeg |
| 64 | ：path | /resource |
| 65 | ：host | example.com |
HEADER_3发送6个报头字段：1)method：GET；2)：scheme：https；3)：host：example.com；4)：path：/new_resource；5)accept：image/jgeg；
6)user-agent：Mozilla/5.0。
其中3、5、6会用报头字段索引格式编码；4用报头字段增量索引带索引名称格式编码。该消息后动态表为以下表2所示。
表2
| 62 | ：path | /new_resource |
| 63 | user-agent | Mozilla/5.0 |
| 64 | accept | image/jgeg |
| 65 | ：path | /resource |
| 66 | ：host | example.com |
但是在旁路是可能丢包，现在假设丢了HEAD1数据包，直接收到HEAD3数据表时候的情形：
由于丢了HEAD1数据包，收到HEAD3这时候该链接的动态表为空，解码的时候发现有报头字段索引格式解码出索引ID值64、63、62，这时候我们的动态表为空。这时候一般解码器会认为出现异常直接返回。将导致HEAR3帧解码失败。这需要客户端将HEAD1帧、DATA1帧、HEAD3帧和DATA3帧重新传送至服务端，进而降低了数据传输速率和效率。
如果旁路出现上述异常情况，在报头字段解码可能出现如下错误：
1、报头字段索引格式：解码出来的索引值在动态表和静态表中找不到对应的记录；
2、报头字段增量索引带索引名称格式：解码出来的名称索引值在动态表和静态表中找不到对应的记录；或用索引值找到的名称和解码出来报头字段的值不对应。例如，解码报头字段名称为:method,值为156；156不在:method有效值范围，所以解码出来的报头字段肯定异常。
3、报头字段不索引带索引名称格式：解码出来的名称索引值在动态表和静态表中找不到对应的记录；或用索引值找到的名称和解码出来报头字段的值不对应。例如，解码报头字段名称为:method,值为156；156不在:method有效值范围，所以解码出来的报头字段肯定异常。
参考图2，传统的解码方案遇到上述解码错误时会直接错误返回并信息数据重传，从而降低了数据传输速率和效率，并导致整个数据包不能参与XDR合成等后续处理。
发明内容
鉴于上述的分析，本发明实施例旨在提供一种报头解码方法和装置，用以解决现有传输方法遇到解码错误而导致的数据传输效率和速率降低等问题。
一方面，本发明实施例提供了一种基于HTTP2协议的数据传输方法，包括：生成多个发送端请求，其中，每个发送端请求包括报头帧和请求数据帧，所述报头帧包括多个报头字段；按照编码格式对所述多个报头字段中的每个报头字段进行编码以形成多个编码报头字段作为压缩的报头帧，其中，所述编码格式包括报头字段索引格式编码、报头字段增量索引带索引名称格式编码、报头字段增量索引带文字名称格式编码、报头字段不索引带索引名称格式编码和报头字段不索引带文字名称格式编码；将所述每个发送端请求中的所述压缩的报头帧和所述请求数据帧分别地顺序发送至接收端；以及对所述每个发送端请求中的每个编码报头字段按照编码格式分别地顺序进行解码，并且当解码失败时启动解码异常修复机制。
上述技术方案的有益效果如下：在解码失败时，启动单报头字段解码异常修复机制，避免直接错误返回和数据重传，从而提高了数据传输速度和效率，并能够及时参与XDR合成等后续处理。
基于上述方法的进一步改进，对所述多个编码报头字段中的每个编码报头字段按照编码格式分别地顺序进行解码，并且当解码失败时启动解码异常修复机制进一步包括：识别一个编码报头字段的编码格式；基于识别的编码格式对被识别的编码报头字段进行解码并判断解码是否成功，其中，当解码成功时，将解码出来的报头字段加入报头字段列表；以及当识别的编码格式为所述报头字段增量索引带索引名称格式编码或者所述报头字段增量索引带文字名称格式编码时，将解码出来的报头字段插入动态表并将所述动态表的开始表项的状态设置为非丢包状态；当解码失败时，启动单报头字段解码异常修复机制。
基于上述方法的进一步改进，启动单报头字段解码异常修复机制进一步包括：当基于索引值在索引表中进行检索并且没有检索到与所述索引值相对应的记录内容时，确定所述动态表关联的TCP链接上丢失携带有所述报头字段增量索引带索引名称或者所述报头字段增量索引带文字名称的报头字段的报头帧；以及根据所述索引值在所述动态表中插入空报头字段以供后续的修改机制使用并将插入位置的表项的状态设置为丢包状态，其中，所述索引表包括静态表和所述动态表，所述静态表的索引值为1至61以及所述动态表的索引值大于等于62。
基于上述方法的进一步改进，启动单报头字段解码异常修复机制包括：当解码出来的报头字段名称和报头字段值不对应时，根据所述报头字段值推导所述报头字段名称以修改解码出来的报头字段和动态表，其中，所述报头字段包括报头字段名称和报头字段值。
基于上述方法的进一步改进，在所述多个编码报头字段解码完成以后，还包括：检查所述报头字段列表中是否还存在解码异常的报头字段；以及当存在解码异常的报头字段时，启动基于3GPP规范和正常解码统计结构的修复机制。
基于上述方法的进一步改进，启动基于3GPP规范和正常解码统计结构的修复机制还包括：在接收到所述请求数据帧之后，根据所述请求数据帧中的所有信息单元，确定与所述请求数据帧相对应的所述报头帧中的多个报头字段；以及根据确定的多个报头字段，修复所述解码异常的报头字段，以恢复所述空报头字段并将所述插入位置的表项的状态修改为非丢包状态。
基于上述方法的进一步改进，启动基于3GPP规范和正常解码统计结构的修复机制还包括：在同一设备和同一类型的报头帧的情况下，预先存储解码成功的报头帧的多个报头字段和出现报头字段的顺序；根据存储的解码成功的报头帧中报头字段和出现报头字段的顺序，对所述解码异常的报头字段进行修复。
基于上述方法的进一步改进，按照编码格式对所述多个报头字段中的每个报头字段进行编码以形成多个编码报头字段作为压缩的报头帧进一步包括：在静态表和动态表中查询报头字段；当所述报头字段在所述静态表或所述动态表中时，按照所述报头字段索引格式对所述报头字段进行编码；当所述报头字段不在所述静态表或所述动态表中时，根据报头字段名称是否在所述静态表或所述动态表中以及是否将所述报头字段放入所述动态表中，按照除所述报头字段索引格式之外的编码格式对所述报头字段进行编码，其中，所述报头字段包括报头字段名称和报头字段值。
基于上述方法的进一步改进，根据报头字段名称是否在所述静态表或所述动态表中以及是否将所述报头字段放入所述动态表中，按照除所述报头字段索引格式之外的编码格式对所述报头字段进行编码进一步包括：当所述报头字段名称在所述静态表或所述动态表中并且将所述报头字段放入所述动态表中时，按照报头字段增量索引名称格式对所述报头字段进行编码；当所述报头字段名称在所述静态表或所述动态表中并且所述报头字段不放入所述动态表中时，按照报头字段不索引带索引名称格式对所述报头字段进行编码；当所述报头字段名称不在所述静态表或所述动态表中并且将所述报头字段放入所述动态表中时，按照报头字段增量索引带文字名称格式对所述报头字段进行编码；以及当所述报头字段名称不在所述静态表或所述动态表中并且所述报头字段不放入所述动态表中时，按照报头字段不索引带文字名称格式对所述报头字段进行编码。
另一方面，本发明实施例提供了一种基于HTTP2协议的数据传输装置，包括：发送端和接收端，其中，所述发送端包括请求生成模块、编码模块和传送模块，以及所述接收端包括解码模块和修复模块，其中，所述请求生成模块，用于生成多个发送端请求，其中，每个发送端请求包括报头帧和请求数据帧，所述报头帧包括多个报头字段；所述编码模块，用于按照编码格式对所述多个报头字段中的每个报头字段进行编码以形成多个编码报头字段作为压缩的报头帧，其中，所述编码格式包括报头字段索引格式编码、报头字段增量索引带索引名称格式编码、报头字段增量索引带文字名称格式编码、报头字段不索引带索引名称格式编码和报头字段不索引带文字名称格式编码；所述传送模块，用于将所述每个发送端请求中的所述压缩的报头帧和所述请求数据帧分别地顺序传送至接收端；所述解码模块，用于对所述每个发送端请求中的每个编码报头字段按照编码格式分别地顺序进行解码；以及所述修复模块，用于当解码失败时启动解码异常修复机制。
与现有技术相比，本发明至少可实现如下有益效果之一：
1、在解码失败时，启动单报头字段解码异常修复机制，避免直接错误返回和数据重传，从而提高了数据传输速度和效率，并能够及时参与XDR合成等后续处理。
2、在出现HTTP/2头部帧解码异常的情况下，启动修复机制对解码结果和动态表做修复处理，保证在丢包等情况下在尽量解码出后续处理需要的报头字段，并尽可能短时间内重同步动态表。
3、在3GPP规范中某些操作中某些报头字段是固定的，如对于某些操作method或status是固定的，那么如果没有解码出来method或status报头字段或者解码出来的method或status报头字段和3GPP规范不一致那么可以根据3GPP规范修复。
4、本申请的实施例将同一个网元同一个PATH类型的HEADER中携带的报头字段内容和报头字段顺序基本相同。基于这个认知，对成功的HEADER帧解码，我们按照设备+PATH类型为维度统计出现的报头字段和出现报头字段的顺序。我们可以使用统计结果对解码异常报头字段进行修复。
本发明中，上述各技术方案之间还可以相互组合，以实现更多的优选组合方案。本发明的其他特征和优点将在随后的说明书中阐述，并且，部分优点可从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过说明书以及附图中所特别指出的内容中来实现和获得。
附图说明
附图仅用于示出具体实施例的目的，而并不认为是对本发明的限制，在整个附图中，相同的参考符号表示相同的部件。
图1为采用HAPCK协议在客户端和服务端之间进行信息传输的实例。
图2为现有报头解码方法的框图。
图3为根据本发明实施例的基于HTTP2协议的数据传输方法的流程图。
图4为5G网络结构及相关接口协议的示图。
图5为根据本发明实施例的报头编码方法的流程图。
图6为根据本发明实施例的报头解码方法的具体流程图。
图7为根据本发明实施例的基于HTTP2协议的数据传输装置的框图。
图8为HPACK使用的静态表的示图。
图9为HPACK头压缩原理图。
具体实施方式
下面结合附图来具体描述本发明的优选实施例，其中，附图构成本申请一部分，并与本发明的实施例一起用于阐释本发明的原理，并非用于限定本发明的范围。
为了减少上述因素对解码和后续XDR合成的影响，引入了检查和修复机制补充解码和动态表机制，尽可能多的解码出正常的报头字段列表和尽可能短时间内重同步动态表。
本发明的一个具体实施例，公开了一种报头解码方法。参考图3，基于HTTP2协议的数据传输方法，包括：在步骤S302中，生成多个发送端请求，其中，每个发送端请求包括报头帧和请求数据帧，报头帧包括多个报头字段；在步骤S304中，按照编码格式对多个报头字段中的每个报头字段进行编码以形成多个编码报头字段作为压缩的报头帧，其中，编码格式包括报头字段索引格式编码、报头字段增量索引带索引名称格式编码、报头字段增量索引带文字名称格式编码、报头字段不索引带索引名称格式编码和报头字段不索引带文字名称格式编码；在步骤S306中，将每个发送端请求中的压缩的报头帧和请求数据帧分别地顺序发送至接收端；以及在步骤S308中，对每个发送端请求中的每个编码报头字段按照编码格式分别地顺序进行解码，并且当解码失败时启动解码异常修复机制。
与现有技术相比，本实施例提供的报头解码方法，在解码失败时，启动单报头字段解码异常修复机制，避免直接错误返回和数据重传，从而提高了数据传输速度和效率，并能够及时参与XDR合成等后续处理(XDR合成：采集处理运营商通信网络全量数据进行生成XDR记录)，其中，XDR是基于运营商通信网络全量数据进行处理后，生成的供信令监测平台和信令类应用使用的业务详细记录。
下文中，将参考图3，对根据本发明实施例的基于HTTP2协议的数据传输方法的各个步骤进行详细描述。
在步骤S302中，生成多个发送端请求，其中，每个发送端请求包括报头(HEADER)帧和请求数据(DATA)帧，报头帧包括多个报头字段。例如，生成第一发送端请求和第二发送端请求，该第一发送端请求包括HEADER1帧和DATA1帧。第二发送端请求包括HEADER2帧和DATA2帧。一个HTTP/2请求分为两个帧：HEADER帧和一个DATA帧，其中，HEADER帧是头压缩的，DATA帧是请求内容帧是明文的。在移动通信领域DATA帧的内容是3GPP规范定义的。
在步骤S304中，按照编码格式对多个报头字段中的每个报头字段进行编码以形成多个编码报头字段作为压缩的报头帧，其中，编码格式包括报头字段索引格式编码、报头字段增量索引带索引名称格式编码、报头字段增量索引带文字名称格式编码、报头字段不索引带索引名称格式编码和报头字段不索引带文字名称格式编码。按照编码格式对多个报头字段中的每个报头字段进行编码以形成多个编码报头字段作为压缩的报头帧进一步包括：在静态表和动态表中查询报头字段；当报头字段在静态表或动态表中时，按照报头字段索引格式对报头字段进行编码；当报头字段不在静态表或动态表中时，根据报头字段名称是否在静态表或动态表中以及是否将报头字段放入动态表中，按照除报头字段索引格式之外的编码格式对报头字段进行编码，其中，报头字段包括报头字段名称和报头字段值。根据报头字段名称是否在静态表或动态表中以及是否将报头字段放入动态表中，按照除报头字段索引格式之外的编码格式对报头字段进行编码进一步包括：当报头字段名称在静态表或动态表中并且将报头字段放入动态表中时，按照报头字段增量索引名称格式对报头字段进行编码；当报头字段名称在静态表或动态表中并且报头字段不放入动态表中时，按照报头字段不索引带索引名称格式对报头字段进行编码；当报头字段名称不在静态表或动态表中并且将报头字段放入动态表中时，按照报头字段增量索引带文字名称格式对报头字段进行编码；以及当报头字段名称不在静态表或动态表中并且报头字段不放入动态表中时，按照报头字段不索引带文字名称格式对报头字段进行编码。
在步骤S306中，将每个发送端请求中的压缩的报头帧和请求数据帧分别地顺序发送至接收端。例如，首先，将第一发送端请求发送至接收端，从接收端接收第二接收端响应，以及将第三发送端请求发送至接收端，该第一发送端请求包括HEADER1帧和DATA1帧。第二接收端响应包括HEADER2帧和DATA2帧。第三发送端请求包括HEADER3帧和DATA3帧。报头帧以压缩的方式进行发送，而请求数据帧以明文的方式进行发送。
在步骤S308中，对每个发送端请求中的每个编码报头字段按照编码格式分别地顺序进行解码，并且当解码失败时启动解码异常修复机制。
具体地，对多个编码报头字段中的每个编码报头字段按照编码格式分别地顺序进行解码，并且当解码失败时启动解码异常修复机制进一步包括：识别一个编码报头字段的编码格式；基于识别的编码格式对被识别的编码报头字段进行解码并判断解码是否成功，其中，当解码成功时，将解码出来的报头字段加入报头字段列表；以及当识别的编码格式为报头字段增量索引带索引名称格式编码或者报头字段增量索引带文字名称格式编码时，将解码出来的报头字段插入动态表并将动态表的开始表项的状态设置为非丢包状态(例如，默认地设置为0)；当解码失败时，启动单报头字段解码异常修复机制。表项的状态值包括0和1，默认值0代表处于非丢包状态，1代表处于丢包状态。
启动单报头字段解码异常修复机制进一步包括：当基于索引值在索引表中进行检索并且没有检索到与索引值相对应的记录内容时，确定动态表关联的TCP链接上丢失携带有报头字段增量索引带索引名称或者报头字段增量索引带文字名称的报头字段的报头帧；以及根据索引值在动态表中插入空报头字段以供后续的修改机制使用并将插入位置的表项的状态设置为丢包状态，其中，索引表包括静态表和动态表，静态表的索引值为1至61以及动态表的索引值大于等于62。在可选实施例中，启动单报头字段解码异常修复机制包括：当解码出来的报头字段名称和报头字段值不对应时，根据报头字段值推导报头字段名称以修改解码出来的报头字段和动态表，其中，报头字段包括报头字段名称和报头字段值。
在多个编码报头字段解码完成以后，还包括：检查报头字段列表中是否还存在解码异常的报头字段；以及当存在解码异常的报头字段时，启动基于3GPP规范和正常解码统计结构的修复机制。具体地，启动基于3GPP规范和正常解码统计结构的修复机制还包括：在接收到请求数据帧之后，根据请求数据帧中的所有信息单元，确定与请求数据帧相对应的报头帧中的多个报头字段；以及根据确定的多个报头字段，修复解码异常的报头字段，以恢复空报头字段并将插入位置的表项的状态修改为非丢包状态。启动基于3GPP规范和正常解码统计结构的修复机制还包括：在同一设备和同一类型的报头帧的情况下，预先存储解码成功的报头帧的多个报头字段和出现报头字段的顺序；根据存储的解码成功的报头帧中报头字段和出现报头字段的顺序，对解码异常的报头字段进行修复。
下文中，参考图4至图6，以具体实例的方式，对根据本发明实施例的报头解码方法进行详细描述。
HTTP/2头部压缩原理
HTTP1.X由于其设计的缺陷，被大家诟病已久，其中头疼的问题之一，就是无意义的重复的头部。于是出现了各种各样的解决方案，如Google直接在HTTP1.X的基础上设计了SPDY协议，对头部使用deflate算法进行压缩，一并解决了多路复用和优先级等问题。HTTP2的实现就是参考了SPDY协议，但是专门为头部压缩设计了一套压缩算法，就是HPACK(例如，Header Compression for HTTP2-RFC7541)。
参考图9，HPACK将报头字段列表(Header List)视报头字段(HTTP/2 HeaderField，HTTP/2HEADER帧中的名称-值对)的有序集合，HPACK顺序对每个报头字段对进行压缩和解压缩。
HPACK使用2个索引表(静态表和动态表)来把报文字段映射到索引值，并对静态表和动态表中不存在的报头字段使用Huffman编码，并动态缓存到动态表，从而达到压缩头部的效果。参考图8，静态表(Static Table)由HPACK协议预定义的报头字段静态列表(即，61个常用的头部字段)组成，索引值从1-61。静态表是只读的，其中的条目及其位置(索引值)均不可更改。例如，图8列出了全部的静态表条目。动态表(Dynamic Table，动态维护的报头字段列表，用于消除冗余报头字段)也由一系列头部字段组成，但其中的元素不固定，在实际编码过程中按照需要插入新的条目或删除已经存在的条目。HPACK协议要求静态表与动态表合并在同一个存储空间中，其中静态表置于前部，动态表紧随其后。那么在整个索引表空间中，动态表的第一个条目的索引将是62。动态表的维护原则是先进先出(FIFO，最新条目处于最低索引处，最旧条目处于最高索引处)。当向动态表中增加条目时，将总是从第62位插入，原有的条目将全部向右移动一个位置。当从动态表中删除条目时，将总是从最后一位进行删除。
HPACK整个压缩解压过程：数据发送端自主决定哪些报头字段需要加入到动态表并按照HPACK规范加入动态表并压缩编码，所有的报头字典都编码完成后，这个数据包发送给数据接收端；数据接收端收到数据包按照HPACK规范解码能还原出和数据发送端一样的报头字段列表和动态表。
参考图9的头压缩原理图，发送端准备发送以下6个报头字段：
1)method:GET；2):scheme:https；3):host:example.com；4):path:/resource；5)user-agent:Mozilla/5.0；6)custom－hdr：some－value。现在索引表的动态表中有两个条目：62索引处的user-agent:Mozilla/5.0；63索引处的:host:example.com。第1个method：GET报头字段在静态表的2的位置，在编码的时候该报头字段编码为索引表中的索引值“2”；第2个:scheme:https报头字段在静态表的7的位置，在编码的时候该报头字段编码为索引表中的索引值“7”；第3个:host:example.com在动态表的第二个位置，对应在索引表中的索引为63，编码的时候该报头字段编码为索引表中的索引值“63”；第4个:path:/resource报头字段中报头字段名“:path”在静态表19的位置，编码的时候编码端选择采用“报头字段增量索引带索引名称格式”表头字段名称“：path”编码为索引表中的索引值，报头字段的值采用huffman编码的方法；第5个user-agent:Mozilla/5.0报头字段在动态表中的第一个位置，对应在索引表中的值为62，编码的时候该报头字段编码为索引表中的索引值“62”；第6个custom－hdr：some－value报头字段的报头字段名不在动态表和静态表中，编码端选在采用“报头字段不索引带文字名称格式”，报头字段名称“custom－hdr”编码为huffman(coustom－hdr)，报头字段值“some－value”编码为huffman(some－value)。下文中，对按照HPACK规范整个压缩的过程进行描述。参考图5，HPACK按照报头列表循序为每个报头字段编码：
1、查寻静态和动态的字典。如果报头字段在动态表中完整存在的，就使用报头字段索引格式(Indexed Header Field Representation,使用动态表或者静态表中的索引值编码一个报头字段)进行编码。这通常会消耗一个字节，最多两个字节就足够了。因为许多头部是重复的，所以这个策略有着非常高的成功率。
如果上面的HPACK头压缩原理图中的四个报头字段：
1)method:GET；2):scheme:https；3):host:example.com；4)user-agent:Mozilla/5.0，编码为2、7、63、62索引值，每个占用一个字节。
2、当无法在静态表和动态表匹配到一个完整报头字段。尝试在静态表和动态表中匹配报头字段名称，如果匹配到得到该报头字段名称在动态表或者静态表中的索引值。
3、决定是否把正在编码的报头字段加入动态表。如果报头字段要加入动态表，编码的前两个bit为01；如果报头字段不加入动态表，编码的前四个bit为0000。
4、如果决定将增加编码的报头字段加入动态表，可以使用“报头字段增量索引带索引名称格式编码(Literal Header Field with Incremental Indexing-Index Name，用头索引值到动态表或者静态表中得到名称，在直接得到头字段值，形成报头字段附加到解码的头部列表；并将其作为新条目插入到动态表中)”或者“报头字段增量索引带文字名称格式编码(Literal Header Field with Incremental Indexing--New Name。这种格式解码时，直接解码得到报头字段名称和报头字段值，形成报头字段附加到解码的头部列表；并将其作为新条目插入到动态表中)”这两中格式之一进行编码。“报头字段增量索引带索引名称格式编码”为报头字段名称在索引表中报头字段的值不在索引表中，名称用索引表中的索引值编码，值采用huffman编码，上面的hpack头压缩原理图中“：path:/resource”报头字段就是采用这种编码。“报头字段增量索引带文字名称格式编码”为报头字段的名称和值都不在索引表中，名称和值都采用huffman编码，上面的hpack头压缩原理图中custom－hdr：some－value就是采用这种编码。如果这两个字段都决定加入动态表，那么编码后动态表()为如下表3所示。
表3
Statie table
| 1 | ||
| 2 | ||
| … | … | … |
| 51 | refer | |
| … | … | … |
| 62 | eostom-hdr | some-value |
| 63 | ：path | /resouree |
| 64 | user-agent | Vozilla/5.0 |
| 65 | ：host | example |
Dynamic table
5、如果决定不将编码的报头字段加入动态表，可以使用“报头字段不索引带索引名称格式编码(Literal Header Field without Indexing--Indexed Name，这种格式解码时，用头索引值到动态表或者静态表中得到名称，在直接得到头字段值，形成保头字段附加到解码的头部列表；不改变动态表，及不能将该新条目插入到动态表中)”和“报头字段不索引带文字名称格式编码(Literal Header Field without Indexing--New Name，这种格式解码时，直接解码得到报头字段名称和报头字段值，形成保头字段附加到解码的头部列表；不改变动态表，及不能将该新条目插入到动态表中)”。“报头字段不索引带索引名称格式编码”为报头字段名称在索引表中报头字段的值不在索引表中，名称用索引表中的索引值编码，值采用huffman编码，上面的hpack头压缩原理图中“：path：/resource”报头字段就是采用这种编码。“报头字段不索引带文字名称格式编码”为报头字段的名称和值都不在索引表中，名称和值都采用huffman编码，上面的hpack头压缩原理图中custom-hdr：some-value就是采用这种编码。如果报头字段不加入动态表，编码完成后动态表不变。
参考图4，5G核心网颠覆了传统的CT网络架构及协议，将服务化接口引入。
其中各网元缩写释义如下：
AUSF：Authentication Server Function，鉴权服务功能；
AMF：Access and Mobility Management Function，接入与移动性管理功能；
SMF：Session Management Function，会话管理功能；
NSSF：Network Slice Selection Function，网络切片选择功能；
UDM：Unified Data Management，统一数据管理；
NEF：Network Exposure Function，网络暴露功能；
NRF：Network Repository Function，网络注册功能；
PCF：Policy Control Function，策略控制功能；
UPF：User Plane Function，用户平面功能；
AF：Application Function，应用功能；
DN：Data Network，数据网络；
图4中的Nnssf、Nnef、Nnrf、Npcf、Nudm、Naf、Nausf、Namf和Nsmf等接口都是使用HTTP2协议进行通信。由于HTTP2通信的时候为了提高安全性和通信效率，操作类型、操作资源、操作结果等关键的信息都在动态表中；如果这些信息没有解码成功将影响XDR合成。因此在信令采集解析系统中对HTTP2的动态头解压准确性将决定整个系统的准确性和可用性。
本发明增加在出现HTTP/2头部帧解码异常的情况下，启动修复机制对解码结果和动态表做修复处理，保证在传丢包等情况下在尽量解码出后续处理需要的报头字段，并尽可能短时间内重同步动态表的内容。
参考图6，对报头解码方法进行详细描述。
1、判断报头字段的编码格式。
2、按照报头字段的编码格式解码报头字段。
3、如果报头字段解码成功，查看报头字段是否需要插入动态表。对于使用“报头字段增量索引带索引名称格式编码”或者“报头字段增量索引带文字名称格式编码”这两种格式之一进行编码的报头字段需要插入动态表。当前动态表内容参考如下表4。
表4
| 62 | user-agent | Mozilla/5.0 |
| 63 | accept | image/jgeg |
| 64 | ：path | /resource |
| 65 | ：host | example.com |
如果收到了一个数据包，解码是遇到“：path：/new_resource”报头字段需要插入动态表；那么就需要包“：path：/new_resource”插入动态表中，插入完成后动态表内容参考如下表5。
表5
| 62 | ：path | /new_resource |
| 63 | user-agent | Mozilla/5.0 |
| 64 | accept | image/jgeg |
| 65 | ：path | /resource |
| 66 | ：host | example.com |
4、如果报头字段解码失败，启动单报头字段解码异常修复机制。
在这个阶段能发现解码失败都是报头字段格式为报头字段索引、报头字段增量索引带索引名称或者报头字段不索引带索引名称等格式的时候，用索引值没有在索引表中找到值。
遇到这种错误一般情况是这个动态表关联的TCP链接上丢了一个携带有“报头字段增量索引带索引名称”或“报头字段增量索引带文字名称”的报头字段的HTTP2 Header帧。这时候需要在动态表中插入一个空的报头字段，供后续的修复机制使用。插入位置为该动态表关联的TCP链接最近丢包的位置。该动态表关联的TCP连接的TCP链接的链接管理发现该TCP链接上有丢包，那么置该动态表开始表项的丢包状态置为1(默认为0)；丢包位置为从动态表的开始遍历，一直到有表项的丢包状态为1或者动态表结尾。如果用动态表表项的丢包状态为1，那么插入位置为该表项前面；如果一直遍历到了动态表结尾那么插入位置就是动态表的结尾。例如当前的动态表内容参考如下表6。
表6
| 62 | user-agent | Mozilla/5.0 |
| 63 | accept | image/jgeg |
| 64 | ：path | /resource |
| 65 | ：host | example.com |
如果收到一个数据包的报头字段索引值为66，并且动态表中62对应的表项的丢包状态为0，63丢包状态为1；那么需要在63之前插入一个空报头字段，插入后动态表内容参考如下表7。
表7
| 62 | user-agent | Mozilla/5.0 |
| 63 | ||
| 64 | accept | image/jgeg |
| 65 | ：path | /resource |
| 66 | ：host | example.com |
这时候认为索引66的值为“：host：example.com”，索引63的值为空内容。
5、所有报头字段解码完成后，检查报头字段列表中是否有解码异常的报头字段。
6、如果有异常报头字段，启动基于3GPP规范的修复机制。
(1)在3GPP规范中某些操作中某些报头字段是固定的，如对于某些操作method或status是固定的，那么如果没有解码出来method或status报头字段或者解码出来的method或status报头字段和3GPP规范不一致那么可以根据3GPP规范修复。
例如，path为{apiRoot}/nsmf-pdusession/v1/sm-contexts的操作method肯定为post；成功的响应的status一定是201。那么如果解码出来了method为put或者status为201那么一定是解码错误了，需要清空method：put的索引值和stauts：201的索引值对应的表项。
例如：开始的时候动态表状态如下表8：
表8
| 62 | user--agent | Mozilla/5.0 |
| 63 | method | put |
| 64 | accept | image/jgeg |
| 65 | ：path | /resource |
| 66 | ：host | example.com |
收到数据包解码出path为{apiRoot}/nsmf-pdusession/v1/sm-contexts和method：put报头字段。method：put报头字段对应的索引为63，那么可以认为63表项异常。执行修复操作可以清空63对应的表项，执行修复后的动态表为如下表9所示。
表9
| 62 | user--agent | Mozilla/5.0 |
| 63 | ||
| 64 | accept | image/jgeg |
| 65 | ：path | /resource |
| 66 | ：host | example.com |
(2)根据DATA帧修复
一个HTTP/2请求分为两个帧，一个HEADER帧和一个DATA帧，HEADER帧是头压缩的，DATA帧是请求内容帧是明文的。在移动通信领域DATA帧的内容是3GPP规范定义的。
如果解码HEADERS帧的时候存在报头字段解码异常，可以延迟处理，延迟到该HEADER帧对应的DATA帧处理完成后。可以由DATA帧的解码内容和3GPP规范推导出HEADERS帧中需要携带的报头字段。如果需要携带的报头字段在我们解码成功的报头字段中不全，这些内容肯定在解码异常的报头字段中。那么可以知道解码异常的报头字段的取值范围。
如果只有一个解码异常的报头字段和缺失一个需要携带的报头字段，那么可以确定解码异常的报头字段的值，这时候可以修正解码异常的报头字段和按照索引值增加该报头字段到动态表的方式修复动态表。
在第一示例中，根据3GPP规范如果smf服务的data消息中出现了下列的所有信息单元：
-dnn
-vsmfId
-servingNetwork
-vsmfPduSessionUri
-vcnTunnelInfo
-anType
则可以确认，该data对应的服务是：
{apiRoot}/nsmf-pdusession/v1/pdu-sessions
从而可以得到该data帧对应的headers帧里面有如下头字段：
-method：post
-content-length：data的长度
-content-type：application/json或者multipart/related(依赖data帧的格式，data确定后content-type就能唯一确定了)
-path：{apiRoot}/nsmf-pdusession/v1/pdu-sessions
如果HEADER帧中解码的时候没有解码出content-type并且有一个63的索引没有在动态表中得到内容，那么可以确定索引63对应的表项值为“content-type：application/json”。
如果解码前动态表的内容如下表10所示。
表10
| 62 | user--agent | Mozilla/5.0 |
| 63 | ||
| 64 | accept | image/jgeg |
| 65 | ：path | /resource |
| 66 | ：host | example.com |
那么修复后动态表的内容为如下表11所示。
表11
| 62 | user-agent | Mozilla/5.0 |
| 63 | content-type | application/json |
| 64 | accept | image/jgeg |
| 65 | ：path | /resource |
| 66 | ：host | example.com |
在第二示例中，根据3GPP规范如果udm服务的data消息中出现了下列的所有信息单元：
-smfInstanceId
-pduSessionId
-singleNssai
-plmnId
则可以确认，该data对应的服务是：
/{ueId}/registrations/smf-registrations/{pduSessionId}
从而可以得到该data帧对应的headers帧里面必须有如下头字段：
-path：/{ueId}/registrations/smf-registrations/{pduSessionId}
-method：put
-content-length：data的长度
-content-type：application/json
如果HEADER帧中解码的时候没有解码出content-type并且有一个63的索引没有在动态表中得到内容，那么可以确定索引63对应的表项值为“content-type：application/json”。
如果解码前动态表的内容为如下表12所示。
表12
| 62 | user--agent | Mozilla/5.0 |
| 63 | ||
| 64 | accept | image/jgeg |
| 65 | ：path | /resource |
| 66 | ：host | example.com |
那么修复后动态表的内容为如下表13所示。
表13
| 62 | user--agent | Mozilla/5.0 |
| 63 | content-type | application/json |
| 64 | accept | image/jgeg |
| 65 | ：path | /resource |
| 66 | ：host | example.com |
在第三示例中，根据3GPP规范如果udm服务的DATA消息中出现了下列的所有信息单元：
-amfInstanceId
-imsVoPs
-deregCallbackUri
-guami
-ratType
可以通过DATA中的方向确定该DATA帧是请求DATA帧还是响应DATA帧(如果该DATA帧的目的地址是UDM那么是请求帧，如果该DATA帧的源地址是UDM那么是响应帧)。如果该DATA是请求DATA帧，
则可以确认，该data对应的服务是：
/{ueId}/registrations/amf-non-3gpp-access
从而可以得到该data帧对应的headers帧里面必须有如下头字段：
-path：/{ueId}/registrations/amf-non-3gpp-access
-method：put
-content-length：data的长度
-content-type：application/json
如果HEADER帧中解码的时候没有解码出method并且有一个63的索引没有在动态表中得到内容，那么可以确定索引63对应的表项值为“methon：put”。
如果解码前动态表的内容为如下表14所示。
表14
| 62 | user--agent | Mozilla/5.0 |
| 63 | ||
| 64 | accept | image/jgeg |
| 65 | ：path | /resource |
| 66 | ：host | example.com |
那么修复后动态表的内容为如下表15所示。
表15
| 62 | user--agent | Mozilla/5.0 |
| 63 | method | put |
| 64 | accept | image/jgeg |
| 65 | ：path | /resource |
| 66 | ：host | example.com |
7、启动基于3GPP网元和PATH类型统计修复机制
我们认为同一个网元同一个PATH类型的HEADER中携带的报头字段内容和报头字段顺序基本相同。
基于这个认知，对成功的HEADER帧解码，我们按照设备+PATH类型为维度统计出现的报头字段和出现报头字段的顺序。我们可以使用统计结果对解码异常报头字段进行修复。
下面举例说明可以使用统计结果修复的场景：
(1)如果某个PATH操作中有报头字段A在所有正常的HEADERS帧中都只出现一次，但是本次解码报头字段A出现了多次；那么可以肯定有解码异常的，可以结合报头字段A在正常HEADERS帧中出现的顺序，确认那个报头字段A是解码正常的；除了这个解码正常的报头字段，其他都是解码异常的。
(2)如某个包解码出了两个content-type，但是该PATH操作content-type在所有正常的HEADERS帧中都只出现一次，那么肯定有一个content-type报头字段索引对应的动态表项异常。可以结合content-type在该PATH操作的正常HEADERS帧中出现的顺序，确认那个content-type报头字段索引对应的动态表项异常。
(3)如果某个PATH操作中有报头字段A在所有正常的HEADERS帧中都出现，但是在存在解码异常报头字段的HEADERS帧中没有出现。那么认为解码异常的报头字段中肯定存在报头字段A。可以结合报头字段A在正常HEADERS帧中出现的顺序，确认解码异常的报头字段中那个字段的值为报头字段A。
(4)如果某个PATH操作中有报头字段A在正常的HEADERS帧中高频出现(如超过95％)，但是在解码异常的报头字段的HEADERS帧中没有出现。那么认为解码异常的报头字段中可能存在报头字段A；再结合报头字段A在正常HEADERS帧中出现的顺序，可能可以确认解码异常的报头字段中那个值为报头字段A。
(5)如果某个PATH操作中有报头字段序列(报头字段A,报头字段B，报头字段C)在所有正常的HEADERS帧中都出现或者出现的频率很高，但是有解码异常的报头字段的HEADER帧中没有出现；但是出现了(报头字段A，解码异常报头字段，报头字段C)的报头字段序列，那么可以认为解码异常报头字段为报头字段B。
(6)当出现多个需要出现的多个解码异常的报头字段和缺失多个需要携带的报头字的时候，可以先通过缺失字段在正常的HEADERS帧中出现的顺序确定解码异常报头字段对应的值。
在第四示例中，可以按照“服务+源IP地址+头部字段”的各种排列为维度统计移动通信网络各设备发送各种服务的HEADER帧中各种头部字段排列出现的顺序的概率。从而得到各种设备中各种服务出现概率最高的头部字段顺序。
如果通过统计得到某IP地址(IP1)发送的/sm-contexts/
{smContextRef}/modify服务的HEADER帧中的概率最高头部字段顺序为：
1)：authority；2)：method；3)：path；4)：scheme；5)：content-type如果我们收到IP1地址发送的/sm-contexts/{smContextRef}/modify的服务器中解码出了两个content-type。解码结果如下表16所示。
表16
| 头字段索引 | 头字段名 | 头字段值 |
| 68 | ：content-type | application/json |
| 3 | ：method | post |
| 64 | ：path | /nsmf-pdusession/v1/sm-contexts/1/modify |
| 6 | ：scheme | http |
| 62 | ：content-type | application/json |
那么肯定有一个content-type报头字段索引对应的动态表项异常。
通过学习知道该服务头部字段的出现顺序为1)：authority；
2)：method；3)：path；4)：scheme；5)：content-type这种序列的概率很高，可以尝试用这种序列修复；及可以认为头字段索引68解码出来的值是异常的，及动态表中68索引值对应的条目异常。可以修复68索引值得表项：表项名为：authority；表项值未知：解码前动态内容为如下表17所示。
表17
| 62 | ：content-type | application/json |
| 63 | user-agent | Mozilla/5.0 |
| 64 | ：path | /nsmf-pdusession/v1/sm-contexts/1/modify |
| 65 | ：path | /resource |
| 66 | ：host | example.com |
| 67 | accept | image/jgeg |
| 68 | ：content-type | application/json |
修复后动态表内容为如下表18所示。
表18
| 62 | ：content-type | application/json |
| 63 | user-agent | Mozilla/5.0 |
| 64 | ：path | /nsmf-pdusession/v1/sm-contexts/1/modify |
| 65 | ：path | /resource |
| 66 | ：host | example.com |
| 67 | accept | image/jgeg |
| 68 | ：authority |
在第五示例中，可以按照“服务+源IP地址+头部字段”为维度统计移动通信网络各设备发送各种服务的HEADER帧中各种头部字段出现的顺序的概率。从而得到各种设备中各种服务出现概率TOPN的头部字段。
如果通过统计得到某IP地址(IP1)发送的/sm-contexts/
{smContextRef}/modify服务的HEADER帧中的TOPN的头部字段为如下表19所示。
表19
| 头字段名 | 头字段值 | 出现概率 |
| ：content-type | application/json | 100％ |
| ：method | post | 100％ |
| ：path | /nsmf-pdusession/v1/sm-contexts/1/modify | 100％ |
| ：scheme | http | 100％ |
如果我们收到IP1地址发送的/sm-contexts/{smContextRef}/modify的服务的Header帧解码结果如以下表20所示。
表20
| 头字段索引 | 头字段名 | 头字段值 |
| 68 | ：authority | 10.10.10.10：80 |
| 3 | ：method | post |
| 64 | ：path | /nsmf-pdusession/v1/sm-contexts/1/modify |
| 6 | ：scheme | http |
| 62 | ：accept-encoding | gzip |
从统计中可以肯定IP1地址发送的/sm-contexts/{smContextRef}/modify的服务肯定携带：content-type，但是本次解码结果中没有。可以认为本次有解码异常的头部字段。结合该服务头部字段出现顺序的统计结果(见例一)，可以确定62对应的头部字段解码异常。可以修复62索引值得表项：表项名为：content-type；表项值application/json。及解码前动态表的内容如以下表21所示。
表21
| 62 | ：accept-encoding | gzip |
| 63 | user-agent | Mozilla/5.0 |
| 64 | ：path | /nsmf-pdusession/v1/sm-contexts/1/modify |
| 65 | ：path | /resource |
| 66 | ：host | example.com |
| 67 | accept | image/jgeg |
| 68 | ：authority | 10.10.10.10：80 |
修复后动态表的内容为如下表22所示。
表22
| 62 | ：content-type | application/json |
| 63 | user-agent | Mozilla/5.0 |
| 64 | ：path | /nsmf-pdusession/y1/sm-contexts/1/modify |
| 65 | ：path | /resource |
| 66 | ：host | example.com |
| 67 | accept | image/jgeg |
| 68 | ：authority | 10.10.10.10：80 |
在第六示例中，可以按照“服务+源IP地址+头部字段”的各种排列为维度统计移动通信网络各设备发送各种服务的HEADER帧中各种头部字段排列出现的顺序的概率。
如果我们收到IP1地址发送的/sm-contexts/{smContextRef}/modify的服务器中解码结果如下表23所示。
表23
| 头字段索引 | 头字段名 | 头字段值 |
| 68 | ：authority | 10.10.10.10：80 |
| 3 | ：method | post |
| 64 | ：path | /nsmf-pdusession/v1/sm-contexts/1/modify |
| 6 | ：scheme | http |
| 62 | ：accept-encoding | gzip |
解码结果的头字段序列：1)：authority；2)：method；3)：path；4)：scheme；5)：accept-encoding。基本没有出现过，可以猜测可能出现了解码异常，尝试修复。
通过学习知道该服务与只相似头部字段顺序1)：authority；2)：method；
3)：path；4)：scheme；5)：content-type出现的概率很高，可以尝试用该序列修复；及可以认为头字段索引62解码出来的值是异常的，可以修复62索引值得表项：表项名为content-type；表项值application/json。
解码前动态内容为如下表24所示。
表24
| 62 | ：accept-encoding | gzip |
| 63 | user-agent | Mozilla/5.0 |
| 64 | ：path | /nsmf-pdusession/v1/sm-contexts/1/modify |
| 65 | ：path | /resource |
| 66 | ：host | example.com |
| 67 | accept | image/jgeg |
| 68 | ：authority | 10.10.10.10：80 |
修复后动态表内容为如下表25所示。
表25
| 62 | ：content-type | application/json |
| 63 | user-agent | Mozilla/5.0 |
| 64 | ：path | /nsmf-pdusession/v1/sm-contexts/1/modify |
| 65 | ：path | /resource |
| 66 | ：host | example.com |
| 67 | accept | image/jgeg |
| 68 | ：authority | 10.10.10.10∶80 |
本发明的另一个具体实施例，公开了一种基于HTTP2协议的数据传输装置。参考图7，基于HTTP2协议的数据传输装置包括：发送端和接收端，其中，发送端包括请求生成模块702、编码模块704和传送模块706，以及接收端包括解码模块708和修复模块710。请求生成模块702用于生成多个发送端请求，其中，每个发送端请求包括报头帧和请求数据帧，报头帧包括多个报头字段。编码模块704用于按照编码格式对多个报头字段中的每个报头字段进行编码以形成多个编码报头字段作为压缩的报头帧，其中，编码格式包括报头字段索引格式编码、报头字段增量索引带索引名称格式编码、报头字段增量索引带文字名称格式编码、报头字段不索引带索引名称格式编码和报头字段不索引带文字名称格式编码。传送模块706用于将每个发送端请求中的压缩的报头帧和请求数据帧分别地顺序传送至接收端。解码模块708用于对每个发送端请求中的每个编码报头字段按照编码格式分别地顺序进行解码。修复模块710用于当解码失败时启动解码异常修复机制。
基于HTTP2协议的数据传输装置还包括多个其他模块。由于基于HTTP2协议的数据传输方法对应于基于HTTP2协议的数据传输装置，所以为了避免赘述，本文中省略了多个其他模块的详细描述。
与现有技术相比，本发明至少可实现如下有益效果之一：
1、在解码失败时，启动单报头字段解码异常修复机制，避免直接错误返回和数据重传，从而提高了数据传输速度和效率，并能够及时参与XDR合成等后续处理。
2、在出现HTTP/2头部帧解码异常的情况下，启动修复机制对解码结果和动态表做修复处理，保证在丢包等情况下在尽量解码出后续处理需要的报头字段，并尽可能短时间内重同步动态表。
3、在3GPP规范中某些操作中某些报头字段是固定的，如对于某些操作method或status是固定的，那么如果没有解码出来method或status报头字段或者解码出来的method或status报头字段和3GPP规范不一致那么可以根据3GPP规范修复。
4、本申请的实施例将同一个网元同一个PATH类型的HEADER中携带的报头字段内容和报头字段顺序基本相同。基于这个认知，对成功的HEADER帧解码，我们按照设备+PATH类型为维度统计出现的报头字段和出现报头字段的顺序。我们可以使用统计结果对解码异常报头字段进行修复。
本领域技术人员可以理解，实现上述实施例方法的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于计算机可读存储介质中。其中，所述计算机可读存储介质为磁盘、光盘、只读存储记忆体或随机存储记忆体等。
以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。
Claims (10)
1.一种基于HTTP2协议的数据传输方法，其特征在于，包括：
生成多个发送端请求，其中，每个发送端请求包括报头帧和请求数据帧，所述报头帧包括多个报头字段；
按照编码格式对所述多个报头字段中的每个报头字段进行编码以形成多个编码报头字段作为压缩的报头帧，其中，所述编码格式包括报头字段索引格式编码、报头字段增量索引带索引名称格式编码、报头字段增量索引带文字名称格式编码、报头字段不索引带索引名称格式编码和报头字段不索引带文字名称格式编码；
将所述每个发送端请求中的所述压缩的报头帧和所述请求数据帧分别地顺序发送至接收端；以及
对所述每个发送端请求中的每个编码报头字段按照编码格式分别地顺序进行解码，并且当解码失败时启动解码异常修复机制。
2.根据权利要求1所述的基于HTTP2协议的数据传输方法，其特征在于，对所述多个编码报头字段中的每个编码报头字段按照编码格式分别地顺序进行解码，并且当解码失败时启动解码异常修复机制进一步包括：
识别一个编码报头字段的编码格式；
基于识别的编码格式对被识别的编码报头字段进行解码并判断解码是否成功，其中，
当解码成功时，将解码出来的报头字段加入报头字段列表；以及当识别的编码格式为所述报头字段增量索引带索引名称格式编码或者所述报头字段增量索引带文字名称格式编码时，将解码出来的报头字段插入动态表并将所述动态表的开始表项的状态设置为非丢包状态；
当解码失败时，启动单报头字段解码异常修复机制。
3.根据权利要求2所述的基于HTTP2协议的数据传输方法，其特征在于，启动单报头字段解码异常修复机制进一步包括：
当基于索引值在索引表中进行检索并且没有检索到与所述索引值相对应的记录内容时，确定所述动态表关联的TCP链接上丢失携带有所述报头字段增量索引带索引名称或者所述报头字段增量索引带文字名称的报头字段的报头帧；以及
根据所述索引值在所述动态表中插入空报头字段以供后续的修改机制使用并将插入位置的表项的状态设置为丢包状态，其中，所述索引表包括静态表和所述动态表，所述静态表的索引值为1至61以及所述动态表的索引值大于等于62。
4.根据权利要求2所述的基于HTTP2协议的数据传输方法，其特征在于，启动单报头字段解码异常修复机制包括：
当解码出来的报头字段名称和报头字段值不对应时，根据所述报头字段值推导所述报头字段名称以修改解码出来的报头字段和动态表，其中，所述报头字段包括报头字段名称和报头字段值。
5.根据权利要求3所述的基于HTTP2协议的数据传输方法，其特征在于，在所述多个编码报头字段解码完成以后，还包括：
检查所述报头字段列表中是否还存在解码异常的报头字段；以及
当存在解码异常的报头字段时，启动基于3GPP规范和正常解码统计结构的修复机制。
6.根据权利要求5所述的基于HTTP2协议的数据传输方法，其特征在于，启动基于3GPP规范和正常解码统计结构的修复机制还包括：
在接收到所述请求数据帧之后，根据所述请求数据帧中的所有信息单元，确定与所述请求数据帧相对应的所述报头帧中的多个报头字段；以及
根据确定的多个报头字段，修复所述解码异常的报头字段，以恢复所述空报头字段并将所述插入位置的表项的状态修改为非丢包状态。
7.根据权利要求5或6所述的基于HTTP2协议的数据传输方法，其特征在于，启动基于3GPP规范和正常解码统计结构的修复机制还包括：
在同一设备和同一类型的报头帧的情况下，预先存储解码成功的报头帧的多个报头字段和出现报头字段的顺序；
根据存储的解码成功的报头帧中报头字段和出现报头字段的顺序，对所述解码异常的报头字段进行修复。
8.根据权利要求1所述的基于HTTP2协议的数据传输方法，其特征在于，按照编码格式对所述多个报头字段中的每个报头字段进行编码以形成多个编码报头字段作为压缩的报头帧进一步包括：
在静态表和动态表中查询报头字段；
当所述报头字段在所述静态表或所述动态表中时，按照所述报头字段索引格式对所述报头字段进行编码；
当所述报头字段不在所述静态表或所述动态表中时，根据报头字段名称是否在所述静态表或所述动态表中以及是否将所述报头字段放入所述动态表中，按照除所述报头字段索引格式之外的编码格式对所述报头字段进行编码，其中，所述报头字段包括报头字段名称和报头字段值。
9.根据权利要求8所述的基于HTTP2协议的数据传输方法，其特征在于，根据报头字段名称是否在所述静态表或所述动态表中以及是否将所述报头字段放入所述动态表中，按照除所述报头字段索引格式之外的编码格式对所述报头字段进行编码进一步包括：
当所述报头字段名称在所述静态表或所述动态表中并且将所述报头字段放入所述动态表中时，按照报头字段增量索引名称格式对所述报头字段进行编码；
当所述报头字段名称在所述静态表或所述动态表中并且所述报头字段不放入所述动态表中时，按照报头字段不索引带索引名称格式对所述报头字段进行编码；
当所述报头字段名称不在所述静态表或所述动态表中并且将所述报头字段放入所述动态表中时，按照报头字段增量索引带文字名称格式对所述报头字段进行编码；以及
当所述报头字段名称不在所述静态表或所述动态表中并且所述报头字段不放入所述动态表中时，按照报头字段不索引带文字名称格式对所述报头字段进行编码。
10.一种基于HTTP2协议的数据传输装置，其特征在于，包括：发送端和接收端，其中，所述发送端包括请求生成模块、编码模块和传送模块，以及所述接收端包括解码模块和修复模块，其中，
所述请求生成模块，用于生成多个发送端请求，其中，每个发送端请求包括报头帧和请求数据帧，所述报头帧包括多个报头字段；
所述编码模块，用于按照编码格式对所述多个报头字段中的每个报头字段进行编码以形成多个编码报头字段作为压缩的报头帧，其中，所述编码格式包括报头字段索引格式编码、报头字段增量索引带索引名称格式编码、报头字段增量索引带文字名称格式编码、报头字段不索引带索引名称格式编码和报头字段不索引带文字名称格式编码；
所述传送模块，用于将所述每个发送端请求中的所述压缩的报头帧和所述请求数据帧分别地顺序传送至接收端；
所述解码模块，用于对所述每个发送端请求中的每个编码报头字段按照编码格式分别地顺序进行解码；以及
所述修复模块，用于当解码失败时启动解码异常修复机制。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111122426.0A CN115883682A (zh) | 2021-09-24 | 2021-09-24 | 一种基于http2协议的数据传输方法和装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111122426.0A CN115883682A (zh) | 2021-09-24 | 2021-09-24 | 一种基于http2协议的数据传输方法和装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115883682A true CN115883682A (zh) | 2023-03-31 |
Family
ID=85762391
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111122426.0A Pending CN115883682A (zh) | 2021-09-24 | 2021-09-24 | 一种基于http2协议的数据传输方法和装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115883682A (zh) |
-
2021
- 2021-09-24 CN CN202111122426.0A patent/CN115883682A/zh active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9166931B2 (en) | Method and device for improving robustness of context update message in robust header compression | |
| EP1378064B1 (en) | Method and system for providing a context for message compression | |
| US9246630B2 (en) | Method, device, and system for forward error correction | |
| US7779336B2 (en) | Assembling forward error correction frames | |
| CN110943800B (zh) | 数据包的发送方法、装置及系统、存储介质、电子装置 | |
| US20030023915A1 (en) | Forward error correction system and method for packet based communication systems | |
| CN111385268B (zh) | 一种数据包头压缩确认方法及通信设备 | |
| US20160020872A1 (en) | Encoding and decoding methods and apparatuses of ethernet physical layer | |
| CN106656424B (zh) | 一种数据传输的校验方法 | |
| US9654255B2 (en) | Data transmission method and device | |
| KR102383892B1 (ko) | 미디어 콘텐츠 기반의 자가 적응 시스템 코드 fec의 코딩 및 디코딩 방법, 장치, 시스템 및 매체 | |
| CN115134138B (zh) | 一种基于单向光闸的文件同步方法 | |
| EP1392025A2 (en) | Wireless communication method and wireless communication device | |
| WO2021190031A1 (zh) | 基于wdm的数据传输方法、装置、系统及存储介质 | |
| CN113364508A (zh) | 一种语音数据的传输控制方法、系统及设备 | |
| KR100624619B1 (ko) | 광대역 무선통신시스템에서의 패킷 데이터 서비스를 위한데이터 송수신 방법 | |
| CN115883682A (zh) | 一种基于http2协议的数据传输方法和装置 | |
| CN108769000B (zh) | 一种用于深空环境的高效流媒体传输方法 | |
| CN1863311B (zh) | 传输视频数据的方法 | |
| CN115883683A (zh) | 一种报头解码方法和装置 | |
| KR20020019334A (ko) | 비동기식 무선통신 시스템에서의 하이브리드 자동재전송요구 2/3 방식 적용 방법과 그의 성능 향상을 위한에러 처리 방법 | |
| CN113517950B (zh) | 一种信号收发方法、系统及介质 | |
| CN114337917B (zh) | 基于前向纠错数据传输方法和短报文发送方法 | |
| CN116896567B (zh) | 网络层协议传输数据方法和装置 | |
| US11323135B2 (en) | Polar code coding, polar code decoding method, apparatus and device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |