Packet processing method and packet processing device

Abstract

The application discloses a message processing method and device, and relates to the technical field of communication. The method comprises the following steps: establishing a communication connection through handshake request information, confirming a new message type for adjusting a data flow communication port, and allocating a communication interface for data flow transmission according to the new message type, so that data flow messages and control flow messages are transmitted through different ports, and the message transmission path and the reasonable allocation of resources are optimized. The technical problems that, in the prior art, control flow messages occupy CPU resources, affect the data flow message forwarding efficiency, and control flow messages are prone to packet loss due to resource competition are solved, and the technical effects of high transmission efficiency and low packet loss rate are achieved.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to a message processing method and a message processing device. Background Art

[0002] SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are protocols used to protect network communications. Both reside between the TCP / IP protocol and the application layer, and are primarily used to establish encrypted connections between clients and servers to ensure the security and integrity of data transmission. TLS is a successor to SSL, providing improved security and the ability to avoid vulnerabilities in older protocols. The DTLS protocol (Datagram Transport Layer Security), a derivative of the TLS protocol, is designed specifically for UDP and aims to overcome the application limitations of TLS in UDP environments. The DTLS protocol supports the UDP protocol by extending the TLS architecture, enabling it to provide data encryption and integrity protection in a connectionless, unreliable UDP environment.

[0003] However, the SSL / TLS / DTLS protocols primarily focus on providing security and encryption at the transport layer and are not designed to accelerate business data processing down to the data plane or lower layers. When network resources are limited, rate-limiting devices struggle to effectively distinguish between SSL / TLS / DTLS protocol control messages and business forwarding messages. As a result, control messages may be overwhelmed by a large number of business messages and fail to reach the other end. Furthermore, the lack of separation between the forwarding and control planes in the DTLS protocol means that CPU resources are consumed when processing control messages, which in turn affects the forwarding efficiency of business messages. Summary of the Invention

[0004] The embodiments of the present application provide a message processing method and a message processing device to solve the technical problems in the prior art that control flow messages occupy CPU resources and affect the forwarding efficiency of data flow messages, and that control flow messages are prone to packet loss due to resource competition, thereby achieving the technical effects of high transmission efficiency and low packet loss rate.

[0005] In a first aspect, an embodiment of the present application provides a message processing method, comprising the following steps:

[0006] In response to a handshake request message sent by the client, establishing a communication connection, and generating communication information related to the handshake request message, wherein the communication information includes a new message type, and the new message type is used to adjust a data stream communication port, wherein the data stream communication port refers to a destination port for transmitting a data stream between the client and the server;

[0007] Allocating a communication interface according to the communication information, wherein the communication interface refers to a data stream communication port for data stream transmission;

[0008] Sending a port change agreement to the client, wherein the port change agreement carries information related to the communication interface;

[0009] Identify the message attributes of the target message and perform data interaction according to the message attributes, wherein the message attributes include a data flow message and a control flow message, and the sequence number of the data flow message and the sequence number of the control flow message are calculated independently.

[0010] In a second aspect, an embodiment of the present application provides a message processing device, including:

[0011] a response module, configured to respond to a handshake request message sent by a client, establish a communication connection, and generate communication information related to the handshake request message, wherein the communication information includes a new message type, and the new message type is used to adjust a data stream communication port, wherein the data stream communication port refers to a destination port for transmitting a data stream between a client and a server;

[0012] an allocation module, configured to allocate a communication interface according to the communication information, wherein the communication interface refers to a data stream communication port for data stream transmission and a control stream communication interface for control stream transmission;

[0013] A change module, configured to send a port change agreement to the client, wherein the port change agreement carries information related to the communication interface;

[0014] The interaction module is used to identify the message attributes of the target message and perform data interaction according to the message attributes, wherein the message attributes include data flow message and control flow message, and the sequence number of the data flow message and the sequence number of the control flow message are calculated independently.

[0015] One or more technical solutions provided in the embodiments of the present application have at least the following technical effects or advantages: establishing a communication connection through handshake request information, confirming a new message type for adjusting the data flow communication port, and allocating a communication interface for data flow transmission based on the new message type, so that data flow messages and control flow messages are transmitted using different ports, thereby optimizing message transmission paths and rational allocation of resources. This solves the technical problems in the prior art where control flow messages occupy CPU resources, affecting the forwarding efficiency of data flow messages, and where control flow messages are prone to packet loss due to resource competition, thereby achieving the technical effects of high transmission efficiency and low packet loss rate. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 A flowchart of a message processing method provided in at least one embodiment of the present application;

[0017] Figure 2An example diagram of a message processing method provided in at least one embodiment of the present application;

[0018] Figure 3 An example flow chart of a message processing method provided in at least one embodiment of the present application;

[0019] Figure 4 A flow chart of a method for establishing a communication connection provided in at least one embodiment of the present application;

[0020] Figure 5 An example diagram of key negotiation provided in at least one embodiment of the present application;

[0021] Figure 6 A flowchart of a key negotiation method provided in at least one embodiment of the present application;

[0022] Figure 7 A flowchart of a method for negotiating a response session provided in at least one embodiment of the present application;

[0023] Figure 8 A flowchart of a method for searching a control flow session provided in at least one embodiment of the present application;

[0024] Figure 9 A flow chart of a data interaction method provided in at least one embodiment of the present application;

[0025] Figure 10 A schematic diagram of the structure of a message processing device provided in at least one embodiment of the present application;

[0026] Figure 11 A flowchart of the encryption encapsulation method provided in at least one embodiment of the present application;

[0027] Figure 12 An example diagram of encryption packaging provided by at least one embodiment of the present application;

[0028] Figure 13 A first example flow chart of encryption encapsulation provided for at least one embodiment of the present application;

[0029] Figure 14 A second example flow chart of encryption encapsulation provided for at least one embodiment of the present application;

[0030] Figure 15 A flowchart of a decapsulation method provided in at least one embodiment of the present application;

[0031] Figure 16 An example diagram of decapsulation provided for at least one embodiment of the present application;

[0032] Figure 17 A first exemplary flow chart of decapsulation provided for at least one embodiment of the present application;

[0033] Figure 18 A second exemplary flow chart of decapsulation provided for at least one embodiment of the present application;

[0034] Figure 19 A flow chart of a method for determining a UDP session provided in at least one embodiment of the present application;

[0035] Figure 20 An example flow chart for determining a UDP session provided in at least one embodiment of the present application;

[0036] Figure 21 A schematic diagram of the structure of a message processing device provided in at least one embodiment of the present application;

[0037] Figure 22 A module diagram of an electronic device provided in at least one embodiment of the present application. DETAILED DESCRIPTION

