网络地址映射方法、装置和系统

暂无

网络地址映射方法、装置和系统\n技术领域\n[0001] 本申请涉及互联网领域，具体而言，涉及一种网络地址映射方法、装置和系统。\n背景技术\n[0002] 互联网协议地址(Internet Protocol Address)为国际通用的计算机网络地址标识符，分为IPv4与IPv6两个版本。其中，IPv4：由32位二进制数组成，为便于使用，常以XXX.XXX.XXX.XXX形式表现，每组XXX代表小于或等于255的10进制数。例如维基媒体的一个IP地址是208.80.152.2。IPv4地址可分为A，B，C，D，E五大类，其中E类属于特殊保留地址。IP地址是唯一的，目前IP技术可能使用的IP地址最多可有约42亿个，由于早期编码和分配上的问题，使很多区域的编码实际上被空出或不能使用。IPv6：从IPv4到IPv6最显著的变化就是网络地址的长度。具体地，RFC 2373(request for comments，即请求评议)和RFC 2374定义的IPv6地址，有128位长；IPv6地址的表达形式，一股采用32个十六进制数。IPv6中可能的地址有2128≈3.4×1038个，也可以想象为1632个，因为32位地址每位可以取16个不同的值。\n[0003] DNS SRV(即解析，是DNS系统的数据库中支持的一种资源记录的类型)记录：为DNS记录的一种扩展，其解决了A记录映射过粗的问题，加入了对端口的映射，最早在RFC 2782中得到定义，SRV记录的格式为：\n[0004] service._proto.name.TTL class SRV priority weight port target[0005] 例如：_sip._tcp.example.com  86400  IN  SRV  10  60  5060 bigbox.example.com.\n[0006] DNS(Domain Name System)网络地址映射系统是全球通用的应用层协议，旨在为抽象难记的IP地址(特别是IPv6)提供一个适合人类理解记忆的映射关系，其总体结构如图\n1所示。\n[0007] 如图1所示，网络地址映射系统主要分为域名服务器(即域名解析服务器)与客户端两部分。域名解析服务器结构呈树状，父结点(如图1示出的根域名服务器)拥有子结点的全部内容，在当前服务器没有指定的映射的情况下，当前的DNS Server(DNS服务器)接收到DNS查询之后，可以选择向上级的服务器查询(递归查询)或者告诉客户端查询其它服务器(迭代查询)。\n[0008] 如图2所示，客户端向域名服务器A查询域名xxx.org，域名服务器A向客户端反馈信息请尝试域名服务器B；客户端向域名服务器B查询域名xxx.org，域名服务器B向客户端反馈信息请尝试域名服务器C；客户端向域名服务器C查询域名xxx.org，域名服务器C向客户端反馈IP地址：xx.xx.xx.xx。\n[0009] 在域名服务器中存在多种映射种类，主要有A记录、AAAA记录与CNAME记录，其中A记录便是域名与IP地址(以IPv4为例)的映射关系：\n[0010] some.domain.org→[127.0.1.1，220.12.3.104，120.10.11.18，10.10.8.8][0011] 如此，应用客户端就可以把“some.domain.org”当作对方地址来使用了，实现映射。\n[0012] 如上所述，现有技术中的地址映射关系始终是静态的，如映射：\n[0013] some.domain.org→[127.0.1.1，220.12.3.104，120.10.11.18，10.10.8.8][0014] 因为地址映射关系是静态的，那么每次查询的时候返回的值都是一样的，网络地址无法动态解析，例如根据对方的负载状态、网络状态等等。\n[0015] 现有技术中采用的方法DNS仅存储一个映射关系，对映射结果并不做正确性保证，极可能返回无效的地址，而且其返回的数据结构也比较单一，返回数据中仅包括映射关系，无法附带其它信息如地址的权重、存活时间等，其中，DNS SRV使DNS可以存储IP+port(端口)，但仍无法自定义扩展；另外，DNS仅仅是个协议，并无实质性的约束，对客户端的行为很难把控，实质使用中会经常出现变更不生效的情况，原因是系统对解析请求进行了缓存。\n[0016] 针对现有技术中无法动态映射网络地址的问题，目前尚未提出有效的解决方案。\n发明内容\n[0017] 针对相关技术中无法动态映射网络地址的问题，目前尚未提出有效的解决方案，为此，本申请的主要目的在于提供一种网络地址映射方法、装置和系统，以解决上述问题。\n[0018] 为了实现上述目的，根据本申请的一个方面，提供了一种网络地址映射方法，该方法包括：过滤器截取域名解析请求，其中，域名解析请求中携带有请求访问的待解析域名；\n过滤器检测域名存储内存中是否保存有待解析域名，其中，过滤器位于发送域名解析请求的终端上；过滤器在域名存储内存中保存有待解析域名的情况下，从域名存储内存中读取与待解析域名对应的IP地址；在域名存储内存中没有保存待解析域名的情况下，则将域名解析请求转发至域名解析服务器。\n[0019] 进一步地，从域名存储内存中读取与待解析域名对应的IP地址包括：在域名存储内存中查找与待解析域名对应的IP地址；在域名存储内存中查找到与待解析域名对应的IP地址的情况下，读取与待解析域名对应的IP地址。\n[0020] 进一步地，在域名存储内存中查找与待解析域名对应的IP地址之后，网络地址映射方法还包括：在域名存储内存中查找不到与待解析域名对应的IP地址的情况下，从域名配置服务器上读取与待解析域名对应的IP地址。\n[0021] 进一步地，域名配置服务器上保存有预先获取的域名信息，域名信息包括预先获取的域名和预先获取的域名的描述信息IP地址的对应关系，预先获取的域名保存在域名存储内中的第一列表中，描述信息保存在域名存储内中的第二列表中，其中，预先获取的域名的描述信息包括预先获取的域名对应的IP地址、预先获取的域名与IP地址的对应关系。\n[0022] 进一步地，在检测域名存储内存中是否保存有待解析域名之前，网络地址映射方法还包括下述更新处理中的至少之一：域名配置服务器每隔第一预设时间检测域名信息中的IP地址是否均为有效地址，在域名信息中的IP地址不为有效地址的情况下，更新域名信息；每隔第二预设时间使用域名配置服务器中预先获取的域名更新第一列表；每隔第三预设时间使用域名配置服务器中的描述信息更新第二列表。\n[0023] 为了实现上述目的，根据本申请的一个方面，提供了一种网络地址映射装置，该装置包括：请求获取模块，用于截取域名解析请求，其中，域名解析请求中携带有请求访问的待解析域名；第一检测模块，用于检测域名存储内存中是否保存有待解析域名，其中，域名存储内存存储在发送域名解析请求的终端上；域名处理模块，用于在域名存储内存中保存有待解析域名的情况下，从域名存储内存中读取与待解析域名对应的IP地址；在域名存储内存中没有保存待解析域名的情况下，则将域名解析请求转发至域名解析服务器。\n[0024] 进一步地，域名处理模块包括：第一查找模块，用于在域名存储内存中查找与待解析域名对应的IP地址；第一读取子模块，用于在域名存储内存中查找到与待解析域名对应的IP地址的情况下，读取与待解析域名对应的IP地址。\n[0025] 进一步地，网络地址映射装置还包括：第二读取子模块，用于在域名存储内存中查找不到与待解析域名对应的IP地址的情况下，从域名配置服务器上读取与待解析域名对应的IP地址。\n[0026] 进一步地，域名配置服务器上保存有预先获取的域名信息，域名信息包括预先获取的域名和预先获取的域名的描述信息IP地址的对应关系，预先获取的域名保存在域名存储内中的第一列表中，描述信息保存在域名存储内中的第二列表中，其中，预先获取的域名的描述信息包括预先获取的域名对应的IP地址、预先获取的域名与IP地址的对应关系。\n[0027] 进一步地，网络地址映射装置还包括如下更新模块中的至少之一：第一更新模块，用于每隔第一预设时间检测域名信息中的IP地址是否均为有效地址，在域名信息中的IP地址不为有效地址的情况下，更新域名信息；第二更新模块，用于每隔第二预设时间使用域名配置服务器中预先获取的域名更新第一列表；第三更新模块，用于每隔第三预设时间使用域名配置服务器中的描述信息更新第二列表。\n[0028] 为了实现上述目的，根据本申请的一个方面，提供了一种网络地址映射系统，该系统包括：终端，包括过滤器，其中，过滤器用于获取终端上的域名解析请求，并检测域名存储内存中是否保存有待解析域名，若域名存储内存中保存有待解析域名，则从域名存储内存中读取与待解析域名对应的IP地址，其中，域名解析请求中携带有请求访问的待解析域名；\n域名存储内存存储在发送域名解析请求的终端的过滤器上。\n[0029] 进一步地，网络地址映射系统还包括：域名配置服务器，与终端连接，用于在域名存储内存中查找不到与待解析域名对应的IP地址的情况下，为过滤器提供与待解析域名对应的IP地址；还用于每隔预设时间使用域名配置服务器中的域名信息更新域名存储内存。\n[0030] 采用本申请实施例，可以将上述实施例中的各个模块设置在过滤器中，在过滤器的请求获取模块截取域名解析请求之后，通过第一检测模块检测域名存储内存中是否存在待解析域名，在该域名存储内存中存在该待解析域名的情况下，直接读取与该待解析域名对应的IP地址，而在域名存储内存中没有待解析域名的情况下，将该域名解析请求转发至域名解析服务器，可以获取依据目标终端的健康状态获取的IP地址，实现了域名DNS的动态映射。在该实施例中通过过滤器可以直接对部分域名解析请求做出回应(返回IP地址)，只有少部分不存在于域名存储内存中的待解析域名的域名解析请求才会转发到域名解析服务器，使用域名解析服务器对其进行解析，这样不仅可以实现DNS的动态映射还可以节省很多地解析时间，解决了现有技术中的无法动态映射网络地址的问题，实现了动态映射网络地址的效果。\n附图说明\n[0031] 此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：\n[0032] 图1是根据现有技术中网络地址映射系统的架构图；\n[0033] 图2是根据现有技术中网络地址映射系统的工作原理示意图；\n[0034] 图3是根据本申请实施例的网络地址映射装置的结构示意图；\n[0035] 图4是根据现有技术的网络地址映射装置的架构图；\n[0036] 图5是根据本申请实施例的网络地址映射装置的架构图；\n[0037] 图6是根据本申请实施例的域名配置服务器对IP地址进行健康检测的状态变换示意图；\n[0038] 图7是根据本申请实施例的一种可选域名配置系统的示意图；\n[0039] 图8是根据本申请实施例的网络地址映射方法的流程图；以及\n[0040] 图9是根据本申请实施例的一种可选的网络地址映射方法的流程图。\n具体实施方式\n[0041] 为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。\n[0042] 需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。\n[0043] 图3是根据本申请实施例的网络地址映射装置的结构示意图。如图3所示，该装置可以包括：请求获取模块10、第一检测模块20和域名处理模块30。\n[0044] 其中，请求获取模块，用于截取域名解析请求，其中，域名解析请求中携带有请求访问的待解析域名。\n[0045] 第一检测模块，用于检测域名存储内存中是否保存有待解析域名，其中，域名存储内存存储在发送域名解析请求的终端上。\n[0046] 域名处理模块，用于过滤器在域名存储内存中保存有待解析域名的情况下，从域名存储内存中读取与待解析域名对应的IP地址；在域名存储内存中没有保存待解析域名的情况下，则将域名解析请求转发至域名解析服务器。\n[0047] 采用本申请实施例，可以将上述实施例中的各个模块设置在过滤器中，在过滤器的请求获取模块截取域名解析请求之后，通过第一检测模块检测域名存储内存中是否存在待解析域名，在该域名存储内存中存在该待解析域名的情况下，直接读取与该待解析域名对应的IP地址，而在域名存储内存中没有待解析域名的情况下，将该域名解析请求转发至域名解析服务器，可以获取依据目标终端的健康状态获取的IP地址，实现了域名DNS的动态映射。在该实施例中通过过滤器可以直接对部分域名解析请求做出回应(返回IP地址)，只有少部分不存在于域名存储内存中的待解析域名的域名解析请求才会转发到域名解析服务器，使用域名解析服务器对其进行解析，这样不仅可以实现DNS的动态映射还可以节省很多地解析时间，解决了现有技术中的无法动态映射网络地址的问题，实现了动态映射网络地址的效果。\n[0048] 其中，域名存储内存中保存有依据目标终端的健康状态确定的IP地址；域名解析服务器是原始的域名解析服务器。\n[0049] 其中，上述实施例中的过滤器可以为设置于终端上的一个应用程序，该过滤器用于过滤域名解析请求。上述实施例中的终端可以为任意的个人电脑、移动终端(如手机、平板电脑)等的客户机(客户终端)。\n[0050] 下面以个人电脑为例，详细介绍本申请。\n[0051] 如图4所示，在现有技术中，用户通过个人电脑(即上述实施例中的客户终端40’)的应用程序41’(如浏览器)发送访问某个网络地址的域名解析请求，运行该应用程序的客户终端的操作系统43’获取该域名解析请求之后，将该域名解析请求转发至域名解析服务器60’(即DNS服务器)，DNS服务器解析得到与该域名解析请求对应的IP地址之后，将该IP地址返回至客户终端的操作系统，该操作系统将IP地址返回至应用程序，该应用程序使用IP地址访问请求访问的网络地址对应的服务器50’。\n[0052] 如图5所示，采用本申请上述实施例，在应用程序41与操作系统43中间嵌入一个本地伪DNS作为过滤器45，如果是管辖范围内的域名(即存在于域名存储内存中)，则通过DNS协议直接返回计算后的配置中心中的数据(即IP地址)，如果不是，则再递交操作系统。具体地，用户通过个人电脑(即上述实施例中的客户终端40)的应用程序(如浏览器)发送访问某个网络地址的域名解析请求，运行该应用程序的客户终端的过滤器获取到该域名解析请求，然后检测域名存储内存中是否存在待解析域名，如果存在，则直接将过滤器中域名存储内存中的与待解析域名对应的IP地址返回至应用程序，应用程序使用该IP地址访问服务器\n50，这样大大地节省了域名解析的时间，也加快了网络访问的速度。在域名存储内存中不存在待解析域名的情况下，过滤器通过操作系统将域名解析请求发送至域名解析服务器60，通过域名解析服务器获取与域名解析请求对应的IP地址。\n[0053] 其中，图4和图5中的虚线代表返回的IP地址。\n[0054] 需要进一步说明的是，过滤器作为单独的进程运行，与应用程序的本身是无关的。\n对域名解析请求的拦截是通过修改Linux系统中的resolv.conf文件，将个客户终端的域名解析请求设置成首选DNS达到的，Windows系统也可以进行相应设置。\n[0055] 根据本申请的上述实施例，域名处理模块可以包括：第一查找模块，用于在域名存储内存中查找与待解析域名对应的IP地址；第一读取子模块，用于在域名存储内存中查找到与待解析域名对应的IP地址的情况下，读取与待解析域名对应的IP地址。\n[0056] 具体地，网络地址映射装置还可以包括：第二读取子模块，用于在域名存储内存中查找不到与待解析域名对应的IP地址的情况下，从域名配置服务器上读取与待解析域名对应的IP地址。\n[0057] 根据本申请的上述实施例，域名配置服务器上保存有预先获取的域名信息，域名信息包括预先获取的域名和预先获取的域名的描述信息IP地址的对应关系，预先获取的域名保存在域名存储内中的第一列表中，描述信息保存在域名存储内中的第二列表中，其中，预先获取的域名的描述信息包括预先获取的域名对应的IP地址、预先获取的域名与IP地址的对应关系。\n[0058] 在本申请的上述实施例中，域名存储内存可以包括域名列表(即上述实施例中的第一列表)和域名信息表(即上述实施例中的第二列表)，其中，域名列表中可以包括预先获取的域名，域名信息表中保存有对应预先获取的域名的描述信息(如IP地址)。\n[0059] 进一步地，过滤器在获取到域名解析请求之后，在域名列表中查找域名解析请求中的待解析域名，如果在域名列表中查找到该待解析域名，则从域名信息表中查找与该待解析域名对应的IP地址，在查找到与待解析域名对应的IP地址之后，将该IP地址返回给应用程序。\n[0060] 如果在域名信息表中仅仅保存了该待解析域名，而没有与该待解析域名对应的IP地址，则连接域名配置服务器(如配置中心)，从配置中心读取对应的IP地址。\n[0061] 根据本申请的上述实施例，网络地址映射装置还可以包括：第二检测模块，用于若域名存储内存中没有保存待解析域名，则将待解析域名保存入待更新域名表中且检测域名配置服务器上是否存在待解析域名，其中，域名配置服务器上保存有预先获取的域名信息，域名信息包括预先获取的域名和IP地址的对应关系；第二读取模块，用于在域名配置服务器上存在待解析域名的情况下，读取与待解析域名对应的IP地址。其中，在该实施例中待更新域名表可以为上述实施例中的域名列表。\n[0062] 具体地，过滤器在获取到域名解析请求之后，在域名列表中查找域名解析请求中的待解析域名，如果在域名列表中没有查找到该待解析域名，建立与域名配置服务器的链接，在域名配置服务器上查找该待解析域名，如果域名配置服务器上存在该待解析域名，获取与该待解析域名对应的IP地址，将该IP地址返回给过滤器，过滤器将该IP地址返回至应用程序；若域名配置服务器上没有该待解析域名，确定通过过滤器检测不到该待解析域名，也即通过过滤器无法解析该域名解析请求，过滤器通过操作系统转发该域名解析请求至域名解析服务器，使用域名解析服务器解析该域名解析请求。\n[0063] 根据本申请的上述实施例，网络地址映射装置还可以包括如下更新模块中的至少之一：第一更新模块，用于每隔第一预设时间检测域名信息中的IP地址是否均为有效地址，在域名信息中的IP地址不为有效地址的情况下，更新域名信息；第二更新模块，用于每隔第二预设时间使用域名配置服务器中预先获取的域名更新第一列表；第三更新模块，用于每隔第三预设时间使用域名配置服务器中的描述信息更新第二列表。\n[0064] 在上述实施例中，过滤器可以每隔第一预设时间使用域名配置服务器中的域名信息进行更新，域名配置服务器也可以通过对IP地址的健康检测更新其的域名信息。健康检测可以通过检测IP地址是否为有效地址来实现，其中，有效地址为可以连接到服务器的地址，无法连接到服务器的地址不是有效地址。\n[0065] 通过上述实施例，过滤器中的域名存储内存就可以保持最新的配置变更状态，与服务器达成最终一致性，实现动态准确地为应用程序解析网络地址。\n[0066] 具体地，域名配置服务器，用于对各个域名进行配置变更与控制的。通过域名配置服务器可以维护一个中心化的配置，其实现HTTP协议来响应过滤器发来的更新请求。同时，为了保证返回的服务地址(即上述实施例中的IP地址)尽可能是正确的、有效的，配置中心还可以对保存在配置中心的域名里的服务地址(即上述实施例中的IP地址)进行定期的健康检测。例如，在支持4层TCP与7层HTTP健康检测的域名配置服务器中，在对7层HTTP进行健康检测的过程中，域名配置服务器可以发送一个http请求，该http的请求目标是一个检测文件(检测文件中可以包括请求连接服务器的IP列表)，可以打开链接的IP地址认为是有效地址，不能打开连接的IP地址认为不是有效地址；在对4层TCP进行健康检测时，通过判断TCP端口是否能建立连接来确定该IP地址是否为有效地址，如果TCP端口可以建立连接确定IP地址为有效地址，如果TCP端口不可以建立连接确定该IP地址不为有效地址。可选地，可以发送三次握手信号，如果三次握手信号TCP端口均无法建立连接，则确定TCP端口无法建立连接。\n[0067] 需要进一步说明的是，由于网络有时候会抖动，因此如果某次康健检测失败我们并不能立即判定其无效，否则会造成状态频繁反复变换。为了减少状态切换的频率，提高检测效率，可以使用三次握手信号确定是否成功建立连接(或是否成功打开连接)。\n[0068] 下面以4层TCP为例，详细介绍检测的方法。\n[0069] 如图6所示，在连接成功的情况下，健康检测失败一次(如图所示的fail[times＝＝0])，则将该IP地址的状态由可用(如图所示的ok)变更为FK(即fast check，快速检测)，会启动一次快速检测，时间大概为正常的1/6，连续对该IP地址进行两次健康检测，如果两次健康检测都失败，则更改状态为：NA(即not available，不可用的)；相反地，只有当连续3次健康检测都成功了才会将服务地址(即上述实施例中的IP地址)的状态变为：ok(可用)。\n由于一股情况而言，应用程序并不会在意机器的从“不能用”至“可用”的时间间隔，所以这里就不再需要快速检测了。\n[0070] 具体地，图6中示出的fail[times＝＝0]表示第二次健康检测失败，fail[times＞＝2]表示至少连续三次健康检测失败，okay[times＜＝2]表示三次或小于三次健康检测成功(即可用)，okey[times＞2]表示连续三次健康检测成功。\n[0071] 需要进一步说明的是，网络地址映射装置还可以包括：解析模块，用于如果域名配置服务器中没有保存待解析域名，则从域名解析服务器获取与待解析域名对应的IP地址，其中，域名解析服务器为对待解析域名进行域名解析的服务器。\n[0072] 在本申请所提供的几个实施例中，应该理解到，所揭露的终端，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。\n[0073] 所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。\n[0074] 另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。\n[0075] 所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。\n[0076] 本申请还提供了一种网络地址映射系统，该系统可以包括一个或多个终端，每个所述终端均可以包括过滤器。\n[0077] 其中，过滤器用于获取终端上的域名解析请求，并检测域名存储内存中是否保存有待解析域名，若域名存储内存中保存有待解析域名，则从域名存储内存中读取与待解析域名对应的IP地址，其中，域名解析请求中携带有请求访问的待解析域名；域名存储内存存储在发送域名解析请求的终端的过滤器上。\n[0078] 采用本申请实施例，可以将上述实施例中的各个模块设置在过滤器中，在过滤器的请求获取模块截取域名解析请求之后，通过第一检测模块检测域名存储内存中是否存在待解析域名，在该域名存储内存中存在该待解析域名的情况下，直接读取与该待解析域名对应的IP地址，而在域名存储内存中没有待解析域名的情况下，将该域名解析请求转发至域名解析服务器，实现了域名DNS的动态映射。在该实施例中通过过滤器可以直接对部分域名解析请求做出回应(返回IP地址)，只有少部分不存在于域名存储内存中的待解析域名的域名解析请求才会转发到域名解析服务器，使用域名解析服务器对其进行解析，这样不仅可以实现DNS的动态映射还可以节省很多地解析时间，解决了现有技术中的无法动态映射网络地址的问题，实现了动态映射网络地址的效果。\n[0079] 根据本申请的上述实施例，网络地址映射系统还可以包括：域名配置服务器，与终端连接，用于在域名存储内存中查找不到与待解析域名对应的IP地址的情况下，为过滤器提供与待解析域名对应的IP地址；还用于每隔预设时间使用域名配置服务器中的域名信息更新域名存储内存。\n[0080] 可选地，网络地址映射系统还可以包括：域名解析服务器，与用于如果域名存储内存中没有保存待解析域名，则从域名解析服务器获取与待解析域名对应的IP地址。\n[0081] 如图7所示，该系统可以包括一个或多个终端，如客户终端，图7中示出了三个客户终端，每个客户终端上均有发送域名解析请求的应用程序41和过滤域名解析请求的过滤器\n45。\n[0082] 其中，上述实施例中的过滤器可以为设置于终端上的一个应用程序，该过滤器用于过滤域名解析请求。上述实施例中的终端可以为任意的个人电脑、移动终端(如手机、平板电脑)等的客户机(客户终端)。\n[0083] 具体地，在应用程序与操作系统中间嵌入一个本地伪DNS作为过滤器，如果是管辖范围内的域名(即存在于域名存储内存中)，则通过DNS协议直接返回计算后的域名配置服务器70(即配置中心)中的数据(即IP地址)，如果不是，则再递交操作系统。具体地，用户通过个人电脑(即上述实施例中的客户终端)的应用程序(如浏览器)发送访问某个网络地址的域名解析请求，运行该应用程序的客户终端的过滤器获取到该域名解析请求，然后检测域名存储内存中是否存在待解析域名，如果存在，则直接将过滤器中域名存储内存中的与待解析域名对应的IP地址返回至应用程序，应用程序使用该IP地址访问服务器50，这样大大地节省了域名解析的时间，也加快了网络访问的速度。在域名存储内存中不存在待解析域名的情况下，过滤器通过操作系统将域名解析请求发送至域名解析服务器，通过域名解析服务器获取与域名解析请求对应的IP地址。\n[0084] 在该实施例中，过滤器通过HTTP协议定时向配置中心(即上述实施例中的域名配置服务器)获取最新的域名配置(即域名信息)。具体地，由于域名配置可能极多，每次并不是获取最新的配置信息，所以将配置的拉取分为了两部分，简称为T1(即上述实施例中的域名列表)、T2(即上述实施例中的域名信息表)：T1定期地向配置中心拉取所有的域名列表(不包含其它信息)，间隔较长，如30秒；T2定时地向配置中心拉取域名配置详细信息，时间较短，如1秒。为了知道哪些域名需要获取详细的域名配置信息，过滤器需要对每次访问的域名与T1拉取的列表进行对比，如果发现有一样的，即视为管辖的域名，便加入到T2的拉取列表中，同时对此域名进行过滤操作，即返回配置中的配置，而不是移交给操作系统。\n[0085] 具体地，域名配置服务器，用于对各个域名进行配置变更与控制的。通过域名配置服务器可以维护一个中心化的配置，其实现HTTP协议来响应过滤器发来的更新请求。同时，为了保证返回的服务地址(即上述实施例中的IP地址)尽可能是正确的、有效的，配置中心还可以对保存在配置中心的域名里的服务地址(即上述实施例中的IP地址)进行定期的健康检测。例如，在支持4层TCP与7层HTTP健康检测的域名配置服务器中，在对7层HTTP进行健康检测的过程中，域名配置服务器可以发送一个http请求，该http请求中可以携带一个检测文件(检测文件中可以包括请求连接服务器的IP列表)，可以打开链接的IP地址认为是有效地址，不能打开连接的IP地址认为不是有效地址；在对4层TCP进行健康检测时，通过判断TCP端口是否能建立连接来确定该IP地址是否为有效地址，如果TCP端口可以建立连接确定IP地址为有效地址，如果TCP端口不可以建立连接确定该IP地址不为有效地址。可选地，可以发送三次握手信号，如果三次握手信号TCP端口均无法建立连接，则确定TCP端口无法建立连接。\n[0086] 通过上述实施例，过滤器中的域名存储内存就可以保持最新的配置变更状态，与服务器达成最终一致性，实现动态准确地为应用程序解析网络地址。\n[0087] 图8是根据本申请实施例的网络地址映射方法的流程图，如图8所示该方法包括如下步骤：\n[0088] 步骤S802，过滤器截取域名解析请求，其中，域名解析请求中携带有请求访问的待解析域名。\n[0089] 步骤S804，过滤器检测域名存储内存中是否保存有待解析域名，其中，域名存储内存存储在发送域名解析请求的终端上。\n[0090] 其中，在域名存储内存中保存有待解析域名的情况下，执行步骤S806；在所述域名存储内存中没有保存所述待解析域名的情况下，执行步骤S808。\n[0091] 步骤S806，过滤器从域名存储内存中读取与待解析域名对应的IP地址。\n[0092] 步骤S808，过滤器将所述域名解析请求转发至域名解析服务器。\n[0093] 采用本申请实施例，可以将上述实施例中的各个模块设置在过滤器中，在过滤器的请求获取模块截取域名解析请求之后，通过第一检测模块检测域名存储内存中是否存在待解析域名，在该域名存储内存中存在该待解析域名的情况下，直接读取与该待解析域名对应的IP地址，而在域名存储内存中没有待解析域名的情况下，将该域名解析请求转发至域名解析服务器，实现了域名DNS的动态映射。在该实施例中通过过滤器可以直接对部分域名解析请求做出回应(返回IP地址)，只有少部分不存在于域名存储内存中的待解析域名的域名解析请求才会转发到域名解析服务器，使用域名解析服务器对其进行解析，这样不仅可以实现DNS的动态映射还可以节省很多地解析时间，解决了现有技术中的无法动态映射网络地址的问题，实现了动态映射网络地址的效果。\n[0094] 其中，上述实施例中的过滤器可以为设置于终端上的一个应用程序，该过滤器用于过滤域名解析请求。上述实施例中的终端可以为任意的个人电脑、移动终端(如手机、平板电脑)等的客户机(客户终端)。\n[0095] 具体地，从域名存储内存中读取与待解析域名对应的IP地址可以包括：在域名存储内存中查找与待解析域名对应的IP地址；在域名存储内存中查找到与待解析域名对应的IP地址的情况下，读取与待解析域名对应的IP地址。\n[0096] 采用本申请上述实施例，在应用程序与操作系统中间嵌入一个本地伪DNS作为过滤器，如果是管辖范围内的域名(即存在于域名存储内存中)，则通过DNS协议直接返回计算后的配置中心中的数据(即IP地址)，如果不是，则再递交操作系统。具体地，用户通过个人电脑(即上述实施例中的客户终端)的应用程序(如浏览器)发送访问某个网络地址的域名解析请求，运行该应用程序的客户终端的过滤器获取到该域名解析请求，然后检测域名存储内存中是否存在待解析域名，如果存在，则直接将过滤器中域名存储内存中的与待解析域名对应的IP地址返回至应用程序，应用程序使用该IP地址访问服务器，这样大大地节省了域名解析的时间，也加快了网络访问的速度。在域名存储内存中不存在待解析域名的情况下，过滤器通过操作系统将域名解析请求发送至域名解析服务器，通过域名解析服务器获取与域名解析请求对应的IP地址。\n[0097] 需要进一步说明的是，在域名存储内存中查找与待解析域名对应的IP地址之后，网络地址映射方法还可以包括：在域名存储内存中查找不到与待解析域名对应的IP地址的情况下，从域名配置服务器上读取与待解析域名对应的IP地址。\n[0098] 根据本申请的上述实施例，域名配置服务器上保存有预先获取的域名信息，域名信息包括预先获取的域名和预先获取的域名的描述信息IP地址的对应关系，预先获取的域名保存在域名存储内中的第一列表中，描述信息保存在域名存储内中的第二列表中，其中，预先获取的域名的描述信息包括预先获取的域名对应的IP地址、预先获取的域名与IP地址的对应关系。\n[0099] 具体地，域名存储内存可以包括域名列表(即上述实施例中的第一列表)和域名信息表(即上述实施例中的第二列表)，其中，域名列表中可以包括预先获取的域名，域名信息表中保存有对应预先获取的域名的域名信息(如IP地址)。\n[0100] 进一步地，过滤器在获取到域名解析请求之后，在域名列表中查找域名解析请求中的待解析域名，如果在域名列表中查找到该待解析域名，则从域名信息表中查找与该待解析域名对应的IP地址，在查找到与待解析域名对应的IP地址之后，将该IP地址返回给应用程序。\n[0101] 如果在域名信息表中仅仅保存了该待解析域名，而没有与该待解析域名对应的IP地址，则连接域名配置服务器(如配置中心)，从配置中心读取对应的IP地址。\n[0102] 可选地，在检测域名存储内存中是否保存有待解析域名之后，网络地址映射方法还可以包括：若域名存储内存中没有保存待解析域名，则将待解析域名保存在待更新域名表中且检测域名配置服务器上是否存在待解析域名，其中，域名配置服务器上保存有预先获取的域名信息，域名信息包括预先获取的域名和IP地址的对应关系；在域名配置服务器上存在待解析域名的情况下，读取与待解析域名对应的IP地址。\n[0103] 具体地，过滤器在获取到域名解析请求之后，在域名列表中查找域名解析请求中的待解析域名，如果在域名列表中没有查找到该待解析域名，建立与域名配置服务器的链接，在域名配置服务器上查找该待解析域名，如果域名配置服务器上存在该待解析域名，获取与该待解析域名对应的IP地址，将该IP地址返回给过滤器，过滤器将该IP地址返回至应用程序；若域名配置服务器上没有该待解析域名，确定通过过滤器检测不到该待解析域名，也即通过过滤器无法解析该域名解析请求，过滤器通过操作系统转发该域名解析请求至域名解析服务器，使用域名解析服务器解析该域名解析请求。\n[0104] 根据本申请上述实施例，在检测域名存储内存中是否保存有待解析域名之前，网络地址映射方法还可以包括下述更新处理中的至少之一：域名配置服务器每隔第一预设时间检测域名信息中的IP地址是否均为有效地址，在域名信息中的IP地址不为有效地址的情况下，更新域名信息；每隔第二预设时间使用域名配置服务器中预先获取的域名更新第一列表；每隔第三预设时间使用域名配置服务器中的描述信息更新第二列表。\n[0105] 在上述实施例中，过滤器可以每隔第一预设时间使用域名配置服务器中的域名信息进行更新，域名配置服务器也可以通过对IP地址的健康检测更新其的域名信息；每隔第二预设时间(如30秒)更新一次第一列表，每隔第三预设时间(如1秒)更新一次第二列表。健康检测可以通过检测IP地址是否为有效地址来实现，其中，有效地址为可以连接到服务器的地址，无法连接到服务器的地址不是有效地址。\n[0106] 通过上述实施例，过滤器中的域名存储内存就可以保持最新的配置变更状态，与服务器达成最终一致性，实现动态准确地为应用程序解析网络地址。\n[0107] 根据本申请的上述实施例，在检测域名配置服务器上是否存在待解析域名之后，网络地址映射方法还可以包括：如果域名配置服务器中没有保存待解析域名，则从域名解析服务器获取与待解析域名对应的IP地址，其中，域名解析服务器为对待解析域名进行域名解析的服务器。\n[0108] 需要进一步说明的是，过滤器作为单独的进程运行，与应用程序的本身是无关的。\n对域名解析请求的拦截是通过修改Linux系统中的resolv.conf文件，将各客户终端的域名解析请求设置成首选DNS达到的，Windows系统也可以进行相应设置。\n[0109] 下面结合附图9详细介绍本申请。如图9所示，本申请上述实施例可以通过如下步骤实现：\n[0110] 步骤S901：检测待解析域名是否存在于域名列表中。\n[0111] 用户通过应用程序发送域名解析请求，过滤器获取到域名解析请求之后，检测待解析域名是否存在于域名列表中。如果待解析域名存在于域名列表中，则执行步骤S902；如果待解析域名不存在于域名列表中，则执行步骤S903。\n[0112] 步骤S902：在域名信息表中查找该待解析域名。\n[0113] 具体地，将该待解析域名加入域名信息表，在该域名信息表中查找待解析域名的IP地址。\n[0114] 步骤S903：转发该域名解析请求至域名解析服务器。\n[0115] 具体地，通过运行该应用程序的操作系统转发该域名解析请求至域名解析服务器。\n[0116] 步骤S904：在域名信息表中读取与待解析域名对应的IP地址。\n[0117] 步骤S905：应用程序获取IP地址。\n[0118] 应用程序获取该IP地址之后，可以如图8所示的对服务器开启访问服务。\n[0119] 步骤S906：定时从域名配置服务器中更新域名列表。\n[0120] 步骤S907：定时从域名配置服务器中更新域名信息表。\n[0121] 具体地，在该实施例中，过滤器通过HTTP协议定时向配置中心(即上述实施例中的域名配置服务器)获取最新的域名配置(即域名信息)。具体地，由于域名配置可能极多，每次并不是获取最新的配置信息，所以将配置的拉取分为了两部分，简称为T1(即上述实施例中的域名列表)、T2(即上述实施例中的域名信息表)：T1定期地向配置中心拉取所有的域名列表(不包含其它信息)，间隔较长，如30秒；T2定时地向配置中心拉取域名配置详细信息，时间较短，如1秒。为了知道哪些域名需要获取详细的域名配置信息，过滤器需要对每次访问的域名与T1拉取的列表进行对比，如果发现有一样的，即视为管辖的域名，便加入到T2的拉取列表中，同时对此域名进行过滤操作，即返回配置中的配置，而不是移交给操作系统。\n[0122] 通过上述实施例，可以将DNS查询方式接入本地系统，而无需上层应用代码变更；\n能根据映射配置关系(如网络RT，系统繁忙度)等等动态返回地址；可以配置成每次请求返回不同的映射，实现短连接请求负载均衡；能够对接入的地址信息进行定期健康检测，及时剔除不健康的地址。\n[0123] 在本申请的上述实施例中，定时更新配置(即上述实施例中的域名)的域名信息表是按访问过的并且在配置列表(即上述实施例中的域名列表)中的配置名(即上述实施例中的域名)进行的，采用该种更新方式可以减轻服务端的压力。\n[0124] 需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。\n[0125] 从以上的描述中，可以看出，本申请实现了如下技术效果：\n[0126] 采用本申请实施例，可以将上述实施例中的各个模块设置在过滤器中，在过滤器的请求获取模块截取域名解析请求之后，通过第一检测模块检测域名存储内存中是否存在待解析域名，在该域名存储内存中存在该待解析域名的情况下，直接读取与该待解析域名对应的IP地址，而在域名存储内存中没有待解析域名的情况下，将该域名解析请求转发至域名解析服务器，实现了域名DNS的动态映射。在该实施例中通过过滤器可以直接对部分域名解析请求做出回应(返回IP地址)，只有少部分不存在于域名存储内存中的待解析域名的域名解析请求才会转发到域名解析服务器，使用域名解析服务器对其进行解析，这样不仅可以实现DNS的动态映射还可以节省很多地解析时间，解决了现有技术中的无法动态映射网络地址的问题，实现了动态映射网络地址的效果。\n[0127] 上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。\n[0128] 在本申请的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。\n[0129] 显然，本领域的技术人员应该明白，上述的本申请的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请不限制于任何特定的硬件和软件结合。\n[0130] 以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。