Resource processing method and system of gateway device, electronic device and storage medium

CN122340167APending Publication Date: 2026-07-03CLOUD INTELLIGENCE ASSETS HOLDING (SINGAPORE) PTE LTD
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
CLOUD INTELLIGENCE ASSETS HOLDING (SINGAPORE) PTE LTD
Filing Date
2025-01-02
Publication Date
2026-07-03

Smart Images

  • Figure CN122340167A_ABST
    Figure CN122340167A_ABST
Patent Text Reader

Abstract

This application discloses a resource processing method, system, electronic device, and storage medium for a gateway device, relating to the fields of network protocols and communication technology. The method includes: detecting a message to be transmitted in the gateway device; determining the message category to which the message to be transmitted belongs, wherein the message category at least characterizes the scenario in which the message to be transmitted is transmitted in the gateway device; based on the message category, determining the state information of the session information to which the message to be transmitted belongs, wherein the session information has resources allocated during the operation of the gateway device, and the state information indicates whether the resources are allowed to be released under the message category; based on the state information, determining a resource release policy for the gateway device, wherein the resource release policy represents the rules for the gateway device to perform resource release operations on resources; and performing resource release operations on the resources according to the resource release policy. This application solves the technical problem of low resource release efficiency in gateway devices.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of network protocol and communication technology, and more specifically, to a resource processing method, system, electronic device, and storage medium for a gateway device. Background Technology

[0002] Currently, releasing resources allocated to the session information where the transmitted message resides is usually achieved by setting the session timeout.

[0003] In related technologies, the above method is typically used to release session-related resources for User Datagram Protocol (UDP) sessions. However, for Transmission Control Protocol (TCP), which is a stateful protocol, setting session timeouts to release resources results in low resource release efficiency for gateway devices.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides a resource processing method, system, electronic device, and storage medium for a gateway device, to at least solve the technical problem of low resource release efficiency in gateway devices.

[0006] According to one aspect of the embodiments of this application, a resource processing method for a gateway device is provided. The method may include: detecting a message to be transmitted in the gateway device; determining the message category to which the message to be transmitted belongs, wherein the message category is used to at least characterize the scenario in which the message to be transmitted is transmitted in the gateway device; determining, based on the message category, the state information of the session information to which the message to be transmitted resides, wherein the session information has resources allocated during the operation of the gateway device, and the state information is used to indicate whether the resources are allowed to be released under the message category; determining, based on the state information, a resource release policy of the gateway device, wherein the resource release policy is used to represent the rules by which the gateway device performs resource release operations on resources; and performing resource release operations on the resources according to the resource release policy.

[0007] According to another aspect of the embodiments of this application, a resource processing method for a gateway device is provided. The method may include: detecting a packet to be transmitted in a Network Address Translation (NAT) gateway device; determining the packet category to which the packet to be transmitted belongs, wherein the packet category is used to at least characterize the scenario in which the packet to be transmitted is transmitted in the NAT gateway device; determining, based on the packet category, the state information of the NAT session information to which the packet to be transmitted resides, wherein the NAT session information allocates NAT resources during the operation of the NAT gateway device, and the state information is used to indicate whether the NAT resources are allowed to be released under the packet category; determining, based on the state information, a resource release policy of the NAT gateway device, wherein the resource release policy is used to represent the rules for the NAT gateway device to perform resource release operations on NAT resources; and performing resource release operations on the NAT resources according to the resource release policy.

[0008] According to another aspect of the embodiments of this application, a resource processing method for a gateway device is provided. The method may include: detecting a message to be transmitted in the gateway device under a content delivery network; determining the message category to which the message to be transmitted belongs in the content delivery network, wherein the message category is used to at least characterize the scenario in which the message to be transmitted is transmitted in the content delivery network; determining, based on the message category, the state information of the session information to which the message to be transmitted belongs, wherein the session information has resources allocated during the operation of the gateway device, and the state information is used to indicate whether the resources are allowed to be released under the message category; determining, based on the state information, a resource release policy of the gateway device, wherein the resource release policy is used to represent the rules by which the gateway device performs resource release operations on resources; and performing resource release operations on the resources in the content delivery network according to the resource release policy.

[0009] According to another aspect of the embodiments of this application, a resource processing system for a gateway device is provided. The system may include: a communication end for generating a message to be transmitted; a gateway device for determining the message category to which the message to be transmitted belongs, wherein the message category is used to at least characterize the scenario in which the message to be transmitted is transmitted in the gateway device; determining, based on the message category, state information of the session information to which the message to be transmitted belongs, wherein the session information has resources allocated during the operation of the gateway device, and the state information is used to indicate whether the resources are allowed to be released under the message category; determining, based on the state information, a resource release policy of the gateway device, wherein the resource release policy is used to represent the rules by which the gateway device performs resource release operations on resources; and performing resource release operations on the resources according to the resource release policy.

[0010] According to another aspect of the embodiments of this application, an electronic device is also provided. The electronic device may include a memory and a processor: the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions. When the computer-executable instructions are executed by the processor, the resource processing method of the gateway device described above is implemented.

[0011] According to another aspect of the embodiments of this application, a processor is also provided, which is used to run a program, wherein the resource processing method of the gateway device described above is executed when the program is running.

[0012] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored program, wherein, when the program is running, it controls the device where the storage medium is located to execute the resource processing method of the gateway device described above.

[0013] According to another aspect of the embodiments of this application, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the resource processing method of the gateway device described above.

[0014] In this embodiment, a message to be transmitted in a gateway device is detected; the message category to which the message to be transmitted belongs is determined, wherein the message category is used to at least characterize the scenario in which the message to be transmitted is transmitted in the gateway device; based on the message category, the state information of the session information to which the message to be transmitted belongs is determined, wherein the session information is allocated resources during the operation of the gateway device, and the state information is used to indicate whether the resources are allowed to be released under the message category; based on the state information, a resource release policy of the gateway device is determined, wherein the resource release policy is used to represent the rules for the gateway device to perform resource release operations on resources; and resource release operations are performed on the resources according to the resource release policy. In other words, this embodiment determines the state information of the session information to which the message to be transmitted belongs by the message category in the gateway device, and then determines the resource release policy of the gateway device based on the state information to perform resource release operations on the resources, thereby achieving the purpose of improving resource utilization and thus realizing the technical effect of improving the resource release efficiency of the gateway device, solving the technical problem of low resource release efficiency of the gateway device.

[0015] It is worth noting that the general description above and the detailed description that follow are merely for illustrative purposes and do not constitute a limitation on this application. Attached Figure Description

[0016] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0017] Figure 1 This is a schematic diagram illustrating an application scenario of a resource processing method for a gateway device according to an embodiment of this application;

[0018] Figure 2 This is a flowchart of a resource processing method for a gateway device according to an embodiment of this application;

[0019] Figure 3 This is a schematic diagram of a state machine according to an embodiment of this application;

[0020] Figure 4 This is a flowchart illustrating the status tracking of receiving or sending a RESET message according to an embodiment of this application;

[0021] Figure 5 This is a schematic diagram of a four-way handshake process for actively initiating a FIN packet according to an embodiment of this application;

[0022] Figure 6 This is a schematic diagram illustrating the tracking of a four-way handshake process when a FIN message is actively initiated, according to an embodiment of this application.

[0023] Figure 7 This is a schematic diagram of a four-way handshake process for passively initiating a FIN message according to an embodiment of this application;

[0024] Figure 8 This is a schematic diagram illustrating the tracking of a four-way handshake process in the case of passively initiating a FIN message, according to an embodiment of this application.

[0025] Figure 9 This is a flowchart of another resource processing method for a gateway device according to an embodiment of this application;

[0026] Figure 10 This is a flowchart of another resource processing method for a gateway device according to an embodiment of this application;

[0027] Figure 11 This is a schematic diagram of a resource processing system for a gateway device according to an embodiment of this application;

[0028] Figure 12 This is a structural block diagram of the computing environment of a resource processing method for a gateway device according to an embodiment of this application;

[0029] Figure 13 This is a schematic diagram of a resource processing apparatus for a gateway device according to an embodiment of this application;

[0030] Figure 14 This is a schematic diagram of a resource processing apparatus for another gateway device according to an embodiment of this application;

[0031] Figure 15 This is a schematic diagram of a resource processing apparatus for a gateway device according to an embodiment of this application;

[0032] Figure 16 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0033] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0034] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0035] First, some nouns or terms that appear in the description of the embodiments of this application shall be interpreted as follows:

[0036] Network Address Translation (NAT) is a network technology that enables communication with the public internet within a private network using private Internet Protocol (IP) addresses. NAT allows devices on an internal network to access the internet using one or a few public IP addresses, while simultaneously allowing internal devices to use private IP addresses. This conserves public IP address resources and improves the flexibility of address allocation.

[0037] Resource reclamation refers to releasing the memory, IP, and port resources consumed by NAT sessions.

[0038] The Transmission Control Protocol (TCP) requires establishing a virtual connection (through a three-way handshake) before data transmission, exchanging data on that connection, and finally closing the connection through a four-way handshake.

[0039] The three-way handshake, the process of establishing a TCP connection, involves the exchange of three data packets between the two parties to synchronize their initial sequence numbers and confirm that both parties are ready to transmit data.

[0040] The four-way handshake, the process of closing a TCP connection, involves the exchange of four data packets to ensure that both parties can properly terminate the connection.

[0041] The resource processing method for the gateway device provided in this application embodiment can be applied to, for example, Figure 1 The application scenarios shown are not limited to these. Figure 1 This is a schematic diagram illustrating an application scenario of a resource processing method for a gateway device according to an embodiment of this application. Figure 1 In the application scenario shown, the server 10 can be in the cloud. The server 10 can connect to one or more client devices 20 via a local area network (LAN), wide area network (WAN), internet connection, or other types of data network. These client devices 20 can include, but are not limited to, smartphones, tablets, laptops, PDAs, personal computers, smart home devices, and in-vehicle devices. These client devices collectively constitute the client relative to the server. An operation interface for obtaining messages to be transmitted from the gateway device can be deployed on the graphical user interface of the client device. The client device 20 can interact with the user through the graphical user interface to implement the resource processing method for the gateway device provided in this embodiment.

[0042] In this embodiment, the system consisting of client device 20 and server 10 can perform the following steps: The client device 20 can perform corresponding operations on its interface to obtain a message to be transmitted from the gateway device. The client device can obtain the message to be transmitted and send it to the server via the network. After receiving the message to be transmitted, the server can perform the following steps: Step S102, detect the message to be transmitted from the gateway device; Step S104, determine the message category to which the message to be transmitted belongs, wherein the message category is used to at least characterize the scenario in which the message to be transmitted is transmitted in the gateway device; Step S106, based on the message category, determine the status information of the session information where the message to be transmitted is located, wherein the session information has resources allocated during the operation of the gateway device, and the status information is used to indicate whether the resources are allowed to be released under the message category; Step S108, based on the status information, determine the resource release policy of the gateway device, wherein the resource release policy is used to represent the rules for the gateway device to perform resource release operations on resources; Step S110, perform resource release operations on the resources according to the resource release policy.

[0043] Under the aforementioned operating environment, this application provides the following: Figure 2 The resource processing method of the gateway device shown. Figure 2 This is a flowchart of a resource processing method for a gateway device according to an embodiment of this application, such as... Figure 2 As shown, the method may include the following steps:

[0044] Step S202: Detect the message to be transmitted in the gateway device.

[0045] In the technical solution provided in step S202 of this application, the message to be transmitted in the gateway device can be detected. The gateway device can be a device used to connect different networks and can be used to implement data forwarding and conversion between different networks. For example, the gateway device can be a router, switch, NAT gateway, etc. This is only an example and does not impose specific limitations on the type of gateway device.

[0046] In this embodiment, the message to be transmitted can be a data unit from the source device to the destination device in network communication. For example, the message to be transmitted can be a TCP message. This TCP message can be a data unit used by TCP for data transmission in the network, and can include a TCP protocol header and a data portion. It can be used to transmit data in the network and ensure the reliability and orderliness of the data. This is only an example and does not impose specific limitations on the type of message to be transmitted.

[0047] Optionally, for scenarios where the message to be transmitted is being transmitted in the gateway device, the message to be transmitted in the gateway device can be detected. For example, for scenarios where the TCP transport layer receives TCP messages, the received TCP messages can be detected at the TCP transport layer; for scenarios where the TCP transport layer sends TCP messages, the sent TCP messages can be detected at the TCP transport layer; for scenarios where a TCP handshake is actively initiated to close the connection, the TCP messages received during the first handshake of the four-way handshake process can be detected; for scenarios where a TCP handshake is passively initiated to close the connection, the TCP messages sent during the first handshake of the four-way handshake process can be detected.

[0048] Step S204: Determine the message category to which the message to be transmitted belongs.

[0049] In the technical solution provided in step S204 of this application, after detecting the message to be transmitted in the gateway device, the message category to which the message to be transmitted belongs can be determined. The message category can include at least Synchronize (SYN), Synchronize Acknowledgement (SYNACK), Acknowledgement (ACK), Reset, Finish (FIN), and Finish Acknowledgement (FINACK). Specifically, the SYN message category can be used to indicate a request to establish a connection, the SYNACK message category can be used to indicate confirmation of the request to establish a connection, the ACK message category can be used to indicate confirmation of received data, the RESET message category can be used to indicate forced closure of the connection, the FIN message category can be used to indicate that the sender has completed sending data, and the FINACK message category can be used to indicate confirmation of termination of the connection.

