Message processing method, device, system, equipment, medium and product

Abstract

The invention relates to the technical field of communication, in particular to a message processing method, device, system and equipment, a medium and a product, and the method comprises the steps that a server receives a first handshake message forwarded by a gateway under the condition that the analysis of the first handshake message sent by a client fails; if it is determined that the message length of the first handshake message meets the length requirement, generating a handshake message retransmission request, and sending the handshake message retransmission request to the client; the server receives a target handshake message sent by the gateway under the condition that the second handshake message sent by the client is successfully analyzed, and establishes a handshake connection with the client based on the target handshake message, the target handshake message carries user identity information of a user to which the client belongs, and the user identity information carries user identity information of the user to which the client belongs. The second handshake message is sent to the gateway by the client based on the handshake message retransmission request, so that the message size of the second handshake message resent by the client meets the analysis buffer area of the gateway, and the success rate of gateway number taking and handshake connection can be effectively improved.

Description

Technical Field

[0001] This disclosure relates to the technical field of communications, and more specifically, to a message processing method, apparatus, system, device, medium, and product. Background Technology

[0002] The client sends a message to the server via the one-click login software development kit (SDK). After successfully identifying the user, the operator gateway adds the user's contact information to the message and forwards it to the server. After removing the added contact information, the server returns credentials to the one-click login SDK, thus realizing the one-click login function.

[0003] In related technologies, in order to address the security threats posed by quantum computers, anti-quantum algorithm groups have been introduced into the messages. However, since the message length may exceed the parsing buffer of the operator's gateway, there is a problem that the operator's gateway may fail to retrieve the number, which in turn leads to a low success rate of the handshake between the client and the server. Summary of the Invention

[0004] This disclosure is made in view of the above-mentioned problems. This disclosure provides a message processing method, apparatus, system, device, medium, and product.

[0005] According to one aspect of this disclosure, a message processing method is provided, applied to a server, comprising:

[0006] The receiving gateway forwards the first handshake message if it fails to parse the first handshake message sent by the client.

[0007] If it is determined that the length of the first handshake message meets the length requirement, a handshake message retransmission request is generated and sent to the client.

[0008] The gateway receives a target handshake message sent by the client after successfully parsing the second handshake message sent by the client, and establishes a handshake connection with the client based on the target handshake message; wherein the target handshake message carries the user identity information of the user to which the client belongs, and the second handshake message is a retransmission request sent by the client to the gateway based on the handshake message.

[0009] Furthermore, generating a handshake message retransmission request according to one aspect of this disclosure includes:

[0010] The first handshake message is parsed to obtain the first key exchange algorithm supported by the client;

[0011] Based on the first key exchange algorithm and the second key exchange algorithm supported by the server, a target key exchange algorithm is determined; wherein the length of the key corresponding to the target key exchange algorithm is less than the length of the key corresponding to the first key exchange algorithm.

[0012] Based on the target key exchange algorithm, the handshake message retransmission request is generated.

[0013] Furthermore, according to one aspect of this disclosure, the number of second key exchange algorithms is multiple; the step of determining the target key exchange algorithm based on the first key exchange algorithm and the second key exchange algorithm supported by the server includes:

[0014] Multiple second key exchange algorithms are matched with the first key exchange algorithm to obtain matching results; wherein, the matching results are used to indicate the degree of matching between each second key exchange algorithm and the first key exchange algorithm;

[0015] The target key exchange algorithm is determined based on the matching results and multiple second key exchange algorithms.

[0016] Furthermore, determining the target key exchange algorithm based on the matching result and a plurality of second key exchange algorithms according to one aspect of this disclosure includes:

[0017] If, based on the matching results, it is determined that each of the second key exchange algorithms matches the first key exchange algorithm, the compatibility between each of the second key exchange algorithms and the client is determined.

[0018] The second key exchange algorithm that meets the compatibility requirements is determined to be the target key exchange algorithm.

[0019] Furthermore, determining the target key exchange algorithm based on the matching result and a plurality of second key exchange algorithms according to one aspect of this disclosure includes:

[0020] If, based on the matching result, there is a second key exchange algorithm among a plurality of second key exchange algorithms that does not match the first key exchange algorithm, the target key exchange algorithm is determined based on the second key exchange algorithm that does not match the first key exchange algorithm.

[0021] Furthermore, according to one aspect of this disclosure, generating the handshake message retransmission request based on the target key exchange algorithm includes:

[0022] The security protocol is determined based on the message length of the first handshake message; wherein the security protocol is a different version from the security protocol corresponding to the first handshake message.

[0023] The handshake message retransmission request is generated based on the security protocol and the target key exchange algorithm.

[0024] Furthermore, the method according to one aspect of this disclosure also includes:

[0025] After receiving the first handshake message forwarded by the gateway in the event that the gateway fails to parse the first handshake message sent to the client, it is determined whether the first handshake message is the first handshake message that the gateway has failed to parse.

[0026] If it is determined that the first handshake message is a handshake message that the gateway failed to parse for the first time, and if it is determined that the length of the first handshake message meets the length requirement, then a handshake message retransmission request is generated.

[0027] According to one aspect of this disclosure, a message processing method is provided, applied to a client, comprising:

[0028] Send the first handshake message to the gateway;

[0029] In response to a handshake message retransmission request sent by the server, a second handshake message is generated; wherein, the handshake message retransmission request is generated by the server after determining that the message length of the first handshake message meets the length requirement;

[0030] The second handshake message is sent to the gateway so that if the gateway successfully parses the second handshake message, it adds the user's identity information to the second handshake message to obtain the target handshake message, and then sends the target handshake message to the server.

[0031] According to one aspect of this disclosure, a message processing method is provided, applied to a gateway, comprising:

[0032] If parsing the first handshake message sent by the client fails, the first handshake message is forwarded to the server.

[0033] The client receives a second handshake message; wherein the second handshake message is generated by the client after receiving a handshake message retransmission request from the server, and the handshake message retransmission request is generated by the server after determining that the message length of the first handshake message meets the length requirement.

[0034] If the second handshake message is successfully parsed, the user identity information is added to the second handshake message to obtain the target handshake message;

[0035] The target handshake message is returned to the server so that the server can establish a handshake connection with the client based on the target handshake message.

[0036] According to another aspect of this disclosure, a message processing system is provided, comprising: a client, a gateway, and a server;

[0037] The client is used to send a first handshake message to the gateway;

[0038] The gateway is used to send the first handshake message to the server if the parsing of the first handshake message fails.

[0039] The server is configured to generate a handshake message retransmission request and send the handshake message retransmission request to the client if it determines that the message length of the first handshake message meets the length requirement.

[0040] The client is configured to generate a second handshake message in response to the handshake message retransmission request, and send the second handshake message to the gateway;

[0041] The gateway is configured to add user identity information to the second handshake message to obtain the target handshake message if the second handshake message is successfully parsed, and then return the target handshake message to the server.

