Network traffic service-type determination method, electronic device, and readable storage medium

Through the feature matching between QUIC migration flow and negotiation flow, the problem that the DPI system cannot identify the migration service type after QUIC connection migration is solved, and the accurate identification of the QUIC migration flow and the service type determination are achieved, and traffic billing and QoS are supported. Assure.

WO2025001092A1PCT designated stage expired Publication Date: 2025-01-02ZTE CORP
View PDF 4 Cites 0 Cited by

Patent Information

Application Number
PCT/CN2024/073319
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Priority Date
2023-06-26
Filing Date
2024-01-19
Publication Date
2025-01-02

AI Technical Summary

Technical Problem

After the QUIC connection migration, the DPI system cannot directly determine the migration service type through the QUIC migration flow, resulting in the inability to accurately generate traffic billing, QoS guarantee and business statistics report.

Method used

By obtaining the identification characteristics of the QUIC migration flow and matching the negotiation service type in the QUIC negotiation flow, the migration service type is determined using metadata objects to realize the association identification between the QUIC migration flow and the QUIC negotiation flow.

Benefits of technology

After the connection migration, the migration service type of the QUIC migration flow can be accurately determined, and the traffic billing, QoS guarantee and the generation of business statistics reports can be supported, which improves the identification capabilities of the DPI system.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN2024073319_02012025_PF_FP_ABST
    Figure CN2024073319_02012025_PF_FP_ABST
Patent Text Reader

Abstract

Disclosed in the present application are a network traffic service-type determination method, an electronic device, and a readable storage medium. The method comprises the steps of: acquiring a QUIC migration stream, and determining a first identification feature corresponding to the QUIC migration stream; and performing matching from a metadata object to obtain a negotiation service type corresponding to the first identification feature, wherein the metadata object is generated on the basis of a second identification feature corresponding to a QUIC negotiation stream corresponding to the QUIC migration stream and the negotiation service type, and then taking the negotiation service type as a migration service type corresponding to the QUIC migration stream.
Need to check novelty before this filing date? Find Prior Art

Description

Method for determining service type of network traffic, electronic device and readable storage medium

[0001] Related applications

[0002] This application claims priority to Chinese patent application No. 202310767550.5 filed on June 26, 2023, the entire contents of which are incorporated by reference into this application. Technical Field

[0003] The present application relates to the field of communications, and in particular to a method for determining the service type of network traffic, an electronic device, and a readable storage medium. Background Art

[0004] Most of the services on the Internet are carried by HTTP (HyperText Transfer Protocol). With the update and iteration of HTTP, the connection migration function was introduced in the underlying protocol QUIC (Quick UDP Internet Connections) of HTTP / 3. Among them, the network traffic of HTTP includes the QUIC negotiation stream in the handshake negotiation phase between the terminal device and the server before the connection migration, and the QUIC migration stream after the connection migration. It should be noted that detecting HTTP network traffic and accurately identifying the service type is one of the most important capabilities of the DPI (Deep Packet Inspection) system. Through this service type, operators can perform traffic billing, QoS (Quality of Service) assurance, and generate service statistics reports.

[0005] In actual applications, the service type includes the negotiated service type before connection migration and the migrated service type after connection migration. Before connection migration, the DPI system can determine the negotiated service type through the SNI (Server Name Indication) in the ClientHello message in the QUIC negotiation stream. However, after the connection migration occurs, since there will be no handshake negotiation between the terminal device and the server, the DPI system cannot obtain SNI from the QUIC migration stream, resulting in the inability to determine the migration service type corresponding to the QUIC migration stream.

[0006] Therefore, in practical applications, a solution is needed that can accurately determine the migration service type corresponding to the QUIC migration flow after the connection is migrated.

[0007] Summary of the Invention

[0008] The main purpose of this application is to provide a method for determining the service type of network traffic, an electronic device and a readable storage medium, aiming to solve the technical problem that after the connection is migrated, it is impossible to determine the migration service type corresponding to the QUIC migration flow.

[0009] To achieve the above-mentioned objectives, the present application provides a method for determining the service type of network traffic, which includes the following steps: obtaining a QUIC migration flow and determining a first identification feature corresponding to the QUIC migration flow; matching and obtaining a negotiated service type corresponding to the first identification feature from a metadata object; the metadata object is generated based on a second identification feature and a negotiated service type corresponding to the QUIC negotiation flow corresponding to the QUIC migration flow; and using the negotiated service type as the migration service type corresponding to the QUIC migration flow.

[0010] Exemplarily, to achieve the above-mentioned purpose, the present application also provides a method for determining the service type of network traffic, which includes the following steps: obtaining a QUIC negotiation stream; determining a second identification feature corresponding to the QUIC negotiation stream, and determining the negotiation service type corresponding to the QUIC negotiation stream; generating a metadata object based on the second identification feature and the negotiation service type; the metadata object is used to determine the migration service type corresponding to the QUIC migration stream corresponding to the QUIC negotiation stream.

[0011] Exemplarily, to achieve the above-mentioned purpose, the present application also provides an electronic device, which includes: a memory, a processor, and a network traffic business type determination program stored on the memory and runnable on the processor, wherein the network traffic business type determination program is configured to implement the steps of the network traffic business type determination method as described above.

[0012] Exemplarily, to achieve the above-mentioned purpose, the present application also provides a computer-readable storage medium, on which a program for determining the business type of network traffic is stored. When the program for determining the business type of network traffic is executed by a processor, the steps of the method for determining the business type of network traffic as described above are implemented. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] FIG1 is a schematic diagram of the evolution of HTTP and QUIC protocols involved in an embodiment of the present application;

[0014] FIG2 is a flow chart of a first embodiment of a method for determining a service type of network traffic according to the present invention;

[0015] FIG3 is a schematic diagram of message decoding involved in the first embodiment of the method for determining the service type of network traffic of the present application;

[0016] FIG4 is a schematic diagram of a process for generating a negotiation CID triplet object according to a first embodiment of the method for determining the service type of network traffic of the present application;

[0017] FIG5 is a schematic diagram of a process for generating a negotiation quad-tuple object according to a first embodiment of the method for determining the service type of network traffic of the present application;

[0018] FIG6 is a schematic diagram showing the composition of a message involved in the first embodiment of the method for determining the service type of network traffic of the present application;

[0019] FIG7 is a flow chart of a second embodiment of a method for determining a service type of network traffic according to the present invention;

[0020] FIG8 is a schematic diagram of the identification process of three identification methods in the second embodiment of the method for determining the service type of network traffic of the present application;

[0021] 9 is a schematic diagram of the migration process of a connection migration in a non-inter-network migration case involved in the second embodiment of the method for determining the service type of network traffic of the present application;

[0022] FIG10 is a schematic diagram of a process for rapid association identification according to a second embodiment of the method for determining the service type of network traffic of the present application;

[0023] 11 is a schematic diagram of detecting a migration CID in an uplink message according to a second embodiment of the method for determining the service type of network traffic of the present application;

[0024] FIG12 is a schematic diagram of a process for strong correlation identification according to a second embodiment of the method for determining the service type of network traffic of the present application;

[0025] FIG13 is a schematic diagram of a process for weak correlation identification according to a second embodiment of the method for determining the service type of network traffic of the present application;

[0026] 14 is a schematic diagram of the results recorded in the negotiated network address triplet object involved in the second embodiment of the method for determining the service type of network traffic of the present application;

[0027] FIG15 is a schematic diagram of the interaction between the DPI system and the external system involved in the second embodiment of the method for determining the service type of network traffic of the present application;

[0028] FIG16 is a schematic diagram of the structure of the hardware operating environment involved in the embodiment of the present application.

[0029] The realization of the objectives, functional features and advantages of this application will be further explained in conjunction with embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0030] It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0031] In order to better understand the embodiments of the present application, the embodiments of the present application are briefly described below:

[0032] Referring to Figure 1, Figure 1 is a schematic diagram of the evolution of the HTTP and QUIC protocols involved in the embodiments of the present application. Since 1990, HTTP has evolved from HTTP / 0.9, HTTP / 1.0, HTTP / 1.1, HTTP / 2 to QUIC-based HTTP / 3 in 2022. Specifically, from TCP (Transmission Control Protocol)-based transmission to UDP (User Datagram Protocol)-based transmission, and from TLS (Transport Layer Security)-based encryption to QUIC-based encryption, the form of HTTP network traffic has become more and more complex, making it increasingly difficult for the DPI system to identify HTTP network traffic.

[0033] Since QUIC introduced the connection migration function, support for connection migration has appeared in newer QUIC implementations. Some large Internet companies (such as Google, Meta, etc.) already have network traffic based on QUIC connection migration in their important businesses (business types include Youtube, Google Play, Instagram, etc.).

[0034] For HTTP / 3 services based on connectionless migration, the DPI system can typically accurately identify the service type by detecting the SNI of the initial ClientHello message during the handshake negotiation phase. For example, if the DPI system detects that the SNI contains ".youtube.com" or ".googlevideo.com", it will identify the related QUIC negotiation stream as YouTube.

[0035] For HTTP / 3 services based on connection migration, the QUIC migration flow after connection migration is a completely new form for the DPI system. The DPI system in actual applications cannot identify it, and the identification result is usually "Unknown UDP", which means it is identified as an unknown service type.

[0036] In actual applications, research has found that the negotiation service type corresponding to the QUIC negotiation stream and the migration service type corresponding to the QUIC migration stream are actually the same service type. Therefore, if the migration service type cannot be directly determined through the QUIC migration stream, the connection between the QUIC migration stream and the QUIC negotiation stream can be used to obtain the negotiation service type and use the negotiation service type as the migration service type, thereby indirectly determining the migration service type. Therefore, after connection migration, the problem of how to determine the migration service type corresponding to the QUIC migration stream can be transformed into the problem of how to determine the migration service type corresponding to the QUIC migration stream through the connection between the QUIC migration stream and the QUIC negotiation stream.

[0037] In order to determine the connection between the QUIC migration flow and the QUIC negotiation flow, it was found through research that the same identification feature exists between the QUIC negotiation flow and the QUIC migration flow, that is, the identification feature is the connection between the QUIC migration flow and the QUIC negotiation flow. The negotiation service type corresponding to the QUIC negotiation flow corresponding to the QUIC migration flow can be determined through the identification feature, thereby obtaining the migration service type. The process of determining the migration service type corresponding to the QUIC migration flow through the identification feature includes: obtaining the QUIC migration flow and determining the first identification feature corresponding to the QUIC migration flow; matching the negotiation service type corresponding to the first identification feature from the metadata object; the metadata object is generated based on the second identification feature and the negotiation service type corresponding to the QUIC negotiation flow corresponding to the QUIC migration flow; and finally, the negotiation service type is used as the migration service type corresponding to the QUIC migration flow.

[0038] Due to the same identification feature, the negotiation service type corresponding to the QUIC negotiation stream determines the migration service type corresponding to the QUIC migration stream corresponding to the QUIC negotiation stream, so that the migration service type corresponding to the QUIC migration stream can be determined after the connection migration.

[0039] The DPI system is deployed on electronic devices, including but not limited to various gateways or routing products, independent DPI devices, network traffic analysis devices, and service experience sensitive detection devices. The embodiments of this application include a first embodiment and a second embodiment, wherein the first embodiment relates to the DPI system's processing stage for QUIC migration flows, and the second embodiment relates to the DPI system's processing stage for QUIC negotiation flows.

[0040] First embodiment:

[0041] In the DPI system's processing stage of the QUIC negotiation stream, the following steps are included: determining the QUIC negotiation stream; identifying the negotiation service type corresponding to the QUIC negotiation stream based on SNI; extracting the second identification feature corresponding to the QUIC negotiation stream; recording the second identification feature and the negotiation service type for determining the migration service type.

[0042] 2 , which is a flow chart of a first embodiment of a method for determining a service type of network traffic according to the present application.

[0043] The present application provides an embodiment of a method for determining the service type of network traffic. It should be noted that although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than shown. The method for determining the service type of network traffic includes:

[0044] Step S210: Obtain the QUIC negotiation stream.

[0045] The steps of obtaining the QUIC negotiation stream involve determining the QUIC negotiation stream.

[0046] In the step of determining the QUIC negotiation flow, the DPI system checks the first message in each processed flow and determines the flow to which the message that meets the following inspection conditions belongs as a QUIC negotiation flow. Referring to Figure 3, Figure 3 is a schematic diagram of message decoding involved in the first embodiment of the method for determining the service type of network traffic of the present application. Check condition 1: The network layer protocol of the message is IPv4 or IPv6; Check condition 2: The transport layer protocol type of the message is UDP; Check condition 3: The direction of the message is upstream, that is, it is sent from the user side (terminal) to the network side (server); Check condition 4: The UDP payload length of the message is greater than or equal to 1200 bytes, where the UDP payload is at least 1200 bytes as required by the RFC 9000 protocol; Check condition 5: The message is decoded according to the QUIC protocol header, and the header format is the QUIC long header; Check condition 6: The message is decoded according to the QUIC protocol header, and the message type is QUIC initial message; Check condition 7: The message is decoded according to the QUIC protocol header, and the correct QUIC version number can be obtained (for example: the version number of QUIC v1 is 0x00000001).

[0047] For flows that fail to pass the above inspection conditions, the DPI system considers that the flow is not a QUIC negotiation flow, marks the flow, and no longer performs further processing related to determining the service type for subsequent messages of the flow; for flows that pass the above detection conditions, the DPI system enters the step of identifying the negotiation service type corresponding to the QUIC negotiation flow based on SNI.

[0048] Exemplarily, the DPI system manages flows in quintuples. Each quintuple is a key, which is composed of five metadata in a fixed order. A key uniquely identifies the corresponding quintuple context. The five metadata include: user IP (Internet Protocol) address, network IP address (the IP address of the QUIC server), user port, network port, and transport layer protocol type (UDP or TCP).