[0050] In this embodiment, the message type can be used to at least characterize the scenario in which the message to be transmitted is transmitted in the gateway device. For example, the scenario can include at least: when the TCP transport layer receives a RESET message, the TCP layer will close the TCP connection; when the TCP transport layer sends a RESET message, the transport layer has already closed the TCP connection; actively initiating a TCP handshake to close, and after completing the four-way handshake, the TCP layer will close the TCP connection; passively initiating a TCP handshake to close, and after completing the four-way handshake, the TCP layer will close the TCP connection, etc.

[0051] Optionally, after detecting the message to be transmitted in the gateway device, the content of the message header can be obtained by reading the field corresponding to the message header in the gateway device. Since the content of the message header contains information about different types of messages, the message category to which the message to be transmitted belongs can be determined.

[0052] For example, when the gateway device is a NAT gateway and the message to be transmitted is a TCP message, the message type of the TCP message to be transmitted can be determined by reading the fields corresponding to the header of the TCP message to be transmitted in the NAT gateway.

[0053] Step S206: Determine the status information of the session information where the message to be transmitted belongs based on the message type.

[0054] In the technical solution provided by step S206 of this application, after determining the message category to which the message to be transmitted belongs, the status information of the session information to which the message to be transmitted belongs can be determined based on the determined message category. The session information is allocated resources during the operation of the gateway device. For example, the session information of a NAT gateway can be represented as a NAT session, and these resources can be memory resources, IP resources, and PORT resources consumed by the NAT session.

[0055] In this embodiment, the status information can be used to indicate whether the resource is allowed to be released under the packet category. The status information can include at least allowed release status information and prohibited release status information. For example, allowed release status information can be represented by the TCP_CT_OPEN status, and prohibited release status information can be represented by the TCP_CT_CLOSED status.

[0056] Optionally, after determining the message category to which the message to be transmitted belongs, in order to maintain the state tracking of the TCP stream (e.g., a reliable and ordered bidirectional byte stream transmission channel established by the TCP protocol), a state machine can be developed, and then the state information such as the TCP_CT_OPEN state and TCP_CT_CLOSED state of the NAT session can be determined in the state machine.

[0057] It should be noted that this state machine can at least be used to track the state information of NAT sessions, and thus take different actions for different state information. For example, for the TCP_CT_OPEN state of a NAT session, the action of continuing to track can be taken; for the TCP_CT_CLOSED state of a NAT session, the action of releasing the resources allocated for the NAT session can be taken.

[0058] Step S208: Based on the status information, determine the resource release strategy for the gateway device.

[0059] In the technical solution provided in step S208 of this application, after determining the state information of the session information where the message to be transmitted belongs based on the message type, the resource release policy of the gateway device can be determined based on the determined state information. The resource release policy can be used to represent the rules by which the gateway device will perform resource release operations on resources; for example, the resource release operation can be a release action or a disposal action at the TCP transport layer.

[0060] In this embodiment, after determining the state information of the NAT session in the state machine, when the state information is TCP_CT_CLOSED, the resource release strategy can be to perform resource release operation after the quiet period. The quiet period can be dynamically adjusted according to actual needs. For example, the quiet period can be 1 second (s). This is only an example and no specific limit is made on the duration of the quiet period.

[0061] Optionally, the above resource release strategy can also be implemented such that after determining that the NAT session's state information is TCP_CT_CLOSED, that is, during the NAT session's quiet period, if an anomaly is detected (e.g., a judgment error), the NAT session's state information can be changed from TCP_CT_CLOSED to TCP_CT_OPEN, in order to minimize the probability of misjudging the NAT session's state information.

[0062] Optionally, the above resource release strategy can also be implemented such that after determining that the NAT session's state information is TCP_CT_CLOSED, that is, during the NAT session's quiet period, if new data is received, the NAT session's state information is reset to TCP_CT_OPEN to avoid the problem of new data not being able to be transmitted normally.

[0063] Step S210: Perform resource release operation on the resource according to the resource release strategy.

[0064] In the technical solution provided by step S210 of this application, after determining the resource release strategy of the gateway device based on the status information, the resource release operation can be performed on the resource according to the determined resource release strategy.

[0065] For example, after completing the four-way handshake process for a TCP connection, the corresponding NAT session's state is immediately set to TCP_CT_CLOSED, indicating that the connection has been officially closed. A short period of silence is then set to monitor for new data packets. If no new data arrives, the connection is considered truly terminated. After the silence period ends, resources associated with the NAT session are officially released, such as IP resources and port allocations, ensuring that inactive connections do not occupy valuable system resources for extended periods.

[0066] This embodiment releases unused resources at appropriate times (e.g., after a quiet period following connection closure) according to a resource release strategy, which can avoid resource waste and improve resource utilization.

[0067] Through steps S202 to S210 of this application, the message to be transmitted in the gateway device is detected; the message category to which the message to be transmitted belongs is determined, wherein the message category is used to at least characterize the scenario in which the message to be transmitted is transmitted in the gateway device; based on the message category, the status information of the session information to which the message to be transmitted belongs is determined, wherein the session information is allocated resources during the operation of the gateway device, and the status information is used to indicate whether the resources are allowed to be released under the message category; based on the status information, the resource release policy of the gateway device is determined, wherein the resource release policy is used to indicate the rules for the gateway device to perform resource release operations on resources; and the resource release operation is performed on the resources according to the resource release policy. In other words, the embodiments of this application determine the status information of the session information to which the message to be transmitted belongs in the gateway device by the message category to which the message to be transmitted belongs, and then determine the resource release policy of the gateway device based on the status information to perform resource release operations on the resources, thereby achieving the purpose of improving resource utilization and realizing the technical effect of improving the resource release efficiency of the gateway device, thus solving the technical problem of low resource release efficiency of the gateway device.

[0068] The method described in this embodiment will be further described below.

[0069] As an optional implementation, step S202, determining the state information of the session information where the message to be transmitted belongs based on the message type, includes: determining the state information of the session information in the state machine based on the message type, wherein the state machine includes initial state information and closed state information, the initial state information is used to indicate the state in which the resource is allowed to be used under the message type, and the closed state information is used to indicate the state in which the resource is allowed to be released in the future time period under the message type.

[0070] In this embodiment, the state machine can be a programming design pattern used to manage multiple states of session information and the transitions between states. It is applicable to stateful protocols; for example, a TCP state machine can provide a structured method for the lifecycle of a TCP connection and the reclamation of NAT sessions within a NAT gateway. The state machine can include initial state information and closing state information. The initial state information can be used to indicate the state in which a resource is allowed to be used under a packet class; for example, the initial state information can be represented by the TCP_CT_OPEN state. The closing state information can be used to indicate the state in which a resource is allowed to be released in a future time period under a packet class; for example, the closing state information can be represented by the TCP_CT_CLOSED state. Optionally, the TCP_CT_CLOSED state can be used to indicate that a NAT session can be released in a future time period (in the near future).

[0071] Optionally, in order to maintain the state tracking of the TCP stream, Figure 3 This is a schematic diagram of a state machine according to an embodiment of this application, such as... Figure 3 As shown, the state machine can include the TCP_CT_OPEN state and the TCP_CT_CLOSED state. The TCP_CT_OPEN state can be used to represent the initial state of the TCP stream, and the TCP_CT_CLOSED state can be used to indicate that a NAT session has been determined to be ready for release.

[0072] Optionally, the state information of the NAT session can be determined through a state machine. When the state information of the NAT session is TCP_CT_OPEN, the NAT gateway will allocate necessary resources (such as port resources) for the NAT session. When the state information of the NAT session is TCP_CT_CLOSED, the resources allocated to the NAT session can be released, thereby improving resource utilization efficiency.

[0073] This embodiment uses a state machine to determine and manage the TCP_CT_OPEN and TCP_CT_CLOSED states of a NAT session, which can effectively improve the performance, security, and reliability of the NAT gateway.

[0074] As an optional implementation, the state information of the session information is determined in the state machine based on the message type, including: in response to the message type being a reset message type, the state information of the session information is set from the initial state information to the closed state information in the state machine; or, in response to the message type being a non-reset message type, the state information of the session information is set from the closed state information to the initial state information in the state machine.

[0075] In this embodiment, the RESET message type can be used to forcibly close a TCP connection. Non-RESET message types can be any message type other than RESET, such as SYN, SYNACK, ACK, FIN, FINACK, etc.

[0076] Optionally, when the message type is RESET message type, i.e., when a RESET message has been received or sent, such as Figure 3 As shown, the NAT session state information can be changed from TCP_CT_OPEN to TCP_CT_CLOSED. This occurs when the packet type is not a reset packet type, for example, when a new packet is received. Figure 3 As shown, the NAT session state information can be changed from TCP_CT_CLOSED to TCP_CT_OPEN.

[0077] Optionally, when the message type is RESET, that is, when a RESET message is detected, it indicates that the TCP connection may have terminated abnormally or is no longer needed. In this case, marking the NAT session from the TCP_CT_OPEN state to the TCP_CT_CLOSED state can enable the NAT gateway to release the resources associated with the TCP connection (such as port resources) in a timely manner, thereby avoiding resource waste.

[0078] Optionally, when the message type is a non-reset message type, such as when a new valid data packet is received, the NAT session can be marked from the TCP_CT_CLOSED state to the TCP_CT_OPEN state. This allows the NAT gateway to quickly adapt to possible misjudgments or special situations, ensuring that legitimate data flows are not blocked due to incorrect state judgments.

[0079] This embodiment enhances security and ensures the effective use of resources by accurately tracking changes in the state information of NAT sessions, enabling the NAT gateway to take appropriate measures for different state information.

[0080] As an optional implementation, during the waiting period after the session information status information is set from initial status information to closed status information, the resource is allowed to be used under the message category, and the waiting period is before a future period. The method further includes: during the waiting period, in response to receiving a new message, in the state machine, setting the session information status information from closed status information to initial status information, and identifying the new message as a message to be transmitted.

[0081] In this embodiment, the waiting period can be a time period set according to actual needs, and the waiting period can be dynamically adjusted according to actual needs to improve resource utilization efficiency and avoid wasting memory. The waiting period can also be called a quiet period. For example, the waiting period can be 1 second, which can be adjusted to a shorter time according to actual needs, or when the gateway memory is low, the waiting period can be adjusted to a longer time. This is only an example for illustration, and no specific limit is made on the length of the waiting period.

[0082] Optionally, after setting the NAT session's state from TCP_CT_OPEN to TCP_CT_CLOSED, a quiet period (waiting period) can be pre-set. During this quiet period, resources allocated to the NAT session can be used, and the NAT session is only truly released after the quiet period ends.

[0083] For example, after setting the NAT session state from TCP_CT_OPEN to TCP_CT_CLOSED, if an anomaly is detected (e.g., a misjudgment), the NAT session state can be set back from TCP_CT_CLOSED to TCP_CT_OPEN. For instance, after receiving or sending a RESET message and setting the NAT session state to TCP_CT_CLOSED, if new data (new packets) is received during the NAT session's quiet period, the NAT session state should be reset to TCP_CT_OPEN to minimize the probability of misjudgment.

[0084] Optionally, after receiving a new message, the received new message can be identified as a TCP message to be transmitted, and the step of determining the message category to which the TCP message to be transmitted belongs can be returned to continue the detection and status tracking of the new message.

[0085] This embodiment provides a buffer period by setting a quiet period before actually releasing the NAT session, allowing for confirmation that the TCP connection has indeed terminated. If a new packet is received during the quiet period, the previous assessment can be considered incorrect, and the NAT session's state information can be restored to TCP_CT_OPEN. This helps avoid premature resource release due to brief network delays or other abnormal situations.

[0086] As an optional implementation, step S208, determining the resource release strategy of the gateway device based on the status information, includes: in response to the status information remaining closed during the waiting period, determining the resource release strategy of the gateway device.

[0087] In this embodiment, if no anomalies (e.g., judgment errors) or new packets are detected during the quiet period, and the NAT session state information remains in the TCP_CT_CLOSED state, then it can be determined that the NAT gateway's resource release strategy is to release the relevant resources allocated to the NAT session after the quiet period, thereby improving resource utilization efficiency.

[0088] Alternatively, by accurately reclaiming unused resources, the memory footprint of the NAT gateway can be significantly reduced, allowing the NAT gateway to handle more valid connections, thereby improving overall performance and scalability.

[0089] This implementation ensures that the NAT gateway can quickly identify inactive TCP connections and immediately release the resources allocated to the NAT session, thereby helping to improve resource utilization efficiency and avoid resource waste, especially in high-concurrency environments.

[0090] As an optional implementation, step S202, detecting the message to be transmitted in the gateway device, includes: detecting the received message to be transmitted at the transport layer of the gateway device; in response to the message type being a reset message type, setting the session information status information from the initial status information to the closed status information in the state machine, including: in response to the received message type being a reset message type, setting the session information status information from the initial status information to the closed status information in the state machine.

[0091] In this embodiment, the transport layer of the gateway device can be a service layer responsible for end-to-end communication in the network protocol stack. It can be used to ensure reliable and orderly transmission of data between the source and destination, and provide flow control and error detection functions. For example, the transport layer of the gateway device can be the TCP transport layer.