[0042] The server is used to establish a handshake connection with the client based on the target handshake message.

[0043] According to another aspect of this disclosure, a server is provided, comprising:

[0044] The first message receiving unit is used to receive the first handshake message forwarded by the gateway when the first handshake message sent by the client fails to be parsed.

[0045] The request generation unit is configured to generate a handshake message retransmission request and send the handshake message retransmission request to the client if it is determined that the message length of the first handshake message meets the length requirement.

[0046] The handshake unit is used to receive a target handshake message sent by the gateway when the second handshake message sent by the client is successfully parsed, and to establish a handshake connection between the gateway and the client based on the target handshake message; wherein the target handshake message carries the user identity information of the user to which the client belongs, and the second handshake message is a retransmission request sent by the client to the gateway based on the handshake message.

[0047] According to another aspect of this disclosure, a client is provided, comprising:

[0048] The first message sending unit is used to send the first handshake message to the gateway;

[0049] A message generation unit is used to generate a second handshake message in response to a handshake message retransmission request sent by the server; wherein the handshake message retransmission request is generated by the server after determining that the message length of the first handshake message meets the length requirement;

[0050] The second message sending unit is used to send the second handshake message to the gateway, so that if the gateway successfully parses the second handshake message, it adds the user identity information to the second handshake message to obtain the target handshake message, and sends the target handshake message to the server.

[0051] According to another aspect of this disclosure, a gateway is provided, comprising:

[0052] The third message sending unit forwards the first handshake message to the server if it fails to parse the first handshake message sent by the client.

[0053] The second message receiving unit is used to receive the second handshake message sent by the client; wherein the second handshake message is generated by the client after receiving the handshake message retransmission request sent by the server, and the handshake message retransmission request is generated by the server after determining that the message length of the first handshake message meets the length requirement;

[0054] The user identity information adding unit is used to add user identity information to the second handshake message when the second handshake message is successfully parsed, so as to obtain the target handshake message;

[0055] The message return unit is used to return the target handshake message to the server so that the server can establish a handshake connection with the client based on the target handshake message.

[0056] According to another aspect of this disclosure, an electronic device is provided, comprising: a processor, a memory, and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the memory via the bus, and when the machine-readable instructions are executed by the processor, the steps in the above-described message processing method are performed.

[0057] According to another aspect of this disclosure, a computer-readable storage medium is provided that stores a computer program, which, when executed by a processor, performs the steps in the above-described message processing method.

[0058] According to another aspect of this disclosure, a computer program product is provided, which is stored in a storage medium and executed by at least one processor to implement the steps in the above-described message processing method.

[0059] As will be described in detail below, according to the message processing method, apparatus, system, device, medium, and product of the present disclosure, the client sends a first handshake message to the gateway. If the gateway fails to parse the first handshake message, it sends the first handshake message to the server. If the server determines that the message length of the first handshake message meets the length requirement, it generates a handshake message retransmission request and sends the handshake message retransmission request to the client. In response to the handshake message retransmission request, the client generates a second handshake message and sends the second handshake message to the gateway. If the gateway successfully parses the second handshake message, it adds user identity information to the second handshake message to obtain a target handshake message and returns the target handshake message to the server. The server establishes a handshake connection with the client based on the target handshake message. Through the above processing method, if the gateway fails to parse the first handshake message, the server can send a handshake message retransmission request to the client. The client then resends the second handshake message to the gateway, enabling the gateway to successfully parse the second handshake message. This ensures that the size of the second handshake message meets the gateway's parsing buffer, thereby effectively improving the success rate of the gateway in obtaining the number. Furthermore, through the interaction between the client, gateway, and server, the success rate of the handshake between the server and the client can be effectively improved.

[0060] It should be understood that both the foregoing general description and the following detailed description are exemplary and intended to provide further illustration of the claimed technology. Attached Figure Description

[0061] The above and other objects, features, and advantages of this disclosure will become more apparent from the more detailed description of the embodiments thereof in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this disclosure and form part of the specification. They are used together with the embodiments of this disclosure to explain the disclosure and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0062] Figure 1 This is a flowchart illustrating a message processing method according to an embodiment of the present disclosure.

[0063] Figure 2 This is a flowchart illustrating a second message processing method according to an embodiment of the present disclosure.

[0064] Figure 3 This is a flowchart illustrating a third message processing method according to an embodiment of the present disclosure.

[0065] Figure 4 This is an interactive diagram illustrating a message processing procedure according to an embodiment of the present disclosure.

[0066] Figure 5This is a flowchart illustrating an algorithmic screening process according to an embodiment of the present disclosure.

[0067] Figure 6 This is a schematic diagram illustrating a message processing architecture according to an embodiment of the present disclosure.

[0068] Figure 7 This is a schematic diagram of a server according to an embodiment of the present disclosure.

[0069] Figure 8 This is a schematic diagram illustrating a client according to an embodiment of the present disclosure.

[0070] Figure 9 This is a schematic diagram illustrating a gateway according to an embodiment of the present disclosure.

[0071] Figure 10 This is a hardware block diagram illustrating an electronic device according to an embodiment of the present disclosure.

[0072] Figure 11 This is a schematic diagram illustrating a computer program product according to an embodiment of the present disclosure. Detailed Implementation

[0073] To make the objectives, technical solutions, and advantages of this disclosure more apparent, exemplary embodiments according to this disclosure will now be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this disclosure, and not all embodiments of this disclosure. It should be understood that this disclosure is not limited to the exemplary embodiments described herein.

[0074] To facilitate understanding of this embodiment, a message processing method disclosed in this disclosure will first be described in detail. The execution subject of the message processing method provided in this disclosure is generally an electronic device with a certain computing capability, such as a terminal device, a server, or other processing device. In some possible implementations, the message processing method can be implemented by a processor calling computer-readable instructions stored in memory.

[0075] See Figure 1 The diagram shows a flowchart of a message processing method provided in this embodiment of the present disclosure. This message processing method can be applied to a server. The method includes steps S101 to S103, wherein:

[0076] Step S101: Receive the first handshake message forwarded by the gateway in the event that the first handshake message sent by the client fails to be parsed.

[0077] As mentioned in the background technology, in order to deal with the security threat of quantum computers, the client has introduced anti-quantum algorithm groups in the handshake message, which causes the length of the handshake message to exceed the gateway's parsing buffer. The gateway cannot accurately identify and parse the handshake message, which leads to the gateway failing to obtain the number. For example, browsers and WeChat have this problem.

[0078] Directly increasing the capacity of the parsing buffer in the gateway has several drawbacks. First, it suffers from poor compatibility and operability. For example, as the length of the handshake message continues to increase, it becomes impossible to effectively determine the expansion amount of the parsing buffer capacity. Second, as the parsing buffer capacity increases, it consumes more of the gateway's computing resources, which affects the user experience of those using the operator's services. Moreover, updating the gateway device requires a significant amount of time and cost.

[0079] In response, this disclosure improves the server-side design by adding a message pre-reading, parsing, and forwarding processor. This allows the handshake message to be read and parsed before a handshake connection is established between the client and the server, ensuring that the handshake message can be successfully parsed by the gateway.

[0080] Based on this, in this embodiment of the disclosure, the client sends a first handshake message to the gateway, the gateway parses the first handshake message, and if the parsing of the first handshake message fails, it sends the first handshake message to the server.

[0081] There are many reasons why the gateway might fail to resolve the message, such as the first handshake message being too large or having an incorrect message format. However, if the gateway resolves the first handshake message successfully, it can directly add the user's identity information to the first handshake message and send a first handshake message carrying that user's identity information to the server. The server can then establish a handshake connection with the client based on this first handshake message carrying the user's identity information.

[0082] Step S102: If it is determined that the length of the first handshake message meets the length requirement, a handshake message retransmission request is generated and sent to the client.

[0083] Research has shown that successful handshake messages average 600 bytes, while failed handshake messages average 1,800 bytes, and quantum-resistant algorithm messages average 1,200 bytes. Therefore, this disclosure allows setting a length threshold of 1,500 bytes, or adjusting it according to the actual application scenario.

[0084] If the length of the first handshake message exceeds the length threshold, it is determined that the first handshake message needs to be retransmitted. The server needs to generate a handshake message retransmission request so that the client can resend the handshake message.

[0085] This disclosure may also support other methods for setting length requirements, but no further examples are provided here.

[0086] In this embodiment of the disclosure, the server can first identify the length of the first handshake message. If it is determined that the message length meets the length requirement, the server generates a handshake message retransmission request and sends the handshake message retransmission request to the client so that the client retransmits the handshake message, which facilitates the establishment of a handshake connection between the server and the client.

[0087] In the above implementation, retransmitting the handshake message before establishing a handshake connection between the client and the server makes it easier to locate the cause of the handshake failure. If the handshake message is retransmitted after establishing a handshake connection, it is impossible to accurately determine the source of the problem among the client, gateway, and server, thus saving tracing time and improving message processing efficiency.

[0088] Step S103: Receive the target handshake message sent by the gateway after successfully parsing the second handshake message sent by the client, and establish a handshake connection with the client based on the target handshake message; wherein, the target handshake message carries the user identity information of the user to which the client belongs, and the second handshake message is a retransmission request sent by the client to the gateway based on the handshake message.

[0089] Here, the length of the second handshake message is less than the length of the first handshake message, and the length of the second handshake message is less than the parsing buffer capacity of the gateway. Based on this, the gateway can successfully parse the second handshake message and execute the gateway number retrieval process.

[0090] The target handshake message is the second handshake message after adding user identity information, which includes the user's contact information and other information. This disclosure does not require this information.

[0091] In this embodiment of the disclosure, after receiving a handshake message retransmission request sent by the server, the client generates a second handshake message in response to the handshake message retransmission request. The client sends the second handshake message to the gateway. If the gateway successfully parses the second handshake message, it adds the user identity information of the user to which the client belongs to the second handshake message to obtain the target handshake message. The gateway returns the target handshake message to the server. The server establishes a handshake connection with the client based on the target handshake message.

[0092] In the above implementation, if the gateway fails to parse the first handshake message, the server can send a handshake message retransmission request to the client. The client then retransmits the second handshake message to the gateway, enabling the gateway to successfully parse the second handshake message. This ensures that the size of the second handshake message meets the gateway's parsing buffer, thereby effectively improving the success rate of the gateway obtaining the number. Furthermore, through the interaction between the client, gateway, and server, the handshake success rate between the server and client is effectively improved.

[0093] In an optional implementation, the above steps generate a handshake message retransmission request, specifically including the following steps:

[0094] The first handshake message is parsed to obtain the first key exchange algorithm supported by the client;

[0095] Based on the first key exchange algorithm and the second key exchange algorithm supported by the server, a target key exchange algorithm is determined; wherein the length of the key corresponding to the target key exchange algorithm is less than the length of the key corresponding to the first key exchange algorithm.

[0096] Based on the target key exchange algorithm, the handshake message retransmission request is generated.

[0097] As mentioned earlier, a message pre-reading, parsing, and forwarding processor can be added to the server in advance. Since there are multiple message formats sent from the gateway to the server, including handshake messages and non-handshake messages, the message pre-reading, parsing, and forwarding processor needs to be compatible with different message formats.

[0098] If it is a handshake message (e.g., a ClientHello message), the message pre-read parser forwarding processor needs to parse relevant core information, such as the message size, the TLS (Transport Layer Security) version supported by the client, the KeyShare key exchange algorithm supported by the client, and gateway number extension information, etc. If it is a non-handshake message (e.g., a proxy-protocol message), the message pre-read parser forwarding processor needs to parse the user's Internet Protocol (IP) information carried in the proxy-protocol message.

[0099] Based on this, the message structure and fields of the handshake message can be used to determine whether it is a handshake message, as shown in Table 1. If the message length is less than 5 bytes, it indicates that the message is incomplete or the message format is incorrect, and the client needs to resend the message. keyShareGroup refers to the first key exchange algorithm supported by the client.

[0100] Table 1

[0101]

[0102]

[0103] Since the client defaults to TLS 1.2, if the length of the first handshake message meets the length requirement (i.e., the first handshake message is a ClientHello packet), then a TLS protocol version greater than TLS 1.2 needs to be used for processing. Therefore, it is necessary to determine the protocol version supported by the current first handshake message.

[0104] Based on this, if the message is determined to be a handshake message according to the above processing procedure, it is necessary to read the SupportedVersions table in Table 1 to determine whether it contains TLS 1.3 or higher.

[0105] If the supported versions include TLS 1.3 and above, the handshake message can continue to be processed; otherwise, processing should be stopped.

[0106] Following on from the previous section, the client introduces a quantum-resistant algorithm group in the handshake message. That is, the first key exchange algorithm supported by the client is a quantum-resistant algorithm. For the key exchange algorithm, this disclosure can select a target key exchange algorithm from the second key exchange algorithms supported by the server to ensure that the length of the key corresponding to the target key exchange algorithm is less than the length of the key corresponding to the first key exchange algorithm, thereby reducing the message length of the handshake message from the key exchange algorithm level.

[0107] In this embodiment of the disclosure, the server parses the first handshake message, reads the first key exchange algorithm supported by the client in the first handshake message, finds the second key exchange algorithm supported locally by the server, selects a suitable target key exchange algorithm from the second key exchange algorithm according to the first key exchange algorithm and the second key exchange algorithm, and generates a handshake message retransmission request so that the client can replace the original first key exchange algorithm with the target key exchange algorithm, which facilitates the regeneration of the second handshake message.

[0108] In the above embodiments, the key exchange algorithm is dynamically configured through the first key exchange algorithm and the second key exchange algorithm, thereby reducing the message length of the retransmitted handshake message to meet the gateway's parsing capabilities and effectively improving the gateway's success rate in obtaining numbers.

[0109] In one optional implementation, the number of second key exchange algorithms in the above steps is multiple; determining the target key exchange algorithm based on the first key exchange algorithm and the second key exchange algorithm supported by the server specifically includes the following steps:

[0110] Multiple second key exchange algorithms are matched with the first key exchange algorithm to obtain matching results; wherein, the matching results are used to indicate the degree of matching between each second key exchange algorithm and the first key exchange algorithm;

[0111] The target key exchange algorithm is determined based on the matching results and multiple second key exchange algorithms.

[0112] This disclosure allows for the pre-configuration of a recommended algorithm table on the server side, as shown in Table 2. Table 2 includes multiple second key exchange algorithms, which are not quantum-resistant algorithms, such as secp256r1 and secp384r1. Among them, the secp256r1 algorithm has the best performance and compatibility. The higher the priority in Table 2, the stronger the compatibility between the algorithm and the client. The algorithms in Table 2 can have their priorities adjusted or be modified according to the actual application scenario, but this disclosure does not require this.

[0113] Table 2

[0114] Algorithm identifier Algorithm Name Priority Feature Description secp256r1 NIST P-256 1 It has the best compatibility and is widely supported by mainstream clients. secp384r1 NIST P-384 2 Higher security strength, but with greater computational overhead.

[0115] Since the first key exchange algorithm supported by the client is a quantum-resistant algorithm, this disclosure requires selecting a key exchange algorithm that does not match the first key exchange algorithm from among multiple second key exchange algorithms as the target key exchange algorithm. To this end, it is necessary to determine the degree of matching between each second key exchange algorithm and the first key exchange algorithm in order to select the final target key exchange algorithm.

[0116] There can be multiple first key exchange algorithms. Accordingly, the matching result obtained above is the degree of matching between each second key exchange algorithm and each first key exchange algorithm.

[0117] In this embodiment of the disclosure, the server matches its supported second key exchange algorithm with the client's supported first key exchange algorithm, and determines the target key exchange algorithm from multiple second key exchange algorithms based on the degree of matching between each second key exchange algorithm and the first key exchange algorithm.

[0118] In the above implementation, the target key exchange algorithm is selected by calculating the matching degree between the second key exchange algorithm and the first key exchange algorithm. This effectively prevents the client from reselecting the quantum-resistant algorithm, i.e., the first key exchange algorithm, and ensures the validity of the handshake message retransmission request, so as to support the flexibility of the message processing process.

[0119] In an optional implementation, the above steps determine the target key exchange algorithm based on the matching result and multiple second key exchange algorithms, specifically including the following steps:

[0120] If, based on the matching results, it is determined that each of the second key exchange algorithms matches the first key exchange algorithm, the compatibility between each of the second key exchange algorithms and the client is determined.

[0121] The second key exchange algorithm that meets the compatibility requirements is determined to be the target key exchange algorithm.

[0122] In this embodiment of the disclosure, if each second key exchange algorithm matches the first key exchange algorithm, then the second key exchange algorithm that meets the compatibility requirements with the client is selected as the target key exchange algorithm.

[0123] It is worth noting that although the second key exchange algorithm matches the first key exchange algorithm, the second key exchange algorithm is not the same as the first key exchange algorithm. Therefore, the problem of reselecting the quantum-resistant algorithm (i.e. the first key exchange algorithm) mentioned earlier will not occur.

[0124] Furthermore, the second key exchange algorithm with the highest compatibility with the client can be selected as the target key exchange algorithm. As shown in Table 2, secp256r1 can be selected as the target key exchange algorithm. The compatibility level can be adjusted adaptively as required, but this disclosure does not impose such requirements.

[0125] In the above implementation, this key exchange algorithm selection mechanism measures the matching degree between algorithms and the compatibility between the algorithm and the client, ensuring the accuracy of the target key exchange algorithm and thus effectively ensuring the continuity of the message processing process. Furthermore, this mechanism can be applied to mainstream PCs and mobile devices such as Edge, Chrome, and Firefox, expanding the application scenarios of the entire message processing process.

[0126] In an optional implementation, the above steps determine the target key exchange algorithm based on the matching result and multiple second key exchange algorithms, specifically including the following steps:

[0127] If, based on the matching result, there is a second key exchange algorithm among a plurality of second key exchange algorithms that does not match the first key exchange algorithm, the target key exchange algorithm is determined based on the second key exchange algorithm that does not match the first key exchange algorithm.

[0128] In this embodiment of the disclosure, if any second key exchange algorithm does not match the first key exchange algorithm, then the second key exchange algorithm is selected as the target key exchange algorithm; if multiple second key exchange algorithms do not match the first key exchange algorithm, then the multiple second key exchange algorithms that do not match the first key exchange algorithm are first determined, then the compatibility degree between each second key exchange algorithm and the client is determined, and the second key exchange algorithm that meets the compatibility requirements is determined as the target key exchange algorithm.

[0129] In the above implementation, a second key exchange algorithm that does not match the first key exchange algorithm is selected as the target key exchange algorithm to prevent the client from using the first key exchange algorithm to send handshake messages again, ensuring the validity of the resent handshake messages, thereby improving the success rate of the handshake connection between the client and the server.

[0130] In an optional implementation, the above steps, based on the target key exchange algorithm, generate the handshake message retransmission request, specifically including the following steps:

[0131] The security protocol is determined based on the message length of the first handshake message; wherein the security protocol is a different version from the security protocol corresponding to the first handshake message.

[0132] The handshake message retransmission request is generated based on the security protocol and the target key exchange algorithm.

[0133] Here, the security protocol can be the Transport Layer Security (TLS) protocol. The default choice is TLS 1.2, which has the best compatibility with the gateway. That is, the protocol version corresponding to the security protocol in the first handshake message is TLS 1.2.

[0134] This disclosure can dynamically select the version of the security protocol based on the length of the first handshake message. Specifically, if it is determined that the length of the first handshake message meets the length requirement, TLS1.3 is selected first, with TLS1.1 and TLS1.2 as candidates; if it is determined that the length of the first handshake message does not meet the length requirement, TLS1.2 is selected first, with TLS1.1 as a candidate.

[0135] Accordingly, the handshake connection phase between the client and the server is also performed according to the priority of the above version.

[0136] In this embodiment, the server can generate a handshake message retransmission request by dynamically selecting a security protocol and key exchange algorithm, which assists the client in generating a second handshake message. This ensures that the size of the second handshake message is within the gateway's parsing buffer, thereby improving the success rate of gateway number retrieval and handshake connection.

[0137] In an optional implementation, the above steps further include the following steps:

[0138] After receiving the first handshake message forwarded by the gateway in the event that the gateway fails to parse the first handshake message sent to the client, it is determined whether the first handshake message is the first handshake message that the gateway has failed to parse.

[0139] If it is determined that the first handshake message is a handshake message that the gateway failed to parse for the first time, and if it is determined that the length of the first handshake message meets the length requirement, then a handshake message retransmission request is generated.

[0140] During the processing of handshake messages, if the server determines that the message length meets the length requirement, it adds the needHelloRetry flag, indicating that a handshake message retransmission request needs to be generated, and sends the handshake message retransmission request to the client.

[0141] After receiving a handshake message retransmission request, the client will add a HelloRetried flag to the retransmitted handshake message to indicate that the handshake message is a retransmitted handshake message.

[0142] When the server receives a resent handshake message, it first parses the message to see if it contains the HelloRetried identifier. If the message does contain the HelloRetried identifier, it means that the message is a resent handshake message from the client. Even if the gateway fails to parse the message again, the server will not add the needHelloRetry identifier. This avoids resending the handshake message and reducing unnecessary performance overhead.

[0143] In response, the server can use the HelloRetried flag to determine whether the received first handshake message is a handshake message that failed to be parsed by the gateway for the first time. In this embodiment, if the first handshake message is a handshake message that failed to be parsed by the gateway for the first time, the above-mentioned process of generating a handshake message retransmission request is executed; if the first handshake message is not a handshake message that failed to be parsed by the gateway for the first time, the processing of the first handshake message is stopped and the message pre-read parsing and forwarding processor is deregistered.

[0144] In the above embodiments, by determining whether the first handshake message is the first failed parsing, the repeated processing of the same handshake message can be effectively avoided, preventing repeated sending of handshake message requests for the same handshake message and effectively avoiding the risk of looping in the handshake processing process.

[0145] See Figure 2The diagram shows a flowchart of a second message processing method provided in this embodiment of the present disclosure. This message processing method can be applied to a client. The method includes steps S201 to S204, wherein:

[0146] Step S201: Send the first handshake message to the gateway.

[0147] Step S202: In response to the handshake message retransmission request sent by the server, generate a second handshake message; wherein the handshake message retransmission request is generated by the server after determining that the message length of the first handshake message meets the length requirement.

[0148] Here, the handshake message retransmission request includes the security protocol and target key exchange algorithm dynamically selected by the server for the first handshake message. The client can first parse the handshake message retransmission request and generate a second handshake message according to the parsed security protocol and target key exchange algorithm. The message length of the second handshake message is less than that of the first handshake message.

[0149] In this embodiment of the disclosure, the client sends a first handshake message to the gateway. The gateway parses the first handshake message. If the parsing of the first handshake message fails, the gateway sends the first handshake message to the server. The server can first identify the message length of the first handshake message. If it determines that the message length meets the length requirement, it generates a handshake message retransmission request and sends the handshake message retransmission request to the client. The client responds to the handshake message retransmission request and generates a second handshake message.

[0150] In the above implementation, the client can determine the security protocol and key exchange algorithm selected by the server based on the retransmission request of the handshake message sent by the server, and generate a second handshake message based on the security protocol and key exchange algorithm, so that the second handshake message can meet the gateway's parsing capabilities, thereby improving the success rate of the gateway in obtaining numbers.

[0151] Step S203: Send the second handshake message to the gateway, so that if the gateway successfully parses the second handshake message, it adds the user identity information to the second handshake message to obtain the target handshake message, and sends the target handshake message to the server.

[0152] In this embodiment of the disclosure, the client sends a second handshake message to the gateway. If the gateway successfully parses the second handshake message, it adds the user identity information of the user to which the client belongs to the second handshake message to obtain the target handshake message. The gateway returns the target handshake message to the server, and the server establishes a handshake connection with the client based on the target handshake message.

[0153] In the above implementation, if the gateway fails to parse the first handshake message, the server can send a handshake message retransmission request to the client. The client then retransmits the second handshake message to the gateway, enabling the gateway to successfully parse the second handshake message. This ensures that the size of the second handshake message meets the gateway's parsing buffer, thereby effectively improving the success rate of the gateway obtaining the number. Furthermore, through the interaction between the client, gateway, and server, the handshake success rate between the server and client is effectively improved.

[0154] See Figure 3 The diagram shows a flowchart of a third message processing method provided in this embodiment of the present disclosure. This message processing method can be applied to a gateway. The method includes steps S301 to S304, wherein:

[0155] Step S301: If parsing the first handshake message sent by the client fails, forward the first handshake message to the server.

[0156] In this embodiment of the disclosure, the client sends a first handshake message to the gateway, the gateway parses the first handshake message, and if the parsing of the first handshake message fails, it sends the first handshake message to the server.

[0157] Step S302: Receive the second handshake message sent by the client; wherein the second handshake message is generated by the client after receiving the handshake message retransmission request sent by the server, and the handshake message retransmission request is generated by the server after determining that the message length of the first handshake message meets the length requirement.

[0158] In this embodiment of the disclosure, after receiving the first handshake message sent by the gateway, the server identifies the message length of the first handshake message. If it is determined that the message length meets the length requirement, the server generates a handshake message retransmission request and sends the handshake message retransmission request to the client. The client responds to the handshake message retransmission request, generates a second handshake message, and sends the second handshake message to the gateway.

[0159] Step S303: If the second handshake message is successfully parsed, add the user identity information to the second handshake message to obtain the target handshake message.

[0160] Step S304: Return the target handshake message to the server so that the server can establish a handshake connection with the client based on the target handshake message.

[0161] If the gateway fails to parse the second handshake message, it forwards the second handshake message to the server. After the server determines that the second handshake message is a handshake message resent by the client, it stops processing the second handshake message to prevent the handshake message from being processed in a loop.

[0162] In this embodiment of the disclosure, if the gateway successfully parses the second handshake message, it adds the user identity information of the user to which the client belongs to the second handshake message to obtain the target handshake message. The gateway then returns the target handshake message to the server, and the server establishes a handshake connection with the client based on the target handshake message.

[0163] In the above implementation, if the gateway fails to parse the first handshake message, the server can send a handshake message retransmission request to the client. The client then retransmits the second handshake message to the gateway, enabling the gateway to successfully parse the second handshake message. This ensures that the size of the second handshake message meets the gateway's parsing buffer, thereby effectively improving the success rate of the gateway obtaining the number. Furthermore, through the interaction between the client, gateway, and server, the handshake success rate between the server and client is effectively improved.

[0164] The following is combined with Figure 4 The above message processing procedure is described. For example... Figure 4 As shown, the specific process is described below:

[0165] S401: The client sends the first handshake message to the gateway.

[0166] S402: If the gateway fails to parse the first handshake message, it sends the first handshake message to the server.

[0167] S403: If the server determines that the length of the first handshake message meets the length requirement, it generates a handshake message retransmission request.

[0168] S404: The server sends a handshake message retransmission request to the client.

[0169] S405: The client responds to the handshake message retransmission request by generating a second handshake message.

[0170] S406: The client sends a second handshake message to the gateway.

[0171] S407: If the gateway successfully parses the second handshake message, it adds the user's identity information to the second handshake message to obtain the target handshake message.

[0172] S408: The gateway returns the target handshake message to the server.

[0173] S409: The server establishes a handshake connection with the client based on the target handshake message.

[0174] The following is combined with Figure 5 The above algorithm's selection process is described. For example... Figure 5 As shown, the specific process is described below:

[0175] S501: Match the first key exchange algorithm supported by the client with the second key exchange algorithm supported by the server to obtain the matching result.

[0176] Here, the matching result is used to indicate the degree of matching between each second key exchange algorithm and the first key exchange algorithm.

[0177] S502: Determine whether the second key exchange algorithm and the first key exchange algorithm match based on the matching result.

[0178] If the second key exchange algorithm matches the first key exchange algorithm, then execute S503-S504; otherwise, execute S505.

[0179] S503: Determine the compatibility between each second key exchange algorithm and the client.

[0180] S504: Determine the second key exchange algorithm that meets the compatibility requirements as the target key exchange algorithm.

[0181] S505: Determine the target key exchange algorithm based on the second key exchange algorithm that does not match the first key exchange algorithm.

[0182] Based on the above message processing flow, this disclosure also makes adjustments to the network architecture, such as... Figure 6 As shown, this method simplifies link communication while increasing the flexibility of gateway number acquisition and handshake processes.

[0183] In the old architecture, after receiving the handshake message retransmission request, the client first forwards the handshake message retransmission request to the F5 hardware load balancer, which is responsible for the initial request distribution. Then the request is forwarded by Layer 4 to nginx, which can be understood as an HTTP and reverse proxy web server. Finally, nginx forwards the handshake message retransmission request by Layer 4 to the HTTP business module, which is used to handle the number retrieval logic.

[0184] In the new architecture, after receiving a handshake message retransmission request, the client first forwards the handshake message retransmission request to the F5 hardware load balancer, and then it is forwarded by Layer 4 to the Agent module. The Agent module can parse the handshake message retransmission request and, based on the parsing result, forward the handshake message retransmission request to the corresponding business module through an internal HTTP call, such as the HyperText Markup Language 5 (HTML5) business module or the Software Development Kit (SDK) business module.

[0185] Nginx Layer 4 forwarding refers to data forwarding at the transport layer. Traditional Nginx Layer 4 forwarding is not flexible enough when handling TLS handshakes. In order to handle TLS handshakes and gateway number retrieval more efficiently, this disclosure removes Nginx Layer 4 forwarding and replaces it with a newly created agent module. This module can directly establish a connection with the client to handle the TLS handshake process.

[0186] The Agent module includes a message prefetching, parsing, and forwarding processor, which is used to prefetch and parse handshake messages before the TLS handshake. This message prefetching, parsing, and forwarding processor supports the identification and parsing of proxy-protocol messages and ClientHello messages, enabling the replacement of Nginx.

[0187] The Agent module itself acts as both an HTTPS server and a gateway. It can route handshake messages to different business modules based on the interface path, improving system flexibility and scalability, and facilitating management and maintenance. Furthermore, this architectural improvement achieves isolation and decoupling of request parsing and number retrieval business logic, realizing functional isolation. Changes to the Agent will not affect business modules, improving the stability of the processing.

[0188] As can be seen from the above description, the technical solution disclosed herein has the following advantages:

[0189] By adding a message pre-reading parsing and forwarding processor on the server side to parse handshake messages in real time, and customizing handshake message retransmission requests based on the parsed information, the system can dynamically select the TLS version and key exchange algorithm, solve the problem of gateway-side failure to parse handshake messages, ensure that the client retransmits concise handshake messages, and improve the handshake success rate.

[0190] This disclosure also provides a message processing system, which includes: a client, a gateway, and a server;

[0191] The client is used to send a first handshake message to the gateway;

[0192] The gateway is used to send the first handshake message to the server if the parsing of the first handshake message fails.

[0193] The server is configured to generate a handshake message retransmission request and send the handshake message retransmission request to the client if it determines that the message length of the first handshake message meets the length requirement.

[0194] The client is configured to generate a second handshake message in response to the handshake message retransmission request, and send the second handshake message to the gateway;

[0195] The gateway is configured to add user identity information to the second handshake message to obtain the target handshake message if the second handshake message is successfully parsed, and then return the target handshake message to the server.

[0196] The server is used to establish a handshake connection with the client based on the target handshake message.

[0197] Here, the specific implementation methods of the client, gateway, and server are as described in the above embodiments, and will not be described in detail here.

[0198] Reference Figure 7 The diagram shown is a schematic representation of a server provided in an embodiment of this disclosure, including: a first message receiving unit 70, a request generation unit 71, and a handshake unit 72; wherein:

[0199] The first message receiving unit is used to receive the first handshake message forwarded by the gateway when the first handshake message sent by the client fails to be parsed.

[0200] The request generation unit is configured to generate a handshake message retransmission request and send the handshake message retransmission request to the client if it is determined that the message length of the first handshake message meets the length requirement.

[0201] The handshake unit is used to receive a target handshake message sent by the gateway when the second handshake message sent by the client is successfully parsed, and to establish a handshake connection between the gateway and the client based on the target handshake message; wherein the target handshake message carries the user identity information of the user to which the client belongs, and the second handshake message is a retransmission request sent by the client to the gateway based on the handshake message.

[0202] In one possible implementation, the server is also used for:

[0203] The first handshake message is parsed to obtain the first key exchange algorithm supported by the client;

[0204] Based on the first key exchange algorithm and the second key exchange algorithm supported by the server, a target key exchange algorithm is determined; wherein the length of the key corresponding to the target key exchange algorithm is less than the length of the key corresponding to the first key exchange algorithm.

[0205] Based on the target key exchange algorithm, the handshake message retransmission request is generated.

[0206] In one possible implementation, the server is also used for:

[0207] Multiple second key exchange algorithms are matched with the first key exchange algorithm to obtain matching results; wherein, the matching results are used to indicate the degree of matching between each second key exchange algorithm and the first key exchange algorithm;

[0208] The target key exchange algorithm is determined based on the matching results and multiple second key exchange algorithms.

[0209] In one possible implementation, the server is also used for:

[0210] If, based on the matching results, it is determined that each of the second key exchange algorithms matches the first key exchange algorithm, the compatibility between each of the second key exchange algorithms and the client is determined.

[0211] The second key exchange algorithm that meets the compatibility requirements is determined to be the target key exchange algorithm.

[0212] In one possible implementation, the server is also used for:

[0213] If, based on the matching result, there is a second key exchange algorithm among a plurality of second key exchange algorithms that does not match the first key exchange algorithm, the target key exchange algorithm is determined based on the second key exchange algorithm that does not match the first key exchange algorithm.

[0214] In one possible implementation, the server is also used for:

[0215] The security protocol is determined based on the message length of the first handshake message; wherein the security protocol is a different version from the security protocol corresponding to the first handshake message.

[0216] The handshake message retransmission request is generated based on the security protocol and the target key exchange algorithm.

[0217] In one possible implementation, the server is also used for:

[0218] After receiving the first handshake message forwarded by the gateway in the event that the gateway fails to parse the first handshake message sent to the client, it is determined whether the first handshake message is the first handshake message that the gateway has failed to parse.

[0219] If it is determined that the first handshake message is a handshake message that the gateway failed to parse for the first time, and if it is determined that the length of the first handshake message meets the length requirement, then a handshake message retransmission request is generated.

[0220] Reference Figure 8The diagram shown is a schematic representation of a client provided in an embodiment of this disclosure, including: a first message sending unit 80, a message generation unit 81, and a second message sending unit 82; wherein:

[0221] The first message sending unit is used to send the first handshake message to the gateway;

[0222] A message generation unit is used to generate a second handshake message in response to a handshake message retransmission request sent by the server; wherein the handshake message retransmission request is generated by the server after determining that the message length of the first handshake message meets the length requirement;

[0223] The second message sending unit is used to send the second handshake message to the gateway, so that if the gateway successfully parses the second handshake message, it adds the user identity information to the second handshake message to obtain the target handshake message, and sends the target handshake message to the server.

[0224] Reference Figure 9 The diagram shown is a schematic representation of a gateway provided in an embodiment of this disclosure, including: a third message sending unit 90, a second message receiving unit 91, a user identity information adding unit 92, and a message return unit 93; wherein:

[0225] The third message sending unit forwards the first handshake message to the server if it fails to parse the first handshake message sent by the client.

[0226] The second message receiving unit is used to receive the second handshake message sent by the client; wherein the second handshake message is generated by the client after receiving the handshake message retransmission request sent by the server, and the handshake message retransmission request is generated by the server after determining that the message length of the first handshake message meets the length requirement;

[0227] The user identity information adding unit is used to add user identity information to the second handshake message when the second handshake message is successfully parsed, so as to obtain the target handshake message;

[0228] The message return unit is used to return the target handshake message to the server so that the server can establish a handshake connection with the client based on the target handshake message.

[0229] The processing flow of each module and the interaction flow between modules can be referred to the relevant descriptions in the above method embodiments, and will not be elaborated here.

[0230] Corresponding to Figure 1 , Figure 2 and Figure 3In addition to the message processing method described in this disclosure, this embodiment also provides an electronic device 40, such as... Figure 10 The diagram shown is a structural schematic of an electronic device 40 provided in an embodiment of this disclosure, including:

[0231] The system includes a processor 41, a memory 42, and a bus 43. The memory 42 stores execution instructions and includes main memory 421 and external memory 422. The main memory 421, also called internal memory, temporarily stores the computational data in the processor 41, as well as data exchanged with external memory such as a hard disk. The processor 41 exchanges data with the external memory 422 through the main memory 421. When the electronic device 40 is running, the processor 41 communicates with the memory 42 through the bus 43, causing the processor 41 to execute the following instructions:

[0232] The receiving gateway forwards the first handshake message if it fails to parse the first handshake message sent by the client.

[0233] If it is determined that the length of the first handshake message meets the length requirement, a handshake message retransmission request is generated and sent to the client.

[0234] The gateway receives a target handshake message sent by the client after successfully parsing the second handshake message sent by the client, and establishes a handshake connection with the client based on the target handshake message; wherein the target handshake message carries the user identity information of the user to which the client belongs, and the second handshake message is a retransmission request sent by the client to the gateway based on the handshake message.

[0235] Alternatively, execute the following command:

[0236] Send the first handshake message to the gateway;

[0237] In response to a handshake message retransmission request sent by the server, a second handshake message is generated; wherein, the handshake message retransmission request is generated by the server after determining that the message length of the first handshake message meets the length requirement;

[0238] The second handshake message is sent to the gateway so that if the gateway successfully parses the second handshake message, it adds the user's identity information to the second handshake message to obtain the target handshake message, and then sends the target handshake message to the server.

[0239] Alternatively, execute the following command:

[0240] If parsing the first handshake message sent by the client fails, the first handshake message is forwarded to the server.

[0241] The client receives a second handshake message; wherein the second handshake message is generated by the client after receiving a handshake message retransmission request from the server, and the handshake message retransmission request is generated by the server after determining that the message length of the first handshake message meets the length requirement.

[0242] If the second handshake message is successfully parsed, the user identity information is added to the second handshake message to obtain the target handshake message;

[0243] The target handshake message is returned to the server so that the server can establish a handshake connection with the client based on the target handshake message.

[0244] This disclosure also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the message processing method described in the above-described method embodiments. The storage medium may be a volatile or non-volatile computer-readable storage medium.

[0245] This disclosure also provides a computer program product 100, such as... Figure 11 The diagram shown is a structural schematic of a computer program product 100 provided in an embodiment of this disclosure. The computer program product 100 carries a computer program 1001. The program included in the computer program 1001 can be used to execute the steps of the message processing method described in the above method embodiments. For details, please refer to the above method embodiments, which will not be repeated here.

[0246] The above description, with reference to the accompanying drawings, outlines a message processing method, apparatus, system, device, medium, and product according to embodiments of the present disclosure. First, the client sends a first handshake message to the gateway. If the gateway fails to parse the first handshake message, it sends the first handshake message to the server. Then, if the server determines that the message length of the first handshake message meets the length requirement, it generates a handshake message retransmission request and sends it to the client. In response to the retransmission request, the client generates a second handshake message and sends it to the gateway. If the gateway successfully parses the second handshake message, it adds user identity information to the second handshake message to obtain a target handshake message and returns it to the server. Finally, the server establishes a handshake connection with the client based on the target handshake message. Through the above processing method, if the gateway fails to parse the first handshake message, the server can send a handshake message retransmission request to the client. The client then resends the second handshake message to the gateway, enabling the gateway to successfully parse the second handshake message. This ensures that the size of the second handshake message meets the gateway's parsing buffer, thereby effectively improving the success rate of the gateway in obtaining the number. Furthermore, through the interaction between the client, gateway, and server, the success rate of the handshake between the server and the client can be effectively improved.

[0247] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0248] The block diagrams of devices, apparatuses, devices, and systems disclosed herein are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.

[0249] Additionally, as used herein, the “or” used in a list of items beginning with “at least one” indicates a separate list, such that a list of, for example, “at least one of A, B, or C” means A or B or C, or AB or AC or BC, or ABC (i.e., A and B and C). Furthermore, the word “exemplary” does not imply that the described example is preferred or better than other examples.

[0250] It should also be noted that in the systems and methods of this disclosure, the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered as equivalent solutions to this disclosure.

[0251] Various changes, substitutions, and modifications can be made to the technology described herein without departing from the teachings defined by the appended claims. Furthermore, the scope of the claims of this disclosure is not limited to the specific aspects of the processes, machines, manufactures, events, means, methods, and actions described above. Currently existing or later-developed processes, machines, manufactures, events, means, methods, or actions that perform substantially the same function or achieve substantially the same result as the corresponding aspects described herein can be utilized. Therefore, the appended claims include such processes, machines, manufactures, events, means, methods, or actions within their scope.

[0252] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0253] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations therein.

Claims

1. A message processing method, characterized in that, Applied to the server side, including: The receiving gateway forwards the first handshake message if it fails to parse the first handshake message sent by the client. If it is determined that the length of the first handshake message meets the length requirement, a handshake message retransmission request is generated and sent to the client. The gateway receives a target handshake message sent by the client after successfully parsing the second handshake message sent by the client, and establishes a handshake connection with the client based on the target handshake message; wherein the target handshake message carries the user identity information of the user to which the client belongs, and the second handshake message is a retransmission request sent by the client to the gateway based on the handshake message.

2. The method according to claim 1, characterized in that, The generation of the handshake message retransmission request includes: The first handshake message is parsed to obtain the first key exchange algorithm supported by the client; Based on the first key exchange algorithm and the second key exchange algorithm supported by the server, a target key exchange algorithm is determined; wherein the length of the key corresponding to the target key exchange algorithm is less than the length of the key corresponding to the first key exchange algorithm. Based on the target key exchange algorithm, the handshake message retransmission request is generated.

3. The method according to claim 2, characterized in that, The number of second key exchange algorithms is multiple; the step of determining the target key exchange algorithm based on the first key exchange algorithm and the second key exchange algorithms supported by the server includes: Multiple second key exchange algorithms are matched with the first key exchange algorithm to obtain matching results; wherein, the matching results are used to indicate the degree of matching between each second key exchange algorithm and the first key exchange algorithm; The target key exchange algorithm is determined based on the matching results and multiple second key exchange algorithms.

4. The method according to claim 3, characterized in that, The step of determining the target key exchange algorithm based on the matching result and multiple second key exchange algorithms includes: If, based on the matching results, it is determined that each of the second key exchange algorithms matches the first key exchange algorithm, the compatibility between each of the second key exchange algorithms and the client is determined. The second key exchange algorithm that meets the compatibility requirements is determined to be the target key exchange algorithm.

5. The method according to claim 3, characterized in that, The step of determining the target key exchange algorithm based on the matching result and multiple second key exchange algorithms includes: If, based on the matching result, there is a second key exchange algorithm among a plurality of second key exchange algorithms that does not match the first key exchange algorithm, the target key exchange algorithm is determined based on the second key exchange algorithm that does not match the first key exchange algorithm.

6. The method according to claim 2, characterized in that, The step of generating the handshake message retransmission request based on the target key exchange algorithm includes: The security protocol is determined based on the message length of the first handshake message; wherein the security protocol is a different version from the security protocol corresponding to the first handshake message. The handshake message retransmission request is generated based on the security protocol and the target key exchange algorithm.

7. The method according to claim 1, characterized in that, The method further includes: After receiving the first handshake message forwarded by the gateway in the event that the gateway fails to parse the first handshake message sent to the client, it is determined whether the first handshake message is the first handshake message that the gateway has failed to parse. If it is determined that the first handshake message is a handshake message that the gateway failed to parse for the first time, and if it is determined that the length of the first handshake message meets the length requirement, then a handshake message retransmission request is generated.

8. A message processing method, characterized in that, Applied to the client side, including: Send the first handshake message to the gateway; In response to a handshake message retransmission request sent by the server, a second handshake message is generated; wherein, the handshake message retransmission request is generated by the server after determining that the message length of the first handshake message meets the length requirement; The second handshake message is sent to the gateway so that if the gateway successfully parses the second handshake message, it adds the user's identity information to the second handshake message to obtain the target handshake message, and then sends the target handshake message to the server.

9. A message processing method, characterized in that, Applied to gateways, including: If parsing the first handshake message sent by the client fails, the first handshake message is forwarded to the server. The client receives a second handshake message; wherein the second handshake message is generated by the client after receiving a handshake message retransmission request from the server, and the handshake message retransmission request is generated by the server after determining that the message length of the first handshake message meets the length requirement. If the second handshake message is successfully parsed, the user identity information is added to the second handshake message to obtain the target handshake message; The target handshake message is returned to the server so that the server can establish a handshake connection with the client based on the target handshake message.

10. A message processing system, characterized in that, include: Client, gateway, and server; The client is used to send a first handshake message to the gateway; The gateway is used to send the first handshake message to the server if the parsing of the first handshake message fails. The server is configured to generate a handshake message retransmission request and send the handshake message retransmission request to the client if it determines that the message length of the first handshake message meets the length requirement. The client is configured to generate a second handshake message in response to the handshake message retransmission request; And send the second handshake message to the gateway; The gateway is used to add user identity information to the second handshake message if the second handshake message is successfully parsed, so as to obtain the target handshake message; And return the target handshake message to the server; The server is used to establish a handshake connection with the client based on the target handshake message.

11. A server, characterized in that, include: The first message receiving unit is used to receive the first handshake message forwarded by the gateway when the first handshake message sent by the client fails to be parsed. The request generation unit is configured to generate a handshake message retransmission request and send the handshake message retransmission request to the client if it is determined that the message length of the first handshake message meets the length requirement. The handshake unit is used to receive a target handshake message sent by the gateway when the second handshake message sent by the client is successfully parsed, and to establish a handshake connection between the gateway and the client based on the target handshake message; wherein the target handshake message carries the user identity information of the user to which the client belongs, and the second handshake message is a retransmission request sent by the client to the gateway based on the handshake message.

12. A client, characterized in that, include: The first message sending unit is used to send the first handshake message to the gateway; A message generation unit is used to generate a second handshake message in response to a handshake message retransmission request sent by the server; wherein the handshake message retransmission request is generated by the server after determining that the message length of the first handshake message meets the length requirement; The second message sending unit is used to send the second handshake message to the gateway, so that if the gateway successfully parses the second handshake message, it adds the user identity information to the second handshake message to obtain the target handshake message, and sends the target handshake message to the server.

13. A gateway, characterized in that, include: The third message sending unit forwards the first handshake message to the server if it fails to parse the first handshake message sent by the client. The second message receiving unit is used to receive the second handshake message sent by the client; wherein the second handshake message is generated by the client after receiving the handshake message retransmission request sent by the server, and the handshake message retransmission request is generated by the server after determining that the message length of the first handshake message meets the length requirement; The user identity information adding unit is used to add user identity information to the second handshake message when the second handshake message is successfully parsed, so as to obtain the target handshake message; The message return unit is used to return the target handshake message to the server so that the server can establish a handshake connection with the client based on the target handshake message.

14. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, they perform the steps of the message processing method as described in any one of claims 1 to 9.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the message processing method as described in any one of claims 1 to 9.

16. A computer program product, characterized in that, The computer program product is stored in a storage medium, and the program product is executed by at least one processor to implement the message processing method as described in any one of claims 1 to 9.

Images