Message processing method and apparatus, and device and readable storage medium

Abstract

Disclosed in the present description are a message processing method and apparatus, and a device and a readable storage medium. According to an example of the method, insofar as a TCP session is established between a user equipment and a network device, when data processing units in the user equipment respectively generate messages to be sent, by means of a session management unit, message headers of the messages to be sent is normalized to obtain normalized message headers, and first target messages corresponding to the messages to be sent are obtained on the basis of the normalized message headers. Thus, since first target messages can be transmitted on the basis of a TCP session between a user equipment and a network device, TCP message transmission between the user equipment including a plurality of data processing units and the network device in a mimic security system is realized.

Description

Message processing method, device, equipment and readable storage medium Technical Field

[0001] This specification relates to the field of computer technology, and in particular to methods, devices, equipment, and readable storage media for message processing. Background Art

[0002] The mimetic security defense theory based on intrinsic security is widely used in network devices such as storage controllers, servers, gateways, switches, industrial controllers, and can significantly improve the security performance of the equipment. In a mimetic security system, multiple data processing units can usually be deployed in a user device, and these multiple data processing units perform the same function independently of each other. In traditional network communications, Transmission Control Protocol (TCP) sessions exist between points. This means that once a user device establishes a TCP link with a network device, multiple data processing units in the user device should be able to establish a TCP session with the network device. However, since the message headers contained in the messages sent by different data processing units are inconsistent, in fact, the multiple data processing units in the user device cannot transmit data based on the same TCP session.

[0003] Summary of the Invention

[0004] In view of this, the present specification provides a message processing method, apparatus, device and readable storage medium to partially solve the above-mentioned problems existing in the prior art.

[0005] According to a first aspect of the present specification, a message processing method is provided, the method being applied to a user device, wherein the user device establishes a TCP session with a network device, the user device comprising a session management unit and multiple data processing units. The method may include: obtaining to-be-sent messages generated by the multiple data processing units; normalizing the message headers of each to-be-sent message by the session management unit to obtain a normalized message header; obtaining a first target message corresponding to each of the to-be-sent messages based on the normalized message header; and sending each of the first target messages to the network device via the established TCP session.

[0006] Optionally, the session management unit performs normalization processing on the message headers of each message to be sent to obtain a normalized message header, specifically including: selecting a target message from each message to be sent, and determining a first to-be-processed field in the message header of the target message, the first to-be-processed field including a message identifier, a port identifier, and a sequence number; reading designated parameters corresponding to the target message from the session management unit, and determining whether the designated parameters are initial values; if so, storing the first to-be-processed field in the message header of the target message as a target field in the session management unit, and determining the normalized first to-be-processed field based on the target field; if not, determining the normalized first to-be-processed field based on the target field pre-stored in the session management unit.

[0007] Optionally, when the first field to be processed is a sequence number, the pre-stored target field is read according to the session management unit to determine the first field to be processed after normalization, which may specifically include: updating the specified parameters corresponding to the target message according to the payload length of the target message; reading the pre-stored target sequence number from the session management unit; and obtaining a new sequence number as the normalized sequence number based on the updated specified parameters and the target sequence number.

[0008] Optionally, the session management unit normalizes the message headers of each message to be sent to obtain a normalized message header, specifically including: determining each second to-be-processed field from the message headers of each message to be sent, the second to-be-processed field including a sliding window, a maximum message segment length, and a user timeout duration; selecting the second to-be-processed field with the smallest value from each second to-be-processed field as the second to-be-processed field after normalization, and storing it in the session management unit.

[0009] Optionally, before normalizing the message headers of each message to be sent by the session management unit to obtain the normalized message headers, the method further includes: determining that hash values ​​of message data of each message to be sent are the same.

[0010] According to a second aspect of the present specification, a message processing method is provided. The method is applied to a user device, wherein the user device establishes a TCP session with a network device, and the user device includes a session management unit and multiple data processing units. The method may include: receiving a message to be processed sent by the network device via the established TCP session; extracting pre-stored session information of the multiple data processing units from the session management unit; determining second target messages corresponding to each of the multiple data processing units based on the session information of the multiple data processing units and the message to be processed; and sending each second target message to each of the multiple data processing units.

[0011] Optionally, based on the session information of the multiple data processing units and the messages to be processed, determining the second target messages corresponding to the multiple data processing units respectively, specifically including: copying the messages to be processed according to the number of the multiple data processing units; extracting the designated fields corresponding to the multiple data processing units respectively from the session information of the multiple data processing units, the designated fields including the message identifier, port identifier and serial number; obtaining the second target messages corresponding to the multiple data processing units respectively according to the designated fields corresponding to the multiple data processing units and each of the copied messages.

[0012] Optionally, when the designated field is a serial number, the second target messages corresponding to the multiple data processing units are obtained according to the designated fields corresponding to the multiple data processing units and the copied messages, which may specifically include: determining the designated parameters and payload length of the message to be processed; redetermining the designated parameters of the message to be processed according to the payload length of the message to be processed; redetermining the serial numbers corresponding to the multiple data processing units according to the serial numbers corresponding to the multiple data processing units and the redetermined designated parameters; and filling the redetermined serial numbers corresponding to the multiple data processing units into the copied messages in turn to obtain the second target messages corresponding to the multiple data processing units.

[0013] Optionally, based on the session information of the multiple data processing units and the messages to be processed, the second target messages corresponding to the multiple data processing units are determined, specifically including: determining the sequence number in the message header of the message to be processed; obtaining the session timeout counter in the session management unit; if it is determined based on the sequence number in the message header of the message to be processed that there is no sequence number error in the message to be processed, and the session timeout counter indicates that there is no timeout for the TCP session, then based on the session information of the multiple data processing units and the messages to be processed, the second target messages corresponding to the multiple data processing units are determined.

[0014] According to a third aspect of this specification, a message processing device is provided, the device being applied to a user device, the user device establishing a TCP session with a network device, the user device comprising a session management unit and a plurality of data processing units. The device may include: a message acquisition module for acquiring messages to be sent generated by the plurality of data processing units; a normalization module for normalizing the message headers of each message to be sent through the session management unit to obtain a normalized message header; a first target message determination module for obtaining a first target message corresponding to each message to be sent based on the normalized message header; and a first sending module for sending each first target message to the network device via the established TCP session.

[0015] Optionally, the device also includes: a message receiving module to be processed, used to receive the message to be processed sent by the network device through the established TCP session; a session information extraction module, used to extract the pre-stored session information of the multiple data processing units from the session management unit; a second target message determination module, used to determine the second target messages corresponding to the multiple data processing units respectively based on the session information of the multiple data processing units and the message to be processed; and a second sending module, used to send each second target message to the multiple data processing units respectively.

[0016] According to a fourth aspect of the present specification, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the above-mentioned message processing method is implemented.

[0017] According to a fifth aspect of this specification, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the above-mentioned message processing method when executing the computer program.

[0018] In the message processing solution provided in this specification, when a TCP session is established between a user device and a network device, when multiple data processing units in the user device each generate a message to be sent, the session management unit can normalize the message headers of each message to be sent, and obtain a corresponding first target message based on the normalized message headers and each message to be sent. In this way, multiple data processing units in the user device can all transmit the first target message based on the TCP session between the user device and the network device, thereby realizing TCP message transmission between a user device containing multiple data processing units and a network device in a mimetic security system. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The drawings described herein are used to provide further understanding of this specification and constitute a part of this specification. The illustrative embodiments of this specification and their descriptions are used to explain this specification and do not constitute improper limitations on this specification.

[0020] FIG1 is a schematic diagram of the architecture of a system for implementing a message processing method according to an embodiment of this specification.

[0021] FIG2 is a schematic diagram of functional modules of a session management unit according to an embodiment of the present specification.

[0022] FIG3 is a flow chart of a message processing method according to an embodiment of this specification.

[0023] FIG4 is a flow chart of another message processing method according to an embodiment of this specification.

[0024] FIG5 is a flow chart of another message processing method according to an embodiment of this specification.

[0025] FIG6 is a flowchart of another message processing method according to an embodiment of this specification.

[0026] FIG. 7 is a schematic diagram of state transitions of a session state machine according to an embodiment of this specification.

[0027] FIG8 is a schematic diagram of state transitions of a matching sub-state machine according to an embodiment of this specification.

[0028] FIG9 is a schematic diagram of functional modules of a message processing device provided according to an embodiment of this specification.

[0029] FIG10 is a schematic diagram of functional modules of another message processing device provided according to an embodiment of this specification.

[0030] FIG11 is a schematic structural diagram of an electronic device for message processing according to an embodiment of this specification. DETAILED DESCRIPTION

[0031] To make the objectives, technical solutions, and advantages of this specification more clear, the following will clearly and completely describe the technical solutions of this specification in conjunction with the specific embodiments of this specification and the corresponding drawings. Obviously, the embodiments described are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without making any creative efforts are within the scope of protection of this specification.

[0032] In addition, all actions of acquiring signals, information or data in this manual are performed in compliance with the relevant local data protection laws and policies and with the authorization of the corresponding device owner.

[0033] Unless there is any conflict, the features of the following embodiments and implementations may be combined with each other.

[0034] The technical solutions provided by the embodiments of this specification are described in detail below with reference to the accompanying drawings.

[0035] Figure 1 is a schematic diagram of the architecture of a system applicable to the message processing method provided in this specification. As shown in Figure 1, the system includes a user device 100 and a network device 200. Among them, the user device 100 includes multiple data processing units 110-1 to 110-N (hereinafter collectively referred to as data processing units 110) and a session management unit 120. In the mimetic security system, each data processing unit 110 can be a homogeneous executor or a heterogeneous executor. Each data processing unit 110 independently performs the same function, thereby serving as a redundant backup for each other. As for the network device 200 that establishes a TCP session with the user device 100, the network device 200 is not aware of the multiple data processing units 110 in the user device 100. Therefore, there is only one TCP session between the user device 100 and the network device 200, and the messages generated by the multiple data processing units 110 need to be normalized before being sent to the network device 200.

[0036] The data processing unit 110 can be any type of execution unit that can independently complete data processing tasks, such as a CPU, a container, a virtual machine, etc., which is well known to those skilled in the art, and this specification does not limit this. Specifically, in terms of hardware structure, the session management unit 120 is connected to the network device 200 through a network port, and is connected to each data processing unit 110 through a PCIe interface. The session management unit 120 normalizes the to-be-sent messages generated by each data processing unit 110 and sends them to the network device 200 via the established TCP session. Alternatively, the session management unit 120 copies the to-be-processed messages sent by the network device 200 and fills in the session information before distributing them to each data processing unit 110.

[0037] As shown in Figure 2, the session management unit 120 may include a message preprocessing unit 121 and a normalization processing unit 122. The normalization processing unit 122 includes a session management state machine 1221 and a read / write controller 1222. The message preprocessing unit 121 is used to parse the message input to the session management unit 120 (including the to-be-sent messages generated by the multiple data processing units 110 and / or the to-be-processed messages sent by the network device 200) to obtain the message header and message data. The session management state machine 1221 in the normalization processing unit 122 includes multiple different states. This allows the session management state machine 1221 to jump to multiple different states in sequence based on the message header and message data, thereby generating different control instructions. For example, the control instructions include at least an instruction for normalizing the message header. In addition, session management state machine 1221 can also send message read and write instructions to read / write controller 1222, so that read / write controller 1222 can read messages (to be sent or to be processed) from memory or write messages to memory. Based on the above-mentioned Direct Memory Access (DMA) mechanism, the fast storage and reading of normalized messages is achieved. This is completely hardware-controlled and driver-free. Compared with software implementations based on the Data Plane Development Kit (DPDK), it is faster, more efficient, and has higher space utilization.

[0038] For example, user device 100 is a computer operated by a user. Multiple CPUs are deployed in user device 100 as data processing units 110 to implement mimetic defense for inherent security. Network device 200 is the server that the user intends to access. When the user enters the access domain name through user device 100, each CPU deployed in user device 100 generates a message to be sent based on the access domain name. The message data of each message to be sent is generally the same, but the message headers are inconsistent. Each message to be sent enters session management unit 120 for normalization processing, resulting in a first target message that can be transmitted through the TCP session between user device 100 and network device 200. The first target message is then sent to network device 200. Network device 200 responds to the first target message by sending a response message to user device 100. User device 100 treats the response message returned by the network device as a message to be processed and inputs it into session management unit 120 for processing. After the session management unit 120 processes the unprocessed message, a second target message corresponding to each data processing unit 110 is obtained. Then, the session management unit 120 distributes each second target message to each data processing unit 100. At this point, the user equipment 100 and the network device 200 complete a session.

[0039] Based on the above hardware system architecture, this specification provides a message processing method. As shown in FIG3 , the message processing method is used to normalize messages sent from a user device to a network device, and includes the following steps S100 to S106 .

[0040] In step S100: obtaining the to-be-sent messages generated by the plurality of data processing units respectively.

[0041] As mentioned above, in actual applications, the network device is not aware that multiple data processing units are deployed in the user device. Therefore, only one TCP session is established between the network device and the user device. Since the TCP session is a point-to-point connection, there is no third party in a TCP session. In other words, in order to enable the to-be-sent messages generated by the multiple data processing units to be transmitted based on the TCP session between the user device and the network device, the message headers of the to-be-sent messages generated by the multiple data processing units need to be normalized. Otherwise, the session information carried in the message header is inconsistent with the session information of the TCP session, which will cause the to-be-sent messages generated by the data processing units to be unable to be transmitted based on the TCP session established between the network device and the user device.

