CN103297461B - NAT session keepalive duration method to set up and client and server - Google Patents

Abstract

The application discloses a kind of NAT session keepalive duration method to set up and has realized the client and server of the method. Can comprise according to the NAT session keepalive duration method to set up of the application's embodiment: client is obtained QoS grade according to user and/or business information; User end to server sends described QoS grade; Server receives described request message, according to described QoS classification keep-alive duration; And server sends described keep-alive duration to client. According to the application's method and apparatus, can NAT session keepalive duration be set according to user and business, make NAT resource be able to reasonable distribution and release, thereby improve resource utilization.

Description

NAT session keep-alive duration setting method and client and server

technical field

This application relates to a method for setting a NAT session keep-alive duration and a client and a server for realizing the method.

Background technique

Network Address Translation (Network Address Translation), referred to as NAT, is an IETF standard that can map one IP address domain to another IP address domain, thereby providing transparent routing for end hosts to solve the current shortage of public network IP addresses and network security issues. However, the mapping information between the user's public network IP address and private network IP address recorded and kept alive in the NAT device has a certain survival period. When there is no new request message within the survival period, the NAT session will be released, and then the server actively pushes the Messages will not be sent to the client, affecting user experience.

In order to solve the above problems, one way is that the client continuously sends heartbeat messages to keep the user's NAT session information alive, so that the host in the private TCP/IP network using the NAT device and the server maintain a long connection, so as to Ensure network security and smooth flow of data between client and server. However, the continuous sending of heartbeat messages seriously consumes radio channel resources and reduces the utilization rate of radio resources.

A way to avoid continuously sending heartbeat messages is to implement a PCP-based NAT session keep-alive solution. PCP (PortControlProtocol) is a protocol defined by IETF for session keep-alive between a PCP client and a PCP server (such as NAT). The core is that the PCP client sends information such as the IP address, port, and keep-alive period that need to be kept alive to the PCP server, and the server returns the information such as the allocated public network IP address, port, and negotiated keep-alive period to the client. , and then the client sends a keep-alive message to keep the session alive. According to this method, although the continuous sending of heartbeat messages is avoided, the PCP server generally sets the keep-alive period according to the requirements of the client, which easily causes waste of IP address resources.

Contents of the invention

In order to solve the resource waste problem of the existing PCP-based NAT session keep-alive duration setting, the present application proposes a method for setting the NAT session keep-alive duration and a client and a server implementing the method.

According to one aspect of the present application, a method for setting a NAT session keep-alive duration is proposed, which may include: the client obtains the QoS level according to user and/or service information; the client sends the QoS level to the server; the server receives the request message, determining the NAT session keep-alive duration according to the QoS level; and the server sends the NAT session keep-alive duration to the client.

According to another aspect of the present application, a client is proposed, which may include: a QoS level acquisition module, which acquires the QoS level according to user and/or service information; a sending module, which sends the QoS level; and a receiving module, which receives the guaranteed Live information.

According to another aspect of the present application, a server is proposed, which may include: a receiving module that receives a message including a QoS level; a keep-alive duration determination module that determines a NAT session keep-alive duration according to the QoS level; and a sending module, Send the keep-alive duration of the NAT session.

Through the method and device of the present application, the NAT session keep-alive duration can be set according to specific characteristics of different users and/or services, so that NAT resources can be reasonably allocated and released, and resource utilization can be improved.

Description of drawings

Fig. 1 is a flow chart of the NAT session keep-alive duration setting method according to an embodiment of the present application;

Figure 2 is a block diagram of a client device according to one embodiment of the present application; and

FIG. 3 is a block diagram of a server device according to one embodiment of the present application.

detailed description

Embodiments of the present application will be described in detail below with reference to the accompanying drawings.

Fig. 1 is a flowchart of a method for setting a NAT session keep-alive duration according to an embodiment of the present application. As shown in FIG. 1 , in step S1002, the client may obtain the QoS level according to user or service information or a combination of user and service information. Then in step S1004, the client may send the acquired QoS level to the server. In step S1006, the server receives the request message sent by the client, and determines the keep-alive duration according to the QoS level. Afterwards, in step S1008, the server sends the determined keep-alive duration to the client.

Through this method, the NAT session keep-alive duration can be set according to specific characteristics of different users and/or services, so that NAT resources can be reasonably allocated and released, and resource utilization can be improved.

According to the specific implementation plan of this application, in order to allocate different keep-alive periods for different users, services and other information, a QoS level lookup table can be configured in the client, so that the QoS level query table can be configured according to the user, service information or the combination of user and service information. Find the corresponding QoS class. The QoS class lookup table can be configured by the operator and can be modified flexibly.

It can be understood that the two factors of user and service may be considered simultaneously, or one of the factors of user and service may be considered separately, which will be described in detail later.

It can be understood that the client can obtain service information through various existing methods, for example, service detection through DPI, or add other network elements (for example, PCRF) to report service information.

According to a specific embodiment, after the client obtains the QoS level, it can insert it into the QoS level flag added in the request message to be sent to the server, and send the QoS level to the server through the request message.

According to a specific implementation solution, the server may be configured with a keep-alive time lookup table, and the keep-alive time length may be determined by querying the keep-alive time lookup table according to the QoS level. Similar to the QoS level query table, the keep-alive duration query table can be configured by the operator and can be flexibly modified. As a specific embodiment, a higher keep-alive duration can be set for a higher QoS level, so that in the case of resource shortage, users or services with a high QoS level can be given priority in providing services.