[0038] The embodiments of the present application provide a message processing method that establishes a communication connection through handshake request information, identifies a new message type for adjusting the data flow communication port, and allocates a communication interface for data flow transmission based on the new message type, so that data flow messages and control flow messages are transmitted using different ports. This optimizes message transmission paths and rationally allocates resources. This solves the technical problems in the prior art where control flow messages occupy CPU resources, affecting the forwarding efficiency of data flow messages, and where control flow messages are prone to packet loss due to resource competition, thereby achieving high transmission efficiency and low packet loss rate.

[0039] The DTLS protocol evolved from the TLS protocol. A key difference between the two is that the transport layer of the TLS protocol is carried by the TCP protocol, while the transport layer of the DTLS protocol is carried by the UDP protocol. DTLS inherits most of the features of the TLS protocol, including the fact that both DTLS and TLS protocols are independent of each other in terms of forwarding and control. This integration of forwarding and control is reflected in the fact that forwarding and control plane messages share the same UDP five-tuple (source address, source port, destination address, destination port, and transport layer protocol), share the same session, the same TCP / UDP protocol stack, and the same processing program. Similar to TLS, the DTLS protocol can be divided into two layers: the bottom layer protocol and the upper layer protocol. The bottom layer protocol is the record layer protocol, while the upper layer protocol is further divided into the handshake protocol, alerting protocol, cipher specification change protocol, and application data processing. The DTLS handshake protocol's primary capability is DTLS key negotiation. The handshake interaction ultimately results in a set of negotiated session keys for DTLS. This session key information includes the session identifier, compression algorithm, encryption algorithm and mode, authentication algorithm, and session key. The DTLS Alert Protocol communicates alerts to the peer during the handshake negotiation process. The DTLS Cipher Specification Change Protocol notifies the peer to use the newly negotiated ciphers for encrypted communications upon completion of the handshake negotiation. DTLS Application Data Processing encapsulates and decapsulates DTLS-carried services based on the keys negotiated during the handshake.

[0040] In terms of protocol nature, messages exchanged via the Handshake Protocol (protocol number 22), Alarm Protocol (protocol number 21), and Password Specification Change Protocol (protocol number 20) are all considered control messages, while messages using the Application Data Processing Encapsulation (protocol number 23) are considered forwarding messages.

[0041] The DTLS protocol mixes the aforementioned handshake protocol, alert protocol, cryptographic specification change protocol, and application data processing together, and all of these are handled by the application-level control plane program. This significantly reduces DTLS's efficiency in forwarding service data. Furthermore, DTLS's control messages are processed together with service forwarding messages, and these messages share the same IP layer and transport layer network characteristics. When the network's carrying capacity is limited, the rate-limiting devices in the network cannot effectively distinguish between DTLS's control messages and service messages, and will indiscriminately limit and drop packets for both. Consequently, control messages, overwhelmed by service messages, cannot effectively reach the other end, causing numerous unnecessary link interruptions and significantly impacting the stability of the DTLS connection.

[0042] Traditional DTLS protocol control messages and service forwarding messages share the same network and flow control characteristics and belong to the same session. Traditional DTLS protocol control and forwarding data are processed together, making it impossible for SSLVPN implementation equipment to transfer traditional DTLS protocol service data to high-speed data plane processing components. Traditional DTLS not only reduces service data forwarding efficiency but also suffers from poor connection stability caused by rate-limiting devices in the network indiscriminately discarding DTLS protocol service and control messages.

[0043] The extended DTLS protocol proposed in this application fundamentally enables the DTLS protocol to have the ability to separate control and transfer at the protocol level, so that control data and business data do not share ports, sessions, or implementation entities. This is a capability that traditional SSL / TLS / DTLS protocols do not have.

[0044] In addition, this application also proposes a protocol processing method based on this extended DLTS protocol. The implementation system implemented according to the method proposed in this article can achieve DTLS control separation.

[0045] Based on this application, not only can the SSLVPN implementation equipment greatly improve the DTLS service message processing capability, but it can also provide the speed-limiting devices in the network with different traffic characteristics of DTLS protocol control messages and service forwarding messages, and assign different service levels to DTLS control messages and service forwarding messages, thereby giving priority to the passage of DTLS protocol control messages and thus ensuring the stability of the DTLS connection.

[0046] The following are some explanations of terms:

[0047] VPN (Virtual Private Network) is a technology that uses virtualization technology to establish a virtual private network on a public network. It is used to protect network communication security and is a general term for a series of protocol technologies.

[0048] TLS (Transport Layer Security): A type of VPN that operates at the transport layer, providing data confidentiality, integrity, and authentication of both communicating parties. The latest TLS protocol version is TLSv1.3.

[0049] DTLS (Datagram Transport Layer Security): A transport layer security protocol that uses the UDP protocol. The latest DTLS protocol version is DTLSv1.3.

[0050] VPP (Vector Packet Processing): A user-mode protocol stack open sourced by Cisco that offers powerful data plane processing and Layer 3 forwarding capabilities.

[0051] UDP (User Datagram Protocol): A transport layer protocol defined by RFC 768. It is a connectionless, datagram-oriented transmission protocol with the characteristics of low latency, high performance, and low header overhead.

[0052] TCP (Transmission Control Protocol): A transport layer protocol defined by RFC 793. It is a connection-oriented, reliable, byte stream-based transmission protocol with features such as reliable transmission and transmission congestion control.

[0053] In order to better understand the above technical solution, the above technical solution will be described in detail below with reference to the accompanying drawings and specific implementation methods.

[0054] Example 1

[0055] Please refer to Figure 1 , an embodiment of the present application provides a message processing method, comprising the following steps:

[0056] S100. Respond to the handshake request information sent by the client, establish a communication connection, and generate communication information related to the handshake request information. The communication information includes a new message type. The new message type is used to adjust the data flow communication port. The data flow communication port refers to the destination port for transmitting data flow between the client and the server.

[0057] Specifically, the handshake request message is the first message in the handshake process, used to indicate the intention to establish a communication connection and provide the parameters required for the communication connection. The handshake request message is used to perform handshake verification with the client, establish a communication connection, and generate communication information. The communication information includes at least the session key, the encryption communication algorithm, and the new message type. The session key and encryption communication algorithm are used for data encryption, and the new message type indicates the destination port for the data flow between the client and the server.

[0058] For example, a handshake request message is a synchronization message sent by a client requesting a connection. Upon receiving the message, the server sends a synchronization confirmation message indicating readiness to establish the connection. Finally, the client sends a connection confirmation message to establish the communication connection. New message types are added to the handshake protocol. By adding new message types and assigning them numbers greater than 20, the new message types are effectively distinguished from existing message types in the handshake protocol, enabling the adjustment of data flow communication ports.

