CN109039932B - Server and overload control method thereof - Google Patents
Server and overload control method thereof Download PDFInfo
- Publication number
- CN109039932B CN109039932B CN201810879977.3A CN201810879977A CN109039932B CN 109039932 B CN109039932 B CN 109039932B CN 201810879977 A CN201810879977 A CN 201810879977A CN 109039932 B CN109039932 B CN 109039932B
- Authority
- CN
- China
- Prior art keywords
- transaction
- historical
- server
- current
- client
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/12—Avoiding congestion; Recovering from congestion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
- H04L65/1104—Session initiation protocol [SIP]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Telephonic Communication Services (AREA)
Abstract
The embodiment of the invention provides a server overload control method, which comprises the following steps: the client calculates and stores the time data of each historical transaction; the client calculates the timeout reference duration of the current transaction according to the time data of each historical transaction in a preset time period; the client calculates the transaction timeout duration of the current transaction according to the timeout reference duration of the current transaction; and the client controls the state of the current transaction according to the transaction timeout duration of the current transaction. The invention also provides a server. The server and the overload control method thereof provided by the invention can solve the problem of server overload.
Description
Technical Field
The invention relates to the technical field of network communication, in particular to a server and an overload control method thereof.
Background
In the process of establishing a Session through Session Initiation Protocol (SIP), if a service end on a communication path is not congested, the SIP Session establishment process is generally as shown in fig. 1: a User Agent Client (UAC) first sends an INVITE request message to a User Agent Server (UAS), the UAC forwards the INVITE request message to the UAS through a proxy Server 1 and a proxy Server 2 (hereinafter, referred to as proxy servers) by routing, and the UAS receives the request message, replies response messages with response codes of 100Trying, 180Ringing and 200OK respectively in sequence, and sends the response messages to the UAC through the proxy servers.
The UAC determines address information of the UAS based on the response message whose response code is 200 OK. And finally, the UAC directly sends the ACK request message to the UAS without passing through a proxy server, the UAC and the UAS successfully establish connection, and the UAC and the UAS start to directly transmit data by using a Real-time Transport Protocol (RTP). If the UAC and the UAS need to tear down the session, the UAC can directly send a BYE request message to the UAS, and the UAS directly replies a response message with a response code of 200OK to the UAC to successfully tear down the session between the UAC and the UAS.
As the number of requests from voice over internet protocol ("voip") networks increases, overloading of servers within a SIP trunking system may occur, and when SIP transactions use unreliable transport layer communication protocols, continued overloading of servers may result in a congestion situation as shown in fig. 2: after the proxy server 1 sends the INVITE request message to the proxy server 2, because the proxy server 2 is congested and no response message is returned to the proxy server 1, the proxy server 1 continuously retransmits the current INVITE request message, and further the request amount of the proxy server 2 is increased sharply, and the load of the proxy server 2 is increased. Congestion situations like proxy 2 may also occur in proxy 1 or in the user proxy. The overload of the server in the SIP trunking system may be caused by a Distributed Denial of Service (DDoS) attack, and the like.
In order to solve the problem of server overload in the SIP trunking system, a local overload control method and a distributed overload control method are generally adopted in the prior art. The local overload control method means that the server identifies overload by comparing the magnitude of the external request quantity with the processing capacity of the external request quantity, and when the received request approaches to the processing capacity of the external request quantity, the server starts to reply a denial of service message to the subsequently received request, so that the overload is prevented. The distributed overload control method is that when the load condition of a downstream server approaches to the processing capacity of the downstream server through calculation, the downstream server is notified in a broadcast mode, the upstream server reduces the quantity of requests subsequently forwarded to the downstream server, and then overload is eliminated.
The inventor of the present invention has proposed another server overload control method in solving the above-described problem of server overload.
Disclosure of Invention
The application aims to provide a server and an overload control method thereof so as to solve the problem of server overload.
In order to achieve the above object, an aspect of the present application provides a server overload control method, including: the client calculates and stores the time data of each historical transaction; the client calculates the timeout reference duration of the current transaction according to the time data of each historical transaction in a preset time period; the client calculates the transaction timeout duration of the current transaction according to the timeout reference duration of the current transaction; and the client controls the state of the current transaction according to the transaction timeout duration of the current transaction.
Further, the step of calculating and storing the time data of each historical transaction by the client specifically includes: when the client sends the history request message of each history transaction to the server, the history request time when each history request message is sent is stored; when the historical response messages received by the client are not busy responses, calculating and storing historical round-trip time of each historical response message received by the client and the historical round-trip time of each corresponding historical request time; and when the historical response message received by the client is a busy response or the historical response message is not received, taking a default value as the historical round-trip time and storing the historical round-trip time.
Further, the step of calculating, by the client, the timeout reference duration of the current transaction according to the time data of each historical transaction in the preset time period specifically includes: when the client sends the current request message of the current transaction to the server, calculating each historical request moment in a preset time period, and respectively keeping a distance from the request time interval for sending the current request message; the client side calculates the congestion parameters of the server side according to each request time interval and each corresponding historical round trip time; and the client adds the default round-trip time length and the congestion parameters of the server to obtain the timeout reference time length of the current transaction.
Further, the step of calculating, by the client, the congestion parameter of the server according to each request time interval and each corresponding historical round-trip time specifically includes: the client calculates the congestion factor of the server according to each request time interval and each corresponding historical round-trip time; and the client accumulates the congestion factors of each server to obtain the congestion parameters of the servers.
In one embodiment, the congestion parameter is calculated by the following formula:
wherein t is the preset time period; t is txIs the requested time interval; tt is a natural substancexThe historical round trip time length is obtained; constants a and c are real numbers; the constant b is less than or equal to 0; a is the default round trip duration.
Further, the step of calculating, by the client, the transaction timeout duration of the current transaction according to the timeout reference duration of the current transaction specifically includes: the client calculates transaction overtime parameters according to each request time interval and each corresponding historical round-trip time; and the client multiplies the transaction timeout parameter by the timeout reference time length to obtain the transaction timeout time length of the current transaction.
In one embodiment, the transaction timeout duration of the current transaction is calculated by the following formula:
wherein t is the preset time period; t is txIs the requested time interval; tt is a natural substancexThe historical round trip time length is obtained; constants a and c are real numbers; the constant b is less than or equal to 0; a is the default round trip duration.
Further, if the current transaction uses an unreliable transport layer communication protocol, the step after the client calculates the timeout reference duration of the current transaction according to the time data of each historical transaction in a preset time period further includes: the client side takes the overtime reference duration of the current transaction as the first retransmission duration of the current request message to retransmit the current request message; and after the client retransmits the current request message once, the retransmission time length is doubled.
In one embodiment, the calculation formula of the retransmission time length is as follows:
retransmission duration is 2mX reference time length of time-out
Wherein m is the number of times the current request message has been retransmitted.
In order to achieve the above object, another aspect of the present application further provides a server, including: the first calculation module is used for calculating and storing time data of each historical transaction; the second calculation module is used for calculating the timeout reference duration of the current transaction according to the time data of each historical transaction in a preset time period; the third calculation module is used for calculating the transaction timeout duration of the current transaction according to the timeout reference duration of the current transaction; and the timeout control module is used for controlling the state of the current transaction according to the transaction timeout duration of the current transaction.
Further, the first calculating module is specifically configured to: storing the history request time when the history request message of each history transaction is sent in a server; when the received historical response message is a non-busy response, calculating and storing the historical response time of each received historical response message and the historical round-trip time of each corresponding historical request time; and when the received historical response message is a busy response or the historical response message is not received, taking a default value as the historical round-trip time and storing the historical round-trip time.
Further, the second calculating module is specifically configured to: calculating each historical request time in a preset time period, wherein the time interval is respectively far from the request time interval when the current request message of the current transaction is sent; calculating congestion parameters of the server according to each request time interval and each corresponding historical round trip time; and adding the default round trip time length and the congestion parameter of the server to obtain the timeout reference time length of the current transaction.
Further, the second calculating module is specifically further configured to: calculating a congestion factor of the server according to each request time interval and each corresponding historical round trip time; and accumulating the congestion factors of each service end to obtain the congestion parameters of the service ends.
In one embodiment, the congestion parameter is calculated by the following formula:
wherein t is the preset time period; t is txIs the requested time interval; tt is a natural substancexThe historical round trip time length is obtained; constants a and c are real numbers; the constant b is less than or equal to 0; a is the default round trip time length.
Further, the third calculating module is specifically configured to: calculating a transaction timeout parameter according to each request time interval and each corresponding historical round-trip time; and multiplying the transaction timeout parameter and the timeout reference duration to obtain the transaction timeout duration of the current transaction.
In one embodiment, the calculation formula of the transaction timeout duration of the current transaction is as follows:
wherein t is the preset time period; t is txIs the request time interval; tt is a Chinese characterxThe historical round trip time length is obtained; constants a and c are real numbers; the constant b is less than or equal to 0; a is the default round trip duration.
Further, if the current transaction uses an unreliable transport layer communication protocol, the timeout control module is further configured to retransmit the current request message by using the timeout reference duration of the current transaction as a first retransmission duration of the current request message; and after the current request message is retransmitted once, the retransmission time length is doubled.
In one embodiment, the calculation formula of the retransmission time length is as follows:
retransmission duration is 2mX reference time length of time-out
Wherein m is the number of times the current request message has been retransmitted.
In order to achieve the above object, another aspect of the present application further provides a server, which includes a memory and a processor, wherein the memory is used for storing a computer program, and the computer program, when executed by the processor, implements the above server overload control method.
Therefore, the overload condition of the downstream server of the client is objectively reflected by calculating the timeout reference time. The longer the calculated timeout reference time length is, the heavier the overload of the server is reflected, and when the calculated timeout reference time length is equal to the default round-trip time length, the overload of the server is not reflected.
The invention calculates the transaction timeout duration of the current transaction and the retransmission duration of the current request message according to the calculated timeout reference duration. Compared with the prior art, the default round-trip time length is adopted as the timeout reference time length of all the request messages, and the default round-trip time length is even multiple 26As for the transaction timeout duration of all transactions, the invention can shorten the transaction timeout duration. When the current affair uses unreliable transmission layer communication protocol, the invention can also prolong the retransmission time of the request message, thereby reducing the retransmission times of the request message.
In addition, the local overload control method provided by the prior art only performs well under the condition that the server load is light, and when the request amount is excessive and the load is heavy, the server rejects the request to cause extra resource consumption, so that the self overload is aggravated, and even the congestion is crashed. In the distributed overload control method provided by the prior art, a complex signaling protocol needs to be defined in cooperation between an upstream server and a downstream server, and the implementation difficulty in building the SIP cluster system is increased. Compared with the prior art, the method and the system can relieve the overload condition of the server, avoid congestion and crash of the server due to a large number of refused requests, or define a complex signaling protocol between upstream and downstream servers, and avoid causing additional resource consumption.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings required to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the description below are only some embodiments of the present invention, and it is obvious for those skilled in the art that other drawings can be obtained according to the drawings without creative efforts.
Fig. 1 is a schematic diagram of a SIP session establishment process provided in the background art;
fig. 2 is a schematic diagram of an SIP session establishment process when a server is overloaded according to the background art;
fig. 3 is a SIP network topology diagram provided by the embodiment of the present invention;
fig. 4 is a schematic diagram of a basic SIP entity relationship according to an embodiment of the present invention;
fig. 5 is a flowchart of a server overload control method according to an embodiment of the present invention;
FIG. 6 is a detailed flowchart of step 501 in FIG. 5;
FIG. 7 is a flowchart illustrating the detailed procedure of step 502 in FIG. 5;
FIG. 8 is a functional block diagram of a server according to an embodiment of the present invention;
fig. 9 is a schematic structural diagram of a server according to an embodiment of the present invention.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
The server overload control method provided by the embodiment of the invention can be used for controlling the server load in the SIP network, and the SIP network usually comprises a plurality of SIP cluster systems. Fig. 3 shows a topology diagram of a SIP network, and it should be noted that fig. 3 shows only a part of the SIP network. The SIP network includes a communication path, a plurality of User Agents (UAs), and a plurality of servers over the communication path. The UAs shown in fig. 3 represent user agent terminals: in a session, a UAs used to initiate a request message may be referred to as a UAC, a UAs used to receive and respond to a request message initiated by a UAC may be referred to as a UAS, and numbers 1-7 represent servers in a SIP server network topology between which communications may be established. The server may be a proxy server, UAS, redirect server, or registry server, etc.
Part of the SIP basic entity relationship of a SIP network is shown in fig. 4. The SIP basic entities comprise a UAC, a UAS, a proxy server, a redirect server and a register server. The proxy server 1 and the proxy server 2 are used for routing and forwarding request messages between the UAC and the UAS and response messages corresponding to the request messages; the redirection server is used for planning a communication path; the registration server is used for completing the registration of the UAS and uploading the address information of the UAS to the positioning server. In addition, the location server shown in fig. 4 is a public server in the internet, and does not belong to the SIP trunking system, and the location server may be used to store address information uploaded by the registration server in the SIP trunking system, so that the proxy server establishes a connection with the UAS.
Fig. 5 is a flowchart of a server overload control method according to an embodiment of the present invention. The method can be used for solving the problem that the SIP basic entity in the figure 3 or the figure 4 is overloaded. The server overload control method provided by the embodiment of the invention specifically comprises the following steps:
s501, the client calculates and stores time data of historical transactions;
it should be noted that the client may be a UAC or a proxy server. In this embodiment, the transaction is a SIP transaction, the historical transaction is relative to the current transaction, and all transactions before the current transaction may be referred to as historical transactions. The SIP transaction comprises a request message and all response messages corresponding to the request message, and the time data of the historical transaction at least comprises historical request time and historical round trip time. For SIP transactions using unreliable transport layer communication protocols, the SIP transaction also includes a retransmitted request message. SIP transactions may use unreliable transport layer communication protocols as well as reliable transport layer communication protocols. Unreliable transport layer communication protocols may include User Datagram Protocol (UDP), and reliable transport layer communication protocols may include Transmission Control Protocol (TCP). Regardless of whether the historical transaction uses an unreliable transport layer communication protocol or a reliable transport layer communication protocol, the time data of the historical transaction is valid for subsequent calculation of the timeout reference duration of the current transaction.
The specific implementation steps of step S501 are shown in fig. 6. In other words, performing steps S601 to S604 in fig. 6 may implement the steps of the client calculating and storing time data of the historical transaction.
S502, the client calculates the timeout reference duration of the current transaction according to the time data of each historical transaction in a preset time period;
it should be noted that the timeout reference duration T1 in this embodiment is a reference value of a Round-Trip Time (RTT) of a request message. RTT refers to the time interval from when a client sends a request message to when a corresponding response message is received. In the prior art, a fixed default round-trip duration is used as a timeout reference duration.
The transaction timeout Timer B controls the state of the current transaction according to the timeout reference time length, and in the prior art, the transaction timeout time length of the Timer B is 2 of the default round-trip time length6And (4) doubling.
When the current transaction uses an unreliable transport layer communication protocol, the retransmission Timer A controls the retransmission of the current request message according to the timeout reference time length, the first retransmission time length of the Timer A is the timeout reference time length, and the retransmission time length of the Timer A is doubled when the client retransmits the current request message once, so that the retransmission times of the request message are controlled, and the pressure on the server is reduced.
In one embodiment, in order to improve the efficiency of the client for calculating the timeout reference duration and ensure the accuracy of the timeout reference duration, the client calculates the timeout reference duration of the current transaction according to the time data of the historical transaction within the preset time period.
Specifically, the farther the historical request time is from the request time interval for sending the current request message, the weaker the correlation between the historical round-trip time and the current load condition of the server is, so that the preset time period can be set, and the time data of each historical transaction in the preset time period is used as the basic data for calculating the current timeout reference time. Moreover, since the request time interval and the correlation are nonlinearly related, a Gaussian function can be used
To calculate a non-linear correlation coefficient reflecting the correlation of each historical round trip time length and the current load condition of the server. Wherein, txA request time interval, that is, the duration of time from the current request when the INVITE request is sent by the historical transaction; constants a and c are real numbers; the constant b is less than or equal to 0.
The method for calculating T1 in step S502 may specifically refer to fig. 7, in other words, executing steps S701 to S703 in fig. 7 may implement a step in which the client calculates a timeout reference duration of the current transaction according to time data of each historical transaction within a preset time period.
S503, the client calculates the transaction timeout duration of the current transaction according to the timeout reference duration of the current transaction;
firstly, the client calculates a transaction timeout parameter 2 according to each request time interval and each corresponding historical round-trip timen；
In one embodiment, whether the current transaction uses an unreliable transport layer communication protocol or a reliable transport layer communication protocol, the current transaction is at an even multiple of 2 of T1nAs the transaction timeout duration T2, i.e., T2 ═ 2nT1. Using unreliable transport layer communication protocols, 2nT1 corresponds to the client retransmitting the current request message a maximum of n times. The calculation formula of n in this embodiment is:
wherein, a is a default round-trip duration, in this embodiment, the value is 500ms, which reflects a time interval from sending a request message to receiving a corresponding response message by the client under normal conditions; t is txA request time interval between a time of sending a history request message and a time of sending a current request message for a client; t is a preset time period; tt is a natural substancexSending a history request message for the client terminal to receive the history round trip time of a response message corresponding to the history request message.
It is to be noted that, in the embodiment of the present invention, the default round-trip duration value of 500ms is provided based on the rule of the inventor on the historical data, and is an average value, and in practical applications, due to the difference of the SIP network, the default round-trip duration value may also be determined according to the actual situation of the SIP network, so that the calculation results of T1 and T2 may be more applicable.
Further, the client multiplies the transaction timeout parameter by the timeout reference duration to obtain a transaction timeout duration T2 of the current transaction, and a calculation formula of T2 is as follows:
in one embodiment, in order to simplify the calculation formula of T2 and objectively reflect the load condition of the server, a gaussian function may be used
The value of the constant a is 1, the value of the constant b is 0, the value of the constant c is 0.5, the preset time period t can be 2min, namely 120000ms, and the value of A is 500 ms. The simplified T2 calculation formula is:
the invention can calculate the transaction overtime duration and the retransmission duration of the request message by calculating the overtime reference duration, and when the current transaction does not receive the response message in the transaction overtime duration, the message of session failure is immediately returned to the client and the current session is terminated, thereby avoiding overload of the server caused by continuous retransmission of the request message when the client does not receive the response message; further, in the transaction using the unreliable transport layer communication protocol, the retransmission frequency of the request message can be dynamically controlled based on the retransmission time length, and the pressure on the server side can be reduced to a certain extent.
S504, the client controls the state of the current affair according to the affair overtime length of the current affair.
In one embodiment, no matter whether the current transaction uses an unreliable transport layer communication protocol or a reliable transport layer communication protocol, the client starts Timer B when sending a request message to judge whether the current transaction is overtime, if yes, the client switches the state of the current transaction from Calling (Calling) to terminating (Terminated) through a state machine to terminate and clear the current transaction and inform the UAC that the UAC cannot generate an ACK request message, so that the connection between the UAC and the UAS cannot be successfully established, and the session is failed to be established; if not, the client closes the Timer B. The timeout period of Timer B is T2 calculated in step S503. The method for judging whether the current transaction is overtime comprises the following steps: when the client receives the response message in T2, the current transaction is not timed out; when the client does not receive the final response message within T2, the current transaction times out. The response code of the response message may be 1XX, 2XX, 3XX, 4XX, 5XX or 6 XX.
In one embodiment, the current transaction uses an unreliable transport layer communication protocol, and the client also starts a retransmission Timer a when issuing the request message, for controlling the retransmission of the current request message. The time A is the time T1 for the first retransmission, and the calculation process of T1 is shown in detail in FIG. 7. And when the client receives the response message, closing the Timer A and the Timer B. And when the client does not receive the response message in T1, retransmitting the current request message, and doubling the retransmission time length of the Timer A, otherwise, not retransmitting the request message.
The calculation formula of the retransmission duration of the current request message is as follows:
Where m is the number of times the current request message has been retransmitted.
It should be noted that the Via header fields of the request message and the response message include a name, a version number, and a transport layer communication protocol type of the protocol, and the client may know the transport layer communication protocol type according to the Via header fields, and then determine whether to start Timer a. For example, the header fields of the current request message include Via: SIP/2.0/UDP, which means that the current transaction uses an unreliable transport layer communication protocol UDP, the client starts Timer A.
Fig. 6 is a detailed flowchart of step 501 in fig. 5.
S601, when a client sends a history request message of a history transaction to a server, storing a history request moment when the history request message is sent;
it should be noted that, the server is relative to the client, the server is a server downstream of the client, and the server may be a proxy server, a UAS, a redirect server, a registration server, or the like. When the client sends a history request message to the server, the time for sending the history request message is stored in a local memory of the client.
S602, the client judges whether to calculate the historical round-trip time;
In one embodiment, the client determines whether to calculate the historical round-trip time according to whether the historical response message is successfully received and the type of the received historical response message. When the history response message received by the client is a non-busy response, executing step S603; when the response code of the history response message received by the client is 486 or when no history response message is received, step S604 is executed.
It should be noted that, according to the branch parameter and Cseq header field of the Via header field in the history response message, the client-side corresponds the received history response message to the history request message one-to-one to calculate the history round-trip time. The historical round-trip time is the time interval between the time when the historical response message is received and the time when the corresponding historical request is sent out.
S603, when the historical response messages received by the client are not busy responses, calculating and storing the historical response time of each received historical response message and the historical round-trip time of the historical response time which is far away from the corresponding historical request time;
for example, when the client receives the history response message with the response code of 100Trying, the client calculates and stores the history round-trip time from the history request time when the history response time of 100Trying is received.
S604, when the historical response message received by the client is a busy response or the historical response message is not received, taking a default value as the historical round-trip time and storing;
for example, when the client receives the historical response message with the response code of 486, although it can be determined that the server is overloaded, the overload degree of the server cannot be determined, so the client takes and stores a default value as the historical round-trip time. When the client does not receive the historical response message, the overload degree of the server cannot be determined, so the client also takes a default value as the historical round-trip time and stores the historical round-trip time. In one embodiment, the default value may be 1000ms as the historical round trip time, where 1000ms is equivalent to the round trip time of the client sending two request messages under normal circumstances.
FIG. 7 is a flowchart illustrating step 502 in FIG. 5.
S701, when a client sends a current request message of a current transaction to a server, calculating a request time interval from each historical request moment to the sending of the current request message within a preset time period;
in one embodiment, the predetermined time period may be 2min, which is only a preferred embodiment of the present invention and is not intended to limit the present invention. Within 2min from the time when the client sends the current request message to the time when the current request message is sent, the client sends a plurality of historical request messages to the server, and a plurality of request time intervals and a plurality of historical round-trip durations which are locally stored by the client are respectively in one-to-one correspondence (refer to table 1).
TABLE 1
| Request time interval tx | Historical round trip duration ttx |
| t1 | tt1 |
| t2 | tt2 |
| t3 | tt3 |
| …… | …… |
T in Table 11、t2And t3Etc. represent request time intervals, tt1、tt2And tt3Etc. represents the historical round trip time length, and t1And tt1、t2And tt2And t3And tt3And the like correspond one to one, respectively.
S702, the client calculates the congestion parameters of the server according to each request time interval and each corresponding historical round-trip time;
first, the client calculates the congestion factor of the server according to each request time interval and each corresponding historical round trip time shown in table 1:
wherein constants a and c are real numbers; the constant b is less than or equal to 0; a is the default round-trip duration, which in this embodiment takes 500 ms.
Secondly, the client accumulates the congestion factors of each server to obtain the congestion parameters of the servers:
s703, the client adds the default round-trip time length to the congestion parameter of the server to obtain the timeout reference time length of the current transaction;
the formula of the timeout reference duration T1 of the current request message is:
in one embodiment, in order to simplify the calculation formula of T1 and objectively reflect the load condition of the server, a Gaussian function can be used
The value of the real constant a is 1, and the value of the real constant c is 0.5. t is a preset time period, and can be set to 2min, namely 120000 ms. The value of A is 500 ms. The simplified T1 calculation formula is:
The calculated timeout reference time length T1 objectively reflects the load condition of the server. If the calculated T1 is 500ms and is the same as the default round-trip time, the server side is not overloaded; and if the calculated T1 is greater than 500ms, the overload occurs on the server, and the larger the adjusted timeout reference time length is, the heavier the load of the server is reflected.
Therefore, the overload condition of the downstream server side of the client side is objectively reflected by calculating the timeout reference time length. The longer the calculated timeout reference time length is, the heavier the current overload of the server is reflected, and when the calculated timeout reference time length is 500ms, the condition that the server is not overloaded is reflected.
The invention calculates the transaction overtime duration of the current transaction and the retransmission duration of the current request message according to the calculated overtime reference duration. The default round-trip duration is adopted as the timeout reference duration of all request messages and is an even multiple 2 of the default round-trip duration6As for the transaction timeout duration of all transactions, the invention can shorten the transaction timeout duration. When the current transaction uses isWhen the current affair is overtime, the invention can terminate the current affair in advance compared with the prior art, thereby reducing the request quantity sent by the client to the server and eliminating and preventing the overload of the server.
In addition, the local overload control method provided by the prior art only performs well under the condition that the server load is light, and when the request amount is excessive and the load is heavy, the server rejects the request to cause extra resource consumption, so that the self overload is aggravated, and even the congestion is crashed. In the distributed overload control method provided by the prior art, a complex signaling protocol needs to be defined in cooperation between an upstream server and a downstream server, and the implementation difficulty in building the SIP cluster system is increased. Compared with the prior art, the method and the system can relieve the overload condition of the server, and avoid congestion and crash of the server due to a large number of refused requests or additional resource consumption caused by defining a complex signaling protocol between upstream and downstream servers.
Fig. 8 is a schematic functional block diagram of a server according to a first embodiment of the present invention.
As shown in fig. 8, the server of this embodiment may include: the device comprises a first calculation module, a second calculation module, a third calculation module and a timeout control module. The first calculation module is used for calculating and storing time data of each historical transaction; the second calculation module is used for calculating the timeout reference duration of the current transaction according to the time data of each historical transaction in a preset time period; the third calculation module is used for calculating the transaction timeout duration of the current transaction according to the timeout reference duration of the current transaction; and the timeout control module is used for controlling the state of the current transaction according to the transaction timeout duration of the current transaction.
In one embodiment, the first calculation module is specifically configured to: storing the history request time when the history request message of each history transaction is sent in a server; when the received historical response message is a non-busy response, calculating and storing the historical response time of each received historical response message and the historical round-trip time of each corresponding historical request time; and when the received historical response message is a busy response or when the historical response message is not received, taking a default value as the historical round-trip time length and storing the historical round-trip time length.
In one embodiment, the second calculation module is specifically configured to: calculating each historical request time within a preset time period, and respectively keeping a request time interval when a current request message of the current transaction is sent; calculating congestion parameters of the server according to each request time interval and each corresponding historical round-trip time; and adding the default round-trip time length and the congestion parameters of the server to obtain the timeout reference time length of the current transaction.
In an embodiment, the second calculating module is further specifically configured to: calculating a congestion factor of the server according to each request time interval and each corresponding historical round-trip time; and accumulating the congestion factors of each service end to obtain the congestion parameters of the service ends.
In one embodiment, the congestion parameter is calculated by the following formula:
wherein t is the preset time period; t is txIs the requested time interval; tt is a natural substancexThe historical round trip time length is obtained; constants a and c are real numbers; the constant b is less than or equal to 0; a is the default round trip time length.
In an embodiment, the third calculating module is specifically configured to: calculating a transaction timeout parameter according to each request time interval and each corresponding historical round-trip time; and multiplying the transaction timeout parameter and the timeout reference duration to obtain the transaction timeout duration of the current transaction.
Further, the calculation formula of the transaction timeout duration of the current transaction is as follows:
wherein t is the preset time period; t is txIs the request time interval; tt is a Chinese characterxThe historical round trip time length is obtained; constants a and c are real numbers; the constant b is less than or equal to 0; a is the default round trip duration.
In one embodiment, if the current transaction uses an unreliable transport layer communication protocol, the timeout control module is further configured to retransmit the current request message by using a timeout reference duration of the current transaction as a first retransmission duration of the current request message; after retransmitting the current request message once, the retransmission time length is doubled.
In one embodiment, the retransmission duration is calculated by the following formula:
retransmission duration 2mX standard time length of time-out
Where m is the number of times the current request message has been retransmitted.
The server of this embodiment may be configured to execute the method of the method embodiments shown in fig. 5 to fig. 7, and the implementation principle and the technical effect to be achieved of the method are discussed above, and are not described herein again.
Fig. 9 is a schematic structural diagram of a server according to an embodiment of the present invention. The server comprises a memory for storing a computer program and a processor, wherein the computer program, when executed by the processor, can implement the server overload control method.
In particular, the server overload control method may be stored in a memory as a computer program, and the memory may be coupled to a processor, so that when the processor executes the computer program in the memory, the steps of the server overload control method may be implemented.
Through the above description of the embodiments, those skilled in the art will clearly understand that each embodiment can be implemented by software plus a necessary general hardware platform, and can also be implemented by hardware. Based on such understanding, the above technical solutions may be embodied in the form of software products, which are stored in a server readable storage medium, such as ROM/RAM, magnetic disk, optical disk, etc., and store instructions for causing a server to execute the methods described in the embodiments or some parts of the embodiments.
The above description is only for the purpose of illustrating the preferred embodiments of the present invention and should not be taken as limiting the scope of the present invention, which is intended to cover any modifications, equivalents, improvements, etc. within the spirit and scope of the present invention.
Claims (17)
1. A server overload control method, the method comprising:
the client calculates and stores time data of each historical transaction;
the client calculates the timeout reference duration of the current transaction according to the time data of each historical transaction in a preset time period;
the client calculates the transaction timeout duration of the current transaction according to the timeout reference duration of the current transaction;
the client controls the state of the current transaction according to the transaction timeout duration of the current transaction;
the step of calculating the timeout reference duration of the current transaction by the client according to the time data of each historical transaction in a preset time period specifically comprises the following steps:
when the client sends the current request message of the current transaction to the server, calculating each historical request moment in a preset time period, and respectively keeping a distance from the request time interval for sending the current request message;
The client calculates the congestion parameters of the server according to each request time interval and each corresponding historical round-trip time;
and the client adds the default round-trip time length to the congestion parameter of the server to obtain the timeout reference time length of the current transaction.
2. The method of claim 1, wherein the step of the client computing and storing the temporal data for each historical transaction specifically comprises:
when the client sends a history request message of each history transaction to the server, the history request moment when each history request message is sent is stored;
when the historical response message received by the client is a non-busy response, calculating and storing the historical round-trip time of the historical response time of each received historical response message and the historical round-trip time of each corresponding historical request time;
and when the historical response message received by the client is a busy response or the historical response message is not received, taking a default value as the historical round-trip time length and storing the historical round-trip time length.
3. The method as claimed in claim 1, wherein the step of the client computing the congestion parameter of the server according to each request time interval and each corresponding historical round-trip time length specifically includes:
The client calculates the congestion factor of the server according to each request time interval and each corresponding historical round-trip time;
and the client accumulates the congestion factors of each server to obtain the congestion parameters of the servers.
4. The method of claim 1, wherein the congestion parameter is calculated as:
wherein t is the preset time period, txFor the requested time interval, ttxAnd setting constants a and c as real numbers for the historical round-trip time, setting constant b to be less than or equal to 0, and setting A as the default round-trip time.
5. The method according to claim 1, wherein the step of calculating, by the client, the transaction timeout duration of the current transaction according to the timeout reference duration of the current transaction specifically includes:
the client calculates transaction overtime parameters according to each request time interval and each corresponding historical round-trip time;
and the client multiplies the transaction overtime parameter by the overtime reference time length to obtain the transaction overtime time length of the current transaction.
6. The method of claim 5, wherein the transaction timeout duration for the current transaction is calculated by the formula:
Wherein t is the preset time period; t is txIs the requested time interval; tt is a natural substancexThe historical round trip time length is obtained; constants a and c are real numbers; the constant b is less than or equal to 0; a is the default round trip time length.
7. The method of claim 1, wherein if the current transaction uses an unreliable transport layer communication protocol, the step of the client computing the timeout reference duration of the current transaction according to the time data of each historical transaction within a preset time period further comprises:
the client side retransmits the current request message by taking the timeout reference time length of the current transaction as the first retransmission time length of the current request message;
and after the client retransmits the current request message once, the retransmission time length is doubled.
8. The method of claim 7, wherein the retransmission time duration is calculated by the formula:
wherein m is the number of times the current request message has been retransmitted.
9. A server, comprising:
the first calculation module is used for calculating and storing time data of each historical transaction;
the second calculation module is used for calculating the timeout reference duration of the current transaction according to the time data of each historical transaction in a preset time period;
The third calculation module is used for calculating the transaction timeout duration of the current transaction according to the timeout reference duration of the current transaction;
the overtime control module is used for controlling the state of the current transaction according to the transaction overtime duration of the current transaction;
the second calculation module is specifically configured to:
calculating each historical request moment in a preset time period, and respectively keeping a distance from a request time interval when a current request message of the current transaction is sent;
calculating congestion parameters of a server according to each request time interval and each corresponding historical round-trip time;
and adding the default round trip time length and the congestion parameter of the server to obtain the timeout reference time length of the current transaction.
10. The server according to claim 9, wherein the first computing module is specifically configured to:
storing the history request time when the history request message of each history transaction is sent out in a server;
when the received historical response message is a non-busy response, calculating and storing the historical round-trip time of each historical response message from the corresponding historical request time;
And when the received historical response message is a busy response or the historical response message is not received, taking a default value as the historical round-trip time length and storing the historical round-trip time length.
11. The server according to claim 10, wherein the second computing module is further specifically configured to:
calculating a congestion factor of the server according to each request time interval and each corresponding historical round-trip time;
and accumulating the congestion factors of each service end to obtain the congestion parameters of the service ends.
12. The server according to claim 10, wherein the congestion parameter is calculated by the formula:
wherein t is the preset time period; t is txIs the request time interval; tt is a Chinese characterxThe historical round trip time length is obtained; constants a and c are real numbers; the constant b is less than or equal to 0; a is the default round trip duration.
13. The server according to claim 10, wherein the third computing module is specifically configured to:
calculating a transaction timeout parameter according to each request time interval and each corresponding historical round-trip time;
and multiplying the transaction timeout parameter and the timeout reference duration to obtain the transaction timeout duration of the current transaction.
14. The server of claim 13, wherein the transaction timeout duration for the current transaction is calculated by the formula:
wherein t is the preset time period; t is txIs the requested time interval; tt is a natural substancexThe historical round trip time length is obtained; constants a and c are real numbers; the constant b is less than or equal to 0; a is the default round trip duration.
15. The server of claim 9, wherein if the current transaction uses an unreliable transport layer communication protocol, the timeout control module is further to:
retransmitting the current request message by taking the timeout reference time length of the current transaction as the first retransmission time length of the current request message;
and after the current request message is retransmitted once, the retransmission time length is doubled.
16. The server according to claim 15, wherein the retransmission time duration is calculated by the formula:
wherein m is the number of times the current request message has been retransmitted.
17. A server, characterized in that the server comprises a memory for storing a computer program and a processor, the computer program, when executed by the processor, implementing the method of any one of claims 1 to 8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810879977.3A CN109039932B (en) | 2018-08-03 | 2018-08-03 | Server and overload control method thereof |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810879977.3A CN109039932B (en) | 2018-08-03 | 2018-08-03 | Server and overload control method thereof |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109039932A CN109039932A (en) | 2018-12-18 |
| CN109039932B true CN109039932B (en) | 2022-07-15 |
Family
ID=64649416
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810879977.3A Active CN109039932B (en) | 2018-08-03 | 2018-08-03 | Server and overload control method thereof |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109039932B (en) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110278601B (en) * | 2019-04-30 | 2022-02-15 | 中国联合网络通信集团有限公司 | Terminal power saving method and device |
| CN110166572A (en) * | 2019-06-06 | 2019-08-23 | 北京达佳互联信息技术有限公司 | Network processing method, device, electronic equipment and storage medium |
| CN112181669A (en) * | 2019-07-04 | 2021-01-05 | 中兴通讯股份有限公司 | Deadlock detection control method and device, communication equipment and computer storage medium |
| CN111756646B (en) * | 2020-07-08 | 2023-09-29 | 腾讯科技（深圳）有限公司 | Network transmission control method, device, computer equipment and storage medium |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100640862B1 (en) * | 2004-08-03 | 2006-11-02 | 엘지전자 주식회사 | A dynamic control method of an timeout measurement in a forward message transmission |
| US7978599B2 (en) * | 2006-11-17 | 2011-07-12 | Cisco Technology, Inc. | Method and system to identify and alleviate remote overload |
| CN101459496B (en) * | 2008-12-18 | 2011-05-04 | 北京大学 | Regulating method and apparatus for timeout interval for messages |
| US8699343B2 (en) * | 2009-04-27 | 2014-04-15 | Sonus Networks, Inc. | Adaptive rate control based on overload signals |
| CN103095434B (en) * | 2011-10-27 | 2018-02-02 | 山东金佳园科技股份有限公司 | A kind of data retransmission control method and device, terminal device |
| CN102325146A (en) * | 2011-10-28 | 2012-01-18 | 武汉杰瑞诚光电科技有限公司 | Universal data exchange (UDX) protocol stack, and UDX-protocol-based data transmission system and method |
| EP2819353A4 (en) * | 2012-02-24 | 2015-05-20 | Hitachi Ltd | Communication device |
| US9143454B2 (en) * | 2012-10-03 | 2015-09-22 | LiveQoS Inc. | System and method for a TCP mapper |
-
2018
- 2018-08-03 CN CN201810879977.3A patent/CN109039932B/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN109039932A (en) | 2018-12-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109039932B (en) | Server and overload control method thereof | |
| EP2002619B1 (en) | Network load balancing and overload control | |
| US8699343B2 (en) | Adaptive rate control based on overload signals | |
| EP2280520A1 (en) | A method and a network element for controlling the end-to-end overload based on the diameter application | |
| KR100786991B1 (en) | Session initiation protocol retransmission method | |
| JP4214793B2 (en) | Wireless communication system, server, base station, mobile terminal, and retransmission timeout time determination method used for them | |
| Shen et al. | Session initiation protocol (SIP) server overload control: Design and evaluation | |
| US20100274893A1 (en) | Methods and apparatus for detecting and limiting focused server overload in a network | |
| US20100223492A1 (en) | Node failure detection system and method for sip sessions in communication networks | |
| US20080205277A1 (en) | Congestion control in an IP network | |
| Azhari et al. | Overload control in SIP networks using no explicit feedback: A window based approach | |
| CN109088828B (en) | Server overload control method and system | |
| US8886793B2 (en) | Methods and systems for adjusting a traffic rate for a MSRP session | |
| Ohta | Performance comparisons of transport protocols for session initiation protocol signaling | |
| JP7067544B2 (en) | Communication systems, communication devices, methods and programs | |
| Hong et al. | Applying control theoretic approach to mitigate SIP overload | |
| Montazerolghaem et al. | Design, implementation and performance evaluation of a proactive overload control mechanism for networks of SIP servers | |
| US8203939B2 (en) | Method and apparatus for providing a window based overload control | |
| Egger et al. | SIP proxy high-load detection by continuous analysis of response delay values | |
| Hristov | Signaling Delay in Wireless Networks with Ses-sion Initiation Protocol over User Datagram Pro-tocol | |
| Salvachua et al. | Internet Draft Intended status: Informational JJ Garcia Aranda Expires: June 2019 Nokia M. Cortes | |
| Yamada et al. | Notification about congestion information through SIP session for call congestion control of VoIP application | |
| Moghaddam | Ahmadreza Montazerolghaem & | |
| Cortes et al. | DISPATCH Working Group JJ Garcia Aranda J. Perez Lajo Internet Draft LM Diaz Vizcaino G. Munoz Fernandez Intended status: Standards Track Alcatel-Lucent |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |