CN115883683B

CN115883683B - Header decoding method and device

Info

Publication number: CN115883683B
Application number: CN202111125652.4A
Authority: CN
Inventors: 崔传金; 卞忠鸣
Original assignee: Beijing Zhongchuang Telecom Test Co Ltd
Current assignee: Beijing Zhongchuang Telecom Test Co Ltd
Priority date: 2021-09-24
Filing date: 2021-09-24
Publication date: 2024-09-20
Anticipated expiration: 2041-09-24
Also published as: CN115883683A

Abstract

The invention relates to a header decoding method and a header decoding device, belongs to the technical field of network protocols, and solves the problem that the whole data packet cannot be processed later due to direct error return when decoding errors are encountered in the prior art. The method comprises the following steps: receiving a HEADER frame from a sender and the HEADER frame comprising a plurality of encoded HEADER fields; the following steps are sequentially performed for each of the plurality of encoded header fields, respectively: identifying a coding format for coding the header field, wherein the coding format comprises a header field index format coding, a header field delta index tape index name format coding, and the like; decoding the identified coded header field based on the identified coding format and determining whether the decoding is successful; and when decoding fails, starting a single header field decoding exception repair mechanism. When decoding fails, a single header field decoding exception repair mechanism is started to avoid direct error return.

Description

Header decoding method and device

Technical Field

The present invention relates to the field of network protocols, and in particular, to a method and apparatus for decoding a header.

Background

In general, the HTTP/2 transport layer adopts the TCP protocol, which provides a connection-oriented, reliable and byte stream-based transport layer communication protocol, that is, it can ensure that data received by both the client and the service will not have abnormal conditions such as disorder and loss, which is also a requirement of HAPCK protocol on the underlying transport. Namely, the decryption rate of header compression can certainly reach hundred percent as long as the received data packet is ensured not to have abnormal conditions such as disorder, loss and the like.

However, in the application field of the network protocol monitoring and analyzing technology, bypass means such as light splitting are generally adopted to obtain the data packet of HTTP2, and the following anomalies may occur in the data obtained by the application system in the bypass mode inevitably:

1. HTTP2 long connection results in a packet between the beginning of the lost connection and the start of the acquisition resolution device:

The long connection means that the client initiates connection to the server, the server receives the connection of the client, the client and the server establish connection, after completing a request, the connection between the client and the server is not actively closed, and the subsequent read-write operation can continue to use the connection. The HTTP2 link between 5G core network (5 GC) devices is mostly a long connection, and the data source for signaling acquisition is usually after the long connection has been established, which means that the data entering the acquisition device is the data that has been header compressed from the moment of access, and the decoding procedure will not get a dynamic table negotiated by the communication network element before the procedure is started.

2. Message loss: if the HTTP/2 header frame carrying the header text with the increment index is lost, the dynamic table is inconsistent with the reality, and decoding information of subsequent header frames can be lost or error decoding results can be obtained.

The effect of packet loss on HTTP2 decoding is illustrated below with reference to fig. 1: scenario HADER _1 six header fields ：1)method：GET;2)：scheme：https;3)：host：example.com;4)：path：/resource;5)accept：image/jgeg;6)user-agent：Mozilla/5.0. are sent, of which four header fields 3, 4, 5, 6 are added to the dynamic table, which is shown in table 1 below.

TABLE 1

62	user-agent	Mozilla/5.0
			63	accept	image/jgeg
64	：path	/resource
			65	：host	example.com

HEADER_3 sends 6 HEADER fields ：1)method：GET;2)：scheme：https;3)：host：example.com;4)：path：/new_resource;5)accept：image/jgeg;6)user-agent：Mozilla/5.0.

Wherein 3,5,6 are encoded in a header field index format; 4 encoded in header field delta index indexed name format. The post-message dynamic table is shown in table 2 below.

TABLE 2

62	：path	/new_resource
			63	user-agent	Mozilla/5.0
64	accept	image/jgeg
			65	：path	/resource
66	：host	example.com

But in the case where bypass is a possible packet loss, it is now assumed that the HEAD1 packet is lost and the HEAD3 table is received directly:

Because the HEAD1 packet is lost, the linked dynamic table is empty when HEAD3 is received, and the index ID values 64, 63, 62 are decoded in the header field index format when decoding is found, and the dynamic table is empty. At this point the decoder will typically consider that an exception is coming back directly. Leading to HEAR3 frame decoding failure.

If the bypass occurs in the abnormal situation, the following errors may occur in the header field decoding:

1. Header field index format: the decoded index value cannot find the corresponding record in the dynamic table and the static table;

2. Header field delta index with index name format: the decoded name index value cannot find the corresponding record in the dynamic table and the static table; or the name found with the index value does not correspond to the value of the decoded header field. For example, the decoded header field name is method, and the value is 156;156 are not within the method valid value range, the decoded header field is certainly abnormal.

3. The header field does not index the indexed name format: the decoded name index value cannot find the corresponding record in the dynamic table and the static table; or the name found with the index value does not correspond to the value of the decoded header field. For example, the decoded header field name is method, and the value is 156;156 are not within the method valid value range, the decoded header field is certainly abnormal.

Referring to fig. 2, the conventional decoding scheme encounters the above decoding error and returns directly, so that the entire data packet cannot participate in the subsequent processes such as XDR synthesis. To reduce the impact of the above factors on decoding and subsequent XDR synthesis, we have introduced a checking and repair mechanism that complements the decoding and dynamic table mechanism, decodes as many normal header field lists as possible and resynchronizes the dynamic table in as short a time as possible.

Disclosure of Invention

In view of the above analysis, the embodiments of the present invention aim to provide a method and an apparatus for decoding a header, so as to solve the problem that the whole data packet cannot participate in the subsequent processing such as XDR synthesis due to the fact that the decoding error encountered by the existing decoding method returns directly.