[0059] S200. Allocate a communication interface according to communication information, where the communication interface refers to a data stream communication port used for data stream transmission.

[0060] For example, determining and allocating data flow communication ports based on new message types in communication information ensures that control flow messages and data flow messages are transmitted using different ports. This can reduce retransmission and processing delays caused by message disorder or loss, reducing overall communication overhead and latency. Using independent communication interfaces to transmit messages can better isolate the control plane and data plane, preventing potential security threats from affecting the security of data transmission. In situations where network resources are limited, this can prevent control flow messages from being overwhelmed by a large number of business messages and unable to effectively reach the other end.

[0061] S300: Send a port change agreement to the client, where the port change agreement carries information related to the communication interface.

[0062] Specifically, the port change protocol involves renegotiating the communication interface to adapt to new communication requirements. In this embodiment, by sending a port change protocol to the client, the data flow communication interface is adjusted so that the data flow messages and the control flow messages are transmitted using different ports, thereby preventing the control flow messages from occupying CPU resources and affecting the forwarding efficiency of the data flow messages, and preventing the control flow messages from being easily lost due to resource competition.

[0063] S400: Identify the message attributes of the target message and perform data exchange according to the message attributes. The message attributes include data flow messages and control flow messages. The sequence numbers of the data flow messages and the control flow messages are calculated independently.

[0064] Specifically, target messages refer to messages to be transmitted, including data stream messages, data stream keepalive messages, control stream messages, and control stream keepalive messages. Sequence numbers are used to identify the order of messages. Independently calculating the sequence numbers for data stream and control stream messages ensures independent processing of these two types, improving the security and reliability of message processing.

[0065] Exemplarily, the message processing method provided in this embodiment is implemented based on an SSLVPN server of the DTLS protocol with forwarding and control separation. The specific processing steps of the DTLS protocol processing method based on forwarding and control separation are as follows:

[0066] Step 1: Calculate the sequence numbers for the control stream messages, including the DTLS handshake protocol (protocol number 22), alert protocol (protocol number 21), and cipher specification change protocol (protocol number 20). Calculate the sequence numbers for the data stream messages of the Application Data Processing Encapsulation Protocol (protocol number 23) separately. Calculate the sequence numbers for data stream messages and control stream messages separately.

[0067] Step 2: Extend a message type named "Data Stream Port Change" for the handshake protocol (protocol number 22). Define the message type msg_type as 21. This message type carries the communication destination port of the data stream (i.e., the service forwarding message) sent from the client to the server. This port is not fixed and is randomly assigned by the server. The "Data Stream Port Change" message is sent by the DTLS server to the DTLS client after the key exchange is completed and before the key specification change protocol. On the one hand, the destination port of the control stream message sent by the DTLS client to the server continues to use the destination port set by the traditional DTLS protocol (for example, 443). On the other hand, the destination port of the data stream message sent by the DTLS client to the server uses the port carried by the server in the "Data Stream Port Change" message.

[0068] In this example, the DTLS protocol is not specific to a specific DTLS version and is applicable to the current DTLSv1.0, DTLSv1.2, and DTLSv1.3, as well as future higher versions of DTLS.

[0069] For example, the message processing method provided in this embodiment is implemented based on an SSLVPN server of the DTLS protocol with separation of forwarding and control. Figure 2-Figure 3 The specific steps for message processing by the SSLVPN server are as follows:

[0070] S110: The DTLS client and the DTLS server complete the DTLS protocol handshake exchange.

[0071] S120: The DTLS server allocates a data stream service port, that is, the port used for data stream communication (the destination port of the service forwarding message sent by the client to the server).

[0072] S130: The "Data Stream Port Change" protocol payload sent by the DTLS server to the client carries the data stream service port described in S120.

[0073] S140: Service data is exchanged between the DTLS client and the DTLS server. The UDP destination port in the service forwarding data sent from the client to the server is the port carried in the "Data Stream Port Change" protocol payload in S130. The sequence number of the data stream message is independent of the sequence number of the control stream message.

[0074] In this example, the DTLS client and DTLS server complete a DTLS handshake exchange through the SSLVPN server. The data stream service port refers to the communication interface. The port change protocol refers to the data stream port change protocol. Service forwarding data refers to data stream packets. After establishing a communication connection, the DTLS server sends a data stream port change protocol message carrying the data stream service port to the DTLS client to exchange service data. This ensures that when the client sends service forwarding data to the server, the UDP destination port matches the port carried in the data stream port change protocol payload. This significantly improves the SSLVPN implementation device's DTLS service packet processing capabilities and provides rate-limiting devices in the network with the different traffic characteristics of DTLS control packets and service forwarding packets, assigning different service levels to DTLS control packets and service forwarding packets. This prioritizes the passage of DTLS control packets and thus ensures the stability of the DTLS connection.

[0075] The technical solutions in the above embodiments of the present application have at least the following technical effects or advantages:

[0076] A communication connection is established through a handshake request message, a new message type for adjusting the data flow communication port is confirmed, and a communication interface for data flow transmission is allocated based on the new message type. This allows data flow messages and control flow messages to be transmitted using different ports, optimizing message transmission paths and resource allocation. This solves the technical problems in the prior art where control flow messages occupy CPU resources, affecting data flow message forwarding efficiency, and where control flow messages are prone to packet loss due to resource competition. This achieves high transmission efficiency and low packet loss.

[0077] Please refer to Figure 1 After S400, identifying the message attributes of the target message and performing data exchange according to the message attributes, the following steps are also included:

[0078] S500. Regularly receive control flow keep-alive messages or data flow keep-alive messages sent by the client. The control flow keep-alive messages and data flow keep-alive messages are generated by the control flow session keep-alive protocol and the data flow session keep-alive protocol respectively. The control flow keep-alive message uses the same source port and destination port as the control flow message, and the data flow keep-alive message uses the same source port and destination port as the data flow message.

[0079] Specifically, the control flow session keep-alive protocol and the data flow session keep-alive protocol are used to ensure the continuity of sessions in network communications. By regularly receiving control flow keep-alive messages or data flow keep-alive messages, the control flow session, data flow session, and the corresponding NAT session on the network communication link are kept alive respectively. By keeping the session active, connection timeout or disconnection due to long periods of no data transmission is prevented.

[0080] Exemplarily, the control flow session keep-alive protocol and the data flow session keep-alive protocol are generated by extending the record layer protocol type, and the control flow session keep-alive protocol and the data flow session keep-alive protocol are not subjected to the record layer encryption and compression, and are organized in a clear text manner. The control flow keep-alive message and the data flow keep-alive message use the same source port and destination port as the control flow message and the data flow message, so that the control flow keep-alive message and the data flow keep-alive message maintain consistent port information with the control flow message and the data flow message during transmission, ensuring correct routing and identification, and ensuring consistency with normal data transmission.

