一种访问控制方法及装置与流程

1.本技术涉及计算机技术领域，特别是涉及一种访问控制方法及装置。


背景技术：

2.随着技术的飞速发展，大量的用户使用手机上网以享用网络服务，其可以对用户的工作和生活带来极大方便。
3.在上网的过程中，用户可以使用手机与服务提供商的服务端之间进行数据交互，例如，在购物的场景中，用户可以使用手机从电子商务的服务端中获取购物页面并显示购物页面，以供用户通过购物页面购物等。再例如，在支付场景中，用户可以使用手机从金融机构的服务端中获取支付页面并显示支付页面，以供用户通过支付页面支付等。


技术实现要素：

4.本技术示出了一种访问控制方法及装置。
5.第一方面，本技术示出了一种访问控制方法，应用于电子设备，所述方法包括：
6.接收终端发送的基于中间层协议的握手请求消息，所述中间层协议包括应用于计算机网络模型中的应用层与传输层之间的协议；
7.获取历史总数量，所述历史总数量包括在历史时间段接收到的历史握手请求消息的总数量，所述历史握手请求消息包括基于所述中间层协议的握手请求消息，历史时间段位于当前时刻之前；
8.在所述历史总数量小于预设数量的情况下，根据所述终端发送的握手请求消息向所述终端返回基于所述中间层协议的握手响应消息。
9.在一个可选的实现方式中，所述中间层协议包括安全套接层协议ssl或安全传输层协议tls。
10.在一个可选的实现方式中，所述方法还包括：
11.在所述历史总数量大于或等于预设数量的情况下，确定所述终端发送的握手请求消息是否触发所述电子设备的控流条件；
12.在所述终端发送的握手请求消息未触发所述电子设备的控流条件的情况下，根据所述终端发送的握手请求消息向所述终端返回基于所述中间层协议的握手响应消息。
13.在一个可选的实现方式中，所述方法还包括：
14.在所述终端发送的握手请求消息触发所述电子设备的控流条件的情况下，停止对所述终端发送的握手请求消息处理。
15.在一个可选的实现方式中，所述方法还包括：
16.在所述终端发送的握手请求消息触发所述电子设备的控流条件的情况下，若已建立与所述终端之间的位于所述传输层的通信连接，断开与所述终端之间的位于所述传输层的通信连接。
17.在一个可选的实现方式中，所述方法还包括：
18.根据所述终端发送的握手请求消息，增加已记录的历史总数量。
19.在一个可选的实现方式中，所述终端发送的握手请求消息用于请求与分布式服务系统中的多个服务端中的一个服务端之间握手；
20.所述获取历史总数量，包括：
21.获取所述分布式服务系统中的各个服务端的历史数量，服务端的历史数量包括服务端在历史时间段接收到的历史握手请求消息的总数量，历史握手请求消息包括基于所述中间层协议的握手请求消息；
22.计算所述分布式服务系统中的各个服务端的历史数量之间的总和，得到所述历史总数量。
23.在一个可选的实现方式中，所述获取历史总数量，包括：
24.根据所述终端发送的握手请求消息获取所述终端所请求的域名；
25.获取所述域名对应的历史总数量，所述域名对应的历史总数量包括在历史时间段接收到的请求所述域名的基于所述中间层协议的握手请求消息的总数量。
26.在一个可选的实现方式中，所述确定所述终端发送的握手请求消息是否触发所述电子设备的控流条件，包括：
27.根据所述历史总数量以及预设数量获取控流比例。
28.根据所述控流比例确定所述终端发送的握手请求消息是否触发所述电子设备的控流条件。
29.在一个可选的实现方式中，所述根据所述控流比例确定所述终端发送的握手请求消息是否触发所述电子设备的控流条件，包括：
30.设置多个预设标签；
31.根据所述控流比例，在所述多个预设标签中筛选部分预设标签；以及，在所述多个预设标签中为所述终端发送的握手请求消息随机选择一个预设标签；
32.在选择的预设标签位于所述部分预设标签的情况下，确定所述终端发送的握手请求消息触发所述电子设备的控流条件；
33.或者，
34.在选择的预设标签不位于所述部分预设标签的情况下，确定所述终端发送的握手请求消息未触发所述电子设备的控流条件。
35.在一个可选的实现方式中，所述确定所述终端发送的握手请求消息是否触发所述电子设备的控流条件，包括：
36.根据所述终端发送的握手请求消息获取所述终端的标识信息；
37.在白名单中查找所述终端的标识信息；在白名单中查找到所述终端的标识信息的情况下，确定所述终端发送的握手请求消息未触发控流条件；或者，在白名单中未查找到所述终端的标识信息的情况下，确定所述终端发送的握手请求消息触发控流条件。
38.或者，
39.在黑名单中查找所述终端的标识信息；在黑名单中查找到所述终端的标识信息的情况下，确定所述终端发送的握手请求消息触发控流条件；或者，在黑名单中未查找到所述终端的标识信息的情况下，确定所述终端发送的握手请求消息未触发控流条件。
40.第二方面，本技术示出了一种访问控制装置，应用于电子设备，所述装置包括：
41.接收模块，用于接收终端发送的基于中间层协议的握手请求消息，所述中间层协议包括应用于计算机网络模型中的应用层与传输层之间的协议；
42.获取模块，用于获取历史总数量，所述历史总数量包括在历史时间段接收到的历史握手请求消息的总数量，所述历史握手请求消息包括基于所述中间层协议的握手请求消息，历史时间段位于当前时刻之前；
43.返回模块，用于在所述历史总数量小于预设数量的情况下，根据所述终端发送的握手请求消息向所述终端返回基于所述中间层协议的握手响应消息。
44.在一个可选的实现方式中，所述中间层协议包括安全套接层协议ssl或安全传输层协议tls。
45.在一个可选的实现方式中，所述装置还包括：
46.确定模块，用于在所述历史总数量大于或等于预设数量的情况下，确定所述终端发送的握手请求消息是否触发所述电子设备的控流条件；
47.所述返回模块还用于：在所述终端发送的握手请求消息未触发所述电子设备的控流条件的情况下，根据所述终端发送的握手请求消息向所述终端返回基于所述中间层协议的握手响应消息。
48.在一个可选的实现方式中，所述装置还包括：
49.停止模块，用于在所述终端发送的握手请求消息触发所述电子设备的控流条件的情况下，停止对所述终端发送的握手请求消息处理。
50.在一个可选的实现方式中，所述装置还包括：
51.断开模块，用于在所述终端发送的握手请求消息触发所述电子设备的控流条件的情况下，若已建立与所述终端之间的位于所述传输层的通信连接，断开与所述终端之间的位于所述传输层的通信连接。
52.在一个可选的实现方式中，所述装置还包括：
53.增加模块，用于根据所述终端发送的握手请求消息，增加已记录的历史总数量。
54.在一个可选的实现方式中，所述终端发送的握手请求消息用于请求与分布式服务系统中的多个服务端中的一个服务端之间握手；
55.所述获取模块包括：
56.第一获取单元，用于获取所述分布式服务系统中的各个服务端的历史数量，服务端的历史数量包括服务端在历史时间段接收到的历史握手请求消息的总数量，历史握手请求消息包括基于所述中间层协议的握手请求消息；
57.计算单元，用于计算所述分布式服务系统中的各个服务端的历史数量之间的总和，得到所述历史总数量。
58.在一个可选的实现方式中，所述获取模块包括：
59.第二获取单元，用于根据所述终端发送的握手请求消息获取所述终端所请求的域名；
60.第三获取单元，用于获取所述域名对应的历史总数量，所述域名对应的历史总数量包括在历史时间段接收到的请求所述域名的基于所述中间层协议的握手请求消息的总数量。
61.在一个可选的实现方式中，所述确定模块包括：
62.第四获取单元，用于根据所述历史总数量以及预设数量获取控流比例。
63.第一确定单元，用于根据所述控流比例确定所述终端发送的握手请求消息是否触发所述电子设备的控流条件。
64.在一个可选的实现方式中，所述第一确定单元包括：
65.设置子单元，用于设置多个预设标签；
66.筛选子单元，用于根据所述控流比例，在所述多个预设标签中筛选部分预设标签；
67.选择子单元，用于在所述多个预设标签中为所述终端发送的握手请求消息随机选择一个预设标签；
68.第一确定子单元，用于在选择的预设标签位于所述部分预设标签的情况下，确定所述终端发送的握手请求消息触发所述电子设备的控流条件；
69.或者，
70.第二确定子单元，用于在选择的预设标签不位于所述部分预设标签的情况下，确定所述终端发送的握手请求消息未触发所述电子设备的控流条件。
71.在一个可选的实现方式中，所述确定模块包括：
72.第五获取单元，用于根据所述终端发送的握手请求消息获取所述终端的标识信息；
73.第二确定单元，用于在白名单中查找所述终端的标识信息；在白名单中查找到所述终端的标识信息的情况下，确定所述终端发送的握手请求消息未触发控流条件；或者，在白名单中未查找到所述终端的标识信息的情况下，确定所述终端发送的握手请求消息触发控流条件。
74.或者，
75.第三确定单元，用于在黑名单中查找所述终端的标识信息；在黑名单中查找到所述终端的标识信息的情况下，确定所述终端发送的握手请求消息触发控流条件；或者，在黑名单中未查找到所述终端的标识信息的情况下，确定所述终端发送的握手请求消息未触发控流条件。
76.第三方面，本技术示出了一种电子设备，电子设备包括：处理器；用于存储处理器可执行指令的存储器；其中，处理器被配置为执行如前述的任一方面所示的方法。
77.第四方面，本技术示出了一种非临时性计算机可读存储介质，当存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如前述的任一方面所示的方法。
78.第五方面，本技术示出了一种计算机程序产品，当计算机程序产品中的指令由电子设备的处理器执行时，使得电子设备能够执行如前述的任一方面所示的方法。
79.与现有技术相比，本技术包括以下优点：
80.在本技术中，接收终端发送的基于中间层协议的握手请求消息，中间层协议包括应用于计算机网络模型中的应用层与传输层之间的协议；获取历史总数量，历史总数量包括在历史时间段接收到的历史握手请求消息的总数量，历史握手请求消息包括基于中间层协议的握手请求消息，历史时间段位于当前时刻之前；在历史总数量小于预设数量的情况下，根据终端发送的握手请求消息向终端返回基于中间层协议的握手响应消息。
81.通过本技术，在历史总数量小于预设数量的情况下，根据终端发送的握手请求消息向终端返回基于中间层协议的握手响应消息，相应地，在历史总数量大于或等于预设数
量的情况下，不根据终端发送的握手请求消息向终端返回基于中间层协议的握手响应消息，例如，不处理终端发送的握手请求消息，不执行ssl握手的相关步骤，消除ssl握手阶段产生的系统资源消耗，如此可以节省服务端的系统资源，以尽可能地降低服务端的系统资源的负荷。
附图说明
82.图1是本技术一示例性实施例示出的一种访问控制系统的结构框图。
83.图2是本技术一示例性实施例示出的一种访问控制系统的结构框图。
84.图3是本技术一示例性实施例示出的一种访问控制系统的结构框图。
85.图4是本技术一示例性实施例示出的一种访问控制方法的流程示意图。
86.图5是本技术一示例性实施例示出的一种访问控制方法的流程示意图。
87.图6是本技术一示例性实施例示出的一种访问控制方法的流程示意图。
88.图7是本技术一示例性实施例示出的一种访问控制装置的结构框图。
89.图8是本技术一示例性实施例示出的一种装置的结构示意图。
具体实施方式
90.为使本技术的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本技术作进一步详细的说明。
91.随着用户使用手机与服务提供商的服务端之间进行数据交互的次数增多以及交互的数据的私密性或者重要性增加，渐渐地，对网络交互的安全性提出了更高的要求。目前，在手机与服务端交互的场景中，https(hyper text transfer protocol over secure socket layer，超文本传输安全协议)已经被越来越广泛的使用。
92.其中，手机与服务端之间往往基于计算机网络模型进行数据交互，计算机网络模型可以包括：7层的iso(open system interconnection，开发系统互联)模型或4层的tcp(transmission control protocol，传输控制协议)/ip(internet protocol，网络之间互联的协议)模型等。
93.7层的iso模型中从下层至上层依次包括：物理层、数据链路层、网络层、传输层、会话层、表示层以及应用层。
94.4层的tcp/ip模型从下层至上层依次包括：网络接口层、网际层、传输层以及应用层。
95.在计算机网络模型中，靠下的层往往需要对靠上的层提供支持。
96.https往往应用于计算机网络模型中的应用层，位于应用层的协议往往需要位于传输层的网络连接来支持，例如，需要位于传输层的tcp连接来支持。
97.如此，在手机与服务端之间进行数据交互之前，无论使用哪一个计算机网络模型，可以按照层的由下至上的顺序，依次建立手机与服务端之间的针对各个层的关联。
98.例如，针对传输层以及应用层而言，在手机需要与服务端进行数据交互的场景中，可以先建立手机与服务端之间的tcp连接。然后，手机与服务端之间使用应用层的https协议来经由tcp连接就可以进行数据交互。
99.其中，在一个可能的情况中，广大用户均可以使用各自的手机与服务端之间进行
数据交互，也即，服务端可以并发地对多个手机提供数据服务。
100.但是，发明人发现，有时候可能会出现高并发的情况，在出现高并发的情况下，可能会导致服务端的系统资源超负荷，进而可能导致服务端出现故障，例如宕机等。
101.其中，高并发的情况可以包括：服务端短期内接收到大量的https请求，且需要对大量的https请求进行处理。
102.其中，服务端的系统资源可以包括服务端cpu(central processing unit，中央处理器)以及内存等。
103.如此，提出了避免服务端的系统资源超负荷的需求。
104.为了实现避免服务端的系统资源超负荷的目的，在一种方式中，针对服务端而言，在服务端短期内接收到的https请求的数量较多的情况下，则可以针对接收的部分https请求返回拒绝响应(例如包括https 429状态码等)，从而就可以不对接收的部分https请求正常处理，以期降低服务端的一部分负荷。
105.然而，发明人发现，从结果的状态来看，上述方式降低服务端负荷的效果小，且在部分情况下，即使对部分https请求返回拒绝响应，服务端的系统资源仍旧超负荷。
106.如此，发明人发现，对部分https请求返回拒绝响应无法实现避免服务端的系统资源超负荷的目的。
107.鉴于此，发明人分析了对部分https请求返回拒绝响应无法避免服务端的系统资源超负荷的原因，并发现：
108.在手机与服务端之间进行数据交互的场景中，若在应用层使用的是https等，则在建立手机与服务端之间的位于传输层的tcp连接之后，在手机基于tcp连接向服务端发送https请求之前，由于使用的https，则为了保障数据安全，手机需要先与服务端之间进行ssl(secure sockets layer，安全套接层协议)握手，在手机与服务端之间ssl握手之后，手机才会基于tcp连接向服务端发送https请求。
109.其中，手机与服务端之间进行ssl握手的过程包括：
110.01)、终端向服务端发送client hello(客户端呼叫)消息。
111.client hello消息中可以包括ssl版本号、随机数、会话id(identity document，身份标识号)、密码套件以及压缩方法等。
112.其中，密码套件表明了终端所能支持的算法列表，其中包括密钥交换方式、签名方式和加密方式等。
113.02)、服务端根据client hello消息向终端返回server hello(服务端呼叫)消息。
114.server hello消息中可以包括ssl版本号，服务端和终端共同支持的密钥交换方式、签名方式、加密方式以及用于后续生成秘钥的随机数等。
115.其中，服务端可以通过预先加载的数字证书以及签名方式来和client hello里的密码套件进行匹配，在匹配成功的情况下，可以向终端返回server hello消息，并在服务端里标识双方协商好的所使用的密码算法。
116.03)、服务端向终端发送指定的证书(证书链)，用于身份验证。
117.04)、终端成功验证服务端证书后，发送client key exchange(客户端密钥交换)消息给服务端，用于将预主秘钥通过服务端的公钥加密后发送给服务端。
118.05)、双方根据预主秘钥以及随机数生成用于传输阶段的主秘钥，从而完成ssl握
手协商的过程。
119.可见，手机与服务端之间进行ssl握手包括多个步骤，服务端执行相应的步骤会耗费服务端的系统资源。
120.在一个可能的情况下，即使服务端对一部分https请求不处理，但是，在各个终端分别向服务端发送这一部分https请求中的各自的https请求之前，各个终端分别会与服务端之间进行ssl握手，ssl握手的过程会耗费服务端的系统资源，进而导致对部分https请求返回拒绝响应无法实现避免服务端的系统资源超负荷的目的。
121.因此，发明人总结出：对部分https请求返回拒绝响应无法避免服务端的系统资源超负荷的原因可以包括：服务端接收部分https请求之前会与部分https请求中的各个http请求的发送方之间进行ssl握手，ssl握手的过程耗费了服务端的系统资源，进而导致对部分https请求返回拒绝响应无法实现避免服务端的系统资源超负荷的目的。
122.为此，发明人想到了另一种方式：若服务端为了避免超负荷而不需要对部分https请求处理，则可以在接收部分https之前与不部分https的发送方之间进行ssl握手，例如，服务端不执行ssl握手的相关步骤，如此可以节省服务端的系统资源，以尽可能地降低服务端的系统资源的负荷。
123.例如，若服务端为了避免超负荷而不需要对部分https请求处理，则在服务端接收到这部分https请求的发送方在ssl握手阶段发送的client hello消息的情况下，可以不处理client hello消息，例如，上述ssl握手阶段的02)～05)步骤不被执行，也即，不参与执行ssl握手，从而可以节省服务端的系统资源，以尽可能地降低服务端的系统资源的负荷。
124.具体方案可以本技术之后的描述，在此不做详述。
125.其中，为了便于理解本技术，对本技术可能涉及的技术术语进行解释：
126.sni：server name indication，服务端名称指示，用来改善服务端与终端的ssl和tls(transport layer security，安全传输层协议)的一个扩展，主要用来解决一台服务端只能使用一个证书(或一个域名)的缺点，随着服务端对虚拟主机的支持，一个服务端可以为多个域名提供服务，而sni的设计目的是为了让服务端根据请求来决定为哪个域提供服务。
127.ssl：已被广泛地用于web(网页)浏览器与服务端之间的身份认证和加密数据传输。ssl协议位于tcp/ip协议与各种应用层协议之间，为数据通讯提供安全支持。ssl协议可分为两层：ssl记录协议(ssl record protocol)：它建立在可靠的传输协议(如tcp)之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。ssl握手协议(ssl handshake protocol)：它建立在ssl记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。
128.tls：用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两层组成：tls记录协议(tls record)和tls握手协议(tls handshake)。较低的层为tls记录协议，位于某个可靠的传输协议(例如tcp)上面。tls协议包括两个协议组：tls记录协议和tls握手协议。tls记录协议是一种分层协议。每一层中的信息可能包含长度、描述和内容等字段。记录协议支持信息传输、将数据分段到可处理块、压缩数据、应用mac、加密以及传输结果等。对接收到的数据进行解密、校验、解压缩、重组等，然后将它们传送到高层客户机。tls握手协议由三个子协议组构成，允许对等双方在记录层的安全参数上达成一致、自我认证、例
示协商安全参数、互相报告出错条件。由于tls是建立在ssl的基础上的，是ssl的后续版本，两者之间存在着差别，主要是它们所支持的加密算法不同，而整体的流程是基本相同的，因此，在本技术实施例中，主要以ssl进行说明。ssl握手的第一阶段启动逻辑连接，建立这个连接的安全能力。
129.https是以安全为目标的http(hypertext transfer protocol，超文本传送协议)通道，即http下加入ssl或其后续版本tls，ssl/tls利用数据加密、身份验证和消息完整性验证机制，为网络上数据的传输提供安全性保证。
130.域名：类似于网络上的门牌号码，是用于识别和定位互联网上计算机的层次结构式字符标识，国际互联网域名体系中，对顶级域名进行划分，包括：国家和地区顶级域名(country code top level domain，简称cctld)和通用类别顶级域名(generic top level domain，简称gtld)，国家和地区顶级域名对应于国家、地区的地理位置，如.cn代表中国、.us代表美国等；通用类别顶级域名对应不同类别，比较常见的如.com代表商业机构、.net代表从事互联网服务的机构、.org代表非赢利性组织等。
131.参照图1，示出了本技术的一种访问控制系统的结构框图。在图1中，访问控制系统中包括一个服务端01以及至少一个终端02。
132.该一个服务端可以对各个终端分别提供数据服务，且，该一个服务端可以针对各个终端分别提供多个域名的数据服务。各个终端可以请求与该一个服务端进行数据交互，以享用该一个服务端针对域名的提供的数据服务。
133.参照图2，示出了本技术的一种访问控制系统的结构框图。在图2中，访问控制系统中包括分布式服务系统以及至少一个终端02。分布式服务系统中包括多个服务端01，各个服务端之间可以相互通信。
134.各个服务端均可以对各个终端分别提供数据服务，且各个服务端可以针对各个终端分别提供多个域名的数据服务，例如，同一个终端从各个服务端中均可以请求多个域名的数据服务。各个终端可以请求与多个服务端进行数据交互，以享用服务端针对域名的提供的数据服务。
135.参照图3，示出了本技术的一种访问控制系统的结构框图。在图3中，访问控制系统中包括分布式服务系统以及至少一个终端02。分布式服务系统中包括多个服务端01以及控流节点03。控流节点与各个服务端之间可以相互通信。控流节点可以对终端不可见，控流节点可以不与终端之间进行数据交互。
136.该控流节点具有统计功能，并根据统计功能制定控流策略，并将控流策略下发至各个服务端，以供各个服务端根据控流策略控制流量，例如，服务端可以根据控流策略确定是根据终端向自己发送的握手请求消息向终端返回握手响应消息还是不对握手请求消息处理(例如不根据终端向自己发送的握手请求消息向终端返回握手响应消息)。
137.在一个例子中，在对各个终端提供数据服务的场景中，对于任意一个服务端，在服务端接收到终端发送的握手请求消息的情况下，就可以向控流节点上报服务端接收到终端发送的握手请求消息，以供控流节点统计各个服务端分别接收到的终端发送的握手请求消息，并根据各个服务端分别接收到的终端发送的握手请求消息制定控流策略。
138.上述提到的终端包括广大用户使用的设备。例如包括手机、平板电脑、笔记本电脑或台式电脑等。
139.结合图1-3所示的访问控制系统，参见图4，示出了本技术的一种访问控制方法的流程示意图，该方法可以应用于电子设备中，电子设备包括图1-3所示的服务端等，之后的实施例以电子设备为服务端为例进行举例说明，但不作为对本技术保护范围的限制，该方法包括：
140.在步骤s101中，接收终端发送的基于中间层协议的握手请求消息，中间层协议包括应用于计算机网络模型中的应用层与传输层之间的协议。
141.终端发送的基于中间层协议的握手请求消息用于请求与服务端基于中间层协议握手。
142.在终端与服务端之间进行数据交互的场景中，终端与服务端之间可以基于计算机网络模型进行数据交互。
143.中间层协议包括应用于计算机网络模型中的多层中的传输层与应用层之间的协议，例如ssl或tls等。
144.在本技术中，应用层与传输层之间可以通过中间层协议进行交互。
145.例如，应用层的数据可以不直接传递给传输层，而是传递给中间层，例如，ssl/tls，ssl/tls层对从应用层收到的数据进行加密，在传递至传输层。
146.中间层协议包括ssl或tls等。
147.ssl/tls是安全网络传输协议，主要是为了保护在互联网中传递的机密信息，该协议包括两个过程：握手阶段以及数据传输阶段。
148.数据传输阶段就是对传输的数据分别使用协商好的对称秘钥进行加解密和摘要秘钥进行摘要运算，以保证数据的私密性和完整性。
149.握手阶段的主要目的就是为了确认对方身份的真实有效性并产生数据传输阶段所需要的秘钥。
150.在一个实施例中，可以接收终端基于安全套接层协议ssl或安全传输层协议tls发送的握手请求消息。
151.终端向服务端发出client hello消息(即握手请求消息)并等待服务端的响应。
152.需要说明的是，短期内可能存在多个客户端分别发送的基于中间层协议的握手请求消息，为了提高对握手请求消息的处理速度，服务端中可以启动多个进程，各个进程均用于处理不同的握手请求消息，在需要将多个客户端分别发送的基于中间层协议的握手请求消息分配给各个进程时，可以根据各个进程当前的处理能力分配握手请求消息，以达到负载均衡的目的。
153.在步骤s102中，获取历史总数量，历史总数量包括在历史时间段接收到的历史握手请求消息的总数量，历史握手请求消息包括基于中间层协议的握手请求消息，历史时间段位于当前时刻之前。
154.当前时刻包括在步骤s101中接收到终端发送的基于中间层协议的握手请求消息时的接收时刻。
155.在本技术中，历史时间段的持续时长可以根据实际情况而定，例如，1秒、2秒、3秒或4秒等，本技术对此不加以限定。历史时间段的结束时刻可以为当前时刻等。
156.其中，在步骤s101中接收到终端发送的基于中间层协议的握手请求消息时的接收时刻为当前时刻。
157.之前在历史时间段中，曾经接收到过基于中间层协议的历史握手请求消息，以及，已记录有(例如在服务端中记录有)在历史时间段中接收到的基于中间层协议的历史握手请求消息的历史数量，如此，可以直接获取已记录的、在历史时间段中接收到的基于中间层协议的历史握手请求消息的历史数量。
158.在一个实施例中，在图1所示的访问控制系统的场景中，终端发送的基于中间层协议的握手请求消息是请求与一个服务端握手。在该实施例中，仅涉及该一个服务端，如此，可以将已记录的该服务端在历史时间段接收到的基于中间层协议的历史握手请求消息的历史数量确定为历史总数量。
159.或者，在本技术另一个实施例中，在图2或3所示的访问控制系统的场景中，终端发送的基于中间层协议的握手请求消息是请求与一个服务端握手。在该实施例中，涉及分布式服务系统，分布式服务系统中包括多个服务端，多个服务端均可以对外提供服务，该一个服务端为分布式服务系统中的多个服务端中的其中一个服务端，也即，握手请求消息用于请求与分布式服务系统中的多个服务端中的一个服务端之间握手。
160.如此，可以获取分布式服务系统中的各个服务端的历史数量，服务端的历史数量包括服务端在历史时间段接收到的历史握手请求消息的总数量，历史握手请求消息包括基于中间层协议的握手请求消息，历史时间段位于当前时刻之前；计算分布式服务系统中的各个服务端的历史数量之间的总和，得到历史总数量。
161.在另一个实施例中，获取历史总数量的流程包括：
162.1021、根据终端发送的握手请求消息获取终端所请求的域名。
163.在本技术一个实施例中，服务端针对域名对外提供服务，且服务端可以针对不同的域名对外提供服务，如此，在本技术中，需要基于域名的维度对握手请求消息处理，进而就需要根据握手请求消息获取终端所请求的域名。
164.在本技术一个实施例中，在中间层协议为ssl协议的情况下，握手请求消息可以为“client hello”的数据包。
165.可以从“client hello”的数据包中包括sni字段，sni字段中包括终端所请求的域名，例如，所请求的服务端的域名等。如此，可以在“client hello”的数据包中的sni字段中提取终端所请求的域名。
166.例如，sni字段中具有server name(服务器名称)字段，server name字段中记录有终端所请求的服务端的域名。如此，在sni字段中可以索引出server name字段，获取server name字段中的域名，并作为终端所请求的域名。
167.在一个例子中，具体地，sni字段定义在rfc4366，是一项用于改善ssl/tls的技术，在ssl3.0/tls1.0中被启用。它允许请求方在发起ssl握手请求时(包括请求方发出ssl请求中的client hello阶段)，就可以通过sni扩展字段提交请求的域名，使得服务端能够切换到正确的域名并基于正确的域名对外提供服务。如此，在本技术中，可以基于此原理中的sni字段中的server name字段来提取出请求方所请求的域名。
168.在中间层协议为tls协议的情况下，类似ssl协议，在此不做详述。
169.1022、获取该域名对应的历史总数量，该域名对应的历史总数量包括在历史时间段接收到的请求该域名的基于中间层协议的握手请求消息的总数量。
170.在步骤s103中，确定历史总数量是否小于预设数量。
171.在本技术中，预设数量可以是事先根据实际情况设置的，例如，是根据服务端的自身能够承载的负荷设置的等，例如，可以包括10000、11000或12000等，本技术对此不加以限定。
172.可以理解的是，预设数量也可以根据实际情况实时调整等。
173.在历史总数量小于预设数量的情况下，在步骤s104中，根据终端发送的握手请求消息向终端返回基于中间层协议的握手响应消息。
174.终端发送的握手请求消息包括步骤s101中接收到的握手请求消息。
175.例如，根据client hello消息向终端返回server hello消息等。
176.在历史总数量小于预设数量的情况下，则往往说明在历史时间段服务端的负荷并非很高，服务端往往还能够继续承载更多的负荷，服务端接收的握手请求消息的数量往往具有延续性，如此，推断在当前时刻之后服务端的负荷可能并非很高，服务端往往还能够继续承载更多的负荷，因此，为了尽可能地对外正常提供服务，在当前时刻之后可以不对服务端控流，例如，可以对接收到的基于中间层协议的握手请求消息正常处理，如此，可以根据握手请求消息向终端返回基于中间层协议的握手响应消息。
177.在历史总数量大于或等于预设数量的情况下，在步骤s105中，确定终端发送的握手请求消息是否触发电子设备的控流条件。
178.在历史总数量大于或等于预设数量的情况下，则往往说明在历史时间段服务端的负荷很高，服务端往往无法继续承载更多的负荷，服务端接收的握手请求消息的数量往往具有延续性，如此，推断在当前时刻之后服务端的负荷可能很高，服务端往往无法继续承载更多的负荷，因此，需要进一步地判断在当前时刻之后是否对服务端控流，例如，确定握手请求消息是否触发电子设备的控流条件，在触发电子设备的控流条件的情况下，再对服务端控流，或者，在未触发电子设备的控流条件的情况下，可以不对服务端控流。
179.在终端发送的握手请求消息未触发电子设备的控流条件的情况下，执行步骤s105：根据终端发送的握手请求消息向终端返回基于中间层协议的握手响应消息。
180.本步骤具体可以参见之后所示的实施例，在此不做详述。
181.在终端发送的握手请求消息触发电子设备的控流条件的情况下，在步骤s106中，停止对终端发送的握手请求消息处理。
182.例如，不根据握手请求消息向终端返回基于中间层协议的握手响应消息，例如，不根据client hello消息向终端返回server hello消息等，例如，上述ssl握手阶段的02)～05)步骤不被执行，可以直接丢弃握手请求消息，从而可以节省服务端的系统资源，以尽可能地降低服务端的系统资源的负荷。
183.在本技术中，接收终端发送的基于中间层协议的握手请求消息，中间层协议包括应用于计算机网络模型中的应用层与传输层之间的协议；获取历史总数量，历史总数量包括在历史时间段接收到的历史握手请求消息的总数量，历史握手请求消息包括基于中间层协议的握手请求消息，历史时间段位于当前时刻之前；在历史总数量小于预设数量的情况下，根据终端发送的握手请求消息向终端返回基于中间层协议的握手响应消息。
184.通过本技术，在历史总数量小于预设数量的情况下，根据终端发送的握手请求消息向终端返回基于中间层协议的握手响应消息，相应地，在历史总数量大于或等于预设数量的情况下，不根据终端发送的握手请求消息向终端返回基于中间层协议的握手响应消
息，例如，不处理终端发送的握手请求消息，不执行ssl握手的相关步骤，消除ssl握手阶段产生的系统资源消耗，如此可以节省服务端的系统资源，以尽可能地降低服务端的系统资源的负荷。
185.在本技术中，在步骤s101中接收到终端发送的基于中间层协议的握手请求消息之前，在一个可能的实施例中，已建立与终端之间的位于传输层的通信连接，例如，已建立服务端(图1-3中的访问控制系统中的一个服务端)与终端之间的位于传输层的通信连接，其中，位于传输层的通信连接可以包括tcp连接或udp(user datagram protocol，用户数据报协议)连接等。
186.在握手请求消息触发电子设备的控流条件的情况下，若已建立与终端之间的位于传输层的通信连接，则可以断开与终端之间的位于传输层的通信连接。
187.其中，由于握手请求消息触发电子设备的控流条件，可见，是为了阻断之后终端请求从服务端中获取服务，由于是需要阻断之后终端请求从服务端中获取服务，如此，与终端之间的位于传输层的通信连接(例如服务端与终端之间的位于传输层的通信连接)至少在短期内是无用的，如此，为了节省与终端之间的位于传输层的通信连接涉及的网络资源以及节省服务端为了维护与终端之间的位于传输层的通信连接而耗费的系统资源，可以断开与终端之间的位于传输层的通信连接。
188.进一步地，在本技术另一个实施例中，已记录有(例如在服务端中记录等)历史总数量，另外，在步骤s101中又接收到了终端发送的基于中间层协议的握手请求消息，如此，可以根据在步骤s101中接收到的终端发送的基于中间层协议的握手请求消息，增加已记录的历史总数量，例如，对已记录的历史总数量增加特定数值等，其中，特征数值可以包括1、2或3等正整数，本技术对此不加以限定。
189.在本技术一个实施例中，参见图5，步骤s106包括：
190.在步骤s201中，根据历史总数量以及预设数量获取控流比例。
191.在一个实施例中，历史总数量大于或等于预设数量，可以计算历史总数量与预设数量之间的差值，然后可以计算该差值与预设数量之间的比值，并作为控流比例。
192.或者，在另一个实施例中，历史总数量大于或等于预设数量，可以计算历史总数量与预设数量之间的差值，然后可以计算该差值与历史总数量之间的比值，并作为控流比例。
193.在步骤s202中，根据控流比例确定终端发送的握手请求消息是否触发电子设备的控流条件。
194.在本技术一个实施例中，本步骤可以通过如下流程实现，包括：
195.2021、设置多个预设标签。
196.多个预设标签互不相同。
197.在一个例子中，多个预设标签可以是多个不同的数字。例如，可以包括100个数字，分别为1～100等。
198.2022、根据控流比例，在多个预设标签中筛选部分预设标签。
199.在本技术中，控流比例为大于0且小于1的数值，可以计算多个预设标签的数量与控流比例之间的乘积，得到一个数值，可以取该数值中的整数部分，得到一个整数。
200.然后根据该整数在多个预设标签中筛选预设标签(例如在多个预设标签中筛选的预设标签的数量为该整数)，即为部分预设标签，其中，可以根据该整数在多个预设标签中
随机筛选预设标签(例如，只要满足筛选的预设标签的数量为该整数即可，至于筛选哪些预设标签都可以)。
201.例如，假设该整数为20，在步骤2021的0～100的数字中可以筛选20个数字，例如，筛选的20个数字为数字1～20，并作为部分预设标签。
202.2023、在多个预设标签中为终端发送的握手请求消息随机选择一个预设标签。
203.其中，可以在多个预设标签中随机选择一个预设标签，并作为为终端发送的握手请求消息随机选择的预设标签。
204.例如，在步骤2021的例子中的0～100的数字中为握手请求消息随机选择一个数字。
205.2024、在选择的预设标签位于部分预设标签的情况下，确定终端发送的握手请求消息触发电子设备的控流条件。
206.例如，假设在步骤2023中的0～100的数字中为握手请求消息随机选择的数字为11，其位于在步骤2022中筛选的20个数字1～20中，如此可以确定握手请求消息触发电子设备的控流条件。
207.2025、在选择的预设标签不位于部分预设标签的情况下，确定终端发送的握手请求消息未触发电子设备的控流条件。
208.例如，假设在步骤2023中的0～100的数字中为握手请求消息随机选择的数字为37，其不位于在步骤2022中筛选的20个数字1～20中，如此可以确定握手请求消息未触发电子设备的控流条件。
209.或者，在本技术一个实施例中，参见图6，步骤s106包括：
210.在步骤s301中，根据终端发送的握手请求消息获取终端的标识信息。
211.在本技术一个实施例中，在中间层协议为ssl协议的情况下，握手请求消息可以为“client hello”的数据包。
212.可以从“client hello”的数据包中包括标识字段，标识字段中包括终端的标识信息，终端的标识信息包括终端的ip地址或mac(media access control，介质访问控制)地址。如此，可以在“client hello”的数据包中的标识字段中提取终端的标识信息。
213.在中间层协议为tls协议的情况下，类似ssl协议，在此不做详述。
214.在步骤s302中，根据终端的标识信息确定终端发送的握手请求消息是否触发电子设备的控流条件。
215.例如，在一个实施例中，在白名单中查找终端的标识信息。在白名单中查找到终端的标识信息的情况下，确定握手请求消息未触发电子设备的控流条件。或者，在白名单中未查找到终端的标识信息的情况下，确定握手请求消息触发电子设备的控流条件。
216.本技术实施例中，事先可以设置白名单，白名单中包括至少一个终端的标识信息，标识信息位于白名单中的终端向服务端发送的握手请求消息可以不被控流，而可以被正常处理，以实现针对终端的维度的精准控流。另外，根据实际情况可以对白名单中的标识信息更新，以满足实时的需求。
217.或者，在一个实施例中，在黑名单中查找终端的标识信息。在黑名单中查找到终端的标识信息的情况下，确定握手请求消息触发电子设备的控流条件。或者，在黑名单中未查找到终端的标识信息的情况下，确定握手请求消息未触发电子设备的控流条件。
218.本技术实施例中，事先可以设置黑名单，黑名单中包括至少一个终端的标识信息，标识信息位于黑名单中的终端向服务端发送的握手请求消息可以被控流，而不被正常处理，以实现针对终端的维度的精准控流。另外，根据实际情况可以对黑名单中的标识信息更新，以满足实时的需求。
219.需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本技术并不受所描述的动作顺序的限制，因为依据本技术，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于可选实施例，所涉及的动作并不一定是本技术所必须的。
220.参照图7，示出了本技术的一种访问控制装置的结构框图，应用于电子设备，所述装置包括：
221.接收模块11，用于接收终端发送的基于中间层协议的握手请求消息，所述中间层协议包括应用于计算机网络模型中的应用层与传输层之间的协议；
222.获取模块12，用于获取历史总数量，所述历史总数量包括在历史时间段接收到的历史握手请求消息的总数量，所述历史握手请求消息包括基于所述中间层协议的握手请求消息，历史时间段位于当前时刻之前；
223.返回模块13，用于在所述历史总数量小于预设数量的情况下，根据所述终端发送的握手请求消息向所述终端返回基于所述中间层协议的握手响应消息。
224.在一个可选的实现方式中，所述中间层协议包括安全套接层协议ssl或安全传输层协议tls。
225.在一个可选的实现方式中，所述装置还包括：
226.确定模块，用于在所述历史总数量大于或等于预设数量的情况下，确定所述终端发送的握手请求消息是否触发所述电子设备的控流条件；
227.所述返回模块还用于：在所述终端发送的握手请求消息未触发所述电子设备的控流条件的情况下，根据所述终端发送的握手请求消息向所述终端返回基于所述中间层协议的握手响应消息。
228.在一个可选的实现方式中，所述装置还包括：
229.停止模块，用于在所述终端发送的握手请求消息触发所述电子设备的控流条件的情况下，停止对所述终端发送的握手请求消息处理。
230.在一个可选的实现方式中，所述装置还包括：
231.断开模块，用于在所述终端发送的握手请求消息触发所述电子设备的控流条件的情况下，若已建立与所述终端之间的位于所述传输层的通信连接，断开与所述终端之间的位于所述传输层的通信连接。
232.在一个可选的实现方式中，所述装置还包括：
233.增加模块，用于根据所述终端发送的握手请求消息，增加已记录的历史总数量。
234.在一个可选的实现方式中，所述终端发送的握手请求消息用于请求与分布式服务系统中的多个服务端中的一个服务端之间握手；
235.所述获取模块包括：
236.第一获取单元，用于获取所述分布式服务系统中的各个服务端的历史数量，服务端的历史数量包括服务端在历史时间段接收到的历史握手请求消息的总数量，历史握手请
求消息包括基于所述中间层协议的握手请求消息；
237.计算单元，用于计算所述分布式服务系统中的各个服务端的历史数量之间的总和，得到所述历史总数量。
238.在一个可选的实现方式中，所述获取模块包括：
239.第二获取单元，用于根据所述终端发送的握手请求消息获取所述终端所请求的域名；
240.第三获取单元，用于获取所述域名对应的历史总数量，所述域名对应的历史总数量包括在历史时间段接收到的请求所述域名的基于所述中间层协议的握手请求消息的总数量。
241.在一个可选的实现方式中，所述确定模块包括：
242.第四获取单元，用于根据所述历史总数量以及预设数量获取控流比例。
243.第一确定单元，用于根据所述控流比例确定所述终端发送的握手请求消息是否触发所述电子设备的控流条件。
244.在一个可选的实现方式中，所述第一确定单元包括：
245.设置子单元，用于设置多个预设标签；
246.筛选子单元，用于根据所述控流比例，在所述多个预设标签中筛选部分预设标签；
247.选择子单元，用于在所述多个预设标签中为所述终端发送的握手请求消息随机选择一个预设标签；
248.第一确定子单元，用于在选择的预设标签位于所述部分预设标签的情况下，确定所述终端发送的握手请求消息触发所述电子设备的控流条件；
249.或者，
250.第二确定子单元，用于在选择的预设标签不位于所述部分预设标签的情况下，确定所述终端发送的握手请求消息未触发所述电子设备的控流条件。
251.在一个可选的实现方式中，所述确定模块包括：
252.第五获取单元，用于根据所述终端发送的握手请求消息获取所述终端的标识信息；
253.第二确定单元，用于在白名单中查找所述终端的标识信息；在白名单中查找到所述终端的标识信息的情况下，确定所述终端发送的握手请求消息未触发控流条件；或者，在白名单中未查找到所述终端的标识信息的情况下，确定所述终端发送的握手请求消息触发控流条件。
254.或者，
255.第三确定单元，用于在黑名单中查找所述终端的标识信息；在黑名单中查找到所述终端的标识信息的情况下，确定所述终端发送的握手请求消息触发控流条件；或者，在黑名单中未查找到所述终端的标识信息的情况下，确定所述终端发送的握手请求消息未触发控流条件。
256.在本技术中，接收终端发送的基于中间层协议的握手请求消息，中间层协议包括应用于计算机网络模型中的应用层与传输层之间的协议；获取历史总数量，历史总数量包括在历史时间段接收到的历史握手请求消息的总数量，历史握手请求消息包括基于中间层协议的握手请求消息，历史时间段位于当前时刻之前；在历史总数量小于预设数量的情况
下，根据终端发送的握手请求消息向终端返回基于中间层协议的握手响应消息。
257.通过本技术，在历史总数量小于预设数量的情况下，根据终端发送的握手请求消息向终端返回基于中间层协议的握手响应消息，相应地，在历史总数量大于或等于预设数量的情况下，不根据终端发送的握手请求消息向终端返回基于中间层协议的握手响应消息，例如，不处理终端发送的握手请求消息，不执行ssl握手的相关步骤，消除ssl握手阶段产生的系统资源消耗，如此可以节省服务端的系统资源，以尽可能地降低服务端的系统资源的负荷。
258.本技术实施例还提供了一种非易失性可读存储介质，该存储介质中存储有一个或多个模块(programs)，该一个或多个模块被应用在设备时，可以使得该设备执行本技术实施例中各方法步骤的指令(instructions)。
259.本技术实施例提供了一个或多个机器可读介质，其上存储有指令，当由一个或多个处理器执行时，使得电子设备执行如上述实施例中一个或多个的方法。本技术实施例中，电子设备包括服务器、网关、子设备等，子设备为物联网设备等设备。
260.本公开的实施例可被实现为使用任意适当的硬件，固件，软件，或及其任意组合进行想要的配置的装置，该装置可包括服务器(集群)、终端设备如iot设备等电子设备。
261.图8示意性地示出了可被用于实现本技术中的各个实施例的示例性装置1300。
262.对于一个实施例，图8示出了示例性装置1300，该装置具有一个或多个处理器1302、被耦合到(一个或多个)处理器1302中的至少一个的控制模块(芯片组)1304、被耦合到控制模块1304的存储器1306、被耦合到控制模块1304的非易失性存储器(nvm)/存储设备1308、被耦合到控制模块1304的一个或多个输入/输出设备1310，和被耦合到控制模块1304的网络接口1312。
263.处理器1302可包括一个或多个单核或多核处理器，处理器1302可包括通用处理器或专用处理器(例如图形处理器、应用处理器、基频处理器等)的任意组合。在一些实施例中，装置1300能够作为本技术实施例中网关等服务器设备。
264.在一些实施例中，装置1300可包括具有指令1314的一个或多个计算机可读介质(例如，存储器1306或nvm/存储设备1308)和与该一个或多个计算机可读介质相合并被配置为执行指令1314以实现模块从而执行本公开中的动作的一个或多个处理器1302。
265.对于一个实施例，控制模块1304可包括任意适当的接口控制器，以向(一个或多个)处理器1302中的至少一个和/或与控制模块1304通信的任意适当的设备或组件提供任意适当的接口。
266.控制模块1304可包括存储器控制器模块，以向存储器1306提供接口。存储器控制器模块可以是硬件模块、软件模块和/或固件模块。
267.存储器1306可被用于例如为装置1300加载和存储数据和/或指令1314。对于一个实施例，存储器1306可包括任意适当的易失性存储器，例如，适当的dram。在一些实施例中，存储器1306可包括双倍数据速率四同步动态随机存取存储器(ddr4sdram)。
268.对于一个实施例，控制模块1304可包括一个或多个输入/输出控制器，以向nvm/存储设备1308及(一个或多个)输入/输出设备1310提供接口。
269.例如，nvm/存储设备1308可被用于存储数据和/或指令1314。nvm/存储设备1308可包括任意适当的非易失性存储器(例如，闪存)和/或可包括任意适当的(一个或多个)非易
失性存储设备(例如，一个或多个硬盘驱动器(hdd)、一个或多个光盘(cd)驱动器和/或一个或多个数字通用光盘(dvd)驱动器)。
270.nvm/存储设备1308可包括在物理上作为装置1300被安装在其上的设备的一部分的存储资源，或者其可被该设备访问可不必作为该设备的一部分。例如，nvm/存储设备1308可通过网络经由(一个或多个)输入/输出设备1310进行访问。
271.(一个或多个)输入/输出设备1310可为装置1300提供接口以与任意其他适当的设备通信，输入/输出设备1310可以包括通信组件、拼音组件、传感器组件等。网络接口1312可为装置1300提供接口以通过一个或多个网络通信，装置1300可根据一个或多个无线网络标准和/或协议中的任意标准和/或协议来与无线网络的一个或多个组件进行无线通信，例如接入基于通信标准的无线网络，如wifi、2g、3g、4g、5g等，或它们的组合进行无线通信。
272.对于一个实施例，(一个或多个)处理器1302中的至少一个可与控制模块1304的一个或多个控制器(例如，存储器控制器模块)的逻辑封装在一起。对于一个实施例，(一个或多个)处理器1302中的至少一个可与控制模块1304的一个或多个控制器的逻辑封装在一起以形成系统级封装(sip)。对于一个实施例，(一个或多个)处理器1302中的至少一个可与控制模块1304的一个或多个控制器的逻辑集成在同一模具上。对于一个实施例，(一个或多个)处理器1302中的至少一个可与控制模块1304的一个或多个控制器的逻辑集成在同一模具上以形成片上系统(soc)。
273.在各个实施例中，装置1300可以但不限于是：服务器、台式计算设备或移动计算设备(例如，膝上型计算设备、手持计算设备、平板电脑、上网本等)等终端设备。在各个实施例中，装置1300可具有更多或更少的组件和/或不同的架构。例如，在一些实施例中，装置1300包括一个或多个摄像机、键盘、液晶显示器(lcd)屏幕(包括触屏显示器)、非易失性存储器端口、多个天线、图形芯片、专用集成电路(asic)和扬声器。
274.本技术实施例提供了一种电子设备，包括：一个或多个处理器；和，其上存储有指令的一个或多个机器可读介质，当由一个或多个处理器执行时，使得电子设备执行如本技术中一个或多个的方法。
275.对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
276.本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。
277.本技术实施例是参照根据本技术实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、和流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程信息处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程信息处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
278.这些计算机程序指令也可存储在能引导计算机或其他可编程信息处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方
框或多个方框中指定的功能。
279.这些计算机程序指令也可装载到计算机或其他可编程信息处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
280.尽管已描述了本技术实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例和落入本技术实施例范围的所有变更和修改。
281.最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括要素的过程、方法、物品或者终端设备中还存在另外的相同要素。
282.以上对本技术所提供的一种访问控制方法及装置，进行了详细介绍，本文中应用了具体个例对本技术的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本技术的方法及其核心思想；同时，对于本领域的一般技术人员，依据本技术的思想，在具体实施方式及应用范围上均会有改变之处，综上，本说明书内容不应理解为对本技术的限制。