CN116233248A - 资源响应方法、设备及可读存储介质 - Google Patents
资源响应方法、设备及可读存储介质 Download PDFInfo
- Publication number
- CN116233248A CN116233248A CN202310099442.5A CN202310099442A CN116233248A CN 116233248 A CN116233248 A CN 116233248A CN 202310099442 A CN202310099442 A CN 202310099442A CN 116233248 A CN116233248 A CN 116233248A
- Authority
- CN
- China
- Prior art keywords
- resource file
- cache server
- target
- resource
- keyword
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Information Transfer Between Computers (AREA)
Abstract
本申请公开了一种资源响应方法、设备及可读存储介质,缓存服务器接收到用于请求目标资源文件的请求报文后,根据请求报文确定出一级关键字,当缓存服务器已缓存一级关键字对应的资源文件集合中的至少一个资源文件时,从资源文件集合中确定出目标资源文件,向终端设备响应目标资源文件。其中,资源文件集合用于存储源站为目标URL提供的资源文件。采用该种方案,通过根据不包含查询字符串的一级关键字缓存URL的资源文件,使得缓存服务器上同一URL的资源文件数量最多等于源服务器上资源文件的数量,且无需源服务器提供Etag响应头,降低对缓存服务器的存储容量的要求且提高资源文件命中率。
Description
技术领域
本申请实施例涉及通信技术领域,特别涉及一种资源响应方法、设备及可读存储介质。
背景技术
目前,网络中部署缓存服务器,缓存服务器上缓存从源服务器拉取的各种资源文件。当用户请求资源文件时,用户请求被引导到就近的缓存服务器,使得用户可以就近获取到资源文件,从而降低网络拥塞,提高用户访问响应速度和命中率。
通常情况下,服务器根据统一资源定位符(Uniform Resource Locator,URL)缓存资源文件,一个URL对应一个或多个资源文件。例如,一个URL对应两个资源文件,其中一个用于响应PC端浏览器,另一个用于响应移动端浏览器。也就是说,PC端浏览器和移动端浏览器针对同一个URL请求资源文件时,缓存服务器响应不同的资源文件。缓存服务器采用Vary缓存机制。基于该机制,缓存服务器接收到用户的资源请求时,若本地未缓存用户期望的资源文件,则向源服务器转发资源请求。源服务器向缓存服务器发送资源响应,该资源响应携带Vary响应头和资源文件,Vary响应头指定请求头的值(简称Vary值)。缓存服务器缓存请求头的值和资源文件的对应关系。例如,Vary响应头指定的请求头为Accept-Encoding,值为gzip,则缓存服务器缓存Accept-Encoding请求头、gzip和资源文件的对应关系。后续再次接收到资源请求时,只有资源请求中携带Accept-Encoding请求头且值为gzip时,才能将缓存的资源文件响应给用户。倘若资源请求未携带Accept-Encoding请求头,或者,即使携带了Accept-Encoding请求头但是值不是gzip,则缓存服务器不能将资源文件响应给用户,只能回源服务器拉取资源。
然而,虽然请求头的个数是有限的,但是请求头的值的个数通常是无限的,当缓存服务器按照一个Vary值对应一个资源文件的方式缓存资源文件时,导致同一个URL会有无穷多个资源文件,对存储容量的要求极高,成本高且命中率低。因此,如何缓存资源文件并快速响应用户实为亟待解决的问题。
发明内容
本申请实施例提供一种资源响应方法、设备及可读存储介质,通过根据URL的一级关键字缓存该URL的资源文件,使得缓存服务器上同一URL的资源文件数量最多等于源服务器上资源文件的数量,且无需源服务器提供Etag响应头,降低对缓存服务器的存储容量的要求且提高资源文件命中率。
第一方面,本申请实施例提供一种资源响应方法,应用于缓存服务器,该方法包括:
接收来自终端设备的请求报文,所述请求报文用于请求目标资源文件;
根据所述请求报文确定目标URL的一级关键字,所述一级关键字不包含所述目标URL中的查询字符串,所述目标URL是所述请求报文指示的URL;
从所述一级关键字对应的资源文件集合中确定出所述目标资源文件,所述资源文件集合用于存储源站为所述目标URL提供的资源文件;
向所述终端设备发送携带所述目标资源文件的响应报文。
第二方面,本申请实施例提供一种电子设备,包括:处理器、存储器及存储在所述存储器上并可在处理器上运行的计算机程序,所述处理器执行所述计算机程序时使得所述电子设备实现如上第一方面各种可能的实现方式所述的方法。
第三方面,本申请实施例提供一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机指令,所述计算机指令在被处理器执行时用于实现如上第一方面各种可能的实现方式所述的方法。
第四方面,本申请实施例提供一种包含计算程序的计算机程序产品,所述计算机程序被处理器执行时实现如上第一方面各种可能的实现方式所述的方法。
本申请实施例提供的资源响应方法、设备及可读存储介质,缓存服务器接收到用于请求目标资源文件的请求报文后,根据请求报文确定出一级关键字,当缓存服务器已缓存一级关键字对应的资源文件集合中的至少一个资源文件时,从资源文件集合中确定出目标资源文件,向终端设备响应目标资源文件。其中,资源文件集合用于存储源站为目标URL提供的资源文件。采用该种方案,通过根据不包含查询字符串的一级关键字缓存URL的资源文件,使得缓存服务器上同一URL的资源文件数量最多等于源服务器上资源文件的数量,且无需源服务器提供Etag响应头,降低对缓存服务器的存储容量的要求且提高资源文件命中率。
附图说明
为了更清楚地说明本申请实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1A是本申请实施例提供的资源响应方法的网络架构示意图;
图1B是本申请实施例提供的资源响应方法适用的CDN网络的架构示意图;
图2是本申请实施例提供的资源响应方法的流程图;
图3是本申请实施例提供的资源响应方法中采用一级关键字和二级关键字缓存资源文件的示意图;
图4是本申请实施例提供的资源响应方法的一个响应过程示意图;
图5是本申请实施例提供的资源响应方法的另一个响应过程示意图;
图6A是本申请实施例提供的资源响应方法的过程示意图;
图6B是图6A对应的流程图;
图7为本申请实施例提供的一种资源响应装置的示意图;
图8为本申请实施例提供的一种电子设备的结构示意图。
具体实施方式
目前,缓存服务器的一个重要功能是缓存某条URL的资源文件,便于后面访问该URL的客户端更快得到响应。实际场景中,一些URL与资源文件是一对多的关系。
例如,对于同一条URL,源服务器提供两个资源文件,一个用于响应PC端浏览器,一个用于响应移动端浏览器。
再如,对于同一条URL,源服务器针对不同的压缩算法提供不同的资源文件。不同的压缩算法例如为gzip算法、br算法等。
又如,对于同一条URL,源服务器针对不同的地区缓存不同的资源文件,不同地区例如为亚洲、欧洲等。
又如,对于同一条URL,源服务器针对不同的用户提供不同的资源文件。用户信息携带在Cookie请求头中。
通常情况下,缓存服务器采用HTTP协议提供的“缓存协商响应”方法(简称Vary缓存机制)缓存资源文件。基于该机制,源服务器通过响应报文中的Vary响应头,告诉缓存服务器使用哪些请求头缓存资源文件,即缓存服务器缓存资源文件时,同时缓存资源文件与请求头的值的对应关系。当缓存服务器接收到的新的报文请求中存在Vary指定的请求头、且请求头的值与资源文件的请求头的值相同时,缓存服务器才将已缓存的资源文件作为新请求的响应。其中,Vary指定的请求头的值又称作Vary值。
以某条URL指定Accept-Encoding请求头的值作为Vary值为例,假设源服务器提供两份资源文件,一份资源文件采用gzip压缩方式,另一份资源文件是未压缩的资源文件、指定Vary值为gzip,缓存服务器接收到请求报文后,若未缓存资源文件,则从源服务器拉取资源文件,并缓存资源文件与gzip的对应关系。后续若再次接收到用于访问该URL的报文请求,则只有在Accept-Encoding请求头的值为gzip时,缓存服务器才能将缓存的资源文件响应给终端设备。倘若请求报文没有携带Accept-Encoding请求头,或者,即使携带了Accept-Encoding请求头但是值不是gzip,则不能将资源文件响应给终端设备,只能从源服务器拉取资源文件并缓存。例如,请求报文携带Accept-Encoding请求头,且值为br,则缓存服务器从源站拉取未压缩的资源文件,并缓存未压缩的资源文件与br的对应关系。
之后,缓存服务器接收到请求报文,该请求报文的Accept-Encoding请求头的值为deflate,则缓存服务器从源站拉取未压缩的资源文件,并缓存未压缩的资源文件与deflate的对应关系。显然,即使针对br算法和deflate算法响应的均是未压缩的资源文件,但是缓存服务器上缓存两个未压缩的资源文件,极度冗余。显然,基于Vary缓存机制,即使源服务器提供有限的资源文件,但是缓存服务器会缓存无穷多个文件。
Vary缓存机制的优势如下:缓存服务器不需要额外的改造,按照HTTP协议的规范执行即可。
Vary缓存机制的缺点如下:请求头的值的个数通常是无限的,导致Vary值的范围无穷大。若按照一个Vary值对应一个资源文件的方式缓存,则针对同一个URL,缓存服务器会缓存无穷多个资源文件,对存储容量的要求极大,同时导致缓存服务器的缓存命中率降低。
为克服Vary缓存机制的弊端,业界对缓存服务器进行如下优化:
当缓存服务器上未缓存终端设备请求的资源文件时则回源,即缓存服务器向源服务器发送请求报文。源服务器向缓存服务器发送携带资源文件的响应报文,该响应报文还携带Etag响应头以及Etag响应头的值。缓存服务器缓存资源文件以及对应的Etag响应头的值,后续缓存服务器根据Etag响应头对不同的资源文件进行复用。也就是说,即使不同的请求报文均携带Vary指定的请求头,且请求头的值不同,但是由于Etag响应头的值相同,则缓存服务器响应同一个资源文件。
例如,源服务器只支持gzip压缩方式。当缓存服务器接收到一个请求报文,该请求报文的Accept-Encoding请求头的值为gzip时,若缓存服务器上未缓存请求报文所请求的资源文件,则缓存服务器回源,即从源站拉取资源文件。缓存服务器接收携带资源文件1的响应报文,该响应报文的Etag响应头的值为a,资源文件1为采用gizp压缩方式得到的资源文件。缓存服务器缓存资源文件1、gzip和a的关系。
后续缓存服务器接收到另一个请求报文,该请求报文的Accept-Encoding请求头的值为br,缓存服务器回源。缓存服务器接收到携带资源文件2的响应报文,该响应报文的Etag响应头的值为b,资源文件2为未压缩的资源文件。缓存服务器缓存资源文件2、br和b的关系。
后续缓存服务器又接收到一个请求报文,该请求报文的Accept-Encoding请求头的值为Wzip,缓存服务器回源。缓存服务器接收到携带资源文件2的响应报文,该响应报文的Etag响应头的值为b,资源文件2为未压缩的资源文件。缓存服务器缓存资源文件2、br、Wzip和b的关系。
之后,若缓存服务器继续接收到Accept-Encoding请求头的值为br或Wzip的请求报文,则将本地缓存的资源文件2响应给终端设备。
显然,经过上述优化,即使两个不同的请求报文均携带Vary指定的请求头,且请求头的值不同,但是由于Etag响应头的值相同,则缓存服务器响应同一个资源文件。同时,缓存服务器上同一条URL的资源文件的数量,等于源服务器上针对该URL的资源文件数量。
但是,上述优化方式的前提是:源服务器必须提供Etag响应头。然而,并非所有的源服务器都会提供Etag响应头。
根据上述可知:源服务器不可能针对每种请求头的值准备一份资源文件,而是只能准备有限的几份资源文件。当源服务器不提供Etag响应头,或者,缓存服务器没有对Vary缓存机制进行优化,缓存服务器缓存的资源文件的数量非常大,使得缓存服务器和源服务器容易被恶意攻击。以Vary值为User-Agent请求头的值为例,攻击者伪造大量User-Agent请求头的值,不同请求报文携带User-Agent请求头的不同值,使得缓存服务器消耗大量的存储资源,同时缓存服务器的命中率为0。而且,缓存服务器每次接收到请求报文后,由于Vary值不同,则回源以从源服务器拉取资源,给源服务器带来巨大的压力。
Squid缓存服务器和Nginx缓存服务器为两种常见的支持Vary缓存机制的缓存服务器。Squid缓存服务器通常采用Vary缓存机制缓存资源文件,将请求方法+请求协议+URL+Vary值作为缓存资源的缓存关键字(key)。由于关键字包括Vary值,而Vary值的取值范围是无穷大的,导致对Squid服务器的存储容量的要求高、同时导致命中率差。
Nginx服务器利用变量自由拼接出缓存关键字,内置Vary缓存机制,即不需要将Vary请求头配在缓存关键字中,该种缓存机制十分灵活,扩展性极强。然而,过分灵活可能导致不合理的配置,使得缓存出错。例如,若使用一个不包含变量的字符串作为缓存关键字,将使得所有的URL对应到同一个资源文件。
基于此,本申请实施例提供一种资源响应方法、设备及可读存储介质,通过根据URL的一级关键字缓存该URL的资源文件,使得缓存服务器上同一URL的资源文件数量最多等于源服务器上资源文件的数量,且无需源服务器提供Etag响应头,降低对缓存服务器的存储容量的要求且提高资源文件命中率。
图1A是本申请实施例提供的资源响应方法的网络架构示意图。请参照图1A,该网络架构包括缓存服务器11、源服务器12和终端设备13,缓存服务器11和源服务器12之间建立网络连接,缓存服务器11和终端设备13之间建立网络连接。
缓存服务器11上缓存从源服务器12上拉取的资源文件。当缓存服务器11接收到来自终端设备13的请求报文后,若本地已缓存请求报文所请求的资源文件,则缓存服务器将本地的资源文件响应给终端设备13。若缓存服务器11本地未缓存请求报文所请求的资源文件,则从源服务器12拉取资源文件并缓存,以便后续再次接收到请求同一资源文件的请求报文后,无需回源从源服务器12拉取资源文件。
缓存服务器11例如是内容分发网络(Content Delivery Network,CDN)中的边缘节点等,缓存服务器11可以是硬件也可以是软件。当缓存服务器11为硬件时,该缓存服务器11为单个服务器或多个服务器组成的分布式服务器集群。当缓存服务器11为软件时,可以为多个软件模块或单个软件模块等,本申请实施例并不限制。
源服务器12是缓存服务器11的上级服务器。源服务器12可以是硬件也可以是软件。当服务器12为硬件时,该服务器12为单个服务器或多个服务器组成的分布式服务器集群。当服务器12为软件时,可以为多个软件模块或单个软件模块等,本申请实施例并不限制。
终端设备13可以是硬件也可以是软件。当终端设备13为硬件时,终端设备13例如为手机、平板电脑、电子书阅读器、膝上型便携电脑、台式计算机、服务器等。当终端设备13为软件时,其可以安装在上述列举的硬件设备中,此时,终端设备13例如为多个软件模块或单个软件模块等,本申请实施例并不限制。
应当理解的是,图1中的缓存服务器11、源服务器12和终端设备13的数量仅仅是示意性的。实际实现中,根据实际需求部署任意数量的缓存服务器11、源服务器12和终端设备13。
另外,CDN网络包含多级缓存节点,不同的场景中,同一个缓存节点可以作为上述的缓存服务器11,也可以作为上述的源服务器12。示例性的,请参照图1B,图1B是本申请实施例提供的资源响应方法适用的CDN网络的架构示意图。
请参照图1B,CDN网络包括多级缓存节点,如上层节点14、中层节点15和边缘节点16。其中,上层节点14与源站17直接通信连接,中层节点15与上层节点14之间、中层节点15和边缘节点16之间建立网络连接。本申请实施例提供的资源响应方法可应用于任意一级缓存节点。即本申请实施例中的缓存服务器11可以是任意一级缓存节点。边缘节点16用于接收来自终端设备的请求报文。
例如,当缓存服务器11是边缘节点16时,源服务器12为中层节点15;当缓存服务器11为中层节点15时,源服务器12为上层节点14;当缓存服务器11为上层节点14时,源服务器12为源站17。总之,当本级缓存节点接收到下级缓存节点或终端设备的报文请求后,若本地未缓存报文请求所请求的资源文件,则从上级节点拉取资源文件。本申请实施例提供的资源响应方法,可以应用于任一级缓存节点。
下面,基于图1A和图1B所示网络架构,对本申请实施例提供的资源响应方法进行详细说明。示例性的,请参照图2。
图2是本申请实施例提供的资源响应方法的流程图。本实施例是从缓存服务器的角度进行说明。本实施例包括:
201、接收来自终端设备的请求报文,所述请求报文用于请求目标资源文件。
本申请实施例中,资源文件包括视频、音频、图片、网页等,请求报文例如是超文本传输协议(HyperText Transfer Protocol,HTTP)请求报文或超文本传输安全协议(HyperText Transfer Protocol Secure,HTTPS)请求报文。
请参照图1B,当缓存服务器为边缘节点时,缓存服务器接收来自在终端设备的报文请求。另外,当缓存服务器为中层节点时,则接收来自边缘节点的报文请求;当缓存服务器为上层节点时,则接收来自中层节点的报文请求。
202、根据请求报文确定目标URL的一级关键字,所述一级关键字不包含所述目标URL中的查询字符串,所述目标URL是所述请求报文指示的URL。
本申请实施例中,针对每个URL,缓存服务器缓存该URL对应的资源文件,一个URL可能对应一个或多个资源文件。缓存服务器根据请求报文确定出的URL称之为目标URL。
当目标URL是请求报文中一个连续的字符串时,缓存服务器从请求报文中提取出该字符串,并将该字符串作为目标URL。当目标URL是请求报文中分散的字符串的组合时,缓存服务器提取出每个字符串,然后拼接该些字符串从而得到目标URL。
例如,缓存服务器提供缓存功能的同时,也是一个正向代理服务器。请求报文的请求行和Host请求头如下:
GET https://xxxx.com/item/5937042?fromtitle=URL&fromid=110640&fr=aladdin HTTP/1.1
Host:xxx.com
该请求报文中URL是一个完整的字符串https://xxxx.com/item/5937042?fromtitle=URL&fromid=110640&fr=aladdin HTTP/1.1,因此,缓存服务器提取出该完整的字符串作为目标URL。
根据该请求报文可知:请求方法为GET,GET后面是空格,空格后是一个完整的URL,即https://xxxx.com/item/5937042?fromtitle=URL&fromid=110640&fr=aladdin,URL后面是协议版本。请求报文的Host请求头的值是一个域名,该域名和请求报文中的URL的域名相同。
然而,本申请实施例并不限制,其他可行的实现方式中,若请求行中具有完整的URL,则无论请求报文是否包含Host请求头、Host请求头的值和请求行中的URL的域名是否相同,缓存服务器均将从请求行中提取出的URL作为目标URL。
再如,缓存服务器不提供正向代理功能,接收到的请求报文的请求行和Host请求头如下:
GET/item/5937042?fromtitle=URL&fromid=110640&fr=aladdin HTTP/1.1
Host:xxx.com
该请求报文中,请求行中的URL不完整,缓存服务器从请求行中提取出如下字符串:/item/5937042?fromtitle=URL&fromid=110640&fr=aladdin,同时提取出Host请求头的值xxx.com,将这俩个字符串拼接起来得到目标URL:https://xxxx.com/item/5937042?fromtitle=URL&fromid=110640&fr=aladdin。
本申请实施例中,由于资源文件集合用于存储源站为所述目标URL提供的资源文件。因此,资源文件集合中资源文件的数量至多为源站为所述目标URL提供的资源文件的数量,且资源文件集合中的资源文件数量本身具有差异性,如压缩方式不同、对应的浏览器不同等。
一级关键字又称作主关键字(key),即主key。若缓存服务器确定一级关键字的时候仅考虑目标URL,则一级关键字和目标URL是一一对应的。若缓存服务器确定一级关键字的时候结合目标URL和请求方法,则目标URL和一级关键字是一对多的关系,一级关键字的数量最多等于请求方法的数量。缓存服务器每次从源服务器拉取资源文件后,将该资源文件存储在一级关键字对应的资源文件集合中。
缓存服务器根据目标URL中的协议类型、域名、资源名等确定出一级关键字。当目标URL包含查询字符串时,一级关键字不包含目标URL中的查询字符串。查询字符串是同一URL下的差异化参数,也就是说,本申请实施例中,同一URL下的差异化参数并不能体现在一级关键字,而一些传统的缓存方案中,缓存服务器缓存资源文件时,将URL以及同一URL下的差异化参数等作为关键字存储资源文件,使得缓存服务器缓存的资源文件的个数无限多。
继续沿用上述的例子,缓存服务器根据目标URL和请求方法确定出一级关键字为:GET https://xxxx.com/item/5937042。该一级关键字不包含目标URL中的查询字符串。
203、从所述一级关键字对应的资源文件集合中确定出所述目标资源文件,所述资源文件集合用于存储源站为所述目标URL提供的资源文件。
缓存服务器确定出一级关键字后,从缓存服务器已缓存的资源文件中确定出关于目标URL的、一级关键字对应的资源文件集合,并从资源文件集合中确定出目标资源文件。例如,若目标URL仅有一级关键字,源服务器针对该一级关键字仅准备了一份资源文件,且缓存服务器在本次接收到请求报文之前已缓存该资源文件,则缓存服务器将该资源文件作为目标资源文件。若目标URL具有多个一级关键字,缓存服务器根据请求报文确定出一级关键字,从该一级关键字对应的资源文件集合中确定出目标资源文件,
204、向终端设备发送携带所述目标资源文件的响应报文。
缓存服务器确定出目标资源文件后,生成携带目标资源文件的响应报文并响应给终端设备。另外,若缓存服务器为上述图1B中的中层缓存节点,则向边缘缓存节点发送携带目标资源文件的响应报文;若缓存服务器为上述图1B中的上层缓存节点,则向中层缓存节点发送携带目标资源文件的响应报文。
本申请实施例提供的资源响应方法,缓存服务器接收到用于请求目标资源文件的请求报文后,根据请求报文确定出一级关键字,当缓存服务器已缓存一级关键字对应的资源文件集合中的至少一个资源文件时,从资源文件集合中确定出目标资源文件,向终端设备响应目标资源文件。其中,资源文件集合用于存储源站为目标URL提供的资源文件。采用该种方案,通过根据不包含查询字符串的一级关键字缓存URL的资源文件,使得缓存服务器上同一URL的资源文件数量最多等于源服务器上资源文件的数量,且无需源服务器提供Etag响应头,降低对缓存服务器的存储容量的要求且提高资源文件命中率。
可选的,上述实施例中,缓存服务器根据请求报文确定一级关键字的过程中,根据所述请求报文确定所述目标URL,之后确定目标URL是否携带问号。若目标URL携带问号,则缓存服务器从目标URL中确定出有效字段,根据所述有效字段和所述请求报文指示的请求方法确定所述一级关键字。其中,所述有效字段包含所述目标URL中问号之前的字符。
例如,目标URL为:https://xxxx.com/item/5937042?fromtitle=URL&fromid=110640&fr=aladdin。
该目标URL包含?,因此,缓存服务器从目标URL提取出有效字段:https://xxxx.com/item/5937042。之后,缓存服务器根据请求报文中的请求方法和有效字段生成一级关键字。假设请求方法为GET,则一级关键字为GET https://xxxx.com/item/5937042;假设请求方法为HEAD,则一级关键字为HEAD https://xxxx.com/item/5937042。
当所述目标URL未携带问号时,缓存服务器根据所述目标URL和所述请求报文指示的请求方法确定所述一级关键字。
例如,目标URL为:https://xxxx.com/item/5937042。该目标URL不包含?,因此,缓存服务器根据请求报文中的请求方法和目标URL生成一级关键字。假设请求方法为GET,则一级关键字为GET https://xxxx.com/item/5937042;假设请求方法为HEAD,则一级关键字为HEAD https://xxxx.com/item/5937042。
需要说明的是,本申请实施例中,缓存服务器确定出一级关键字后,一级关键字的值为初始值。若未做特殊说明,根据一级关键字确定资源文件集合,是指根据一级关键字的初始值确定资源文件集合。
采用该种方案,缓存服务器根据请求方法和不带问号的目标URL生成一级关键字,或者,缓存服务器根据请求方法和带问号的目标URL中的有效字段生成一级关键字,速度快、准确率高。
可选的,上述实施例中,缓存服务器从所述一级关键字对应的资源文件集合中确定出所述目标资源文件的过程中,首先,根据所述请求报文中的附加参数确定二级关键字,同一个URL的不同的二级关键字对应不同的资源文件。之后,根据所述二级关键字从所述资源文件集合中确定出所述目标资源文件。
本申请实施例中,目标URL可能对应一个或多个一级关键字,例如,每个不同的请求方法和同一个目标URL组合成不同的一级关键字,每个一级关键字对应的资源文件集合中包含一个或多个资源文件。缓存服务器根据请求报文确定出目标URL的一级关键字。当目标URL只有一个资源文件时,缓存服务器只用一级关键字缓存该资源文件,此时,一级关键字对应的资源文件集合中仅有一个资源文件。缓存服务器预先加载的配置文件指示:该一级关键字下仅有一个资源文件,无需进行二级关键字的查询。因此,缓存服务器后续再接收到请求报文后,根据该请求报文确定出目标URL,进而确定出一级关键字,将该一级关键字的资源文件集合中唯一的资源文件响应给终端设备。例如,目标资源文件为一个图片,该图片具有一个一级关键字。不论请求报文中的Accept-Encoding请求头指示哪种压缩算法、发起请求报文的终端设备位于哪个地区……,缓存服务器不区分压缩算法、地区等,都将该图片响应给终端设备。
当一级关键字对应的资源文件集合中有多个资源文件时,缓存服务器根据一级关键字确定出资源文件集合后,进一步的确定出二级关键字,根据二级关键字从资源文件集合中确定出目标资源文件。例如,缓存服务器根据同一目标URL下的差异化参数确定二级关键字,差异化参数往往是一些变量。变量包括但不限于目标URL中的查询字符串、请求报文中的请求协议版本等,本申请实施例并不限制。缓存服务器使用正则表达式匹配某一类变量,将该变量映射到一个固定值,该固定值即为二级关键字。
图3是本申请实施例提供的资源响应方法中采用一级关键字和二级关键字缓存资源文件的示意图。请参照图3,针对目标URL,缓存服务器根据目标URL和请求报文中的请求方法确定一级关键字,一级关键字对应一个资源文件集合。资源文件集合中的每个资源文件具有二级关键字,二级关键字例是缓存服务器根据附加参数确定出的。
例如,附加参数为Accept-Encoding请求头的值,缓存服务器接收到用于访问同一个URL,即目标URL的N个请求报文,Accept-Encoding请求头的值分别为附加参数1(如Gzip)、附加参数2(如Wzip)……附加参数N(如other),缓存服务器确定各附加参数对应的二级关键字,若本地未缓存二级关键字对应的资源文件,则从源站拉取并缓存。缓存过程中,各资源文件具有相同的一级关键字,但是二级关键字不同。如图3中,资源文件1对应二级关键字1,资源文件2对应二级关键字2,……资源文件N对应二级关键字N,各二级关键字对应同一个一级关键字。
因此,缓存服务器接收到一个请求报文,确定出一级关键字后,即可确定出包含多个资源文件的资源文件集合。之后,缓存服务器读取配置文件发现:需要进一步的根据附加参数确定二级关键字,则缓存服务器进一步的确定出二级关键字,并从资源文件集合中确定出目标资源文件。
例如,针对某个URL,源服务器准备了2份资源文件,分别为支持gzip压缩方式的资源文件和支持br压缩方式的资源文件。该2份资源文件的二级关键字分别为gzip、br,一级关键字根据目标URL和请求方法确定出。缓存服务器上预先加载的配置文件指示的用于确定二级关键字的附加参数为Accept-Encoding请求头的值,则缓存服务器每次接收到请求报文后,根据请求报文确定出Accept-Encoding请求头的值。若Accept-Encoding请求头的值为gzip,则缓存服务器根据二级关键字gzip从资源文件集合中确定出支持gizp压缩方式的资源文件。若Accept-Encoding请求头的值为br,则缓存服务器确定出二级关键字为br,缓存服务器根据二级关键字br从资源文件集合中确定出支持br压缩方式的资源文件。
本申请实施例中,当缓存服务器采用一级关键字+二级关键字的结构缓存资源文件时,若需要对一级关键字对应的资源文件集合内的资源文件进行删除或更新,则通过一级关键字能够快速找到资源文件集合,便于删除或更新资源文件集合内的所有资源文件。
当源服务器更新了这条URL对应的资源文件集合后,需要缓存服务器也更新对应的资源文件集合。源服务器的运维人员通过运维终端向所有的缓存服务器发送变更指令,各缓存服务器接收到变更指令后,若变更指令指示更新资源文件集合,则各缓存服务器根据变更指令确定出一级关键字,用一级关键字查找资源文件集合,并更新资源文件集合中“支持gzip压缩方式”的资源文件和“支持br压缩方式”的资源文件。
采用该种方案,通过两级关键字的结构缓存资源文件,使得一级关键字对应多个资源文件,不同二级关键字对应不同的资源文件,便于快速删除或更新资源文件集合内的所有资源文件。
可选的,上述实施例中,缓存服务器根据所述请求报文中的附加参数确定二级关键字时,根据所述附加参数查询匹配表以确定出所述二级关键字。其中,附加参数包括下述参数中的至少一个:请求协议版本、请求头的值、URL中的查询字符串等。其中,请求协议版本例如是HTTP/1.0、HTTP1.1、HTTP/2、HTTP/3等。
示例性的,缓存服务器上预先存储一个配置好的匹配表,该匹配表指示附加参数与二级关键字的对应关系。例如,附加参数为请求报文中的User-Agent请求头的值,源服务器为三种浏览器提供不同的资源文件,其他浏览器使用另一个缓存文件,则匹配关系如表1所示:
表1
请参照表1,针对某个URL,源服务器准备了4份资源文件,分别对应IE浏览器、火狐浏览器、Chrome浏览器和其他浏览器。该4份资源文件的二级关键字分别为ie、firefox、chrome、other,一级关键字根据目标URL和请求方法确定出。
缓存服务器接收到请求报文后,根据请求报文确定出一级关键字,根据本地的配置文件确定出该一级关键字对应一个资源文件集合,缓存服务器通过一级关键字+二级关键字的结构缓存各资源文件。其中,二级关键字是根据User-Agent请求头的值确定出的,User-Agent请求头的值可视为二级关键字的初始值。因此,缓存服务器根据一级关键字确定出资源文件集合。之后,若配置了匹配表,则缓存服务器根据User-Agent请求头的值查询匹配表即可确定出匹配值,进而根据匹配值从文件集合中确定出目标资源文件。匹配过程中,若User-Agent请求头的值与某一条匹配规则匹配,则该匹配规则为二级关键字的初始值和匹配值的对应关系;若匹配表中不存在User-Agent请求头的值,则将User-Agent请求头的值匹配为空字符串,根据空字符串确定二级关键字,如表1中的最后一列所示。
例如,User-Agent请求头的值为IE6.0,查询匹配表确定出匹配值为ie。因此,缓存服务器将目标URL的资源文件集合中二级关键字为ie的资源文件作为目标资源文件并响应给终端设备。
再如,请求报文中User-Agent请求头的值为Edge10.0,查询匹配表确定出匹配值为other,则缓存服务器将目标URL的资源文件中,二级关键字为other的资源文件作为目标资源文件新响应给终端设备。
根据表1所示匹配规则可知:可以将User-Agent请求头的值收敛为4个值,将映射后的值作为二级关键字。这样一来,针对目标URL,缓存服务器上最多只会缓存4份资源文件。
以上表1是以附加参数为User-Agent请求头的值为例,对如何去除冗余缓存文件进行说明。下面,以附加参数为Accept-Encoding请求头的值为例,对如何去除冗余缓存文件进行说明。
示例性的,针对某个URL,源服务器准备了2份资源文件,分别为支持gzip压缩方式的资源文件和未压缩的资源文件。该2份资源文件的二级关键字分别为gzip、other(实际中也可以是non-compressed、none等,本申请实施例并不限制),一级关键字根据目标URL和请求方法确定出。
缓存服务器接收到请求报文、提取出Accept-Encoding请求头的值后,若Accept-Encoding请求头的值为gzip,则缓存服务器根据二级关键字gzip从资源文件集合中确定出支持gizp压缩方式的资源文件。本实施例中,初始值为gzip,映射值为gzip,即初始值=gzip,一个映射值对应一个初始值。
若Accept-Encoding请求头的值为br,则缓存服务器确定出二级关键字为other,从资源文件集合中确定出未压缩的资源文件。
同理,若Accept-Encoding请求头的值为xxx1、xxx2等,则缓存服务器确定出二级关键字为other,从资源文件集合中确定出未压缩的资源文件。其中,xxx1、xxx2等表示恶意构造的Accept-Encoding请求头的值。当Accept-Encoding请求头的值为gzip以外的值时,即初始值为gzip以外的值时,映射值均为other,即一个映射值对应至少两个初始值。
显然,只有在Accept-Encoding请求头的值为gzip时,缓存服务器从资源文件集合中确定出支持gizp压缩方式的资源文件,当Accept-Encoding请求头的值为恶意构造的请求头的值、源服务器不支持的请求头的值时,缓存服务器根据该请求头确定出的二级关键字均为other,而不会针对每个不同的请求头的值缓存不同的资源文件,极大程度去掉冗余缓存文件、提高命中效率。
采用该种方案,采用附加参数映射的方式,将无限多的附加参数的值映射为有限数量的二级关键字,去除附加参数中大量冗余信息,有效减少缓存服务器上缓存的资源文件的数量,提高缓存服务器的缓存命中率的同时,减少缓存服务器到源服务器拉取资源文件的操作。
可选的,上述实施例中,当资源文件集合中未缓存所述目标资源文件或所述缓存服务器未缓存所述资源文件集合时,缓存服务器向源服务器发送所述请求报文。接着,缓存服务器接收来自所述源服务器的源响应报文,所述源响应报文携带所述目标资源文件、所述目标资源文件与所述一级关键字、所述目标资源文件与所述二级关键字的对应关系。之后,缓存服务器缓存所述目标资源文件、所述目标资源文件与所述一级关键字、所述目标资源文件与所述二级关键字的对应关系。
示例性的,以目标URL对应多个资源文件、即源站针对目标URL准备了多个资源文件为例,缓存服务器每次接收到下级节点或终端设备的请求报文后,根据请求报文确定目标URL。之后,读取本地的配置文件发现:对于该目标URL,需要采用一级关键字+二级关键字的结构缓存资源文件,二级关键字根据附加参数确定出(假设附加参数为User-Agent)。因此,缓存服务器进一步的根据目标URL确定一级关键字。若本地没有目标URL对应的资源文件集合,即资源文件集合为空,则表示缓存服务器未缓存该目标URL的任意资源文件。此时,缓存服务器向源服务器发送请求报文。
当缓存服务器接收到源响应报文后,从源响应报文中提取出目标资源文件。之后,按照一级关键字+二级关键字的结构缓存目标资源文件,并将目标资源文件响应给终端设备。假设一级关键字为HEAD https://xxxx.com/item/5937042,附加参数为User-Agent请求头,且值为ie6.0,则缓存服务器按照一级关键字+二级关键字的结构缓存目标URL的一个资源文件。其中,一级关键字为HEAD https://xxxx.com/item/5937042,二级关键字为ie。
后续再次接收到请求报文后,若一级关键字为HEAD https://xxxx.com/item/5937042,附加参数为User-Agent请求头,且根据User-Agent请求头的值确定出二级关键字为ie,则缓存服务器将已缓存的资源文件作为目标资源文件并响应给终端设备。
若一级关键字为HEAD https://xxxx.com/item/5937042,附加参数为User-Agent请求头,且根据User-Agent请求头的值确定出二级关键字是firefox,则缓存服务器回源拉取资源文件,拉取到资源文件后,缓存资源文件、一级关键字HEAD https://xxxx.com/item/5937042和二级关键字firefox的对应关系。
采用该种方案,缓存服务器按照一级关键字、二级关键字的顺序确定本地是否存在目标资源文件,若本地不存在目标资源文件,则回源以从源服务器拉取资源文件,提高资源响应成功率。
可选的,上述实施例中,缓存服务器还接收变更指令,该变更指令用于指示删除或更新目标URL对应的资源文件集合。之后,缓存服务器删除或更新目标URL对应的资源文件集合。
示例性的,当源服务器上资源文件集合更新或过期后,由于网络中的缓存服务器数量庞大,源服务器的运维人员并不知道哪个缓存服务器上缓存了目标URL的资源文件,因此,运维人员通过运维终端向各缓存服务器发送变更指令,该变更指令携带目标URL或目标URL的一级关键字。缓存服务器接收到指示删除资源文件的变更指令后,若本地缓存了资源文件集合,则删除资源文件集合,若本地未缓存资源文件集合,则丢弃变更指令。若缓存服务器接收到指示更新资源文件的变更指令后,若本地缓存了资源文件集合,则对资源文件集合中的资源文件进行更新,若本地未缓存资源文件集合,则丢弃变更指令。
采用该种方案,缓存服务器采用一级关键字+二级关键字的结构缓存资源文件,由于一级关键字下具有多个资源文件。当接收到变更指令后,能快速删除或更新资源文件集合,响应速度快。
图4是本申请实施例提供的资源响应方法的一个响应过程示意图。请参照图4,客户端发起的请求报文,请求报文的部分信息如下:
GET/web.htm?arg1=1HTTP/1.1
Host:cache.com
User-Agent:IE6.0
根据请求报文的请求行可知:请求方法为GET,目标资源文件的名称为web.htm,协议为http,查询字符串为arg=1;Host请求头的值为cache.com,User-Agent请求头的值为IE6.0。
缓存服务器根据请求报文确定出目标URL为:http://cache.com/web.htm?arg1=1。由于该目标URL携带?,且请求方法为GET,则缓存服务器确定出一级关键字为:
GET http://cache.com/web.htm
根据该一级关键字,缓存服务器确定出目标URL的资源文件集合,其包含三个资源文件,分别为:IE浏览器对应的资源文件1、chrome浏览器对应的资源文件2和其他浏览器对应的资源文件3。也就是说,针对目标URL,源服务器准备了3份资源文件,且缓存服务器本次接收到请求报文之前,已缓存这三份资源文件。
缓存服务器发现本地预先存储目标URL的匹配表,如表3所示:
表3
正则匹配 | 映射为 |
^IE.* | ie |
^Chrome.* | chrome |
.* | other |
由于User-Agent请求头的值为IE6.0,查询匹配表得到二级关键字为:ie,因此,缓存服务器确定出目标资源文件为资源文件1。
需要说明的是,本申请实施例中,一级关键字+二级关键字的结构是可选的。例如,某一条URL只有一个资源文件,则缓存服务器仅缓存一级关键字和资源文件,不需要任何二级资源文件。
本申请实施例中,默认缓存服务器根据上述的一级关键字的初始值缓存资源文件。若存在二级关键字,则采用一级关键字+二级关键字的结构缓存资源文件,默认缓存服务器接收到请求报文后,先根据一级关键字的初始值确定出目标URL的资源文件集合,再根据二级关键字从资源文件集合中确定出目标资源文件,以下将该种采用一级关键字的初始值缓存资源文件和查询资源文件的方式称之为默认规则。基于该默认规则,初始值不同的一级关键字对应不同的资源文件集合。
然而,本申请实施例并不限制,其他可选的实现方式中,不同一级关键字也可以共享资源文件,从而进一步地减少缓存服务器上资源文件的数量。
缓存服务器每次接收到请求报文后,根据请求报文确定出目标URL,进而确定出一级关键字的初始值。然后,缓存确定本地是否存在映射规则,映射规则用于指示所述一级关键字的初始值和映射值之间的对应关系。当所述缓存服务器上未配置所述映射规则时,缓存服务器根据所述一级关键字的初始值确定资源文件集合,从所述资源文件集合中确定出所述目标资源文件。当缓存服务器上配置关键字的映射规则时,缓存服务器根据一级关键字的初始值查找映射规则,确定出一级关键字的映射值,根据所述一级关键字的映射值确定出资源文件集合,从所述资源文件集合中确定出所述目标资源文件。
示例性的,若缓存服务器未配置映射规则,则缓存服务器采用上述的默认规则,即采用一级关键字的初始值缓存资源文件和查询资源文件。采用该种方案,初始值不同一级关键字可对应不同的资源文件集合,实现快速确定出目标资源文件的目的。
若缓存服务器上配置一级关键字的映射规则,则缓存服务器根据一级关键字的初始值查询映射规则,确定出一级关键字的映射值,并根据一级关键字的映射值确定出资源文件。示例性的,请参见表2。表2是本申请实施例提供的资源响应方法中一级关键字的初始值和映射值的映射关系。
表2
一级关键字的初始值 | 一级关键字的映射值 |
GET http://cache.+\.com/web.+\.htm | GET http://cache.com/web.htm |
请参照表2,若一级关键字初始值中的域名包含cache、且资源名包含web,则该一级关键字的映射值为GET http://cache.com/web.htm。例如,一级关键字的初始值为GEThttp://cache1.com/web1.htm,则映射值为GET http://cache.com/web.htm。再如,一级关键字的初始值为GET http://cache2.com/web2.htm,则映射值为GET http://cache.com/web.htm。
缓存服务器接收到请求报文后,根据请求报文确定目标URL,根据目标URL确定一级关键字的初始值。之后,查询映射表以确定出一级关键字的映射值。倘若还配置了二级关键字,则缓存服务器根据一级关键字的映射值确定资源文件集合,之后根据二级关键字从资源文件集合中确定出目标资源文件。若本地未缓存一级关键字的映射值对应的资源文件集合,或资源文件集合中没有目标资源文件,则回源以拉取目标资源文件。
需要说明的是,虽然不同一级关键字共享资源文件的方式会修改资源名称,如表2中将资源名web1.htm修改为web.htm、将资源名web2.htm修改为web.htm.但是默认的一级关键字包含“请求方法”和URL这两个重要信息,极大程度上降低了运营人员犯错的概率。
采用该种方案,不同的一级关键字,即不同的URL共享同一份资源文件,进一步的减少了缓存服务器上资源文件的数量,降低存储资源的消耗。
图5是本申请实施例提供的资源响应方法的另一个响应过程示意图。请参照图5,客户端1发起的请求报文,请求报文的部分信息如下:
GET/web1.htm?arg1=1HTTP/1.1
Host:cache1.com
User-Agent:IE6.0
根据请求报文的请求行可知:请求方法为GET,目标资源文件的名称为web1.htm,协议为http,查询字符串为arg1=1;Host请求头的值为cache1.com,User-Agent请求头的值为IE6.0。
缓存服务器根据请求报文确定出目标URL为:http://cache1.com/web1.htm?arg=1。由于该目标URL携带?,且请求方法为GET,则缓存服务器确定出一级关键字为:GEThttp://cache1.com/web1.htm。
缓存服务器读到本地配置发现:针对目标URL,已预先配置一级关键字的映射规则,但未配置二级关键字的匹配表,因此,缓存服务器根据一级关键字的初始值查询映射规则确定映射值。示例性的,请参照上述的表2。
请参照表2,缓存服务器确定出若一级关键字的初始值为GET http://cache.+\.com/web.+\.htm,则映射值为:GET http://cache.com/web.htm。若本地已缓存映射值对应的资源文件,则将该资源文件响应给终端设备。若本地未缓存该映射值对应的资源文件,则回源以拉起资源文件。
请继续参照图5,客户端2发起的请求报文,请求报文的部分信息如下:
GET/web2.htm HTTP/1.1
Host:cache2.com
User-Agent:IE6.0
根据请求报文的请求行可知:请求方法为GET,目标资源文件的名称为web2.htm,协议为http;Host请求头的值为cache2.com,User-Agent请求头的值为IE6.0。
缓存服务器根据请求报文确定出目标URL为:http://cache2.com/web1.htm。由于该目标URL未携带?,且请求方法为GET,则缓存服务器确定出一级关键字的初始值为:GEThttp://cache2.com/web2.htm。
缓存服务器读到本地映射规则发现:针对目标URL,已预先配置一级关键字的映射规则,因此,缓存服务器不采用默认的根据一级关键字的初始值确定资源文件集合的方式,而是根据一级关键字的初始值查询映射规则确定映射值。示例性的,请参照上述的表2。
请参照表2,缓存服务器确定出映射值为:GET http://cache.com/web.htm。若本地已缓存映射值对应的资源文件,则将该资源文件响应给终端设备。若本地未缓存该映射值对应的资源文件,则回源以拉起资源文件。
根据图5可知:不同的一级关键字共享资源文件,进一步的减少了缓存服务器缓存的资源文件的数量,降低存储资源的消耗。
图6A是本申请实施例提供的资源响应方法的过程示意图,图6B是图6A对应的流程图。请参照图6A和图6B,本实施例包括:
601、缓存服务器接收来自终端设备的请求报文。
602、缓存服务器根据请求报文确定目标URL,根据请求方法和目标URL确定一级关键字。
603、缓存服务器确定是否配置一级关键字对应的映射规则,若未配置映射规则,则执行步骤604;若预先配置映射规则,则执行步骤605。
604、缓存服务器将一级关键字的初始值作为最终值,之后执行步骤606。
605、缓存服务器根据一级关键字的初始值查询映射规则,以确定一级关键字的映射值,并将一级关键字的映射值作为最终值,之后执行步骤606。
606、缓存服务器读取配置文件确定是否需要计算二级关键字,若需要计算二级关键字,则执行步骤607;若无需计算二级关键字,则执行步骤612。
607、缓存服务器根据附加参数确定二级关键字的初始值。
示例性的,缓存服务器根据请求报文确定出附加参数的值等,根据附加参数的值确定出二级关键字初始值。例如,缓存服务器直接将附加参数的值作为二级关键字。
608、缓存服务器确定是否需要查询匹配表以确定二级关键字的匹配值。若需要确定二级关键字的匹配值,则执行步骤609,若不需要确定二级关键字的匹配值,则执行步骤610。
609、缓存服务器查询匹配表以确定二级关键字的匹配值,并将匹配值作为二级关键字的最终值。
匹配表如上1所示。
610、缓存服务器将二级关键字的初始值作为二级关键字的最终值。
611、缓存服务器根据一级关键字的最终值确定资源文件集合,进而根据二级关键字的最终值从资源文件集合中确定出目标资源文件。
612、缓存服务器根据一级关键字的最终值确定目标资源文件。
下述为本申请装置实施例,可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节,请参照本申请方法实施例。
图7为本申请实施例提供的一种资源响应装置的示意图。该资源响应装置700包括:接收模块71、确定模块72、处理模块73和发送模块74。
接收模块71,用于接收来自终端设备的请求报文,所述请求报文用于请求目标资源文件;
确定模块72,用于根据所述请求报文确定目标URL的一级关键字,所述一级关键字不包含所述目标URL中的查询字符串,所述目标URL是所述请求报文指示的URL;
处理模块73,用于从所述一级关键字对应的资源文件集合中确定出所述目标资源文件,所述资源文件集合用于存储源站为所述目标URL提供的资源文件;
发送模块74,用于向所述终端设备发送携带所述目标资源文件的响应报文。
一种可行的实现方式中,所述处理模块73从所述资源文件集合中确定出所述目标资源文件时,用于根据所述请求报文中的附加参数确定二级关键字,同一个URL的不同的二级关键字对应不同的资源文件;根据所述二级关键字从所述资源文件集合中确定出所述目标资源文件。
一种可行的实现方式中,所述处理模块73根据所述请求报文中的附加参数确定二级关键字时,用于根据所述附加参数查询匹配表以确定出所述二级关键字,所述匹配表中存储附加参数与二级关键字的映射关系,所述附加参数包括下述参数中的至少一个:请求协议版本、请求头的值、所述目标URL中的任意一个查询字符串。
一种可行的实现方式中,所述发送模块74,还用于当所述资源文件集合中未缓存所述目标资源文件或所述缓存服务器未缓存所述资源文件集合时,向源服务器发送所述请求报文;
所述接收模块71,还用于接收来自所述源服务器的源响应报文,所述源响应报文携带所述目标资源文件、所述目标资源文件与所述一级关键字、所述目标资源文件与所述二级关键字的对应关系;
所述处理模块73,还用于缓存所述目标资源文件、所述目标资源文件与所述一级关键字、所述目标资源文件与所述二级关键字的对应关系。
一种可行的实现方式中,所述确定模块72,用于根据所述请求报文确定所述目标URL,当所述目标URL携带问号时,从所述目标URL中确定出有效字段,根据所述有效字段和所述请求报文指示的请求方法确定所述一级关键字,所述有效字段包含所述目标URL中问号之前的字符;当所述目标URL未携带问号时,根据所述目标URL和所述请求报文指示的请求方法确定所述一级关键字。
一种可行的实现方式中,所述处理模块73从所述一级关键字对应的资源文件集合中确定出所述目标资源文件之前,还确定所述缓存服务器上是否配置映射规则,所述映射规则用于指示所述一级关键字的初始值和映射值之间的对应关系,一个映射值对应至少两个初始值;当所述缓存服务器上未配置所述映射规则时,根据所述一级关键字的初始值确定所述资源文件集合。
一种可行的实现方式中,所述处理模块73,还用于当所述缓存服务器上配置所述映射规则时,根据所述一级关键字的初始值确定所述一级关键字的映射值,根据所述一级关键字的映射值确定出所述资源文件集合。
一种可行的实现方式中,所述接收模块71,还用于接收变更指令,所述变更指令用于指示删除或者更新所述一级关键字对应的资源文件集合;
所述处理模块73,还用于删除或更新所述资源文件集合。
图8为本申请实施例提供的一种电子设备的结构示意图。如图8所示,该电子设备800例如为上述的缓存服务器,该电子设备800包括:
处理器81和存储器82;
所述存储器82存储计算机指令;
所述处理器81执行所述存储器82存储的计算机指令,使得所述处理器81执行如上缓存服务器实施的资源响应方法。
处理器81的具体实现过程可参见上述方法实施例,其实现原理和技术效果类似,本实施例此处不再赘述。
可选地,该电子设备800还包括通信部件83。其中,处理器81、存储器82以及通信部件83可以通过总线84连接。
本申请实施例还提供一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机指令,所述计算机指令被处理器执行时用于实现如上缓存服务器实施的资源响应方法。
本申请实施例还提供一种计算机程序产品,该计算机程序产品包含计算机程序,计算机程序被处理器执行时实现如上缓存服务器实施的资源响应方法。
本领域技术人员在考虑说明书及实践这里公开的申请后,将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本申请的真正范围和精神由下面的权利要求书指出。
应当理解的是,本申请并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求书来限制。
Claims (10)
1.一种资源响应方法,其特征在于,应用于缓存服务器,所述方法包括:
接收来自终端设备的请求报文,所述请求报文用于请求目标资源文件;
根据所述请求报文确定目标URL的一级关键字,所述一级关键字不包含所述目标URL中的查询字符串,所述目标URL是所述请求报文指示的URL;
从所述一级关键字对应的资源文件集合中确定出所述目标资源文件,所述资源文件集合用于存储源站为所述目标URL提供的资源文件;
向所述终端设备发送携带所述目标资源文件的响应报文。
2.根据权利要求1所述的方法,其特征在于,所述从所述一级关键字对应的资源文件集合中确定出所述目标资源文件,包括:
根据所述请求报文中的附加参数确定二级关键字,同一个URL的不同二级关键字对应不同的资源文件;
根据所述二级关键字从所述资源文件集合中确定出所述目标资源文件。
3.根据权利要求2所述的方法,其特征在于,所述根据所述请求报文中的附加参数确定二级关键字,包括:
根据所述附加参数查询匹配表以确定出所述二级关键字,所述匹配表中存储附加参数与二级关键字的映射关系,所述附加参数包括下述参数中的至少一个:请求协议版本、请求头的值、所述目标URL中的任意一个查询字符串。
4.根据权利要求2所述的方法,其特征在于,还包括:
当所述资源文件集合中未缓存所述目标资源文件或所述缓存服务器未缓存所述资源文件集合时,向源服务器发送所述请求报文;
接收来自所述源服务器的源响应报文,所述源响应报文携带所述目标资源文件、所述目标资源文件与所述一级关键字、所述目标资源文件与所述二级关键字的对应关系;
缓存所述目标资源文件、所述目标资源文件与所述一级关键字、所述目标资源文件与所述二级关键字的对应关系。
5.根据权利要求1至4任一项所述的方法,其特征在于,所述根据所述请求报文确定一级关键字,包括:
根据所述请求报文确定所述目标URL;
当所述目标URL携带问号时,从所述目标URL中确定出有效字段,根据所述有效字段和所述请求报文指示的请求方法确定所述一级关键字,所述有效字段包含所述目标URL中问号之前的字符;
当所述目标URL未携带问号时,根据所述目标URL和所述请求报文指示的请求方法确定所述一级关键字。
6.根据权利要求1至4任一项所述的方法,其特征在于,所述从所述一级关键字对应的资源文件集合中确定出所述目标资源文件之前,还包括:
确定所述缓存服务器上是否配置映射规则,所述映射规则用于指示所述一级关键字的初始值和映射值之间的对应关系;
当所述缓存服务器上未配置所述映射规则时,根据所述一级关键字的初始值确定所述资源文件集合。
7.根据权利要求6所述的方法,其特征在于,还包括:
当所述缓存服务器上配置所述映射规则时,根据所述一级关键字的初始值确定所述一级关键字的映射值;
根据所述一级关键字的映射值确定出所述资源文件集合。
8.根据权利要求1至4任一项所述的方法,其特征在于,还包括:
接收变更指令,所述变更指令用于指示删除或者更新所述一级关键字对应的资源文件集合;
删除或更新所述资源文件集合。
9.一种电子设备,包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的计算机程序,其特征在于,所述处理器执行所述计算机程序时使得所述电子设备实现如权利要求1至8任一所述的方法。
10.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,所述计算机程序被处理器执行时实现如权利要求1至8任一所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310099442.5A CN116233248A (zh) | 2023-02-09 | 2023-02-09 | 资源响应方法、设备及可读存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310099442.5A CN116233248A (zh) | 2023-02-09 | 2023-02-09 | 资源响应方法、设备及可读存储介质 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN116233248A true CN116233248A (zh) | 2023-06-06 |
Family
ID=86583865
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202310099442.5A Pending CN116233248A (zh) | 2023-02-09 | 2023-02-09 | 资源响应方法、设备及可读存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN116233248A (zh) |
-
2023
- 2023-02-09 CN CN202310099442.5A patent/CN116233248A/zh active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11909639B2 (en) | Request routing based on class | |
US11729294B2 (en) | Processing DNS queries to identify pre-processing information | |
US9608957B2 (en) | Request routing using network computing components | |
US9514243B2 (en) | Intelligent caching for requests with query strings | |
US8856279B2 (en) | Method and system for object prediction | |
US9479476B2 (en) | Processing of DNS queries | |
JP4806462B2 (ja) | ピアツーピア・ゲートウェイ | |
RU2642833C2 (ru) | Способ и устройство для обеспечения медиаресурса | |
WO2024124663A1 (zh) | 一种支持cdn缓存批量刷新的方法及装置 | |
CN107682281B (zh) | 一种sdn交换机和sdn交换机的应用管理方法 | |
US9805122B2 (en) | Search engine and method for performing a search for objects that correspond to a search request | |
CN116233248A (zh) | 资源响应方法、设备及可读存储介质 | |
KR100313847B1 (ko) | 북마크정보를이용한인터네트서비스장치및방법 | |
US12034824B2 (en) | Processing DNS queries to identify pre-processing information | |
KR20050046974A (ko) | 클러스터링 환경에서의 모바일 비즈니스 응용 서버간콘텐츠 캐쉬 동기화 방법 | |
CN114338686A (zh) | 一种cdn节点服务器的回源方法及装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |