具体实施方式
下面结合附图对本申请作进一步详细描述。
在本申请一个典型的配置中,终端、服务网络的设备和可信方均包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flashRAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括非暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
图1示出根据本申请一个方面的一种用于处理应用访问请求的网络设备1的设备示意图。其中,所述网络设备1包括预调用请求获取装置11、预响应信息获取装置12、应用访问请求获取装置13和应用访问请求处理装置14。
其中,所述预调用请求获取装置11获取用户设备2(参考图2)先于应用访问请求所发送的对应预调用请求;所述预响应信息获取装置12根据所述预调用请求获取对应辅助应用关于所述预调用请求的预响应信息;所述应用访问请求获取装置13获取所述用户设备2所发送的所述应用访问请求;所述应用访问请求处理装置14根据所述预响应信息处理所述应用访问请求。
具体地,所述预调用请求获取装置11获取用户设备2先于应用访问请求所发送的对应预调用请求。在此,所述网络设备1包括各种智能终端,如各种云端服务器,或服务器集群。所述用户设备2包括各种智能终端设备,如移动智能设备、各种个人计算机等。在此,所述网络设备1用于处理所述用户设备2的应用访问请求,而在处理所述应用访问请求的过程中,所述网络设备1有时需要调用相关辅助应用来协助完成所述应用访问请求的具体处理操作。所述辅助应用调用可以包括但不限于数据类服务的调用、文件流信息的抓取等。例如,用户在电子交易过程中,当需要进行电子支付操作时,会向互联网电子支付处理应用所对应的网络设备1发送相应的应用访问请求,如电子支付请求,而为了对网络交易安全进行有效监控,降低交易安全风险,所述网络设备1会调用相应的第三方支付风险监控应用,如ThreatMetrix服务(设备信息解析服务)、Telesign服务(电话号码解析服务)等,进行交易相关的监控处理,例如,通过调用所述第三方支付风险监控应用,获取相应的调用结果,再将所述调用结果引入到所述网络设备1对所述应用访问请求的处理操作中。在本申请中,优选地,所述用户设备2将在所述应用访问请求发出之前,即提前发送与该应用访问请求对应的预调用请求至所述网络设备1。在此,优选地,所述用户设备2的目标用户将在该设备相关页面上提交所述应用访问请求,例如,通过用户在网页版支付界面、或是软件应用界面输入相关信息,再提交所述应用访问请求至对应网络设备1,则相应的所述预调用请求可以是在所述网页版支付界面、或是所述软件应用界面被打开之时,即被同时发送至所述网络设备1;或是在该相关页面被打开之后,所述应用访问请求被提交发送之前,即被触发,发送至所述网络设备1。具体地,所述预调用请求的发出,可以是在所述网页版支付界面被打开时,通过执行在用户设备2网页中的加载的脚本文件信息,或是在所述软件应用界面被打开之时,通过调用匹配的SDK(Software Development Kit,软件开发包)而实现的。相应的,所述网络设备1将会在获取所述应用访问请求之前,即获得所述预调用请求。
在本申请中,对于辅助应用预先调用请求的目的包括:一方面使得网络设备1有充足的时间从第三方设备调用相应的辅助应用,同时,该调用过程又尽量不占用,或是少占用后续网络设备1处理用户的应用访问请求的时间。基于此,所述预调用请求获取装置11获取所述预调用请求的时间包括但不限于基于上述用户设备2的网页版支付界面、或是软件应用界面的打开时间所确定的调用场景示例,而是可以包括获取用户设备2的应用访问请求之前的任意适合时间。
接着,所述预响应信息获取装置12根据所述预调用请求获取对应辅助应用关于所述预调用请求的预响应信息。具体地,在此,所述预调用请求中包含着需要调用的具体辅助应用的相关信息,如辅助应用名称信息、辅助应用调用路径信息等,该相关信息可以是预先设置在发出预调用请求的用户设备2的页面脚本文件、或是软件SDK中。所述预调用请求还包括对应的调用参数信息。所述辅助应用会基于相应的调用参数信息,进行具体的应用调用,进而,基于所述预调用请求,即可以获取相应辅助应用关于所述预调用请求的预响应信息,所述预响应信息的类型与具体的辅助应用的类型相匹配。例如,若是辅助应用是数据类服务,则所述预响应信息可以是一定的文本数据,如上述在电子支付中调用的第三方支付风险监控应用,所述网络设备1获取的上述预响应信息可以是基于所述用户设备2的调用参数信息获取了该用户设备2的安全级别信息;或者,在医疗网络挂号操作中调用患者病例采集的辅助应用,所述网络设备1获取的上述预响应信息可以是患者的历史病例数据。又如,若所述辅助应用是文件流读取应用,则上述预响应信息可以是所拉取的具体文件信息。
接着,所述应用访问请求获取装置13获取所述用户设备2所发送的所述应用访问请求。在此,优选地,所述应用访问请求的获取,是基于相应用户在用户设备2当前应用页面所提交的访问请求。例如,以电子支付应用为例,当用户在用户设备2的网页版支付界面、或是软件应用界面输入相关信息后,即点击页面中相应的请求图示,发送相应的应用访问请求至对应的网络设备1。在此,进一步,优选地,所述网络设备1获取到所述用户设备2的所述应用访问请求的时间可以是在所述网络设备1处理该用户设备2预调用请求过程中,也可以是在所述网络设备1已经获得所述预响应信息后。
接着,所述应用访问请求处理装置14根据所述预响应信息处理所述应用访问请求。在此,优选地,与所述应用访问请求所对应的预响应请求已提前存储在了所述网络设备对应的本地存储装置中,当获取到所述应用访问请求后,可以直接从本地存储装置中读取所述预响应信息,对应的读取时间与网络设备1直接从辅助应用对应设备中直接调用该相同信息相比要缩短很多。进而,基于所述预响应信息的具体内容,处理所述应用访问请求。优选地,基于所述网络设备1中预设的处理模型,结合所述预响应信息,得到最终处理方案,进而通过执行该方案处理所述应用访问请求。以所述应用访问请求为电子支付请求为例,所述预响应信息为对应第三方支付风险监控应用调用返回的用户设备2的安全级别信息,进而将该安全级别信息带入到网络设备1中设置的对应风险控制模型中进行运算分析,得到安全风险信息,在基于预设的处理规则,对相应的电子支付请求进行匹配处理,例如,若是判断该电子支付所述安全风险信息低于或等于预定的风险阈值信息,执行所述应用访问请求,并将所述应用访问请求的执行结果信息返回至所述用户设备2;反之,停止执行所述应用访问请求,并将对应的风险警示信息返回至所述用户设备2。
在此,本申请中所述网络设备1在获取用户设备2的应用访问请求之前,先获取该用户设备2的预调用请求,并基于该预调用请求从对应的辅助应用中获取匹配的预响应信息,进而,再基于所获取的预响应信息处理用户设备2发送来的所述应用访问请求。在此,当用户设备2发出应用访问请求时,可以直接从网络设备1的本地存储中调用预先已经获得的预响应信息,而不需要实时从所述辅助应用所在设备中获取该预响应信息,从而极大地减少了应用访问请求处理过程中调用辅助应用的实际耗时。在此,因为预调用请求发生在应用访问请求之前,所述预调用请求对应的预响应信息的调用时长不必直接受到应用访问请求处理时间较短的限制,可以相对充裕,相对应的预调用时限也可以设置的较宽裕,使得对于实际调用需要较长时间的辅助应用,也可以顺利的被调用、并获取到相应的预响应信息,降低辅助应用调用失败率,提高处理应用访问请求的整体效率,优化用户体验。
优选地,所述预响应信息获取装置12将所述预调用请求转发至对应的辅助应用,并接收所述辅助应用基于所述预调用请求返回的对应预响应信息。
具体地,在此,优选地,用户设备2通过HTTPS协议向网络设备1提供的REST API(Representational State TransferAPI,服务接口)发送所述预调用请求,所述网络设备1接收到该预调用请求后,再将该预调用请求转发至对应的辅助应用,相应的辅助应用将会基于具体的所述预调用请求的内容,进行相应调用处理,并返回所述预响应信息。例如,在电子支付中预调用第三方支付风险监控应用时,所述网络设备1获取用户设备2发出的该第三方支付风险监控应用对应的预调用请求,进而将其转发至相应的第三方支付风险监控应用,该应用基于所述预调用请求中的调用参数信息,返回对应的安全级别信息至网络设备1。在此,所述用户设备2向网络设备1发起的预调用请求,实际上相当于网络设备1向辅助应用发起实际预调用请求的一个触发操作,因为,对于所述辅助应用来说,所述网络设备1是直接的应用调用请求者,进而所述预响应信息也会返回至对应的网络设备1。
优选地,所述预调用请求包括对应的调用参数信息,所述预响应信息是所述辅助应用基于所述调用参数确定的。
具体地,在此,所述调用参数信息可以包括相应的应用参数和系统参数,其中,所述应用参数信息会基于不同的请求调用的用户设备2、及不同的被请求辅助应用而有所不同,例如,以所述辅助应用为第三方支付风险监控应用,如ThreatMetrix服务为例,所述调用参数信息可以包含相应用户设备2的浏览器的SessionID(会话辨识信息)和IP(Internet Protocol,网络之间互连的协议)信息这类业务参数,还可以包含所述ThreatMetrix服务授权所述网络设备1对其进行调用的license key(授权密钥)信息这类协议参数。接着,所述辅助应用,如第三方支付风险监控应用,将会基于该调用请求中对应的调用参数信息,进行相应的调用运算,确定对应的预响应信息。例如,基于用户设备2的浏览器的SessionID和IP,所述ThreatMetrix服务可以基于已有的运算规则针对该用户设备2、或是该用户设备2的服务器的安全性确定出相应的安全级别信息,例如,确定该用户设备2的安全级别为B级,则此安全级别信息即为相应的、将会返回至所述网络设备1的预响应信息。
优选地,所述网络设备1还包括缓存装置(未示出),所述缓存装置缓存所述预响应信息;其中,所述应用访问请求处理装置14从缓存中读取所述预响应信息,并根据所述预响应信息处理所述应用访问请求。
具体地,所述网络设备1获取到所述辅助应用返回的基于上述预调用请求的预响应信息后,会将其存储在本地存储装置,使得当后续相应用户设备2发出应用访问请求、需要调用对应的预响应信息时,可以直接从本地存储装置中快速读取,而不用直接从所述辅助应用中临时调用。在此,进一步,上述本地存储装置可以优选为缓存装置,进而,利用缓存装置比一般存储装置更高效的运行速度,能够更加有效地提高应用访问请求处理过程中辅助应用对应的预响应信息的读取效率。接着,所述应用访问请求处理装置14从该缓存中读取所述预响应信息,并根据所述预响应信息处理所述应用访问请求。
在一个优选实施例(参考图1)中,所述辅助应用包括对应的安全应用;其中,所述应用访问请求处理装置14包括安全风险信息确定单元(未示出)和第一安全风险信息处理单元(未示出),其中,所述安全风险信息确定单元根据所述预响应信息确定所述应用访问请求的安全风险信息;所述第一安全风险信息处理单元当所述安全风险信息低于或等于预定的风险阈值信息,执行所述应用访问请求,并将所述应用访问请求的执行结果信息返回至所述用户设备2。
具体地,在此,所述辅助应用包括安全应用,例如,在电子支付中为了保护支付安全的所述第三方支付风险监控应用,如所述ThreatMetrix服务、所述Telesign服务等。此时,所述安全风险信息确定单元根据所述预响应信息确定所述应用访问请求的安全风险信息。在此,所述网络设备1会以从安全应用中获取到的预响应信息作为基础,进一步进行分析,例如,基于不同场景下、不同类型应用访问请求的安全需要,先预先设定响应的分析模型或规则,再将所述目标预响应信息带入到相匹配的模型和规则中进行运算分析、确定相应的安全风险信息。一般情况下,若是用户设备2的预响应信息对应的安全性判断较高,则该用户设备2发出的应用访问请求响应的安全风险相对较低。接着,所述第一安全风险信息处理单元当所述安全风险信息低于或等于预定的风险阈值信息,执行所述应用访问请求,并将所述应用访问请求的执行结果信息返回至所述用户设备2。在此,优选地,可以预先设置与所述安全风险信息相对应的风险阈值信息,该风险阈值信息可以根据不同的场景需要,进行灵活地调整,例如。对于安全性要求较高的应用访问请求,可以设置其对应的风险阈值信息较高,反之较低。进而,当所述安全风险信息低于或等于预定的风险阈值信息时,可以推定,基于预设标准,该应用访问请求的安全信息达标,此时所述网络设备1可以顺利执行所述应用访问请求,并且,将响应的执行结果信息返回至该应用访问请求对应的所述用户设备2。
优选地,所述应用访问请求处理装置14还包括第二安全风险信息处理单元(未示出),所述第二安全风险信息处理单元当所述安全风险信息高于所述风险阈值信息,停止执行所述应用访问请求,并将对应的风险警示信息返回至所述用户设备2。
具体地,若是基于所述预响应信息,确定的所述安全风险信息高于预设的所述风险阈值信息,则所述网络设备2将停止执行所述应用访问请求,并将对应的风险警示信息返回至所述用户设备2。在此,所述风险警示信息又会基于不同的场景而有不同,在此,优选地,基于所述安全风险信息可以进一步推定,上述应用访问请求的风险具体来源,例如,所述风险是来自网络攻击、或是该用户设备2本身即为黑名单用户。对于类似前者情况,可以推定该用户设备2本身不存在隐患,则可以通过应用信息提示、或是短信等方式提示响应用户进行安全控件的加载、或是更换安全浏览器等操作;对于类似前者情况,可以推定该用户设备2本身即为隐患源头,则所述网络设备1可以直接中断其交易,并发送响应的警告信息,甚至是通知相关安全处理机构,从而避免造成相关人员的实际交易损失。
优选地(参考图1),所述辅助应用的平均响应时长信息满足以下至少任一项:所述辅助应用的平均响应时长信息等于或超过预定的响应时长阈值信息;所述辅助应用的平均响应时长信息等于或超过所述应用访问请求的平均响应时长信息与预定的响应时长倍数阈值信息的乘积;所述辅助应用的平均响应时长信息等于或超过所述应用访问请求的平均响应时长信息与预定的响应时长差值阈值信息之和。
具体地,因为所述辅助应用的预调用请求发生在应用访问请求之前,所述预调用请求对应的预响应信息的调用时长不必直接受到应用访问请求处理时间较短的限制,可以相对充裕,相对应的预调用时限也可以设置的较宽裕,所以本申请,对于实际响应时间较长的辅助应用来说,意义更大,因为,基于现有技术,此类辅助应用可能多数会因为调用时间大大超过预调用时限而导致调用失败。进而,可以为本申请确定一个优选场景:即当基于本申请调用的辅助应用的平均响应时长信息满足相应条件时,则触发执行本申请所描述的其他操作。在此,辅助应用的平均响应时长信息可以是通过预先统计并获取目标辅助应用响应各个请求的不同时长确定出的平均值,以此来反映该辅助应用应对不同响应请求的平均水平。在此,优选地,对于同一个辅助应用,还可以基于其获取的调用请求的不同类型,例如请求对象、请求内容的不同类型,进行区别处理,分类统计同一辅助应用在不同场景下的平均响应时长信息,进而,在实际应用中,基于本申请中预调用请求的所属类型,确定适用的所述辅助应用的平均响应时长信息。
在此,所述辅助应用的平均响应时长信息满足条件可以包括:第一种,所述辅助应用的平均响应时长信息等于或超过预定的响应时长阈值信息;第二种,所述辅助应用的平均响应时长信息等于或超过所述应用访问请求的平均响应时长信息与预定的响应时长倍数阈值信息的乘积;第三种,所述辅助应用的平均响应时长信息等于或超过所述应用访问请求的平均响应时长信息与预定的响应时长差值阈值信息之和。其中,所述响应时长阈值信息、响应时长倍数阈值信息、响应时长差值阈值信息都是预先设置的,其设定的目的是,当满足三种条件时,本申请中所述网络设备1基于预调用请求获取预响应信息,对于后续的应用访问请求处理效率提高的优势明显。例如,在第二种场景中,所述响应时长倍数阈值信息越大,则要求所述辅助应用的平均响应时长信息与所述应用访问请求的平均响应时长信息的比值越大,即可以要求辅助应用的平均响应时长信息要比所述应用访问请求的平均响应时长信息大的多。
在此,所述响应时长阈值信息、响应时长倍数阈值信息、响应时长差值阈值信息等阈值信息的确定可以参考所述所述应用访问请求的平均响应时长信息、以及在网络设备处理应用访问请求时,从本地缓存中读取所述预响应信息的调用时间。
在本申请实施例中,可以设置所述辅助应用的平均响应时长信息满足预定条件作为本申请其他操作执行的触发条件,由此,可以按照实际应用需要选择执行本申请的优选场景,从而可以在一定程度上减少资源浪费,使得预调用辅助应用的实际价值最大化。
图2示出根据本申请一个优选实施例的用于处理应用访问请求的网络设备1和用户设备2的系统示意图。
其中,所述网络设备1包括预调用请求获取装置11'、预响应信息获取装置12'、应用访问请求获取装置13'和应用访问请求处理装置14';所述用户设备2包括预调用请求发送装置21'和应用访问请求发送装置22'。
其中,所述预调用请求获取装置11'获取用户设备2于应用访问请求所发送的对应预调用请求;所述预响应信息获取装置12'根据所述预调用请求获取对应辅助应用关于所述预调用请求的预响应信息;所述应用访问请求获取装置13'获取所述用户设备2所发送的所述应用访问请求;所述应用访问请求处理装置14'根据所述预响应信息处理所述应用访问请求;所述预调用请求发送装置21'向对应的网络设备1发送应用访问请求对应的预调用请求,其中,所述预调用请求用于获取对应辅助应用的预响应信息,所述预响应信息用于处理所述应用访问请求;所述应用访问请求发送装置22'向所述网络设备1发送所述应用访问请求。在此,所述预调用请求获取装置11'、预响应信息获取装置12'、应用访问请求获取装置13'和应用访问请求处理装置14'与图1示出的预调用请求获取装置11、预响应信息获取装置12、应用访问请求获取装置13和应用访问请求处理装置14内容分别对应相同、或基本相同,在此不再赘述,并以引用的方式包含于此。
具体地,所述预调用请求发送装置21'向对应的网络设备1发送应用访问请求对应的预调用请求,其中,所述预调用请求用于获取对应辅助应用的预响应信息,所述预响应信息用于处理所述应用访问请求。在此,所述预调用请求中包含着需要调用的具体辅助应用的相关信息,如辅助应用名称信息、辅助应用调用路径信息等,该相关信息可以是预先设置在发出预调用请求的用户设备2的页面脚本文件、或是软件SDK中。所述预调用请求还包括对应的调用参数信息。所述辅助应用会基于相应的调用参数信息,进行具体的应用调用,进而,基于所述预调用请求,即可以获取相应辅助应用关于所述预调用请求的预响应信息,所述预响应信息的类型与具体的辅助应用的类型相匹配。而所述预响应信息可以为对应网络设备1在后续处理该用户设备2发送的应用访问请求时读取使用。
在此,所述辅助应用预先调用请求的目的包括:一方面使得网络设备1有充足的时间从第三方设备调用相应的辅助应用,同时,该调用过程又尽量不占用,或是少占用后续网络设备1处理用户的应用访问请求的时间。基于此,所述预调用请求发送装置21'发送所述预调用请求可以是在所述用户设备2获取用于提交应用访问请求的页面时,即通过执行响应的页面脚本文件、或是软件SDK文件而发送至所述网络设备1;还可以是用户设备2发送相应应用访问请求之前的任意适合时间。
接着,由所述网络设备1的预调用请求获取装置11'获取用户设备2于应用访问请求所发送的对应预调用请求;再由网络设备1的所述预响应信息获取装置12'根据所述预调用请求获取对应辅助应用关于所述预调用请求的预响应信息。
接着,所述用户设备2的应用访问请求发送装置22'向所述网络设备1发送所述应用访问请求。在此,优选地,所述应用访问请求是用户设备2基于用户操作,而发送至对应网络设备1的。在此,优选地场景是,用户设备2发出所述预调用请求开始至该用户设备2发出相应应用访问请求之间的时间间隔相比于所述网络设备处理所述应用访问请求的时长要长的多。进一步,所述用户设备2还可能接收到网络设备1返回的对该应用访问请求的处理结果,例如,在电子支付场景中,当所述辅助应用为安全应用时,所述用户设备2可能会接收到网络设备1返回的所述应用访问请求对应的风险警示信息。
在此,所述用户设备2先后将预调用请求、应用访问请求发送至对应网络设备1,由此配合着所述网络设备1,实现本申请对应用访问请求的优化处理。
优选地,所述预调用请问发送装置21'当获取用于提交应用访问请求的页面,向对应的网络设备1发送所述应用访问请求对应的预调用请求,其中,所述预调用请求用于获取对应辅助应用的预响应信息,所述预响应信息用于处理所述应用访问请求。以上述应用访问请求为电子交易中的电子支付请求为例,所述页面可以包括网页版支付界面、或是支付软件应用界面。例如,通过用户在网页版支付界面、或是软件应用界面输入相关信息,再提交所述应用访问请求至对应网络设备1,则相应的所述预调用请求可以是在所述网页版支付界面、或是所述软件应用界面被打开之时,即被同时发送至所述网络设备1;或是在该相关页面被打开之后,所述应用访问请求被提交发送之前,即被触发,发送至所述网络设备1。具体地,所述预调用请求的发出,可以是在所述网页版支付界面被打开时,通过执行在用户设备2网页中的加载的脚本文件信息,或是在所述软件应用界面被打开之时,通过调用匹配的SDK文件而实现的。相应的,所述网络设备1将会在获取所述应用访问请求之前,即获得所述预调用请求。其中,所述预调用请求用于获取对应辅助应用的预响应信息,所述预响应信息用于处理所述应用访问请求。
优选地,所述应用访问请求发送装置22'向所述网络设备1发送所述应用访问请求,其中,所述应用访问请求包括对应用户在所述页面中的输入信息。
具体地,在此,一般情况下,用户设备2发出所述预调用请求开始至该用户设备2发出相应应用访问请求之间的时间间隔相比于所述网络设备处理所述应用访问请求的时长要长的原因是,用户通常会先在打开的应用访问请求页面上手动输入、或是选择相关信息,以所述应用访问请求为电子交易中的电子支付请求为例,当用户打开电子支付请求界面时,通常会输入电子支付的账号信息,相关的支付工具、如银行卡号信息,支付密码信息,有时若是电子购物,还可能会有收货地址信息、收货人信息等。此类输入信息都包含在所述应用访问请求中,同时用户输入信息的时间越长,留给所述网络设备1基于预调用请求从辅助应用调用所述预响应信息的可用时间就越宽裕,本申请所节约的资源就越多,对整个应用访问请求过程的效率提升作用就越明显。
图3示出根据本申请另一个方面的一种在网络设备端用于处理应用访问请求的方法流程图。其中,所述方法包括步骤S31、步骤S32、步骤S33和步骤S34。
其中,在步骤S31中,所述网络设备1获取用户设备2(参考图2)先于应用访问请求所发送的对应预调用请求;在步骤S32中,所述网络设备1根据所述预调用请求获取对应辅助应用关于所述预调用请求的预响应信息;在步骤S33中,所述网络设备1获取所述用户设备2所发送的所述应用访问请求;在步骤S34中,所述网络设备1根据所述预响应信息处理所述应用访问请求。
具体地,在步骤S31中,所述网络设备1获取用户设备2先于应用访问请求所发送的对应预调用请求。在此,所述网络设备1包括各种智能终端,如各种云端服务器,或服务器集群。所述用户设备2包括各种智能终端设备,如移动智能设备、各种个人计算机等。在此,所述网络设备1用于处理所述用户设备2的应用访问请求,而在处理所述应用访问请求的过程中,所述网络设备1有时需要调用相关辅助应用来协助完成所述应用访问请求的具体处理操作。所述辅助应用调用可以包括但不限于数据类服务的调用、文件流信息的抓取等。例如,用户在电子交易过程中,当需要进行电子支付操作时,会向互联网电子支付处理应用所对应的网络设备1发送相应的应用访问请求,如电子支付请求,而为了对网络交易安全进行有效监控,降低交易安全风险,所述网络设备1会调用相应的第三方支付风险监控应用,如ThreatMetrix服务、Telesign服务等,进行交易相关的监控处理,例如,通过调用所述第三方支付风险监控应用,获取相应的调用结果,再将所述调用结果引入到所述网络设备1对所述应用访问请求的处理操作中。在本申请中,优选地,所述用户设备2将在所述应用访问请求发出之前,即提前发送与该应用访问请求对应的预调用请求至所述网络设备1。在此,优选地,所述用户设备2的目标用户将在该设备相关页面上提交所述应用访问请求,例如,通过用户在网页版支付界面、或是软件应用界面输入相关信息,再提交所述应用访问请求至对应网络设备1,则相应的所述预调用请求可以是在所述网页版支付界面、或是所述软件应用界面被打开之时,即被同时发送至所述网络设备1;或是在该相关页面被打开之后,所述应用访问请求被提交发送之前,即被触发,发送至所述网络设备1。具体地,所述预调用请求的发出,可以是在所述网页版支付界面被打开时,通过执行在用户设备2网页中的加载的脚本文件信息,或是在所述软件应用界面被打开之时,通过调用匹配的SDK而实现的。相应的,所述网络设备1将会在获取所述应用访问请求之前,即获得所述预调用请求。
在本申请中,对于辅助应用预先调用请求的目的包括:一方面使得网络设备1有充足的时间从第三方设备调用相应的辅助应用,同时,该调用过程又尽量不占用,或是少占用后续网络设备1处理用户的应用访问请求的时间。基于此,所述预调用请求获取装置11获取所述预调用请求的时间包括但不限于基于上述用户设备2的网页版支付界面、或是软件应用界面的打开时间所确定的调用场景示例,而是可以包括获取用户设备2的应用访问请求之前的任意适合时间。
接着,在步骤S32中,所述网络设备1根据所述预调用请求获取对应辅助应用关于所述预调用请求的预响应信息。具体地,在此,所述预调用请求中包含着需要调用的具体辅助应用的相关信息,如辅助应用名称信息、辅助应用调用路径信息等,该相关信息可以是预先设置在发出预调用请求的用户设备2的页面脚本文件、或是软件SDK中。所述预调用请求还包括对应的调用参数信息。所述辅助应用会基于相应的调用参数信息,进行具体的应用调用,进而,基于所述预调用请求,即可以获取相应辅助应用关于所述预调用请求的预响应信息,所述预响应信息的类型与具体的辅助应用的类型相匹配。例如,若是辅助应用是数据类服务,则所述预响应信息可以是一定的文本数据,如上述在电子支付中调用的第三方支付风险监控应用,所述网络设备1获取的上述预响应信息可以是基于所述用户设备2的调用参数信息获取了该用户设备2的安全级别信息;或者,在医疗网络挂号操作中调用患者病例采集的辅助应用,所述网络设备1获取的上述预响应信息可以是患者的历史病例数据。又如,若所述辅助应用是文件流读取应用,则上述预响应信息可以是所拉取的具体文件信息。
接着,在步骤S33中,所述网络设备1获取所述用户设备2所发送的所述应用访问请求。在此,优选地,所述应用访问请求的获取,是基于相应用户在用户设备2当前应用页面所提交的访问请求。例如,以电子支付应用为例,当用户在用户设备2的网页版支付界面、或是软件应用界面输入相关信息后,即点击页面中相应的请求图示,发送相应的应用访问请求至对应的网络设备1。在此,进一步,优选地,所述网络设备1获取到所述用户设备2的所述应用访问请求的时间可以是在所述网络设备1处理该用户设备2预调用请求过程中,也可以是在所述网络设备1已经获得所述预响应信息后。
接着,在步骤S34中,所述网络设备1根据所述预响应信息处理所述应用访问请求。在此,优选地,与所述应用访问请求所对应的预响应请求已提前存储在了所述网络设备对应的本地存储装置中,当获取到所述应用访问请求后,可以直接从本地存储装置中读取所述预响应信息,对应的读取时间与网络设备1直接从辅助应用对应设备中直接调用该相同信息相比要缩短很多。进而,基于所述预响应信息的具体内容,处理所述应用访问请求。优选地,基于所述网络设备1中预设的处理模型,结合所述预响应信息,得到最终处理方案,进而通过执行该方案处理所述应用访问请求。以所述应用访问请求为电子支付请求为例,所述预响应信息为对应第三方支付风险监控应用调用返回的用户设备2的安全级别信息,进而将该安全级别信息带入到网络设备1中设置的对应风险控制模型中进行运算分析,得到安全风险信息,在基于预设的处理规则,对相应的电子支付请求进行匹配处理,例如,若是判断该电子支付所述安全风险信息低于或等于预定的风险阈值信息,执行所述应用访问请求,并将所述应用访问请求的执行结果信息返回至所述用户设备2;反之,停止执行所述应用访问请求,并将对应的风险警示信息返回至所述用户设备2。
在此,本申请中所述网络设备1在获取用户设备2的应用访问请求之前,先获取该用户设备2的预调用请求,并基于该预调用请求从对应的辅助应用中获取匹配的预响应信息,进而,再基于所获取的预响应信息处理用户设备2发送来的所述应用访问请求。在此,当用户设备2发出应用访问请求时,可以直接从网络设备1的本地存储中调用预先已经获得的预响应信息,而不需要实时从所述辅助应用所在设备中获取该预响应信息,从而极大地减少了应用访问请求处理过程中调用辅助应用的实际耗时。在此,因为预调用请求发生在应用访问请求之前,所述预调用请求对应的预响应信息的调用时长不必直接受到应用访问请求处理时间较短的限制,可以相对充裕,相对应的预调用时限也可以设置的较宽裕,使得对于实际调用需要较长时间的辅助应用,也可以顺利的被调用、并获取到相应的预响应信息,降低辅助应用调用失败率,提高处理应用访问请求的整体效率,优化用户体验。
优选地,在步骤S32中,所述网络设备1将所述预调用请求转发至对应的辅助应用,并接收所述辅助应用基于所述预调用请求返回的对应预响应信息。
具体地,在此,优选地,用户设备2通过HTTPS协议向网络设备1提供的REST API发送所述预调用请求,所述网络设备1接收到该预调用请求后,再将该预调用请求转发至对应的辅助应用,相应的辅助应用将会基于具体的所述预调用请求的内容,进行相应调用处理,并返回所述预响应信息。例如,在电子支付中预调用第三方支付风险监控应用时,所述网络设备1获取用户设备2发出的该第三方支付风险监控应用对应的预调用请求,进而将其转发至相应的第三方支付风险监控应用,该应用基于所述预调用请求中的调用参数信息,返回对应的安全级别信息至网络设备1。在此,所述用户设备2向网络设备1发起的预调用请求,实际上相当于网络设备1向辅助应用发起实际预调用请求的一个触发操作,因为,对于所述辅助应用来说,所述网络设备1是直接的应用调用请求者,进而所述预响应信息也会返回至对应的网络设备1。
优选地,所述预调用请求包括对应的调用参数信息,所述预响应信息是所述辅助应用基于所述调用参数确定的。
具体地,在此,所述调用参数信息可以包括相应的应用参数和系统参数,其中,所述应用参数信息会基于不同的请求调用的用户设备2、及不同的被请求辅助应用而有所不同,例如,以所述辅助应用为第三方支付风险监控应用,如ThreatMetrix服务为例,所述调用参数信息可以包含相应用户设备2的浏览器的SessionID和IP信息这类业务参数,还可以包含所述ThreatMetrix服务授权所述网络设备1对其进行调用的license key信息这类协议参数。接着,所述辅助应用,如第三方支付风险监控应用,将会基于该调用请求中对应的调用参数信息,进行相应的调用运算,确定对应的预响应信息。例如,基于用户设备2的浏览器的SessionID和IP,所述ThreatMetrix服务可以基于已有的运算规则针对该用户设备2、或是该用户设备2的服务器的安全性确定出相应的安全级别信息,例如,确定该用户设备2的安全级别为B级,则此安全级别信息即为相应的、将会返回至所述网络设备1的预响应信息。
优选地,所述方法还包括步骤S35(未示出),在步骤S35中,所述网络设备1缓存所述预响应信息;其中,在步骤S34中,所述网络设备1从缓存中读取所述预响应信息,并根据所述预响应信息处理所述应用访问请求。
具体地,所述网络设备1获取到所述辅助应用返回的基于上述预调用请求的预响应信息后,会将其存储在本地存储装置,使得当后续相应用户设备2发出应用访问请求、需要调用对应的预响应信息时,可以直接从本地存储装置中快速读取,而不用直接从所述辅助应用中临时调用。在此,进一步,上述本地存储装置可以优选为缓存装置,进而,利用缓存装置比一般存储装置更高效的运行速度,能够更加有效地提高应用访问请求处理过程中辅助应用对应的预响应信息的读取效率。接着,在步骤S34中,所述网络设备1从该缓存中读取所述预响应信息,并根据所述预响应信息处理所述应用访问请求。
在一个优选实施例(参考图3)中,所述辅助应用包括对应的安全应用;其中,所述步骤S34包括步骤S341(未示出)和步骤S342(未示出),其中,在步骤S341中,所述网络设备1根据所述预响应信息确定所述应用访问请求的安全风险信息;在步骤S342中,所述网络设备1当所述安全风险信息低于或等于预定的风险阈值信息,执行所述应用访问请求,并将所述应用访问请求的执行结果信息返回至所述用户设备2。
具体地,在此,所述辅助应用包括安全应用,例如,在电子支付中为了保护支付安全的所述第三方支付风险监控应用,如所述ThreatMetrix服务、所述Telesign服务等。此时,在步骤S341中,所述网络设备1根据所述预响应信息确定所述应用访问请求的安全风险信息。在此,所述网络设备1会以从安全应用中获取到的预响应信息作为基础,进一步进行分析,例如,基于不同场景下、不同类型应用访问请求的安全需要,先预先设定响应的分析模型或规则,再将所述目标预响应信息带入到相匹配的模型和规则中进行运算分析、确定相应的安全风险信息。一般情况下,若是用户设备2的预响应信息对应的安全性判断较高,则该用户设备2发出的应用访问请求响应的安全风险相对较低。接着,在步骤S342中,所述网络设备1当所述安全风险信息低于或等于预定的风险阈值信息,执行所述应用访问请求,并将所述应用访问请求的执行结果信息返回至所述用户设备2。在此,优选地,可以预先设置与所述安全风险信息相对应的风险阈值信息,该风险阈值信息可以根据不同的场景需要,进行灵活地调整,例如。对于安全性要求较高的应用访问请求,可以设置其对应的风险阈值信息较高,反之较低。进而,当所述安全风险信息低于或等于预定的风险阈值信息时,可以推定,基于预设标准,该应用访问请求的安全信息达标,此时所述网络设备1可以顺利执行所述应用访问请求,并且,将响应的执行结果信息返回至该应用访问请求对应的所述用户设备2。
优选地,所述步骤S34还包括步骤S343(未示出),在步骤S343中,所述网络设备1当所述安全风险信息高于所述风险阈值信息,停止执行所述应用访问请求,并将对应的风险警示信息返回至所述用户设备2。
具体地,若是基于所述预响应信息,确定的所述安全风险信息高于预设的所述风险阈值信息,则所述网络设备2将停止执行所述应用访问请求,并将对应的风险警示信息返回至所述用户设备2。在此,所述风险警示信息又会基于不同的场景而有不同,在此,优选地,基于所述安全风险信息可以进一步推定,上述应用访问请求的风险具体来源,例如,所述风险是来自网络攻击、或是该用户设备2本身即为黑名单用户。对于类似前者情况,可以推定该用户设备2本身不存在隐患,则可以通过应用信息提示、或是短信等方式提示响应用户进行安全控件的加载、或是更换安全浏览器等操作;对于类似前者情况,可以推定该用户设备2本身即为隐患源头,则所述网络设备1可以直接中断其交易,并发送响应的警告信息,甚至是通知相关安全处理机构,从而避免造成相关人员的实际交易损失。
优选地(参考图3),所述辅助应用的平均响应时长信息满足以下至少任一项:所述辅助应用的平均响应时长信息等于或超过预定的响应时长阈值信息;所述辅助应用的平均响应时长信息等于或超过所述应用访问请求的平均响应时长信息与预定的响应时长倍数阈值信息的乘积;所述辅助应用的平均响应时长信息等于或超过所述应用访问请求的平均响应时长信息与预定的响应时长差值阈值信息之和。
具体地,因为所述辅助应用的预调用请求发生在应用访问请求之前,所述预调用请求对应的预响应信息的调用时长不必直接受到应用访问请求处理时间较短的限制,可以相对充裕,相对应的预调用时限也可以设置的较宽裕,所以本申请,对于实际响应时间较长的辅助应用来说,意义更大,因为,基于现有技术,此类辅助应用可能多数会因为调用时间大大超过预调用时限而导致调用失败。进而,可以为本申请确定一个优选场景:即当基于本申请调用的辅助应用的平均响应时长信息满足相应条件时,则触发执行本申请所描述的其他操作。在此,辅助应用的平均响应时长信息可以是通过预先统计并获取目标辅助应用响应各个请求的不同时长确定出的平均值,以此来反映该辅助应用应对不同响应请求的平均水平。在此,优选地,对于同一个辅助应用,还可以基于其获取的调用请求的不同类型,例如请求对象、请求内容的不同类型,进行区别处理,分类统计同一辅助应用在不同场景下的平均响应时长信息,进而,在实际应用中,基于本申请中预调用请求的所属类型,确定适用的所述辅助应用的平均响应时长信息。
在此,所述辅助应用的平均响应时长信息满足条件可以包括:第一种,所述辅助应用的平均响应时长信息等于或超过预定的响应时长阈值信息;第二种,所述辅助应用的平均响应时长信息等于或超过所述应用访问请求的平均响应时长信息与预定的响应时长倍数阈值信息的乘积;第三种,所述辅助应用的平均响应时长信息等于或超过所述应用访问请求的平均响应时长信息与预定的响应时长差值阈值信息之和。其中,所述响应时长阈值信息、响应时长倍数阈值信息、响应时长差值阈值信息都是预先设置的,其设定的目的是,当满足三种条件时,本申请中所述网络设备1基于预调用请求获取预响应信息,对于后续的应用访问请求处理效率提高的优势明显。例如,在第二种场景中,所述响应时长倍数阈值信息越大,则要求所述辅助应用的平均响应时长信息与所述应用访问请求的平均响应时长信息的比值越大,即可以要求辅助应用的平均响应时长信息要比所述应用访问请求的平均响应时长信息大的多。
在此,所述响应时长阈值信息、响应时长倍数阈值信息、响应时长差值阈值信息等阈值信息的确定可以参考所述所述应用访问请求的平均响应时长信息、以及在网络设备处理应用访问请求时,从本地缓存中读取所述预响应信息的调用时间。
在本申请实施例中,可以设置所述辅助应用的平均响应时长信息满足预定条件作为本申请其他操作执行的触发条件,由此,可以按照实际应用需要选择执行本申请的优选场景,从而可以在一定程度上减少资源浪费,使得预调用辅助应用的实际价值最大化。
图4示出根据本申请一个优选实施例的一种在用户设备端用于处理应用访问请求的方法流程图。其中,所述方法包括步骤S41、步骤S42、步骤S43和步骤S44。
其中,在步骤S41中,所述用户设备2向对应的网络设备1发送应用访问请求对应的预调用请求,其中,所述预调用请求用于获取对应辅助应用的预响应信息,所述预响应信息用于处理所述应用访问请求;在步骤S42中,所述网络设备1根据所述预调用请求获取对应辅助应用关于所述预调用请求的预响应信息;在步骤S43中,所述用户设备2向所述网络设备1发送所述应用访问请求;在步骤S44中,所述网络设备1根据所述预响应信息处理所述应用访问请求。在此,所述步骤S42、步骤S44与图3中示出的步骤S32、步骤S34内容分别对应相同、或基本相同,在此不再赘述,并以引用的方式包含于此。
具体地,在步骤S41中,所述用户设备2向对应的网络设备1发送应用访问请求对应的预调用请求,其中,所述预调用请求用于获取对应辅助应用的预响应信息,所述预响应信息用于处理所述应用访问请求。
在此,所述预调用请求中包含着需要调用的具体辅助应用的相关信息,如辅助应用名称信息、辅助应用调用路径信息等,该相关信息可以是预先设置在发出预调用请求的用户设备2的页面脚本文件、或是软件SDK中。所述预调用请求还包括对应的调用参数信息。所述辅助应用会基于相应的调用参数信息,进行具体的应用调用,进而,基于所述预调用请求,即可以获取相应辅助应用关于所述预调用请求的预响应信息,所述预响应信息的类型与具体的辅助应用的类型相匹配。而所述预响应信息可以为对应网络设备1在后续处理该用户设备2发送的应用访问请求时读取使用。
在此,所述辅助应用预先调用请求的目的包括:一方面使得网络设备1有充足的时间从第三方设备调用相应的辅助应用,同时,该调用过程又尽量不占用,或是少占用后续网络设备1处理用户的应用访问请求的时间。基于此,所述预调用请求发送装置21'发送所述预调用请求可以是在所述用户设备2获取用于提交应用访问请求的页面时,即通过执行响应的页面脚本文件、或是软件SDK文件而发送至所述网络设备1;还可以是用户设备2发送相应应用访问请求之前的任意适合时间。
接着,在步骤S42中,所述网络设备1根据所述预调用请求获取对应辅助应用关于所述预调用请求的预响应信息。
接着,在步骤S43中,所述用户设备2向所述网络设备1发送所述应用访问请求。在此,优选地,所述应用访问请求是用户设备2基于用户操作,而发送至对应网络设备1的。在此,优选地场景是,用户设备2发出所述预调用请求开始至该用户设备2发出相应应用访问请求之间的时间间隔相比于所述网络设备处理所述应用访问请求的时长要长的多。进一步,所述用户设备2还可能接收到网络设备1返回的对该应用访问请求的处理结果,例如,在电子支付场景中,当所述辅助应用为安全应用时,所述用户设备2可能会接收到网络设备1返回的所述应用访问请求对应的风险警示信息。
接着,在步骤S44中,所述网络设备1根据所述预响应信息处理所述应用访问请求。
在此,所述用户设备2先后将预调用请求、应用访问请求发送至对应网络设备1,由此配合着所述网络设备1,实现本申请对应用访问请求的优化处理。
优选地,在步骤S41中,所述用户设备2当获取用于提交应用访问请求的页面,向对应的网络设备1发送所述应用访问请求对应的预调用请求,其中,所述预调用请求用于获取对应辅助应用的预响应信息,所述预响应信息用于处理所述应用访问请求。以上述应用访问请求为电子交易中的电子支付请求为例,所述页面可以包括网页版支付界面、或是支付软件应用界面。例如,通过用户在网页版支付界面、或是软件应用界面输入相关信息,再提交所述应用访问请求至对应网络设备1,则相应的所述预调用请求可以是在所述网页版支付界面、或是所述软件应用界面被打开之时,即被同时发送至所述网络设备1;或是在该相关页面被打开之后,所述应用访问请求被提交发送之前,即被触发,发送至所述网络设备1。具体地,所述预调用请求的发出,可以是在所述网页版支付界面被打开时,通过执行在用户设备2网页中的加载的脚本文件信息,或是在所述软件应用界面被打开之时,通过调用匹配的SDK文件而实现的。相应的,所述网络设备1将会在获取所述应用访问请求之前,即获得所述预调用请求。其中,所述预调用请求用于获取对应辅助应用的预响应信息,所述预响应信息用于处理所述应用访问请求。
优选地,在步骤S43中,所述用户设备2向所述网络设备1发送所述应用访问请求,其中,所述应用访问请求包括对应用户在所述页面中的输入信息。
具体地,在此,一般情况下,用户设备2发出所述预调用请求开始至该用户设备2发出相应应用访问请求之间的时间间隔相比于所述网络设备处理所述应用访问请求的时长要长的原因是,用户通常会先在打开的应用访问请求页面上手动输入、或是选择相关信息,以所述应用访问请求为电子交易中的电子支付请求为例,当用户打开电子支付请求界面时,通常会输入电子支付的账号信息,相关的支付工具、如银行卡号信息,支付密码信息,有时若是电子购物,还可能会有收货地址信息、收货人信息等。此类输入信息都包含在所述应用访问请求中,同时用户输入信息的时间越长,留给所述网络设备1基于预调用请求从辅助应用调用所述预响应信息的可用时间就越宽裕,本申请所节约的资源就越多,对整个应用访问请求过程的效率提升作用就越明显。
图5示出根据本申请另一个优选实施例的一种用于处理应用访问请求的实例示意图。
具体地,此示意图以所述应用访问请求为电子交易中电子支付请求为应用场景。首先,当用户设备2对应的支付页面打开时,一方面,用户开始在页面填写相关信息,如收货信息等;另一方面,当所述页面打开时即自从触发向所述网络设备1发送预调用请求,进而,所述网络设备1基于该预调用请求向相应的辅助应用,即第一安全应用、第二安全应用发起调用,分别以500ms和350ms的时间调用到所述预响应信息(图5未示出),并存储在网络设备1对应的本地缓存中。随后,当用户完成页面信息填写,并向网络设备1进行提交支付时,由网络设备1直接从本地缓存中并发调用所述第一安全应用、第二安全应用,此时从本地缓存中调用相应安全应用的预响应信息的时间分别均为10s,而又因为是并发调用,所以,此时从本地缓存调用第一安全应用、第二安全应用的整体时间也只有10s。进而,所述网络设备1基于读取的所述预响应信息,或是通过其他调用获取的信息,进一步进行风险决策,例如确定所述安全风险信息,并确定风险警示信息,最终将所述决策结果、如风险警示信息返回至用户设备2。
在此,若是基于现有技术,不进行所述预响应信息的预先调用和缓存,则在用户进行提交支付时,由网络设备1实时从所述辅助应用中并行调用第一安全应用、第二安全应用的总时间将是500s,远远大于本申请实现的10s调用时间。
对于本领域技术人员而言,显然本申请不限于上述示范性实施例的细节,而且在不背离本申请的精神或基本特征的情况下,能够以其他的具体形式实现本申请。因此,无论从哪一点来看,均应将实施例看作是示范性的,而且是非限制性的,本申请的范围由所附权利要求而不是上述说明限定,因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外,显然“包括”一词不排除其他单元或步骤,单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一,第二等词语用来表示名称,而并不表示任何特定的顺序。