[0049] Exemplarily, the quintuple is used to generate a quintuple object, which includes a key (the quintuple), a value (service type (obtained by the DPI system identifying the QUIC negotiation flow through SNI) and flow status information) and a correspondence between the key and the value.

[0050] Step S220: Determine the second identification feature corresponding to the QUIC negotiation flow, and determine the negotiation service type corresponding to the QUIC negotiation flow.

[0051] The steps of determining the second identification feature corresponding to the QUIC negotiation stream and determining the negotiation service type corresponding to the QUIC negotiation stream include: identifying the negotiation service type corresponding to the QUIC negotiation stream based on SNI and extracting the second identification feature corresponding to the QUIC negotiation stream.

[0052] Step S230: Generate a mapping relationship between features and service types based on the second identification feature and the negotiated service type; the mapping relationship is used to determine the migration service type corresponding to the QUIC migration flow corresponding to the QUIC negotiation flow.

[0053] In the step of identifying the negotiation service type corresponding to the QUIC negotiation stream based on SNI, the DPI system decodes the message in the QUIC negotiation stream (generally the first message) according to the QUIC CRYPTO frame encoding rules and TLS 1.3 ClientHello message encoding rules. If the decoding fails, the DPI system marks the stream and does not perform further processing related to determining the service type for subsequent messages of the stream; if the decoding is successful, the DPI system enters the step of extracting the second identification feature corresponding to the QUIC negotiation stream.

[0054] For the decoding process, the DPI system obtains the identification result of the QUIC negotiation stream by detecting the SNI in the ClientHello message.

[0055] For example, if the SNI is detected as "www.youtube.com" or "sn-i6b1kns2.googlevideo.com", that is, the SNI contains the characteristic string ".youtube.com" or ".googlevideo.com", the DPI system will identify the QUIC negotiation stream as Youtube.

[0056] For example, if the SNI is detected as "graph.facebook.com", that is, the SNI contains the characteristic string ".facebook.com", the DPI system will identify the QUIC negotiation flow as Facebook.

[0057] For unrecognizable SNIs, the DPI system marks the stream and does not perform further processing related to determining the service type for subsequent packets of the stream. Only when the SNI is successfully identified does the DPI system enter the step of extracting the second identification feature corresponding to the QUIC negotiation stream. It can be understood that only QUIC negotiation streams that the DPI system can identify are necessary to perform subsequent processing related to determining the service type. For QUIC negotiation streams that the DPI system cannot identify, there is no need to perform subsequent processing related to determining the service type.

[0058] In the step of extracting the second identification feature corresponding to the QUIC negotiation stream, the second identification feature is a negotiation CID (Connection ID) triplet or a negotiation network address triplet.

[0059] In the case where the second identification feature is a negotiation CID triplet, the negotiation CID triplet includes at least the negotiation CID, and the other two metadata are the user IP address and the transport layer protocol type.

[0060] The above-mentioned determination of the second identification feature corresponding to the QUIC negotiation flow includes: obtaining the negotiation CID from the QUIC negotiation flow; generating the negotiation CID triplet based on the negotiation CID; the mapping relationship is a negotiation CID triplet object, and the mapping relationship between the feature and the service type generated based on the second identification feature and the negotiation service type includes: generating the negotiation CID triplet object based on the negotiation CID triplet and the negotiation service type; the migration CID triplet is used to match the negotiation service type corresponding to the negotiation CID triplet that is the same as the migration CID triplet from the negotiation CID triplet object.

[0061] Referring to Figure 4, Figure 4 is a flow chart of generating a negotiation CID triplet object involved in the first embodiment of the method for determining the service type of network traffic of the present application. In Figure 4, three corresponding triplets are generated by the quintuples of each of the three QUIC negotiation flows. Among them, the five metadata included in the quintuple are user IP address, network IP address, user port, network port and transport layer protocol type, and the triplet uses two of the metadata, namely user IP address and transport layer protocol type. For any negotiation CID triplet object, it includes a negotiation CID triplet and its corresponding record (i.e., negotiation service type). For example, negotiation CID triplet object 1 includes negotiation CID triplet 1 and its corresponding negotiation service type 1.

[0062] For the QUIC negotiation stream, after obtaining the negotiation CID, the DPI system simultaneously obtains the user IP address and transport layer protocol type from the message information of the QUIC negotiation stream, and uses the user IP address, transport layer protocol type and negotiation CID as a negotiation triplet to establish a negotiation CID triplet object.

[0063] Before creating a negotiation CID triplet object, the DPI system checks whether the negotiation CID triplet object already exists. If it does not exist, the DPI system creates a new negotiation CID triplet object and records the negotiation service type (e.g., YouTube) corresponding to the current QUIC negotiation flow in the negotiation CID triplet object. If it does exist, the DPI system updates the original value in the negotiation CID triplet object with the current negotiation service type.

[0064] As shown in Figure 4, since the negotiation CIDs of different QUIC negotiation streams of the same user (i.e., the same user IP address) are usually not the same, the negotiation CID triplet object of each QUIC negotiation stream is usually different.

[0065] The above-mentioned method for determining the service type of network traffic also includes: obtaining a negotiation quadruple and a negotiation length of the negotiation CID from the QUIC negotiation stream; generating a negotiation quadruple object based on the negotiation length and the negotiation quadruple; the negotiation quadruple object is used to extract a migration CID from the first message in the QUIC migration stream; and the migration CID is used to generate the migration CID triplet.

[0066] Since the DPI system cannot directly obtain the migration CID in the QUIC migration stream, it can obtain the negotiation length, which is used by the DPI system to obtain the migration CID from the QUIC migration stream.

[0067] Referring to Figure 5, Figure 5 is a schematic diagram of the process of generating a negotiation quad-tuple object involved in the first embodiment of the method for determining the service type of network traffic in the present application. It should be noted that the DPI system obtains the negotiation quad-tuple from the first message of the QUIC negotiation flow to establish the negotiation quad-tuple object. The quad-tuple includes: user IP address, network IP address, network port, and transport layer protocol type (UDP).

[0068] Before establishing a negotiation quad-tuple object, the DPI system will query whether the negotiation quad-tuple object already exists; if it does not exist, the DPI system will create a new negotiation quad-tuple object and record the negotiation length in the negotiation quad-tuple object; if it exists, the DPI system will update the original value in the negotiation quad-tuple object with the negotiation length.

[0069] Different QUIC negotiation streams (such as QUIC negotiation stream 1, QUIC negotiation stream 2, and QUIC negotiation stream 3 in Figure 5) may correspond to the same negotiation quadruple object or different negotiation quadruple objects.

[0070] The process of obtaining the negotiation CID from the QUIC negotiation stream and obtaining the negotiation length of the negotiation CID.

[0071] Referring to Figure 6, Figure 6 is a schematic diagram of the composition of the message involved in the first embodiment of the method for determining the service type of network traffic of the present application. The DPI system can obtain the SCID (Source Connection ID) and the SCID length from the QUIC header of the TLS 1.3 ServerHello message (the message in the first message) of the QUIC negotiation flow. The DPI system can also obtain the SCID and the SCID length from the QUIC header of the long header initial message (the first message) that appears for the first time in the QUIC negotiation flow (sent from the network side to the user side) in the downlink.

