Message processing method and message processing device

Abstract

The invention discloses a message processing method and a message processing device, and relates to the technical field of communication. The communication connection is established through the handshake request information, the new message type used for adjusting the data stream communication port is confirmed, and the communication interface used for data stream transmission is allocated according to the new message type, so that the data stream message and the control stream message are transmitted by using different ports, and the message transmission path and the reasonable allocation of resources are optimized. The technical problems that in the prior art, the control flow message occupies CPU resources, the forwarding efficiency of the data flow message is affected, and the control flow message is 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 the security of network communications. Both are located between the TCP / IP protocol and the application layer. They are mainly 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 better security and the ability to avoid vulnerabilities in old protocols. The DTLS protocol (Datagram Transport Layer Security), as a derivative version of the TLS protocol, is designed specifically for UDP to overcome the application limitations of TLS in the UDP environment. 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 are mainly concerned with providing security and encryption functions at the transport layer, and are not designed to sink business data processing to the data plane or lower layers for accelerated processing. When network resources are tight, it is difficult for rate-limiting devices to effectively distinguish between control messages and business forwarding messages of the SSL / TLS / DTLS protocols, resulting in control messages being overwhelmed by a large number of business messages and unable to effectively reach the other end. In addition, the DTLS protocol does not separate the forwarding plane from the control plane, which causes the CPU to occupy resources when processing control messages, thereby affecting 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, thereby solving 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 effect 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 the handshake request information sent by the client, a communication connection is established, and communication information related to the handshake request information is generated, wherein the communication information includes a new message type, and the new message type is used to adjust the data stream communication port, and the data stream communication port refers to the destination port for transmitting the 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, 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, wherein the communication information includes a new message type, and the new message type is used to adjust the data stream communication port, and the data stream communication port refers to the destination port for transmitting the data stream between the client and the 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, used for sending 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 messages and control flow messages, 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, allocating a communication interface for data flow transmission according to the new message type, so that data flow messages and control flow messages use different ports for transmission, optimizing the message transmission path and the reasonable allocation of resources. The technical problems in the prior art that the control flow message occupies CPU resources and affects the forwarding efficiency of the data flow message, and the control flow message is 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. 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 by 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 for 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 flow chart of a method for searching a control flow session provided in at least one embodiment of the present application;

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

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

[0026] Fig.11 A flowchart of a method for encryption packaging provided by at least one embodiment of the present application;

[0027] Fig.12 An example diagram of encryption packaging provided for at least one embodiment of the present application;

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

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

[0030] Fig.15 A flowchart of a decapsulation method provided by at least one embodiment of the present application;

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

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

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

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

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

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

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

[0038] The embodiment of the present application provides a message processing method, establishes a communication connection through handshake request information, confirms a new message type for adjusting the data flow communication port, allocates a communication interface for data flow transmission according to the new message type, and enables data flow messages and control flow messages to use different ports for transmission, thereby optimizing the message transmission path and the reasonable allocation of resources. 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 are solved, and the technical effects of high transmission efficiency and low packet loss rate are achieved.

[0039] The DTLS protocol is developed from the TLS protocol. The typical difference between the DTLS protocol and the TLS protocol 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. The DTLS protocol inherits most of the features of the TLS protocol, including the fact that the DTLS protocol and the TLS protocol are both protocols with inseparable forwarding and control. The inseparable forwarding and control of the DTLS protocol is reflected in the fact that the forwarding plane and the control plane messages have the same UDP five-tuple information (source address, source port, destination address, destination port, transport layer protocol), share the same session, share the TCP / UDP protocol stack, and share the same processing subject program. The DTLS protocol is similar to the TLS protocol and can be divided into two layers, namely the bottom layer protocol and the upper layer protocol. The bottom layer protocol is the record layer protocol, and the upper layer protocol can be further divided into the handshake protocol, the alarm protocol, the password specification change protocol, and the application data processing. The main capability of the DTLS handshake protocol is the DTLS protocol key negotiation. After the interaction of the handshake protocol, a set of session key information is finally negotiated for DTLS. The session key information includes information such as session identifier, compression algorithm, encryption algorithm and encryption mode, authentication algorithm, and session key. The DTLS warning protocol is used to convey warning notifications to the peer during the handshake negotiation process. The function of the DTLS cipher specification change protocol is to inform the peer to use the newly negotiated cipher for encrypted communication when the handshake negotiation is completed. The DTLS application data processing is to encapsulate and decapsulate the services carried by DTLS based on the keys negotiated by the handshake protocol.

[0040] In terms of protocol nature, messages exchanged by the handshake protocol (protocol number 22), the alarm protocol (protocol number 21), and the password specification change protocol (protocol number 20) can all be classified as control messages. Messages in the application data processing encapsulation (protocol number 23) can be classified as forwarding messages.

[0041] The DTLS protocol mixes the above-mentioned handshake protocol, alarm protocol, password specification change protocol, and application data processing together, and the application-state control plane program handles them all together. This obviously greatly reduces the efficiency of DTLS in forwarding business data. Not only that, the control messages of the DTLS protocol are mixed with the business forwarding messages, and the control messages and business forwarding messages have the same IP layer network characteristics and transport layer network characteristics. When the network's carrying capacity is limited, the speed-limiting equipment in the network cannot effectively distinguish the control messages of the DTLS protocol from the business messages, and the control messages and business messages of the DTLS protocol are indiscriminately limited and lost. After being overwhelmed by the business messages, the control messages cannot effectively reach the other end, causing many unnecessary link interruptions, which greatly affects the stability of the DTLS connection.

[0042] Traditional DTLS protocol control messages and service forwarding messages have the same network characteristics and flow control characteristics and belong to the same group of sessions. Traditional DTLS protocol control messages are mixed together for processing, and SSLVPN implementation equipment cannot sink traditional DTLS protocol service data to the high-speed processing components on the data plane. Traditional DTLS protocol not only has the problem of dragging down the efficiency of service data forwarding, but also has the problem of poor connection stability caused by the indiscriminate discarding of DTLS protocol service messages and control messages by the speed-limiting equipment in the network.

[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 transfer and control separation.

[0045] Based on this application, not only can the SSLVPN implementation device greatly improve the DTLS service message processing capability, but it can also provide the speed-limiting device 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 further 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 the security of network communications and is a general term for a series of protocol technologies.

[0048] TLS (Transport Layer Security): A type of VPN that works at the transport layer and can provide data confidentiality, integrity, and identity verification for both parties. The latest TLS protocol version is TLSv1.3.

[0049] DTLS (Datagram Transport Layer Security): A transport layer security protocol version 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 has 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 in conjunction with the accompanying drawings and specific implementation methods.

[0054] Embodiment 1

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

[0056] S100, responding to the handshake request information sent by the client, establishing a communication connection, and generating communication information related to the handshake request information, wherein the communication information includes a new message type, and the new message type is used to adjust the data stream communication port, which refers to the destination port for transmitting the data stream between the client and the server.

[0057] Specifically, the handshake request message refers to the first message in the handshake process, which is used to indicate the intention of the 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 a session key, an encryption communication algorithm, and a new message type. The session key and the encryption communication algorithm are used for data encryption, and the new message type is used to indicate the destination port for transmitting data streams between the client and the server.

[0058] Exemplarily, the handshake request information refers to a synchronization message sent by the client to request to establish a connection. After receiving the message, the server sends a synchronization confirmation message to indicate that it is ready to establish a connection. Finally, the client sends a confirmation connection message to establish a communication connection. A new message type is added to the handshake protocol. By adding a new message type and defining the number of the new message type as a value greater than 20, the new message type is effectively distinguished from the existing message types in the handshake protocol, and the function of adjusting the data flow communication port is realized.

[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 according to the new message type in the communication information ensures that control flow messages and data flow messages are transmitted using different ports, which can reduce retransmission and processing delays caused by message disorder or loss, and reduce overall communication overhead and delay; 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 the case of tight network resources, it can prevent the control flow message from being overwhelmed by a large number of business messages and unable to effectively reach the other end.

[0061] S300: Send a port change protocol to the client, where the port change protocol 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 data flow messages and control flow messages are transmitted using different ports, thereby preventing the control flow messages from occupying CPU resources and affecting the forwarding efficiency of data flow messages, and preventing the control flow messages from being easily lost due to resource competition.

[0063] S400, identifying the message attributes of the target message, and performing data exchange according to the message attributes, wherein the message attributes include data flow messages and control flow messages, and the sequence number of the data flow message and the sequence number of the control flow message are calculated independently.

[0064] Specifically, the target message refers to the message to be transmitted, including data flow messages, data flow keep-alive messages, control flow messages, and control flow keep-alive messages. The sequence number is used to identify the order of the message. The sequence numbers of the data flow messages and the control flow messages are calculated independently to ensure that the data flow messages and the control flow messages can be processed independently, thereby improving the security and reliability of message processing.

[0065] Exemplarily, the message processing method provided in this embodiment is implemented by an SSLVPN server based on 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 number of the messages belonging to the control flow, such as the handshake protocol (protocol number 22), alarm protocol (protocol number 21), and cryptographic specification change protocol (protocol number 20) of the DTLS protocol, and calculate the sequence number of the messages belonging to the data flow of the application data processing encapsulation protocol (protocol number 23) separately. The data flow messages and control flow messages are not mixed together to calculate the sequence number.

[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., business 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 from 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, but is applicable to the current DTLSv1.0, DTLSv1.2, and DTLSv1.3, as well as future higher versions of DTLS.

[0069] Exemplarily, the message processing method provided in this embodiment is implemented based on an SSLVPN server of a DTLS protocol with separation of forwarding and control. Figure 2-Figure 3 The specific steps for message processing through 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. In the service forwarding data sent from the client to the server, the UDP destination port is the port carried in the S130 "Data Stream Port Change" protocol payload. The column 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 the DTLS server complete the DTLS protocol 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. The service forwarding data refers to the data stream message. After the communication connection is established, the DTLS server sends the data stream port change protocol carrying the data stream service port to the DTLS client to exchange service data, so that when the client sends service forwarding data to the server, the UDP destination port is the same as the port carried in the data stream port change protocol payload. The SSLVPN implementation device greatly improves the DTLS service message processing capability, and can also provide the speed limiting device in the network with different traffic characteristics of the DTLS protocol control message and the service forwarding message, and assign different service levels to the DTLS control message and the service forwarding message, so as to give priority to the passage of the DTLS protocol control message, and then ensure 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] The communication connection is established through the handshake request information, the new message type used to adjust the data flow communication port is confirmed, and the communication interface for data flow transmission is allocated according to the new message type, so that the data flow message and the control flow message are transmitted using different ports, which optimizes the message transmission path and the reasonable allocation of resources. The technical problems in the prior art that the control flow message occupies CPU resources and affects the forwarding efficiency of the data flow message, and the control flow message is prone to packet loss due to resource competition are solved, and the technical effect of high transmission efficiency and low packet loss rate is achieved.

[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-term lack of 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 encrypted and compressed at the record layer, but are organized in plain text. 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, respectively, so that the control flow keep-alive message and the data flow keep-alive message respectively maintain the same port information as the control flow message and the data flow message during transmission, ensuring correct routing and identification, and ensuring consistency with normal data transmission.

[0081] For example, Figure 2-Figure 3 As shown, periodically receiving a control flow keepalive message or a data flow keepalive message sent by a client includes the following steps: S150: the client periodically sends a control flow keepalive message to the server, and the destination port of the message is the same as the control flow service port of the server, or, S160: the client periodically sends a data flow keepalive message to the server, and the destination port of the message is the same as the data flow service port of the server.

[0082] Among them, S150 and S160 are periodic tasks, and their periodic cycles can be changed through configuration. The default periodic cycle is once every 20 seconds.

[0083] The source code corresponding to the definition of the control flow session package or protocol is as follows:

[0084]

[0085] The source code corresponding to defining the data stream session package or protocol is as follows:

[0086]

[0087] See also Figure 1 After S500, periodically receiving a control flow keep-alive message or a data flow keep-alive message sent by a client, the following steps are included:

[0088] S600: discard the control flow keep-alive message or the data flow keep-alive message.

[0089] 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.

[0090] Exemplarily, 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 is able to sense and reset the session timer to ensure that even if no response is given, the NAT session will not be interrupted due to a long period of no data transmission.

[0091] See also Figure 4 S100, responding to the handshake request information sent by the client, establishing a communication connection, and generating communication information related to the handshake request information, including the following steps:

[0092] 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.

[0093] 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.

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

[0095] S140. Encapsulate the UDP header and IP header for the negotiation response message, and send it to the client for interaction, generate 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.

[0096] S150: Associate the ID information and session key information of the negotiation response session.

[0097] 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 of the initiator of the request, the UDP destination port, and the message attributes.

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

[0099] Then, key negotiation is initiated based on the generated negotiation response session. During this process, multiple information exchanges are performed based on the preset protocol or algorithm, and finally a negotiation response message is generated. The negotiation response message includes the key negotiation result recognized by both parties and is the key to establishing secure communication.

[0100] 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 is completed, the negotiation response message is sent to the client for interaction, and the key session information constitutes the security basis of the session.

[0101] Finally, by associating the ID information and session key information of the negotiation response session, it is convenient to reuse the negotiation response session parameters in subsequent communications and avoid re-negotiation of the key.

[0102] For example, see Figure 5-Figure 6 , the implementation process is as follows:

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

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

[0105] S230: 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 control flow message.

[0106] S240: The dtls-nego node is responsible for key negotiation, organizing negotiation response messages, and encapsulating UDP headers and IP headers for negotiation response messages.

[0107] S250: Send the negotiation response message to the ip4-output / ip6-output node, and finally send the negotiation response message out through the interface.

[0108] 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 with the corresponding key information.

[0109] S270: Register the data stream port into the udp4-input / udp6-input node so that subsequent data stream messages can be sent to the DTLS control and diversion module.

[0110] In this example, DPDK (Data Plane Development Kit) is first responsible for receiving data packets. After these data packets are processed by IP routing, they are correctly routed to udp4-input (for IPv4) or udp6-input (for IPv6) nodes for subsequent processing logic according to the destination address. Using DPDK's packet processing capabilities ensures that data packets can be forwarded to the corresponding processing nodes quickly and accurately.

[0111] After receiving the data packet, the udp4-input or udp6-input node will check the UDP destination port. If the port is a port registered by the DTLS (Datagram Transport Layer Security) protocol, it means that the data packet is used for DTLS secure communication. At this point, the data packet will be further forwarded to the DTLS conversion identification node for subsequent security processing.

[0112] In the DTLS conversion identification node, the protocol number is identified by parsing the DTLS record layer in the data packet. The data packet is classified according to the protocol number, and the classification result includes data flow message and control flow message.

[0113] The dtls-nego node is used to negotiate security parameters in the DTLS protocol. When the data packet is a control flow message, the dtls-nego node will be responsible for key negotiation. The node will organize the negotiation response message and ensure that it contains the necessary negotiation information. Subsequently, the UDP header and IP header are encapsulated for the negotiation response message to ensure that the data packet can be correctly transmitted through the network.

[0114] After encapsulation, the negotiation response message will be 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 sending process.

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

[0116] Finally, to support subsequent data stream communication, the system will register the data stream port to the udp4-input or udp6-input node. In this way, when data stream messages are received, these messages can be correctly identified and sent to the DTLS control and diversion module for processing. This step ensures that data stream communication can be carried out safely and efficiently.

[0117] Please refer to Figure 7 , when the message attribute is a control flow message, S120 determines the negotiation response session according to the IP address and UDP destination port, including the following steps:

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

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

[0120] S123. If the search succeeds, use the control flow session as the negotiation response session.

[0121] In this embodiment, first, the IP address and UDP destination port are used as retrieval conditions to search for the 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 the negotiation response session; if the search succeeds, it means that the handshake request information is part of the established session. At this time, the found control flow session is directly used as the negotiation response session to continue processing the handshake request, ensuring the continuity of communication while avoiding unnecessary resource overhead.

[0122] Exemplarily, please refer to Figure 8 , the implementation process is as follows:

[0123] S231: Identify it as a control flow message and search for the control flow session through <IP, UDP port>.

[0124] S232: If the control flow session search fails, create a new control flow UDP session;

[0125] S233: Send the control flow message into the processing logic of the dtls-nego node.

[0126] Please refer to Fig. 9 , S400. Identify the message attribute of the target message and perform data interaction according to the message attribute, including the following steps:

[0127] S410. Analyze the record layer protocol number related to the target message and determine the message attribute according to the protocol number.

[0128] S420. Generate a UDP session according to the port number and message attribute of the target message, and the port number includes the source port and the destination port.

[0129] S430. Implement UDP session interaction using the communication interface corresponding to the message attribute.

[0130] 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.

[0131] Specifically, UDP sessions refer to control stream UDP sessions and data stream UDP sessions. The port number defines the transmission channel of the target message. The source port indicates the port number of the sender, and the destination port indicates the port number of the receiver. By generating a UDP session, it is possible to ensure that the target message is correctly and orderly transmitted between the source port and the destination port; according to the different message attributes, the appropriate communication interface is selected for UDP session interaction, which ensures the efficiency and accuracy of the target message transmission.

[0132] Exemplarily, the implementation process is as follows:

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

[0134] 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.

[0135] When 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 it is organized into a data stream UDP session. The next hop processing node of the control stream message is pointed to the DTLS service data encapsulation module and the DTLS service data decapsulation module.

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

[0137] In this example, if Fig.10As shown, the above implementation process is implemented through the DTLS protocol transfer and control identification module. The DTLS protocol negotiation module is used for the negotiation of the DTLS protocol and processes the service packets identified as control flows by the DTLS transfer and control identification module. The DTLS protocol negotiation module has the following upgrades on the basis of implementing the functions of the traditional DTLS protocol server: adding a set of UDP port allocations and adding the message payload organization of the handshake protocol "data stream port change" message type. The processing logic of the data processing encapsulation protocol (protocol number 23) is removed, and this module does not process DTLS data stream packets.

[0138] The DTLS service data encapsulation module is used to encrypt and encapsulate the DTLS data stream packets. 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 key information are recorded on the data stream session.

[0139] The DTLS service data decapsulation module is used to decrypt and decapsulate the DTLS data stream packets. The algorithm suite used by the DTLS service data decapsulation module for decryption and decapsulation is the algorithm suite negotiated by the DTLS protocol negotiation module, and the key used for decryption is also the key negotiated by the DTLS protocol negotiation module. Similarly, the algorithm suite and key information are recorded on the data stream session.

[0140] The key management module manages the key information negotiated by DTLS. The key information includes but is not limited to encryption algorithms and keys, authentication algorithms and keys, control flow sequence numbers, data flow sequence numbers, <IP, control flow destination port>, <IP, data flow destination port>, etc. The key management module is also associated with the data flow and the control flow. The data flow and the control flow areas are marked and distinguished by <IP, destination port>. If the SSLVPN server implementation example is intended to support multi-tenant sharing, the <IP, destination port> binary group uniquely determines a tenant. Since the service IPs of each tenant are different, each tenant can share the same UDP data stream destination port or not share a UDP data stream destination port. Different clients of the same tenant have different UDP data stream sessions. The service ports of the data flow and the control flow cannot be the same.

[0141] In this example, since the control plane of the DTLS protocol has the characteristics of complex logic, high timing requirements, large amount of asymmetric algorithm calculation involved, and small number of messages, the DTLS protocol control plane message is completed by the DTLS protocol negotiation module. Since the forwarding plane of the DTLS protocol has the characteristics of simple logic, low timing requirements, only involving symmetric encryption algorithms and HASH and other algorithms with fast calculation rate, and huge number of messages, the DTLS forwarding plane message is completed by the DTLS service data encapsulation module and the DTLS service data decapsulation module. VPP is responsible for processing the DTLS control flow and also responsible for processing the DTLS data flow. VPP processes the DTLS control flow and the DTLS data flow separately and uses different UDP sessions. Based on the interface management, DPDK integration, Ethernet layer processing, IP layer processing, routing module, and UDP layer processing already possessed by VPP, the implementation system adds the following processing modules: 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. The cipher suite module is referenced by DTLS service data encapsulation module, DTLS service data decapsulation module and DTLS protocol negotiation module.

[0142] See also Fig.11 When the message attribute is a data stream message, S430, using a communication interface corresponding to the message attribute to implement UDP session interaction, including the following steps:

[0143] S431A, receive the encryption encapsulation instruction and generate a key ID.

[0144] S432A. Determine the key object through the key ID and obtain key specific information. The key information includes the key ID and the key object.

[0145] S433A. Use the key specific information to encrypt the UDP session, and encapsulate the encrypted target message in sequence with a UDP header and an IP header to generate an encrypted message.

[0146] S434A, use the data stream communication interface to transmit encrypted messages.

[0147] Specifically, the encryption encapsulation instruction includes the necessary parameters for encryption. According to the encryption encapsulation instruction and the session key information, a unique key ID is generated. Through the key ID, the corresponding key object is located and determined. The key object stores detailed information of the key, including the key ID, the key expiration period, the key type and the actual value of the key. After obtaining the key specific information, the key specific information is used to encrypt the UDP session content. The UDP header and IP header include the source address, destination address and data stream communication port of the data packet to ensure that the data packet can be correctly transmitted in the network. The use of the data stream communication interface to transmit encrypted messages ensures the transmission efficiency of the data stream and the stable transmission of encrypted messages in the network. Through encryption encapsulation, the security of transmission is also guaranteed.

[0148] For example, see Figure 12-14 , the implementation process is as follows:

[0149] S410: DPDK receives the packet, and the message is sent to the dtls-encrypt node processing logic after IP routing or policy matching. The routing entries and policy matching rules are configured by the administrator according to the actual network configuration, and the routing characteristics or policy characteristics of the business data (that is, the data to be encrypted and encapsulated by DTLS) are extracted, and the business data to be encrypted and encapsulated by DTLS is sent to the dtls-encrypt node processing logic.

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

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

[0152] S420: dtls-encrypt node encryption encapsulation. Specifically includes the following steps:

[0153] S421: The dtls-encrypt node retrieves the key object from the key management module through the key ID to obtain specific key information.

[0154] S422: The dtls-encrypt node encrypts and encapsulates the message using the algorithm and key specified in the key information.

[0155] S423: Encapsulate the encrypted message with a UDP header and an IP header, wherein the UDP source port is the data stream service port.

[0156] In this example, after DPDK receives the packet, the message first goes through the IP routing or policy matching process. This process is performed by the administrator according to the routing entries and policy matching rules pre-configured according to the actual networking situation. The administrator will carefully analyze the routing characteristics or policy characteristics of the business data, such as the source address, destination address, port number and other key information, to ensure that the business data that needs to be encrypted and encapsulated by DTLS is accurately sent to the dtls-encrypt node processing logic, which is the premise for ensuring that the data can be safely transmitted according to the established policy. The dtls-encrypt node is responsible for encryption and encapsulation processing. In this node, the message is encrypted and encapsulated to ensure the confidentiality and integrity of the data. The encrypted and encapsulated message will be sent to the ip4-output / ip6-output node. According to the IP version of the message (IPv4 or IPv6), the corresponding output node is selected for processing. Finally, the encrypted and encapsulated message is sent out through the network interface to complete the entire encrypted transmission process.

[0157] In S420: dtls-encrypt node encryption encapsulation, the dtls-encrypt node first retrieves the corresponding key object from the key management module through the key ID. The key object includes the key type, length, algorithm, and key value. After obtaining the key specific information, the dtls-encrypt node will use the algorithm and key specified in the key specific information to encrypt and encapsulate the message to ensure that the data is not stolen or tampered with by unauthorized third parties during transmission. After the encryption is completed, the dtls-encrypt node will encapsulate the UDP header and IP header for the encrypted message. Among them, the UDP source port is set to the data stream communication port to ensure that the encrypted message can be correctly received and processed.

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

[0159] S431B. Determine the IP address and UDP port of the encrypted message, where the encrypted message refers to the target message after encryption and encapsulation.

[0160] S432B. Determine the UDP session corresponding to the encrypted message according to the IP address and UDP port.

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

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

[0163] Specifically, by determining the IP address and UDP port of the encrypted message, the network location information of the target message after encryption and encapsulation 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, the encrypted message can be decrypted, and the data stream message information can be obtained.

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

[0165] S310: DPDK receives the packet, routes the IP packet, and sends the packet to the udp4-input / udp6-input node processing logic.

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

[0167] 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.

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

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

[0170] In this example, after the DPDK receives the packet, it forwards the message to the corresponding processing logic node according to the IP routing table. When the target protocol is IPv4 or IPv6, the message is sent to the udp4-input or udp6-input node for subsequent processing. These nodes are the entry point for the message to enter the UDP protocol stack and are responsible for processing all UDP protocol packets. After receiving the message, the udp4-input or udp6-input node first checks the UDP destination port number. If the UDP destination port number matches the port registered by the DTLS (Datagram Transport Layer Security) protocol in the system, it means that the message is part of the DTLS session. At this time, the node will forward the message to the DTLS conversion identification node for further processing. After receiving the message, the DTLS conversion identification node will parse the content of its DTLS record layer, especially the protocol number field. According to the protocol number, the node can classify the message. For the identified data stream message, the dtls-decrypt node will use the previously negotiated key and algorithm to decrypt and decapsulate it. The decryption process will restore the original application layer data, while the decapsulation process will remove the DTLS protocol header and any possible padding data. The decrypted message will be sent to the ip4-output or ip6-output node, which is the exit of the message from the IP protocol stack. Here, the message will undergo the necessary routing and encapsulation operations and finally be sent out through the corresponding network interface. During the sending process, the data packet will follow the provisions of the IP protocol to ensure that the data can accurately reach the target address.

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

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

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

[0174] In this example, the dtls-decrypt node first identifies the key ID in the message 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 and attaches the key ID as a query parameter. After receiving the request, the key management module will find and return the key object that matches the key ID. This key object contains specific information about the key, such as the key type, length, and specific algorithm used for decryption.

[0175] After obtaining the key information, the dtls-decrypt node uses this information to guide the decryption process. The message is decrypted according to the algorithm and key specified in the key information. During the decryption process, the node removes the header and tail information added by the DTLS protocol to restore the original application layer data. At the same time, 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 completed, the node passes the recovered data to the next processing node for further processing or transmission.

[0176] See also Fig.19 S432B, according to the IP address and the UDP port, determining the UDP session corresponding to the encrypted message, comprising the following steps:

[0177] S432B.1. Find the data stream session using the IP address and UDP port.

[0178] S432B.2. If the search is successful, the data stream session is determined to be a UDP session.

[0179] S432B.3. If the search fails, a new data stream session is created as a UDP session.

[0180] S432B.4. Determine the key ID through the IP address and UDP port, and bind the key ID to the UDP session.

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

[0182] If the search is successful, it means that the encrypted message belongs to an established UDP connection and can be processed according to the defined rules; if the search fails, it means 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 can ensure that each UDP session uses the correct key for encryption and decryption operations, effectively preventing data from being stolen or tampered with during transmission, and avoiding key confusion or incorrect use between multiple UDP sessions. In the subsequent transmission process, there is no need for secondary negotiation and exchange of keys, which reduces communication delays and improves communication efficiency.

[0183] For example, see Fig. 20 , the implementation process is as follows:

[0184] S331: Recognize it as a data stream message and find the data stream session by <IP, UDP port>.

[0185] S332: If the data stream session search fails, create a new data stream UDP session.

[0186] S333: Search for key information in the key management module by <IP, UDP port> and bind the key ID to the session.

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

[0188] S335: Send the data stream message into the processing logic of the dtls - decrypt node.

[0189] Embodiment 2

[0190] Please refer to Fig.21 , this application embodiment also discloses a message processing device, including:

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

[0192] An allocation module 500, which is used to allocate a communication interface according to the communication information, and the communication interface refers to the data stream communication port for data stream transmission. The allocation module 500 can execute S200 in the embodiment shown above Figure 1 shown in Figure 2 S120 in the embodiment shown in Figure 3 S120 in the embodiment shown in, which will not be elaborated here.

[0193] A sending module 600, which is used to send a port change protocol to the client, and the port change protocol carries communication interface - related information. The sending module 600 can execute S300 in the embodiment shown above Figure 1 shown in Figure 2 S130 in the embodiment shown in Figure 3 S130 in the embodiment shown in, which will not be elaborated here.

[0194] The interaction 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 number of the data flow message and the sequence number of the control flow message are calculated independently. The identification module 700 can execute the above Figure 1 S400 in the illustrated embodiment, Figure 2 In the embodiment shown, S140, Figure 3 In the embodiment shown, S140, Fig.13 The embodiment shown, Fig.14 The embodiment shown, Figure 17-Figure 20 The illustrated embodiments will not be described in detail here.

[0195] The receiving module 800 is used to periodically receive a control flow keep-alive message or a data flow keep-alive message sent by a 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.

[0196] The discarding 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, Figure 2 S160 in the embodiment shown, Figure 3 S160 in the illustrated embodiment will not be described in detail here.

[0197] Embodiment 3

[0198] See also Fig. 22 , the embodiment of the present application further provides an electronic device, including:

[0199] processor.

[0200] A memory is used to store processor executable instructions.

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

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

[0203] 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 the 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 through a network connection. When the computer program is executed by the processor, any message processing method is implemented.

[0204] Those skilled in the art will understand that Fig. 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 those shown in the figure, or combine certain components, or have a different arrangement of components.

[0205] Embodiment 4

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

[0207] The computer-readable storage medium mentioned above can be implemented by any type of volatile or non-volatile storage 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 memory, flash memory, magnetic disk or optical disk. The readable storage medium can be any available medium that can be accessed by a general or special-purpose computer.

[0208] 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 a component 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.

[0209] Embodiment 5

[0210] 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, any message processing method is implemented.

[0211] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0212] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or 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, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0213] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0214] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0215] Although the preferred embodiments of the present invention have been described, those skilled in the art may make other changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present invention.

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