[0081] Exemplarily, as shown in Figure 2-Figure 3 S150: the client periodically sends the control flow keep-alive message to the server, and the message destination port is the same as the control flow service port of the server, or S160: the client periodically sends the data flow keep-alive message to the server, and the message destination port is the same as the data flow service port of the server.

[0082] S150 and S160 are both periodic tasks, and the periodic period can be changed by configuration, and the default periodic period is 20 seconds.

[0083] The source code corresponding to the control flow session packet or protocol is defined as follows:

[0084] struct{

[0085] enum{control_keepalive(1), 255}type;

[0086] }ControlKeepalive;

[0087] The source code corresponding to the data flow session packet or protocol is defined as follows:

[0088] struct{

[0089] enum{data_keepalive(1), 255}type;

[0090] }DataKeepalive;

[0091] Please refer to Figure 1 S500, periodically receiving the control flow keep-alive message or the data flow keep-alive message sent by the client, includes the following steps:

[0092] S600, discarding the control flow keep-alive message or the data flow keep-alive message.

[0093] Specifically, after receiving the control flow keep-alive message or the data flow keep-alive message, it is not necessary to respond to the control flow keep-alive message or the data flow keep-alive message, and the control flow session, the data flow session and the NAT session on the network communication link can be kept alive.

[0094] For example, control flow keep-alive messages or data flow keep-alive messages are used in NAT devices. When there is no data transmission, the NAT session may be deleted due to timeout. To avoid this situation, by regularly receiving control flow keep-alive messages and data flow keep-alive messages, NAT can perceive and reset the session timer to ensure that even if no response is given, the NAT session will not be interrupted due to no data transmission for a long time.

[0095] See also Figure 4 S100: Respond to the handshake request information sent by the client, establish a communication connection, and generate communication information related to the handshake request information, including the following steps:

[0096] S110: Receive the handshake request information sent by the client, and identify the IP address, UDP destination port, and message attributes of the handshake request information.

[0097] S120: When the message attribute is a control flow message, determine a negotiation response session according to the IP address and the UDP destination port.

[0098] S130: Perform key negotiation according to the negotiation response session and generate a negotiation response message.

[0099] S140. Encapsulate the UDP header and IP header for the negotiation response message and send it to the client for interaction, generating session key information. The session key information includes encryption algorithm and key information, authentication algorithm and key information, control stream sequence number, data stream sequence number, IP address, control stream destination port, and data stream destination port.

[0100] S150: Correlate the negotiation response session ID information and session key information.

[0101] In this embodiment, the handshake request information sent by the client is first received. During the receiving process, key elements in the handshake request information are identified, including the IP address that initiates the request, the UDP destination port, and the message attributes.

[0102] Then, by determining the message attributes, the handshake request information can be further confirmed. According to the IP address and UDP destination port, the corresponding negotiation response session is searched or created in the internal database, ensuring the accuracy and uniqueness of the session.

[0103] Then, the key negotiation is started according to the generated negotiation response session, in which multiple information exchanges are carried out according to a preset protocol or algorithm, and finally the negotiation response message is generated, which includes the key negotiation result approved by both parties and is the key to establish the secure communication.

[0104] Next, the UDP header and IP header are encapsulated for the negotiation response message to ensure that the negotiation response message can be correctly transmitted to the client. After the encapsulation, the negotiation response message is sent to the client for interaction, and the key session information constitutes the security basis of the session.

[0105] Finally, the ID information and the session key information of the negotiation response session are associated to facilitate the reuse of the negotiation response session parameters in subsequent communication and avoid re-key negotiation.

[0106] For example, please refer to Figure 5-Figure 6 , the implementation process is as follows:

[0107] S210: After the DPDK packet is received and IP routing, the message is sent to the udp4-input / udp6-input node processing logic.

[0108] S220: The udp4-input / udp6-input node identifies that the UDP destination port is the DTLS registered port, and sends the message to the DTLS conversion identification node processing logic.

[0109] S230: The DTLS conversion identification node analyzes the protocol number of the DTLS record layer in the message, and classifies the message according to the above method to identify the control flow message.

[0110] S240: The dtls-nego node is responsible for key negotiation, organizes the negotiation response message, and encapsulates the UDP header and IP header for the negotiation response message.

[0111] S250: The negotiation response message is sent to the ip4-output / ip6-output node, and finally the negotiation response message is sent out through the interface.

[0112] S260: After the negotiation message interaction is completed, the key information is updated into the key management module, and the control flow UDP session ID is associated into the corresponding key information.

[0113] S270: The data flow port is registered into the udp4-input / udp6-input node to facilitate the subsequent data flow message to be sent into the DTLS conversion control shunt module.

[0114] In this example, the Data Plane Development Kit (DPDK) first receives packets. After IP routing, these packets are correctly routed to the udp4-input (for IPv4) or udp6-input (for IPv6) nodes for subsequent processing logic based on their destination addresses. Using DPDK's packet processing capabilities ensures that packets are quickly and accurately forwarded to the appropriate processing nodes.

[0115] After receiving a data packet, the udp4-input or udp6-input node checks the UDP destination port. If the port is registered with the DTLS (Datagram Transport Layer Security) protocol, it indicates that the packet is intended for DTLS secure communication. The packet is then forwarded to the DTLS translation and identification node for subsequent security processing.

[0116] The DTLS conversion and identification node parses the DTLS record layer in the data packet to identify the protocol number. The data packet is classified according to the protocol number, and the classification results include data flow messages and control flow messages.

[0117] The dtls-nego node is used to negotiate security parameters in the DTLS protocol. When a data packet is a control flow message, the dtls-nego node is responsible for key negotiation. It also organizes the negotiation response message and ensures that it contains the necessary negotiation information. It then encapsulates the negotiation response message with a UDP header and an IP header to ensure that the data packet is properly transmitted across the network.

[0118] After encapsulation, the negotiation response message is sent to the ip4-output (for IPv4) or ip6-output (for IPv6) node. These nodes are responsible for sending the data packet through the network interface, thus completing the negotiation response message transmission process.

[0119] After the negotiation response message exchange is complete, the system updates the key information generated during the negotiation process to the key management module. At the same time, it associates the control flow UDP session ID with the corresponding key information so that these keys can be quickly retrieved and used in subsequent communications.

[0120] Finally, to support subsequent data stream communication, the system registers the data stream port with the udp4-input or udp6-input node. This allows for the correct identification of incoming data stream messages and their processing by the DTLS control and diversion module. This ensures secure and efficient data stream communication.

[0121] See also Figure 7 When the message attribute is a control flow message, S120, determining a negotiation response session according to the IP address and the UDP destination port, includes the following steps:

[0122] S121. Search for a control flow session related to the handshake request information through the IP address and UDP destination port.

[0123] S122: If the search fails, create a new control flow UDP session as a negotiation response session.

[0124] S123: If the search is successful, the control flow session is used as the negotiation response session.

[0125] In this embodiment, the IP address and UDP destination port are first used as search conditions to search for a control flow session related to the handshake request information in the established session list. If the search fails, it means that the handshake request information is a new request information, and the handshake request is processed by creating a new control flow UDP session as a negotiation response session. If the search is successful, it means that the handshake request information is part of an established session. In this case, the found control flow session is directly used as the negotiation response session, and the handshake request is continued to be processed, thereby ensuring communication continuity while avoiding unnecessary resource overhead.

[0126] For example, see Figure 8 , the implementation process is as follows:

[0127] S231: Identified as a control flow message, passed<IP,UDP端口> Find the control flow session.

[0128] S232: If the control flow session search fails, a new control flow UDP session is created;

[0129] S233: Send the control flow message to the dtls-nego node processing logic.

[0130] See also Figure 9 S400: Identify the message attributes of the target message and perform data interaction according to the message attributes, including the following steps:

[0131] S410: Parse the record layer protocol number related to the target message, and determine the message attributes according to the protocol number.

[0132] S420: Generate a UDP session according to the port number and message attributes of the target message, where the port number includes the source port and the destination port.

[0133] S430: Implement UDP session interaction using a communication interface corresponding to the message attributes.

[0134] Specifically, the message attributes are determined by parsing the record layer protocol number. When the record layer protocol number is the handshake protocol (protocol number 22), the alarm protocol (protocol number 21), or the password specification change protocol (protocol number 20), the target message is a control flow message; when the record layer protocol number is the data processing encapsulation protocol (protocol number 23), the target message is a data flow message.

[0135] Specifically, a UDP session refers to a control stream UDP session and a data stream UDP session. The port number defines the transmission channel for the target message. The source port represents the sender's port number, and the destination port represents the receiver's port number. Generating a UDP session ensures the correct and orderly transmission of the target message between the source and destination ports. Based on the different message attributes, the appropriate communication interface is selected for UDP session interaction, ensuring efficient and accurate transmission of the target message.

[0136] For example, the implementation process is as follows:

[0137] First, parse the protocol number of the DTLS record layer.

[0138] When the protocol numbers of the DTLS record layer are parsed as the handshake protocol (protocol number 22), the alarm protocol (protocol number 21), and the password specification change protocol (protocol number 20), the message is marked as a control flow message, the source port and destination port of the control flow message are recorded, and it is organized into a control flow UDP session, and the next hop processing node of the control flow message is pointed to the DTLS protocol negotiation module.

[0139] If the protocol number of the DTLS record layer is parsed as data processing encapsulation (protocol number 23), the message is marked as a data stream message, the source port and destination port of the data stream message are recorded, and the message is organized into a data stream UDP session. The next hop processing node of the control stream message is directed to the DTLS service data encapsulation module and the DTLS service data decapsulation module.

[0140] When the DTLS control stream session keepalive protocol (protocol number 24) and data stream session keepalive protocol (protocol number 25) are parsed, they are directly discarded without further processing.

[0141] In this example, if Figure 10As shown, the above implementation process is implemented by a DTLS protocol control identification module. The DTLS protocol negotiation module is used for negotiation of the DTLS protocol and processes service messages identified as control flow by the DTLS control identification module. The DTLS protocol negotiation module has the following upgrades on the basis of implementation of the traditional DTLS protocol server function: allocation of a set of UDP ports and increase of the message load organization of the message type of the handshake protocol "data flow port change". The data processing encapsulation protocol (protocol number 23) processing logic is removed, and this module does not process DTLS data flow messages.

[0142] The DTLS service data encapsulation module is used for encryption and encapsulation of DTLS data flow messages. The algorithm suite used for encryption and encapsulation is the algorithm suite negotiated by the DTLS protocol negotiation module, and the key used for encryption is also the key negotiated by the DTLS protocol negotiation module. The algorithm suite and the key information are recorded on the data flow session.

[0143] The DTLS service data encapsulation module is used for encryption and encapsulation of DTLS data flow messages. The algorithm suite used for encryption and encapsulation is the algorithm suite negotiated by the DTLS protocol negotiation module, and the key used for encryption is also the key negotiated by the DTLS protocol negotiation module. The algorithm suite and the key information are recorded on the data flow session.

[0144] The key management module manages the DTLS negotiated key information, which includes but is not limited to encryption algorithm and key, authentication algorithm and key, control flow sequence number, data flow sequence number, <IP, control flow destination port>, <IP, data flow destination port>, etc. The key management module is associated with the data flow and the control flow. The data flow and the control flow area are marked and distinguished by <IP, destination port>. If the SSLVPN server embodiment wants to support multi-tenancy sharing, the <IP, destination port> binary tuple uniquely determines a tenant. The service IPs of each tenant are different, so each tenant can share the same UDP data flow destination port, or can not share the same UDP data flow destination port. Different UDP data flow sessions are owned by different client terminals of the same tenant. The data flow and the control flow service ports cannot be the same.

[0145] In the present example, the control plane of the DTLS protocol has the characteristics of logical complexity, high timing requirement, large amount of asymmetric algorithm operation, and small amount of messages, and the DTLS protocol control plane message is completed by the DTLS protocol negotiation module. The forwarding plane of the DTLS protocol has the characteristics of simple logic, low timing requirement, only involving fast algorithms such as symmetric encryption algorithm and HASH, and a large amount of messages, and the DLTS forwarding plane message is completed by the DTLS service data encapsulation module and the DTLS service data decapsulation module. The VPP is responsible for processing the DTLS control flow, and also responsible for processing the data flow of the DTLS. The VPP processes the DTLS control flow and the data flow of the DTLS separately, and uses different UDP sessions. The implementation system adds the following processing modules on the basis of the VPP which already has interface management, DPDK integration, Ethernet layer processing, IP layer processing, routing module, and UDP layer processing: DTLS protocol control identification module, DTLS protocol negotiation module, DTLS service data encapsulation module, DTLS service data decapsulation module, key management module, and cipher suite module. The cipher suite module can be further divided into symmetric encryption module, HASH module, and asymmetric encryption module, and the cipher suite module is referenced by the DTLS service data encapsulation module, the DTLS service data decapsulation module, and the DTLS protocol negotiation module.

[0146] Please refer to Figure 11 When the message attribute is a data flow message, S430, the communication interface corresponding to the message attribute is used to realize the UDP session interaction, including the following steps:

[0147] S431A, receiving an encryption encapsulation instruction, generating a key ID.

[0148] S432A, determining a key object through the key ID, obtaining key specific information, and the key information includes the key ID and the key object.

[0149] S433A, using the key specific information to encrypt the UDP session, and sequentially encapsulating the UDP header and the IP header for the encrypted target message to generate an encrypted message.

[0150] S434A, transmitting the encrypted message using the data flow communication interface.

[0151] Specifically, the encryption encapsulation instruction includes necessary parameters required for encryption, a unique key ID is generated according to the encryption encapsulation instruction and session key information, the corresponding key object is located and determined through the key ID, the key object stores detailed specific information of the key, including the key ID, the key expiration date, the key type and the actual value of the key; after obtaining the key specific information, the UPD session content is encrypted using the key specific information, the UDP header and the IP header include the source address, the destination address and the data stream communication port of the data packet, so as to ensure that the data packet can be correctly transmitted in the network. The encrypted message is transmitted using the data stream communication interface, which ensures the transmission efficiency of the data stream, ensures the stable transmission of the encrypted message in the network, and ensures the security of the transmission through the encryption encapsulation.

[0152] For example, refer to Figure 12-14 , the implementation process is as follows:

[0153] S410: DPDK packet receiving, after the packet is routed or matched by a policy, the packet is sent to the dtls-encrypt node processing logic. The routing entry and the policy matching rule are configured by an administrator according to actual networking, the routing features or the policy features of the service data (i.e. the data to be DTLS encrypted and encapsulated) are extracted, and the service data to be DTLS encrypted and encapsulated is sent to the dtls-encrypt node processing logic.

[0154] S420: dtls-encrypt node encryption encapsulation.

[0155] S430: the encrypted and encapsulated packet is sent to the ip4-output / ip6-output node, and finally the encrypted packet is sent out through the interface.

[0156] S420: dtls-encrypt node encryption encapsulation. Specifically, the following steps are included:

[0157] S421: the dtls-encrypt node takes out the key object from the key management module through the key ID, and obtains the key specific information.

[0158] S422: the dtls-encrypt node uses the algorithm indicated in the key information to encrypt and encapsulate the packet with the key.

[0159] S423: the UDP header and the IP header are encapsulated for the encrypted packet. The UDP source port is the data stream service port.

[0160] In this example, after receiving a packet via the DPDK, the packet first undergoes the IP routing or policy matching process. This process is performed by the administrator based on preconfigured routing entries and policy matching rules, tailored to the network configuration. The administrator carefully analyzes the routing or policy characteristics of the service data, such as the source address, destination address, and port number, to ensure that the service data requiring DTLS encryption and encapsulation is accurately delivered to the dtls-encrypt node processing logic. This is a prerequisite for ensuring secure data transmission according to established policies. The dtls-encrypt node is responsible for encryption and encapsulation. Here, the packet is encrypted and encapsulated to ensure data confidentiality and integrity. The encrypted and encapsulated packet is then sent to the ip4-output / ip6-output node. Based on the packet's IP version (IPv4 or IPv6), the appropriate output node is selected for processing. Finally, the encrypted and encapsulated packet is sent through the network interface, completing the entire encrypted transmission process.

[0161] During S420: dtls-encrypt node encryption encapsulation, the dtls-encrypt node first retrieves the corresponding key object from the key management module using the key ID. The key object includes the key type, length, algorithm, and key value. After obtaining the key details, the dtls-encrypt node encrypts and encapsulates the message using the algorithm and key specified in the key details, ensuring that the data is protected from unauthorized third parties during transmission. After encryption is complete, the dtls-encrypt node encapsulates the encrypted message with a UDP header and an IP header. The UDP source port is set to the data stream communication port to ensure that the encrypted message is correctly received and processed.

[0162] See also Figure 15 When the message attribute is a data stream message, S430, using the communication interface corresponding to the message attribute to implement UDP session interaction, including the following steps:

[0163] S431B. Determine the IP address and UDP port of the encrypted message, where the encrypted message refers to the encrypted and encapsulated target message.

[0164] S432B. Determine the UDP session corresponding to the encrypted message based on the IP address and UDP port.

[0165] S433B. Obtain key information related to the UDP session.

[0166] S434B. Decapsulate the encrypted message using the key information to obtain message information.

[0167] Specifically, by determining the IP address and UDP port of the encrypted message, the network location information of the encrypted encapsulated target message can be identified and confirmed; according to the IP address and UDP port, the corresponding UDP session of the encrypted message can be located, the encrypted message can be decapsulated using the key information, and the encrypted message can be decrypted to obtain the data stream message information.

[0168] For example, see Figure 16-17 , the implementation process is as follows:

[0169] S310: DPDK receives the packet, performs IP routing, and sends the message to the udp4-input / udp6-input node processing logic.

[0170] S320: The udp4-input / udp6-input node recognizes that the UDP destination port is the port registered for DTLS and sends the message to the DTLS conversion identification node processing logic.

[0171] S330: The DTLS conversion identification node parses the protocol number of the DTLS record layer in the message, and classifies the message according to the above method to identify the data flow message.

[0172] S340: The dtls-decrypt node decrypts and decapsulates the data stream.

[0173] S350: Send the decrypted message to the ip4-output / ip6_output node, and finally send the decrypted message out through the interface.

[0174] In this example, after receiving a packet, the DPDK forwards the packet to the corresponding processing logic node based on the IP routing table. If the target protocol is IPv4 or IPv6, the packet is sent to the udp4-input or udp6-input node, respectively, for further processing. These nodes are the entry points for packets into the UDP protocol stack and are responsible for processing all UDP protocol packets. Upon receiving a packet, the udp4-input or udp6-input node first checks the UDP destination port number. If the UDP destination port number matches the port registered for the DTLS (Datagram Transport Layer Security) protocol in the system, the packet is part of a DTLS session. The node then forwards the packet to the DTLS translation identification node for further processing. Upon receiving the packet, the DTLS translation identification node parses the DTLS record layer content, specifically the protocol number field. Based on the protocol number, the node can classify the packet. For identified data stream packets, the dtls-decrypt node decrypts and decapsulates them using the previously negotiated key and algorithm. The decryption process restores the original application layer data, while the decapsulation process removes the DTLS header and any possible padding. The decrypted packet is then sent to the ip4-output or ip6-output node, which represents the exit point from the IP protocol stack. Here, the packet undergoes the necessary routing and encapsulation operations before being sent through the appropriate network interface. During this transmission process, the data packet adheres to the IP protocol specifications to ensure that it reaches its destination accurately.

[0175] For example, Figure 18 As shown, S340: the dtls-decrypt node decrypts and decapsulates the data stream. The steps include:

[0176] S341: The dtls-decrypt node retrieves the key object from the key management module using the key ID to obtain specific key information.