In one aspect, an embodiment of the present invention provides a header decoding method, including: receiving a HEADER frame from a sender and the HEADER frame comprising a plurality of encoded HEADER fields; the following steps are sequentially performed for each of the plurality of encoded header fields, respectively: identifying a coding format for coding the header field, wherein the coding format comprises a header field index format code, a header field delta index tape index name format code, a header field delta index tape literal name format code, a header field non-index tape index name format code and a header field non-index tape literal name format code; decoding the identified coded header field based on the identified coding format and determining whether the decoding is successful; and when decoding fails, starting a single header field decoding exception repair mechanism.

The beneficial effects of the technical scheme are as follows: when decoding fails, a single header field decoding exception repair mechanism is started, so that direct error return is avoided, and further the problem that the whole data packet cannot participate in subsequent processing such as XDR synthesis and the like can be prevented.

Based on a further improvement of the above method, the header decoding method further comprises: when the decoding is successful, adding the decoded header fields into a header field list; and when the identified coding format is header field increment index name format coding or header field increment index with literal name format coding, inserting the decoded header field into a dynamic table and setting the packet loss state of the starting table entry of the dynamic table to be a default value of 0.

Based on a further improvement of the above method, initiating a single header field decoding exception repair mechanism includes: determining that a HEADER frame is lost on a TCP link associated with the dynamic table when no record content corresponding to the index value is retrieved in the index table based on the index value, wherein the HEADER frame carries a HEADER field encoded in a HEADER field increment index tape index name format or a HEADER field encoded in a HEADER field increment index tape literal name format; and inserting an empty header field into the dynamic table according to the index value and setting the packet loss state of an entry corresponding to the index value in the dynamic table to be 1, wherein the index table comprises a static table and the dynamic table, the index value of the static table is 1 to 61, and the index value of the dynamic table is more than or equal to 62.

Based on a further improvement of the above method, initiating a single header field decoding exception repair mechanism includes: when the decoded header field name and the header field value do not correspond, deriving the header field name from the header field value to modify the decoded header field and the dynamic table, wherein the header field comprises the header field name and the header field value.

Based on a further improvement of the above method, after the decoding of the plurality of encoded header fields is completed, further comprising: checking whether a header field with abnormal decoding exists in the header field list; and when present, initiating a repair mechanism based on the 3GPP specification and normal decoding statistics.

Based on a further improvement of the above method, initiating a repair mechanism based on the 3GPP specifications and normal decoding statistics structure further comprises: after receiving the HEADER frame, receiving a DATA frame; determining a HEADER field in the HEADER frame corresponding to the DATA frame from all information elements in the DATA frame; and repairing the HEADER field of the decoding exception according to the determined HEADER field in the HEADER frame.

Based on a further improvement of the above method, initiating a repair mechanism based on the 3GPP specifications and normal decoding statistics structure further comprises: storing HEADER fields and the sequence in which the HEADER fields appear in the HEADER frame that is successfully decoded under the condition of the same equipment and the same type of HEADER frame; and repairing the HEADER field with abnormal decoding according to the HEADER field in the stored successfully decoded HEADER frame and the sequence of the HEADER field.

Based on a further improvement of the above method, prior to receiving the HEADER frame, further comprising encoding each of a plurality of HEADER fields to obtain a HEADER frame to be transmitted by: querying header fields in the static table and the dynamic table; encoding the header field according to a header field index format when the header field is in the static table or the dynamic table; when the header field is not in the static table or the dynamic table, the header field is encoded in an encoding format other than the header field index format according to whether a header field name is in the static table or the dynamic table and whether the header field is placed in the dynamic table, wherein the header field includes a header field name and a header field value.

Based on a further improvement of the above method, encoding the header field according to an encoding format other than the header field index format further comprises, depending on whether a header field name is in the static table or the dynamic table and whether the header field is placed in the dynamic table: encoding the header field in a header field delta index name format when the header field name is in the static table or the dynamic table and the header field is placed in the dynamic table; when the header field name is in the static table or the dynamic table and the header field is not put in the dynamic table, encoding the header field in a header field non-indexed name format; encoding the header field in a header field delta index literal name format when the header field name is not in the static table or the dynamic table and the header field is placed in the dynamic table; and when the header field name is not in the static table or the dynamic table and the header field is not placed in the dynamic table, encoding the header field in a header field non-indexed literal name format.

In another aspect, an embodiment of the present invention provides a header decoding apparatus including: a receiving module for receiving a HEADER frame from a sender and the HEADER frame comprising a plurality of encoded HEADER fields; the identification module is used for identifying an encoding format of an encoding header field, wherein the encoding format comprises a header field index format encoding, a header field increment index tape index name format encoding, a header field increment index tape literal name format encoding, a header field non-index tape index name format encoding and a header field non-index tape literal name format encoding; a decoding module for encoding the identified encoded header field based on the identified encoding format; the judging module is used for judging whether the decoding is successful or not; and the repair module is used for starting a single header field decoding exception repair mechanism when decoding fails. Compared with the prior art, the invention has at least one of the following beneficial effects:

1. when decoding fails, a single header field decoding exception repair mechanism is started, so that direct error return is avoided, and further the problem that the whole data packet cannot participate in subsequent processing such as XDR synthesis and the like can be prevented.

2. Under the condition of abnormal HTTP/2 head frame decoding, a repairing mechanism is started to repair the decoding result and the dynamic table, so that the header fields required by subsequent processing are decoded as much as possible under the condition of packet loss and the like, and the dynamic table is resynchronized within the shortest time possible.

3. Some of the header fields are fixed in some operations in the 3GPP specifications, e.g., fixed for some operations methods or status, then the method or status header fields may be repaired according to the 3GPP specifications if not decoded or if the decoded method or status header fields are inconsistent with the 3GPP specifications.

4. The embodiment of the application basically has the same HEADER field content and HEADER field sequence carried in the HEADER of the same PATH type of the same network element. Based on this knowledge, we count the HEADER fields that appear and the order in which the HEADER fields appear for the dimension by device+path type, for successful HEADER frame decoding. We can use the statistics to repair the decoded exception header field.

In the invention, the technical schemes can be mutually combined to realize more preferable combination schemes. Additional features and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The objectives and other advantages of the invention may be realized and attained by the structure particularly pointed out in the written description and drawings.

