请求处理方法、节点及存储介质

技术领域

本发明实施例涉及内容分发网络技术领域，特别涉及一种请求处理方法、节点及存储介质。

背景技术

当网页包含其它网站内容的链接——俗称外链，客户为了提高页面的加载速度，通常会使用内容分发网络(Content Delivery Network，CDN)提供加速服务，然而现有的CDN加速服务只能针对页面中包含的内链进行加速，难以对外链加速，这就导致了页面中部分内容响应缓慢，甚至无法显示。为了实现对外链的加速，目前的做法是在外链的域名之后拼接一个特殊的改写域名，从而使得外链能够基于改写域名使用CDN加速服务，以此达到加速效果，此外改写后的外链内容如果还有外链，也会被再次改写。

但现有方案中，为了使用CDN节点实现CDN加速服务，具体是将改写服务和CDN加速服务耦合在一起，即通过同一个模块或进程来实现，这就使得所有经过该模块或进程的资源，均会先进行改写流程，然后再执行CDN加速。然而在实际应用中，并非所有从源站获取到的资源都需要执行改写流程，因此现有方案不仅会导致请求响应延迟变大，同时会造成对改写性能的严重浪费，进而导致CDN节点整体服务出现瓶颈。

发明内容

本发明实施例的目的在于提供一种请求处理方法、节点及存储介质，旨在解决现有从源站返回的所有资源都需要执行改写业务，然后才反馈给客户端，不仅浪费改写性能，同时导致CDN加速服务效果差，影响CDN节点整体服务性能的技术问题。

为解决上述技术问题，本发明的实施例提供了一种请求处理方法，应用于节点，所述请求处理方法包括：接收客户端发送的第一资源请求，并对所述第一资源请求进行解析，确定所述第一资源请求访问的资源中是否包含外链；如果不包含，将所述第一资源请求发送至对应的源站；如果包含，基于所述第一资源请求生成第二资源请求，并将所述第二资源请求发送至所述源站；接收所述源站返回的资源，如果所述资源为基于所述第一资源请求返回的资源，则将所述资源发送给所述客户端，如果所述资源为基于第二资源请求返回的资源，则对所述资源进行改写，并将改写后的资源发送给所述客户端。

本发明的实施例还提供了一种节点，包括：至少一个处理器；以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如上文所述的请求处理方法。

本发明的实施例还提供了一种计算机可读存储介质，存储有计算机程序，所述计算机程序被处理器执行时实现如上文所述的请求处理方法。

CDN回源遵循的原则是请求发出去的流转过程是怎样的，收到的响应就会按照逆过程流转回客户端。基于这一原则，本发明实施例提供的请求处理方法、节点及存储介质，进行请求处理的节点，通过确定客户端发起的第一资源请求访问的资源中是否包括外链，进而在确定不包括外链时，基于第一资源请求进行回源，即直接基于第一资源请求从源站获取需要访问的资源，并将获取到的资源直接反馈给客户端，从而使得整个回源过程不会再经过改写流程，实现了对客户端发起的第一资源请求访问的资源的加速回源；在客户端发起的第一资源请求访问资源中存在外链时，则设置基于第一资源请求生成第二资源请求，然后再基于第二资源请求从源站获取资源，这样在源站返回的资源是基于第二请求获取的时候，便可以对该资源进行改写处理，然后才将改写后的资源返回给客户端。通过这种方式，既实现了改写业务的正常执行，又能加速不包含外链的资源回源。

此外，由于简化了改写流程，从而大大降低了CDN的性能开销，保证了CDN回源服务的质量。

附图说明

一个或多个实施例通过与之对应的附图中的图片进行示例性说明，这些示例性说明并不构成对实施例的限定，附图中具有相同参考数字标号的元件表示为类似的元件，除非有特别申明，附图中的图不构成比例限制。

图1是本发明实施例提供的请求处理方法的具体流程图；