[0072] Among them, "long header" means that the QUIC header decoding header type is long header, and "initial message" means that the QUIC header decoding message type is initial message.

[0073] The ServerHello message is an encrypted message. Only after decryption can we know whether the first message contains the ServerHello message. In order to avoid the system performance loss caused by decryption, the DPI system in this embodiment does not decrypt the message in the first message, but only uses the encoding information in the QUIC message header to efficiently infer whether the first message contains the ServerHello message.

[0074] After obtaining the SCID and SCID length, the DPI system uses the content from the second byte of the SCID to the last byte of the SCID as the negotiation CID. For example, if the SCID is "594e8a6a5679f5a2" in hexadecimal, the negotiation CID obtained is "4e8a6a5679f5a2" in hexadecimal.

[0075] According to the encoding format of the SCID agreed upon in the QUIC RFC protocol, the first byte in the SCID is variable, so the DPI system starts from the second byte of the SCID.

[0076] The negotiated length of the CID is the length of the SCID minus 1. For example, if the SCID is 8 bytes long, the negotiated length is 7 bytes. The CID is assigned by the QUIC server, and different QUIC server vendors can customize different CID lengths. For example, the length range specified by RFC8999 is 0-255 bytes. The length range specified by RFC9000 is 0-20 bytes. The most common SCID length is 8 bytes.

[0077] Second embodiment:

[0078] In the DPI system's processing stage of the QUIC migration flow, the following steps are included: determining the QUIC migration flow; determining the first identification feature corresponding to the QUIC migration flow; and performing association identification based on the first identification feature.

[0079] 7 , which is a flow chart illustrating a second embodiment of a method for determining a service type of network traffic according to the present application.

[0080] The present application provides an embodiment of a method for determining the service type of network traffic. It should be noted that although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than shown. The method for determining the service type of network traffic includes:

[0081] Step S710: Obtain a QUIC migration flow and determine a first identification feature corresponding to the QUIC migration flow.

[0082] Obtaining a QUIC migration stream involves determining the QUIC migration stream.

[0083] In the step of determining the QUIC migration flow, the DPI system checks the first message of each processed flow and preliminarily determines that the flow to which the message that meets the following inspection conditions belongs may be a QUIC migration flow. Inspection condition 1: The network layer of the message is IPv4 or IPv6; Inspection condition 2: The transport layer of the message is UDP; Inspection condition 3: The direction of the message is upstream, that is, it is sent from the user side (terminal) to the network side (server); Inspection condition 4: The message is decoded according to the QUIC protocol header, and the header format is a short header; Inspection condition 5: The UDP stream cannot be identified as a specific service type by the DPI system through feature word matching. The code stream of the QUIC migration flow is encrypted and does not contain content that can be matched by feature words.

[0084] For flows that fail to pass the above inspection conditions, the DPI system considers that the flow is not a QUIC migration flow, marks the flow, and no longer performs further processing related to determining the service type for subsequent messages of the flow; for flows that pass the above detection conditions, the DPI system enters the step of determining the first identification feature corresponding to the QUIC migration flow.

[0085] Before performing association identification, it is necessary to determine the first identification feature corresponding to the QUIC migration flow, so as to perform association identification based on the first identification feature.

[0086] Association identification includes fast association identification, strong association identification, and weak association identification. The first identification feature may be different for different association identifications. The first identification feature for fast and strong association identification is a migration CID (Connection IDentifier) ​​triplet, which includes at least the migration CID; the first identification feature for weak association identification is a migration network address triplet.

[0087] Referring to Figure 8, Figure 8 is a schematic diagram of the identification process of the three identification methods in the second embodiment of the method for determining the service type of network traffic in the present application. The process is: determine the second identification feature through the quintuple 1 in the QUIC negotiation flow, and the second identification feature is a part of the three storage objects, namely the negotiation quadruple object, the negotiation CID triplet object and the negotiation network address triplet object; then identify the two QUIC migration flows through the identification method and the second identification feature. The identification process is to identify the migration service type corresponding to the QUIC migration flow from the three storage objects through the first identification feature. When using fast association identification to identify the QUIC migration flow, it is necessary to generate the negotiation quadruple and the negotiation CID triplet through the quintuple 1 of the QUIC negotiation flow; when using strong association identification, it is only necessary to generate the negotiation CID triplet through the quintuple 1 of the QUIC negotiation flow; when using weak association identification, it is only necessary to generate the negotiation network address triplet through the quintuple 1 of the QUIC negotiation flow.

[0088] Step S720: Match and obtain the negotiation service type corresponding to the first identification feature from the metadata object; the metadata object is generated based on the second identification feature and the negotiation service type corresponding to the QUIC negotiation flow corresponding to the QUIC migration flow; and use the negotiation service type as the migration service type corresponding to the QUIC migration flow.

[0089] The metadata object is one of the negotiated CID triplet object and the negotiated network address triplet object. The second identification feature is the metadata object's key, and the negotiated service type is the metadata object's value. The key and value have a corresponding relationship. That is, the metadata object exists in the form of a key-value pair. Using the first identification feature as the key, the corresponding value can be matched to obtain the migration service type.

[0090] The following describes the embodiments of the present application with respect to three association identification methods;

[0091] For fast association recognition:

[0092] Fast association identification is a special case of strong association identification. It targets non-inter-network migration scenarios. In such scenarios, according to the QUIC protocol (RFC 9000), although the uplink message of the QUIC migration flow contains a migration CID, it does not contain the migration length of the migration CID, so the specific nature of the migration CID is unknown. Therefore, fast association identification solves the problem of how to quickly determine the migration length to accurately obtain the migration CID and thus identify the QUIC migration flow.

[0093] Referring to Figure 9, Figure 9 is a schematic diagram of the migration process of connection migration in a non-cross-network migration situation involved in the second embodiment of the method for determining the service type of network traffic of the present application. Among them, for services based on the same QUIC connection, the QUIC client (deployed on the terminal device) first negotiates and transmits encrypted data to the QUIC server through QUIC UDP stream 1. After a period of time, the QUIC client performs connection migration and continues to transmit encrypted data to the QUIC server through QUIC UDP stream 2.

[0094] Because QUIC UDP stream 1 contains the SNI in its initial ClientHello message during the handshake negotiation phase, the DPI system can accurately identify QUIC UDP stream 1 based on the features in the SNI. However, since QUIC UDP stream 2 does not contain the initial ClientHello message during the handshake negotiation phase and is entirely encrypted data, the DPI system cannot use SNI feature detection to identify QUIC UDP stream 2.

[0095] The QUIC server can associate the QUIC negotiation stream (QUIC UDP stream 1 in Figure 9) with the QUIC migration stream (QUIC UDP stream 2 in Figure 9) through the CID in the QUIC message. This is because the QUIC server participates in the entire QUIC handshake negotiation process and has accurate information about parameters such as the CID in the QUIC connection. Therefore, it can accurately associate the QUIC migration stream with the QUIC negotiation stream. It can be understood that the negotiation CID in the QUIC negotiation stream and the migration CID in the QUIC migration stream in the same QUIC connection are the same.

[0096] Since the migration CID is the same as the negotiation CID, the migration length is the negotiated length.

[0097] The above-mentioned step of determining the first identification feature corresponding to the QUIC migration flow includes: determining the migration CID based on the QUIC migration flow; generating the migration CID triplet based on the migration CID; the metadata object is a negotiation CID triplet object, the second identification feature is a negotiation CID triplet, and matching the negotiation service type corresponding to the first identification feature from the metadata object includes: matching the negotiation service type corresponding to the negotiation CID triplet that is the same as the migration CID triplet from the negotiation CID triplet object.

[0098] Exemplarily, the above-mentioned determination of the migration CID based on the QUIC migration stream includes: obtaining a migration quadruple from the QUIC migration stream; determining a negotiation value corresponding to a negotiation quadruple that is identical to the migration quadruple from the negotiation quadruple object corresponding to the QUIC negotiation stream; the negotiation value is the negotiation length of the negotiation CID corresponding to the QUIC negotiation stream; the negotiation length is the same as the migration length of the migration CID; and extracting the migration CID from the first message in the QUIC migration stream based on the migration length.

[0099] Referring to Figure 10, Figure 10 is a schematic diagram of the process of rapid association identification involved in the second embodiment of the method for determining the service type of network traffic of the present application. The DPI system obtains a migration quad from the first message of the QUIC migration flow. The migration quad includes: user IP address, network IP address, network port, and transport layer protocol type (UDP).

[0100] The DPI system queries whether the negotiation quad object corresponding to the migration quad already exists. If so, the DPI system obtains the negotiated length from the negotiation quad object and uses it as the migration length. If not, the DPI system attempts to identify the QUIC migration stream through strong or weak association identification.

[0101] The DPI system checks the UDP payload length of the first packet of the QUIC migration flow and determines whether the UDP payload length is greater than the migration length + 1. If so, it uses the migration length to obtain the migration CID. If not, it attempts to identify the QUIC migration flow through strong or weak association identification.

[0102] When obtaining the migration CID based on the migration length, the DPI system starts from the third byte of the UDP payload of the first packet of the QUIC migration flow and obtains the migration CID from the UDP payload according to the obtained migration length. For example, the migration CID is "a3c715961737be".

[0103] According to the QUIC RFC protocol, this short header message starts with the DCID (Destination Connection ID) from the second byte of the UDP payload, and the DPI system extracts the migration CID from the second byte of the DCID.

[0104] The DPI system uses the user IP address, transport layer protocol type, and migration CID as the migration CID triplet, that is, it generates the migration CID triplet through the migration CID. The DPI system uses the migration CID triplet to query whether the negotiation CID triplet object exists. If it exists, the DPI system obtains the negotiation service type of the corresponding QUIC negotiation flow record from the negotiation CID triplet object as the migration service type of the QUIC migration flow, thereby completing the identification of the QUIC migration flow; if it does not exist, the DPI system attempts to identify the QUIC migration flow through weak association identification.

[0105] Exemplarily, before generating the migration CID triplet based on the migration CID, the method includes: determining whether the migration CID is legal; if so, performing the step of generating the migration CID triplet based on the migration CID.

[0106] Before generating a migration CID triplet from the migration CID, the DPI system also checks whether the migration CID is valid. If the migration CID is valid, it will proceed with the subsequent processing. If the migration CID is invalid, the DPI system will consider the flow not to be a true QUIC migration flow, mark the flow, and no longer process the flow's packets.

[0107] In one embodiment, the DPI system determines the validity of a migration CID by checking whether each byte value of the migration CID is unique. If each byte value of the migration CID is unique, the DPI system considers it valid. If the migration CID contains identical byte values, the DPI system considers it invalid. For example, if the migration CID is in hexadecimal "a3c715961737be," where the hexadecimal byte values ​​"a3," "c7," "15," "96," "17," "37," and "be" are unique, the migration CID is considered valid.

[0108] In another embodiment, the DPI system determines whether the migrating CID is legitimate by calculating its entropy value. The DPI system treats each byte of the migrating CID as a set of numbers, calculates the frequency and probability of each number, and calculates the entropy value of the migrating CID based on the Shannon entropy formula. If the entropy value is greater than or equal to a threshold preset by the DPI system, the DPI system considers the migrating CID legitimate. If the entropy value is less than the threshold preset by the DPI system, the DPI system considers the migrating CID illegitimate. The threshold can be set as needed and is not specifically limited in this embodiment.

[0109] Exemplarily, determining the migration CID based on the QUIC migration flow includes: obtaining multiple second messages in the QUIC migration flow; extracting the longest common prefix code stream from the multiple second messages; and determining the migration CID based on the longest common prefix code stream.

[0110] Referring to Figure 11, Figure 11 is a schematic diagram of detecting a migration CID in an uplink message according to the second embodiment of the method for determining the service type of network traffic of the present application. For a QUIC migration flow, the DPI system continuously obtains the first N uplink messages of the QUIC migration flow and attempts to detect possible migration CIDs from these N uplink messages.

[0111] In one embodiment, the DPI system uses the Longest Common Prefix (LCP) algorithm from the second byte of the UDP payload of each of the first N upstream packets of the QUIC migration flow to obtain the longest common prefix (DCID) of these packets. The DPI system then uses the code from the second byte of the DCID to the end of the DCID as the migration CID.

[0112] Figure 11 includes the first 9 uplink messages of a QUIC migration flow. Assuming that each line is the UDP payload part of an uplink message of the QUIC migration flow, the common prefix part of the code stream starting from the second byte of each UDP payload shown in the box is the DCID obtained by detection; and the second byte of the DCID starts as the migration CID obtained by detection.

[0113] Strong correlation identification targets cross-network migration scenarios, such as when a QUIC connection migrates from operator 1's wired WiFi network to operator 2's mobile cellular network. A DPI system deployed in the latter network can only observe the QUIC migration flow and cannot observe the QUIC negotiation flow in the former network. Therefore, strong correlation identification addresses the problem of identifying such isolated QUIC migration flows.

[0114] Referring to Figure 12, Figure 12 is a flow chart of strong correlation identification involved in the second embodiment of the method for determining the service type of network traffic of the present application. The DPI system uses the above-mentioned legitimacy check method to check whether the migration CID obtained by the detection is legal. If it is legal, subsequent processing is performed; if it is illegal, the DPI system considers that the flow is not a true QUIC migration flow, marks the flow, and does not further process the message of the flow. The specific implementation method of subsequently generating the migration CID triple through the migration CID is basically the same as the specific implementation method in the above-mentioned fast correlation identification, and will not be repeated here.

[0115] Exemplarily, the first identification feature is a migration network address triplet, and determining the first identification feature corresponding to the QUIC migration flow includes: obtaining a migration quintuple from the QUIC migration flow; extracting a first part of the content from the migration quintuple as the migration network address triplet; the first part of the content does not change before and after the connection migration; the metadata object is a negotiation network address triplet object, and the second identification feature is a negotiation network address triplet, and matching the negotiation service type corresponding to the first identification feature from the metadata object includes: matching the negotiation service type corresponding to the negotiation network address triplet that is the same as the migration network address triplet from the negotiation network address triplet object.

[0116] Referring to Figure 13, Figure 13 is a flow chart of weak correlation identification involved in the second embodiment of the method for determining the service type of network traffic of the present application. The DPI system uses the network IP address, network port, and transport layer protocol type as the migration network address triplet to query whether the negotiation network address triplet object corresponding to the migration network address triplet exists. If it exists, the DPI system obtains the negotiation service type of the corresponding QUIC negotiation flow record from the negotiation network address triplet object, and uses the negotiation service type as the migration service type of the QUIC migration flow, thereby completing the identification of the QUIC migration flow.

[0117] Referring to Figure 14, Figure 14 is a schematic diagram of the results recorded in the negotiated network address triplet object involved in the second embodiment of the method for determining the service type of network traffic of the present application. If the negotiated network address triplet object records multiple different negotiated service types, the DPI system can assign the corresponding migration service type to the QUIC migration flow based on the relationship between the multiple negotiated service types.

[0118] As shown in Figure 14, the multiple different negotiation service types recorded in the negotiation network address triplet object include the following four situations:

[0119] Case A: If only one negotiated service type is recorded in the negotiated network address triplet object, the DPI system directly uses the negotiated service type as the migration service type of the QUIC migration flow to complete the identification of the QUIC migration flow.

[0120] Case B: The negotiated network address triplet object records multiple different negotiated service types, and there is an inclusion relationship between them. In this case, the DPI system uses the most generalized negotiated service type in the inclusion relationship as the migration service type for the QUIC migration flow based on the preset inclusion relationship information of the negotiated service types. As shown in Figure 14, the negotiated network address triplet object records three different negotiated service types: negotiated service type 1 is Google, negotiated service type 2 is Google Play, and negotiated service type 3 is Gmail. The system also presets the known information that "Google includes Google Play and Gmail." In this case, the DPI system selects negotiated service type 1 and deems the migration service type for the QUIC migration flow to be Google.

[0121] Case C: The negotiated network address triplet object records multiple negotiated service types, and there is a non-inclusion relationship between them. However, based on the preset inclusion relationship information of the negotiated service types, the DPI system knows that these negotiated service types all belong to another generalized negotiated service type. The system then selects this generalized negotiated service type as the migration service type for the QUIC migration flow. As shown in Figure 14, the negotiated network address triplet object records three different negotiated service types: negotiated service type 1 is Google Drive, negotiated service type 2 is Google Play, and negotiated service type 3 is Gmail. These three negotiated service types do not have a non-inclusion relationship with each other, but the DPI system presets the known information that "Google includes Google Drive, Google Play, and Gmail." Therefore, the DPI system considers the migration service type of the QUIC migration flow to be Google.

[0122] Case D: The negotiated network address triplet object records multiple negotiated service types, and there is a non-inclusion relationship between them. The DPI system knows that these negotiated service types do not belong to a generalized negotiated service type based on the preset inclusion relationship information of the negotiated service types. In this case, the DPI system believes that the QUIC migration flow cannot be identified as a specific service type, but the DPI system can identify the QUIC migration flow as "QUIC". The QUIC migration flow is a purely encrypted stream without DPI features. If it is not identified as "QUIC", the DPI system usually cannot identify the QUIC migration flow, and the identification result is usually set to "Unknown UDP". Therefore, although the QUIC migration flow cannot be specifically identified due to the conflict of multiple negotiated service types, the result of identifying the flow as "QUIC" is still better than "Unknown UDP".

[0123] Exemplarily, the method for determining the service type of network traffic further includes: placing identification result information corresponding to the migration service type into an extension field of a tunnel header of a third message; and sending the third message to an external system.

[0124] 15 , which is a schematic diagram illustrating the interaction between the DPI system and the external system involved in the second embodiment of the method for determining the service type of network traffic of the present application.

[0125] After completing the identification of the QUIC migration flow through the associated identification method in the aforementioned steps and successfully obtaining the migration service type of the QUIC migration flow, the DPI system can place the identification result information of the QUIC migration flow into the extension field of the tunnel header of the third message. This allows the external system to directly obtain the migration service type of the QUIC migration flow from the extension field of the tunnel header after forwarding the third message to the external system. This reduces the external system's repeated identification of the QUIC migration flow and other related processing, thereby improving the performance of the external system.

[0126] The identification result information of the QUIC migration flow placed in the extension field of the third message tunnel header includes but is not limited to: whether the flow to which the third message belongs is a QUIC migration flow, the DPI identification result of the flow to which the third message belongs, whether the identification result of the third message is accurate, and the QUIC CID length of the third message (i.e., the migration length).

[0127] Regarding whether the flow to which the third message belongs is a QUIC migration flow, after the external system reads the identification result information, it can know whether the third message and the flow to which it belongs are QUIC migration flows.

[0128] The DPI identification result of the flow to which the third packet belongs. After reading the identification result information, the external system can obtain the specific DPI identification result of the third packet and its flow, such as "Google", "Youtube", "QUIC", etc. Exemplarily, the DPI identification result can be in the form of a numerical AppID agreed upon with the external system, such as the agreed AppID for "Google" is 2, the AppID for "Youtube" is 3, and the AppID for "QUIC" is 1.

[0129] Whether the identification result of the third message is accurate. After reading the identification result information, the external system can determine whether the DPI identification result of the third message and its flow is accurate. For DPI identification results obtained using the fast association identification method or the strong association identification method, the DPI system sets this extended information as accurate; for DPI identification results obtained using the weak association identification method, the extended information is set as inaccurate.

[0130] Regarding the QUIC CID length of the third message, after reading the identification result information, the external system can extract the migration CID based on the QUIC CID length and associate the QUIC negotiation stream with the migration CID to unify the QUIC migration stream and its corresponding QUIC negotiation stream.

[0131] In one embodiment, taking the PGW (PDN GateWay) network element of the core network in the 3GPP (3rd Generation Partnership Project) 4G network as an example, the PGW network element is used as the host network element of the DPI system, and the third message is transmitted between the PGW network element and the wireless access network eNodeB network element through the GTPU (GPRS Tunneling Protocol) tunnel. The DPI system encapsulates the identification result information of the QUIC migration flow of the third message in the GTPU Private Extension extension field, so that the eNodeB network element directly obtains the identification result information in the third message from the extension field, which greatly reduces the processing burden of the eNodeB network element for performing corresponding identification and detection on the third message.

[0132] In another embodiment, taking the core network UPF (User Plane Function) network element in the 3GPP 5G network as an example, the UPF network element is used as the host network element of the DPI system, and the third message is transmitted between the UPF network element and the wireless access network gNodeB network element through the GTPU tunnel. The DPI system encapsulates the identification result information of the QUIC migration flow of the third message in the GTPU Private Extension extension field, so that the gNodeB network element directly obtains the identification result information of the third message from the extension field, which greatly reduces the processing burden of the gNodeB network element for performing corresponding identification and detection on the third message.

[0133] In addition, the present application also provides a device for determining a service type of network traffic, the device for determining a service type of network traffic comprising:

[0134] an acquisition module, configured to acquire a QUIC migration flow and determine a first identification feature corresponding to the QUIC migration flow;

[0135] A matching module is used to match the negotiation service type corresponding to the first identification feature from the metadata object; the metadata object is generated based on the second identification feature and the negotiation service type corresponding to the QUIC negotiation flow corresponding to the QUIC migration flow; and the negotiation service type is used as the migration service type corresponding to the QUIC migration flow.

[0136] Exemplarily, the first identification feature is a migration CID triplet, and the migration CID triplet includes at least a migration CID; and the acquisition module is specifically configured to:

[0137] Determining the migration CID based on the QUIC migration flow;

[0138] generating the migration CID triplet based on the migration CID;

[0139] The metadata object is a negotiation CID triplet object, the second identification feature is a negotiation CID triplet, and obtaining the negotiation service type corresponding to the first identification feature from the metadata object by matching includes:

[0140] A negotiation service type corresponding to the negotiation CID triplet that is the same as the migration CID triplet is matched and obtained from the negotiation CID triplet object.

[0141] Exemplarily, the acquisition module is further configured to:

[0142] Obtaining a migration quad from the QUIC migration stream;

[0143] Determine, from the negotiation quadruple object corresponding to the QUIC negotiation stream, a negotiation value corresponding to the negotiation quadruple that is identical to the migration quadruple; the negotiation value is the negotiation length of the negotiation CID corresponding to the QUIC negotiation stream; and the negotiation length is the same as the migration length of the migration CID;

[0144] Based on the migration length, extract the migration CID from the first packet in the QUIC migration flow.

[0145] Exemplarily, the acquisition module is further configured to:

[0146] Determining whether the migration CID is legal;

[0147] If yes, the step of generating the migration CID triplet based on the migration CID is performed.

[0148] Exemplarily, the acquisition module is further configured to:

[0149] Obtaining multiple second messages in the QUIC migration flow;

[0150] Extracting the longest common prefix code stream from the multiple second messages;

[0151] The migration CID is determined based on the longest common prefix code stream.

[0152] Exemplarily, the first identification feature is a migration network address triplet, and the acquisition module is further configured to:

[0153] Obtain a migration quintuple from the QUIC migration stream;

[0154] Extracting a first portion of content from the migration quintuple as the migration network address triplet; the first portion of content does not change before and after the connection migration;

[0155] The metadata object is a negotiated network address triplet object, the second identification feature is a negotiated network address triplet, and obtaining the negotiated service type corresponding to the first identification feature from the metadata object by matching includes:

[0156] The negotiation service type corresponding to the negotiation network address triplet that is the same as the migration network address triplet is matched and obtained from the negotiation network address triplet object.

[0157] Exemplarily, the network traffic service type determination device further includes:

[0158] an inserting module, configured to insert the identification result information corresponding to the migration service type into an extension field of the tunnel header of the third message;

[0159] A sending module is used to send the third message to an external system.

[0160] The specific implementation of the device for determining the service type of network traffic in the present application is basically the same as the first embodiment of the method for determining the service type of network traffic described above, and will not be repeated here.

[0161] In addition, the present application also provides a device for determining a service type of network traffic, the device for determining a service type of network traffic comprising:

[0162] The first acquisition module is used to obtain the QUIC negotiation stream;

[0163] A determination module, configured to determine a second identification feature corresponding to the QUIC negotiation flow, and determine a negotiation service type corresponding to the QUIC negotiation flow;

[0164] The first generation module is used to generate a metadata object based on the second identification feature and the negotiation service type; the metadata object is used to determine the migration service type corresponding to the QUIC migration flow corresponding to the QUIC negotiation flow.

[0165] Exemplarily, the second identification feature is a negotiation CID triplet, and the negotiation CID triplet includes at least a negotiation CID; and the determining module is specifically configured to:

[0166] Obtain the negotiation CID from the QUIC negotiation stream;

[0167] generating the negotiated CID triplet based on the negotiated CID;

[0168] The metadata object is a negotiation CID triplet object, and generating the metadata object based on the second identification feature and the negotiation service type includes:

[0169] The negotiated CID triplet object is generated based on the negotiated CID triplet and the negotiated service type; the migration CID triplet is used to match the negotiated service type corresponding to the same negotiated CID triplet as the migration CID triplet from the negotiated CID triplet object.

[0170] Exemplarily, the network traffic service type determination device further includes:

[0171] A second acquisition module is configured to acquire a negotiation quadruple and a negotiation length of the negotiation CID from the QUIC negotiation stream;

[0172] The second generation module is used to generate a negotiation quadruple object based on the negotiation length and the negotiation quadruple; the negotiation quadruple object is used to extract the migration CID from the first message in the QUIC migration flow; the migration CID is used to generate the migration CID triplet.

[0173] Exemplarily, the second identification feature is a negotiated network address triplet, and the determination module is specifically configured to:

[0174] Obtain a negotiation quintuple from the QUIC negotiation stream;

[0175] Extracting a second portion of content from the negotiation quintuple as the negotiation network address triplet; the second portion of content does not change before and after the connection migration;

[0176] The metadata object is a negotiated network address triplet object, and generating the metadata object based on the second identification feature and the negotiated service type includes:

[0177] The negotiated network address triplet object is generated based on the negotiated network address triplet and the negotiated service type.

[0178] The specific implementation of the device for determining the service type of network traffic in the present application is basically the same as the second embodiment of the method for determining the service type of network traffic described above, and will not be repeated here.

[0179] In addition, the present application also provides an electronic device. As shown in FIG16 , FIG16 is a schematic diagram of the structure of the hardware operating environment involved in the embodiment of the present application.

[0180] As shown in Figure 16, the electronic device may include a processor 1601, a communication interface 1602, a memory 1603 and a communication bus 1604, wherein the processor 1601, the communication interface 1602 and the memory 1603 communicate with each other through the communication bus 1604, the memory 1603 is used to store computer programs; the processor 1601 is used to implement the steps of the method for determining the business type of network traffic when executing the program stored in the memory 1603.

[0181] The communication bus 1604 mentioned in the electronic device can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The communication bus 1604 can be divided into an address bus, a data bus, and a control bus. For ease of illustration, the figure shows only one thick line, but this does not mean that there is only one bus or only one type of bus.

[0182] The communication interface 1602 is used for communication between the electronic device and other devices.

[0183] The memory 1603 may include random access memory (RMD) or non-volatile memory (NM), such as at least one disk storage. In one embodiment, the memory 1603 may also be at least one storage device located remotely from the processor 1601.

[0184] The above-mentioned processor 1601 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, and discrete hardware component objects.

[0185] The specific implementation of the electronic device of the present application is basically the same as the embodiments of the above-mentioned method for determining the service type of network traffic, and will not be repeated here.

[0186] In addition, an embodiment of the present application also proposes a computer-readable storage medium, which stores a program for determining the business type of network traffic. When the program for determining the business type of network traffic is executed by a processor, the steps of the method for determining the business type of network traffic as described above are implemented.

[0187] The specific implementation of the computer-readable storage medium of the present application is basically the same as the various embodiments of the method for determining the service type of network traffic described above, and will not be repeated here.

[0188] As used herein, the terms "comprises," "comprising," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or system that includes a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or system. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not preclude the presence of additional identical elements in the process, method, article, or system that includes the element.

[0189] The serial numbers of the above embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0190] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus the necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes a number of instructions for enabling a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in each embodiment of the present application.

[0191] The above are merely optional embodiments of the present application and do not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A method for determining the service type of network traffic, wherein: The method for determining the service type of network traffic comprises the following steps: Obtain a QUIC migration flow, and determine a first identification feature corresponding to the QUIC migration flow; Matching and obtaining a negotiation service type corresponding to the first identification feature from a metadata object; the metadata object is generated based on a second identification feature and a negotiation service type corresponding to the QUIC negotiation flow corresponding to the QUIC migration flow; The negotiated service type is used as the migration service type corresponding to the QUIC migration flow.

2. The method for determining the service type of network traffic according to claim 1, wherein: The first identification feature is a migration CID triplet, and the migration CID triplet includes at least a migration CID; and determining the first identification feature corresponding to the QUIC migration flow includes: Determining the migration CID based on the QUIC migration flow; generating the migration CID triplet based on the migration CID; The metadata object is a negotiation CID triplet object, the second identification feature is a negotiation CID triplet, and the matching from the metadata object to obtain the negotiation service type corresponding to the first identification feature includes: A negotiation service type corresponding to the negotiation CID triplet that is the same as the migration CID triplet is matched and obtained from the negotiation CID triplet object.

3. The method for determining the service type of network traffic according to claim 2, wherein: The determining the migration CID based on the QUIC migration flow includes: Obtaining a migration quad from the QUIC migration stream; Determine, from the negotiation quadruple object corresponding to the QUIC negotiation stream, a negotiation value corresponding to the negotiation quadruple that is the same as the migration quadruple; the negotiation value is the negotiation length of the negotiation CID corresponding to the QUIC negotiation stream; the negotiation length is the same as the migration length of the migration CID; Based on the migration length, extract the migration CID from the first message in the QUIC migration flow.

4. The method for determining the service type of network traffic according to claim 2, wherein: Before generating the migration CID triplet based on the migration CID, the method includes: Determining whether the migration CID is legal; If yes, the step of generating the migration CID triplet based on the migration CID is performed.

5. The method for determining the service type of network traffic according to claim 2, wherein: The determining the migration CID based on the QUIC migration flow includes: Obtain multiple second messages in the QUIC migration flow; Extracting the longest common prefix code stream from the multiple second messages; The migration CID is determined based on the longest common prefix code stream.

6. The method for determining the service type of network traffic according to claim 1, wherein: The first identification feature is a migration network address triplet, and determining the first identification feature corresponding to the QUIC migration flow includes: Obtain a migration quintuple from the QUIC migration stream; Extracting the first part of the content from the migration quintuple as the migration network address triplet; the first part of the content does not change before and after the connection migration; The metadata object is a negotiated network address triplet object, the second identification feature is a negotiated network address triplet, and the negotiation service type corresponding to the first identification feature is obtained by matching from the metadata object, including: A negotiation service type corresponding to the negotiation network address triplet that is the same as the migration network address triplet is matched and obtained from the negotiation network address triplet object.

7. The method for determining the service type of network traffic according to claim 1, wherein: The method for determining the service type of network traffic also includes: Putting the identification result information corresponding to the migration service type into the extension field of the tunnel header of the third message; The third message is sent to the external system.

8. A method for determining the service type of network traffic, wherein: The method for determining the service type of network traffic comprises the following steps: Get the QUIC negotiation stream; Determine a second identification feature corresponding to the QUIC negotiation flow, and determine a negotiation service type corresponding to the QUIC negotiation flow; A metadata object is generated based on the second identification feature and the negotiated service type; the metadata object is used to determine the migration service type corresponding to the QUIC migration flow corresponding to the QUIC negotiation flow.

9. The method for determining the service type of network traffic according to claim 8, wherein: The second identification feature is a negotiation CID triplet, and the negotiation CID triplet at least includes a negotiation CID; The determining a second identification feature corresponding to the QUIC negotiation stream includes: Obtain the negotiation CID from the QUIC negotiation stream; generating the negotiation CID triplet based on the negotiation CID; The metadata object is a negotiation CID triplet object, and the generating of the metadata object based on the second identification feature and the negotiation service type includes: The negotiated CID triplet object is generated based on the negotiated CID triplet and the negotiated service type; the migration CID triplet is used to match the negotiated service type corresponding to the negotiated CID triplet that is the same as the migration CID triplet from the negotiated CID triplet object.

10. The method for determining the service type of network traffic according to claim 9, wherein: The method for determining the service type of network traffic also includes: Obtaining a negotiation quadruple and a negotiation length of the negotiation CID from the QUIC negotiation stream; A negotiation quadruple object is generated based on the negotiation length and the negotiation quadruple; the negotiation quadruple object is used to extract a migration CID from a first message in the QUIC migration flow; and the migration CID is used to generate the migration CID triplet.

11. The method for determining the service type of network traffic according to claim 8, wherein: The second identification feature is a negotiation network address triplet, and determining the second identification feature corresponding to the QUIC negotiation stream includes: Obtain a negotiation quintuple from the QUIC negotiation stream; Extracting the second part of the content from the negotiation quintuple as the negotiation network address triplet; the second part of the content does not change before and after the connection migration; The metadata object is a negotiated network address triplet object, and the step of generating the metadata object based on the second identification feature and the negotiated service type includes: The negotiated network address triplet object is generated based on the negotiated network address triplet and the negotiated service type.

12. An electronic device, wherein: The electronic device comprises: a memory, a processor, and a program for determining the business type of network traffic stored in the memory and executable on the processor, wherein the program for determining the business type of network traffic is configured to implement the steps of a method for determining the business type of network traffic as described in any one of claims 1 to 11.

13. A computer-readable storage medium, wherein: The computer-readable storage medium stores a program for determining the service type of network traffic, and when the program for determining the service type of network traffic is executed by a processor, the steps of the method for determining the service type of network traffic according to any one of claims 1 to 11 are implemented.

Citation Information

Patent Citations

  • A method of detecting quick user datagram protocol internet connections, QUIC, traffic in a telecommunication network between a user equipment UE and a content provider cp

    CN112997460A

  • Data transmission method and device, terminal and storage medium

    CN114221909A

  • Classification of encrypted internet traffic

    US11533299B2

  • SNI domain name extraction method, electronic device, and computer-readable storage medium

    WO2023071958A1