CN101873358B - 一种基于域名解析的链路负载均衡方法和设备 - Google Patents
一种基于域名解析的链路负载均衡方法和设备 Download PDFInfo
- Publication number
- CN101873358B CN101873358B CN201010197723.7A CN201010197723A CN101873358B CN 101873358 B CN101873358 B CN 101873358B CN 201010197723 A CN201010197723 A CN 201010197723A CN 101873358 B CN101873358 B CN 101873358B
- Authority
- CN
- China
- Prior art keywords
- link
- domain name
- operator
- address
- information
- 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.)
- Active
Links
Abstract
本发明公开了一种基于域名解析的链路负载均衡方法,包括以下步骤:当接收到来自客户端的第一域名请求报文时,网关设备根据所述第一域名请求报文获取HASH信息;所述网关设备根据所述HASH信息从所述至少两条运营商链路中选择目标运营商链路;所述网关设备根据所述目标运营商链路生成第二域名请求报文;所述网关设备根据所述目标运营商链路发送所述第二域名请求报文。本发明中,提高了域名解析请求的成功率,提高了业务的成功率,并改善了用户体验。
Description
技术领域
本发明涉及通信技术领域,特别是涉及一种基于域名解析的链路负载均衡方法和设备。
背景技术
CDN(Content Delivery Network,内容分发网络)的目的是通过在现有的Internet中增加一层新的网络架构,将网站的内容发布到最接近用户的网络边缘,以使用户可以就近取得所需的内容,并解决Internet网络拥挤的状况,提高用户访问的响应速度;并解决用户访问网站时,由于网络带宽小、用户访问量大、网点分布不均等原因所造成的响应速度慢的问题。
具体的,CDN的关键技术包括:(1)内容发布:借助于建立索引、缓存、流分裂、组播(Multicast)等技术,将内容发布或投递到距离用户最近的远程服务点(POP)处。(2)内容路由:是整体性的网络负载均衡技术,通过内容路由器中的重定向DNS(Domain Name Server,域名服务器)机制,在多个远程POP上均衡用户的请求,以使用户请求得到最近内容源的响应。(3)内容交换:根据内容的可用性、服务器的可用性以及用户的背景,在POP的缓存服务器上,利用应用层交换、流分裂、重定向等技术,智能地平衡负载流量。(4)性能管理:通过内部和外部监控系统,获取网络部件的状况信息,测量内容发布的端到端性能(如包丢失、延时、平均带宽、启动时间、帧速率等),并保证网络处于最佳的运行状态。
如图1所示的CDN技术中DNS的原理示意图,在内容路由技术中,用户进行业务访问时,DNS请求交互流程包括:
(1)将域名解析请求发送到Local(本地)DNS服务器;
(2)Local DNS服务器发现本地没有缓存,则将域名解析请求发送给权威服务器(即CDN智能DNS服务器);
(3)CDN智能DNS服务器根据用户所属的ISP(Internet service provider,因特网服务提供商),返回域名对应的IP地址(该地址属于该ISP);
(4)Local DNS添加本地缓存,并将查询结果返回给用户;
(5)后续用户可以根据返回的IP地址进行业务访问。
当北方联通和南方电信出现之后,对于CDN技术来说,则出现了跨运营商访问速度慢的问题。而出现该问题的根本原因是南北网络的互通互联接点拥塞,造成用户丢包、延迟较大,从而导致访问缓慢,甚至对于一些应用来说根本无法访问。
为了解决上述问题,用户会使用一个电信地址和一个联通地址,并希望访问电信地址走电信的链路,访问联通地址走联通的链路;而服务提供商通常也会租用多条运营商链路,并希望电信用户能够通过电信链路访问服务器,网通用户通过网通链路访问服务器。
如图2所示的多链路业务访问示意图,为一个存在多条链路的内网用户访问服务器的报文交互流程,包括:
(1)用户向运营商的本地DNS服务器发送域名解析请求,其中,该域名解析请求将依次通过用户、内网DNS服务器、内网网关、网关、运营商本地DNS服务器。
(2)运营商本地DNS服务器将域名解析请求报文发送给CDN智能DNS服务器(转发后报文的源IP是运营商本地DNS服务器的IP地址),智能DNS服务器根据报文的源IP地址决定解析返回的IP地址。如果源IP地址为电信对应的IP地址,则返回的IP地址为电信对应的IP地址,如果源IP地址为联通对应的IP地址,则返回的IP地址为联通对应的IP地址。
(3)内网用户根据解析到的IP地址进行服务访问。
通过上述描述可以看出,将域名解析请求发送给运营商本地DNS服务器时,将直接决定后续服务的访问流量。
现有技术中,为了将域名解析请求发送给运营商本地DNS服务器,具体有以下方式:(1)在内网网关上启动DNS代理,内网DNS服务器视该内网网关为DNS服务器,由内网网关根据配置的DNS服务器直接将域名解析请求发送给运营商本地DNS服务器。(2)在内网DNS服务器上直接配置两个运营商的本地DNS服务器,内网网关直接执行NAT(Network AddressTranslation,网络地址转换)转换后,将域名解析请求发送给运营商的本地DNS服务器。
但是,在使用上述方式将域名解析请求发送给运营商本地DNS服务器时,至少存在如下缺陷:
(1)所有的域名解析请求将从一个运营商链路进行发送,导致后续业务流量也都通过该运营商链路,无法实现流量的分担。
(2)域名解析请求的目的地址与出口源IP地址不匹配,例如,域名解析请求发送给中国电信,但是域名解析请求从联通的接口进行发送时,将导致域名解析请求的源IP为联通IP地址,进而导致域名解析失败,用户体验下降。
(3)相同域名进行多次域名解析时,可能解析到不相同运营商的IP地址,对于业务访问存在关联性的情况下,导致业务访问失败。
发明内容
本发明提供一种基于域名解析的链路负载均衡方法和设备,以通过域名解析引导用户流量到不同链路上,改善用户的上网体验,提高网络的可用性。
为了达到上述目的,本发明提出了一种基于域名解析的链路负载均衡方法,应用包括至少两条运营商链路的域名解析系统中,所述方法包括以下步骤:
当接收到来自客户端的第一域名请求报文时,网关设备根据所述第一域名请求报文获取HASH信息;
所述网关设备根据所述HASH信息从所述至少两条运营商链路中选择目标运营商链路;
所述网关设备根据所述目标运营商链路生成第二域名请求报文;
所述网关设备根据所述目标运营商链路发送所述第二域名请求报文。
所述网关设备根据所述第一域名请求报文获取HASH信息,具体包括:
所述网关设备根据所述第一域名请求报文获取域名信息,并根据所述域名信息获取HASH信息。
所述网关设备根据所述HASH信息从所述至少两条运营商链路中选择目标运营商链路,具体包括:
所述网关设备根据所述HASH信息中各个字符的信息和运营商链路的权值信息从所述至少两条运营商链路中选择目标运营商链路。
所述网关设备根据所述HASH信息中各个字符的信息和运营商链路的权值信息从所述至少两条运营商链路中选择目标运营商链路,具体包括:
所述网关设备对所述HASH信息中各个字符的ASCII码信息与所述运营商链路的权值信息进行求余;
所述网关设备根据求余结果以及预设的余数与运营商链路的对应关系,从所述至少两条运营商链路中选择目标运营商链路。
所述网关设备根据所述目标运营商链路生成第二域名请求报文,具体包括:
所述网关设备根据所述目标运营商链路选择对应的目的IP地址和源IP地址;所述目的IP地址为所述目标运营商链路对应运营商本地DNS服务器的IP地址,所述源IP地址为所述目标运营商链路对应运营商为所述网关设备分配的IP地址;
所述网关设备将所述第一域名请求报文中的目的IP地址替换为所述目标运营商链路选择对应的目的IP地址,并将所述第一域名请求报文中的源IP地址替换为所述目标运营商链路选择对应的源IP地址。
一种基于域名解析的链路负载均衡设备,应用包括至少两条运营商链路的域名解析系统中,该设备包括:
获取模块,用于当接收到来自客户端的第一域名请求报文时,根据所述第一域名请求报文获取HASH信息;
选择模块,与所述获取模块连接,用于根据所述HASH信息从所述至少两条运营商链路中选择目标运营商链路;
生成模块,与所述选择模块连接,用于根据所述目标运营商链路生成第二域名请求报文;
发送模块,与所述生成模块和选择模块连接,用于根据所述目标运营商链路发送所述第二域名请求报文。
所述获取模块,具体用于根据所述第一域名请求报文获取域名信息,并根据所述域名信息获取HASH信息。
所述选择模块,具体用于根据所述HASH信息中各个字符的信息和运营商链路的权值信息从所述至少两条运营商链路中选择目标运营商链路。
所述选择模块进一步用于,对所述HASH信息中各个字符的ASCII码信息与所述运营商链路的权值信息进行求余;
并根据求余结果以及预设的余数与运营商链路的对应关系,从所述至少两条运营商链路中选择目标运营商链路。
所述生成模块,具体用于根据所述目标运营商链路选择对应的目的IP地址和源IP地址;所述目的IP地址为所述目标运营商链路对应运营商本地DNS服务器的IP地址,所述源IP地址为所述目标运营商链路对应运营商为所述网关设备分配的IP地址;
将所述第一域名请求报文中的目的IP地址替换为所述目标运营商链路选择对应的目的IP地址,并将所述第一域名请求报文中的源IP地址替换为所述目标运营商链路选择对应的源IP地址。
与现有技术相比,本发明具有以下优点:
存在多个运营商链路的情况下,根据HASH信息从至少两条运营商链路中选择目标运营商链路,从而将用户流量引导到不同的运营商链路上,使得运营商链路的使用更加充分。并且提高了域名解析请求的成功率,提高了业务的成功率,并改善了用户体验。
附图说明
图1为现有技术中CDN智能DNS原理示意图;
图2为现有技术中多链路业务访问示意图;
图3为本发明提出的一种基于域名解析的链路负载均衡方法流程图;
图4为DNS报文格式示意图
图5为本发明应用场景下所提出的一种基于域名解析的链路负载均衡方法流程图;
图6为本发明提出的一种基于域名解析的链路负载均衡设备结构图。
具体实施方式
本发明中,在存在多个运营商链路的情况下,当接收到来自客户端的域名请求报文时,根据该域名请求报文中的HASH信息从至少两条运营商链路中选择目标运营商链路,从而能够将用户流量引导到不同的运营商链路上,使得运营商链路的使用更加充分。并且提高了域名解析请求的成功率,提高了业务的成功率,并改善了用户体验。
基于上述思想,本发明提供一种基于域名解析的链路负载均衡方法,应用包括至少两条运营商链路的域名解析系统中,如图3所示,该方法包括以下步骤:
步骤301,当接收到来自客户端的第一域名请求报文时,网关设备根据所述第一域名请求报文获取HASH信息;
步骤302,所述网关设备根据所述HASH信息从所述至少两条运营商链路中选择目标运营商链路;
步骤303,所述网关设备根据所述目标运营商链路生成第二域名请求报文;
步骤304,所述网关设备根据所述目标运营商链路发送所述第二域名请求报文。
为了更加清楚的阐述本发明提供的技术方案,以下结合具体的应用场景对本发明进行详细说明。本应用场景中,可以适用于CDN技术中的域名解析过程,以图2所示的多链路业务访问示意图为例继续说明;当然,本应用场景还可以适用于其他场景,在此不再赘述。本应用场景下,首先对DNS报文进行介绍,如图4所示,为DNS报文格式示意图。其中,在DNS报文中,包括标识、标志、问题数、资源记录数、授权资源记录数、额外资源记录数、查询问题、回答、授权、额外信息等字段。需要注意的是,并不是所有的DNS报文都会有以上各个字段的。
本应用场景下,将详细说明该查询问题字段,对于其他字段不再详加赘述。其中,在查询问题字段中,包括查询名、查询类型和查询类。
查询名部分长度不定,一般为要查询的域名(反向查询时也可能为IP地址)。该查询名部分由一个或者多个标示符序列组成,每个标示符以首字节数的计数值来说明该标示符长度,每个名字以0结束。例如,查询名为aaaa.bbb.cc.edu时,则查询名字段如下:
4 | a | a | a | a | 3 | b | b | b | 2 | c | c | 3 | e | d | u | 0 |
查询类型(2字节)的类型列表如表1所示,通常查询类型为A(由名字获得IP地址)。其中,表1中只是说明了部分查询类型,对于其他部分不再赘述。
表1
类型 | 助记符 | 说明 |
1 | A | IPv4地址 |
2 | NS | 名字服务器 |
28 | AAAA | IPv6地址 |
查询类(2字节)通常为1,是指Internet数据。
本应用场景下,基于上述查询问题字段,通过解析该查询问题字段可以获取请求信息,继而根据该查询问题字段进行域名请求的分发。
基于上述应用场景,如图5所示,该方法包括以下步骤:
步骤501,网关设备根据域名请求获取域名请求中的域名。其中,当接收到来自客户端的域名请求时,该网关设备需要从该域名请求中获取对应的域名,该网关设备可以为图2中所示的内网网关。
需要注意的是,该域名请求为基于DNS报文的域名请求,则网关设备通过该域名请求的查询问题字段,能够获知该域名请求中的域名。
步骤502,网关设备获取域名中需要的HASH信息。
本应用场景下,域名级别:域名通过“.”符号分割为多个级别,通常大型机构会购买顶级域名,如baidu.com等;并在此基础上定义自身的域名信息,如mp3.baidu.com。同时有一些大型机构会购买国内、国际多个域名,例如sina.com和sina.com.cn。
由于服务提供商的多个业务可能存在关联性,因此需要多次业务请求分发到相同的服务器上,即需要存在相关性的域名解析尽量发送到相同服务器上。
因此,在获取域名中需要的HASH信息时,需要对域名进行如下处理:
(1)将域名尾部去掉常用后缀:如com、edu、gov、us、cn、us等。
(2)将步骤(1)处理完的字符串获取上一级域名信息。
例如:对于news.sina.com.cn,(1)执行之后为:new.sina,(2)执行之后为:sina。此时,该sina(该sina为域名提取的结果)为域名news.sina.com.cn对应的需要的HASH信息。
步骤503,网关设备根据HASH信息选择运营商链路。
本发明中,当存在多条运营商链路时,为了充分利用每条运营商链路,需要将域名请求通过不同运营商链路进行发送,实现不同运营商链路的负载分担。而且对于同一个域名的访问需求,需要保证该访问需求通过相同的运营商链路进行发送。
例如,本应用场景下,多条运营商链路分别为:电信运营商链路和联通运营商链路(实际应用中还可以为其他的运营商链路,本应用场景下不再赘述),网关设备需要根据HASH信息选择运营商链路。对于访问域名A(通过HASH信息获知)的域名请求,选择电信运营商链路进行发送,对于访问域名B的域名请求,选择联通运营商链路进行发送,对于访问域名C的域名请求,选择电信运营商链路进行发送,对于访问域名D的域名请求,选择联通运营商链路进行发送,以此类推。
本发明中,为了保证充分利用每条运营商链路,在选择运营商链路时,还可以根据HASH信息以及当前所有可用的运营商链路计算HASH值,并根据计算出的HASH值选择运营商链路。
具体的,网关设备可以根据HASH信息中的各个字符的ASCII码信息(当然,实际应用中,并不局限于ASCII码信息,还可以根据其他信息,例如,a对应数值1,b对应数值2,以此类推,则还可以为各个字符对应的数值之和,本发明中以ASCII码信息为例进行说明)与运营商链路的权值信息进行求余,另外,在网关设备上,根据实际需要预先设置了余数与运营商链路的对应关系,根据该对应关系,以及求余的结果,即能够选择对应的运营商链路。
例如,电信和网通,权值比为1∶1,预先设置余数0与电信运营商链路的对应关系,以及预先设置余数1与联通运营商链路的对应关系。当获取到sina中的四个字符(s、i、n、a)的ASCII码信息,并与运营商链路的权值信息(由于权值比为1∶1,则权值信息为2)求余时,如果求余结果为0时,则选择电信运营商链路,如果求余结果为1时,则选择联通运营商链路。
又例如,电信和网通,权值比为1∶2,预先设置余数0与电信运营商链路的对应关系,以及预先设置余数1和余数2与联通运营商链路的对应关系。当获取到sina中的四个字符(s、i、n、a)的ASCII码信息,并与运营商链路的权值信息(由于权值比为1∶2,则权值信息为3)求余时,如果求余结果为0时,则选择电信运营商链路,如果求余结果为1或2时,则选择联通运营商链路。
当然,在实际应用中,还可以通过其他方式根据HASH信息选择运营商链路,只要保证运营商链路之间能够进行负载分担,且保证每个域名的访问需求通过同样的运营商链路进行发送即可。
步骤504,网关设备根据该运营商链路选择对应的目的IP地址和源IP地址。
其中,由于该域名请求需要发送给运营商本地DNS服务器,当确定了运营商链路之后,即可以确定该域名请求对应的目的地址,该目的地址为该运营商的本地DNS服务器的IP地址。另外,在网关设备上,预先存储了各个运营商为其分配的IP地址,当确定了运营商链路之后,网关设备需要选择该运营商为其分配的IP地址为源地址。
例如,电信运营商为该网关设备分配了IP地址1,联通运营商为该网关设备分配了IP地址2。当上述步骤中确定需要选择电信运营商链路时,则该目的地址为电信运营商的本地DNS服务器的IP地址,该源地址为电信运营商其分配的IP地址1。当上述步骤中确定需要选择联通运营商链路时,则该目的地址为联通运营商的本地DNS服务器的IP地址,该源地址为联通运营商其分配的IP地址2。
步骤505,网关设备将域名请求报文中的目的IP地址替换为运营商本地DNS服务器的IP地址,并将域名请求报文中的源IP地址替换为运营商为其分配的IP地址。
步骤506,网关设备通过选择的运营商链路发送该域名请求报文。其中,该域名请求报文中的目的IP地址为运营商本地DNS服务器的IP地址,该域名请求报文中的源IP地址为运营商为其分配的IP地址。
当运营商接收到该域名请求报文后,由于域名请求报文中的源IP地址为运营商为其分配的IP地址,则该运营商确定需要对该域名请求报文进行相应处理,不会造成域名请求报文的丢失;而且根据该运营商本地DNS服务器的IP地址,能够将该域名请求报文发送到运营商本地DNS服务器上。
例如,当电信运营商接收到域名请求报文后,如果发现域名请求报文中的源IP地址(IP地址1)为电信运营商分配的IP地址,则电信运营商需要对该域名请求报文进行相应处理,如果发现域名请求报文中的源IP地址(IP地址2)为联通运营商分配的IP地址,则可能导致该域名请求报文的丢失。
步骤507,网关设备解析接收到的应答报文。
当运营商本地DNS服务器接收到域名请求报文后,需要对该域名进行解析,并通过应答报文将解析结果返回给网关设备,当网关设备接收到该应答报文后,需要解析该应答报文,获取该应答报文的源IP地址和目的IP地址。
具体的,该源IP地址为上述域名请求报文中的目的IP地址,即运营商本地DNS服务器的IP地址;该目的IP地址为上述域名请求报文中的源IP地址,即运营商为网关设备分配的IP地址。
步骤508,网关设备调整应答报文中的源IP地址和目的IP地址,并将该应答报文发送给客户端。
具体的,网关设备需要将应答报文中的源IP地址替换为接收到的域名请求报文中的目的IP地址(即网关设备的IP地址),并将应答报文中的目的IP地址替换为接收到的域名请求报文中的源IP地址(即客户端的IP地址)。
基于与上述方法同样的发明构思,本发明还提出了一种基于域名解析的链路负载均衡设备,应用包括至少两条运营商链路的域名解析系统中,如图6所示,该设备进一步包括:
获取模块11,用于当接收到来自客户端的第一域名请求报文时,根据所述第一域名请求报文获取HASH信息。
所述获取模块11,具体用于根据所述第一域名请求报文获取域名信息,并根据所述域名信息获取HASH信息。
选择模块12,与所述获取模块11连接,用于根据所述HASH信息从所述至少两条运营商链路中选择目标运营商链路。
所述选择模块12,具体用于根据所述HASH信息中各个字符的信息和运营商链路的权值信息从所述至少两条运营商链路中选择目标运营商链路。
所述选择模块12进一步用于,对所述HASH信息中各个字符的ASCII码信息与所述运营商链路的权值信息进行求余;
并根据求余结果以及预设的余数与运营商链路的对应关系,从所述至少两条运营商链路中选择目标运营商链路。
生成模块13,与所述选择模块12连接,用于根据所述目标运营商链路生成第二域名请求报文。
所述生成模块13,具体用于根据所述目标运营商链路选择对应的目的IP地址和源IP地址;所述目的IP地址为所述目标运营商链路对应运营商本地DNS服务器的IP地址,所述源IP地址为所述目标运营商链路对应运营商为所述网关设备分配的IP地址;
将所述第一域名请求报文中的目的IP地址替换为所述目标运营商链路选择对应的目的IP地址,并将所述第一域名请求报文中的源IP地址替换为所述目标运营商链路选择对应的源IP地址。
发送模块14,与所述生成模块12和选择模块13连接,用于根据所述目标运营商链路发送所述第二域名请求报文。
其中,本发明装置的各个模块可以集成于一体,也可以分离部署。上述模块可以合并为一个模块,也可以进一步拆分成多个子模块。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到本发明可以通过硬件实现,也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解,本发明的技术方案可以以软件产品的形式体现出来,该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM,U盘,移动硬盘等)中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例所述的方法。
本领域技术人员可以理解附图只是一个优选实施例的示意图,附图中的模块或流程并不一定是实施本发明所必须的。
本领域技术人员可以理解实施例中的装置中的模块可以按照实施例描述进行分布于实施例的装置中,也可以进行相应变化位于不同于本实施例的一个或多个装置中。上述实施例的模块可以合并为一个模块,也可以进一步拆分成多个子模块。
上述本发明序号仅仅为了描述,不代表实施例的优劣。
以上公开的仅为本发明的几个具体实施例,但是,本发明并非局限于此,任何本领域的技术人员能思之的变化都应落入本发明的保护范围。
Claims (8)
1.一种基于域名解析的链路负载均衡方法,其特征在于,应用包括至少两条运营商链路的域名解析系统中,所述方法包括以下步骤:
当接收到来自客户端的第一域名请求报文时,网关设备根据所述第一域名请求报文获取域名信息,并根据所述域名信息获取HASH信息,其中,所述域名信息具体为域信息;
所述网关设备根据所述HASH信息从所述至少两条运营商链路中选择目标运营商链路;
所述网关设备根据所述目标运营商链路生成第二域名请求报文;
所述网关设备根据所述目标运营商链路发送所述第二域名请求报文。
2.如权利要求1所述的方法,其特征在于,所述网关设备根据所述HASH信息从所述至少两条运营商链路中选择目标运营商链路,具体包括:
所述网关设备根据所述HASH信息中各个字符的信息和运营商链路的权值信息从所述至少两条运营商链路中选择目标运营商链路。
3.如权利要求2所述的方法,其特征在于,所述网关设备根据所述HASH信息中各个字符的信息和运营商链路的权值信息从所述至少两条运营商链路中选择目标运营商链路,具体包括:
所述网关设备对所述HASH信息中各个字符的ASCII码信息与所述运营商链路的权值信息进行求余;
所述网关设备根据求余结果以及预设的余数与运营商链路的对应关系,从所述至少两条运营商链路中选择目标运营商链路。
4.如权利要求1所述的方法,其特征在于,所述网关设备根据所述目标运营商链路生成第二域名请求报文,具体包括:
所述网关设备根据所述目标运营商链路选择对应的目的IP地址和源IP地址;所述目的IP地址为所述目标运营商链路对应运营商本地DNS服务器的IP地址,所述源IP地址为所述目标运营商链路对应运营商为所述网关设备分配的IP地址;
所述网关设备将所述第一域名请求报文中的目的IP地址替换为所述目标运营商链路选择对应的目的IP地址,并将所述第一域名请求报文中的源IP地址替换为所述目标运营商链路选择对应的源IP地址。
5.一种基于域名解析的链路负载均衡设备,其特征在于,应用包括至少两条运营商链路的域名解析系统中,该设备包括:
获取模块,用于当接收到来自客户端的第一域名请求报文时,根据所述第一域名请求报文获取域名信息,并根据所述域名信息获取HASH信息,其中,所述域名信息具体为域信息;
选择模块,与所述获取模块连接,用于根据所述HASH信息从所述至少两条运营商链路中选择目标运营商链路;
生成模块,与所述选择模块连接,用于根据所述目标运营商链路生成第二域名请求报文;
发送模块,与所述生成模块和选择模块连接,用于根据所述目标运营商链路发送所述第二域名请求报文。
6.如权利要求5所述的设备,其特征在于,
所述选择模块,具体用于根据所述HASH信息中各个字符的信息和运营商链路的权值信息从所述至少两条运营商链路中选择目标运营商链路。
7.如权利要求6所述的设备,其特征在于,
所述选择模块进一步用于,对所述HASH信息中各个字符的ASCII码信息与所述运营商链路的权值信息进行求余;
并根据求余结果以及预设的余数与运营商链路的对应关系,从所述至少两条运营商链路中选择目标运营商链路。
8.如权利要求5所述的设备,其特征在于,
所述生成模块,具体用于根据所述目标运营商链路选择对应的目的IP地址和源IP地址;所述目的IP地址为所述目标运营商链路对应运营商本地DNS服务器的IP地址,所述源IP地址为所述目标运营商链路对应运营商为网关设备分配的IP地址;
将所述第一域名请求报文中的目的IP地址替换为所述目标运营商链路选择对应的目的IP地址,并将所述第一域名请求报文中的源IP地址替换为所述目标运营商链路选择对应的源IP地址。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201010197723.7A CN101873358B (zh) | 2010-06-11 | 2010-06-11 | 一种基于域名解析的链路负载均衡方法和设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201010197723.7A CN101873358B (zh) | 2010-06-11 | 2010-06-11 | 一种基于域名解析的链路负载均衡方法和设备 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101873358A CN101873358A (zh) | 2010-10-27 |
CN101873358B true CN101873358B (zh) | 2014-09-10 |
Family
ID=42998017
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201010197723.7A Active CN101873358B (zh) | 2010-06-11 | 2010-06-11 | 一种基于域名解析的链路负载均衡方法和设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101873358B (zh) |
Families Citing this family (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102685259B (zh) * | 2011-03-09 | 2015-08-19 | 中国移动通信集团公司 | 对dns解析请求进行解析的方法、系统和智能dns |
CN103685583B (zh) * | 2012-09-05 | 2018-02-23 | 阿里巴巴集团控股有限公司 | 一种域名解析的方法和系统 |
CN103841150B (zh) * | 2012-11-26 | 2017-11-17 | 华为技术有限公司 | 基于内容分发网络cdn分发数据的方法及装置 |
WO2015162451A1 (en) * | 2014-04-22 | 2015-10-29 | Pismo Labs Technology Ltd. | Methods and systems for processing a dns request |
CN104767690B (zh) * | 2014-01-08 | 2018-11-27 | 杭州迪普科技股份有限公司 | 一种流量调度装置及方法 |
CN104092751B (zh) * | 2014-07-01 | 2017-11-17 | 新华三技术有限公司 | 一种业务访问方法和设备 |
CN105577843A (zh) * | 2014-11-07 | 2016-05-11 | 华耀(中国)科技有限公司 | 基于多重策略dns代理实现链路负载均衡的系统及方法 |
CN104469392B (zh) * | 2014-12-19 | 2018-04-20 | 北京奇艺世纪科技有限公司 | 一种视频文件存储方法及装置 |
CN104821965B (zh) * | 2015-04-14 | 2018-10-23 | 鹤壁西默通信技术有限公司 | 基于出口网络的dns智能解析方法 |
CN105897822B (zh) * | 2015-11-11 | 2019-07-26 | 法法汽车(中国)有限公司 | 一种内容分发网络cdn节点选择方法及其装置 |
CN106572009A (zh) * | 2016-11-11 | 2017-04-19 | 锐捷网络股份有限公司 | 一种多运营商链路环境下报文转发方法和装置 |
CN108259372A (zh) * | 2016-12-28 | 2018-07-06 | 天津岩石科技有限公司 | 一种多链路负载均衡系统和方法 |
CN107508760B (zh) * | 2017-09-20 | 2020-01-03 | 杭州安恒信息技术股份有限公司 | 一种基于线路源ip进行负载分发的方法 |
CN108462760B (zh) * | 2018-03-21 | 2020-01-10 | 平安科技(深圳)有限公司 | 电子装置、集群访问域名自动生成方法及存储介质 |
CN109286572A (zh) * | 2018-09-30 | 2019-01-29 | 郑州冰川网络技术有限公司 | 动态域名解析方法 |
CN109561172B (zh) * | 2019-01-29 | 2022-02-25 | 迈普通信技术股份有限公司 | 一种dns透明代理方法、装置、设备及存储介质 |
CN110048956A (zh) * | 2019-05-29 | 2019-07-23 | 中国海洋石油集团有限公司 | 互联网链路负载控制系统 |
CN110933156A (zh) * | 2019-11-26 | 2020-03-27 | 杭州迪普科技股份有限公司 | 一种域名解析的方法及装置 |
CN111787421A (zh) * | 2020-04-07 | 2020-10-16 | 重庆云君教育科技有限公司 | 一种用于在线视频节约带宽的硬件设备 |
CN111953806B (zh) * | 2020-07-13 | 2023-05-12 | 深信服科技股份有限公司 | 一种链路选择方法、装置、计算机设备及计算机存储介质 |
CN111970179B (zh) * | 2020-07-24 | 2022-08-23 | 下一代互联网关键技术和评测北京市工程研究中心有限公司 | 基于IPv6的组网接入方法及系统 |
CN112235201A (zh) * | 2020-08-31 | 2021-01-15 | 贵阳忆联网络有限公司 | 一种实现边缘部署的方法及系统 |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101616079A (zh) * | 2009-07-30 | 2009-12-30 | 杭州华三通信技术有限公司 | Dns请求报文的nat出口链路负载均衡方法及装置 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101505305A (zh) * | 2009-03-12 | 2009-08-12 | 杭州比比西网络科技有限公司 | 一种绑定域名和特定服务的方法及设备 |
-
2010
- 2010-06-11 CN CN201010197723.7A patent/CN101873358B/zh active Active
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101616079A (zh) * | 2009-07-30 | 2009-12-30 | 杭州华三通信技术有限公司 | Dns请求报文的nat出口链路负载均衡方法及装置 |
Also Published As
Publication number | Publication date |
---|---|
CN101873358A (zh) | 2010-10-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101873358B (zh) | 一种基于域名解析的链路负载均衡方法和设备 | |
CN111345012B (zh) | 使用目的地系统的链路级容量的dns解析的系统和方法 | |
US10212124B2 (en) | Facilitating content accessibility via different communication formats | |
CN102077189B (zh) | 使用网络计算组件的请求路由 | |
US9800539B2 (en) | Request routing management based on network components | |
US9160703B2 (en) | Request routing management based on network components | |
US9843554B2 (en) | Methods for dynamic DNS implementation and systems thereof | |
US10069792B2 (en) | Geolocation via internet protocol | |
US10263950B2 (en) | Directing clients based on communication format | |
CN109040243B (zh) | 一种报文处理方法及装置 | |
CN111884902B (zh) | 一种vpn场景网络分流方法及装置 | |
US11323412B2 (en) | DNS rendezvous localization | |
WO2018044520A1 (en) | Anycast manifest retrieval, unicast content retrieval | |
KR101682513B1 (ko) | 다중-코어 플랫폼들을 위한 dns 프록시 서비스 | |
US20230336793A1 (en) | Streaming proxy service | |
Khandaker et al. | On-path vs off-path traffic steering, that is the question |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CP03 | Change of name, title or address | ||
CP03 | Change of name, title or address |
Address after: 310052 Binjiang District Changhe Road, Zhejiang, China, No. 466, No. Patentee after: Xinhua three Technology Co., Ltd. Address before: 310053 Hangzhou hi tech Industrial Development Zone, Zhejiang province science and Technology Industrial Park, No. 310 and No. six road, HUAWEI, Hangzhou production base Patentee before: Huasan Communication Technology Co., Ltd. |