[0092] It should be noted that when a RESET message is received, the TCP transport layer sets the TCP connection to the TCP_CT_CLOSED state and reclaims the resources associated with the TCP connection after the quiet period.

[0093] Optionally, Figure 4 This is a flowchart illustrating the status tracking of receiving or sending a RESET message according to an embodiment of this application, such as... Figure 4 As shown, the status tracking process for receiving RESET messages can include at least the following steps:

[0094] Step S401: Receive message.

[0095] In the above steps, packets can be received in the receive (IN) direction of the NAT gateway.

[0096] Step S402: Is it a RESET message?

[0097] In the above steps, if a message is detected, it can be determined whether the received message is a RESET message. If the received message is a RESET message, proceed to step S403; otherwise, proceed to step S404.

[0098] Step S403: Set the NAT session to TCP_CT_CLOSED state and enter the silent period.

[0099] In the above steps, if the received message is a RESET message, the NAT session status information can be set to TCP_CT_CLOSED, indicating that the resources allocated for the NAT session can be released in the future.

[0100] Optionally, while setting the NAT session's state information to the TCP_CT_CLOSED state, the NAT session can be controlled to enter a silent period. During the silent period, if the NAT session receives any new data packets, the previous state flag of the NAT session is cleared, and the NAT session's state information is reset to the TCP_CT_OPEN state to continue new packet detection and state tracking.

[0101] This embodiment addresses the scenario where the TCP transport layer closes the TCP connection when it receives a RESET message. When the NAT gateway detects the receipt of a RESET message, it sets the NAT session status information to TCP_CT_CLOSED, which can promptly release the resources occupied by inactive connections and improve resource utilization. For example, in a high-concurrency environment, it can support more active connections.

[0102] As an optional implementation, in response to the message type being a non-reset message type, the state information of the session information is set from closed state information to initial state information in the state machine, including: in response to the message type of the received message to be transmitted being a non-reset message type, and the state information of the session information being set to closed state information in the state machine, the state information of the session information is set from closed state information to initial state information.

[0103] In this embodiment, when the detected received packet is a non-reset packet type (i.e., not a RESET packet), and the NAT session state information has already been set to TCP_CT_CLOSED due to RESET, the NAT session state information is changed from TCP_CT_CLOSED to TCP_CT_OPEN to prevent misjudgment and ensure the accuracy of the connection state. Figure 4 As shown:

[0104] Step S404: Is the NAT session set to the TCP_CT_CLOSED state due to RESET?

[0105] In the above steps, it is determined whether the NAT session has been set to the TCP_CT_CLOSED state due to RESET. If the NAT session has been set to the TCP_CT_CLOSED state due to RESET, proceed to step S405; otherwise, proceed to step S406.

[0106] Step S405: Set the NAT session to TCP_CT_OPEN state.

[0107] In the above steps, if the received packet is not a RESET packet and the NAT session has been set to the TCP_CT_CLOSED state due to RESET, then the NAT session's state information can be set to the TCP_CT_OPEN state.

[0108] Step S406, continue state tracking.

[0109] In the above steps, if the received packet is not a RESET packet and the NAT session state information is not set to TCP_CT_CLOSED due to RESET, it indicates that the NAT session state information is TCP_CT_OPEN, and the tracking of the NAT session state information continues.

[0110] In this embodiment, if the NAT session state information is incorrectly marked as TCP_CT_CLOSED (for example, due to a temporary network problem causing the RESET message to be received incorrectly), but the connection is actually still active and has subsequent data transmission needs, then restoring the NAT session state information to TCP_CT_OPEN can avoid the problem of the valid connection being closed prematurely and resources being released due to misjudgment.

[0111] As an optional implementation, step S202, detecting the message to be transmitted in the gateway device, includes: detecting the sent message to be transmitted at the transport layer of the gateway device; in response to the message type being a reset message type, setting the session information status information from the initial status information to the closed status information in the state machine, including: in response to the message type of the sent message to be transmitted being a reset message type, setting the session information status information from the initial status information to the closed status information in the state machine.

[0112] It should be noted that when a RESET message is sent, the TCP transport layer will still set the TCP connection to the TCP_CT_CLOSED state and reclaim the resources associated with the TCP connection after the quiet period.

[0113] In this embodiment, if a sent packet is detected in the NAT gateway's outgoing direction, and the sent packet is a RESET packet, the NAT session's state information can be set to TCP_CT_CLOSED, indicating that the resources allocated for the NAT session can be released in the future. Figure 4 As shown:

[0114] Step S407: Send the message.

[0115] In the above steps, packets can be sent in the out direction of the NAT gateway.

[0116] Step S408: Is it a RESET message?

[0117] In the above steps, if a sent message is detected, it can be determined whether the sent message is a RESET message. If the sent message is a RESET message, proceed to step S403; otherwise, proceed to step S409.

[0118] Optionally, while setting the NAT session's state information to the TCP_CT_CLOSED state, the NAT session can be controlled to enter a silent period. During the silent period, if the NAT session receives any new data packets, the previous state flag of the NAT session is cleared, and the NAT session's state information is reset to the TCP_CT_OPEN state to continue new packet detection and state tracking.

[0119] This embodiment addresses the scenario where the TCP transport layer has already closed the TCP connection when it sends a RESET message. When the NAT gateway detects the sending of a RESET message, it sets the NAT session status information to TCP_CT_CLOSED, thereby improving resource utilization.

[0120] As an optional implementation, in response to the message type being a non-reset message type, the state information of the session information is set from closed state information to initial state information in the state machine, including: in response to the message type of the sent message to be transmitted being a non-reset message type, and the state information of the session information being set to closed state information in the state machine, the state information of the session information is set from closed state information to initial state information.

[0121] In this embodiment, when the detected sent packet type is a non-reset packet type (i.e., not a RESET packet), and the NAT session state information has already been set to TCP_CT_CLOSED due to RESET, the NAT session state information is changed from TCP_CT_CLOSED to TCP_CT_OPEN to prevent misjudgment and ensure the accuracy of the connection state. Figure 4 As shown:

[0122] Step S409: Is the NAT session set to the TCP_CT_CLOSED state due to RESET?

[0123] In the above steps, it is determined whether the NAT session has been set to the TCP_CT_CLOSED state due to RESET. If the NAT session has been set to the TCP_CT_CLOSED state due to RESET, proceed to step S405; otherwise, proceed to step S410.

[0124] Step S410: Continue status tracking.

[0125] In the above steps, if the detected sent packet is not a RESET packet, and the NAT session state information is not set to TCP_CT_CLOSED due to RESET, it indicates that the NAT session state information is TCP_CT_OPEN, and the tracking of the NAT session state information continues.

[0126] In this embodiment, if the NAT session state information is incorrectly marked as TCP_CT_CLOSED (for example, due to a temporary network problem causing the RESET message to be received incorrectly), but the connection is actually still active and has subsequent data transmission needs, then restoring the NAT session state information to TCP_CT_OPEN can avoid the problem of the valid connection being closed prematurely and resources being released due to misjudgment.

[0127] As an optional implementation, the state information of the session information is determined in the state machine based on the message type, including: in response to the message type being a termination message type, the state information of the session information is set from the initial state information to the closed state information in the state machine.

[0128] In this embodiment, the FIN message category can be a special type of message that initiates the TCP connection termination process. It can be used to indicate that the sender has finished sending data and wants to close the data flow in that direction, but can still receive data from the other party until the other party also sends a FIN message.

[0129] Optionally, when the message type is a FIN message type, for example, when actively initiating a TCP handshake to close the connection and completing the four-way handshake before the TCP transport layer closes the TCP connection, or when passively initiating a TCP handshake to close the connection and completing the four-way handshake before the TCP transport layer closes the TCP connection, the NAT session state information can be changed from TCP_CT_OPEN to TCP_CT_CLOSED.

[0130] This embodiment addresses the four-way handshake process for TCP connections. Regardless of whether the close is initiated actively or one party passively responds to the close request, the TCP transport layer will close the TCP connection after the entire four-way handshake process is completed. At this time, the NAT gateway will change the state information of the NAT session associated with this TCP connection from TCP_CT_OPEN to TCP_CT_CLOSED. Once the TCP connection is officially closed, the NAT gateway can immediately release the resources associated with the connection, thereby helping to improve resource utilization efficiency.

[0131] As an optional implementation, step S202, detecting the message to be transmitted in the gateway device, includes: detecting the first message to be transmitted received during the first handshake process of the gateway device; in response to the message type being a termination message type, setting the session information status information from the initial status information to the closed status information in the state machine, including: in response to the message type being a termination message type, sending a first response message corresponding to the first message to be transmitted of the termination message type during the second handshake process of the gateway device; in response to the successful sending of the first response message, sending a second message to be transmitted of the termination message type during the third handshake process of the gateway device; and in the fourth handshake process of the gateway device, receiving a second response message corresponding to the second message to be transmitted of the termination message type, and setting the session information status information from the initial status information to the closed status information in the state machine.

[0132] In this embodiment, the first message to be transmitted can be a FIN message received during the first handshake. The first acknowledgment message can be an acknowledgment (ACK) message sent during the second handshake, corresponding to the FIN message received during the first handshake. The second message to be transmitted can be a FIN message sent during the third handshake. The second acknowledgment message can be an ACK message received during the fourth handshake, corresponding to the FIN message sent during the third handshake.

[0133] Optionally, Figure 5 This is a schematic diagram of a four-way handshake process for actively initiating a FIN packet according to an embodiment of this application, as shown below. Figure 5As shown, the local machine initiates a FIN packet. At this point, it's necessary to trace the complete four-way handshake process between the two parties. The TCP four-way handshake process is as follows: The first handshake involves the initiating closer (the local machine) sending a FIN packet to the passive closer. The passive closer receives the FIN packet from the local machine, indicating that it has no more data to send. At this point, the NAT session can be marked as having received the first packet to be transmitted (FIN packet), and the sequence information (Sequence, or Seq) of the FIN packet can be recorded. The second handshake involves the passive closer receiving the FIN packet and sending an ACK packet as a response to confirm receipt of the FIN packet. At this point, the NAT session can be marked as having sent the first acknowledgment packet (ACK packet for the FIN packet).

[0134] Furthermore, the third handshake involves the passive closing party sending a FIN packet to the active closing party after processing the remaining data, indicating that it has no more data to send. At this point, the NAT session can be marked as having sent the second pending transmission packet (FIN packet). The fourth handshake involves the active closing party receiving the passive closing party's FIN packet and sending an ACK packet to acknowledge receipt. At this point, the NAT session can be marked as having received the second acknowledgment packet (the ACK packet for the FIN packet) and is marked as being in the TCP_CT_CLOSED state. Finally, after the quiet period, the relevant resources of the NAT session are released (reclaimed).

[0135] In this embodiment, when the local machine actively initiates a FIN packet, the NAT gateway can accurately identify the closed state of the TCP connection by fully tracking the four-way handshake process, thereby marking the NAT session state information as TCP_CT_CLOSED, so as to release the relevant resources of the NAT session after the quiet period.

[0136] As an optional implementation, the method further includes at least one of the following: during the first handshake, adding a first receiving identifier to the session information, wherein the first receiving identifier is used to indicate that a first message to be transmitted of the termination message category has been received; and / or, recording the sequence information of the first message to be transmitted of the termination message category; during the second handshake, adding a first sending identifier to the session information, wherein the first sending identifier is used to indicate that a first acknowledgment message has been sent; and / or, determining the acknowledgment sequence number of the first acknowledgment message; during the third handshake, adding a second sending identifier to the session information, wherein the second sending identifier is used to indicate that a second message to be transmitted of the termination message category has been sent; and / or, recording the sequence information of the second message to be transmitted of the termination message category; during the fourth handshake, adding a second receiving identifier to the session information, wherein the second receiving identifier is used to indicate that a second acknowledgment message has been received; and / or, determining the acknowledgment sequence number of the second acknowledgment message.

[0137] In this embodiment, the first receive identifier can be used to mark that the NAT session has received the first packet to be transmitted (FIN packet), and / or to record the sequence information of the first packet to be transmitted. The sequence information can be used to identify the position of the data stream sent in the TCP connection. The receiver reassembles the received data packets according to the sequence information to ensure that the data arrives in the correct order. The first send identifier can be used to mark that the NAT session has sent the first acknowledgment packet (ACK packet of FIN packet), and / or to determine the acknowledgment sequence number of the first acknowledgment packet. The acknowledgment sequence number can be a key field to confirm the received data and can be used to inform the sender and receiver of the sequence number of the next byte expected to be received, thereby ensuring that the data is transmitted in order and that all data is received correctly.

[0138] It should be noted that the second sending identifier can be used to mark that the NAT session has sent the second message to be transmitted (FIN message), and / or to record the sequence information of the second message to be transmitted. The second receiving identifier can be used to mark that the NAT session has received the second acknowledgment message (ACK message of the FIN message), and / or to determine the acknowledgment sequence number of the second acknowledgment message.

[0139] Optionally, Figure 6 This is a schematic diagram illustrating the tracking of a four-way handshake process when a FIN packet is actively initiated, according to an embodiment of this application. Figure 6As shown, during the first handshake, in response to receiving the first packet to be transmitted (FIN packet), the program action can be to mark the NAT session as having received the FIN packet, and / or extract the sequence information (Seq) of the FIN packet, and save this sequence information to the object containing the received FIN sequence information (which can be represented by recv_fin_seq). During the second handshake, in response to sending the first acknowledgment packet (ACK packet for the FIN packet), the program can mark the NAT session as having sent the ACK packet for the FIN packet, and / or extract the acknowledgment sequence number of the ACK packet, and determine whether the acknowledgment sequence number of the ACK packet is equal to the sequence information (Seq) saved in the recv_fin_seq object. The TCP header field (ack_seq) is the acknowledgment sequence number of the ACK packet.