[0177] S342: The dtls-decrypt node decrypts and decapsulates the message using the algorithm and key specified in the key information.

[0178] In this example, the dtls-decrypt node first identifies the key ID in the packet header. This key ID is a unique identifier used to retrieve the corresponding key object from the key management module. The node sends a query request to the key management module, attaching the key ID as a query parameter. Upon receiving the request, the key management module searches for and returns the key object that matches the key ID. This key object contains key details, such as key type, length, and the specific decryption algorithm.

[0179] After obtaining the key information, the dtls-decrypt node uses this information to guide the decryption process. It decrypts the message according to the algorithm and key specified in the key information. During the decryption process, the node removes the header and trailer information added by the DTLS protocol to recover the original application layer data. The node also verifies the integrity and authenticity of the message to ensure that the data has not been tampered with or damaged during transmission. After decryption and decapsulation are complete, the node passes the recovered data to the next processing node for further processing or transmission.

[0180] See also Figure 19 S432B: Determine the UDP session corresponding to the encrypted message based on the IP address and UDP port, including the following steps:

[0181] S432B.1. Find data stream sessions using IP addresses and UDP ports.

[0182] S432B.2. If the search is successful, determine the data stream session as a UDP session.

[0183] S432B.3. If the search fails, create a new data stream session as a UDP session.

[0184] S432B.4. Determine the key ID based on the IP address and UDP port, and bind the key ID to the UDP session.

[0185] Specifically, the IP address includes the source IP address and the destination IP address, and the UDP port includes the source UDP port and the destination UDP port. By using the source IP address and UDP port in the message, it is found whether there is a data stream session matching the encrypted message.

[0186] If the search is successful, it indicates that the encrypted message belongs to an established UDP connection and can be processed according to the defined rules. If the search fails, it indicates that there is no data stream session matching the encrypted message. A new data stream session is created and marked as a UDP session. By binding the key ID to the UDP session, it is ensured that each UDP session uses the correct key for encryption and decryption operations, effectively preventing data from being stolen or tampered with during transmission. It also avoids key confusion or incorrect use between multiple UDP sessions. In subsequent transmissions, there is no need for secondary key negotiation and exchange, reducing communication latency and improving communication efficiency.

[0187] For example, see Figure 20 , the implementation process is as follows:

[0188] S331: Identify it as a data stream message, pass<IP,UDP端口> Find the data streaming session.

[0189] S332: If the data stream session search fails, a new data stream UDP session is created.

[0190] S333: Pass<IP,UDP端口> Search for key information in the key management module and bind the key ID to the session.

[0191] S334: Obtain the key ID from the session.

[0192] S335: Send the data stream message to the dtls-decrypt node processing logic.

[0193] Example 2

[0194] See also Figure 21 , the embodiment of the present application further discloses a message processing device, comprising:

[0195] The response module 400 is used to respond to the handshake request information sent by the client, establish a communication connection, and generate communication information related to the handshake request information. The communication information includes a new message type. The new message type is used to adjust the data flow communication port. The data flow communication port refers to the destination port for transmitting data flow between the client and the server. The response module 400 can perform the above Figure 1 S100 in the embodiment shown, Figure 2 In the embodiment shown, S110, Figure 3 In the embodiment shown, S110, Figure 6 The embodiment shown, Figure 7 The embodiments shown will not be described in detail here.

[0196] The allocation module 500 is used to allocate a communication interface according to the communication information. The communication interface refers to a data flow communication port for data flow transmission. The allocation module 500 can perform the above Figure 1 In the embodiment shown, S200, Figure 2 S120 in the embodiment shown, Figure 3 S120 in the illustrated embodiment will not be described in detail here.

[0197] The sending module 600 is used to send a port change agreement to the client, and the port change agreement carries information related to the communication interface. The sending module 600 can execute the above Figure 1 S300 in the embodiment shown, Figure 2 S130 in the embodiment shown, Figure 3 S130 in the illustrated embodiment will not be described in detail here.

[0198] The interactive module 700 is used to identify the message attributes of the target message and perform data interaction according to the message attributes. The message attributes include data flow messages and control flow messages. The sequence numbers of data flow messages and control flow messages are calculated independently. The interactive module 700 can execute the above Figure 1 S400 in the embodiment shown, Figure 2 S140 in the embodiment shown, Figure 3 S140 in the embodiment shown, Figure 13 The embodiment shown, Figure 14 The embodiment shown, Figures 17-20 The embodiments shown will not be described in detail here.

[0199] The receiving module 800 is used to periodically receive the control flow keep-alive message or data flow keep-alive message sent by the client. The control flow keep-alive message and the data flow keep-alive message are generated by the control flow session keep-alive protocol and the data flow session keep-alive protocol respectively. The control flow keep-alive message uses the same source port and destination port as the control flow message, and the data flow keep-alive message uses the same source port and destination port as the data flow message. The receiving module 800 performs the above Figure 1 S500 in the embodiment shown, Figure 2 S150 in the embodiment shown, Figure 3 S150 in the illustrated embodiment will not be described in detail here.

[0200] The discard module 900 is used to discard the control flow keep-alive message or the data flow keep-alive message. The receiving module 800 executes the above Figure 1 S600 in the embodiment shown, Figure 2 S160 in the embodiment shown, Figure 3 S160 in the illustrated embodiment will not be described in detail here.

[0201] Example 3

[0202] See also Figure 22 , an embodiment of the present application further provides an electronic device, including:

[0203] processor.

[0204] A memory for storing processor-executable instructions.

[0205] The processor is configured to execute instructions to implement any message processing method.

[0206] In this embodiment, the computer device includes a processor, a memory, and a network interface connected via a system bus.

[0207] The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The database of the computer device is used to store data samples. The network interface of the computer device is used to communicate with an external terminal via a network connection. When executed by the processor, the computer program implements any one of the message processing methods.

[0208] Those skilled in the art will understand that Figure 22 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0209] Example 4

[0210] An embodiment of the present application also provides a computer-readable storage medium. When the instructions in the computer-readable storage medium are executed by the processor of the terminal, the terminal is enabled to execute any message processing method.

[0211] The computer-readable storage medium mentioned above may be implemented by any type of volatile or non-volatile memory device, or a combination thereof, such as static random access memory, electrically erasable programmable read-only memory, erasable programmable read-only memory, programmable read-only memory, read-only memory, magnetic storage, flash memory, magnetic disk, or optical disk. The computer-readable storage medium may be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0212] Optionally, a readable storage medium is coupled to a processor so that the processor can read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be an integral part of the processor. The processor and the readable storage medium can be located in an application specific integrated circuit (ASIC). Of course, the processor and the readable storage medium can also exist in the device as discrete components.

[0213] Example 5

[0214] An embodiment of the present application also provides a computer program product, which includes a computer program. When the computer program is executed by a processor, it implements any message processing method.

[0215] Those skilled in the art will appreciate that embodiments of the present application can be devised for a variety of applications. It is intended that the present application be limited only by the scope of the appended claims, and it is intended that various modifications and alterations made by those skilled in the art be considered as within the scope of the present application. The embodiments of the present application will be described with reference to the attached drawings, wherein:

[0216] The present application is described in reference to the drawings using a flowchart and / or a block diagram of the method, apparatus (system) and computer program product according to embodiments of the application. It will be understood that each block of the flowchart and / or block diagram, and combinations of blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, embedded processing device or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart and / or block diagram block or blocks. Figure 1 one or more functions specified in the flowchart and / or block diagram block or blocks. Figure 1 one or more functions specified in the flowchart and / or block diagram block or blocks.

[0217] These computer program instructions can also be stored in a computer- readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the function specified in the flowchart and / or block diagram block or blocks. Figure 1 one or more functions specified in the flowchart and / or block diagram block or blocks. Figure 1 one or more functions specified in the flowchart and / or block diagram block or blocks.

[0218] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart and / or block diagram block or blocks. Figure 1 one or more functions specified in the flowchart and / or block diagram block or blocks. Figure 1 one or more functions specified in the flowchart and / or block diagram block or blocks.

[0219] While the preferred embodiments of the application have been described, additional variations and modifications can be made to the embodiments by those skilled in the art once they learn of the basic inventive concepts. Therefore, the appended claims are intended to cover all such modifications and variations as fall within the scope of the present application.

[0220] Obviously, those skilled in the art may make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if such changes and modifications fall within the scope of the claims and their equivalents, the present invention is intended to include such changes and modifications.

Claims

1. A message processing method, characterized in that: The steps include: In response to a handshake request message sent by the client, establishing a communication connection, and generating communication information related to the handshake request message, the communication information including a new message type, the new message type being used to adjust a data flow communication port to ensure that control flow messages and data flow messages are transmitted using different ports, the data flow communication port being a destination port for transmitting data flows between the client and the server; Allocating a communication interface according to the communication information, wherein the communication interface refers to a data stream communication port for data stream transmission; Sending a port change agreement to the client, wherein the port change agreement carries information related to the communication interface; Identify the message attributes of the target message and perform data interaction according to the message attributes, wherein the message attributes include a data flow message and a control flow message, and the sequence number of the data flow message and the sequence number of the control flow message are calculated independently.

2. The method according to claim 1, characterized in that After data interaction with the client, the following steps are also included: Regularly receive control flow keep-alive messages or data flow keep-alive messages sent by the client, where the control flow keep-alive messages and the data flow keep-alive messages are generated by the control flow session keep-alive protocol and the data flow session keep-alive protocol, respectively. The control flow keep-alive message uses the same source port and destination port as the control flow message, and the data flow keep-alive message uses the same source port and destination port as the data flow message.

3. The method according to claim 1 or 2, wherein: Identify the target message's attributes and perform data exchange based on the message attributes. This includes the following steps: Parse the record layer protocol number associated with the target message and determine the message attributes based on the protocol number; Generate a UDP session based on the port number and message attributes of the target message, where the port number includes the source port and the destination port; The UDP session interaction is implemented using a communication interface corresponding to the message attributes.

4. The method according to claim 2, wherein After periodically receiving a control flow keep-alive message or a data flow keep-alive message from a client, the following steps are included: The control flow keep-alive message or the data flow keep-alive message is discarded.

5. The method according to claim 1, 2 or 4, characterized in that Responding to a handshake request message sent by a client, establishing a communication connection, and generating communication information related to the handshake request message, including the following steps: Receive the handshake request information sent by the client, and identify the IP address, UDP destination port and message attributes of the handshake request information; When the message attribute is a control flow message, determining a negotiation response session according to the IP address and the UDP destination port; Perform key negotiation according to the negotiation response session and generate a negotiation response message; Encapsulate the UDP header and IP header for the negotiation response message, and send it to the client for interaction, generating session key information, which includes encryption algorithm and key information, authentication algorithm and key information, control flow sequence number, data flow sequence number, IP address, control flow destination port, and data flow destination port; Associate the negotiation response session ID information and session key information.

6. The method according to claim 5, wherein When the message attribute is a control flow message, determining a negotiation response session according to the IP address and the UDP destination port includes the following steps: Find the control flow session associated with the handshake request information by IP address and UDP destination port; If the search fails, a new control flow UDP session is created as the negotiation response session; If the search is successful, the control flow session is used as the negotiation response session.

7. The method according to claim 3, wherein When the message attribute is a data stream message, using a communication interface corresponding to the message attribute to implement UDP session interaction includes the following steps: Receive encryption and encapsulation instructions and generate key ID; Determine the key object through the key ID and obtain key specific information, the key specific information includes the key ID and the key object; Use the key information to encrypt the UDP session, and then encapsulate the encrypted target message with the UDP header and IP header to generate an encrypted message. Use the data stream communication interface to transmit encrypted messages.

8. The method according to claim 3, wherein When the message attribute is a data stream message, using a communication interface corresponding to the message attribute to implement UDP session interaction includes the following steps: Determine the IP address and UDP port of the encrypted message, wherein the encrypted message refers to the encrypted and encapsulated target message; Determine the UDP session corresponding to the encrypted message based on the IP address and UDP port; Obtain key information related to the UDP session; Use the key information to decapsulate the encrypted message and obtain the message information.

9. The method according to claim 8, wherein Determining a UDP session corresponding to the encrypted message based on the IP address and the UDP port includes the following steps: Find data streaming sessions using IP addresses and UDP ports; If the search is successful, the data stream session is determined to be a UDP session; If the search fails, a new data stream session is created as a UDP session; The key ID is determined by the IP address and UDP port, and is bound to the UDP session.

10. A message processing device, characterized in that: include: a response module, configured to respond to a handshake request message sent by a client, establish a communication connection, and generate communication information related to the handshake request message, wherein the communication information includes a new message type, and the new message type is used to adjust a data flow communication port to ensure that control flow messages and data flow messages are transmitted using different ports, wherein the data flow communication port refers to a destination port for transmitting data flows between a client and a server; an allocation module, configured to allocate a communication interface according to the communication information, wherein the communication interface refers to a data stream communication port for data stream transmission; A change module, configured to send a port change agreement to the client, wherein the port change agreement carries information related to the communication interface; The interaction module is used to identify the message attributes of the target message and perform data interaction according to the message attributes, wherein the message attributes include data flow message and control flow message, and the sequence number of the data flow message and the sequence number of the control flow message are calculated independently.

Images