信道故障的预警方法及装置的制造方法

文档序号:9380017
信道故障的预警方法及装置的制造方法
【技术领域】
[0001]本发明涉及互联网领域,具体而言,涉及一种信道故障的预警方法及装置。
【背景技术】
[0002]近些年,因网络账号被盗用而导致的个人信息泄露、银行账户非法交易等案件层出不穷。因此,网络账户的安全问题逐渐被人们所关注。
[0003]目前,网站或应用客户端为了增加账户的安全性,通常会在注册网络账户时,要求客户同时绑定一个或多个用于身份验证的手机号码或邮箱地址。以便在用户登陆网络账号时,通过向绑定的手机号码或者邮箱地址发送验证信息来验证用户身份。上述方法因操作简单,适用范围广泛而被众多网站或应用客户端所采用。
[0004]但是,有时因为移动运营商或者网络邮箱服务商的线路问题,导致用户不能及时获取到用于验证用户身份的验证信息,使用户无法正常使用网络账户,大大的影响了用户的使用体验。网站或应用客户端用来发送验证信息的线路是第三方提供的,所以,验证信息的送达率并不可控,通过现有技术并不能对用于发送验证信息的通道是否故障进行提前预目ο
[0005]针对现有技术中因无法对用于发送验证信息的线路的故障进行预警,导致在线路故障时影响网络账号正常使用的问题,目前尚未提出有效的解决方案。

【发明内容】

[0006]本发明的主要目的在于提供一种信道故障的预警方法及装置,以解决现有技术中因无法对用于发送验证信息的线路的故障进行预警,导致在线路故障时影响网络账号正常使用的问题。
[0007]为了实现上述目的,根据本发明实施例的一个方面,提供了一种信道故障的预警方法。该方法包括:获取重复请求信息,其中,重复请求信息,用于根据重复请求信息重新发送数据信息;根据重复请求信息,确定与重复请求信息对应的用于发送数据信息的发送信道,信道为发送数据信息的通道;计算在预定时间内与发送信道对应的重复请求信息的重复请求数量;根据重复请求数量,判断发送信道是否存在故障。
[0008]进一步的,计算在预定时间内与信道对应的重复请求信息的重复请求数量包括:
[0009]从重复请求信息的历史记录中,确定与每条重复请求记录对应的用于接收数据信息的接收地址;根据历史记录,确定与重复请求记录对应的发送数据信息的发送信道;根据接收地址和历史记录,按获取到重复请求信息的时间生成重复请求记录与发送信道的对照表;根据对照表,确定在预定时间内与发送信道对应的重复请求数量。
[0010]进一步的,根据重复请求数量,判断发送信道是否存在故障包括:获取预先设置的计算系数和预先设置的判断阈值;根据计算系数和重复请求数量,计算与发送信道对应的计算值;将计算值与判断阈值进行比对,判断发送信道是否存在故障。
[0011]进一步的,重复请求数量包括连续重复数量和非连续重复数量,其中,在根据对照表,确定在预定时间内与发送信道对应的重复请求数量之后,还包括:根据对照表,计算得出在预定时间内与接收地址对应的连续重复数量;根据重复请求数量和连续重复数量,计算得出非连续重复数量。
[0012]进一步的,根据重复请求数量,判断发送信道是否存在故障包括:获取预先设置的第一计算系数、第二计算系数和判断阈值;根据第一计算系数和连续重复数量,计算发送信道的第一计算值;根据第二计算系数和非连续重复数量,计算发送信道的第二计算值;根据第一计算值和第二计算值,计算与发送信道对应的计算值;将计算值与判断阈值进行比对,判断发送信道是否存在故障。
[0013]进一步的,在根据重复请求数量,判断发送信道是否存在故障之后,方法还包括:当确定发送信道存在故障时,发送报警信息。
[0014]为了实现上述目的,根据本发明实施例的另一方面,提供了一种信道故障的预警装置,该装置包括:获取模块,用于获取重复请求信息,其中,重复请求信息,用于根据重复请求信息重新发送数据信息;确定模块,用于根据重复请求信息,确定与重复请求信息对应的用于发送数据信息的发送信道,信道为发送数据信息的通道;计算模块,用于计算在预定时间内与发送信道对应的重复请求信息的重复请求数量;判断模块,用于根据重复请求数量,判断发送信道是否存在故障。
[0015]进一步的,计算模块包括:第一子确定模块,用于从重复请求信息的历史记录中,确定与每条重复请求记录对应的用于接收数据信息的接收地址;第二子确定模块,用于根据历史记录,确定与重复请求记录对应的发送数据信息的发送信道;第一子获取模块,用于根据接收地址和历史记录,按获取到重复请求信息的时间生成重复请求记录与发送信道的对照表;第三子确定模块,用于根据对照表,确定在预定时间内与发送信道对应的重复请求数量。
[0016]进一步的,判断模块包括:第二子获取模块,用于获取预先设置的计算系数和预先设置的判断阈值;子处理模块,用于根据计算系数和重复请求数量,计算与发送信道对应的计算值;子判断模块,用于将计算值与判断阈值进行比对,判断发送信道是否存在故障。
[0017]进一步的,装置还包括:报警模块,用于当确定发送信道存在故障时,发送报警信息。
[0018]根据发明实施例,通过获取重复请求信息,其中,重复请求信息,用于根据重复请求信息重新发送数据信息;根据重复请求信息,确定与重复请求信息对应的用于发送数据信息的发送信道,信道为发送数据信息的通道;计算在预定时间内与发送信道对应的重复请求信息的重复请求数量;根据重复请求数量,判断发送信道是否存在故障,实现了通过重复请求信息来对信道故障进行预警的效果,达到了对信道的工作状态进行监控的目的,从而解决了现有技术中因无法对用于发送验证信息的线路的故障进行预警,导致在线路故障时影响网络账号正常使用的问题。
【附图说明】
[0019]构成本申请的一部分的附图用来提供对本发明的进一步理解,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图中:
[0020]图1是根据本发明实施例一的一种信道故障的预警方法的流程图;
[0021]图2是根据本发明实施例一可选的一种信道故障的预警方法的流程图;
[0022]图3是根据本发明实施例二的一种信道故障的预警装置的结构示意图;以及
[0023]图4是根据本发明实施例二可选的一种信道故障的预警装置的结构示意图。
【具体实施方式】
[0024]需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本发明。
[0025]为了使本技术领域的人员更好地理解本发明方案,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分的实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都应当属于本发明保护的范围。
[0026]需要说明的是,本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本发明的实施例。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
[0027]实施例1
[0028]本发明实施例提供了一种信道故障的预警方法,图1是根据本发明实施例的信道故障的预警方法的流程图,如图1所示,该方法包括步骤如下:
[0029]步骤S11,获取重复请求信息,其中,重复请求信息,用于根据重复请求信息重新发送数据信息。
[0030]步骤S13,根据重复请求信息,确定与重复请求信息对应的用于发送数据信息的发送信道,信道为发送数据信息的通道。
[0031]步骤S15,计算在预定时间内与发送信道对应的重复请求信息的重复请求数量。
[0032]步骤S17,根据重复请求数量,判断发送信道是否存在故障。
[0033]通过上述步骤Sll至步骤S17,通过接收客户端发送的重复请求信息,确定之前向发送重复请求信息的客户端发送数据信息所使用的发送通道,通过计算在预定时间内获取到的与发送数据信息的通道对应的重复请求信息的数量,来判断该信道是否存在故障。利用上述实施例,实现了通过重复请求信息来对信道故障进行预警的效果,达到了对信道的工作状态进行监控的目的,从而解决了现有技术中因无法对用于发送验证信息的线路的故障进行预警,导致在线路故障时影响网络账号正常使用的问题。
[0034]作为一个可选实施例,可以根据获取到的重复请求信息,建立历史记录。在历史记录中,以接收地址作为唯一索引,根据接收地址,可以统计某一个客户端连续发送重复请
再多了解一些
当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1