Drawings

The drawings are only for purposes of illustrating particular embodiments and are not to be construed as limiting the invention, like reference numerals being used to refer to like parts throughout the several views.

Fig. 1 is an example of information transfer between a client and a server using HAPCK protocols.

Fig. 2 is a block diagram of a conventional header decoding method.

Fig. 3 is a flowchart of a header decoding method according to an embodiment of the present invention.

Fig. 4 is a diagram of a 5G network architecture and associated interface protocols.

Fig. 5 is a flowchart of a header encoding method according to an embodiment of the present invention.

Fig. 6 is a flowchart showing a header decoding method according to an embodiment of the present invention.

Fig. 7 is a block diagram of a header decoding apparatus according to an embodiment of the present invention.

Fig. 8 is a diagram of a static representation used by HPACK.

Fig. 9 is a HPACK head compression schematic.

Detailed Description

The following detailed description of preferred embodiments of the application is made in connection with the accompanying drawings, which form a part hereof, and together with the description of the embodiments of the application, are used to explain the principles of the application and are not intended to limit the scope of the application.

In one embodiment of the present invention, a header decoding method is disclosed. Referring to fig. 3, a header decoding method includes: step S302, receiving a HEADER frame from a sender and the HEADER frame comprises a plurality of coding HEADER fields; the following steps are sequentially performed for each of the plurality of encoded header fields: step S304, identifying the coding format of the coded header field, wherein the coding format comprises a header field index format code, a header field increment index tape index name format code, a header field increment index tape literal name format code, a header field non-index tape index name format code and a header field non-index tape literal name format code; step S306, decoding the identified coded header field based on the identified coding format and judging whether the decoding is successful; and step S308, when decoding fails, starting a single header field decoding exception repair mechanism.

Compared with the prior art, the header decoding method provided by the embodiment starts a single header field decoding exception repair mechanism when decoding fails, so that direct error return is avoided, and further, the whole data packet cannot participate in XDR synthesis (XDR synthesis: collecting and processing the whole data of the operator communication network to generate an XDR record), wherein the XDR is a service detailed record which is generated for a signaling monitoring platform and a signaling application after being processed based on the whole data of the operator communication network.

Hereinafter, a header decoding method according to an embodiment of the present invention will be described in detail with reference to fig. 3 to 6.

Referring to fig. 3, the header decoding method includes: step S302, a HEADER frame is received from a sender and includes a plurality of encoded HEADER fields. Specifically, an HTTP/2 request is split into two frames: a HEADER frame and a DATA frame, wherein the HEADER frame is HEADER compressed and the DATA frame is the request content frame in plaintext. The content of the DATA frame is defined by the 3GPP specifications in the field of mobile communications.

The following steps are sequentially performed for each of the plurality of encoded header fields: step S304, the coding format of the coded header field is identified, wherein the coding format comprises a header field index format code, a header field increment index tape index name format code, a header field increment index tape literal name format code, a header field non-index tape index name format code and a header field non-index tape literal name format code.

Referring to fig. 5, before receiving the HEADER frame, further comprising encoding each of the plurality of HEADER fields to obtain the HEADER frame to be transmitted by: querying the header fields in the static table and the dynamic table; encoding the header fields according to a header field index format when the header fields are in a static table or a dynamic table; when the header field is not in the static table or the dynamic table, the header field is encoded in an encoding format other than the header field index format, wherein the header field includes a header field name and a header field value, depending on whether the header field name is in the static table or the dynamic table and whether the header field is placed in the dynamic table. Encoding the header field according to an encoding format other than the header field index format, depending on whether the header field name is in the static table or the dynamic table and whether the header field is placed in the dynamic table, further comprises: encoding the header fields in a header field delta index name format when the header field names are in a static table or a dynamic table and the header fields are placed in the dynamic table; when the header field name is in the static table or the dynamic table and the header field is not placed in the dynamic table, encoding the header field in a format in which the header field is not indexed with the indexed name; encoding the header field in a header field delta index literal name format when the header field name is not in the static table or the dynamic table and the header field is placed in the dynamic table; and when the header field name is not in the static table or the dynamic table and the header field is not placed in the dynamic table, encoding the header field in a header field non-indexed literal name format.

Step S306, decoding the identified encoded header field based on the identified encoding format and determining whether the decoding is successful. When the decoding is successful, adding the decoded header fields into a header field list; and when the identified coding format is header field increment index name format coding or header field increment index literal name format coding, inserting the decoded header field into the dynamic table and setting the packet loss state of the starting table entry of the dynamic table to be a default value of 0. The packet loss state value includes 0 and 1, and the default value of 0 represents that the packet loss state is in a non-packet loss state, and 1 represents that the packet loss state is in a packet loss state.

Step S308, when decoding fails, a single header field decoding exception repair mechanism is started. The method for starting the single header field decoding exception repair mechanism comprises the following steps: determining that a HEADER frame is lost on a TCP link associated with the dynamic table when no record content corresponding to the index value is retrieved in the index table based on the index value, wherein the HEADER frame carries a HEADER field encoded in a HEADER field delta index tape index name format or a HEADER field encoded in a HEADER field delta index tape literal name format; and inserting an empty header field into the dynamic table according to the index value and setting the packet loss state of an entry corresponding to the index value in the dynamic table as 1, wherein the index table comprises a static table and the dynamic table, the index value of the static table is 1 to 61, and the index value of the dynamic table is more than or equal to 62. In an alternative embodiment, initiating the single header field decoding exception repair mechanism includes: when the decoded header field name and the header field value do not correspond, the header field name is derived from the header field value to modify the decoded header field and the dynamic table, wherein the header field includes the header field name and the header field value.