[0042] To this end, after each data processing unit generates a message to be sent, it will first enter the session management unit for normalization processing and then be sent to the network device through the network port.

[0043] Furthermore, because different data processing units independently complete the same task, the to-be-sent messages generated by these units typically differ only in certain fields within the message header. In particular, if the message data of each to-be-sent message differs, there may be a risk that the user device is under attack or contains errors. In this case, it is necessary to determine the to-be-sent message with the correct message data using a decision-making method or other methods familiar to those skilled in the art, or to directly discard each to-be-sent message to prevent errors in the messages sent from the user device.

[0044] In step S102: the session management unit normalizes the message headers of the messages to be sent to obtain normalized message headers.

[0045] In this step, the session management unit can normalize several fields in the message header of each message to be sent based on the session information stored when the TCP session is established, so that the session information indicated by the normalized message header can be consistent with the session information of the established TCP session, so that the first target message constructed based on the normalized message header and message data can be transmitted based on the established TCP session.

[0046] Of course, the above solution assumes that the user device has already established a TCP session with the network device (i.e., has gone through the "three-way handshake" process) before normalizing each to-be-sent message. If this is the first time the user device is sending a message to the network device, the session management unit does not store session information that supports message header normalization. In this case, the session information of the to-be-established TCP session can be determined based on the message header of one of the to-be-processed messages generated by each data processing unit. Whether this is the first time the user device is sending a message to the network device can be determined by the value of a specified parameter (such as seq_delta) in the to-be-sent message.

[0047] In step S104: according to the normalized message header, a first target message corresponding to each of the messages to be sent is obtained.

[0048] Furthermore, the normalized message header is reassembled with each message to be sent to obtain the corresponding first target message. This is equivalent to replacing the original message header in each message to be sent with the normalized message header, or directly splicing the message data in each message to be sent with the normalized message header.

[0049] The first target message obtained in this step is a message that can be transmitted through the TCP session between the user equipment and the network device.

[0050] In step S106: each of the first target packets is sent to the network device through the established TCP session.

[0051] In the message processing method provided in this specification, a TCP session is established between a user device and a network device. When the data processing units in the network device generate messages to be sent respectively, the message headers of each message to be sent can be normalized by the session management unit to obtain a normalized message header, and the corresponding first target message can be obtained based on the normalized message header and each message to be sent.

[0052] Through the above scheme, the message headers contained in the messages to be sent generated by different data processing units are normalized, so that the first target message can be transmitted based on the TCP session between the user device and the network device, thereby realizing the TCP message transmission between the user device and the network device containing multiple data processing units in the mimetic security system, thereby improving the session security on the user device side.

[0053] In one or more embodiments of the present specification, step S102 described in FIG. 3 may include steps S200 to S206 as shown in FIG. 4 .

[0054] In step S200 , a target message is selected from each message to be sent, and a first field to be processed in a message header of the target message is determined. The first field to be processed includes a message identifier, a port identifier, and a sequence number.

[0055] As previously described, the purpose of normalizing the message header is to enable the first target message containing the normalized message header to be transmitted via an established TCP session. Therefore, in this specification, the fields in the message header that need to be normalized may be information indicating an established TCP session between a user device and a network device, such as a four-tuple containing a source port identifier, a source IP address, a destination port identifier, and a destination IP address. Furthermore, the first field to be processed may also include a message ID and sequence number indicating different messages. Of course, other fields may also be included, such as a window size and a checksum, but this specification does not limit this.

[0056] Based on this, in this specification, the message identifier, port identifier (especially the identifier of the source port) and sequence number in the message header are used as the first to-be-processed fields that need to be normalized.

[0057] In addition, optionally, the to-be-sent messages sent by different data processing units need to be matched, aligned, and other steps before normalization, and the matching, alignment, and other steps can be implemented through the session management state machine deployed in the session management unit. For details, please refer to the state jump scheme shown in the subsequent Figure 7, which will not be repeated here.

[0058] In step S202: the designated parameter corresponding to the target message is read from the session management unit, and it is determined whether the designated parameter is an initial value. If so, step S204 is executed; otherwise, step S206 is executed.

[0059] Furthermore, because the session management unit normalizes several fields in the message header of each to-be-sent message based on session information stored when the TCP session is established, it is necessary to extract a pre-stored target field from the session management unit as the first field to be processed after normalization. The target field includes fields extracted from the message header of a message sent by the user device when the TCP session is established. In other words, if the target message is generated by the data processing unit before the TCP session is established, the pre-stored target field does not exist in the session management unit, and normalization cannot be performed by extracting the target field from the session management unit.

[0060] Based on this, in this step, it can be determined whether the target packet is the first packet communicated between the user device and the network device. This determination can be based on the value of a specified parameter extracted from the packet header of the target packet. The specified parameter can be, for example, seq_delta.

[0061] If the value of the designated parameter is an initial value (e.g., 0), the target message is determined to be the first message sent by the user device to the network device. In this case, the session management unit does not store the target field. Instead, the first to-be-processed field of the target message can be directly used as the target field and stored in the session management unit.

[0062] If the value of the designated parameter is not the initial value, it is determined that the target message is not the first message sent by the user device to the network device. In this case, the session management unit stores the target field, and the first to-be-processed field after normalization can be determined based on the target field extracted from the session management unit.

[0063] In step S204 , the first to-be-processed field in the message header of the target message is stored in the session management unit as a target field, and the first to-be-processed field after normalization is determined according to the target field.

[0064] In step S206: according to the target field pre-stored in the session management unit, a first field to be processed after normalization is determined.

[0065] In practice, the target field pre-stored in the session management unit may be directly used as the first field to be processed after normalization, or the first field to be processed after normalization may be determined based on the target field and other parameters.

[0066] For example, when the first field to be processed is a sequence number, the above step S206 can be specifically implemented through the following steps.

[0067] Step 1: Update the designated parameters corresponding to the target message according to the payload length of the target message.

[0068] The sequence number in a TCP message is used to represent the message data portion of the TCP message. Each TCP message header contains a sequence number field that indicates the sequence number of the first byte in the TCP message. In subsequent messages, the sequence number will increment to indicate the sequence number of the first byte of the next message. The sequence number can help the recipient of the message distinguish between new and old messages, thereby avoiding data errors caused by retransmission of old messages. Therefore, when normalizing the sequence number in the message header contained in the message to be sent, it is necessary to determine it based on the payload length (payload_length) of the target message to achieve normal increment of the sequence number.

[0069] Specifically, the designated parameter corresponding to the target message is read. If the target message is generated for the first time by one of the multiple data processing units, the value of the designated parameter is the initial value. If the target message is not generated for the first time, the value of the designated parameter is not the initial value, and the designated parameter corresponding to the target message needs to be updated based on the payload length of the target message to obtain a new value of the designated parameter. Generally, the value of the designated parameter is determined based on the sum of the payload length of the generated message to be sent and the value of the unupdated designated parameter.

