服务器及其过载控制方法与流程

本发明涉及网络通信
技术领域：
，特别涉及一种服务器及其过载控制方法。
背景技术：
在通过会话初始协议(sessioninitiationprotocol，sip)建立会话的过程中，如果通信路径上的服务端不出现拥堵，通常sip会话建立过程如图1所示：用户代理客户端(useragentclient，uac)首先向用户代理服务器(useragentserver,uas)发送invite请求消息，uac通过代理服务器1及代理服务器2(下文统称为代理服务器)将invite请求消息路由转发给uas，uas接收到请求消息后依次回复响应代码分别为100trying、180ringing、200ok的响应消息，并且通过代理服务器发送至uac。uac基于响应代码为200ok的响应消息确定uas的地址信息。最后，uac不再经过代理服务器，直接向uas发送ack请求消息，二者成功建立连接，并开始直接使用实时传输协议(real-timetransportprotocol，rtp)传输数据。如果二者需要拆除会话，可以由uac直接向uas发送bye请求消息,uas直接向uac回复响应代码为200ok的响应消息成功拆除二者之间的会话。随着网络电话的请求量增多，sip集群系统内的服务器可能发生过载，当sip事务使用的是不可靠的传输层通信协议时，服务器持续过载可能出现如图2所示的拥堵情况：代理服务器1向代理服务器2发送invite请求消息后，由于代理服务器2发生拥堵，未向代理服务器1返回响应消息，导致代理服务器1不断重传当前invite请求消息，进而导致代理服务器2的请求量剧增，加重代理服务器2的负载。类似代理服务器2的拥堵情况，也可能发生在代理服务器1或用户代理服务器中。sip集群系统内的服务器发生过载的原因还可能是受到分布式拒绝服务(distributeddenialofservice，ddos)攻击等。为了解决sip集群系统内的服务器过载问题，现有技术一般采用本地过载控制方法和分布式过载控制方法。本地过载控制方法是指服务器通过将外部请求量大小与其处理能力对比来识别过载，当其接收到的请求接近其处理能力时开始对后续接收到的请求回复拒绝服务消息，进而防止过载。分布式过载控制方法是指下游服务器通过计算自身负载情况接近其处理能力时，广播通知其上游服务器，由上游服务器减少后续转发到该下游服务器的请求量，进而消除过载。本发明的发明人在解决上述服务器过载的问题时，提出了另一种服务器过载控制方法。技术实现要素：本申请的目的在于提供一种服务器及其过载控制方法，以解决服务器过载问题。为实现上述目的，本申请一方面提供一种服务器过载控制方法，所述方法包括：客户端计算并存储每个历史事务的时间数据；所述客户端根据预设时段内的每个所述历史事务的时间数据，计算当前事务的超时基准时长；所述客户端根据所述当前事务的超时基准时长，计算所述当前事务的事务超时时长；所述客户端根据所述当前事务的事务超时时长，控制所述当前事务的状态。进一步的，所述客户端计算并存储每个历史事务的时间数据的步骤具体包括：所述客户端向服务端发出每个所述历史事务的历史请求消息时，存储发出每个所述历史请求消息时的历史请求时刻；当所述客户端接收到的历史响应消息为非繁忙响应时，计算收到每个所述历史响应消息的历史响应时刻，距离对应的每个所述历史请求时刻的历史往返时长并存储；当所述客户端接收到的所述历史响应消息为繁忙响应，或未接收到所述历史响应消息时，取默认值作为所述历史往返时长并存储。进一步的，所述客户端根据预设时段内的每个所述历史事务的时间数据，计算当前事务的超时基准时长的步骤具体包括：所述客户端向所述服务端发出所述当前事务的当前请求消息时，计算预设时段内的每个所述历史请求时刻，分别距离发出所述当前请求消息的请求时间间隔；所述客户端根据每个所述请求时间间隔和对应的每个所述历史往返时长，计算所述服务端的拥堵参数；所述客户端将默认往返时长与所述服务端的拥堵参数相加，得到所述当前事务的超时基准时长。进一步的，所述客户端根据每个所述请求时间间隔和对应的每个所述历史往返时长，计算所述服务端的拥堵参数的步骤具体包括：所述客户端根据每个所述请求时间间隔和对应的每个所述历史往返时长，计算所述服务端的拥堵因子；所述客户端将每个所述服务端的拥堵因子累加，得到所述服务端的拥堵参数。在一个实施例中，所述拥堵参数的计算公式为：其中，t为所述预设时段；tx为所述请求时间间隔；ttx为所述历史往返时长；常数a和c为实数；常数b≤0；a为所述默认往返时长。进一步的，所述客户端根据所述当前事务的超时基准时长，计算所述当前事务的事务超时时长的步骤具体包括：所述客户端根据每个所述请求时间间隔和对应的每个所述历史往返时长，计算事务超时参数；所述客户端将所述事务超时参数与所述超时基准时长相乘，得到所述当前事务的事务超时时长。在一个实施例中，所述当前事务的事务超时时长的计算公式为：其中，t为所述预设时段；tx为所述请求时间间隔；ttx为所述历史往返时长；常数a和c为实数；常数b≤0；a为所述默认往返时长。进一步的，若所述当前事务使用的是不可靠的传输层通信协议，所述客户端根据预设时段内的每个所述历史事务的时间数据，计算当前事务的超时基准时长之后的步骤还包括：所述客户端以所述当前事务的超时基准时长，作为所述当前当前请求消息的首次重传时长，来重传所述当前请求消息；所述客户端每重传一次所述当前请求消息后，将所述重传时长加倍。在一个实施例中，所述重传时长的计算公式为：重传时长＝2m×超时基准时长其中，m为所述当前请求消息已经重传的次数。为实现上述目的，本申请另一方面还提供一种服务器，所述服务器包括：第一计算模块，用于计算并存储每个历史事务的时间数据；第二计算模块，用于根据预设时段内的每个所述历史事务的时间数据，计算当前事务的超时基准时长；第三计算模块，用于根据所述当前事务的超时基准时长，计算所述当前事务的事务超时时长；超时控制模块，用于根据所述当前事务的事务超时时长，控制所述当前事务的状态。进一步的，所述第一计算模块具体用于：将发出每个所述历史事务的历史请求消息时的历史请求时刻存储在服务器中；当接收到的历史响应消息为非繁忙响应时，计算收到每个所述历史响应消息的历史响应时刻，距离对应的每个所述历史请求时刻的历史往返时长并存储；当接收到的所述历史响应消息为繁忙响应，或未接收到所述历史响应消息时，取默认值作为所述历史往返时长并存储。进一步的，所述第二计算模块具体用于：计算预设时段内的每个所述历史请求时刻，分别距离发出所述当前事务的当前请求消息时的请求时间间隔；根据每个所述请求时间间隔和对应的每个所述历史往返时长，计算所述服务端的拥堵参数；将默认往返时长与所述服务端的拥堵参数相加，得到所述当前事务的超时基准时长。进一步的，所述第二计算模块具体还用于：根据每个所述请求时间间隔和对应的每个所述历史往返时长，计算所述服务端的拥堵因子；将每个所述服务端的拥堵因子累加，得到所述服务端的拥堵参数。在一个实施例中，所述拥堵参数的计算公式为：其中，t为所述预设时段；tx为所述请求时间间隔；ttx为所述历史往返时长；常数a和c为实数；常数b≤0；a为所述默认往返时长。进一步的，所述第三计算模块具体用于：根据每个所述请求时间间隔和对应的每个所述历史往返时长，计算事务超时参数；将所述事务超时参数与所述超时基准时长相乘，得到所述当前事务的事务超时时长。在一个实施例中，所述当前事务的事务超时时长的计算公式为：其中，t为所述预设时段；tx为所述请求时间间隔；ttx为所述历史往返时长；常数a和c为实数；常数b≤0；a为所述默认往返时长。进一步的，若所述当前事务使用的是不可靠的传输层通信协议，所述超时控制模块还用于以所述当前事务的超时基准时长，作为所述当前请求消息的首次重传时长，来重传所述当前请求消息；每重传一次所述当前请求消息后，将所述重传时长加倍。在一个实施例中，所述重传时长的计算公式为：重传时长＝2m×超时基准时长其中，m为所述当前请求消息已经重传的次数。为实现上述目的，本申请另一方面还提供一种服务器，所述服务器包括存储器和处理器，所述存储器用于存储计算机程序，所述计算机程序被所述处理器执行时，实现上述的服务器过载控制方法。由上可见，本发明通过计算超时基准时长，客观反映客户端下游的服务端的过载情况。计算后的超时基准时长越长，反映了服务端的过载越重，当计算后的超时基准时长等于默认往返时长时，反映了服务端未发生过载。本发明根据计算后的超时基准时长，来计算当前事务的事务超时时长和当前请求消息的重传时长。相对于现有技术固定采用默认往返时长作为所有请求消息的超时基准时长，并且以默认往返时长的偶数倍26作为所有事务的事务超时时长而言，本发明可以缩短事务超时时长。当当前事务使用的是不可靠的传输层通信协议时，本发明还可以延长请求消息的重传时长，从而减少请求消息的重传次数，当当前事务发生超时时，相较于现有技术提前终止当前事务，进而减少客户端发往服务端的请求量，消除和防止服务端过载。另外，现有技术提供的本地过载控制方法只在服务器负载较轻的情况下表现良好，当请求量过多负载较重时，服务器将因拒绝请求而造成额外的资源消耗，进而加重自身过载，甚至拥塞崩溃。现有技术提供的分布式过载控制方法中，上下游服务器之间合作需要定义复杂的信令协议，增加了搭建sip集群系统的实现难度。相对于现有技术而言，本发明不仅能减轻服务器过载情况，而且避免了服务器因大量拒绝请求而拥塞崩溃，或在上下游服务器之间定义复杂的信令协议，避免造成额外的资源消耗。附图说明为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。图1为
背景技术：
提供的sip会话建立过程示意图；图2为
背景技术：
提供的服务端过载时sip会话建立过程示意图；图3为本发明实施例提供的sip网络拓扑图；图4为本发明实施例提供的一种sip基本实体关系示意图；图5为本发明实施例提供的服务器过载控制方法的流程图；图6为图5中步骤501的具体流程图；图7为图5中步骤502的具体流程图；图8为本发明实施例提供的服务器功能模块示意图；图9为本发明实施例提供的服务器结构示意图。具体实施方式下面将结合附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。本发明实施例提供的服务器过载控制方法，可以用于控制sip网络中的服务器负载，sip网络通常包括多个sip集群系统。图3所示为sip网络拓扑图，需要说明的是，图3所示的仅为sip网络的一部分。sip网络包括通信路径，多个用户代理(useragent，ua)，以及通信路径上面的多个服务器。图3所示的uas代表用户代理终端：在一个会话中，用于发起请求消息的uas可称为uac，用于接收和响应uac发起的请求消息的uas可称为uas，数字1-7代表sip服务器网络拓扑中的服务器，任意两个服务器之间都可以建立通信。所述服务器可以为代理服务器、uas、重定向服务器或注册服务器等。sip网络的部分sip基本实体关系如图4所示。sip基本实体包括uac、uas、代理服务器、重定向服务器及注册服务器。代理服务器1及代理服务器2用于路由转发uac和uas之间的请求消息和与请求消息对应的响应消息；重定向服务器用于规划通信路径；注册服务器用于完成对uas的注册，将uas的地址信息上载至定位服务器。另外，图4所示的定位服务器是互联网中的公共服务器，不属于sip集群系统，定位服务器可以用于存储sip集群系统中注册服务器上载的地址信息，以便代理服务器与uas建立连接。图5为本发明实施例提供的服务器过载控制方法的流程图。该方法可以用于解决图3或图4中的sip基本实体发生过载的问题。本发明实施例提供的服务器过载控制方法具体包括以下步骤：s501，客户端计算并存储历史事务的时间数据；需要说明的是，客户端可以为uac或代理服务器。本实施例中的事务为sip事务，历史事务则是相对于当前事务而言的，当前事务之前的所有事务都可以称为历史事务。sip事务包括请求消息和与该请求消息对应的所有响应消息，历史事务的时间数据至少包括历史请求时刻和历史往返时长。对于使用不可靠的传输层通信协议的sip事务而言，sip事务还包括重传的请求消息。sip事务可以使用不可靠传输层通信协议，也可以使用可靠的传输层通信协议。不可靠的传输层通信协议可包含用户数据报协议(userdatagramprotocol，udp)，可靠的传输层通信协议可包含传输控制协议(transmissioncontrolprotocol，tcp)。无论历史事务使用的是不可靠的传输层通信协议，还是可靠的传输层通信协议，历史事务的时间数据对于后续计算当前事务的超时基准时长都是有效的。步骤s501的具体实施步骤参见图6。换而言之，执行图6中的步骤s601至s604可以实现客户端计算并存储历史事务的时间数据的步骤。s502，客户端根据预设时段内的每个历史事务的时间数据，计算当前事务的超时基准时长；需要说明的是，本实施例中的超时基准时长t1是请求消息往返时长(round-triptime，rtt)的参考值。rtt指客户端从发出请求消息到接收到对应的响应消息的时间间隔。现有技术中采用一个固定的默认往返时长作为超时基准时长。事务超时定时器timerb根据超时基准时长控制当前事务的状态，现有技术中timerb的事务超时时长为默认往返时长的26倍。当前事务使用的是不可靠的传输层通信协议时，重传定时器timera根据超时基准时长控制当前请求消息的重传，timera的首次重传时长为超时基准时长，客户端每重传一次当前请求消息，timera的重传时长加倍，从而控制请求消息重传的次数，以减少对服务端的压力。在一个实施例中，为了提高客户端计算超时基准时长的效率，保证超时基准时长的准确性，客户端根据预设时段以内的历史事务的时间数据，来计算当前事务的超时基准时长。具体的，由于历史请求时刻距离发出当前请求消息的请求时间间隔越远，历史往返时长与服务端当前负载情况的关联性越弱，故可通过设定预设时段，并采用预设时段内的每个历史事务的时间数据作为计算当前超时基准时长的基础数据。并且，由于请求时间间隔与所述关联性呈非线性相关，故可采用高斯函数来计算反映每个历史往返时长与服务端当前负载情况的关联性的非线性相关系数。其中，tx为请求时间间隔，也就是历史事务发出invite请求时距离当前请求的时长；常数a和c为实数；常数b≤0。步骤s502中计算t1的方法可具体参见图7，换而言之，执行图7中的步骤s701至s703可以实现客户端根据预设时段内的每个历史事务的时间数据，计算当前事务的超时基准时长的步骤。s503，客户端根据当前事务的超时基准时长，计算当前事务的事务超时时长；首先，客户端根据每个所述请求时间间隔和对应的每个所述历史往返时长，计算事务超时参数2n；在一个实施例中，无论当前事务使用的是不可靠的传输层通信协议，还是可靠的传输层通信协议，当前事务都以t1的偶数倍2n作为事务超时时长t2，即t2＝2nt1。使用不可靠的传输层通信协议时，2nt1相当于客户端最多对当前请求消息进行n次重传。本实施例中n的计算公式为：其中，a为默认往返时长，本实施例中，取值为500ms，它反映正常情况下客户端从发出请求消息到接收到对应的响应消息的时间间隔；tx为客户端发出历史请求消息的时刻与发出当前请求消息的时刻之间的请求时间间隔；t为预设时段；ttx为客户端发出历史请求消息到接收到与这个历史请求消息对应的响应消息的历史往返时长。值得注意的是，本发明的实施例中，默认往返时长取值为500ms是基于发明人对历史数据的规律提出的，是一个平均值，在实际应用中，由于sip网络的差异性，默认往返时长也可根据该sip网络的实际情况来确定，从而使得t1与t2的计算结果能更加适用。进一步的，客户端将事务超时参数与超时基准时长相乘，得到当前事务的事务超时时长t2，t2的计算公式为：在一个实施例中，为了简化t2的计算公式，并且客观反映服务端的负载情况，可以将高斯函数中的常数a取值为1，常数b取值为0，常数c取值为0.5，可以将预设时段t取值为2min，即120000ms，a取值为500ms。简化后的t2计算公式为：本发明可以通过计算超时基准时长，来计算事务超时时长和请求消息的重传时长，当当前事务在事务超时时长内未收到响应消息时，即时返回会话失败的消息给客户端，并终止当前会话，从而避免客户端在未收到响应消息时持续重传请求消息，而造成服务端的过载；进一步的，在使用的是不可靠传输层通信协议的事务中，可基于重传时长来实现动态控制请求消息的重传频率，也可在一定程度上减少对服务端的压力。s504，客户端根据当前事务的事务超时时长，控制当前事务的状态。在一个实施例中，无论当前事务使用的是不可靠的传输层通信协议，还是可靠的传输层通信协议，客户端在发出请求消息时都启动timerb，用于判断当前事务是否发生超时，若是，则客户端通过状态机将当前事务的状态由呼叫(calling)切换为终止(terminated)，来终止和清除当前事务，并通知uac不能生成ack请求消息，进而使得uac与uas之间不能成功建立连接，此次会话建立失败；若否，则客户端关闭timerb。timerb的超时时长为步骤s503中计算出的t2。当前事务是否发生超时的判断方法为：当客户端在t2内接收到响应消息，则当前事务未发生超时；当客户端在t2内未接收到最终响应消息，则当前事务发生超时。响应消息的响应代码可以为1xx、2xx、3xx、4xx、5xx或6xx。在一个实施例中，当前事务使用的是不可靠的传输层通信协议，客户端在发出请求消息时还启动重传定时器timera，用于控制当前请求消息的重传。timera的首次重传时长为t1，t1的计算过程详见图7。当客户端接收到响应消息，则关闭timera及timerb。当客户端在t1内未接收到响应消息，则重传当前请求消息，并将timera的重传时长加倍，否则不进行请求消息的重传。当前请求消息的重传时长的计算公式为：重传时长＝2mt1其中，m为当前请求消息已经重传的次数。需要说明的是，请求消息和响应消息的via头字段包含协议的名称、版本号和传输层通信协议类型，客户端可以根据via头字段获知传输层通信协议类型，进而判断是否启动timera。例如当前请求消息的头域包括via：sip/2.0/udp，表示当前事务使用的是不可靠的传输层通信协议udp，则客户端启动timera。图6为图5中步骤501的具体流程图。s601，客户端向服务端发出历史事务的历史请求消息时，存储发出历史请求消息时的历史请求时刻；需要说明的是，服务端是相对于客户端而言的，服务端是客户端下游的服务器，服务端可以为代理服务器、uas、重定向服务器或注册服务器等。客户端每向服务端发出一个历史请求消息，都将发出历史请求消息的时刻存储在客户端本地的存储器中。s602，客户端判断是否计算历史往返时长；在一个实施例中，客户端根据是否成功接收到历史响应消息，以及接收到的历史响应消息类型，判断是否计算历史往返时长。当客户端接收到的历史响应消息为非繁忙响应时，执行步骤s603；当客户端接收到的所述历史响应消息的响应代码为486，或当未接收到历史响应消息时，执行步骤s604。需要说明的是，客户端根据历史响应消息中via头字段的branch参数和cseq头字段，将收到的历史响应消息与历史请求消息一一对应，以计算历史往返时长。历史往返时长是指收到历史响应消息的时刻距离其对应的历史请求发出时刻的时间间隔。s603，当客户端接收到的历史响应消息为非繁忙响应时，计算收到每个历史响应消息的历史响应时刻，距离对应的历史请求时刻的历史往返时长并存储；例如，当客户端收到响应代码为100trying的历史响应消息，客户端计算收到100trying的历史响应时刻，距离对应的历史请求时刻的历史往返时长并存储。s604，当客户端接收到的所述历史响应消息为繁忙响应，或未接收到历史响应消息时，取默认值作为历史往返时长并存储；例如，当客户端收到响应代码为486的历史响应消息，虽然可以确定服务端发生过载，但是无法确定服务端的过载程度，因此客户端取默认值作为历史往返时长并存储。当客户端未接收到历史响应消息时，无法确定服务端的过载程度，因此客户端也取默认值作为历史往返时长并存储。在一个实施例中，可以取默认值为1000ms作为历史往返时长，1000ms相当于正常情况下客户端发送两次请求消息的往返时长。图7为图5中步骤502的具体流程图。s701，客户端向服务端发出当前事务的当前请求消息时，计算预设时段内的每个历史请求时刻分别距离发出当前请求消息的请求时间间隔；在一个实施例中，预设时段可以取值为2min，该数值仅为本发明的一个较佳实施例，并不用于限制本发明。从客户端发出当前请求消息到发出当前请求消息2min以内，客户端向服务端发送了多个历史请求消息，客户端本地存储的多个请求时间间隔和多个历史往返时长之间分别一一对应(可参考表1)。表1请求时间间隔tx历史往返时长ttxt1tt1t2tt2t3tt3…………表1中的t1、t2、以及t3等表示请求时间间隔，tt1、tt2、以及tt3等表示历史往返时长，并且t1与tt1、t2与tt2、以及t3与tt3等分别一一对应。s702，客户端根据每个请求时间间隔和对应的每个历史往返时长，计算服务端的拥堵参数；首先，客户端根据表1所示的每个请求时间间隔和对应的每个历史往返时长，计算服务端的拥堵因子：其中，常数a和c为实数；常数b≤0；a为默认往返时长,在本实施例中，取值为500ms。其次，客户端将每个所述服务端的拥堵因子累加，得到所述服务端的拥堵参数：s703，客户端将默认往返时长与服务端的拥堵参数相加，得到当前事务的超时基准时长；当前请求消息的超时基准时长t1的计算公式为：在一个实施例中，为了简化t1的计算公式，并且客观反映服务端的负载情况，可以将高斯函数中的实数常数a取值为1，实数常数c取值为0.5。t为预设时段，可以取值为2min，即120000ms。a取值为500ms。简化后的t1计算公式为：本发明计算后的超时基准时长t1客观反映了服务端的负载情况。若计算后的t1为500ms，与默认往返时长相同，则服务端未发生过载；若计算后的t1大于500ms，则服务端发生过载，并且调整后的超时基准时长越大，反映服务端的负载越重。由上可见，本发明通过计算超时基准时长，客观反映客户端下游的服务端的过载情况。计算后的超时基准时长越长，反映了服务端当前的过载越重，当计算后的超时基准时长为500ms时，反映了服务端未发生过载。本发明根据计算后的超时基准时长，来计算当前事务的事务超时时长和当前请求消息的重传时长。相对于现有技术固定采用默认往返时长作为所有请求消息的超时基准时长，并且以默认往返时长的偶数倍26作为所有事务的事务超时时长而言，本发明可以缩短事务超时时长。当当前事务使用的是不可靠的传输层通信协议时，本发明还可以延长请求消息的重传时长，从而减少请求消息的重传次数，当当前事务发生超时时，相较于现有技术提前终止当前事务，进而减少客户端发往服务端的请求量，消除和防止服务端过载。另外，现有技术提供的本地过载控制方法只在服务器负载较轻的情况下表现良好，当请求量过多负载较重时，服务器将因拒绝请求而造成额外的资源消耗，进而加重自身过载，甚至拥塞崩溃。现有技术提供的分布式过载控制方法中，上下游服务器之间合作需要定义复杂的信令协议，增加了搭建sip集群系统的实现难度。相对于现有技术而言，本发明不仅能减轻服务器过载情况，而且避免了服务器因大量拒绝请求而拥塞崩溃，或在上下游服务器之间定义复杂的信令协议，所造成额外的资源消耗。图8为本发明服务器实施例一的功能模块示意图。如图8所示，本实施例的服务器可以包括：第一计算模块、第二计算模块、第三计算模块、以及超时控制模块。第一计算模块，用于计算并存储每个历史事务的时间数据；第二计算模块，用于根据预设时段内的每个所述历史事务的时间数据，计算当前事务的超时基准时长；第三计算模块，用于根据所述当前事务的超时基准时长，计算所述当前事务的事务超时时长；超时控制模块，用于根据所述当前事务的事务超时时长，控制所述当前事务的状态。在一个实施例中，所述第一计算模块具体用于：将发出每个所述历史事务的历史请求消息时的历史请求时刻存储在服务器中；当接收到的历史响应消息为非繁忙响应时，计算收到每个所述历史响应消息的历史响应时刻，距离对应的每个所述历史请求时刻的历史往返时长并存储；当接收到的所述历史响应消息为繁忙响应时，或当未接收到所述历史响应消息时，取默认值作为所述历史往返时长并存储。在一个实施例中，所述第二计算模块具体用于：计算预设时段内的每个所述历史请求时刻，分别距离发出所述当前事务的当前请求消息时的请求时间间隔；根据每个所述请求时间间隔和对应的每个所述历史往返时长，计算所述服务端的拥堵参数；将默认往返时长与所述服务端的拥堵参数相加，得到所述当前事务的超时基准时长。在一个实施例中，所述第二计算模块具体还用于：根据每个所述请求时间间隔和对应的每个所述历史往返时长，计算所述服务端的拥堵因子；将每个所述服务端的拥堵因子累加，得到所述服务端的拥堵参数。在一个实施例中，所述拥堵参数的计算公式为：其中，t为所述预设时段；tx为所述请求时间间隔；ttx为所述历史往返时长；常数a和c为实数；常数b≤0；a为所述默认往返时长。在一个实施例中，所述第三计算模块具体用于：根据每个所述请求时间间隔和对应的每个所述历史往返时长，计算事务超时参数；将所述事务超时参数与所述超时基准时长相乘，得到所述当前事务的事务超时时长。进一步的，所述当前事务的事务超时时长的计算公式为：其中，t为所述预设时段；tx为所述请求时间间隔；ttx为所述历史往返时长；常数a和c为实数；常数b≤0；a为所述默认往返时长。在一个实施例中，若所述当前事务使用的是不可靠的传输层通信协议，所述超时控制模块还用于以所述当前事务的超时基准时长，作为当前请求消息的首次重传时长，来重传当前请求消息；每重传一次当前请求消息后，将重传时长加倍。在一个实施例中，重传时长的计算公式为：重传时长＝2m×超时基准时长其中，m为当前请求消息已经重传的次数。本实施例的服务器可以用于执行图5至图7所示方法实施例的方法，其实现原理和所要达到的技术效果上文中已有论述，在此不再赘述。图9为本发明实施例提供的服务器结构示意图。所示服务器包括存储器和处理器，所述存储器用于存储计算机程序，所述计算机程序被所述处理器执行时，可以实现上述服务器过载控制方法。具体的，上述服务器过载控制方法可以作为计算机程序存储在存储器中，上述存储器可以与处理器耦合，那么当处理器执行所述存储器中的计算机程序时，便可以实现上述的服务器过载控制方法中的各个步骤。通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件来实现。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该服务器过载控制的软件产品可以存储在服务器可读存储介质中，如rom/ram、磁碟、光盘等，包括存储若干指令用以使得一台服务器执行各个实施例或者实施例的某些部分所述的方法。以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。当前第1页12