After decoding the plurality of encoded header fields is completed, further comprising: checking whether a header field with abnormal decoding exists in the header field list; and when present, initiating a repair mechanism based on the 3GPP specification and normal decoding statistics. Specifically, initiating a repair mechanism based on the 3GPP specifications and normal decoding statistics structure further includes: receiving a DATA frame, or after receiving a HEADER frame; determining a HEADER field in the HEADER frame corresponding to the DATA frame based on all of the information elements in the DATA frame; and repairing the HEADER field of the decoding exception according to the HEADER field in the determined HEADER frame. Initiating a repair mechanism based on the 3GPP specifications and normal decoding statistics structure further comprises: storing HEADER fields and the sequence in which the HEADER fields appear in the HEADER frame that is successfully decoded under the condition of the same equipment and the same type of HEADER frame; and repairing the HEADER field with abnormal decoding according to the HEADER field in the stored successfully decoded HEADER frame and the sequence of the HEADER field.

Hereinafter, a header decoding method according to an embodiment of the present invention will be described in detail by way of specific examples with reference to fig. 4 to 6.

HTTP/2 header compression principle

Http1.X has long been a problem due to its design drawbacks, one of which is the nonsensical repetitive head. Various solutions have emerged, such as Google designs the SPDY protocol directly on the basis of http1.X, compresses the header using the deflate algorithm, and solves the problems of multiplexing and priority. HTTP2 is implemented with reference to the SPDY protocol, but a set of compression algorithms is designed specifically for header compression, HPACK (e.g., header Compression for HTTP2-RFC 7541).

Referring to fig. 9, hpack looks up HEADER field list (HEADER LIST) to an ordered set of HEADER fields (name-value pairs in HTTP/2Header Field,HTTP/2HEADER frames), and HPACK sequentially compresses and decompresses each HEADER field pair.

HPACK use 2 index tables (static table and dynamic table) to map the message field to index value, and use Huffman coding for header fields not existing in static table and dynamic table, and dynamically buffer to dynamic table, thus achieving the effect of compressing header. Referring to fig. 8, a Static Table (Static Table) consists of a Static list of header fields predefined by HPACK protocol (i.e., 61 commonly used header fields), with index values from 1-61. The static table is read-only, and neither the entry nor its location (index value) can be changed. For example, FIG. 8 lists all static table entries. A Dynamic Table (dynamically maintained header field list for eliminating redundant header fields) is also composed of a series of header fields, but elements therein are not fixed, and new entries are inserted or existing entries are deleted as needed in the actual encoding process. The HPACK protocol requires that the static table be merged with the dynamic table in the same memory space, with the static table at the front and the dynamic table immediately following. The index of the first entry of the dynamic table will be 62 throughout the index table space. The dynamic table is maintained on a first-in first-out basis (FIFO, with the latest entry at the lowest index and the oldest entry at the highest index). When adding an entry to the dynamic table, it will always be inserted from bit 62 and the original entry will all be moved one position to the right. When an entry is deleted from the dynamic table, it will always be deleted from the last bit.

HPACK the whole compression and decompression process: the data transmitting end autonomously decides which header fields need to be added into the dynamic table, adds the dynamic table according to HPACK specifications and compresses and encodes, and after all header dictionary codes are completed, the data packet is transmitted to the data receiving end; the data receiving end receives the data packet and decodes the data packet according to HPACK specifications to restore a header field list and a dynamic list which are the same as those of the data transmitting end.

Referring to the header compression schematic of fig. 9, the sender prepares to send 1)method:GET;2):scheme:https;3):host:example.com;4):path:/resource;5)user-agent:Mozilla/5.0;6)custom－hdr：some－value of these 6 header fields. There are now two entries in the dynamic table of the index table: user-agent at 62 index: mozilla/5.0; at 63 index host: example. Method 1: the GET header field is in the position of 2 of the static table, which header field is encoded as index value "2" in the index table at the time of encoding; scheme 2 https header field is in the 7 position of the static table, and the header field is encoded into an index value of 7 in the index table when encoded; host: sample. Com in the second position of the dynamic table, corresponding to index 63 in the index table, the header field is encoded as index value "63" in the index table at the time of encoding; the 4 th step is that the header field name in the path/resource header field is in the position of the static table 19, and the coding end selects to adopt the format of the header field increment index band index name and the header field name during coding: the path' is encoded into an index value in an index table, and the value of the header field adopts a huffman coding method; the 5 th user-agent is Mozilla/5.0 header field corresponding to the value 62 in the index table at the first position in the dynamic table, and the header field is encoded into an index value 62' in the index table when encoded; 6 th customer-hdr: the header field name of the name-value header field is not in the dynamic table and the static table, the coding end selects to adopt a format of 'the header field is not indexed with literal names', the header field name is coded into a huffman (coustom-hdr), and the header field value is coded into a huffman (name-value). Hereinafter, the entire compression process according to HPACK specifications is described. Referring to fig. 5, hpacks encode each header field sequentially in accordance with the header list:

1. static and dynamic dictionaries are looked up. If the header field is fully present in the dynamic table, it is encoded using the header field index format (Indexed HEADER FIELD presentation, encoding a header field using the index value in the dynamic table or the static table). This typically consumes one byte, a maximum of two bytes being sufficient. This strategy has a very high success rate because many heads are repetitive.

GET if 1) method in the HPACK head compression schematic above; 2) Scheme, https; 3) Host: sample. 5) user-agent Mozilla/5.0 four header fields encoded as 2, 7, 63, 62 index values, each occupying one byte.

2. When it is not possible to match a complete header field in both static and dynamic tables. Attempting to match the header field name in the static table and the dynamic table, if matching to get the index value of the header field name in the dynamic table or the static table.

3. It is decided whether to add the header field being encoded to the dynamic table. If the header field is to be added to the dynamic table, the first two bits of the code are 01; if the header field does not add to the dynamic table, the first four bits encoded are 0000.