[0140] Furthermore, during the third handshake, in response to the transmission of the second FIN packet, the NAT session can be marked as having sent a FIN packet, and / or the sequence information (Seq) of the FIN packet can be recorded and saved to the object containing the sent FIN sequence information (which can be represented by send_fin_seq). During the fourth handshake, in response to the receipt of the second acknowledgment packet (ACK packet for the FIN packet), the NAT session can be marked as having received an ACK packet for the FIN packet, and / or the acknowledgment sequence number of the ACK packet can be determined, and it can be checked whether the acknowledgment sequence number of the ACK packet equals the sequence information (Seq) saved in the send_fin_seq object.

[0141] This embodiment ensures that FIN and ACK packets are correctly received and processed by determining the sequence information and acknowledgment number in each handshake process in which the FIN packet is actively initiated, thereby guaranteeing the reliability of the connection closing process.

[0142] As an optional implementation, recording the sequence information of the first message to be transmitted of the termination message category includes: determining the length of the header of the first IP message and the length of the header of the first TCP message based on the first Internet Protocol (IP) message and the first Transmission Control Protocol (TCP) message corresponding to the first message to be transmitted of the termination message category; determining and recording the sequence information of the first message to be transmitted based on the length of the header of the first IP message, the length of the header of the first TCP message, and the start sequence number of the first TCP message; recording the sequence information of the second message to be transmitted of the termination message category includes: determining the length of the header of the second IP message and the length of the header of the second TCP message based on the second IP message and the second TCP message corresponding to the second message to be transmitted of the termination message category; determining and recording the sequence information of the second message to be transmitted based on the length of the header of the second IP message, the length of the header of the second TCP message, and the start sequence number of the second TCP message.

[0143] In this embodiment, the first IP packet can be an IP packet corresponding to the first packet to be transmitted, and the first TCP packet can be a TCP packet corresponding to the first packet to be transmitted. The second IP packet can be an IP packet corresponding to the second packet to be transmitted, and the second TCP packet can be a TCP packet corresponding to the second packet to be transmitted.

[0144] Optionally, based on the length of the first IP packet header and the length of the first TCP packet header, the data length of the first TCP packet can be calculated using the following formula:

[0145] tcp_data_len=bpf_htons(iph->tot_len)-((iph->ih l<<2)+(th->doff<<2))

[0146] Wherein, `tcp_data_len` can be used to represent the data length of the first TCP packet. `bpf_htons(iph->tot_len)` can be used to retrieve the length of the first IP packet, including the IP packet header. `(iph->ih l<<2)` can be used to represent the length of the first IP packet header. `(th->doff<<2)` can be used to represent the length of the first TCP packet header. Further, based on the above determination of the data length and starting sequence number of the first TCP packet, the sequence information of the first packet to be transmitted can be determined using the following formula:

[0147] fin_seq=bpf_hton l(bpf_hton l(th->seq)+tcp_data_len+1)

[0148] Here, fin_seq can be used to represent the sequence information of the first message to be transmitted, and bpf_hton l(th->seq) can be used to represent the starting sequence number of the first TCP message. That is, the starting sequence number of the first TCP message + the data length of the first TCP message + 1 is the sequence information of the first message to be transmitted.

[0149] Optionally, the calculation process of the sequence information of the second message to be transmitted is the same as the calculation process of the sequence information of the first message to be transmitted. That is, based on the length of the header of the second IP message and the length of the header of the second TCP message, the data length of the second TCP message can be calculated. Furthermore, based on the data length of the second TCP message and the starting sequence number of the second TCP message, the sequence information of the second message to be transmitted can be determined. This will not be elaborated on here.

[0150] This embodiment ensures that each step of the TCP connection closing process is executed accurately by calculating the sequence information of the FIN packet, thereby achieving reliable connection closing and effective resource management. By allocating appropriate sequence information to the FIN packet, it ensures that the connection closing request is correctly identified, processed, and acknowledged, thus supporting the reliable transmission service provided by the TCP protocol.

[0151] As an optional implementation, step S202, detecting the message to be transmitted in the gateway device, includes: detecting the third message to be transmitted sent during the first handshake of the gateway device; in response to the message type being a termination message type, setting the session information status information from the initial status information to the closed status information in the state machine, including: in response to the message type being a termination message type, receiving a third response message corresponding to the third message to be transmitted of the termination message type during the second handshake of the gateway device; in response to the successful reception of the third response message, receiving a fourth message to be transmitted of the termination message type during the third handshake of the gateway device; and in the fourth handshake of the gateway device, sending a fourth response message corresponding to the fourth message to be transmitted of the termination message type, and setting the session information status information from the initial status information to the closed status information in the state machine.

[0152] In this embodiment, the third message to be transmitted can be a FIN message sent during the first handshake. The third acknowledgment message can be an ACK message received during the second handshake, corresponding to the FIN message sent during the first handshake. The fourth message to be transmitted can be a FIN message received during the third handshake. The fourth acknowledgment message can be an ACK message sent during the fourth handshake, corresponding to the FIN message received during the third handshake.

[0153] Optionally, Figure 7This is a schematic diagram of a four-way handshake process for passively initiating a FIN packet according to an embodiment of this application, as shown below. Figure 7 As shown, the local machine passively initiates the FIN packet. The TCP four-way handshake process is as follows: The first handshake involves the active closing party sending a FIN packet to the local machine. The local machine receives the FIN packet from the active closing party, indicating that the active closing party has no more data to send. At this point, the NAT session can be marked as having sent the third pending transmission packet (the FIN packet). The second handshake involves the local machine receiving the FIN packet and sending an ACK packet as a response to confirm receipt. At this point, the NAT session can be marked as having received the third acknowledgment packet (the ACK packet for the FIN packet).

[0154] Furthermore, the third handshake process involves the local machine sending a FIN packet to the active closer after processing the remaining data, indicating that it has no more data to send. At this point, the NAT session can be marked as having received the fourth packet to be transmitted (FIN packet), and the sequence information (Seq) of the FIN packet can be recorded. The fourth handshake process involves the active closer sending an ACK packet to acknowledge the FIN packet received from the local machine. At this point, the NAT session can be marked as having sent the fourth acknowledgment packet (ACK packet for the FIN packet), and the NAT session can be marked as being in the TCP_CT_CLOSED state. Finally, after the quiet period, the relevant resources of the NAT session are released (reclaimed).

[0155] In this embodiment, when the local machine passively initiates a FIN packet, the NAT gateway can accurately identify the closed state of the TCP connection by fully tracking the four-way handshake process, thereby marking the NAT session state information as TCP_CT_CLOSED, so as to release the relevant resources of the NAT session after the quiet period.

[0156] As an optional implementation, the method further includes at least one of the following: during the first handshake, adding a third sending identifier to the session information, wherein the third sending identifier is used to indicate that a third message to be transmitted of the termination message category has been sent; and / or, recording the sequence information of the third message to be transmitted of the termination message category; during the second handshake, adding a third receiving identifier to the session information, wherein the third receiving identifier is used to indicate that a third acknowledgment message has been received; and / or, determining the acknowledgment sequence number of the third acknowledgment message; during the third handshake, adding a fourth receiving identifier to the session information, wherein the fourth receiving identifier is used to indicate that a fourth message to be transmitted of the termination message category has been received; and / or, recording the sequence information of the fourth message to be transmitted of the termination message category; during the fourth handshake, adding a fourth sending identifier to the session information, wherein the fourth sending identifier is used to indicate that a fourth acknowledgment message has been sent; and / or, determining the acknowledgment sequence number of the fourth acknowledgment message.

[0157] In this embodiment, the third sending identifier can be used to mark that the NAT session has sent a third message to be transmitted (FIN message), and / or to record the sequence information Seq of the third message to be transmitted. The third receiving identifier can be used to mark that the NAT session has received a third acknowledgment message (ACK message of the FIN message), and / or to determine the acknowledgment sequence number of the third acknowledgment message.

[0158] It should be noted that the fourth receive identifier can be used to mark that the NAT session has received the fourth message to be transmitted (FIN message), and / or to record the sequence information (Seq) of the fourth message to be transmitted. The fourth send identifier can be used to mark that the NAT session has sent the fourth acknowledgment message (ACK message of the FIN message), and / or to determine the acknowledgment sequence number of the fourth acknowledgment message.

[0159] Optionally, Figure 8 This is a schematic diagram illustrating the tracking of a four-way handshake process in the case of passively initiating a FIN packet, according to an embodiment of this application. Figure 8 As shown, during the first handshake, in response to sending the third message to be transmitted (FIN message), the NAT session can be marked as having sent a FIN message, and / or the sequence information Seq of the FIN message can be extracted and saved to the send_fin_seq object. During the second handshake, in response to receiving the third acknowledgment message (ACK message of the FIN message), the NAT session can be marked as having received the ACK message of the FIN message, and / or the acknowledgment sequence number of the ACK message can be extracted, and it can be determined whether the acknowledgment sequence number of the ACK message is equal to the sequence information Seq saved in the send_fin_seq object.

[0160] Furthermore, during the third handshake, in response to the receipt of the fourth message to be transmitted (FIN message), the NAT session can be marked as having received the FIN message, and / or the sequence information Seq of the FIN message can be recorded and saved to the recv_fin_seq object. During the fourth handshake, in response to the sending of the fourth acknowledgment message (ACK message for the FIN message), the NAT session can be marked as having sent an ACK message for the FIN message, and / or the acknowledgment sequence number of the ACK message can be determined, and it can be checked whether the acknowledgment sequence number of the ACK message is equal to the sequence information Seq saved in the recv_fin_seq object.

[0161] This embodiment ensures that FIN and ACK packets are correctly received and processed by determining the sequence information and acknowledgment number in each handshake process of passively initiating FIN packets, thereby guaranteeing the reliability of the connection closing process.

[0162] As an optional implementation, the calculation process of the sequence information of the third message to be transmitted is the same as the calculation process of the sequence information of the first message to be transmitted. That is, based on the length of the header of the third IP message and the length of the header of the third TCP message corresponding to the third message to be transmitted, the data length of the third TCP message is calculated. Furthermore, based on the data length of the third TCP message and the starting sequence number of the third TCP message, the sequence information of the third message to be transmitted can be determined. This will not be elaborated on in detail here.

[0163] It should be noted that the calculation process for the sequence information of the fourth message to be transmitted is the same as the calculation process for the sequence information of the first message to be transmitted. That is, based on the length of the header of the fourth IP message and the length of the header of the fourth TCP message corresponding to the fourth message to be transmitted, the data length of the fourth TCP message is calculated. Furthermore, based on the data length of the fourth TCP message and the starting sequence number of the fourth TCP message, the sequence information of the fourth message to be transmitted can be determined. This will not be elaborated on in detail here.

[0164] As an optional implementation, step S204, determining the message category to which the message to be transmitted belongs, includes: determining the TCP protocol used by the message to be transmitted in the gateway device; and determining the message category from the TCP protocol.

[0165] In this embodiment, after detecting the TCP packets to be transmitted in the NAT gateway, the TCP protocol used by the TCP packets to be transmitted in the NAT gateway can be determined, and then the SYN packet type, SYNACK packet type, ACK packet type, RESET packet type, FIN packet type, FINACK packet type, etc. can be determined from the TCP protocol.

[0166] In one example, NAT resource reclamation is typically achieved by setting a session timeout. This works fine for UDP session aging, the key being the proper configuration of the UDP session aging threshold. However, for the TCP protocol, which is a stateful protocol, using session timeouts to reclaim NAT resources presents a technical challenge: low resource release efficiency for gateway devices.

[0167] However, in this embodiment of the application, in view of the problem of low resource release efficiency of the aforementioned gateway device, a TCP packet detection and TCP state tracking mechanism is designed for the TCP protocol of the NAT gateway. Based on the update logic of TCP packets and state machine, the TCP transport layer's handling action on the TCP connection can be determined in advance, thereby releasing the relevant resources of the NAT session maintained by the NAT gateway in advance, releasing the NAT IP and port resources occupied by the NAT session, improving the utilization efficiency of NAT resources, and thus achieving the technical effect of improving the resource release efficiency of the gateway device.

[0168] In this embodiment, a message to be transmitted in a gateway device is detected; the message category to which the message to be transmitted belongs is determined, wherein the message category is used to at least characterize the scenario in which the message to be transmitted is transmitted in the gateway device; based on the message category, the state information of the session information to which the message to be transmitted belongs is determined, wherein the session information is allocated resources during the operation of the gateway device, and the state information is used to indicate whether the resources are allowed to be released under the message category; based on the state information, a resource release policy of the gateway device is determined, wherein the resource release policy is used to represent the rules for the gateway device to perform resource release operations on resources; and resource release operations are performed on the resources according to the resource release policy. In other words, this embodiment determines the state information of the session information to which the message to be transmitted belongs by detecting the message category in the gateway device, and then determines the resource release policy of the gateway device based on the state information to perform resource release operations on the resources, thereby achieving the purpose of improving resource utilization and thus realizing the technical effect of improving the resource release efficiency of the gateway device, solving the technical problem of low resource release efficiency of the gateway device.