[0070] Step 2: Read the pre-stored target sequence number from the session management unit.

[0071] Step 3: According to the updated value of the designated parameter and the target sequence number, a new sequence number is obtained as the normalized sequence number.

[0072] The target sequence number read from the session management unit is actually the sequence number stored when the TCP session was established. During packet transmission, the sequence number in the packet header increments to indicate the next byte in the packet. Therefore, the normalized sequence number must also increment accordingly. Otherwise, sequence number errors and confusion will occur, making it difficult for the receiver to distinguish between old and new packets. Therefore, a new sequence number must be generated based on the updated value of the specified parameter and the target sequence number, serving as the normalized sequence number.

[0073] In one or more embodiments of this specification, in addition to normalizing the first field to be processed in the message header, normalizing may also be performed on the second field to be processed in the message header. The second field to be processed includes a sliding window, a maximum segment length, and a user timeout duration.

[0074] The first step: determining each second to-be-processed field from the message header of each to-be-sent message, wherein the second to-be-processed field includes a sliding window, a maximum message segment length, and a user timeout duration.

[0075] Step 2: Select the second to-be-processed field with the smallest value from the second to-be-processed fields as the normalized second to-be-processed field, and store it in the session management unit.

[0076] In TCP messages, a sliding window is used to represent the maximum receive buffer currently available to the message receiver. The message sender can adjust the amount of data sent based on the sliding window size, that is, adjust the sender's send window size so that the send window does not exceed the receiver's receive window size, thereby avoiding network congestion and ensuring communication stability. The Maximum Segment Size (MSS) is used to indicate the maximum data length that each TCP message can carry during communication between the sender and receiver. The User Timeout (UTO) is used to control how long unacknowledged data can be maintained. If the UTO is exceeded, the connection will be forcibly closed. Based on the functions implemented by the sliding window, MSS, and UTO respectively, it can be seen that all three are parameter fields used to limit the upper limit. If different to-be-sent messages generated by different data processing units have different second to-be-processed fields, the minimum value can be taken as the normalized second to-be-processed field.

[0077] Taking the UTO as an example, the UTOs of pending messages X1 and X2 are Y1 and Y2, respectively. Y1 is greater than Y2, indicating that packet X1 has a greater tolerance for message timeouts than packet X2. Suppose, in a current TCP session, after a user device sends a message to a network device, it waits for Y3 but still does not receive an acknowledgment from the network device. The actual timeout duration is determined to be Y3. If Y3 is greater than Y2 but less than Y1, the actual timeout duration Y3 has exceeded the UTO of pending message X2. At this point, packet X2 is considered unavailable due to the prolonged lack of an acknowledgment, but for packet X1, the actual timeout duration Y3 does not exceed the UTO of pending message X1. Therefore, the UTO of pending message X1 cannot be used to determine that the TCP session is unavailable. The principles of sliding window and MSS processing are similar to those of UTO and are not further explained. It can be seen that when normalizing the second to-be-processed field, the second to-be-processed field with the smallest value among the second to-be-processed fields of different to-be-transmitted messages needs to be normalized to meet the requirements of all to-be-transmitted messages.

[0078] Normalizing the unprocessed messages sent from the network device to the user device actually involves duplicating the original unprocessed messages and appending session information from different data processing units. Consequently, the second unprocessed field in the message headers of the messages distributed to different data processing units is duplicated. Therefore, normalization of the second unprocessed field is not performed in this process.

[0079] In addition, in an optional embodiment of the present specification, before executing step S102 shown in Figure 3, the to-be-sent messages generated by multiple data processing units are aligned and compared. That is, before performing the message header normalization processing, it is necessary to determine that each data processing unit in the user equipment has generated a message to be sent, each generated message to be sent has entered the session management unit for processing, and the message data of each message to be sent is the same.

[0080] Determining whether each data processing unit has generated a message to be sent and whether each generated message to be sent belongs to the session alignment process can be performed based on the session validity flag of each data processing unit in the session management unit. Specifically, if the session validity flag is 1, it indicates that the message to be sent by the corresponding data processing unit has been generated and has entered the session management unit for processing; conversely, if the session validity flag is 0, it indicates that the message to be sent by the corresponding data processing unit has not been generated or has been generated but has not entered the session management unit for processing. When the session validity flags of multiple data processing units are all 1, the sessions are aligned.

[0081] Furthermore, after the session alignment, a session comparison step can be performed, that is, determining whether there are differences between the message data of the to-be-sent messages generated by the multiple data processing units. Generally, since the message data is relatively long, a scheme of comparing the hash values ​​of the message data can be adopted. Specifically, if the hash values ​​of the message data of each to-be-sent message are the same, it means that the message data of each to-be-sent message is consistent, and a subsequent normalization processing step can be performed. If there is at least one message among the hash values ​​of the message data of each to-be-sent message that is inconsistent with the hash values ​​of the message data of other messages, it means that one or more of the multiple data processing units in the user device has an error. At this time, based on the mimetic security arbitration scheme, it can be determined which message data of the to-be-sent message has an error, and the to-be-sent message with the error can be discarded, and subsequent normalization processing can be performed based on the remaining to-be-sent messages. If it cannot be determined which message data of the to-be-sent message has an error, then all current to-be-sent messages can be discarded, so that each data processing unit regenerates the to-be-sent message.

[0082] In actual applications, before header normalization, in addition to the above-mentioned session alignment and session comparison, there may be multiple other session management links, such as session matching, session creation, and session decision. For details, please refer to the state transition scheme shown in Figure 7, which will not be described here.

[0083] In one or more embodiments of this specification, this specification provides a message processing method, as shown in FIG5 , for normalizing a message sent from a network device to a user device, including the following steps S300 to S306:

[0084] In step S300: a message to be processed sent by the network device through an established TCP session is received.

[0085] In step S302: extracting pre-stored session information of the plurality of data processing units from the session management unit.

[0086] As previously mentioned, because the network device is unaware of the multiple data processing units deployed in the user device, it sends only one pending message to the user device, not a message based on the number of data processing units. This requires the user device's session management unit to replicate the pending message sent by the network device, fill in the replicated pending message with the session information corresponding to the different data processing units, and then distribute it to the corresponding data processing unit.

[0087] In this step, the session information corresponding to each data processing unit is extracted from the session management unit. Generally, the user device is the active party in the TCP session. When the TCP session is established, the to-be-sent messages generated by each data processing unit carry the session information corresponding to each data processing unit. The session management unit can store the session information corresponding to each data processing unit when the TCP session is established so that it can process the to-be-sent messages sent by the network device.

[0088] The session information required for processing the message to be processed may include a message identifier, a port identifier, a sequence number, and the like.

[0089] In step S304 : second target messages corresponding to the plurality of data processing units are determined according to the session information of the plurality of data processing units and the messages to be processed.