4. If it is decided to add the header field of the additional encoding to the dynamic table, one of the two formats may be encoded using "header field delta Index with Index Name format encoding (LITERAL HEADER FIELD WITH INCREMENTAL Indexing-Index Name, get the Name from the header Index value to the dynamic table or static table, get the header field value directly, form the header field to be appended to the decoded header list; and insert it as a New entry into the dynamic table)", or "header field delta Index with literal Name format encoding (LITERAL HEADER FIELD WITH INCREMENTAL Indexing- -New Name. This format decoding, directly decoded to get the header field Name and header field value, form the header field to be appended to the decoded header list; and insert it as a New entry into the dynamic table)". "header field increment index with index name format coding" is that the value of header field name in the index table is not in the index table, the name is coded by the index value in the index table, the value is coded by huffman coding, and the above hpack header compression schematic ": path: the resource "header field is such that the encoding is employed. The header field increment index is coded with literal name format, namely the name and the value of the header field are not in an index table, the name and the value are coded by huffman, and the text-hdr in the hpack header compression schematic diagram is described above: the name-value is the code used. If both fields decide to add to the dynamic table, then the encoded dynamic table (see Table 3 below) is:

TABLE 3 Table 3

Static table

1
			2
…	…	…
			51	refer
…	…	…
			62	costom-hdr	some-value
63	：path	/resource
			64	user-agent	Mozilla/5.0
65	：host	example

Dynamic table

5. If it is decided not to add the encoded header field to the dynamic table, a "header field does not index the encoded header field with index Name format (LITERAL HEADER FIELD without Indexing-Indexed Name), which format decodes with the header index value to the dynamic table or static table to get the Name, directly gets the header value to form the guard field attached to the decoded header list, does not change the dynamic table and cannot insert the New entry into the dynamic table)" and a "header field does not index the encoded header field with literal Name format (LITERAL HEADER FIELD without Indexing-New Name), which format decodes directly to get the header field Name and header field value to form the guard field attached to the decoded header list, does not change the dynamic table and cannot insert the New entry into the dynamic table)" may be used. "header field is not indexed with index name format coding" is that the value of header field name in header field in index table is not in index table, name is coded by index value in index table, value is coded by huffman coding, and in the above hpack header compression schematic ": path: the resource "header field is such that the encoding is employed. The header field is not indexed with literal name format coding, namely the name and the value of the header field are not in an index table, the name and the value are coded by huffman, and the custom-hdr in the hpack header compression schematic is: the name-value is the code used. If the header field is not added to the dynamic table, the dynamic table is unchanged after the encoding is completed.

The core network subverts the traditional CT network architecture and protocol with reference to figure 4,5G, introducing a servitization interface.

Wherein the abbreviations of the network elements are defined as follows:

AUSF: authentication Server Function, authentication service function;

AMF: ACCESS AND Mobility Management Function access and mobility management functions;

SMF: session Management Function session management functions;

NSSF: network Slice Selection Function, a network slice selection function;

UDM: unified DATA MANAGEMENT, unified data management;

NEF: network Exposure Function, network exposure functions;

NRF: network Repository Function, network registration function;

PCF: policy Control Function, policy control functions;

UPF: user Plane Function, user plane functions;

AF: application Function, application functions;

DN: data Network, data Network;

The interfaces Nnssf, nnef, nnrf, npcf, nudm, naf, nausf, namf and Nsmf in fig. 4 all communicate using the HTTP2 protocol. Because the key information such as operation type, operation resource, operation result and the like are in the dynamic table in order to improve the safety and the communication efficiency during HTTP2 communication; if this information is not decoded successfully it will affect the XDR synthesis. The accuracy of the dynamic header decompression of HTTP2 in the signaling acquisition and resolution system will determine the accuracy and availability of the overall system.

The invention increases the restoration mechanism to restore the decoding result and the dynamic table under the condition of abnormal HTTP/2 head frame decoding, ensures that the header fields required by the subsequent processing are decoded as much as possible under the condition of packet loss and the like, and resynchronizes the contents of the dynamic table in the shortest time as possible.

Referring to fig. 6, a header decoding method will be described in detail.

1. The coding format of the header field is judged.

2. The header field is decoded according to the encoding format of the header field.

3. If the header field is decoded successfully, it is checked whether the header field needs to be inserted into the dynamic table. The insertion of a dynamic table is required for header fields encoded using one of the two formats "header field delta index tape index name format encoding" or "header field delta index tape literal name format encoding". The current dynamic table contents are referred to below in table 4.

TABLE 4 Table 4

If a packet is received, decoding is encountered ": path: the/new_resource "header field needs to be inserted into the dynamic table; then the package ": path: the new_resource "is inserted into the dynamic table, and the contents of the dynamic table after the insertion is completed refer to table 5.

TABLE 5

4. If the header field decoding fails, a single header field decoding exception repair mechanism is initiated.

At this stage it can be found that the decoding failure is in the form of header field index, header field delta indexed name or header field not indexed name, etc., no value is found in the index table with the index value.

The error is typically encountered in that the dynamic table associated TCP link drops an HTTP2 Header frame carrying a Header field of "Header field delta index indexed name" or "Header field delta index indexed literal name". This time an empty header field needs to be inserted into the dynamic table for use by the subsequent repair mechanism. The insertion position is the position of the latest packet loss of the TCP link associated with the dynamic table. The link management of the TCP link of the TCP connection associated with the dynamic table finds that the TCP link has packet loss, and then sets the packet loss state of the starting table entry of the dynamic table to be 1 (default to 0); the packet loss position is traversed from the beginning of the dynamic table until the packet loss state with the table entry is 1 or the dynamic table ends. If the packet loss state of the dynamic table entry is 1, the insertion position is in front of the table entry; the insertion position is the end of the dynamic table if it has traversed all the way to the end of the dynamic table. For example, the current dynamic table contents refer to table 6.

TABLE 6

If the index value of the header field of a received data packet is 66, and the packet loss state of the table entry corresponding to 62 in the dynamic table is 0, and the packet loss state of 63 is 1; then an empty header field needs to be inserted before 63 and the contents of the dynamic table after insertion refer to table 7.

TABLE 7

62	user-agent	Mozilla/5.0
			63
64	accept	image/jgeg
			65	：path	/resource
66	：host	example.com

The value of index 66 is considered at this time to be ": host: example. Com ", the value of index 63 is null content.

5. After all the header fields are decoded, checking whether the header fields with abnormal decoding exist in the header field list.

6. If there is an abnormal header field, a repair mechanism based on 3GPP specifications is started.

(1) Some of the header fields are fixed in some operations in the 3GPP specifications, e.g., fixed for some operations methods or status, then the method or status header fields may be repaired according to the 3GPP specifications if not decoded or if the decoded method or status header fields are inconsistent with the 3GPP specifications.

For example, an operation method with path { apiRoot }/nsmf-pdusession/v1/sm-contexts must be post; the status of a successful response must be 201. Then if the method is decoded as put or status is 201, it is necessary to clear the method: index value sum stauts of put: index value of 201 corresponding entries.

For example: the dynamic table state at the beginning is shown in table 8 below

TABLE 8

62	user-agent	Mozilla/5.0
			63	method	put
64	accept	image/jgeg
			65	：path	/resource
66	：host	example.com

The received data packet decodes path { apiRoot }/nsmf-pdusession/v1/sm-contexts and method: put header field. method of: the input header field corresponds to an index of 63, then the 63 entry may be considered anomalous. Performing the repair operation may empty 63 the corresponding entry, and the dynamic table after performing the repair is shown in table 9.

TABLE 9

(2) Repair from DATA frame

An HTTP/2 request is split into two frames, a HEADER frame, which is HEADER compressed, and a DATA frame, which is the request content frame in plaintext. The content of the DATA frame is defined by the 3GPP specifications in the field of mobile communications.

If there is a HEADER field decoding exception when decoding HEADERS frames, the processing may be delayed until the DATA frame processing corresponding to the HEADER frame is completed. The header fields that need to be carried in HEADERS frames can be deduced from the decoded content of the DATA frame and the 3GPP specifications. If the header field to be carried is not full in the header field that we successfully decoded, these contents are certainly in the header field of the decoding exception. The range of values of the header field of the decoding exception can be known.

If there is only one header field of the decoding exception and there is a missing header field to be carried, then the value of the header field of the decoding exception can be determined, at which time the header field of the decoding exception can be corrected and the dynamic table repaired by adding the header field to the dynamic table in accordance with the index value.

Such as: according to the 3GPP specifications if all of the following information elements are present in the data message of the smf service:

-dnn

-vsmfId

-servingNetwork

-vsmfPduSessionUri

-vcnTunnelInfo

-anType

It can be confirmed that the service to which the data corresponds is:

{apiRoot}/nsmf-pdusession/v1/pdu-sessions

So that the headers frame corresponding to the data frame has the following header fields:

-method：post

content-length: length of data

Content-type: application/json or Multipart/related (content-type can be uniquely determined after data determination depending on the format of the data frame)

-path：{apiRoot}/nsmf-pdusession/v1/pdu-sessions

If content-type is not decoded at the time of decoding in the HEADER frame and an index of 63 does not get content in the dynamic table, it may be determined that the entry value corresponding to the index 63 is "content-type: application/json).

The contents of the dynamic table before decoding are as follows in table 10.

Table 10

Then the contents of the post-repair dynamic table are as follows table 11

TABLE 11

62	user-agent	Mozilla/5.0
			63	content-type	application/json
64	accept	image/jgeg
			65	：path	/resource
66	：host	example.com

In a second example, if all of the following information elements are present in the data message of udm services according to the 3GPP specifications:

-smfInstanceId

-pduSessionId

-singleNssai

-plmnId

It can be confirmed that the service to which the data corresponds is:

/{ueId}/registrations/smf-registrations/{pduSessionId}

thus, the following header fields must be present in headers frames corresponding to the data frame:

-path：/{ueId}/registrations/smf-registrations/{pduSessionId}

-method：put

content-length: length of data

-content-type：application/json

If the contents of the dynamic table before decoding are as shown in table 12 below.

Table 12

The contents of the post-repair dynamic table are shown in table 13 below.

TABLE 13

In a third example, if all of the following information elements are present in the DATA message for the udm service according to the 3GPP specifications:

-amfInstanceId

-imsVoPs

-deregCallbackUri

-guami

-ratType

it can be determined by the direction in the DATA whether the DATA frame is a request DATA frame or a response DATA frame (request frame if the destination address of the DATA frame is UDM and response frame if the source address of the DATA frame is UDM). If the DATA is a request DATA frame,

It can be confirmed that the service to which the data corresponds is:

/{ueId}/registrations/amf-non-3gpp-access

-path：/{ueId}/registrations/amf-non-3gpp-access

-method：put

content-length: length of data

-content-type：application/json

If the method is not decoded at the time of decoding in the HEADER frame and an index of 63 does not get content in the dynamic table, then the entry value corresponding to the index 63 may be determined as "methon: put (put).

If the contents of the dynamic table before decoding are as shown in table 14 below.

TABLE 14

The contents of the post-repair dynamic table are shown in table 15 below.

TABLE 15

7. Starting statistical repair mechanism based on 3GPP network element and PATH type

It is considered that the HEADER field content and the HEADER field sequence carried in the HEADER of the same PATH type by the same network element are substantially the same.

Based on this knowledge, we count the HEADER fields that appear and the order in which the HEADER fields appear for the dimension by device+path type, for successful HEADER frame decoding. We can use the statistics to repair the decoded exception header field.

The following illustrates a scenario in which statistics may be used for repair:

(1) If the header field A only appears once in all normal HEADERS frames in a certain PATH operation, the decoded header field A appears many times; then there may be a positive decoding exception and that header field a may be confirmed as decoding normal in conjunction with the order in which that header field a occurs in the normal HEADERS frames; except for this normal decoding header field, the other is abnormal decoding.

(2) If a certain packet decodes two content-types, but the PATH operation content-type only appears once in all normal HEADERS frames, then there must be a dynamic entry exception corresponding to the content-type header field index. The dynamic entry exception corresponding to that content-type header field index may be confirmed in combination with the order in which content-type occurs in the normal HEADERS frames of the PATH operation.