图2是基于图1所示的请求处理方法，客户端、CDN节点和源站之间的交互关系示意图；

图3是本发明实施例提供的请求处理方法的又一具体流程图；

图4是本发明实施例的节点的结构示意图。

具体实施方式

本发明实施例中术语“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

本发明实施例中术语“多个”是指两个或两个以上，其它量词与之类似。

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合附图对本发明的各实施例进行详细的阐述。然而，本领域的普通技术人员可以理解，在本发明各实施例中，为了使读者更好地理解本发明而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施例的种种变化和修改，也可以实现本发明所要求保护的技术方案。以下各个实施例的划分是为了描述方便，不应对本发明的具体实现方式构成任何限定，各个实施例在不矛盾的前提下可以相互结合相互引用。

参见图1，图1是本发明实施例提供的请求处理方法的流程图，本实施例中，以内容分发网络CDN为例，请求处理方法主要应用于CDN节点。

如图1所示，本实施例提供的请求处理方法，包括以下步骤：

步骤101，接收客户端发送的第一资源请求，并对所述第一资源请求进行解析，确定所述第一资源请求访问的资源中是否包含外链。

具体的说，在万维网(World Wide Web，WWW，也称：3W)上，每一信息资源都有统一的且在网上唯一的地址，该地址就是统一资源定位符(Uniform Resource Locator，URL)，它是3W的统一资源定位标志，即网络地址，并且在URL中通常会携带所请求的资源的资源类型。因此基于URL便可以确定客户端发起的第一资源请求访问的资源中是否包含外链。

此外，可理解的，对于不同资源类型的资源，标识其具体类型的后缀名是不相同的，比如对于图片类型的资源，后缀名通常可以是.jpg、.png等，因此对于请求访问的资源为图片类型的资源时，获取到的客户端发起的第一资源请求对应的URL可能如下：https://csdnimg.cn/pubfooter/images/job-QR.png，对于该URL提取出的后缀名则为“.png”。

相应地，对于文本类型的资源，后缀名通常与是.txt，因此对于请求访问的资源为文本类型的资源时，获取到的客户端发起的第一资源请求对应的URL可能如下：https://vms.host.edu/disk$user/my/notes/note12345.txt，对于该URL提取出的后缀名则为“.txt”。

应当理解的是，上述示例仅是为了更好地理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

基于此，在接收到客户端发送的第一资源请求后，对第一资源请求进行解析，实质就是对第一资源请求对应的URL进行解析，提取URL的后缀名，然后根据从URL中提取的后缀名确定第一资源请求访问的资源中是否包含外链。

具体的说，在一个例子中，为了快速确定所述客户端发起的第一资源请求访问的资源中是否包含外链，可以预先构建一个后缀名集合，在该后缀名集合中预先录入不可能存在外链的多种资源类型对应的预设后缀名。进而在根据从URL中提取的后缀名确定第一资源请求访问的资源中是否包含外链时，直接将提取出的后缀名与预先构建的后缀名集合中的预设后缀名进行匹配即可。

具体的，若通过匹配，确定预先构建的后缀名集合中不存在与提取的后缀名匹配的预设后缀名，则确定所述客户端发起的第一资源请求访问的资源中包含外链，或者说可能存在外链，便可以进入步骤102；否则，确定所述客户端发起的第一资源请求访问的资源中不包含外链，即可以进入步骤103。

通过上述描述可知，在访问的资源为图片资源、音频资源、视频资源时，可以确定这类资源中不包含外链，因此预先构建的后缀名集合中的预设后缀名主要分为图片资源后缀名、音频资源后缀名和视频资源后缀名。

关于图片资源后缀名，包括但不限于：.bmp(位图)、.jpg、.jpeg、.png、.gif。

关于音频资源后缀名，包括但不限于：.mp3、.ogg、.wav、.ape、.cda、.au、.midi、.mac、.aac。