[0090] Generally, the message to be processed is copied, and the session information corresponding to the multiple data processing units is filled into the corresponding fields of the message headers of the copied messages to be processed, so as to obtain the second target messages corresponding to the multiple data processing units. This can be achieved by the following steps:

[0091] Step 1: Copy the message to be processed according to the number of the multiple data processing units.

[0092] Step 2: extracting designated fields corresponding to the plurality of data processing units respectively from the session information of the plurality of data processing units, wherein the designated fields include a message identifier, a port identifier and a sequence number.

[0093] In actual applications, not all fields in the message header of the message to be processed need to be replaced. For example, fields such as the sliding window, MSS, and UTO do not need to be differentiated between different second target messages sent to different data processing units. Therefore, the specified fields to be filled in are extracted from the session information of multiple data processing units. The specified fields include the message identifier, port identifier (especially the source port identifier), and sequence number.

[0094] Step 3: Obtain second target messages corresponding to the multiple data processing units respectively according to the designated fields corresponding to the multiple data processing units respectively and the copied messages.

[0095] In step S306: each second target message is sent to the multiple data processing units respectively.

[0096] In the message processing method provided in this specification, session information of multiple data processing units is extracted from a session management unit, and based on the extracted session information and the messages to be processed sent by the network device through the established TCP session, the second target messages corresponding to each data processing unit are determined, and then each second target message is distributed to the corresponding data processing unit among the multiple data processing units.

[0097] Through the above solution, the network device sends a message to be processed, which is then processed by the session management unit to obtain the second target message corresponding to multiple data processing units. As a result, TCP message transmission between user devices containing multiple data processing units and network devices in the mimetic security system is achieved without the network device being aware of it, without the network device having to send messages with duplicate data, thereby improving the security and efficiency of TCP sessions.

[0098] In an optional embodiment of the present specification, in step S304 shown in FIG5 , when the sequence number in the session information of the data processing unit is entered into the copied message, since the sequence number continuously increases during message transmission, directly using the sequence number pre-stored in the session management unit is difficult to meet the requirements. Therefore, a new sequence number can be determined based on the payload length of the message to be processed and the sequence number of the data processing unit pre-stored in the session management unit before entering the new sequence number. Specific solutions may include the following:

[0099] Step 1: Determine the specified parameters and payload length of the message to be processed.

[0100] Step 2: Re-determine the designated parameters of the message to be processed according to the payload length of the message to be processed.

[0101] The designated parameter of the message to be processed indicates the number of times the message to be processed is sent by the network device in the TCP session. The payload length indicates the length of the message data in the message to be processed. Generally, the new designated parameter is determined based on the sum of the payload length of the message to be processed and the designated parameter of the message to be processed. The specific implementation scheme is similar to the specific implementation of step S206 described above when the first field to be processed is a sequence number, and will not be repeated here.

[0102] Step 3: re-determine the serial numbers corresponding to the multiple data processing units respectively according to the serial numbers corresponding to the multiple data processing units respectively and the re-determined designated parameters.

[0103] As previously described, the designated field is session information extracted from the session management unit and needs to be populated into the copied message. For each data processing unit, a new sequence number is determined based on the sequence number corresponding to the data processing unit and the updated designated parameters. This new sequence number is then populated into the copied message to obtain the second target message corresponding to the data processing unit.

[0104] Step 4: Fill the re-determined serial numbers corresponding to the multiple data processing units into each of the copied messages in sequence to obtain second target messages corresponding to the multiple data processing units.

[0105] In an optional embodiment of this specification, before executing step S304 shown in Figure 5, it is necessary to perform a session matching step based on the message to be processed to determine whether the message to be processed has no session timeout or sequence number error issues. This is specifically achieved through the following solution, as shown in Figure 6:

[0106] In step S400: determining the sequence number in the message header of the message to be processed, and obtaining the session timeout counter in the session management unit.

[0107] In step S402 : determine whether the sequence number in the message header of the message to be processed is incorrect. If so, execute step S404 ; otherwise, execute step S406 .

[0108] In step S404: discard the message to be processed.

[0109] If the sequence number corresponding to the pending message is incorrect, it may be that the network device is under attack or there is a packet loss problem during the transmission of the message. In this case, you can discard the pending message first and ask the network device to resend the correct message.

[0110] In step S406 , it is determined whether the TCP session corresponding to the to-be-processed message has timed out based on the session timeout counter. If so, step S408 is executed; otherwise, step S410 is executed.

[0111] In step S408: the TCP session corresponding to the message to be processed is deleted.

[0112] In a TCP session, if a message times out (a sent message goes unanswered for an extended period of time), a timeout retransmission is triggered. However, the number of times a message can be retransmitted after a timeout is generally limited. If the number of retransmissions exceeds the limit, the message will not be retransmitted. If multiple messages in a TCP session cannot be retransmitted, this indicates an error or problem with the TCP session. In this case, the TCP session can be deleted and a new one can be established.

[0113] In step S410 : second target messages corresponding to the plurality of data processing units are determined according to the session information of the plurality of data processing units and the messages to be processed.

[0114] Based on the solution shown in Figure 6, before determining the second target message based on the message to be processed and the session information of the data processing unit, it is necessary to confirm that there are no problems with the message to be processed itself and that there are no problems with the currently established TCP session. This not only ensures the security and reliability of TCP communication, but also improves communication efficiency.

[0115] Of course, in addition to the above-mentioned session matching, there may be multiple other session management links, such as session arbitration, session creation, session decision, etc. For details, please refer to the state jump solution shown in the subsequent Figure 7, which will not be described here.

[0116] In one or more embodiments of the present specification, a normalization processing unit 122 is deployed in the session management unit 120 shown in FIG2 , and the session management state machine 1221 in the normalization processing unit 122 can jump from the current state to another state under different conditions. As the session management state machine sequentially jumps to multiple different states, different control instructions can be generated to establish and maintain a TCP session, normalize the message header of a message to be sent (as shown in step S102 of FIG3 ), or reassemble the second target message (as shown in step S304 of FIG5 ). The states of the session management state machine include idle state, session arbitration state, session matching state, session creation state, session decision state, message discard state, session processing state, session alignment state, session comparison state, message selection state, session normalization state, session information update state, and session deletion state.

[0117] The following describes the process of the session management state machine jumping between multiple different states with reference to FIG7 , which may specifically include the following steps:

[0118] First state: When the user device is powered on, the session management state machine is initialized to the idle state, and the session node cache space is reset and initialized. The designated registers are reset, including at least the queue query flag register, the packet discard flag register, and the sequence number error flag register.

[0119] The session management state machine monitors the extraction of message headers, and in response to obtaining the message header of a message (message to be sent or message to be processed), jumps from the idle state to the session arbitration state.

[0120] Second state: When the session management state machine is in the session arbitration state, the transmission direction of the message (message to be sent or message to be processed) input to the session management unit is determined and recorded in the first designated register. The message transmission direction includes an uplink direction and a downlink direction. The uplink direction indicates that the network device transmits the message to the data processing unit in the user equipment via the session management unit, and the downlink direction indicates that the data processing unit in the user equipment transmits the message to the network device via the session management unit.