(3) If there is a header field a in a certain PATH operation that occurs in all normal HEADERS frames, but not in HEADERS frames where there is a decoding exception header field. Then it is considered that there is certainly a header field a in the header field of the decoding exception. The value of one of the header fields of the decoding exception may be confirmed as header field a in combination with the order in which header field a occurs in the normal HEADERS frames.

(4) If header field a occurs at high frequencies (e.g., over 95%) in normal HEADERS frames in a certain PATH operation, but not in HEADERS frames that decode the abnormal header field. Then it is considered that there may be a header field a in the header fields of the decoding exception; in combination with the order in which header field a occurs in the normal HEADERS frames, it may be possible to confirm which value in the header field of the decoding exception is header field a.

(5) If there is a sequence of HEADER fields (HEADER field a, HEADER field B, HEADER field C) in a certain PATH operation, it occurs in all normal HEADERS frames or occurs very frequently, but not in the HEADER frame with the HEADER field decoding abnormally; but a sequence of header fields (header field a, decoding exception header field, header field C) occurs, then the decoding exception header field can be considered to be header field B.

(6) When a plurality of header fields needing to be generated and a plurality of header words needing to be carried are generated, the corresponding values of the header fields needing to be generated and the plurality of header words needing to be carried are deleted, the corresponding values of the header fields needing to be generated and the plurality of header fields needing to be carried can be determined through the sequence of the deleted fields in the normal HEADERS frames.

In a fourth example, the probability of the occurrence of the various HEADER field arrangements in the HEADER frame in which the various services are transmitted by the respective devices of the mobile communication network may be counted for the dimensions in various arrangements of "service+source IP address+header field". Thus, the header field sequence with the highest occurrence probability of various services in various devices is obtained.

If the highest probability HEADER field sequence in the HEADER frame of the/sm-contexts/{ smContextRef }/modification service sent by a certain IP address (IP 1) is obtained through statistics:

1): an authority; 2): method; 3): path; 4): scheme; 5): content-type if we have decoded two content-types in the server that receives the/sm-contexts/{ smContextRef }/modification sent by the IP1 address. The decoding results are shown in table 16 below.

Table 16

Header field index	Header field name	Header field value
			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

There must be one content-type header field index corresponding to the dynamic entry exception.

Knowing by learning that the order of occurrence of the service header fields is 1): an authority; 2): method; 3): path; 4): scheme; 5): the probability of a content-type such sequence is high, and repair with such a sequence can be attempted; and the decoded value of the header index 68 may be considered anomalous, and the entry corresponding to the index value of 68 in the dynamic table is anomalous. The index value table entry may be repaired 68: the table entry names are: an authority; the entry value is unknown: the dynamic content before decoding is shown in table 17 below.

TABLE 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

The post-repair dynamic table contents are shown in table 18 below.

TABLE 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

In a fifth example, the probability of the occurrence of various HEADER fields in a HEADER frame in which various services are transmitted by each device of the mobile communication network may be counted in terms of "service+source IP address+header field" for the dimension. Thereby obtaining header fields of various service occurrence probabilities TOPN in various devices.

The HEADER field of TOPN in the HEADER frame of the/sm-contexts/{ smContextRef }/modification service, which is sent by a certain IP address (IP 1) is found by statistics, is shown in the following Table 19.

TABLE 19

Header field name	Header field value	Probability of occurrence
			：content-type	application/json	100％
：method	post	100％
			：path	/nsmf-pdusession/v1/sm-contexts/1/modify	100％
：scheme	http	100％

The Header frame decoding result of the service if we receive/sm-contexts/{ smContextRef }/modification transmitted by the IP1 address is shown in the following table 20.

Table 20

Header field index	Header field name	Header field value
			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

The service of sm-contexts/{ smContextRef }/modification, which can confirm the IP1 address transmission from statistics, positively carries: content-type, but there is no current decoding result. The header field of the decoding exception can be considered to be present. In conjunction with statistics of the order in which the service header fields occur (see example one), a corresponding header field decoding exception may be determined 62. The index value table entry may be repaired 62: the table entry names are: content-type; the entry value application/json. And the contents of the dynamic table before decoding are shown in table 21 below.

Table 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

The contents of the post-repair dynamic table are shown in table 22 below.

Table 22

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

In a sixth example, the probability of the occurrence of the various HEADER field arrangements in the HEADER frame in which the respective devices of the mobile communication network transmit various services may be counted for the dimensions in various arrangements of "service+source IP address+header field".

The decoding results in the server if we received the IP1 address sent/sm-contexts/{ smContextRef }/modification are shown in table 23 below.

Table 23

Header field sequence of decoding result: 1): an authority; 2): method; 3): path; 4): scheme; 5): accept-encoding. Substantially no decoding anomalies may be hypothesized to occur and repair attempted.

Knowing by learning that the service is similar to only header field order 1): an authority; 2): method; 3): path; 4): scheme; 5): the probability of content-type occurrence is high and repair with this sequence can be attempted; and the value decoded by the header index 62 can be considered abnormal, and the index value table entry can be repaired 62: the list item is named content-tyPe; the entry value application/json.

The dynamic content before decoding is shown in table 24 below.

Table 24

The post repair dynamic table contents are shown in table 25 below.

Table 25

Another embodiment of the present invention discloses a header decoding apparatus. Referring to fig. 7, the header decoding apparatus includes: a receiving module 702 for receiving a HEADER frame from a sender and the HEADER frame comprising a plurality of encoded HEADER fields; an identification module 704, configured to identify a coding format for coding the header field, where the coding format includes a header field index format code, a header field delta index tape index name format code, a header field delta index tape literal name format code, a header field non-index tape index name format code, and a header field non-index tape literal name format code; a decoding module 706 for encoding the identified encoded header field based on the identified encoding format; a judging module 708, configured to judge whether the decoding is successful; and a repair module 710 for initiating a single header field decoding exception repair mechanism when decoding fails.

The header decoding apparatus further includes a plurality of other modules. The header decoding apparatus corresponds to a header decoding method, and thus, detailed descriptions of a plurality of other modules are omitted for the sake of avoiding redundancy.

Compared with the prior art, the invention has at least one of the following beneficial effects:

Those skilled in the art will appreciate that all or part of the flow of the methods of the embodiments described above may be accomplished by way of a computer program to instruct associated hardware, where the program may be stored on a computer readable storage medium. Wherein the computer readable storage medium is a magnetic disk, an optical disk, a read-only memory or a random access memory, etc.

The present invention is not limited to the above-mentioned embodiments, and any changes or substitutions that can be easily understood by those skilled in the art within the technical scope of the present invention are intended to be included in the scope of the present invention.

Claims

1. A header decoding method, comprising:

receiving a HEADER frame from a sender and the HEADER frame comprising a plurality of encoded HEADER fields;

the following steps are sequentially performed for each of the plurality of encoded header fields, respectively:

Identifying a coding format for coding the header field, wherein the coding format comprises a header field index format code, a header field delta index tape index name format code, a header field delta index tape literal name format code, a header field non-index tape index name format code and a header field non-index tape literal name format code;

Decoding the identified coded header field based on the identified coding format and determining whether the decoding is successful; and

When decoding fails, a single header field decoding exception repair mechanism is started, wherein the starting of the single header field decoding exception repair mechanism comprises: determining that a HEADER frame is lost on a TCP link associated with a dynamic table when no record content corresponding to an index value is retrieved in the index table based on the index value, wherein the HEADER frame carries a HEADER field encoded in a HEADER field increment index tape index name format or a HEADER field encoded in a HEADER field increment index tape literal name format; and inserting an empty header field into the dynamic table according to the index value and setting the packet loss state of an entry corresponding to the index value in the dynamic table to be 1, wherein the index table comprises a static table and the dynamic table, the index value of the static table is 1 to 61, and the index value of the dynamic table is more than or equal to 62.

2. The header decoding method of claim 1, further comprising:

when the decoding is successful, adding the decoded header fields into a header field list; and

When the identified coding format is header field increment index name format coding or header field increment index name format coding, inserting the decoded header field into a dynamic table and setting the packet loss state of the starting table entry of the dynamic table to be a default value of 0.

3. The header decoding method of claim 1, wherein initiating a single header field decoding exception repair mechanism comprises:

When the decoded header field name and the header field value do not correspond, deriving the header field name from the header field value to modify the decoded header field and the dynamic table, wherein the header field comprises the header field name and the header field value.

4. The header decoding method of claim 2, further comprising, after decoding of the plurality of encoded header fields is completed:

checking whether a header field with abnormal decoding exists in the header field list; and

When present, a repair mechanism based on 3GPP specifications and normal decoding statistics is initiated.

5. The header decoding method of claim 4, wherein initiating a repair mechanism based on 3GPP specifications and normal decoding statistics further comprises:

After receiving the HEADER frame, receiving a DATA frame;

Determining a HEADER field in the HEADER frame corresponding to the DATA frame from all information elements in the DATA frame; and

And repairing the HEADER field of the decoding exception according to the determined HEADER field in the HEADER frame.

6. The header decoding method according to claim 4 or 5, wherein starting a repair mechanism based on 3GPP specifications and normal decoding statistics further comprises:

Storing HEADER fields and the sequence in which the HEADER fields appear in the HEADER frame that is successfully decoded under the condition of the same equipment and the same type of HEADER frame; and

And repairing the HEADER field with abnormal decoding according to the HEADER field in the stored successfully decoded HEADER frame and the sequence of the HEADER field.

7. The HEADER decoding method according to claim 2 or 4, characterized by further comprising, before receiving the HEADER frame, encoding each of a plurality of HEADER fields to obtain a HEADER frame to be transmitted by:

querying header fields in the static table and the dynamic table;

Encoding the header field according to a header field index format when the header field is in the static table or the dynamic table;

When the header field is not in the static table or the dynamic table, the header field is encoded in an encoding format other than the header field index format according to whether a header field name is in the static table or the dynamic table and whether the header field is placed in the dynamic table, wherein the header field includes a header field name and a header field value.

8. The header decoding method of claim 7, wherein encoding the header field in an encoding format other than the header field index format according to whether a header field name is in the static table or the dynamic table and whether the header field is placed in the dynamic table further comprises:

Encoding the header field in a header field delta index name format when the header field name is in the static table or the dynamic table and the header field is placed in the dynamic table;

when the header field name is in the static table or the dynamic table and the header field is not put in the dynamic table, encoding the header field in a header field non-indexed name format;

Encoding the header field in a header field delta index literal name format when the header field name is not in the static table or the dynamic table and the header field is placed in the dynamic table; and

When the header field name is not in the static table or the dynamic table and the header field is not placed in the dynamic table, the header field is encoded in a header field non-indexed literal name format.

9. A header decoding apparatus, comprising:

a receiving module for receiving a HEADER frame from a sender and the HEADER frame comprising a plurality of encoded HEADER fields;

The identification module is used for identifying an encoding format of an encoding header field, wherein the encoding format comprises a header field index format encoding, a header field increment index tape index name format encoding, a header field increment index tape literal name format encoding, a header field non-index tape index name format encoding and a header field non-index tape literal name format encoding;

A decoding module for encoding the identified encoded header field based on the identified encoding format;

the judging module is used for judging whether the decoding is successful or not; and

And the repair module is used for starting a single header field decoding exception repair mechanism when decoding fails, wherein the starting of the single header field decoding exception repair mechanism comprises the following steps: determining that a HEADER frame is lost on a TCP link associated with a dynamic table when no record content corresponding to an index value is retrieved in the index table based on the index value, wherein the HEADER frame carries a HEADER field encoded in a HEADER field increment index tape index name format or a HEADER field encoded in a HEADER field increment index tape literal name format; and inserting an empty header field into the dynamic table according to the index value and setting the packet loss state of an entry corresponding to the index value in the dynamic table to be 1, wherein the index table comprises a static table and the dynamic table, the index value of the static table is 1 to 61, and the index value of the dynamic table is more than or equal to 62.