关于视频资源后缀名，包括但不限于：.rmvb、.wmv、.asf、.avi、.3gp、.mpg、.mkv、.mp4、.dvd、.ogm、.mov、.mpeg2、.mpeg4。

应当理解的是，上述示例仅是为了更好地理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

此外，值得一提的是，在实际应用中，如果客户端发起的第一资源请求访问的资源是二进制类型的资源，则也认为需要访问的资源中不包含外链。

此外，在具体实现中，可能存在URL中没有携带资源类型的情况，即URL没有携带能够标识需要访问的资源的类型的后缀名时，为了使本实施例提供的请求处理方法能够依旧被适用，在从URL中提取不到后缀名，或者预先构建的后缀名集合中没有匹配到对应的预设后缀名时，为了避免实际上不需要进行改写的资源对应的第一资源请求被修改为第二资源请求，进而导致回源过程中，所有响应信息要经过改写流程，既影响正常执行改写业务，又影响CDN加速服务，在确定所述客户端发起的第一资源请求访问的资源中包含外链的资源之前，可以基于HTTP请求支持的HEAD子请求进一步对所述客户端发起的第一资源请求访问的资源进行验证，最终根据验证结果来确定所述客户端发起的第一资源请求访问的资源中是否确实不包含外链，或包含外链。

具体的，先基于所述URL向所述客户端发起的第一资源请求访问的资源所在的源站发起HEAD子请求，然后根据所述源站返回的响应信息确定所述客户端发起的第一资源请求访问的资源中是否包含外链。

需要说明的，在实际应用中，基于HEAD子请求获取的源站返回的响应信息中仅包括第一资源请求访问的资源对应的元数据，不包含响应信息体，即不包含第一资源请求访问的资源。而元数据便可以体现需要访问的资源对应的具体类型，因此根据源站返回的响应信息，即元数据对应的需要访问的资源的具体类型，便可以确定客户端发起的第一资源请求访问的资源中是否包含外链。

相应地，如果根据所述源站返回的响应信息确定所述客户端发起的第一资源请求访问的资源中不包含外链，则执行上述所说的确定所述客户端发起的第一资源请求访问的资源中不包含外链的步骤；否则，执行上述所说的确定所述客户端发起的第一资源请求访问的资源中包含外链的资源的步骤。

由此不难发现，本实施例提供的请求处理方法，通过上述多种方式单独或组合的形式来确定客户端发起的第一资源请求访问的资源中是否包含外链，能够较为精准地将需要改写的资源和不需要改写的资源划分出来，避免对无需改写的资源执行改写流程，从而进一步降低对CDN节点的性能开销，优化CDN节点的回源服务。

步骤102，基于所述第一资源请求生成第二资源请求，并将所述第二资源请求发送至对应的源站。

步骤103，将所述第一资源请求发送至对应的源站。

步骤104，接收所述源站返回的资源，如果所述资源为基于所述第一资源请求返回的资源，则将所述资源发送给所述客户端，如果所述资源为基于第二资源请求返回的资源，则对所述资源进行改写，并将改写后的资源发送给所述客户端。

为了更好地理解本实施例提供的请求处理方法，以下同一个CDN节点中运行了两个独立的进程为例，即CDN加速服务和外链改写分别由两个单独运行的进程实现，为了便于说明以下将提供CDN加速服务的进程称为第一进程，将提供改写服务的进程称为第二进程。

也就是说，为了保证本实施例提供的请求处理方法的正常执行，首先需要对现有CDN节点中耦合在一起的CDN加速服务和改写服务进行解耦合处理，以将CDN加速服务能够由独立运行的第一进程实现，改写业务能够由独立运行的第二进程实现，即在同一个CDN节点内采用旁路部署的方式，由两个独立的进程分别实现CDN加速服务和改写业务。

如图2所示，运行在同一个CDN节点中的第一进程和第二进程在实现本实施例提供的请求处理方法时，具体流程为：