[0169] This application also provides a resource processing method for a gateway device. Figure 9 This is a flowchart of another resource processing method for a gateway device according to an embodiment of this application, such as... Figure 9 As shown, the method may include the following steps:

[0170] Step S902: Detect the packets to be transmitted in the Network Address Translation (NAT) gateway device.

[0171] In the technical solution provided in step S902 of this application, the packet to be transmitted in the Network Address Translation (NAT) gateway device can be detected. The NAT gateway device can be simply referred to as a NAT gateway.

[0172] In this embodiment, for scenarios where a packet to be transmitted is being transmitted within a NAT gateway device, the packet to be transmitted within the NAT gateway device can be detected. For example, in a scenario where the TCP transport layer receives a TCP packet, the received TCP packet can be detected at the TCP transport layer; in a scenario where the TCP transport layer sends a TCP packet, the sent TCP packet can be detected at the TCP transport layer; in a scenario where a TCP handshake is actively initiated to close the connection, the TCP packet received during the first handshake of the four-way handshake process can be detected; and in a scenario where a TCP handshake is passively initiated to close the connection, the TCP packet sent during the first handshake of the four-way handshake process can be detected.

[0173] Step S904: Determine the message category to which the message to be transmitted belongs.

[0174] In the technical solution provided by step S904 of this application, after detecting the message to be transmitted in the NAT gateway device, the message category to which the message to be transmitted belongs can be determined. The message category can at least characterize the scenario in which the message to be transmitted is transmitted in the NAT gateway device.

[0175] In this embodiment, after detecting the packet to be transmitted in the NAT gateway device, the content of the packet header can be obtained by reading the field corresponding to the packet header in the NAT gateway device. Since the content of the packet header contains information about different types of packets, the packet category to which the packet to be transmitted belongs can be determined.

[0176] For example, when the message to be transmitted is a TCP message, the message type of the TCP message to be transmitted can be determined by reading the fields corresponding to the header of the TCP message to be transmitted in the NAT gateway.

[0177] Step S906: Based on the message type, determine the status information of the NAT session information where the message to be transmitted resides.

[0178] In the technical solution provided by step S906 of this application, after determining the message category to which the message to be transmitted belongs, the status information of the NAT session information where the message to be transmitted resides is determined based on the determined message category. The NAT session information allocates NAT resources during the operation of the NAT gateway device, and the status information can be used to indicate whether the NAT resources are allowed to be released under the message category.

[0179] In this embodiment, after determining the packet category to which the packet to be transmitted belongs, a state machine can be established to maintain the state tracking of the TCP stream. The state machine can then determine state information such as the TCP_CT_OPEN state and TCP_CT_CLOSED state of the NAT session.

[0180] It should be noted that this state machine can at least be used to track the state information of NAT sessions, and thus take different actions for different state information. For example, for the TCP_CT_OPEN state of a NAT session, the action of continuing to track can be taken; for the TCP_CT_CLOSED state of a NAT session, the action of releasing the resources allocated for the NAT session can be taken.

[0181] Step S908: Based on the status information, determine the resource release strategy for the NAT gateway device.

[0182] In the technical solution provided by step S908 of this application, after determining the state information of the NAT session information where the message to be transmitted resides based on the message type, the resource release policy of the NAT gateway device can be determined based on the determined state information. The resource release policy can be used to represent the rules by which the NAT gateway device will perform resource release operations on NAT resources.

[0183] In this embodiment, after determining the state information of the NAT session in the state machine, when the state information is TCP_CT_CLOSED, the resource release strategy can be to perform a resource release operation on the resource after the quiet period.

[0184] Optionally, the above resource release strategy can also be implemented such that after determining the NAT session's state information to be TCP_CT_CLOSED, that is, during the NAT session's quiet period, if an anomaly is detected (e.g., a judgment error), the NAT session's state information can be changed from TCP_CT_CLOSED to TCP_CT_OPEN to minimize the probability of misjudgment.

[0185] Optionally, the above resource release strategy can also be implemented such that after determining that the NAT session's state information is TCP_CT_CLOSED, that is, during the NAT session's quiet period, if new data is received, the NAT session's state information is reset to TCP_CT_OPEN to avoid the problem of new data not being able to be transmitted normally.

[0186] Step S910: Perform resource release operation on NAT resources according to the resource release policy.

[0187] In the technical solution provided by step S910 of this application, after determining the resource release policy of the NAT gateway device based on the status information, the resource release operation can be performed on the NAT resources according to the determined resource release policy.

[0188] For example, after completing the four-way handshake process for a TCP connection, the corresponding NAT session state is immediately set to TCP_CT_CLOSED, indicating that the connection has been officially closed. A short silence period is then set to monitor for new data packets. If no new data arrives, the connection is considered truly terminated. After the silence period ends, the NAT resources associated with that NAT session are officially released, such as IP resources and port allocations, ensuring that inactive connections do not occupy valuable system resources for extended periods.

[0189] This embodiment releases unused NAT resources at appropriate times (e.g., after a quiet period following connection closure) according to a resource release strategy, which can avoid resource waste and improve resource utilization.

[0190] Through steps S902 to S910 of this application, the following steps are performed: A packet to be transmitted in the Network Address Translation (NAT) gateway device is detected; the packet category to which the packet to be transmitted belongs is determined, wherein the packet category at least characterizes the scenario in which the packet to be transmitted is transmitted in the NAT gateway device; based on the packet category, the status information of the NAT session information where the packet to be transmitted resides is determined, wherein the NAT session information allocates NAT resources during the operation of the NAT gateway device, and the status information indicates whether the NAT resources are allowed to be released under the packet category; based on the status information, the resource release policy of the NAT gateway device is determined, wherein the resource release policy indicates the rules for the NAT gateway device to perform resource release operations on NAT resources; and according to the resource release policy, the resource release operation is performed on the NAT resources. In other words, this application embodiment determines the status information of the session information where the packet to be transmitted resides by detecting the packet category to which the packet to be transmitted belongs in the NAT gateway device, and then determines the resource release policy of the NAT gateway device based on the status information to perform resource release operations, thereby improving resource utilization and achieving the technical effect of improving the resource release efficiency of the NAT gateway device, thus solving the technical problem of low resource release efficiency of the NAT gateway device.

[0191] This application also provides a resource processing method for a gateway device. Figure 10This is a flowchart of another resource processing method for a gateway device according to an embodiment of this application, such as... Figure 10 As shown, the method may include the following steps:

[0192] Step S1002: In the content delivery network, detect the message to be transmitted in the gateway device.

[0193] In the technical solution provided in step S1002 of this application, under the Content Delivery Network (CDN), the packets to be transmitted in the gateway device can be detected.

[0194] In this embodiment, for scenarios where a message to be transmitted is being transmitted in a gateway device, the message to be transmitted in the gateway device can be detected. For example, in a scenario where the TCP transport layer receives a TCP message, the received TCP message can be detected at the TCP transport layer; in a scenario where the TCP transport layer sends a TCP message, the sent TCP message can be detected at the TCP transport layer; in a scenario where a TCP handshake is actively initiated to close the connection, the TCP message received during the first handshake of the four-way handshake process can be detected; and in a scenario where a TCP handshake is passively initiated to close the connection, the TCP message sent during the first handshake of the four-way handshake process can be detected.

[0195] Step S1004: Determine the message category of the message to be transmitted in the content delivery network.

[0196] In the technical solution provided by step S1004 of this application, after detecting the message to be transmitted in the gateway device within the content delivery network, the message category to which the message to be transmitted belongs in the content delivery network can be determined. The message category can at least characterize the scenario in which the message to be transmitted is transmitted within the content delivery network.

[0197] In this embodiment, after detecting the message to be transmitted in the gateway device, the content of the message header can be obtained by reading the field corresponding to the message header in the gateway device. Since the content of the message header contains information about different types of messages, the message category to which the message to be transmitted belongs can be determined.

[0198] For example, when the gateway device is a NAT gateway and the message to be transmitted is a TCP message, the message type of the TCP message to be transmitted can be determined by reading the fields corresponding to the header of the TCP message to be transmitted in the NAT gateway.

[0199] Step S1006: Determine the status information of the session information where the message to be transmitted belongs based on the message type.

[0200] In the technical solution provided in step S1006 of this application, after determining the message category to which the message to be transmitted belongs in the content delivery network, the status information of the session information to which the message to be transmitted belongs can be determined based on the determined message category. The session information allocates resources during the operation of the gateway device, and the status information can be used to indicate whether the resources are allowed to be released under the message category.

[0201] In this embodiment, after determining the message category to which the message to be transmitted belongs, in order to maintain the state tracking of the TCP stream (a reliable and ordered bidirectional byte stream transmission channel established by the TCP protocol), a state machine can be formulated, and then the state information such as the TCP_CT_OPEN state and TCP_CT_CLOSED state of the NAT session can be determined in the state machine.

[0202] It should be noted that this state machine can at least be used to track the state information of NAT sessions, and thus take different actions for different state information. For example, for the TCP_CT_OPEN state of a NAT session, the action of continuing to track can be taken; for the TCP_CT_CLOSED state of a NAT session, the action of releasing the resources allocated for the NAT session can be taken.

[0203] Step S1008: Based on the status information, determine the resource release policy of the gateway device, wherein the resource release policy is used to represent the rules for the gateway device to perform resource release operations on resources to be performed.

[0204] In the technical solution provided in step S1008 of this application, after determining the status information of the session information where the message to be transmitted belongs based on the message type, the resource release policy of the gateway device can be determined based on the determined status information. The resource release policy can be used to represent the rules by which the gateway device will perform resource release operations on resources.

[0205] In this embodiment, after determining the state information of the NAT session in the state machine, when the state information is TCP_CT_CLOSED, the resource release strategy can be to perform resource release operation after the quiet period. The quiet period can be dynamically adjusted according to actual needs. For example, the quiet period can be seconds (s). This is only an example and no specific limit is made on the duration of the quiet period.

[0206] Optionally, the above resource release strategy can also be implemented such that after determining the NAT session's state information to be TCP_CT_CLOSED, that is, during the NAT session's quiet period, if an anomaly is detected (e.g., a judgment error), the NAT session's state information can be changed from TCP_CT_CLOSED to TCP_CT_OPEN to minimize the probability of misjudgment.

[0207] Optionally, the above resource release strategy can also be implemented such that after determining that the NAT session's state information is TCP_CT_CLOSED, that is, during the NAT session's quiet period, if new data is received, the NAT session's state information is reset to TCP_CT_OPEN to avoid the problem of new data not being able to be transmitted normally.

[0208] Step S1010: Perform resource release operation on the resource in the content delivery network according to the resource release strategy.

[0209] In the technical solution provided by step S1010 of this application, after determining the resource release strategy of the gateway device based on the status information, the resource release operation can be performed on the resource in the content delivery network according to the determined resource release strategy.

[0210] For example, after completing the four-way handshake process for a TCP connection, the corresponding NAT session's state is immediately set to TCP_CT_CLOSED, indicating that the connection has been officially closed. A short period of silence is then set to monitor for new data packets. If no new data arrives, the connection is considered truly terminated. After the silence period ends, resources associated with the NAT session are officially released, such as IP resources and port allocations, ensuring that inactive connections do not occupy valuable system resources for extended periods.

[0211] This embodiment releases unused resources at appropriate times (e.g., after a quiet period following connection closure) according to a resource release strategy, which can avoid resource waste and improve resource utilization.

[0212] Through steps S1002 to S1010 of this application, in a content delivery network (CDN), a message to be transmitted in a gateway device is detected; the message category to which the message to be transmitted belongs in the CDN is determined, wherein the message category is used to at least characterize the scenario in which the message to be transmitted is transmitted in the CDN; based on the message category, the state information of the session information to which the message to be transmitted belongs is determined, wherein the session information has resources allocated during the operation of the gateway device, and the state information is used to indicate whether the resources are allowed to be released under the message category; based on the state information, the resource release policy of the gateway device is determined, wherein the resource release policy is used to represent the rules for the gateway device to perform resource release operations on resources; and according to the resource release policy, the resource release operation is performed on the resources in the CDN. In other words, this application embodiment determines the state information of the session information to which the message to be transmitted belongs by detecting the message category to which the message to be transmitted belongs in the gateway device, and then determines the resource release policy of the gateway device based on the state information to perform resource release operations on the resources, thereby achieving the purpose of improving resource utilization and thus realizing the technical effect of improving the resource release efficiency of the gateway device, solving the technical problem of low resource release efficiency of the gateway device.

[0213] Figure 11 This is a schematic diagram of a resource processing system for a gateway device according to an embodiment of this application, such as... Figure 11 As shown, the resource processing system of the gateway device may include: a communication terminal 1102 and a gateway device 1104.

[0214] Communication terminal 1102 is used to generate messages to be transmitted.

[0215] Optionally, the communication terminal 1102 can be used to detect packets to be transmitted in the gateway device to generate packets to be transmitted. For scenarios where packets to be transmitted are being transmitted in the gateway device, the packets to be transmitted in the gateway device can be detected. For example, in a scenario where the TCP transport layer receives TCP packets, the received TCP packets can be detected at the TCP transport layer; in a scenario where the TCP transport layer sends TCP packets, the sent TCP packets can be detected at the TCP transport layer; in a scenario where a TCP handshake is actively initiated to close, the TCP packets received during the first handshake of the four-way handshake process can be detected; and in a scenario where a TCP handshake is passively initiated to close, the TCP packets sent during the first handshake of the four-way handshake process can be detected.

[0216] Gateway device 1104 is used to determine the message category to which the message to be transmitted belongs, wherein the message category is used to at least characterize the scenario in which the message to be transmitted is transmitted in the gateway device; based on the message category, determine the status information of the session information to which the message to be transmitted belongs, wherein the session information has resources allocated during the operation of the gateway device, and the status information is used to indicate whether the resources are allowed to be released under the message category; based on the status information, determine the resource release policy of the gateway device, wherein the resource release policy is used to represent the rules for the gateway device to perform resource release operations on resources; and perform resource release operations on resources according to the resource release policy.

[0217] Optionally, the gateway device 1104 can be used to determine the message category of the message to be transmitted. By reading the fields corresponding to the header of the message to be transmitted in the gateway device, the content of the header of the message to be transmitted can be obtained. Since the content of the header of the message to be transmitted contains information about different types of messages, the message category of the message to be transmitted can be determined. For example, when the gateway device is a NAT gateway and the message to be transmitted is a TCP message to be transmitted, the message category of the TCP message to be transmitted can be determined by reading the fields corresponding to the header of the TCP message to be transmitted in the NAT gateway.

[0218] Optionally, the gateway device 1104 can be used to determine the state information of the session information to which the packet to be transmitted belongs based on a determined packet category. After determining the packet category to which the packet to be transmitted belongs, a state machine can be defined to maintain TCP stream state tracking, and then the state information such as the TCP_CT_OPEN state and TCP_CT_CLOSED state of the NAT session can be determined in the state machine. It should be noted that this state machine can at least be used to track the state information of the NAT session, so as to take different operations for different state information. For example, for the TCP_CT_OPEN state of the NAT session, the operation of continuing to track can be taken; for the TCP_CT_CLOSED state of the NAT session, the operation of releasing the resources allocated to the NAT session can be taken.

[0219] Optionally, the gateway device 1104 can be used to determine the resource release strategy of the gateway device based on the state information. After determining the state information of the NAT session in the state machine, when the state information is TCP_CT_CLOSED, the resource release strategy can be to perform a resource release operation after the quiet period. The quiet period can be dynamically adjusted according to actual needs. For example, the quiet period can be seconds (s). This is only an example and no specific limit is placed on the duration of the quiet period. Optionally, the above resource release strategy can also be that after determining the state information of the NAT session to be TCP_CT_CLOSED, that is, during the quiet period of the NAT session, if an anomaly is found (e.g., a judgment error), the state information of the NAT session can be changed from TCP_CT_CLOSED to TCP_CT_OPEN to minimize the probability of misjudgment. Optionally, the above resource release strategy can also be implemented such that after determining that the NAT session's state information is TCP_CT_CLOSED, that is, during the NAT session's quiet period, if new data is received, the NAT session's state information is reset to TCP_CT_OPEN, in order to avoid the problem of new data not being able to be transmitted normally.

[0220] Optionally, gateway device 1104 can perform resource release operations according to a resource release policy. For example, after completing the four-way handshake process of a TCP connection, the corresponding NAT session state information is immediately set to TCP_CT_CLOSED, indicating that the connection has been officially closed. A short silence period is set during which new data packets are monitored for arrival. If no new data arrives, the connection is considered to have indeed terminated. After the silence period ends, the resources associated with the NAT session are officially released, such as IP resources and port allocations, ensuring that inactive connections do not occupy valuable system resources for an extended period.

[0221] This embodiment releases unused resources at appropriate times (e.g., after a quiet period following connection closure) according to a resource release strategy, which can avoid resource waste and improve resource utilization.

[0222] In this system, a message to be transmitted is generated through communication terminal 1102. Gateway device 1104 determines the message category to which the message to be transmitted belongs, where the message category at least characterizes the scenario in which the message to be transmitted is transmitted within the gateway device. Based on the message category, the status information of the session information containing the message to be transmitted is determined, whereby resources are allocated during the operation of the gateway device, and the status information indicates whether the resources are allowed to be released under the message category. Based on the status information, a resource release policy of the gateway device is determined, whereby the resource release policy represents the rules for the gateway device to perform resource release operations on resources. According to the resource release policy, the resource release operation is performed on the resources. In other words, this embodiment of the application determines the status information of the session information containing the message to be transmitted by detecting the message category to which the message to be transmitted belongs in the gateway device, and then determines the resource release policy of the gateway device based on the status information to perform resource release operations, thereby improving resource utilization and achieving the technical effect of improving the resource release efficiency of the gateway device, solving the technical problem of low resource release efficiency of the gateway device.

[0223] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application, such as the data to be verified, are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0224] Currently, in computing era scenarios involving edge cloud containers and large virtual machine clusters, there are typically two NAT gateway architectures: one is a dedicated origin-backup device for the cluster, where traffic within the cluster is routed to the dedicated device via a private network address. This dedicated NAT device usually has one or more public IP addresses for NAT line switching. The other architecture does not have a dedicated origin-backup device; each physical machine has a shared public IP address, used for both scenario services and NAT origin-backup. Container or virtual machine traffic on the physical machine passes through the NAT gateway on the host machine, which performs network address translation, enabling access from the private network to the public network.

[0225] The strength of a NAT gateway service largely depends on the amount of available NAT resources. If there are insufficient available IP addresses or ports, the NAT capability is limited and it will be difficult to cope with sudden traffic surges. There are generally two ways to improve the utilization of NAT resources: one is to increase the number of NAT IP addresses and the range of available ports; the other is to speed up the NAT session reclamation efficiency by reasonably adjusting the session timeout time to release resources as quickly as possible and improve resource utilization.

[0226] In one example, NAT resource reclamation is typically achieved by setting a session timeout. This works fine for UDP session aging, the key being the proper configuration of the UDP session aging threshold. However, for the TCP protocol, which is a stateful protocol, using session timeouts to reclaim NAT resources presents a technical challenge: low resource release efficiency for gateway devices.

[0227] However, in this embodiment of the application, in view of the problem of low resource release efficiency of the aforementioned gateway device, a TCP packet detection and TCP state tracking mechanism is designed for the TCP protocol of the NAT gateway. Based on the update logic of TCP packets and state machine, the TCP transport layer's handling action on the TCP connection can be determined in advance, thereby releasing the relevant resources of the NAT session maintained by the NAT gateway in advance, releasing the NAT IP and port resources occupied by the NAT session, improving the utilization efficiency of NAT resources, and thus achieving the technical effect of improving the resource release efficiency of the gateway device.

[0228] This application provides a method for real-time reclamation of NAT resources for NAT gateway TCP sessions based on TCP packet detection and TCP connection state tracking. Specifically targeting the TCP protocol of the NAT gateway, a TCP packet detection and TCP state tracking mechanism is proposed. Based on the update logic of TCP packets and the state machine, the mechanism pre-determines the TCP layer's actions on TCP connections, thereby releasing the TCP session objects maintained by the NAT gateway in advance, releasing the NAT IP and port resources they occupy, improving the utilization efficiency of NAT resources, and increasing the upper limit of the NAT gateway's capabilities. In a high-traffic CDN environment, this solution achieves a real-time TCP session resource reclamation rate of 98% for the NAT gateway.

[0229] The method described in this embodiment will be further described below.

[0230] Traditional NAT gateways rely on a complex mechanism to ensure effective resource management and release when handling session aging and resource reclamation. One mechanism for session aging is the establishment timeout mechanism. NAT gateways typically set a timeout for each established session, usually based on the characteristics of the TCP or UDP protocol. Once a session has no activity within the set time (e.g., no new packets pass through), it is considered terminated and removed from the NAT table. For TCP connections, a timeout slightly longer than the TCP Maximum Segment Lifetime (MSL) is usually set to ensure that segments are acknowledged or discarded. For UDP connections, since UDP is a connectionless protocol, the timeout is usually shorter because UDP sessions are typically short and do not require acknowledgment. Another mechanism for session aging is activity detection. A NAT gateway can detect whether new packets are associated with a specific session. If no new packets are associated, the session will be considered inactive and aged out after a certain period of time.

[0231] Common resource reclamation mechanisms include periodic scanning, proactive probing, priority management, and dynamic adjustment. For periodic scanning, the NAT gateway can periodically scan its maintained session table, finding and removing entries that have exceeded their timeout period, helping to release unused resources promptly. For proactive probing, in some advanced implementations, the NAT gateway may proactively send probe packets to external addresses to confirm the validity of a session. If a response is received, the session is still active; if no response is received, the session can be deleted. For priority management, under resource constraints, the NAT gateway may prioritize retaining high-priority sessions (e.g., critical traffic) and reclaim low-priority sessions more quickly. For dynamic adjustment, the session timeout period is dynamically adjusted based on network load and actual usage. Under high load, the timeout period can be appropriately shortened to accelerate resource reclamation.

[0232] The aging time setting typically takes into account the characteristics of network traffic and security requirements. For example, for Hypertext Transfer Protocol (HTTP) traffic, the aging time can be set relatively short because HTTP is usually a short-connection protocol. However, for applications that require long-term connections, such as File Transfer Protocol (FTP), the aging time should be set longer.

[0233] In summary, traditional NAT solutions employ numerous session aging and resource reclamation mechanisms, but the core mechanism still relies on setting session aging times. While these can be dynamically adjusted based on scenario differences or released based on flow priority, this busy-waiting mechanism struggles to guarantee timely resource reclamation. Traditional NAT solutions primarily achieve session aging and resource reclamation through reasonable control of session aging times, a mechanism suitable for UDP. However, it is unsuitable for TCP, as TCP is a stateful standard protocol with strict handshake establishment and teardown closure mechanisms.

[0234] Therefore, by understanding the TCP packet types at the NAT layer, this embodiment can guess and track the TCP connection state, thereby anticipating the transport layer's possible release actions on the TCP connection and deciding whether the NAT session should be released in advance.

[0235] It should be noted that the transport layer releases TCP connections in the following main ways: When the TCP transport layer receives a RESET message, it will close the TCP connection; when the TCP transport layer sends a RESET message, it has already closed the TCP connection; when the TCP handshake is actively initiated and four handshakes are completed, the TCP layer will close the TCP connection; when the TCP handshake is passively initiated and four handshakes are completed, the TCP layer will close the TCP connection; and when the transport layer silently closes the TCP connection due to network timeouts, insufficient resources, etc.

[0236] TCP silent closure is a standard practice where the TCP layer releases the TCP connection when network transmission times out or resources are insufficient, without a reset or four-way handshake mechanism. However, TCP silent closure is not a common behavior and occurs very rarely; in massive data statistics, less than 1% of TCP connections may be silently closed due to network timeouts or insufficient resources. In a NAT gateway, a session tracing mechanism based on TCP flows can be used to observe the TCP packets flowing through the session. Understanding these TCP packets can then help infer the release action of the TCP transport layer. Since the fifth scenario mentioned above occurs in very small numbers of samples, it can be ignored.

[0237] The TCP protocol standard describes various types of messages, such as SYN, SYNACK, ACK, RESET, FIN, and FINACK. The TCP header content can be obtained by reading the corresponding fields in the TCP header through the NAT gateway. Furthermore, the NAT gateway is a bidirectional processing function, needing to track not only IN-direction messages but also OUT-direction messages. This application operates in both directions simultaneously.

[0238] To maintain state tracking of the TCP stream, this embodiment defines a state machine, such as... Figure 3 As shown, the TCP_CT_OPEN state can be used to represent the initial state of a TCP stream, and the TCP_CT_CLOSED state can be used to indicate that a NAT session has been determined to be ready for release. After a NAT session is set to TCP_CT_CLOSED, if an anomaly is detected (e.g., a misjudgment), the NAT session state can be reset to TCP_CT_OPEN. For example, after receiving or sending a RESET message and setting the NAT session to TCP_CT_CLOSED, if new data is received during the session's quiet period, the NAT session state will be reset to TCP_CT_OPEN to minimize the probability of false positives. After a NAT session is set to TCP_CT_CLOSED, resources are actually released after a certain quiet period. This quiet period can be set as needed; for example, 1 second can guarantee a 90% recovery rate.

[0239] This addresses scenarios where the TCP transport layer closes the TCP connection when it receives a RESET message, and scenarios where the transport layer has already closed the TCP connection when it sends a RESET message. Figure 4As shown, by tracing the TCP transmission code, each time a RESET message is sent or received, the TCP transport layer sets the TCP connection to the TCP_CT_CLOSED state, after which it is reclaimed. Therefore, in the NAT gateway, regardless of whether it's in the IN or OUT direction, when a RESET message is detected in the NAT session, the TCP session is set to the TCP_CT_CLOSED state, indicating that it can be released in the future. Simultaneously, a quiet period is set for the NAT session. During this quiet period, if the NAT session receives any data packets, the previous state flags of the NAT session are cleared, and the NAT session state is reset to the TCP_CT_OPEN state to continue new packet detection and state tracking.

