具体实施方式
为使本发明的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本发明保护的范围。
本发明实施例提供的业务请求处理方法应用于CDN的业务请求中,即利用CDN为用户终端(client)提供所请求的业务,其中,所述的利用CDN为用户终端提供所请求的业务,是内容提供商(Content Provider,CP)通过CDN 为用户终端提供的一种业务内容加速访问。为便于对本发明实施例技术方案的理解,下面首先对本实施例中,特别是CND中常见的网络设备进行说明:
本地域名服务器(Local Domain Name Server,Local DNS),其是网络中,用于为用户终端提供宽带接入服务的内容提供商的本地DNS,也可以是直接在用户终端上配置使用公共(public)的DNS服务,如谷歌(Google)提供的DNS,以对用户在网络上发起的业务请求,例如网页访问等,进行域名解析服务;
内容提供商CP的授权DNS,是由CP部署的为自己发布的域名提供解析服务的DNS;
业务路由器(Service Router),是CDN中负责完成业务路由的设备,其可以根据用户终端的地理位置以及用户终端所请求的业务,从CDN中选择最合适的服务节点为终端提供内容交付服务,其中所述的服务节点也称为缓存节点(Cache node);
服务节点,是用于缓存内容提供商的业务的缓存节点,在本地会根据内容热度(如用户终端请求业务的频率等)缓存用户终端所请求的内容,在收到用户终端的业务请求时根据本地缓存的内容直接为用户终端提供内容交付,如果本地没有缓存用户终端所要请求的内容,则向CDN中的上级服务节点或者CP的源服务器(Original Server)请求内容后再交付给用户终端;
源服务器是CP部署的内容源服务器,当CP选用CDN提供内容分发业务时,如果CDN中没有本地缓存用户终端所请求的业务,则CDN会向源服务器请求内容。
本实施例中,所述的CDN可以是传统CDN的网络架构,只是用户终端以及业务路由器等网元对业务请求的处理过程是采用本实施例技术方案。下面将以不同实例对本发明技术方案进行说明。
图1为本发明实施例一提供的业务请求处理方法的流程示意图。本实施例应用于CDN的业务请求处理中,当用户终端需要通过CDN网络访问CP 提供的业务,例如网页时,用户终端可按本实施例方法发对业务请求进行处理,以利用CDN的加速服务为用户终端提供所请求的业务,具体地,如图1 所示,本实施例业务请求处理方法可包括如下步骤:
步骤101、用户终端发起针对原始URL的业务请求,该原始URL为用户所要请求的业务的URL;
步骤102、用户终端接收业务路由器返回的重定向消息,该重定向消息包括目的服务节点的地址,该目的服务节点为业务路由器选择的为用户提供业务的服务节点;
步骤103、用户终端根据目的服务节点的地址,向目的服务节点发起针对原始URL的业务请求。
本实施例中,用户终端发起业务请求时,CDN网络中的业务路由器可在返回的重定向消息时,携带为用户终端分配的目的服务节点的IP地址,这样,用户终端可基于该目的服务节点的IP地址,向目的服务节点发送针对原始 URL的业务请求,而不是基于重定向消息中重定向的URL发起业务请求,从而可在向目的服务节点发起的业务请求中携带cookie信息。
本领域技术人员可以理解,由于cookie信息是业务服务器,即业务内容提供商存放在用户终端的资料,以便于业务服务器可基于用户终端上传的 cookie信息来辨识用户终端;且cookie信息与URL是唯一匹配的,因此cookie 信息仅能携带在与其匹配的URL的业务请求中。
本领域技术人员可以理解,用户终端在发起业务请求时,首先会向网络中的DNS,如本地DNS进行域名解析请求,获得CDN中业务路由器的IP 地址,以便向业务路由器发起业务请求,由业务路由器返回重定向消息,其具体实现与传统CDN的实现过程相同或类似。
综上,本实施例提供的业务请求处理方法,在用户发起针对原始URL的业务请求时,可根据业务路由器返回的重定向消息中携带的目的服务节点的地址,向目的服务节点发起针对原始URL的业务请求,使得向目的服务节点发起的业务请求时可携带原始URL对应的cookie信息,可便于内容提供商基于该cookie信息对用户进行鉴权或记录用户的访问记录,提高用户访问业务的用户体验和安全性。
图2为本发明实施例二提供的业务请求处理方法的流程示意。与上述图 1所示实施例不同的是,本实施例中,用户终端接收到CDN中的业务路由器反馈的重定向消息时,可首先对重定向消息进行解析,以确定该重定向消息中是否携带目的服务节点的地址,具体地,如图2所示,本实施业务请求处理方法可包括如下步骤:
步骤201、用户终端发起针对原始URL的业务请求;
步骤202、用户终端接收业务路由器返回的重定向消息;
步骤203、用户终端解析重定向消息,确定重定向消息中是否包括目的服务节点的地址,是则执行步骤204,否则,执行步骤205;
步骤204、用户终端根据目的服务节点的地址,向目的服务节点发起针对原始URL的业务请求,结束;
步骤205、用户终端发起针对重定向消息中的重定向的目的URL的业务请求,结束。
本实施例中,CDN中的业务路由器接收到用户的业务请求,并确定目的服务节点时,返回的重定向消息中携带有指示用户终端进行重定向的目的 URL,该目的URL就是指向目的服务节点的目的URL。
本领域技术人员可以理解,由于目的服务节点的IP地址是携带在重定向消息中,而用户终端有时可能并无法解析并得到该目的服务节点的IP地址,因此在无法解析时,仍旧可以按照传统的业务请求处理方式,基于重定向的 URL发起业务请求,避免业务请求无法实现。
上述图1或图2所示的实施例中,业务服务器返回的重定向消息中还可包括重定向消息的有效时长,在该有效时长内,用户终端需要重新发起针对上述原始URL的业务请求时,可直接利用重定向消息中目的服务节点的地址,向目的服务节点发起针对原始URL的业务请求。这样,用户终端在发起同样URL的业务请求时,就不需要再经过业务路由器,而是基于已有的重定向路由信息快速的访问业务,从而可避免重新向业务路由器发送业务请求,减少业务路由器对业务请求的处理数量和处理时间,可有效提高业务访问效率,特别适用于流媒体业务的访问请求处理中。
本领域技术人员可以理解,流媒体内容的提供商,通常是将内容按时间分片(例如,每2秒一个分片),这样,用户终端在播放该流媒体内容时,就需要频繁的进行业务请求,而采用本实施例技术方案,可极大的减少业务请求的数量,减少业务路由器的负载,同时提高业务访问效率。
上述图1或图2所示的实施例中,业务服务器返回的重定向消息中也可包括URL匹配信息以及匹配信息有效时长,在该匹配信息有效时长内,需要发起针对与该URL匹配信息相匹配的新URL的业务请求时,根据重定向消息中的目的服务节点的地址,向目的服务节点发起针对新URL的业务请求。其中,所述的与URL匹配的URL可以是指一类的业务,例如访问网页中的资讯类时,处于资讯类下的所有业务,例如国际资讯、实时资讯等业务对应的URL均可以是指一类业务,同样可以减少业务路由器对业务请求的处理数量和处理时间,提高业务的访问速率。
图3为本发明实施例三提供的业务请求处理方法的流程示意图。本实施例中,用户终端可接收CDN中的业务路由器返回的多个重定向消息,并可基于重定向消息的优先级发起业务请求,具体地,如图3所示,本实施例业务请求处理方法可包括如下步骤:
步骤301、用户终端发起针对原始URL的业务请求;
步骤302、用户终端接收业务路由器返回的多个重定向消息;
步骤303、用户终端根据各重定向消息中的目的服务节点的地址,并基于重定向消息的优先级的大小,优先向优先级高的重定向消息中的目的服务节点发起针对原始URL的业务请求。
本实施例中,CDN中的业务路由器在接收到用户终端发起的业务请求时,可根据用户终端的地址,采用地理位置优先和/或内容优先原则,为用户终端分配多个目的服务节点,这样可在用户终端基于一个目的服务节点的地址发起业务请求失败时,可转到其他目的服务节点,以提高业务访问成功率,并可提高业务访问效率。
实际应用中,各重定向消息的优先级可以是业务路由器反馈时设定的优先级,或者,也可以是用户终端基于接收重定向消息的先后顺序,按照接收的先后顺序设定优先级。
图4为本发明实施例四提供的业务请求处理方法的流程示意图。本实施例的执行主体是CDN中的业务路由器,可对上述图1-图3中所述的用户终端发起的针对原始URL的业务请求进行处理,以向用户终端返回重定向消息,具体地,如图4所示,本实施例方法可包括如下步骤:
步骤401、业务路由器接收用户终端发起的针对原始URL的业务请求;
步骤402、业务路由器根据原始URL及CDN路由规则,为该用户分配提供业务的目的服务节点;
步骤403、业务路由器向用户终端返回重定向消息,该重定向消息包括目的服务节点的地址,以便用户终端可基于该目的服务节点的地址,向服务节点发起针对原始URL的业务请求。
本实施例中,上述的CDN路由规则具体可以是地理位置优先和/或内容优先规则,其中,所述的地理位置优先就是根据用户终端的地址和CDN中各服务节点的地址,确定为用户终端提供业务的最近的服务节点;所述的内容优先就是基于各服务节点中的业务及业务状态,确定为用户提供业务的最优的服务节点,且二者可以结合起来确定最优的服务节点,其具体实现与传统方式相同或类似,在此不再赘述。
本实施例中,上述步骤403返回的重定向消息中,还可包括重定向消息的有效时长,以便用户终端在该有效时长内,需要重新发起针对上述原始URL 的业务请求时,可基于重定向消息发起业务请求,其具体实现可参见本发明方法相关实施例的说明。
此外,本实施例中,上述的重定向消息中,也可包括URL匹配信息以及匹配信息有效时长,以便用户终端在该匹配信息有效时长内,需要发起针对与该URL匹配信息相匹配的新URL的业务请求时,根据重定向消息中的目的服务节点的地址,向目的服务节点发起针对该新URL的业务请求,其具体实现可参见本发明方法相关实施例的说明。
本实施例中,业务路由器接收到用户终端发起的业务请求时,也可向用户返回包括不同目的服务节点的多个重定向消息,用户终端接收到该重定向消息后,可根据各重定向消息的优先级发起业务请求,其具体实现可参见本发明方法相关实施例的说明。
上述本发明各实施例中,用户终端可基于HTTP或者实时流传输协议(Real TimeStreaming Protocol,RTSP)等传输协议,发的业务请求,对此本发明实施例并不做特别限制。
为便于对本发明实施例技术方案有更好的了解,下面将以用户终端基于HTTP发起业务请求的过程进行说明。
图5为本发明实施例五提供的业务请求处理方法的流程示意图。本实施例业务请求是基于HTTP协议进行,并假设用户终端所要请求的业务的URL 为http://www.cp1.com/ news/a.html。那么在用户终端向该URL发起业务请求时,CDN中的相关网元就会对该业务请求进行处理,具体地,如图5所示,本实施例业务处理方法可包括如下步骤:
步骤501、用户终端向本地DNS发起解析www.cp1.com的域名解析请求。
本领域技术人员可以理解,用户终端在发起针对URL的业务请求时,需要获取和URL中的域名对应的IP地址,因此,用户终端首先需要向本地DNS 发起解析www.cp1.com的域名解析请求。
步骤502、本地DNS接收到用户终端发起的域名解析请求后,检查本地没有缓存和www.cp1.com对应的地址信息时,根据DNS协议向CP的授权DNS发起针对www.cp1.com的域名解析请求。
步骤503、CP的授权DNS接收到本地DNS发起的针对www.cp1.com的域名解析请求后,根据与CDN签约的www.cp1.com,可知需要对用户终端发起的业务请求由CDN提供加速服务,此时,通过返回别名(CNAME)的方式将域名解析请求指向到CDN中,例如返回CNAME可为:www.cp1.com.cdn.net。
步骤504、本地DNS接收到CP的授权DNS返回的CNAME后,将CNAME 作为新的域名,向CDN中的业务路由器发起域名解析请求,即这时域名解析请求的域名是www.cp1.com.cdn.net,该域名由CDN中的业务路由器负责解析。
步骤505、CDN中的业务路由器接收到对域名www.cp1.com.cdn.net的解析请求后,根据签约信息知道是要为www.cp1.com提供加速服务,由于这时候并没有获取到用户终端的IP地址和用户终端要请求的内容,为了准确选择为用户终端提供服务的服务节点,首先返回业务路由器的IP地址。
本领域技术人员可以理解,上述步骤503-步骤505中,CP授权的DNS以及本地DNS上具有CP预先设置或约定好的DNS解析协议,用于对用户终端发起的针对自身的域名解析进行上述处理,即本地DNS接收到上述URL为www.cp1.com的域名解析请求时,会自动向CP部署的CDN中的CP的授权DNS 发起上述URL的域名解析请求,而CP的授权DNS会返回预先设置的CNAME,从而本地DNS可向业务路由器发起基于该CNAME的域名解析;业务路由器接收到该CNAME的域名解析请求时,就可以基于CP在自身上的设置,为用户终端提供自身的IP地址。
步骤506、本地DNS接收到业务路由器返回的业务路由器的IP地址后,将业务路由器的IP地址返回给用户终端。
步骤507、用户终端获取到业务路由器的IP地址后,根据业务路由器的IP 地址向业务路由器发起针对原始URL的业务请求,即发起针对URL为: http://www.cp1.com/news/a.html的业务请求,以便业务路由器可基于该URL确定为用户终端提供业务的服务节点。
步骤508、业务路由器接收到用户终端发起的HTTP业务请求后,即可获取用户终端的地理位置以及业务请求的内容。
具体地,业务路由器可根据和用户终端之间建立的TCP连接可以获取用户终端的IP地址,从而可以根据地理位置数据库或者配置数据定位用户终端所在的地理位置;且根据HTTP业务请求的URL可以知道用户终端所要请求的内容,即http://www.cp1.com/news/a.html。
步骤509、业务路由器获取到用户终端的地理位置信息和所请求的内容后,就可以基于CDN的路由规则,例如地理位置优先或者内容优先原则来选择最合适的服务节点,即目的服务节点。
其中,对于地理位置优先就是选择和用户终端的地理位置最近的服务节点提供服务,而对于内容优先就是选择缓存有用户终端所请求的内容的服务节点提供服务。
步骤510、业务路由器选定最合适的目的服务节点后,基于选择的目的服务节点构造重定向消息,通过返回302重定向消息将用户终端重定向到所选择的目的服务节点上。
其中,在给用户终端返回的重定向消息中通过Location头域携带重定向后的目的URL,因此需要将选定的目的服务节点的信息包含在目的URL中。
具体地,返回的目地URL可以按照如下方式构造:http://cache node IP/original,即针对原始请求http://www.cp1.com/news/a.html返回的目地URL 为:http://cache node IP/www.cp1.com/news/a.html。
同时,在业务路由器返回的302重定向消息中除了携带Location头域之外,还扩展携带X-Location-Address头域,该头域的定义如下:
X-Location-Address="X-Location-Address″″:"host[":"port]",""Max-age" "="delta-seconds
host=hostname|IPv4address
port=*digit;default 80if empty
delta-seconds=1*DIGIT
其中,host用于指示目的服务节点的IP地址;port为端口号,若为空则端口号默认为80;delta-seconds,用于指示该头域指示的IP地址有效时长,单位为秒。
例如,若业务路由器选定由服务节点1(cache node1)作为目的服务节点为用户终端提供业务,且cache node1的IP地址为10.10.10.10,则返回的302重定向消息的Location头域和X-Location-Address头域示例如下:
Location:http://10.10.10.10/www.cp1.com/news/a.html
X-Location-Address:10.10.10.10,Max-age=60
步骤511、用户终端接收到业务路由器返回的重定向消息后,可判断其中是否存在X-Location-Address头域,并对其进行解析,确定是否存在目的服务节点的IP地址,是则执行步骤512,否则,以重定向消息中的目的URL向业务路由器发起业务请求;
其中,解析X-Location-Address头域,获取目的服务节点的IP地址时,由于X-Location-Address头域中携带的可能是IP地址,因此,可从该头域直接获取IP地址。
步骤512、用户终端识别到业务路由器返回的重定向消息中携带了 X-Location-Address头域后,并解析该头域获取到目的服务节点的IP地址后,用户终端就可向从X-Location-Address头域获取到的IP地址用原始的URL请求内容,即使用原始的URL:http://www.cp1.comnews/a.html向目的服务节点发起HTTP业务请求。由于重新发起的业务请求没有修改原始请求的域名信息,因此在原始请求中携带的cookie信息还是可以携带上。
步骤513、目的服务节点接收到用户终端发起的业务请求后可以检查本地是否缓存有用户终端所请求的内容,是则执行步骤516,否则,执行步骤514。
步骤514、目的服务节点从上级的服务节点或者CP的源服务器请求该业务请求的内容,本实施例中假设从CP的源服务器获取该内容。
步骤515、CP的源服务器返回业务请求的内容至目的服务节点。
步骤516、目的服务节点将本地有缓存的内容直接交付给用户终端,或者将从CP获取的内容交付给用户终端,结束。
步骤517、当用户终端需要重新发起针对URL为www.cp1.com/news/a.html的HTTP业务请求时,若重新发起的时间,在X-Location-Address头域中的指示目的服务节点的IP地址的有效时长内,就可直接以该头域中目的服务节点的IP地址,向目的服务节点发起针对www.cp1.com/news/a.html的HTTP业务请求。
由于X-Location-Address头域中的Max-age参数指示了目的服务节点的IP 地址的有效时长,因此用户终端可以缓存该头域信息,如果在 X-Location-Address头域过期之前,用户终端请求同样的URL,则用户终端可以直接向缓存的该目的服务节点的IP地址发起针对该同样URL的HTTP业务请求。
上述步骤511中,在业务路由器从重定向消息中无法得到目的服务节点的地址时,可使用重定向消息的Location头域中的目的URL向业务路由器发起业务请求,即根据http://10.10.10.10/www.cp1.com/news/a.html发起业务请求,其具体实现与传统方式相同或类似,在此不再赘述。但是,利用这种方式发起业务请求时实际上是将原始请求的域名修改成了目的服务节点的IP地址,因此cookie会丢失。
本领域技术人员可以理解,上述的X-Location-Address头域命名方式,也可以是其他命名,或者头域内容的定义也可以为其他定义方式,对此本实施例并不做特别限制。
图6为本发明实施例六提供的业务请求处理方法的流程示意图。与上述图 5所示实施例技术方案不同的是,本实施例中在业务路由器返回的重定向消息中还携带有URL匹配信息以及匹配信息有效时长,具体地,如图6所示,本实施例业务处理方法可包括如下步骤:
步骤601-步骤609。
本实施例中,步骤601-步骤609与上述图5所示实施例步骤501-509相同,在此不在赘述。
步骤610。
本步骤610中,除了具有与上述图5所示的步骤510相同的处理过程,在扩展了X-Location-Address头域外,还扩展有X-Location-Rule头域,包括 URL匹配信息以及匹配信息的有效时长信息。
具体地,本步骤610中,扩展的X-Location-Rule头域的定义如下:
X-Location-Rule=“X-Location-Rule″″:”“Origin-exp=”regularexpression1","“Dst-exp=”regular expression2",″″Max-age""="delta-seconds
其中:Origin-exp=regular expression 1和Dst-exp=regular expression2的取值都为正则表达式,表示与regular expression1匹配的URL的业务请求都按照regularexpression2进行替换,替换的结果就是重定向后的目的URL;
Max-age=delta-seconds=1*DIGIT;单位为秒,用于指示该规则的有效时长;
例如,业务路由器在选定由cache node1提供服务,并且想让 www.cp1.com/news/下的所有内容都由cache node1服务,其IP地址为 10.10.10.10,则返回的302重定向消息的Location头域、X-Location-Address 头域和X-Location-Rule头域示例如下:
Location:http://10.10.10.10/www.cp1.com/news/a.html
X-Location-Address:10.10.10.10,Max-age=60
X-Location-Rule:Origin-exp=^(www.cp1.comnews/)(.*)$,Dst-exp=$1$2,Max-age=60
本领域技术人员可以理解,对X-Location-Rule头域也可以定义其他的命名,对此本发明实施例并不做特别限制。
步骤611-步骤617。
本实施例中,步骤611-步骤617与图5所示的步骤511-步骤517相同或类似,在此不再赘述。
步骤618、用户需要针对新的URL发起的新的HTTP业务请求时,在匹配信息的有效时长,即Max-age时间内,可根据重定向消息中X-Location-Rule 头域携带的Origin-Exp,本实施例中为^(www.cp1.com/news/)(.*)$,对新的 HTTP业务请求中的新URL进行匹配,如果匹配成功,则直接将针对该新的 URL发起的HTTP业务请求直接发送至目的服务节点。
具体地,根据X-Location-Rule头域中Origin-Exp和Dst-Exp的值,只要新URL是以www.cp1.com/news/开始的就可以用新URL向 X-Location-Address头域指示的目的服务节点的IP地址发起HTTP业务请求。而不需要再进行域名解析以及获得业务路由器的重定向消息,这样,可提高业务处理的效率。
本实施例中,X-Location-Rule头域中的参数Max-age,本实施例中值为 6s,表明该规则在60秒内有效,如果在60秒内请求的新URL是也是以 www.cp1.com/news/开始的则同样用新URL向X-Location-Address头域指示的目的服务节点的IP地址重新发起业务请求,因此用户终端需要将 X-Location-Rule头域的信息和X-Location-Address头域的信息在本地缓存下来。
例如,若用户终端在60秒内要访问http://www.cp1.comnews/b.txt,只要和之前缓存下来的X-Location-Rule头域中指定的规则匹配,就可以向同时保存下来的X-Location-Address头域中指示的目的服务节点发起业务请求。
本领域技术人员可以理解,上述的X-Location-Rule头域也可以单独出现,这时可以没有X-Location-Address,因为X-Location-Rule中也可定义包括有目的服务节点的IP地址,或者,X-Location-Rule也可以按照如下方式设置,实现www.cp1.com/news/下的所有 请求都重定向到和其中携带的目的服务节点的IP地址,例如10.10.10.10对应的服务节点。
本领域技术人员可以理解,实际应用中,当针对新的URL发起的新的 HTTP业务请求时,在Max-age时间内,根据重定向消息中X-Location-Rule 头域携带的Origin-Exp对新的HTTP业务请求中的新URL进行匹配,如果匹配成功时,也可将新URL进行变换获得重新发起业务请求时所使用的URL,例如www.cp1.comnews/,即将所有符合匹配规则的新URL均变换成 www.cp1.comnews/发起业务请求。
上述图5或图6所示实施例中,业务路由器返回的重定向消息也可有多个,相应地,X-Location-Address头域和X-Location-Rule头域也可出现多次。
例如,假设返回两个重定向消息,则返回的X-Location-Address可分别为:
X-Location-Address:10.10.10.10,Max-age=60
X-Location-Address:10.10.10.11,Max-age=60
可以看出,两个重定向消息确认的目的服务节点的地址分别为10.10.10.10以及10.10.10.11,即有两个服务节点可为用户终端提供所请求的业务,那么用户终端就可以根据接收到的重定向消息的先后次序作为优先级顺序,首先以10.10.10.10的IP地址的目的服务节点发起针对原始的URL的HTTP 业务请求,当超时后没有收到响应消息后,则可继续向10.10.10.11的IP地址对应的目的服务节点重新发起业务请求。
图7为本发明实施例七提供的用户终端的结构示意图。如图7所示,本实施例用户终端可包括第一业务请求模块11、重定向消息接收模块12和第二业务请求模块13,其中:
第一业务请求模块11,用于发起针对原始URL的业务请求,原始URL 为用户所要请求的业务的URL;
重定向消息接收模块12,用于接收业务路由器返回的重定向消息,该重定向消息包括目的服务节点的地址,目的服务节点为业务路由器选择的为用户提供业务的服务节点;
第二业务请求模块13,用于根据目的服务节点的地址,向目的服务节点发起针对原始URL的业务请求。
本实施例用户终端即为上述利用CDN向CP提供的内容发起业务请求的用户终端,其可以按照上述本发明方法实施例提供的步骤对业务请求进行处理,以利用CDN获得其所要请求的业务,具体实现可参见上述本发明方法实施例的说明,在此不在赘述。
图8为本发明实施例八提供的用户终端的结构示意图。本实施例中,如图8所示,用户终端还可包括重定向消息解析模块14,用于解析重定向消息接收模块12接收的重定向消息,确定重定向消息中是否包括所述目的服务节点的地址;相应地,上述的第二业务请求模块13具体可用于确定重定向消息包括目的服务节点的地址时,向目的服务节点发起针对原始URL的业务请求。
进一步地,如图8所示,本实施例用户终端还可包括第三业务请求模块 15,用于上述重定向消息解析模块14确定重定向消息未包括目的服务节点的地址时,发起针对重定向消息中的重定向的目的URL的业务请求。其具体实现可参见上述本发明方法实施例的说明,在此不在赘述。
图9为本发明实施例九提供的用户终端的结构示意图。在上述图7或图 8所示实施例技术方案基础上,上述的重定向消息解析模块12接收的重定向消息还包括有重定向消息的有效时长,相应地,如图9所示,本实施例用户终端还可包括第四业务请求模块16,用于在该有效时长内,需要重新发起针对原始URL的业务请求时,基于该重定向消息发起业务请求。
本实施例可在向同一URL发起业务请求时,可基于针对该URL返回的重定向消息进行业务请求的发送,以提高业务访问效率,其具体实现可参见上述本发明方法实施例的说明,在此不再赘述。
图10为本发明实施例十提供的用户终端的结构示意图。在上述图7-图9 所示实施例技术方案基础上,上述的重定向消息解析模块12接收的重定向消息还包括有URL匹配信息以及匹配信息有效时长,相应地,如图10所示,本实施例用户终端还可包括第五业务请求模块17,用于在该匹配信息有效时长内,需要发起针对与该URL匹配信息相匹配的新URL的业务请求时,根据该重定向消息中的目的服务节点的地址,向目的服务节点发起针对该新URL的业务请求。
本实施例可在向与重定向消息中的URL匹配信息匹配的URL发起业务请求时,可基于该重定向消息中的目的地址发起业务请求,以提高业务访问效率,其具体实现可参见上述本发明方法实施例的说明,在此不再赘述。
上述图7-图10所示各实施例技术方案中,上述的重定向消息 接收模块 12具体可用于接收业务路由器返回的多个重定向消息;相应地,上述的第二业务请求模块13具体可用于根据各重定向消息中的目的服务节点的地址,并基于重定向消息的优先级的大小,优先向优先级高的重定向消息中的目的服务节点发起针对所述原始URL的业务请求。其具体实现可参见上述本发明方法实施例的说明,在此不再赘述。
图11为本发明实施例十一提供的用户终端的结构示意图。如图11所示,本实施例用户终端可包括处理器111和存储器112,以及接口113,处理器111、存储器112和接口113通过总线或其他方式连接,本实施例中为通过总线连接。其中,存储器112用于存储指令,处理器111用于执行该指令实现相关操作,接口113可将处理器111的处理结果信息发送出去,或者接收相关信息给处理器111。
具体地,本实施例中,处理器111执行存储器112中存储的指令,可用于发起针对原始URL的业务请求,该原始URL为用户所要请求的业务的 URL,该原始URL的业务请求可通过接口113发送出去;该处理器111还用于接收业务路由器返回的重定向消息,该重定向消息包括目的服务节点的地址,该目的服务节点为业务路由器选择的为用户提供业务的服务节点,该重定向消息可通过接口113接收过来;该处理器111还用于根据所述目的服务节点的地址,向目的服务节点发起针对原始URL的业务请求,该业务请求可通过接口113发送出去。存储器112还用于存储重定向消息和原始URL。
本实施例中,处理器111执行存储器112存储的指令除了实现上述操作外,还可实现如下操作:
本实施例的处理器111可用于在根据目的服务节点的地址,向目的服务节点发起针对所述原始URL的业务请求之前,解析所述重定向消息,确定所述重定向消息中是否包括所述目的服务节点的地址,以便确定所述重定向消息包括所述目的服务节点的地址时,向所述目的服务节点发起针对所述原始 URL的业务请求。
本实施例的处理器111还可用于重定向消息未包括目的服务节点的地址时,发起针对重定向消息中的重定向的目的URL的业务请求。
本实施例中,重定向消息还包括重定向消息的有效时长,相应地,处理器111还可用于在有效时长内,需要重新发起针对原始URL的业务请求时,基于重定向消息发起业务请求。
本实施例中,重定向消息还包括URL匹配信息以及匹配信息有效时长;相应地,处理器111还可用于在匹配信息有效时长内,需要发起针对与URL 匹配信息相匹配的新URL的业务请求时,根据重定向消息中的目的服务节点的地址,向目的服务节点发起针对新URL的业务请求。
本实施例中,处理器11还可接收业务路由器返回的多个重定向消息,并可用于根据各重定向消息中的目的服务节点的地址,并基于重定向消息的优先级的大小,优先向优先级高的重定向消息中的目的服务节点发起针对所述原始URL的业务请求。
本实施例用户终端可按照上述本发明方法实施例提供的步骤对业务请求进行处理,以利用CDN获得其所要请求的业务,具体实现可参见上述本发明方法实施例的说明,在此不在赘述。
图12为本发明实施例十二提供的业务路由器的结构示意图。如图12所示,本实施例业务路由器包括业务请求接收模块21、服务节点分配模块22 和重定向消息返回模块23,其中:
业务请求接收模块21,用于接收用户终端发起的针对原始URL的业务请求,该原始URL为用户所要请求的URL;
服务节点分配模块22,用于根据原始URL及CDN路由规则,为用户分配提供业务的目的服务节点;
重定向消息返回模块23,用于向用户终端返回重定向消息,该重定向消息包括目的服务节点的地址,以便用户终端基于目的服务节点的地址,向服务节点发起针对原始URL的业务请求。
本实施例提供的业务路由器即为上述CDN中的对用户终端发起的业务请求进行处理的路由器,可在对用户终端发起的业务请求中携带目的服务节点的IP地址,其具体实现可参见上述本发明方法实施例的说明,在此不再赘述。
本实施例中,上述的CDN路由规则可包括地理位置优先或内容优先规则。上述的服务节点分配模块22具体可通过地理位置优先或内容优先规则来选择为用户终端提供业务的目的服务节点。
本实施例中,重定向消息返回模块23返回的重定向消息中还可包括重定向消息的有效时长,以便用户终端在该有效时长内,需要重新发起针对原始 URL的业务请求时,基于重定向消息发起业务请求。
此外,该重定向消息也可包括URL匹配信息以及匹配信息有效时长,以便用户终端在匹配信息有效时长内,需要发起针对与该URL匹配信息相匹配的新URL的业务请求时,根据重定向消息中的目的服务节点的地址,向目的服务节点发起针对新URL的业务请求。
本实施例中,上述的重定向消息返回模块23,具体用于向用户返回多个包括不同目的服务节点的重定向消息,这样,用户终端可基于该多个重定向消息进行业务请求的发送,其具体实现可参见上述本发明方法实施例的说明,在此不在赘述。
图13为本发明实施例十三提供的业务路由器的结构示意图。本实施例业务路由器可包括处理器211和存储器212,以及接口213,处理器211、存储器212和接口213通过总线或其他方式连接,本实施例中为通过总线连接。其中,存储器212用于存储指令,处理器211用于执行该指令实现相关操作,接口213可将处理器211的处理结果信息发送出去,或者接收相关信息给处理器211。
具体地,本实施例中,处理器211执行存储器212中的指令,可用于接收用户终端发起的针对原始URL的业务请求,该原始URL为用户所要请求的URL,该业务请求通过接口213接收过来;该处理器211还用于根据原始 URL及CDN路由规则,为用户分配提供业务的目的服务节点;该处理器211 还用于向用户终端返回重定向消息,该重定向消息包括目的服务节点的地址,以便用户终端基于目的服务节点的地址,向服务节点发起针对原始URL的业务请求,该重定向消息通过接口213返回用户终端。存储器212也可用于存储CDN路由规则,该CDN路由规则可包括地理位置优先和/或内容优先规则。
本实施例中,重定向消息还可包括重定向消息的有效时长,以便用户终端在所述有效时长内,需要重新发起针对原始URL的业务请求时,基于重定向消息发起业务请求。
本实施例中,重定向消息还包括URL匹配信息以及匹配信息有效时长,以便用户终端在匹配信息有效时长内,需要发起针对与URL匹配信息相匹配的新URL的业务请求时,根据重定向消息中的目的服务节点的地址,向目的服务节点发起针对新URL的业务请求。
本实施例中,处理器211还可用于向用户返回多个包括不同目的服务节点的地址的重定向消息。
本实施例可基于上述本发明实施例提供方法对用户终端发送的业务请求进行处理,具体实现可参见上述本发明方法实施例的说明,在此不再赘述。
图14为本发明实施例十四提供的网络系统的结构示意图。如图14所示,本实施例系统可包括用户终端10和业务路由器20,其中,用户终端10可为采用图7-图11所示的用户终端,业务路由器20可为采用图12或图13所示的业务路由器。
本实施例中,所述的业务路由器20是由CP部署在网络中的CDN,以用于为用户访问CP业务时,通过CDN为用户提供业务,实现业务访问的加速,如图14所示,业务路由器20可管理有多个缓存有CP的内容源服务器提供的业务的服务节点30,当CDN中的业务路由器20接收到用户发起的业务请求后,就可以为用户分配为其提供业务的服务节点。其中,CDN的部署方式与现有CDN的部署方式相同或类似。
图15为本发明实施例十五提供的网络系统的结构示意图。与上述图14 所示实施例技术方案不同的是,如图15所示,本实施例网络系统中,多个服务节点30可分别连接有一负载均衡器40,这样,业务路由器20在接收到用户终端10发起的业务请求后,可将用户终端10的业务请求重定向至选择的负载均衡器40,然后再由负载均衡器40对其管理的服务节点30获取所需的业务,提供给用户终端,其中,图中虚线表示的是CDN中的设备,即业务路由器20、服务节点30和负载均衡器40均是CDN中的网元,且服务节点30 可连接有CP提供源服务器(图中未示出)。
本领域技术人员可以理解,上述的负载均衡器会实时监控后台的各个服务节点的状态,在收到用户终端的业务请求后,负载均衡器会根据当前服务节点的状态和预设的调度算法,例如轮叫调度(Round Robin Scheduling)算法将请求转发到合适的服务节点,在收到服务节点的响应消息后再转发给用户终端。
本领域普通技术人员可以理解:实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成,前述的程序可以存储于一计算机可读取存储介质中,该程序在执行时,执行包括上述方法实施例的步骤;而前述的存储介质包括:ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是:以上各实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述各实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分或者全部技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。