(1)由提供CDN加速服务的第一进程接收客户端发送的第一资源请求，并对所述第一资源请求进行解析，确定所述第一资源请求访问的资源中是否包含外链。

具体的说，上述接收到的第一资源请求具体是由客户端发起的，如一个超文本传输协议(HyperText Transfer Protocol，HTTP)请求。

此外，可理解的，在一个例子中，客户端发起的第一资源请求访问的资源大致可以分为如下两类：

不包含外链的资源，如图片资源、音频资源、视频资源、文本资源等，此处不再一一列举，本实施例对此不做限制。

包含，或可能包含外链的资源，如网页资源等。

对于不包含外链的资源，由于获取后可以直接交由客户端进行展示，而无需其他处理，因此对于客户端发起的第一资源请求访问的资源是此类资源时，可以由第一进程根据客户端发起的第一资源请求直接进行回源，即无需执行改写流程，这种情况下直接执行如下所述的步骤(3)。

相应地，对于客户端发起的第一资源请求访问的资源中包含，或可能包含外链，为了保证能够从源站返回的资源中提取出需要改写的外链，并进行改写，就需要对第一资源请求进行修改，这种情况下就需要将第一资源请求转发到第二进程，然后在从第二进程流转回第一进程，此时原本的第一资源请求经过流转通过对四元组的更新，已经变成了第二资源请求，最后再由第一进程将第二资源请求发送至对应的源站，即对于包含外链的情况，对请求的处理方式需要按照下述步骤(3-1)至步骤(3-3)进行。

(2)不含外链的处理方式：由所述第一进程将所述第一资源请求发送至对应的源站。

(3)包含外链的处理方式：

(3-1)由所述第一进程将所述第一资源请求转发至提供改写服务的第二进程。

(3-2)由所述第二进程更新所述第一资源请求的四元组，得到第二资源请求，并将所述第二资源请求转发至所述第一进程。

可理解的，本实施例中所说的四元组具体是指携带的内容为：源网际协议地址(Internet Protocol，IP)、源端口号、目的IP和目的端口号。

对于到达第二进程，但还未更新的第一资源请求的四元组，源IP和源端口号是指向第一进程的，目的IP和目的端口是指向第二进程的；对于更新后得到的第二资源请求的四元组，源IP和源端口是指向第二进程的，而目的IP和目的端口则是指向第一进程的。

(3-3)由所述第一进程将所述第二资源请求发送至所述源站。

(4)第一进程接收到源站返回的资源为基于所述第一资源请求返回的资源的处理方式：由所述第一进程将所述资源发送给所述客户端，即由第一进程根据第一资源请求直接进行回源。

应当理解的，CDN回源遵循的原则是请求发出去的流转过程是怎样的，收到的响应就会按照逆过程流转回客户端。因此，基于这一原则，上述所说的由第一进程根据所述客户端发起的第一资源请求直接进行回源，具体是指由所述第一进程将源站返回的基于第一资源请求返回的资源，直接返回给客户端。

(5)第一进程接收到源站返回的资源为基于所述第二资源请求返回的资源的处理方式：

(5-1)由所述第一进程将所述资源转发至提供改写服务的第二进程。

(5-2)由所述第二进程对所述资源进行改写，并将改写后的资源转发至所述第一进程。

(5-3)由所述第一进程将改写后的所述资源发送至所述客户端。

需要说明的是，关于上述所说的由第二进程对源站基于第二资源请求返回的资源进行的改写，具体是指对该资源进行扫描，然后提取出该资源中包含的外链，并对提取出的外链的域名进行改写。

应当理解的是，上述示例仅是为了更好地理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制，在实际应用中，提供CDN加速服务的第一进程和提供改写服务的第二进程也可以分别运行在不同的CDN节点中，本实施例对此不做限制。

此外，值得一提的是，在一个例子中，第二进程在对外链进行改写时，可以基于预设的加密算法对外链进行加密改写，从而避免改写后的外链在下发给客户的过程中，被恶意第三方拦截后进行篡改，进而给客户端带来安全隐患。

由此，本发明实施例提供的请求处理方法，进行请求处理的CDN节点，通过确定客户端发起的第一资源请求访问的资源中是否包括外链，进而在确定不包括外链时，由第一进程根据第一资源请求进行回源，即由第一进程直接基于第一资源请求从源站获取需要访问的资源，并将获取到的资源直接反馈给客户端从而使得整个回源过程不会再经过改写流程，实现了对客户端发起的第一资源请求访问的资源的加速回源。

而在客户端发起的第一资源请求访问资源中包含外链时，则设置客户端发起的第一资源请求从第一进程流转到独立运行的第二进程，再流转回第一进程进行回源，从而使得包含外链的资源响应给第一进程后，由第一进程直接转发至独立运行的第二进程进行扫描和匹配，以提取出包含的外链，并进行改写，然后在将处理过的资源返回给客户端。

通过这种方式，既实现了改写业务的正常执行，又能加速不包含外链的资源回源。

此外，由于简化了改写流程，从而大大降低了CDN的性能开销，保证了CDN回源服务的质量。

参见图3，图3是本发明实施例提供的请求处理方法的又一流程图。本实施例在图1所示的请求处理方法的基础上，给出了CDN节点针对改写后的外链发起的第三资源请求的具体处理方式。

如图3所示，本实施例涉及的请求处理方法，包括如下步骤：

步骤301，接收客户端发送的第一资源请求，并对所述第一资源请求进行解析，确定所述第一资源请求访问的资源中是否包含外链

步骤302，基于所述第一资源请求生成第二资源请求，并将所述第二资源请求发送至所述源站。

步骤303，将所述第一资源请求发送至对应的源站。

步骤304，接收所述源站返回的资源，如果所述资源为基于所述第一资源请求返回的资源，则将所述资源发送给所述客户端，如果所述资源为基于第二资源请求返回的资源，则对所述资源进行改写，并将改写后的资源发送给所述客户端。

不难发现，本实施例提供的步骤301至步骤304与图1所的实施例中的步骤101至步骤104大致相同，此处不再赘述。

步骤305，如果接收到所述客户端发送的针对改写后的所述外链发起的第三资源请求，将改写后的所述外链的域名进行还原，得到原始外链。

仍以提供CDN加速服务的第一进程和提供改写服务的第二进程运行在同一个CDN节点为例，结合图2，在第一进程将改写后的资源发送给客户端后，如果接收到客户端发送的针对改写后的外链发起的第三资源请求，则第一进程先将改写后的外链的域名进行还原，比如改写的外链为添加了某个标识，则此处的还原则为去除该标识。

步骤306，从所述原始外链对应的源站获取所述第三资源请求访问的资源。

具体的，关于步骤306中所说的从所述原始外链对应的源站获取所述第三资源请求访问的资源，在本实施例中，具体为：

对所述第三资源请求进行解析，确定所述第三资源请求访问的资源中是否包含外链；如果不包含，将所述第三资源请求发送至所述原始外链对应的源站；如果包含，基于所述第三资源请求生成第四资源请求，并将所述第四资源请求发送至所述原始外链对应的源站；接收所述原始外链对应的源站返回的资源，如果所述资源为基于所述第三资源请求返回的资源，则将所述资源发送给所述客户端，如果所述资源为基于第四资源请求返回的资源，则对所述资源进行改写，并将改写后的资源发送给所述客户端。

此外，需要说明的是，本实施例中所说的第一资源请求是指客户端首次发起访问的资源请求，即从客户端第一次到达CDN节点的资源请求。而第二资源请求，为第一进程确定其请求访问的资源包含外链时，将第一资源请求转发至第二进程，然后再流转回第一进程后的资源请求，本质上第二资源请求与客户端发送来的第一资源请求是相同的，它们所访问的源站是相同的，内容也是相同的，只是为了让包含外链的资源在到达CDN节点后，能够从第一进程直接流转到第二进程进行改写服务。