The following describes in detail how to set the keep-alive duration based on user and business information.

In a specific embodiment, configuring the QoS level lookup table in the client may only correspond to the QoS level according to the service. For example, for friendly always-on applications, since the always-on applications originally need to be permanently online, a persistent connection can be maintained for them, and the heartbeat message sending frequency of such applications can be reduced to reduce their occupation of wireless resources. Therefore, you can set a higher corresponding QoS level for this type of application, so as to configure a longer keep-alive duration. For another example, for applications such as uncooperative applications or viruses, a lower QoS level may be set, and the server may reject applications of such applications.

In another specific embodiment, the configuration of the QoS level lookup table in the client may only correspond to the QoS level according to the user. For example, higher priority can be provided for VIP users, that is, differentiated QoS levels can be provided according to user levels. When resources are tight, provide services for users with high QoS levels, and reject PCP requests of users with low QoS levels.

After the server determines the keep-alive duration, it sends it to the client, and the client can send a NAT session keep-alive message according to the received keep-alive duration.

It can be understood that the NAT session keep-alive message may be the same as the previously sent message containing the QoS request. The server will maintain the user session mapping relationship. If no data is sent within a certain period of time (that is, the timeout period), the mapping table will be deleted, so the user will not be able to access services (such as accessing the Internet). The keep-alive period is the mapping relationship. Timeout period, so as long as another message is received within this timeout period, the session will remain.

Referring next to FIG. 2 , a client device according to an embodiment of the present application will be described.

As shown in FIG. 2 , the client device 20 may include a QoS class acquisition module 202 and a sending module 204 . The QoS level acquiring module 202 can acquire the QoS level according to user and/or service information, and the sending module 204 can send the acquired QoS level.

According to an embodiment, the QoS level acquisition module may be configured with a QoS level lookup table, and the QoS level acquisition module acquires the QoS level by querying the QoS level lookup table according to user and/or service information.

According to an embodiment, in the request message of the client, a QoS level flag bit can be added, and the sending module sends the request message including the QoS level.

According to an embodiment, the client may further include a receiving module (not shown), configured to receive keep-alive duration information. The sending module can send a NAT session keep-alive message according to the received keep-alive duration information.

Referring next to FIG. 3 , a server device according to an embodiment of the present application will be described.

As shown in the figure, the server 30 may include a receiving module 302 , a keep-alive duration determining module 304 and a sending module 306 . The receiving module 302 can receive a message including a QoS class. The keep-alive duration determination module 304 can determine the keep-alive duration according to the QoS level, and the sending module 306 can send the keep-alive duration.

According to an embodiment, the keep-alive duration determination module may be configured with a keep-alive duration query table, and the keep-alive duration determination module may determine the keep-alive duration by querying the keep-alive duration query table according to the QoS level.

The exemplary embodiments of the present application are described above with reference to the accompanying drawings. Those skilled in the art should understand that the above-mentioned embodiments are only examples for the purpose of illustration, rather than limitation. Any modification, equivalent replacement, etc. made under the teaching of the present application and the protection scope of the claims shall be included in the protection scope of the present application.

Claims (11)

1. NAT session keep-alive duration setting method, including: The client obtains the QoS level according to user and/or service information; The client sends the QoS level to the server; The server receives the request message, and determines the NAT session keep-alive duration according to the QoS level; and The server sends the NAT session keep-alive duration to the client. 2. The method according to claim 1, wherein the client is configured with a QoS level lookup table, and the client obtains the QoS level by querying the QoS level lookup table according to user and/or service information. 3. The method according to claim 1, wherein a QoS level flag bit is added in the request message sent by the client to the server, and the QoS level is sent to the server through the request message. 4. The method according to claim 1, wherein the server is configured with a keep-alive duration lookup table, and the server determines the keep-alive duration by querying the keep-alive duration lookup table according to the QoS level. 5. The method according to claim 1, further comprising: the client sends a NAT session keep-alive message according to the received keep-alive duration. 6. Client devices, including: The QoS level acquisition module acquires the QoS level according to user and/or service information; A sending module, sending a request message including the QoS level; and A receiving module, configured to receive NAT session keep-alive duration information determined according to the QoS level. 7. The client device according to claim 6, wherein the QoS level acquisition module includes a QoS level lookup table, and the QoS level acquisition module queries the QoS level lookup table according to user and/or service information. Get the QoS class. 8. The client device according to claim 6, wherein the sending module sends a NAT session keep-alive message according to the keep-alive duration information. 9. Server equipment, including: The receiving module receives the message including the QoS level; The keep-alive duration determining module determines the NAT session keep-alive duration according to the QoS level; and A sending module, for sending the NAT session keep-alive duration. 10. The server device according to claim 9, wherein the keep-alive duration determination module includes a keep-alive duration lookup table, and the keep-alive duration determination module queries the keep-alive duration lookup table according to the QoS level To determine the keep-alive period. 11. NAT session keep-alive duration setting method, including: The client obtains the QoS level according to user and/or service information; The client sends a request message to the server, wherein the obtained QoS level is included in the QoS level flag bit of the request message; The server receives the request message, and determines the keep-alive duration according to the QoS level; The server sends the keep-alive duration to the client; and The client sends a NAT session keep-alive message according to the received keep-alive duration.