[0121] When it is determined that the transmission direction is recorded in the first designated register, the session management state machine jumps from the session arbitration state to the session matching state.

[0122] The third state: When the session management state machine is in the session matching state, it updates the queue query flag register, creates a session matching subprocess, and generates a matching request. The session matching subprocess implements session matching via the matching substate machine, which is initialized when the session management unit is powered on and in the idle state. The multiple states of the matching substate machine and their transition relationships are detailed in Figure 8.

[0123] As shown in Figure 8, in response to the match request, the matching sub-state machine jumps from the idle state to the match determination state. When in the match determination state, the matching sub-state machine determines whether the packet header is stored in the TCP session cache queue. If so, the match result is a match success; otherwise, the match result is a match failure. The matching sub-state machine returns the match result to the session management state machine.

[0124] In response to a matching result indicating a successful match, the session management state machine jumps from a session matching state to a session decision state.

[0125] In response to the matching result being a match failure, it is determined whether the message input into the session management unit meets the preset conditions. If so, the session management state machine jumps from the session matching state to the session creation state. If not, the session management state machine jumps from the session matching state to the message discarding state. The preset conditions are that the message type corresponding to the message input into the session management unit is SYN, and the transmission direction of the message input into the session management unit is a specified direction. The specified direction in the preset conditions can be determined according to the specific application scenario. For example, in a scenario where a user accesses a server, the user device is a computer operated by the user, the network device is a server that the user intends to access, and the user device is the party requesting to establish a TCP session. The specified direction in the preset conditions can be set to the downlink direction. In a scenario where a remote server remotely controls an unmanned driving device, the network device is a remote server, the user device is an unmanned driving device, and the network device is the party requesting to establish a TCP session. The specified direction in the preset conditions can be set to the uplink direction.

[0126] It should be noted that, in this specification, the message type corresponding to the message input into the session management unit may be one of SYN, ACK, PUSH, and FIN. Among them, when the message type is SYN, it indicates that the message is a message used to apply for establishing a TCP session. When the message type is ACK, it indicates that the message is a confirmation message used to confirm the previously received message. When the message type is PUSH, it indicates that the message is used to urge the message receiver to read the data from the TCP receive buffer as soon as possible. Usually, when the message sender determines that the TCP receive buffer of the message receiver is almost full based on the size of the sliding window of the message returned by the message receiver, it sends a message with a message type of PUSH, so that the message receiver reads the data from the TCP receive buffer as soon as possible. When the message type is FIN, it indicates that the message sender requests to disconnect the TCP session with the message receiver.

[0127] Therefore, when the session management state machine is in the session matching state, if the message type corresponding to the message input to the session management unit is SYN and the transmission direction of the message is the specified direction, it indicates that the message is sent by the party requesting to establish a TCP session in the current application scenario and is used to request to establish a TCP session. Based on this message, the session management state machine can jump from the session matching state to the session creation state to establish the TCP session between the network device and the user device.

[0128] The fourth state: When the session management state machine is in the session creation state, it applies to the dual-pool linked list management body for a new session cache node. After the application is successful, the message type and four-tuple information corresponding to the message input to the session management unit are recorded in the first memory space of the new session cache node, and the session timeout counter and output timeout counter are started in the second memory space of the session cache node. In addition, if the message is a message to be sent generated by the data processing unit, the corresponding data processing unit identifier (such as the execution body ID) will also be recorded in the second memory space. Among them, when the session management state machine is in the session creation state, the message type is SYN. ​​Afterwards, the session management state machine jumps from the session creation state to the session decision state.

[0129] Fifth state: When the session management state machine is in the session decision state, it executes a decision process similar to that of FIG6 . Specifically, based on the four-tuple information and sequence number in the message header, it is determined whether the message input to the session management unit has a sequence number error. If so, the session management state machine transitions from the session decision state to the message discard state. If not, the session management state machine transitions from the session decision state to the message discard state. If not, the session management state machine transitions from the session decision state to the session processing state.

[0130] The sixth state: When the session management state machine is in the session processing state, the message type is recorded in the first memory space of the session cache node. The message type recorded in the first memory space of the session cache node includes one of SYN, ACK, PUSH, and FIN. The message identifier, port identifier, sequence number, sliding window, maximum message segment length MSS, user timeout duration UTO, and message hash value in the message header are recorded in the second memory space of the session cache node, the session timeout counter and output timeout counter are reinitialized, and the session validity flag of the data processing unit corresponding to the message input to the session management unit is updated to a specified value (such as 1). The message input to the session management unit is stored in the third memory space of the session cache node. The session management state machine jumps from the session processing state to the session alignment state.

[0131] Seventh state: When the session management state machine is in the session alignment state, the session validity flags of the data processing units in the second memory space of the session cache node are read. If the session validity flags corresponding to the multiple data processing units are all specified values ​​(e.g., 1), it is determined that the messages to be sent by the multiple data processing units are aligned, and the session management state machine transitions from the session alignment state to the session comparison state. However, if at least one of the session validity flags corresponding to the multiple data processing units is not the specified value, it is determined that the messages to be sent by the multiple data processing units are not aligned, and the session management state machine transitions from the session alignment state to the idle state.

[0132] The eighth state: when the session management state machine is in the session comparison state, the message hash value of the message to be sent stored in the second memory space of the session cache node is read, and the message hash values ​​of the messages to be sent corresponding to the multiple data processing units are compared to obtain a message comparison result; in response to obtaining the message comparison result, the session management state machine jumps from the session comparison state to the message selection state.

[0133] Ninth state: When the session management state machine is in the message selection state, if the message comparison result is that the message hash values ​​of the messages to be sent corresponding to the multiple data processing units are all consistent, then the target data processing unit is selected from the multiple data processing units, and the identifier of the target data processing unit is determined, and the session management state machine jumps from the message selection state to the session normalization state; if the message comparison result is that the message hash values ​​of the messages to be sent corresponding to the multiple data processing units are not completely consistent, then the session management state machine jumps from the message selection state to the session deletion state.

[0134] Tenth State: When the session management state machine is in the Session Normalization state, a session normalization sub-process is initiated to normalize the message headers of messages to be sent, as specifically shown in FIG3 . Alternatively, the session normalization sub-process processes messages input to the session management unit to obtain second target messages corresponding to the multiple data processing units, as specifically shown in FIG5 . The output timeout counter is then reset, and the session management state machine transitions from the Session Normalization state to the Session Information Update state.

[0135] Eleventh state: when the session management state machine is in the session update state, the normalized message header is stored in the memory space of the session cache node, and the session management state machine jumps from the session update state to the idle state.

[0136] The twelfth state: when the session management state machine is in the message discarding state, the message discarding flag register is updated and the message input to the session management unit is discarded. In response to the message being discarded, the session management state machine jumps from the message discarding state to the idle state.