而对于第三资源请求，实质上是基于第二资源请求返回的资源中存在的改写后的外链发起的资源访问请求。第三资源请求与第一资源请求最大的区别在于，在第三资源请求到达第一进程后，第一进程需要先将改写后的外链进行还原，然后再判断第三资源请求要访问的资源是否包括外链，即在将第三资源请求的外链还原后，后续进行的操作实质上与第一资源请求是类似的。

也就是说，第四资源请求，本质上与客户端发送来的第三资源请求是相同的，它们所访问的源站是相同的，内容也是相同的，只是为了让包含外链的资源在到达CDN节点后，能够从第一进程直接流转到第二进程进行改写服务。

也就是说，对于任一到达第一进程的资源请求，第一进程均会对该资源请求对应的URL进行解析，进而确定该资源请求访问的资源是否包含外链，即需要重复执行上述步骤301至步骤306中的操作，直至源站返回的资源中不包含需要改写的外链为止。

此外，值得一提的是，由于本实施例中提供的请求处理方，第一进程和第二进程是独立运行在同一个CDN节点或不同CDN节点中的，因此第一进程和第二进程可以同时工作，互不影响，即在第二进程对源站返回的资源进行改写的过程中，第一进程仍然可以接收源站返回的资源，并确定返回的资源是否需要进行改写，如果不需要改写，则直接将接收到的资源发送给客户端，如果需要，则添加到改写队列中，等待第二进程对当前需要改写的资源改写完成后，再从改写队列中读取需要改写的资源进行改写。

应当理解的是，上面各种方法的步骤划分，只是为了描述清楚，实现时可以合并为一个步骤或者对某些步骤进行拆分，分解为多个步骤，只要包括相同的逻辑关系，都在本专利的保护范围内；对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计，但不改变其算法和流程的核心设计都在该专利的保护范围内。

本发明的实施例还涉及一种CDN节点，如图4所示，包括至少一个处理器401；以及，与所述至少一个处理器401通信连接的存储器402；其中，所述存储器402存储有可被所述至少一个处理器401执行的指令，所述指令被所述至少一个处理器401执行，以使所述至少一个处理器401能够执行上述方法实施例所描述的请求处理方法。

其中，存储器402和处理器401采用总线方式连接，总线可以包括任意数量的互联的总线和桥，总线将一个或多个处理器401和存储器402的各种电路连接在一起。总线还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路连接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口在总线和收发机之间提供接口。收发机可以是一个元件，也可以是多个元件，比如多个接收器和发送器，提供用于在传输介质上与各种其他装置通信的单元。经处理器401处理的数据通过天线在无线介质上进行传输，进一步，天线还接收数据并将数据传输给处理器401。

处理器401负责管理总线和通常的处理，还可以提供各种功能，包括定时，外围接口，电压调节、电源管理以及其他控制功能。而存储器402可以被用于存储处理器401在执行操作时所使用的数据。

此外，值得一提的是，本实施例中所说的CDN节点，在执行上述方法实施例所描述的请求处理方法时，处理器401会通过一单独的进程实现CDN加速服务，即上述所说的第一进程，通过另一单独的进程实现外链改写，即上述所说的第二进程。即处理器401在执行上述方法实施例所描述的请求处理方法时，会根据需要控制第一进程和第二进程相互配合，共同实现上述方法实施例所描述的请求处理方法。

本发明的实施例还涉及一种计算机可读存储介质，存储有计算机程序。计算机程序被处理器执行时实现上述请求处理方法实施例。

即，本领域技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域的普通技术人员可以理解，上述各实施例是实现本发明的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本发明的精神和范围。