一种防止短信轰炸方法及装置与流程

1.本文涉及通信技术领域，尤其涉及一种防止短信轰炸方法及装置。


背景技术：

2.随着手机逐渐成为人们生活不可或缺的通信工具，需要手机验证的地方越来越多，比如注册、登录、购物等，都需要往手机下发验证码，“短信轰炸”就是集成海量网站的短信验证码接口，无需使用浏览器打开短信发送页面、直接请求短信验证码url，循环向指定手机号发送注册、密码找回等验证码请求，以达到骚扰目的。常见于用户因网购中给商家差评遭到商家恶意报复，商家利用“短信轰炸”平台持续向用户手机号发送验证短信(1分钟内可向同一手机号发送超过100条短信)。
3.网站或app提供的短信验证码功能，极易被不法分子收集并利用，包装成“短信轰炸机”进行兜售，成为骚扰手机用户的武器，不仅严重威胁网络和现实安全秩序，且因短信验证码为收费服务，长期被“短信轰炸机”利用还会对网站或app运营方造成财产损失。此外，以骚扰短信形式侵扰个人安宁，不仅会对网站声誉造成负面影响，还会面临一定的法律风险。
4.目前企业预防“短信轰炸”主要是使用图片验证码、滑动验证码、逻辑验证码、文字点选等手段来识别人机、防止恶意程序调用。但上述方式需要用户手动操作，操作难度较高，极易导致验证码输入错误，用户体验较差。且随着人工智能、机器学习、图像识别技术的快速发展，图片验证码、滑动验证码、逻辑验证码等均面临绕过风险。
5.因此，如何在用户无感知的前提下，有效避免网站或app短信验证码接口被恶意程序利用、沦为“短信轰炸”武器，成为目前亟待解决的问题。


技术实现要素：