[0137] Thirteenth state: when the session management state machine is in the session deletion state, the memory space of the session cache node is cleared.

[0138] Since there are no session alignment, session comparison, and message selection steps when processing pending messages sent by the network device based on the session management state machine, the state of the session management state machine for pending messages sent by the network device can be shown as the dotted line in Figure 7; the state of the session management state machine for processing pending messages generated by the data processing unit can be shown as the solid line in Figure 7.

[0139] In addition, in this specification, the session management state machine is responsible for the entire life cycle of the TCP session normalization function, that is, from the input of the message into the session management unit to the output of the message by the session management unit, completing the jumps between the aforementioned multiple states such as session matching, new session, session comparison, message selection, session information update, message DMA access, session deletion, message discard, and message pass-through, thereby realizing the normalization of the messages to be processed or to be sent and maintaining the TCP session.

[0140] Among them, the session management state machine can realize hardware-fast TCP session management by adopting a dual-pool bidirectional linked list, that is, a bidirectional linked list plus a dual-pool mechanism. Specifically, a dual-pool linked list is set to manage the TCP session cache nodes, and the dual pools are respectively a used list (used_list) and a free list (free_list). Among them, the used list (used_list) maintains the used TCP session cache nodes, and the free list (free_list) maintains the reserved but unused TCP session cache nodes. The operation of the dual pools is a complementary relationship, that is, when a node is added to the used list (used_list), the free list (free_list) will reduce the nodes accordingly. In the TCP session normalization process, the insertion and deletion of the TCP session cache node will trigger the update of the head pointer phead and the tail pointer pend of the linked list node. The specific pointer update method can be any update method well known to those skilled in the art, and this manual is not limited to this.

[0141] The above is a message processing method provided in one or more embodiments of this specification. Based on the same idea, this specification also provides a corresponding message processing device, as shown in Figures 9 and 10.

[0142] FIG9 is a schematic diagram of a message processing device provided in this specification. The device is applied to a user device, and the user device establishes a TCP session with a network device. The user device includes a session management unit and multiple data processing units. As shown in FIG9 , the device includes: a message acquisition module 500 for acquiring messages to be sent generated by the multiple data processing units; a normalization module 502 for normalizing the message headers of each message to be sent through the session management unit to obtain a normalized message header; a first target message determination module 504 for obtaining a first target message corresponding to each message to be sent based on the normalized message header; and a first sending module 506 for sending each first target message to the network device through an established TCP session.

[0143] Optionally, the normalization module 502 is specifically used to: select a target message from each message to be sent, and determine a first to-be-processed field in the message header of the target message, where the first to-be-processed field includes a message identifier, a port identifier, and a sequence number; read a specified parameter corresponding to the target message from the session management unit, and determine whether the specified parameter is an initial value; if so, store the first to-be-processed field in the message header of the target message as a target field in the session management unit, and determine the first to-be-processed field after normalization based on the target field; if not, determine the first to-be-processed field after normalization based on the target field pre-stored in the session management unit.

[0144] Optionally, when the first field to be processed is a sequence number, the normalization module 502 is specifically used to: update the specified parameters corresponding to the target message according to the payload length of the target message; read the pre-stored target sequence number from the session management unit; and obtain a new sequence number as the normalized sequence number based on the updated specified parameters and the target sequence number.

[0145] Optionally, the normalization module 502 is specifically used to: determine each second to-be-processed field from the message header of each message to be sent, the second to-be-processed field including a sliding window, a maximum message segment length, and a user timeout duration; select the second to-be-processed field with the smallest value from each second to-be-processed field as the second to-be-processed field after normalization, and store it in the session management unit.

[0146] Optionally, the apparatus further includes a comparison module 508, specifically configured to determine whether the hash values ​​of the message data of each message to be sent are the same.

[0147] FIG10 is a schematic diagram of a message processing device provided in this specification. The device is applied to a user device, and the user device establishes a TCP session with a network device. The user device includes a session management unit and multiple data processing units. As shown in FIG10 , the device includes: a message receiving module 600 for receiving a message to be processed sent by the network device through an established TCP session; a session information extraction module 602 for extracting pre-stored session information of the multiple data processing units from the session management unit; a second target message determination module 604 for determining the second target messages corresponding to the multiple data processing units respectively based on the session information of the multiple data processing units and the message to be processed; and a second sending module 606 for sending each second target message to the multiple data processing units respectively.

[0148] Optionally, the second target message determination module 604 is specifically used to: copy the message to be processed according to the number of the multiple data processing units; extract the designated fields corresponding to the multiple data processing units from the session information of the multiple data processing units, the designated fields including the message identifier, port identifier and serial number; obtain the second target messages corresponding to the multiple data processing units respectively according to the designated fields corresponding to the multiple data processing units and each of the copied messages.

[0149] Optionally, when the designated field is a serial number, the second target message determination module 604 is specifically used to: determine the designated parameters and payload length of the message to be processed; redetermine the designated parameters of the message to be processed based on the payload length of the message to be processed; redetermine the serial numbers corresponding to the multiple data processing units respectively based on the serial numbers corresponding to the multiple data processing units and the redetermined designated parameters; fill the redetermined serial numbers corresponding to the multiple data processing units respectively into each of the copied messages in turn to obtain the second target messages corresponding to the multiple data processing units respectively.

[0150] Optionally, the second target message determination module 604 is specifically used to: determine the sequence number in the message header of the message to be processed; obtain the session timeout counter in the session management unit; if it is determined based on the sequence number in the message header of the message to be processed that there is no sequence number error in the message to be processed, and the session timeout counter indicates that there is no timeout for the TCP session, then determine the second target messages corresponding to the multiple data processing units respectively according to the session information of the multiple data processing units and the message to be processed.

[0151] This specification also provides a computer-readable storage medium on which a computer program is stored. The computer program can be used to execute the message processing method shown in Figures 3 and 5 above.

[0152] This specification also provides a schematic structural diagram of the electronic device shown in Figure 11. As shown in Figure 11, at the hardware level, the electronic device includes a processor, an internal bus, a network interface, a memory and a non-volatile memory, and of course may also include hardware required for other services. The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it to implement the message processing method shown in Figures 3 and 5 above. Of course, in addition to software implementation, this specification does not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc., that is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0153] In the 1990s, technological improvements could be clearly distinguished as either hardware improvements (for example, improvements to circuit structures like diodes, transistors, and switches) or software improvements (improvements to process flows). However, with the advancement of technology, many process flow improvements today can now be considered direct improvements to hardware circuit structures. Designers almost always create the corresponding hardware circuit structure by programming the improved process flow into the hardware circuit. Therefore, it cannot be said that a process flow improvement cannot be implemented using a hardware module. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA) or session management unit) is an integrated circuit whose logical function is determined by user programming. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to hire a chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly done using "logic compiler" software. This is similar to the software compiler used when developing programs. Before compilation, the original code must also be written in a specific programming language, called a hardware description language (HDL). There is not just one HDL, but many, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art will also understand that by simply programming the method flow in one of these hardware description languages ​​and then programming it into an integrated circuit, a hardware circuit that implements the logic method flow can be easily obtained.

[0154] The controller can be implemented in any suitable manner. For example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that in addition to implementing the controller in a purely computer-readable program code format, the controller can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the devices for implementing various functions can be considered as both software modules that implement the method and structures within the hardware component.

[0155] The systems, devices, modules, or units described in the above embodiments may be implemented by computer chips or physical devices, or by products having certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0156] For the convenience of description, the above devices are described as being divided into various units according to their functions. Of course, when implementing this specification, the functions of each unit can be implemented in the same or multiple software and / or hardware.

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

[0158] This specification is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of this specification. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes 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 produce a device for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0159] These computer program instructions may also be stored in a computer-readable memory that can direct 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 a product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0160] 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, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0161] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0162] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0163] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0164] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

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

[0166] This specification may be described in the general context of computer-executable instructions, such as program modules, executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. This specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media, including storage devices.

[0167] The various embodiments in this specification are described in a progressive manner. Similar parts between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences between the other embodiments. In particular, the system embodiments are generally similar to the method embodiments, so the description is relatively simple. For relevant parts, refer to the description of the method embodiments.

Claims

1. A message processing method, applied to a user device that establishes a TCP session with a network device, wherein the user device includes a session management unit and multiple data processing units, characterized in that: The method comprises: Obtaining the messages to be sent generated by the multiple data processing units respectively; Normalizing the message headers of the messages to be sent by the session management unit to obtain normalized message headers; Obtaining, according to the normalized message headers, a first target message corresponding to each of the messages to be sent; Each of the first target messages is sent to the network device through the established TCP session.

2. The method according to claim 1, wherein Normalizing the message headers of the messages to be sent by the session management unit to obtain the normalized message headers specifically includes: Selecting a target message from each of the messages to be sent, and determining a first to-be-processed field in a message header of the target message, wherein the first to-be-processed field includes a message identifier, a port identifier, and a sequence number; Reading a specified parameter corresponding to the target message from the session management unit, and determining whether the specified parameter is an initial value; If so, storing the first to-be-processed field in the message header of the target message as the target field in the session management unit, and determining the first to-be-processed field after normalization according to the target field; If not, a first field to be processed after normalization is determined according to the target field pre-stored in the session management unit.

3. The method according to claim 2, wherein When the first to-be-processed field is a sequence number, the session management unit reads a pre-stored target field to determine the first to-be-processed field after normalization, specifically including: Updating the specified parameters corresponding to the target message according to the payload length of the target message; Reading a pre-stored target sequence number from the session management unit; According to the updated designated parameters and the target sequence number, a new sequence number is obtained as the normalized sequence number.

4. The method according to claim 1, wherein Normalizing the message headers of the messages to be sent by the session management unit to obtain the normalized message headers specifically includes: Determining a corresponding second to-be-processed field from a message header of each to-be-sent message, where the second to-be-processed field includes a sliding window, a maximum segment length, and a user timeout duration; A second to-be-processed field with the smallest value is selected from each of the second to-be-processed fields as the second to-be-processed field after normalization processing, and is stored in the session management unit.

5. The method according to claim 1, wherein Before normalizing the message headers of the messages to be sent by the session management unit to obtain the normalized message headers, the method further includes: Determine that the hash values of the message data of each of the messages to be sent are the same.

6. A message processing method, applied to a user device that establishes a TCP session with a network device, wherein the user device includes a session management unit and multiple data processing units, characterized in that: The method comprises: receiving a message to be processed sent by the network device through the TCP session; extracting pre-stored session information of the plurality of data processing units from the session management unit; Determining second target messages corresponding to the plurality of data processing units respectively according to the session information of the plurality of data processing units and the messages to be processed; The second target messages are sent to the multiple data processing units respectively.

7. The method according to claim 6, wherein Determining, according to the session information of the multiple data processing units and the to-be-processed messages, the second target messages corresponding to the multiple data processing units respectively, specifically includes: Copying the message to be processed according to the number of the multiple data processing units; Extracting designated fields corresponding to the plurality of data processing units respectively from the session information of the plurality of data processing units, the designated fields including a message identifier, a port identifier and a sequence number; According to the designated fields respectively corresponding to the multiple data processing units and the copied messages, the second target messages respectively corresponding to the multiple data processing units are obtained.

8. The method according to claim 7, wherein When the designated field is a sequence number, obtaining second target messages corresponding to the plurality of data processing units respectively according to the designated fields corresponding to the plurality of data processing units and the respective copied messages specifically includes: Determining the specified parameters and payload length of the message to be processed; Re-determining the specified parameters of the message to be processed according to the payload length of the message to be processed; Re-determining the serial numbers corresponding to the multiple data processing units respectively according to the serial numbers corresponding to the multiple data processing units and the re-determined designated parameters; The re-determined serial numbers corresponding to the plurality of data processing units are sequentially filled into the copied messages to obtain second target messages corresponding to the plurality of data processing units.

9. The method according to claim 6, wherein Determining, according to the session information of the multiple data processing units and the to-be-processed messages, the second target messages corresponding to the multiple data processing units respectively, specifically includes: Determining a sequence number in a message header of the message to be processed; Get the session timeout counter in the session management unit; If it is determined based on the sequence number in the message header of the message to be processed that there is no sequence number error in the message to be processed, and the session timeout counter indicates that there is no timeout in the TCP session, then the second target messages corresponding to the multiple data processing units are determined based on the session information of the multiple data processing units and the message to be processed.

10. A message processing device, applied to a user equipment that establishes a TCP session with a network device, the user equipment comprising a session management unit and a plurality of data processing units, the device comprising: A message acquisition module to be sent, used to obtain the messages to be sent generated by the multiple data processing units respectively; a normalization module, configured to perform normalization processing on the message headers of the messages to be sent through the session management unit to obtain normalized message headers; A first target message determining module, configured to obtain a first target message corresponding to each of the to-be-sent messages according to the normalized message header; A first sending module is configured to send each of the first target packets to the network device through the TCP session.

11. The apparatus according to claim 10, further comprising: a message receiving module for receiving a message to be processed sent by the network device through the TCP session; A session information extraction module, configured to extract pre-stored session information of the plurality of data processing units from the session management unit; A second target message determining module, configured to determine second target messages corresponding to the plurality of data processing units respectively according to the session information of the plurality of data processing units and the messages to be processed; The second sending module is used to send each of the second target messages to the multiple data processing units respectively.

12. A computer-readable storage medium having a computer program stored thereon, wherein the computer program implements the method according to any one of claims 1 to 9 when executed by a processor.

13. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the method according to any one of claims 1 to 9 is implemented.

Images