[0240] For scenarios where the TCP layer actively initiates a TCP handshake to close the connection, and after completing the four-way handshake, the TCP layer will close the TCP connection. The process of actively initiating a FIN packet and performing a four-way handshake is as follows: Figure 5 As shown, the process of tracing the four-way handshake when actively initiating a FIN packet is as follows: Figure 6 As shown, in the program implementation, a data structure is defined to track the TCP state machine. This structure is embedded in the NAT gateway's session structure. For the scenario where a TCP handshake is passively initiated to close, and the TCP layer closes the TCP connection after completing the four-way handshake, the process of the four-way handshake for passively initiating a FIN packet is as follows: Figure 7 As shown, the process of tracing the four-way handshake when the FIN packet is passively initiated is as follows: Figure 8 As shown, similarly in program implementation, a data structure is defined to track the TCP state machine, and this structure is embedded in the NAT gateway's session structure. Furthermore, in engineering implementation, the solutions for the two scenarios can be combined. Since a TCP connection can be either actively closed or passively closed, a generic structure can be directly embedded within the NAT session. The process for each scenario is determined by whether the TCP connection is actively or passively closed.

[0241] Regarding the calculation of sequence information, based on the length of the IP packet header and the length of the TCP packet header, the data length of the TCP packet can be calculated using the following formula:

[0242] tcp_data_len=bpf_htons(iph->tot_len)-((iph->ih l<<2)+(th->doff<<2))

[0243] Here, `tcp_data_len` can be used to represent the data length of a TCP packet. `bpf_htons(iph->tot_len)` can be used to retrieve the length of an IP packet, including the IP packet header. `(iph->ih l<<2)` can be used to represent the length of the IP packet header. `(th->doff<<2)` can be used to represent the length of the TCP packet header. Further, based on the above determination of the TCP packet data length and the TCP packet's starting sequence number, the sequence information of the packet to be transmitted can be determined using the following formula:

[0244] fin_seq=bpf_hton l(bpf_hton l(th->seq)+tcp_data_len+1)

[0245] Here, `fin_seq` can be used to represent the sequence information of the message to be transmitted, and `bpf_hton l(th->seq)` can be used to represent the start sequence number of the TCP message. That is, the start sequence number of the TCP message + the data length of the TCP message + 1 is the sequence information of the message to be transmitted. It should be noted that the acknowledgment sequence number of the ACK message is the `ack_seq` field in the TCP header.

[0246] This embodiment provides a TCP packet detection and TCP state tracking mechanism for the TCP protocol of NAT gateways. Based on the update logic of TCP packets and state machines, it can predict the TCP layer's handling of TCP connections in advance, thereby releasing the TCP session objects maintained by the NAT gateway in advance, releasing the NAT IP and port resources they occupy, improving the utilization efficiency of NAT resources, and increasing the upper limit of the NAT gateway's capabilities.

[0247] In this embodiment, a message to be transmitted in a gateway device is detected; the message category to which the message to be transmitted belongs is determined, wherein the message category is used to at least characterize the scenario in which the message to be transmitted is transmitted in the gateway device; based on the message category, the state information of the session information to which the message to be transmitted belongs is determined, wherein the session information is allocated resources during the operation of the gateway device, and the state information is used to indicate whether the resources are allowed to be released under the message category; based on the state information, a resource release policy of the gateway device is determined, wherein the resource release policy is used to represent the rules for the gateway device to perform resource release operations on resources; and resource release operations are performed on the resources according to the resource release policy. In other words, this embodiment determines the state information of the session information to which the message to be transmitted belongs by detecting the message category in the gateway device, and then determines the resource release policy of the gateway device based on the state information to perform resource release operations on the resources, thereby achieving the purpose of improving resource utilization and thus realizing the technical effect of improving the resource release efficiency of the gateway device, solving the technical problem of low resource release efficiency of the gateway device.

[0248] Figure 12 This is a structural block diagram of the computing environment for a resource processing method for a gateway device according to an embodiment of this application, such as... Figure 12 As shown, computing environment 1201 includes multiple computing nodes (such as servers) running on a distributed network (represented in the figure as 1210-1, 1210-2, ...,). Each computing node contains local processing and memory resources, and end user 1202 can remotely run applications or store data within computing environment 1201. Applications can be provided as multiple services 1220-1, 1220-2, 1220-3, and 1220-4 within computing environment 1201, representing services "A", "D", "E", and "H", respectively.

[0249] End user 1202 can provide and access services through a web browser or other software application on the client. In some embodiments, the provisioning and / or requests of end user 1202 can be provided to ingress gateway 1230. Ingress gateway 1230 may include a corresponding agent to handle the provisioning and / or requests for services (one or more services provided in computing environment 1201).

[0250] The services are provided or deployed based on various virtualization technologies supported by the computing environment 1201. In some embodiments, services may be provided based on virtual machine (VM)-based virtualization, container-based virtualization, and / or similar methods. VM-based virtualization can simulate a real computer by initializing a virtual machine, executing programs and applications without directly accessing any actual hardware resources. While the machine is virtualized by a virtual machine, container-based virtualization can launch containers to virtualize an entire operating system (OS), allowing multiple workloads to run on a single OS instance.

[0251] In one embodiment based on container virtualization, several containers of a service can be assembled into a Pod (e.g., a Kubernetes Pod). For example, such as Figure 12 As shown, service 1220-2 can be equipped with one or more Pods 1240-1, 1240-2, ..., 1240-N (collectively referred to as Pods). A Pod can include agent 1245 and one or more containers 1242-1, 1242-2, ..., 1242-M (collectively referred to as containers). One or more containers within a Pod handle requests related to one or more corresponding functions of the service. Agent 1245 typically controls service-related network functions such as routing and load balancing. Other services can also be equipped with Pods similar to Pods.

[0252] During operation, executing a user request from end user 1202 may require calling one or more services in computing environment 1201, and executing one or more functions of one service may require calling one or more functions of another service. For example... Figure 12 As shown, service "A" 1220-1 receives user requests from terminal user 1202 from ingress gateway 1230. Service "A" 1220-1 can call service "D" 1220-2, and service "D" 1220-2 can request service "E" 1220-3 to perform one or more functions.

[0253] The aforementioned computing environment can be a cloud computing environment, where resource allocation is managed by cloud services, allowing functionality development without needing to consider implementation, adjustment, or server scaling. This computing environment allows developers to execute event-responsive code without building or maintaining complex infrastructure. Services can be partitioned into a set of functions that can automatically and independently scale, rather than scaling a single hardware device to handle potential loads.

[0254] According to embodiments of this application, a method for implementing the above is also provided. Figure 2The resource processing method of the gateway device shown is a resource processing apparatus for the gateway device.

[0255] Figure 13 This is a schematic diagram of a resource processing apparatus for a gateway device according to an embodiment of this application, as shown below. Figure 13 As shown, the resource processing device 1300 of the gateway device may include: a first detection unit 1302, a first determination unit 1304, a second determination unit 1306, a third determination unit 1308, and a first release unit 1310.

[0256] The first detection unit 1302 is used to detect the message to be transmitted in the gateway device.

[0257] The first determining unit 1304 is used to determine the message category to which the message to be transmitted belongs, wherein the message category is used to at least characterize the scenario in which the message to be transmitted is transmitted in the gateway device.

[0258] The second determining unit 1306 is used to determine the status information of the session information where the message to be transmitted is located based on the message type. The session information is allocated resources during the operation of the gateway device, and the status information is used to indicate whether the resources are allowed to be released under the message type.

[0259] The third determining unit 1308 is used to determine the resource release strategy of the gateway device based on the status information, wherein the resource release strategy is used to represent the rules for the gateway device to perform resource release operations on resources to be performed.

[0260] The first release unit 1310 is used to perform resource release operations on resources in accordance with the resource release strategy.

[0261] It should be noted that the first detection unit 1302, the first determination unit 1304, the second determination unit 1306, the third determination unit 1308, and the first release unit 1310 correspond to steps S202 to S210. The five units and their corresponding steps implement the same examples and application scenarios, but are not limited to the content disclosed above. It should also be noted that the aforementioned units can be hardware or software components stored in memory and processed by one or more processors. These units can also run as part of the device within the server 10 provided in the above embodiments.

[0262] In the resource processing device of the gateway device, the first detection unit 1302 detects the message to be transmitted in the gateway device. The first determination unit 1304 determines the message category to which the message to be transmitted belongs, wherein the message category is used to at least characterize the scenario in which the message to be transmitted is transmitted in the gateway device. The second determination unit 1306 determines the status information of the session information to which the message to be transmitted belongs based on the message category, wherein the session information has resources allocated during the operation of the gateway device, and the status information is used to indicate whether the resources are allowed to be released under the message category. The third determination unit 1308 determines the resource release policy of the gateway device based on the status information, wherein the resource release policy is used to represent the rules for the gateway device to perform resource release operations on resources. The first release unit 1310 performs resource release operations on the resources according to the resource release policy. In other words, this application embodiment determines the status information of the session information where the message to be transmitted belongs by detecting the message category in the gateway device, and then determines the resource release strategy of the gateway device based on the status information to perform resource release operation, thereby achieving the purpose of improving resource utilization and realizing the technical effect of improving the resource release efficiency of the gateway device, thus solving the technical problem of low resource release efficiency of the gateway device.

[0263] According to embodiments of this application, a method for implementing the above is also provided. Figure 3 The resource processing method of the gateway device shown is a resource processing apparatus for the gateway device.

[0264] Figure 14 This is a schematic diagram of a resource processing apparatus for another gateway device according to an embodiment of this application, such as... Figure 14 As shown, the resource processing device 1400 of the gateway device may include: a second detection unit 1402, a fourth determination unit 1404, a fifth determination unit 1406, a sixth determination unit 1408, and a second release unit 1410.

[0265] The second detection unit 1402 is used to detect the packets to be transmitted in the Network Address Translation (NAT) gateway device.

[0266] The fourth determining unit 1404 is used to determine the message category to which the message to be transmitted belongs, wherein the message category is used to at least characterize the scenario in which the message to be transmitted is transmitted in the NAT gateway device.

[0267] The fifth determining unit 1406 is used to determine the status information of the NAT session information where the message to be transmitted is located based on the message type. The NAT session information allocates NAT resources during the operation of the NAT gateway device, and the status information is used to indicate whether the NAT resources are allowed to be released under the message type.

[0268] The sixth determining unit 1408 is used to determine the resource release policy of the NAT gateway device based on the status information, wherein the resource release policy is used to represent the rules for the NAT gateway device to perform resource release operations on NAT resources.

[0269] The second release unit 1410 is used to perform resource release operations on NAT resources in accordance with the resource release policy.

[0270] Here, the second detection unit 1402, the fourth determination unit 1404, the fifth determination unit 1406, the sixth determination unit 1408, and the second release unit 1410 correspond to steps S302 to S310. The five units and their corresponding steps implement the same examples and application scenarios, but are not limited to the content disclosed above. It should be noted that the above units can be hardware or software components stored in memory and processed by one or more processors. These units can also run as part of the device in the server 10 provided in the above embodiment.

[0271] In the resource processing device of the gateway device, the second detection unit 1402 detects the packets to be transmitted in the Network Address Translation (NAT) gateway device. The fourth determination unit 1404 determines the packet category to which the packet to be transmitted belongs, wherein the packet category is used to at least characterize the scenario in which the packet to be transmitted is transmitted in the NAT gateway device. The fifth determination unit 1406 determines the status information of the NAT session information to which the packet to be transmitted belongs based on the packet category, wherein the NAT session information allocates NAT resources during the operation of the NAT gateway device, and the status information is used to indicate whether the NAT resources are allowed to be released under the packet category. The sixth determination unit 1408 determines the resource release policy of the NAT gateway device based on the status information, wherein the resource release policy is used to represent the rules for the NAT gateway device to perform resource release operations on NAT resources. The second release unit 1410 performs resource release operations on the NAT resources according to the resource release policy. In other words, this application embodiment determines the status information of the session information where the packet to be transmitted belongs by detecting the packet category in the NAT gateway device, and then determines the resource release strategy of the NAT gateway device based on the status information to perform resource release operation, thereby achieving the purpose of improving resource utilization and thus realizing the technical effect of improving the resource release efficiency of the NAT gateway device, solving the technical problem of low resource release efficiency of the NAT gateway device.

[0272] According to embodiments of this application, a method for implementing the above is also provided. Figure 4 The resource processing method of the gateway device shown is a resource processing apparatus for the gateway device.

[0273] Figure 15This is a schematic diagram of a resource processing apparatus for a gateway device according to an embodiment of this application, as shown below. Figure 15 As shown, the resource processing device 1500 of the gateway device may include: a third detection unit 1502, a seventh determination unit 1504, an eighth determination unit 1506, a ninth determination unit 1508, and a third release unit 1510.

[0274] The third detection unit 1502 is used to detect the message to be transmitted in the gateway device under the content delivery network.

[0275] The seventh determining unit 1504 is used to determine the message category to which the message to be transmitted belongs in the content delivery network, wherein the message category is used to at least characterize the scenario in which the message to be transmitted is transmitted in the content delivery network.

[0276] The eighth determining unit 1506 is used to determine the status information of the session information where the message to be transmitted is located based on the message type. The session information is allocated resources during the operation of the gateway device, and the status information is used to indicate whether the resources are allowed to be released under the message type.

[0277] The ninth determining unit 1508 is used to determine the resource release strategy of the gateway device based on the status information, wherein the resource release strategy is used to represent the rules for the gateway device to perform resource release operations on resources to be performed.

[0278] The third release unit 1510 is used to perform resource release operations on resources in the content delivery network in accordance with the resource release strategy.