6.本文用于解决现有技术中预防短信轰炸的方法，存在用户体验差，且随着人功能智能、机器学习等快速发展，限制用户发起获取验证码请求的方式容易被绕过，从而无法准确地防止短信恶意攻击。另外，现有技术中预防短信轰炸的方法还无法解决短信验证接口被短信轰炸机利用向大量、不同短信接收方分别发送少量骚扰短信，积少成多造成网站或app短信资源浪费的问题，网站或app运营方仍然面临财产损失和声誉风险。
7.为了解决上述技术问题，本文一方面提供一种防止短信轰炸的方法，包括：
8.识别短信验证码发送请求，得到目标业务场景及目标短信接收方/发送方信息；
9.从短信接收/发送统计模块中，获取与目标业务场景及目标短信接收方/发送方匹配的各时间周期内短信接收/发送统计数值，所述短信接收/发送统计模块用于计算短信接收/发送统计数值；
10.从短信防轰炸控制阈值配置信息中，获取与目标业务场景及各时间周期匹配的短信接收/发送阈值，所述短信防轰炸控制阈值配置信息存储有业务场景、时间周期信息及短信接收/发送阈值的对应关系；
11.判断是否存在其中一个时间周期内的短信接收/发送统计数值超过相应的短信接收/发送阈值，若是，则拒绝响应所述短信验证码发送请求。
12.作为本文进一步实施例中，所述短信防轰炸控制阈值配置信息的短信接收/发送阈值包括：短信阈值字段及阈值类型字段。
13.作为本文进一步实施例中，所述方法还包括：根据短信验证码发送请求的分布规律，实时调整时间周期。
14.作为本文进一步实施例中，所述短信防轰炸控制阈值配置信息中的各业务场景下各时间周期对应的短信接收/发送阈值根据页面访问量/用户访问量确定。
15.作为本文进一步实施例中，若存在一个时间周期内的短信接收方统计数值超过相应的短信接收阈值，则确认所述目标短信接收方异常；
16.判断最近预定时间段内所有异常的目标短信接收方数量是否小于预定值，若是，则拒绝响应所述短信验证码发送请求，若否，则发送异常提示信息。
17.作为本文进一步实施例中，识别短信验证码发送请求得到目标短信收/发信息方后，还包括：
18.从黑名单中查询目标短信发送方，若查询成功，则拒绝响应所述短信验证码发送请求，若查询失败，则执行获取短信接收方/发送方统计数值的步骤；
19.其中，所述黑名单中存储有具有短信轰炸行为的发送方信息。
20.本文另一方面，提供一种防止短信轰炸系统，包括：
21.短信接收统计模块，用于实时计算各业务场景下各短信接收方的各时间周期内的短信接收统计数值；
22.短信发送统计模块，用于实时计算各业务场景下各短信发送方的各时间周期内的短信发送统计数值；
23.短信防轰炸控制规则模块，用于存储短信防轰炸控制阈值配置信息，其中，所述短信防轰炸控制阈值配置信息中存储有业务场景、时间周期信息及短信接收/发送阈值的对应关系；
24.短信接收方/发送方防轰炸校验模块，用于识别短信验证码发送请求，得到目标业务场景及目标短信接收方/发送方信息；从短信接收统计模块及短信接收发送统计模块中，获取与目标业务场景及目标短信接收方/发送方匹配的各时间周期内短信接收/发送统计数值；从短信防轰炸控制阈值配置信息中，获取与目标业务场景及各时间周期匹配的短信接收/发送阈值；判断是否存在其中一个时间周期内的短信接收/发送统计数值超过相应的短信接收/发送阈值，若是，则拒绝响应所述短信验证码发送请求。
25.本文又一方面，还提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现前述任一实施例所述方法。
26.本文又一方面，还提供一种计算机存储介质，其上存储有计算机程序，所述计算机程序被计算机设备的处理器运行时，执行根据前述任一实施例所述方法。
27.本文又一方面，还提供一种计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序被处理器执行时实现前述任一实施例所述方法。
28.本文提供的防止短信轰炸方法及装置，通过将目标业务场景及多个时间周期内的
短信接收/发送统计数据加入防止短信轰炸的策略中，为各业务场景的各时间周期配置短信接收/发送阈值，能够根据实际需求从多个时间周期粒度限制短信接收方接收短信的数量以及短信发送方发送验证码请求的数量，既能避免单个短信接收方遭受短信轰炸，又能解决“短信轰炸机”利用短信发送方的短信验证码接口向不同短信接收方发送骚扰短信的行为，保护网站或app运营方免遭财产损失。
29.为让本文的上述和其他目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附图式，作详细说明如下。
附图说明
30.为了更清楚地说明本文实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本文的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
31.图1示出了本文实施例防止短信轰炸系统的结构图；
32.图2示出了本文实施例防止短信轰炸方法的第一流程图；
33.图3示出了本文实施例防止短信轰炸方法的第二流程图；
34.图4示出了本文实施例防止短信轰炸方法的第三流程图；
35.图5示出了本文实施例防止短信轰炸装置的结构图；
36.图6示出了本文实施例计算机设备结构图。
37.附图符号说明：
38.110、客户端；
39.120、服务器端；
40.130、目标短信接收方；
41.510、短信接收统计模块；
42.520、短信发送统计模块；
43.530、短信防轰炸控制规则模块；
44.541、短信接收方防轰炸校验模块；
45.542、短信发送方防轰炸校验模块；
46.543、短信发送模块；
47.602、计算机设备；
48.604、处理器；
49.606、存储器；
50.608、驱动机构；
51.610、输入/输出模块；
52.612、输入设备；
53.614、输出设备；
54.616、呈现设备；
55.618、图形用户接口；
56.620、网络接口；
57.622、通信链路；
58.624、通信总线。
具体实施方式
59.下面将结合本文实施例中的附图，对本文实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本文一部分实施例，而不是全部的实施例。基于本文中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本文保护的范围。
60.需要说明的是，本文的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本文的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、装置、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
61.本说明书提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或装置产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行。
62.需要说明的是，本文的防止短信轰炸方法及装置可用于金融领域，也可用于除金融领域之外的任意领域，本文的防止短信轰炸方法及装置的应用领域不做限定。
63.需要说明的是，本技术所涉及的信息(包括但不限于短信接收方信息、短信发送方信息等)，均为经用户授权或者经过各方充分授权的信息和数据。
64.发明人通过分析现有防止短信轰炸发现，现有技术存在如下缺点：
65.1.图片验证码、滑动验证码、逻辑验证码、文字点选等预防“短信轰炸”的方式需要用户手动操作，操作难度较高，极易导致验证码输入错误，用户体验较差。
66.2.随着人工智能、机器学习、图像识别技术的快速发展，图片验证码、滑动验证码、逻辑验证码等均面临绕过风险。
67.3.现有技术仅针对短信接收方进行风险控制，仅能一定程度上保证单个手机用户无法遭受短信骚扰，但无法解决短信验证码接口被“短信轰炸机”利用向大量、不同手机用户分别发送少量骚扰短信，积少成多造成网站或app短信资源浪费的问题，网站或app运营方仍然面临财产损失和声誉风险。
68.4.现有技术使用统一的控制规则，无法根据实际业务场景(注册、登录、购物等)定制风险阈值。
69.为了解决现有技术存在的上述技术问题，本文提供一种防止短信轰炸系统，具体的，如图1所示，包括：客户端110及服务器端120。
70.客户端110为可供用户上网的终端设备，用户可通过客户端发起注册、登录、购物等业务场景下的短信验证码发送请求。
71.服务器端120设置于业务场景响应服务器侧，用于在接收到短信验证码发送请求
后，执行如下处理过程：识别短信验证码发送请求，得到目标业务场景及目标短信接收方/发送方；从短信接收/发送统计模块中，获取与目标业务场景及目标短信接收方/发送方匹配的各时间周期内短信接收/发送统计数值，所述短信接收/发送统计模块用于计算短信接收/发送统计数值；从短信防轰炸控制阈值配置信息中，获取与目标业务场景及各时间周期匹配的短信接收/发送阈值，所述短信防轰炸控制阈值配置信息存储有业务场景、时间周期信息及短信接收/发送阈值的对应关系；判断是否存在其中一个时间周期内的短信接收/发送统计数值超过相应的短信接收/发送阈值，若是，则拒绝响应所述短信验证码发送请求，若否，则发送短信验证码至目标短信接收方130。
72.其中，目标短信接收方为接收验证码短信的终端设备，例如为手机号、邮箱等，不同手机号、邮箱代表不同的接收方。
73.目标短信发送方为触发验证码获取请求发送操作的设备，正常情况是用户使用的电脑或移动设备，目标短信发送方可通过设备序列号、ip地址等区分。
74.时间周期内短信接收统计数值指的是在时间周期内短信接收方已接收短信的统计量，时间周期内短信发送统计数值指的是在时间周期内短信发送方已发起请求验证码的统计量。具体实施时，短信接收统计数值及短信发送统计数值的时间周期可根据实际情况进行设定，二者可以相同，也可以不同，本文对此不作限定。
75.本实施例通过将目标业务场景及多个时间周期内的短信接收/发送统计数据加入防止短信轰炸的策略中，为各业务场景的各时间周期配置短信接收/发送阈值，能够根据实际需求从多个时间周期粒度限制短信接收方/短信发送方的接收短信的数量，既能避免单个短信接收方遭受短信轰炸，又能解决“短信轰炸机”利用短信发送方的短信验证码接口向不同短信接收方发送骚扰短信的行为，保护网站或app运营方免遭财产损失。
76.本文一实施例中，还提供一种应用于业务场景响应服务器的防止短信轰炸的方法，本实施例实施之前需预先确定短信防轰炸控制阈值配置信息，即设定各业务场景下在各时间周期内短信接收阈值及短信发送阈值。
77.具体的，如图2所示，防止短信轰炸的方法包括：
78.步骤201，接收并识别短信验证码发送请求，得到目标业务场景及目标短信接收方/发送方；
79.步骤202，从短信接收/发送统计模块中，获取与目标业务场景及目标短信接收方/发送方匹配的各时间周期内短信接收/发送统计数值，短信接收/发送统计模块用于计算短信接收/发送统计数值；
80.步骤203，从短信防轰炸控制阈值配置信息中，获取与目标业务场景及各时间周期匹配的短信接收/发送阈值；
81.步骤204，判断是否存在其中一个时间周期内的短信接收/发送统计数值超过相应的短信接收/发送阈值，若是，则拒绝响应短信验证码发送请求，若否，则响应短信验证码发送请求，发送短信至接收方，记录短信接收方的接收行为，记录短信发送方的发送行为。
82.详细的说，短信防轰炸控制阈值配置信息可由用户根据实际应用场景(注册、登录、购物等)定制风险阈值，支持实时调整，支持不同时间周期，能够满足不同业务场景、业务淡旺季的短信交易风险控制。
83.上述步骤201中，短信验证码发送请求中包括：业务场景、短信接收方、短信发送
方。业务场景例如为注册、登录、购物，可根据用户获取验证码的目的进行划分。短信接收方及短信发送方参考前述描述，此处不再详述。本文所述的“/”为并列符，用于表示符号两侧内容为并列内容。
84.上述步骤202中，短信接收/发送统计模块例如为两个统计程序，其中一统计程序负责各业务场景及短信接收方在各时间周期内短信接收量的统计数值，另一统计程序负责各业务场景及短信发送方在各时间周期内短信请求发送量的统计数值。两个统计程序的时间周期可以相同也可以不同，可根据实际需求由工作人员设定，例如为1分钟，1小时及1天等。
85.实施时，短信接收/发送统计模块统计信息以key/value形式存储，例如存储于redis数据库中，redis数据库支持多种数据类型，包括string(字符串)、list(链表)、set(集合)、zset(有序集合)和hash(哈希)，支持push/pop、add/remove及取交集、并集、差集等丰富的操作，可满足不同场景下的存储需求，适用于需要支撑海量数据存储、高并发请求的网站或app。
86.举例来说，短信发送统计模块统计的不同业务场景、不同短信发送方在不同时间周期内的统计数值采用如下数据格式存储：
87.key/value＝transcode:id:period/count。
88.各项含义说明如下：
89.transcode：交易码，不同业务场景区分控制使用，例如注册交易可设为“register”，登录交易可设为“login”。
90.id：限制项目，短信发送流水id为发送方(设备ip或移动设备序列号)，如“192.168.xxx.xxx”。
91.period：时间周期，可分别从1m(分钟)、1h(小时)、1d(小时)三种不同时间周期对短信发送频率及次数进行限制。
92.count：计数值，不同时间周期id已发送的短信验证码次数累计。
93.例如短信发送统计模块统计的信息如下：
94.register:192.168.xxx.xxx:1m/1；
95.register:192.168.xxx.xxx:1h/3；
96.register:192.168.xxx.xxx:1d/5。
97.上述信息含义为：192.168.xxx.xxx的设备，通过注册交易(register)，1分钟内已发送1条短信息，1小时内已发送3条短信息，1天内已发送5条短信息，接近正常用户操作频率。
98.相应的，短信接收统计模块统计的不同业务场景、不同短信接收方在不同时间周期内的统计数值采用如下数据格式存储：
99.key/value＝transcode:id:period/count
100.各项含义说明：
101.transcode：交易码，不同业务场景区分控制使用，注册交易可设为“register”，登录交易可设为“login”。
102.id：限制项目，短信接收流水id为接收方手机号码，如“188xxxx2048”。
103.period：时间周期，可分别从1m(分钟)、1h(小时)、1d(天)三种不同时间周期对短
信接收频率及次数进行限制。
104.count：计数值，不同时间周期已发送的短信验证码次数累计。
105.本文各时间周期的开始时刻通过如下方式确定：首次接收到用户验证码请求时，根据配置的风控规则(即短信防轰炸控制阈值配置信息)，同时开启不同时间周期的累计计数，并根据时间周期设定计数周期的过期时间。后续验证码请求，在已存在的计数周期内加入累计计数，若某些计数周期已过期(每秒、每分这种)，需重新开启新的计数周期的计数，并设定计数过期时间。
106.例如短信接收统计模块统计的信息如下：
107.register:188xxxx2048:1m/1；
108.register:188xxxx2048:1h/3；
109.register:188xxxx2048:1d/5。
110.意为：通过网站或app的注册交易(register)，1分钟内已向手机号码188xxxx2048发送3条短信息，1小时内已向手机号码188xxxx2048发送5条短信息，1天内已向手机号码188xxxx2048发送8条短信息，接近正常用户操作频率。
111.步骤203中的短信防轰炸控制阈值配置信息可以以key-value形式存储。实施时，为了便于区分短信阈值具体为接收阈值还是发送阈值，可通过设置短信阈值字段及阈值类型字段区分，短信阈值字段记录具体短信阈值，阈值类型字段记录为接收或发送。
112.具体的，短信防轰炸控制阈值按照如下数据格式存储：
113.key/value＝type:transcode:period/limit。
114.各项含义说明如下：
115.type：阈值类型，例如，接收阈值为“receive”，发送阈值为“send”。
116.transcode：交易码，不同业务场景区分控制使用，例如，注册交易可设为“register”，登录交易可设为“login”。
117.period：时间周期，可分别从1m(分钟)、1h(小时)、1d(天)三种不同时间周期对短信发送频率及次数进行限制，实施时，还可用其它周期表示，各时间周期的计量单位可以均选择s(秒)。
118.limit：阈值限制，特定时间周期内允许的次数上限。
119.例如短信防轰炸控制阈值配置信息中如下信息：
120.receive:register:1m/1；
121.receive:register:1h/5；
122.receive:register:1d/10。
123.上述信息含义为：通过注册交易(register)向指定手机号码发送的短信验证码，需满足：1分钟内向该手机号码发送的短信数量不得超过1条，1小时内向该手机号码发送的短信数量不得超过5条，1天内向该手机号码发送的短信数量不得超过10条。
124.又例如短信防轰炸控制阈值配置信息中如下信息：
125.send:register:1m/10；
126.send:register:1h/50；
127.send:register:1d/100。
128.上述信息含义为：特定发送方(或设备)，通过注册交易(register)发送的短信验
证码，需满足：1分钟内允许该设备发送的短信数量不得超过10条，1小时内允许该设备发送的短信数量不得超过50条，1天内允许该设备发送的短信数量不得超过100条。
129.本实施例通过将目标业务场景及多个时间周期内的短信接收/发送统计数据加入防止短信轰炸的策略中，为各业务场景的各时间周期配置短信接收/发送阈值，能够根据实际需求从多个时间周期粒度限制短信接收方/短信发送方的接收短信的数量，既能避免单个短信接收方遭受短信轰炸，又能解决“短信轰炸机”利用短信发送方的短信验证码接口向不同短信接收方发送骚扰短信的行为，保护网站或app运营方免遭财产损失。
130.本文一实施例中，短信防轰炸控制阈值配置信息中的时间周期可由人工进行配置，还可在分析短信验证码发送请求的分布规律的基础上，自动进行调整，具体的，例如一段时间内(一天、一个月、一年等中的某一时段)短信验证码发送比较集中(例如举办大型促销活动)，则在该段时间时，设置时间周期小一些，若分布规律比较分散，则设置时间周期大一些。
131.本文一实施例中，短信防轰炸控制阈值配置信息中的各业务场景下各时间周期对应的短信接收/发送阈值根据页面访问量/用户访问量确定，这样既能保证正常交易不受影响，又能识别并拦截异常行为。本文所述的页面为短信验证请求发送页面。页面访问量指的是网站的页面浏览量或者点击量，用户每次对网站的访问或点击均被记录，用户对同一页面的多次访问、同一按钮的多次点击，访问量累计。用户访问量指的是访问网站的一台手机或电脑客户端，可根据ip地址、硬件设备号来区分访客数，用户在一段时间内重复访问，算作同一次访问量。页面访问量/用户访问量得到单用户使用短信验证功能的平均次数。具体实施时，可根据单用户使用短信验证功能的平均次数制定短信接收/发送阈值。后期根据业务量增减情况随时调整阈值大小。
132.本文一实施例中，为了避免因网络故障、网站或app等引起短信接收方接收到的验证码异常的情况发生，如图3所示，上述步骤204判断结果是，即若存在一个时间周期内的短信接收方统计数值超过相应的短信接收阈值，则确认所述目标短信接收方异常。
133.防止短信轰炸的方法还包括：步骤205，判断最近预定时间段内所有异常的目标短信接收方数量是否小于预定值，若是，则拒绝响应所述短信验证码发送请求，若否，则发送异常提示信息。
134.本文一实施例中，为了提高验证码请求效率，如图4所示，上述步骤201之后，还包括：
135.步骤201’，从黑名单中查询目标短信发送方，若查询成功，则拒绝响应短信验证码发送请求，若查询失败，则执行步骤202，其中，所述黑名单中存储有具有短信轰炸行为的发送方信息。黑名单可根据历史短信攻击行为的发送方确定。
136.基于同一发明构思，本文还提供一种防止短信轰炸装置，如下面的实施例所述。由于防止短信轰炸装置解决问题的原理与防止短信轰炸方法相似，因此防止短信轰炸装置的实施可以参见防止短信轰炸方法，重复之处不再赘述。
137.具体的，如图5所示，防止短信轰炸的装置包括：
138.短信接收统计模块510，用于实时计算各业务场景下各短信接收方的各时间周期内的短信接收统计数值；
139.短信发送统计模块520，用于实时计算各业务场景下各短信发送方的各时间周期
内的短信发送统计数值；
140.短信防轰炸控制规则模块530，用于存储短信防轰炸控制阈值配置信息，其中，所述第一短信防轰炸控制阈值配置信息中存储有业务场景、时间周期信息及短信接收/发送阈值的对应关系；
141.短信接收方/发送方防轰炸校验模块，具体的，短信接收方/发送方防轰炸校验模块包括：短信接收方防轰炸校验模块541、短信发送方防轰炸校验模块542及短信发送模块543。
142.短信接收方防轰炸校验模块541用于识别短信验证码发送请求，得到目标业务场景及目标短信接收方信息；从短信接收统计模块中，获取与目标业务场景及目标短信接收方匹配的各时间周期内短信接收统计数值；从短信防轰炸控制阈值配置信息中，获取与目标业务场景及各时间周期匹配的短信接收阈值；判断是否存在其中一个时间周期内的短信接收统计数值超过相应的短信接收阈值，发送判断结果至短信发送模块543。
143.短信发送方防轰炸校验模块542识别短信验证码发送请求，得到目标业务场景及目标短信发送方信息；从短信发送统计模块中，获取与目标业务场景及目标短信发送方匹配的各时间周期内短信发送统计数值；从短信防轰炸控制阈值配置信息中，获取与目标业务场景及各时间周期匹配的短信发送阈值；判断是否存在其中一个时间周期内的短信发送统计数值超过相应的短信发送阈值，发送判断结果至短信发送模块543。
144.短信发送模块543根据短信接收方防轰炸校验模块541及短信发送方防轰炸校验模块542判断结果确定是否生成验证码，具体的，若其中一判断结果为是，则拒绝响应所述短信验证码发送请求，若否，则向目标短信接收方发送短信验证码，并按照约定格式(例如，key/value＝transcode:id:period/count)记录短信发送行为、短信接收行为。
145.本文提供的防止短信轰炸方法及装置，立足网站或app，在保障用户体验的基础上，降低“短信轰炸”对网站或app带来的财产损失、声誉风险和法律风险，具体的，本文能够实现如下技术效果：
146.(1)在用户无感知的前提下，避免网站或app短信验证码接口被恶意程序利用、沦为“短信轰炸”武器，在保证安全性的基础上有效提升用户体验。
147.(2)同时针对短信发送方及短信接收方进行控制，既能避免单个手机用户遭受短信轰炸，又能解决“短信轰炸机”利用短信验证码接口向不同手机用户发送骚扰短信的行为，保护网站或app运营方免遭财产损失。
148.(3)能够根据实际业务场景(注册、登录、购物等)定制风险阈值，支持实时调整，支持不同时间周期，能够满足不同业务场景、业务淡旺季的短信交易风险控制。
149.本文一实施例中，还提供一计算机设备，如图6所示，计算机设备602可以包括一个或多个处理器604，诸如一个或多个中央处理单元(cpu)，每个处理单元可以实现一个或多个硬件线程。计算机设备602还可以包括任何存储器606，其用于存储诸如代码、设置、数据等之类的任何种类的信息。非限制性的，比如，存储器606可以包括以下任一项或多种组合：任何类型的ram，任何类型的rom，闪存设备，硬盘，光盘等。更一般地，任何存储器都可以使用任何技术来存储信息。进一步地，任何存储器可以提供信息的易失性或非易失性保留。进一步地，任何存储器可以表示计算机设备602的固定或可移除部件。在一种情况下，当处理器604执行被存储在任何存储器或存储器的组合中的相关联的指令时，计算机设备602可以
执行相关联指令的任一操作。计算机设备602还包括用于与任何存储器交互的一个或多个驱动机构608，诸如硬盘驱动机构、光盘驱动机构等。
150.计算机设备602还可以包括输入/输出模块610(i/o)，其用于接收各种输入(经由输入设备612)和用于提供各种输出(经由输出设备614))。一个具体输出机构可以包括呈现设备616和相关联的图形用户接口618(gui)。在其他实施例中，还可以不包括输入/输出模块610(i/o)、输入设备612以及输出设备614，仅作为网络中的一台计算机设备。计算机设备602还可以包括一个或多个网络接口620，其用于经由一个或多个通信链路622与其他设备交换数据。一个或多个通信总线624将上文所描述的部件耦合在一起。
151.通信链路622可以以任何方式实现，例如，通过局域网、广域网(例如，因特网)、点对点连接等、或其任何组合。通信链路622可以包括由任何协议或协议组合支配的硬连线链路、无线链路、路由器、网关功能、名称服务器等的任何组合。
152.对应于图2至图4中的方法，本文实施例还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述方法的步骤。
153.本文实施例还提供一种计算机可读指令，其中当处理器执行所述指令时，其中的程序使得处理器执行如图2至图4所示的方法。
154.应理解，在本文的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本文实施例的实施过程构成任何限定。
155.还应理解，在本文实施例中，术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系。例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
156.本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本文的范围。
157.所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
158.在本文所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口、装置或单元的间接耦合或通信连接，也可以是电的，机械的或其它的形式连接。
159.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本文实施例方案的
目的。
160.另外，在本文各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
161.所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本文的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本文各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-only memory)、随机存取存储器(ram，random access memory)、磁碟或者光盘等各种可以存储程序代码的介质。
162.本文中应用了具体实施例对本文的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本文的方法及其核心思想；同时，对于本领域的一般技术人员，依据本文的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本文的限制。