Claims

1. A message processing method, characterized in that: The steps include: In response to the handshake request information sent by the client, a communication connection is established, and communication information related to the handshake request information is generated, wherein the communication information includes a new message type, and the new message type is used to adjust the data stream communication port, and the data stream communication port refers to the destination port for transmitting the data stream 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 a control flow keep-alive message or a data flow keep-alive message sent by a client, wherein the control flow keep-alive message and the data flow keep-alive message are generated by a control flow session keep-alive protocol and a data flow session keep-alive protocol, respectively, and 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, characterized in that Identify the message attributes of the target message and perform data exchange based on the message attributes, including 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 according to the port number and message attributes of the target message, wherein the port number includes a source port and a destination port; A communication interface corresponding to the message attributes is used to implement UDP session interaction.

4. The method according to claim 2, characterized in that After periodically receiving a control flow keep-alive message or a data flow keep-alive message sent by 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 the handshake request information sent by the client, establishing a communication connection, and generating communication information related to the handshake request information, 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, generate 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; The ID information and session key information of the association negotiation response session are associated.

6. The method according to claim 5, characterized in that 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 stream 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, characterized in that 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 packaging instructions and generate a key ID; Determine the key object through the key ID and obtain the key specific information, wherein the key information includes the key ID and the key object; Use the key specific information to encrypt the UDP session, and encapsulate the encrypted target message with a UDP header and an IP header in sequence to generate an encrypted message; Use the data stream communication interface to transmit encrypted messages.

8. The method according to claim 3, characterized in that 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 target message after encryption and encapsulation; Determine the UDP session corresponding to the encrypted message according to the IP address and the 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, characterized in that Determining a UDP session corresponding to the encrypted message according to 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 the UDP port, and is bound to the UDP session.

10. A message processing device, characterized in that: include: A response module, 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, wherein the communication information includes a new message type, and the new message type is used to adjust the data stream communication port, and the data stream communication port refers to the destination port for transmitting the data stream between the client and the 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, used for sending 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 messages and control flow messages, and the sequence number of the data flow message and the sequence number of the control flow message are calculated independently.

Images