[0279] It should be noted that the third detection unit 1502, the seventh determination unit 1504, the eighth determination unit 1506, the ninth determination unit 1508, and the third release unit 1510 correspond to steps S402 to S410. The five units and their corresponding steps implement the same examples and application scenarios, but are not limited to the content disclosed above. It should also be noted that the aforementioned units can be hardware or software components stored in memory and processed by one or more processors. These units can also run as part of the device within the server 10 provided in the above embodiments.

[0280] In the resource processing device of the gateway device, the third detection unit 1502 detects the packets to be transmitted in the gateway device under the content delivery network. The seventh determination unit 1504 determines the packet category to which the packet to be transmitted belongs in the content delivery network, wherein the packet category is used to at least characterize the scenario in which the packet to be transmitted is transmitted in the content delivery network. The eighth determination unit 1506 determines the status information of the session information to which the packet to be transmitted belongs based on the packet category, wherein the session information has resources allocated during the operation of the gateway device, and the status information is used to indicate whether the resources are allowed to be released under the packet category. The ninth determination unit 1508 determines the resource release policy of the gateway device based on the status information, wherein the resource release policy is used to represent the rules for the gateway device to perform resource release operations on resources. The third release unit 1510 performs resource release operations on the resources in the content delivery network according to the resource release policy. In other words, this application embodiment determines the status information of the session information where the message to be transmitted belongs by detecting the message category in the gateway device, and then determines the resource release strategy of the gateway device based on the status information to perform resource release operation, thereby achieving the purpose of improving resource utilization and realizing the technical effect of improving the resource release efficiency of the gateway device, thus solving the technical problem of low resource release efficiency of the gateway device.

[0281] Embodiments of this application may provide an electronic device. Figure 16 This is a structural block diagram of an electronic device according to an embodiment of this application, such as... Figure 16 As shown, the electronic device may include: an input / output device 1602; a memory 1604; and a processor 1606, wherein the processor 1606 is connected to the input / output device 1602 and the memory 1604 via a bus 1608.

[0282] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and apparatus in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the methods in the above embodiments. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0283] The processor can invoke an executable program stored in memory via a transmission device to execute the method described in any of the above embodiments.

[0284] It will be understood by those skilled in the art that the structure shown in the figure is merely illustrative, and the computing device may also be a smartphone (such as an Android phone, an iOS phone, etc.), a tablet computer, a PDA, a mobile internet device (MID), a PAD, or other terminal device. This figure does not limit the structure of the aforementioned computing device. For example, computing device 1600 may also include more or fewer components (such as network interfaces, display devices, etc.) than shown in the figure, or may have a different configuration than that shown in the figure.

[0285] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0286] Embodiments of this application also provide a computer-readable storage medium. Optionally, in this embodiment, the computer-readable storage medium can be used to store the program code executed by the resource processing method of the gateway device provided in Embodiment 1.

[0287] Embodiments of this application also provide a computer program product. Optionally, in this embodiment, the computer program product may include a computer program that, when executed by a processor, implements the methods provided in the embodiments described above.

[0288] Optionally, the computer program product described above may include a non-volatile computer-readable storage medium, which can be used to store a computer program that, when executed by a processor, implements the method provided in the above embodiments.

[0289] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0290] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of units or modules may be electrical or other forms.

[0291] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0292] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0293] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory, random access memory, portable hard drive, magnetic disk, or optical disk.

[0294] The above are merely preferred embodiments of this application. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A resource processing method for a gateway device, characterized in that, include: Detect the messages to be transmitted in the gateway device; Determine the message category to which the message to be transmitted belongs, wherein the message category is used to at least characterize the scenario in which the message to be transmitted is transmitted in the gateway device; Based on the message type, the status information of the session information where the message to be transmitted is located is determined, wherein the session information has resources allocated during the operation of the gateway device, and the status information is used to indicate whether the resources are allowed to be released under the message type; Based on the status information, a resource release strategy for the gateway device is determined, wherein the resource release strategy is used to represent the rules by which the gateway device performs a resource release operation on the resource to be released; According to the resource release strategy, the resource release operation is performed on the resource.

2. The method according to claim 1, characterized in that, The step of determining the session information status information of the message to be transmitted based on the message type includes: Based on the message category, the state information of the session information is determined in the state machine, wherein the state machine includes initial state information and closed state information. The initial state information is used to indicate the state in which the resource is allowed to be used under the message category, and the closed state information is used to indicate the state in which the resource is allowed to be released in a future time period under the message category.

3. The method according to claim 2, characterized in that, The step of determining the state information of the session information in the state machine based on the message type includes: In response to the message type being a reset message type, in the state machine, the state information of the session information is changed from the initial state information to the closed state information; or, In response to the message type being a non-reset message type, in the state machine, the state information of the session information is changed from the closed state information to the initial state information.

4. The method according to claim 3, characterized in that, During a waiting period after the state information of the session information is set from the initial state information to the closed state information, the resource is allowed to be used under the message category, and the waiting period is before the future time period, the method further includes: During the waiting period, in response to receiving a new message, in the state machine, the state information of the session information is changed from the closed state information to the initial state information, and the new message is identified as the message to be transmitted.

5. The method according to claim 4, characterized in that, The step of determining the resource release strategy for the gateway device based on the status information includes: In response to the status information maintaining the off status information during the waiting period, the resource release strategy of the gateway device is determined.

6. The method according to claim 3, characterized in that, The messages to be transmitted in the detection gateway device include: The gateway device detects the received message to be transmitted at its transport layer. In response to the message type being a reset message type, setting the state information of the session information from the initial state information to the closed state information in the state machine includes: in response to the received message to be transmitted having the message type being a reset message type, setting the state information of the session information from the initial state information to the closed state information in the state machine.

7. The method according to claim 6, characterized in that, In response to the message type being a non-reset message type, in the state machine, the state information of the session information is changed from the closed state information to the initial state information, including: In response to the received message type being the non-reset message type and the state information of the session information being set to the closed state information in the state machine, the state information of the session information is changed from the closed state information to the initial state information.

8. The method according to claim 3, characterized in that, The messages to be transmitted in the detection gateway device include: The gateway device detects the sent message to be transmitted at its transport layer. In response to the message type being a reset message type, setting the state information of the session information from the initial state information to the closed state information in the state machine includes: in response to the message type of the sent message to be transmitted being the reset message type, setting the state information of the session information from the initial state information to the closed state information in the state machine.

9. The method according to claim 8, characterized in that, In response to the message type being a non-reset message type, in the state machine, the state information of the session information is changed from the closed state information to the initial state information, including: In response to the fact that the message type of the transmitted message is the non-reset message type, and the status information of the session information has been set to the closed status information in the state machine, the status information of the session information is changed from the closed status information to the initial status information.

10. The method according to claim 3, characterized in that, The step of determining the state information of the session information in the state machine based on the message type further includes: In response to the message type being a termination message type, in the state machine, the state information of the session information is changed from the initial state information to the closed state information.

11. The method according to claim 10, characterized in that, The messages to be transmitted in the detection gateway device include: Detect the first message to be transmitted received during the first handshake process of the gateway device; In response to the message type being a termination message type, in the state machine, the state information of the session information is changed from the initial state information to the closed state information, including: In response to the message type being the termination message type, during the second handshake process of the gateway device, a first response message corresponding to the first message to be transmitted of the termination message type is sent; In response to the successful transmission of the first response message, during the third handshake process of the gateway device, a second message to be transmitted of the termination message category is sent; During the fourth handshake process of the gateway device, a second response message corresponding to the second message to be transmitted of the termination message category is received, and in the state machine, the state information of the session information is changed from the initial state information to the closed state information.

12. The method according to claim 11, characterized in that, The method further includes at least one of the following: During the first handshake process, a first reception identifier is added to the session information, wherein the first reception identifier is used to indicate that the first message to be transmitted of the termination message type has been received; and / or, the sequence information of the first message to be transmitted of the termination message type is recorded; During the second handshake process, a first sending identifier is added to the session information, wherein the first sending identifier is used to indicate that the first response message has been sent; and / or, the response sequence number of the first response message is determined; During the third handshake process, a second sending identifier is added to the session information, wherein the second sending identifier is used to indicate that the second message to be transmitted of the termination message type has been sent; and / or, the sequence information of the second message to be transmitted of the termination message type is recorded; During the fourth handshake process, a second reception identifier is added to the session information, wherein the second reception identifier is used to indicate that the second response message has been received; and / or, the response sequence number of the second response message is determined.

13. The method according to claim 12, characterized in that, The sequence information of the first message to be transmitted of the termination message category includes: Based on the first Internet Protocol (IP) packet and the first Transmission Control Protocol (TCP) packet corresponding to the first packet to be transmitted of the termination packet category, determine the length of the header of the first IP packet and the length of the header of the first TCP packet. Based on the length of the header of the first IP packet, the length of the header of the first TCP packet, and the starting sequence number of the first TCP packet, the sequence information of the first packet to be transmitted is determined and recorded. The sequence information of the second message to be transmitted of the termination message category includes: Based on the second IP packet and the second TCP packet corresponding to the second packet to be transmitted of the termination packet category, determine the length of the header of the second IP packet and the length of the header of the second TCP packet. Based on the length of the second IP packet header, the length of the second TCP packet header, and the start sequence number of the two TCP packets, the sequence information of the second packet to be transmitted is determined and recorded.

14. The method according to claim 10, characterized in that, The messages to be transmitted in the detection gateway device include: Detect the third message to be transmitted sent during the first handshake process of the gateway device; In response to the message type being a termination message type, in the state machine, the state information of the session information is changed from the initial state information to the closed state information, including: In response to the message type being the termination message type, during the second handshake process of the gateway device, a third response message corresponding to the third message to be transmitted of the termination message type is received; In response to the successful receipt of the third response message, during the third handshake process of the gateway device, the fourth message to be transmitted of the termination message category is received; During the fourth handshake process of the gateway device, a fourth response message corresponding to the fourth message to be transmitted of the termination message category is sent, and in the state machine, the state information of the session information is changed from the initial state information to the closed state information.

15. The method according to claim 14, characterized in that, The method further includes at least one of the following: During the first handshake process, a third sending identifier is added to the session information, wherein the third sending identifier is used to indicate that the third message to be transmitted of the termination message category has been sent; and / or, the sequence information of the third message to be transmitted of the termination message category is recorded; During the second handshake process, a third receiving identifier is added to the session information, wherein the third receiving identifier is used to indicate that the third response message has been received; and / or, the response sequence number of the third response message is determined; During the third handshake process, a fourth reception identifier is added to the session information, wherein the fourth reception identifier is used to indicate that the fourth message to be transmitted of the termination message type has been received; and / or, the sequence information of the fourth message to be transmitted of the termination message type is recorded; During the fourth handshake process, a fourth sending identifier is added to the session information, wherein the fourth sending identifier is used to indicate that the fourth response message has been sent; and / or, the response sequence number of the fourth response message is determined.

16. The method according to any one of claims 1 to 15, characterized in that, Determining the message category to which the message to be transmitted belongs includes: Determine the TCP protocol used in the gateway device for the message to be transmitted; The message type is determined from the TCP protocol.

17. A resource processing method for a gateway device, characterized in that, include: Detect packets to be transmitted in the Network Address Translation (NAT) gateway device; Determine the message category to which the message to be transmitted belongs, wherein the message category is used to at least characterize the scenario in which the message to be transmitted is transmitted in the NAT gateway device; Based on the message type, the status information of the NAT session information where the message to be transmitted is located is determined, wherein the NAT session information allocates NAT resources during the operation of the NAT gateway device, and the status information is used to indicate whether the NAT resources are allowed to be released under the message type; Based on the status information, a resource release policy for the NAT gateway device is determined, wherein the resource release policy is used to represent the rules by which the NAT gateway device performs resource release operations on the NAT resources to be executed; According to the resource release policy, the resource release operation is performed on the NAT resource.

18. A resource processing method for a gateway device, characterized in that, include: In a content delivery network, detect the packets to be transmitted in the gateway device; Determine the message category to which the message to be transmitted belongs in the content delivery network, wherein the message category is used to at least characterize the scenario in which the message to be transmitted is transmitted in the content delivery network; Based on the message type, the status information of the session information where the message to be transmitted is located is determined, wherein the session information has resources allocated during the operation of the gateway device, and the status information is used to indicate whether the resources are allowed to be released under the message type; Based on the status information, a resource release strategy for the gateway device is determined, wherein the resource release strategy is used to represent the rules by which the gateway device performs a resource release operation on the resource to be released; According to the resource release strategy, the resource release operation is performed on the resource in the content delivery network.

19. A resource processing system for a gateway device, characterized in that, include: The communication end is used to generate messages to be transmitted; A gateway device is configured to: determine the message category to which the message to be transmitted belongs, wherein the message category is used to at least characterize the scenario in which the message to be transmitted is transmitted in the gateway device; based on the message category, determine the status information of the session information to which the message to be transmitted belongs, wherein the session information has resources allocated during the operation of the gateway device, and the status information is used to indicate whether the resources are allowed to be released under the message category; based on the status information, determine the resource release policy of the gateway device, wherein the resource release policy is used to represent the rules by which the gateway device performs a resource release operation on the resource; and execute the resource release operation on the resource according to the resource release policy.

20. An electronic device, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program, when running, performs the method according to any one of claims 1 to 18.

21. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored executable program, wherein, when the executable program is executed, it controls the device on which the storage medium is located to perform the method according to any one of claims 1 to 18.

22. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method according to any one of claims 1 to 18.