WO2015169094A1 - 基于预取机制的dns资源记录缓存和响应方法及系统 - Google Patents

基于预取机制的dns资源记录缓存和响应方法及系统 Download PDF

Info

Publication number
WO2015169094A1
WO2015169094A1 PCT/CN2014/095165 CN2014095165W WO2015169094A1 WO 2015169094 A1 WO2015169094 A1 WO 2015169094A1 CN 2014095165 W CN2014095165 W CN 2014095165W WO 2015169094 A1 WO2015169094 A1 WO 2015169094A1
Authority
WO
WIPO (PCT)
Prior art keywords
prefetch
resource record
dns
prefetching
resource
Prior art date
Application number
PCT/CN2014/095165
Other languages
English (en)
French (fr)
Inventor
邓光青
孔宁
沈烁
Original Assignee
中国科学院计算机网络信息中心
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 中国科学院计算机网络信息中心 filed Critical 中国科学院计算机网络信息中心
Publication of WO2015169094A1 publication Critical patent/WO2015169094A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming

Definitions

  • the invention belongs to the field of domain name resolution technology, and particularly relates to a DNS resource record caching and response method and system using a resource record prefetching mechanism, which can improve the response speed of the recursive server and shorten the query delay of the DNS client DNS resource record.
  • DNS is the most important basic resource of the Internet and is the guarantee for the safe operation of other Internet services.
  • the DNS system is mainly composed of an authoritative server, a recursive server, and a client.
  • the authoritative server stores information of one or more zones and is the source of the DNS resource record.
  • the recursive server is responsible for accepting the request sent by the client (parser), and then obtaining the query result required by the user by issuing a query request to the authoritative server at each level, and finally returning to the parser of the client.
  • the recursive server can cache various records returned by the authoritative server to reduce the number of queries and improve query efficiency, and is therefore also referred to as a cache server.
  • the client generally queries various resource records through the recursive server.
  • Each resource record cached by the recursive server corresponds to a TTL (Time To Live) value. If the TTL expires, the recursive server will immediately delete the corresponding resource record. Next time, if another client requests the resource record from the recursive server, the recursive server needs to re-download the resource record to the corresponding authoritative server. Since the client has to wait for a period of time to download the resource record, its waiting delay is large, which affects the user experience.
  • TTL Time To Live
  • the present invention provides a DNS resource record caching and response method and system based on a prefetching mechanism, which can shorten the response delay of the recursive server and improve the service experience of the DNS system.
  • a DNS resource record caching and response method based on a prefetch mechanism the steps of which include:
  • the DNS recursive server responds to the query request by using the prefetched resource record, and sends the corresponding resource record to the client.
  • the pre-fetching target of the resource record is divided into two categories: a) a resource record with a heat greater than a certain threshold, the cache hit ratio is not less than a given value; b) a domain is in a TTL period due to a prefetch mechanism The number of additional DNS requests caused is less than a given value.
  • pre-fetch window duration is calculated using the following method:
  • T h -log(1-P hit )/ ⁇
  • T h is the prefetch window duration
  • ⁇ is the average arrival rate of the resource record request
  • P hit is the probability that the resource record is prefetched in T h
  • P hit is also the probability that subsequent requests to the resource record are cached. , called the cache hit ratio
  • N is the number of resource records owned by one domain
  • ⁇ i (1 ⁇ i ⁇ N) is the heat of each resource record
  • N Packets is the additional traffic caused by the prefetch mechanism in the TTL period. That is, the total number of DNS requests sent by the domain due to the prefetch mechanism.
  • the DNS recursive server prefetches the corresponding resource record.
  • the resource record prefetching instruction is sent to the DNS recursive server, otherwise the resource record does not need to be released. Prefetch instructions.
  • a DNS resource record caching and response system using the above method comprising a DNS recursive server, a prefetch function configuration module, a prefetch window duration calculation module, and a prefetch instruction delivery module;
  • the prefetch function configuration module sets a resource record a prefetching target;
  • the prefetching window duration calculating module calculates a prefetching window duration according to the set prefetching target;
  • the prefetching instruction issuing module determines the remaining surviving time of the resource record and the corresponding prefetching window duration Whether to issue a resource record prefetch instruction to the DNS recursive server; after receiving the prefetch instruction, the DNS recursive server prefetches the corresponding resource record.
  • the invention shortens the response delay of the recursive server, improves the response speed of the recursive server, shortens the query delay of the DNS client resource record of the DNS client, and improves the user experience of the client.
  • 1 is a schematic view of the duration of a prefetch window of the present invention.
  • FIG. 2 is a schematic diagram of a DNS recursive recursive server module of the present invention.
  • FIG. 3 is a flow chart of the dynamic adjustment of the recursive server resource record of the present invention.
  • FIG. 4 is a diagram showing the relationship between the prefetch window duration and the extra request packet in the embodiment of the present invention.
  • the recursive server caches the resource record for a period of time.
  • the recursive server deletes the resource record from the cache.
  • the recursive server immediately sends a request to the corresponding authoritative server to retrieve the resource record and send it to the client.
  • the biggest problem with this mechanism is that after the TTL of the resource record expires, the request time of the first client requesting the resource record is too long.
  • the present invention proposes a resource record prefetch mechanism: delineating a short period of time before the TTL expiration of each resource record is the prefetch window time, as shown in FIG. If the recursive server receives a query request for a resource record during this prefetch window, it immediately sends a request to the corresponding authoritative server and prefetches the resource record locally.
  • the principle of prefetching is: only the "hot" resource records need to be prefetched. Otherwise, if the "unpopular" resource record is prefetched, since the resource record will not be requested for a long time, it will instead Waste storage resources. Obviously, the prefetch window time setting determines which type of resource record will be cached.
  • the prefetch window time is set to be short, only a very small number of very "hot” resource records will be prefetched in advance; otherwise, the prefetch window time is set long, there will be many "unpopular" resources. Records are prefetched in advance, resulting in wasted storage resources. Therefore, the determination of the prefetch window time is very important, and the present invention is specifically used to calculate the prefetch window time by setting a prefetch window duration calculation module.
  • FIG. 2 is a schematic diagram showing the structure of a DNS recursive recursive server module of the present invention.
  • the invention reduces the response delay of the DNS recursive server by adding a prefetch function configuration module, a prefetch window duration calculation module, and a prefetch instruction delivery module to the existing DNS recursive server.
  • the workflow of each module is described in detail below.
  • the prefetch window duration calculation module is a core content of the present invention, so the working principle is first introduced.
  • the length of the prefetch window is related to the "hotness" of the resource record (that is, the number of times requested per unit time), the cache hit rate of the resource record, and the like.
  • To establish a mathematical relationship between the three first establish a simple model.
  • the arrival process of a request for a resource record on a recursive server can be described by the Poisson process (http://en.wikipedia.org/wiki/Poisson_process).
  • the application of the Poisson process is very common, and the arrival of bus station customers Process, the process of reaching a download request for a file on the network can be modeled using a Poisson process.
  • ⁇ (can be regarded as the average number of requests for a resource record per unit time); set the prefetch window duration to T h ; set the resource record TTL to T (TTL and pre- The relationship between the window duration is as shown in FIG. 1; the probability that the resource record is prefetched in T h is P hit , and since the P hit is also the probability that the subsequent request for the resource record is cached, it is also called P Hit is the cache hit ratio.
  • P hit the probability that the resource record is prefetched in T h
  • P hit the probability that the subsequent request for the resource record is cached
  • T h -log(1-P hit )/ ⁇ (2)
  • the prefetch window duration is an increasing function of the cache hit ratio, that is, the larger the cache hit ratio, the larger the prefetch window duration; meanwhile, the prefetch window duration is the decreasing function of the resource record heat, that is, the resource. The greater the heat of recording, the smaller the length of the prefetch window.
  • the additional flow rate can be calculated by equation (1).
  • a domain such as cnnic.cn
  • the number of resource records it contains is very large. It may be assumed that one domain has N resource records, and the heat of each resource record is set to ⁇ i (1 ⁇ i ⁇ N).
  • the additional traffic caused by the prefetch mechanism for this domain is as follows:
  • N Packets is the total number of DNS requests sent by the domain due to the prefetch mechanism.
  • the prefetch target is of two types: 1) the cache hit rate of the resource record whose heat is greater than a certain threshold needs to be not less than a given value; 2) a domain (such as cnnic.cn) is caused by the prefetch mechanism in a TTL period. The number of additional DNS requests is less than a given value.
  • the prefetch window duration calculation module When the prefetch window duration calculation module receives the prefetch target issued by the prefetch function configuration module, for the prefetch target 1), the prefetch window duration calculation module can immediately calculate the prefetch window duration according to the formula (2). Because the administrator has given the specific values of the parameters ⁇ and P hit ; for the above prefetch target 2), the prefetch window duration calculation module can calculate the prefetch window duration according to formula (3); meanwhile, the DNS recursive server needs The heat of all resource records in the domain (that is, the average number of requested times per unit time) is counted and sent to the prefetch window duration calculation module, and then the prefetch window duration calculation module can obtain N Packets according to formula (3).
  • the relationship between the T h and then the prefetch window duration calculation module can find the corresponding T h according to the specific value of the N Packets issued by the administrator in the prefetch target 2), so that the prefetch window duration is determined. It is. Then, the prefetch window duration calculation module sends the calculated prefetch window duration to the prefetch instruction delivery module. At this time, the ordinary DNS recursive server sends the remaining survival time of each resource record to the pre-fetching instruction delivery module in real time. The so-called remaining survival time is the TTL value of the resource record minus the time that the resource record is cached on the recursive server. .
  • the working process of the prefetching instruction delivery module is as shown in FIG. 3: the recursive server sends the remaining survival time of the resource record to the prefetching instruction delivery module, and the prefetching instruction issuing module according to the remaining survival time of the resource record and the corresponding pre
  • the window time is taken to determine whether to issue a resource record prefetch instruction to the recursive server. If the remaining survival time of the resource record is less than the prefetch window time, and the release time interval of the two prefetch instructions is greater than the prefetch window time (to prevent the prefetch instruction from being repeated in a prefetch window time, in other words, in one During the prefetching window time, it is only necessary to prefetch one time.
  • the resource record prefetch instruction is sent to the recursive server, otherwise the resource record prefetch instruction does not need to be released.
  • the recursive server After receiving the prefetch instruction issued by the prefetch instruction issuing module, the recursive server prefetches the corresponding resource record.
  • the cache hit rate of the resource record with a heat greater than 1 time per second needs to be no less than 90%.
  • the prefetch window duration can be calculated by formula (2), ie
  • T h -log(1-P hit )/ ⁇
  • the prefetch window duration calculation module sends the calculated prefetch window duration (ie, 2.3026 seconds) to the prefetch instruction delivery module. Then, the prefetch instruction issuing module determines, according to the flowchart shown in FIG. 3, when to issue the prefetch instruction.
  • the number of additional DNS requests caused by the prefetch mechanism in a domain is less than 800.
  • the example.cn domain has 1000 resource records, and the heat of these resource records is subject to a uniform distribution between [0, 1000].
  • the prefetch window duration calculation module receives the prefetch target, the relationship between the prefetch window duration and the extra request packet is calculated by formula (3), as shown in FIG. 4, the horizontal axis is the prefetch window duration, and the vertical axis.
  • the number of packets As can be seen from the figure, if the number of packets is desired to be less than 800, the prefetch window duration can be set to 5 seconds.
  • T h -log(1-P hit )/ ⁇
  • the prefetch window duration calculation module sends the calculated prefetch window duration (ie, 5 seconds) to the prefetch instruction delivery module. Then, the prefetch instruction issuing module determines, according to the flowchart shown in FIG. 3, when to issue the prefetch instruction.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本发明涉及一种基于预取机制的DNS资源记录缓存和响应方法及系统。该方法包括：1)设定资源记录的TTL到期前的一小段时间为预取窗口时间；2)在所述预取窗口时间内，如果DNS递归服务器收到针对某资源记录的查询请求，则向相应的权威服务器发送请求，将该资源记录预取到本地并进行缓存；3)DNS递归服务器利用预取的资源记录对查询请求进行响应，将相应的资源记录发送至客户端。该系统包括DNS递归服务器、预取功能配置模块、预取窗口时长计算模块和预取指令下发模块。本发明能够缩短DNS客户端DNS资源记录查询时延，提升客户端的用户体验。

Description

基于预取机制的DNS资源记录缓存和响应方法及系统 技术领域
本发明属于域名解析技术领域，具体涉及一种采用资源记录预取机制的DNS资源记录缓存和响应方法及系统，能够提高递归服务器响应速度，缩短DNS客户端DNS资源记录的查询时延。
背景技术
DNS是互联网最为重要的基础性资源，是其它互联网业务安全运行的保证。DNS系统主要由权威服务器、递归服务器以及客户端构成，权威服务器存储了一个或多个区的信息，是DNS资源记录的源头。递归服务器负责接受客户端(解析器)发送的请求，然后通过向各级权威服务器发出查询请求获得用户需要的查询结果，最后返回给客户端的解析器。递归服务器可以将权威服务器返回的各种记录进行缓存从而减少查询次数和提高查询效率，因而也被称为缓存服务器。客户端一般通过递归服务器查询各类资源记录。
递归服务器所缓存的每条资源记录都对应一个TTL(Time To Live)值，如果TTL到期，那么递归服务器就会立刻将相应的资源记录删除。下一次，如果其它客户端来向该递归服务器请求该资源记录，则递归服务器需重新向相应的权威服务器下载该资源记录。由于客户端必须等待一段时间才能下载资源记录，因而其等待时延较大，影响了用户体验。
发明内容
针对当前递归服务器存在的响应不及时的问题，本发明提供一种基于预取机制的DNS资源记录缓存和响应方法及系统，能够缩短递归服务器响应时延，提升DNS系统服务体验。
为实现上述目的，本发明采用的技术方案如下：
一种基于预取机制的DNS资源记录缓存和响应方法，其步骤包括：
1)设定资源记录的TTL到期前的一小段时间为预取窗口时间；
2)在所述预取窗口时间内，如果DNS递归服务器收到针对某资源记录的查询请求，则向相应的权威服务器发送请求，将该资源记录预取到本地并进行缓存；
3)DNS递归服务器利用预取的资源记录对查询请求进行响应，将相应的资源记录发送至客户端。
进一步地，资源记录的预取目标分为两类：a)热度大于某一阈值的资源记录，其缓存命中率不小于某给定值；b)某一域在一个TTL周期内因预取机制而导致的额外DNS请求数小于某一给定值。
进一步地，采用下述方法计算预取窗口时长：
对于a)类预取目标，依据下式计算预取窗口时长：
Th＝-log(1-Phit)/λ，
其中，Th为预取窗口时长；λ为资源记录请求的平均到达率；Phit为资源记录在Th内被预取的概率，Phit也是后续对该资源记录的请求被缓存命中的概率，称为缓存命中率；
对于b)类预取目标，依据下式计算预取窗口时长：
Figure PCTCN2014095165-appb-000001
其中，N为一个域拥有的资源记录个数，λi(1≤i≤N)为每个资源记录的热度，NPackets为在一个TTL周期内该域因预取机制而带来的额外流量，即发送该域的由于预取机制而导致的DNS请求的总数。
进一步地，根据资源记录的剩余存活时间以及对应的预取窗口时长，判断是否向DNS递归服务器下发资源记录预取指令；DNS递归服务器接收到预取指令后，立即预取相应的资源记录。
进一步地，如果资源记录的剩余存活时间小于预取窗口时间，且两次预取指令的下达时间间隔大于预取窗口时间，则向DNS递归服务器下发资源记录预取指令，否则无需下达资源记录预取指令。
一种采用上述方法的DNS资源记录缓存和响应系统，包括DNS递归服务器、预取功能配置模块、预取窗口时长计算模块和预取指令下发模块；所述预取功能配置模块设定资源记录的预取目标；所述预取窗口时长计算模块根据设定的预取目标计算预取窗口时长；所述预取指令下发模块根据资源记录的剩余存活时间以及对应的预取窗口时长，判断是否向DNS递归服务器下发资源记录预取指令；所述DNS递归服务器接收到预取指令后，立即预取相应的资源记录。
与现有技术相比，本发明缩短了递归服务器的响应时延，提高了递归服务器响应速度；缩短DNS客户端DNS资源记录查询时延，提升了客户端的用户体验。
附图说明
图1是本发明的预取窗口时长示意图。
图2是本发明的DNS递归递归服务器模块示意图。
图3是本发明的递归服务器资源记录动态调整流程图。
图4是本发明实施例的预取窗口时长与额外请求数据包之间的关系图。
具体实施方式
下面通过具体实施例和附图，对本发明做进一步说明。
首先说明本发明的基本原理。现有技术中，为避免频繁向权威服务器发送域名解析请求，递归服务器会将资源记录缓存一段时间，当资源记录的TTL(Time To Live)到期后，递归服务器就将资源记录从缓存中删除。此后，如果收到了来自于客户端关于该资源记录的DNS请求，递归服务器就会立即向相应的权威服务器发送请求，以获取该资源记录并将其发送给客户端。这种机制的最大问题是，资源记录的TTL到期后，第一个请求该资源记录的客户端的请求时间过长。
为避免这种状况，本发明提出了一种资源记录预取机制：划定每个资源记录TTL到期前的一小段时间为预取窗口时间，如图1所示。如果在这个预取窗口时间内递归服务器收到了针对某资源记录的查询请求，则立即向相应的权威服务器发送请求并将该资源记录预取到本地。预取的原则是：只有比较“热门”的资源记录才需被预取，否则，如果预取了“冷门”资源记录，由于该资源记录在很长一段时间内不会被请求到，反而会浪费存储资源。显然，预取窗口时间的设置决定了哪类资源记录会被缓存下来。如果预取窗口时间被设置得很短，则只有极少一部分非常“热门”的资源记录会被提前预取；反之，预取窗口时间被设置得很长，则会有很多“冷门”的资源记录会被提前预取，从而造成存储资源的浪费。因而，预取窗口时间的确定非常重要，本发明通过设置预取窗口时长计算模块，专门用来计算预取窗口时间。
图2是本发明的DNS递归递归服务器模块构成示意图。本发明通过为现有DNS递归服务器增添预取功能配置模块、预取窗口时长计算模块、预取指令下发模块来减小DNS递归服务器的响应时延。下面具体介绍各个模块的工作流程。
预取窗口时长计算模块是本发明的一个核心内容，故首先介绍其工作原理。实际上，预取窗口时长与资源记录的“热度”(即单位时间内被请求的次数)、资源记录的缓存命中率等有关。为建立起三者之间的数学关系，先建立一个简单的模型。递归服务器上针对某个资源 记录的请求的到达过程可以用泊松过程(http://en.wikipedia.org/wiki/Poisson_process)来描述，泊松过程的应用非常普遍，公交车站顾客的到达过程，网络上对某文件的下载请求的达到过程均可以用泊松过程来建模。设资源记录请求的平均到达率为：λ(可视为单位时间内对某个资源记录的请求的平均数)；设预取窗口时长为Th；设资源记录的TTL为T(TTL与预取窗口时长的关系如图1所示)；设该资源记录在Th内被预取的概率为Phit，由于Phit也是后续对该资源记录的请求被缓存命中的概率，故也称Phit为缓存命中率。则依据泊松过程相关理论(Sheldon M.Ross,stochastic process.John Wiley&Sons,1983.)，有
Figure PCTCN2014095165-appb-000002
这里，
Figure PCTCN2014095165-appb-000003
是Th时间内资源记录的请求到达数。经数学变形，得
Th＝-log(1-Phit)/λ   (2)
由上式可以看出，预取窗口时长是缓存命中率的增函数，即缓存命中率越大，预取窗口时长也越大；同时，预取窗口时长是资源记录热度的减函数，即资源记录的热度越大，预取窗口时长越小。
实施预取机制在提高缓存命中率的同时，也会带来一些额外流量。进一步地，可由式(1)来计算额外流量。对于一个域(例如cnnic.cn)，其所包含的资源记录的数目非常大，不妨设一个域拥有N个资源记录，每个资源记录的热度设为λi(1≤i≤N)，则在一个TTL周期内，该域因预取机制而带来的额外流量如下：
Figure PCTCN2014095165-appb-000004
这里，NPackets是发送该域的由于预取机制而导致的DNS请求的总数。
下面来阐述图2中三个模块的工作流程：
首先，管理员通过预取功能配置模块输入其所期望的预取目标。预取目标为两类：1)热度大于某一阈值的资源记录的缓存命中率需不小于某给定值；2)某一域(比如cnnic.cn)在一个TTL周期内因预取机制而导致的额外DNS请求数小于某一给定值。
预取窗口时长计算模块收到预取功能配置模块所发出的预取目标时，对于上述预取目标1)，预取窗口时长计算模块依据式(2)即可立即计算出预取窗口时长，因为管理员已给出了参数λ和Phit的具体值；对于上述预取目标2)，预取窗口时长计算模块依据式(3)即可计算 出预取窗口时长；同时，DNS递归服务器需将该域所有资源记录的热度(即单位时间内的平均被请求次数)统计出来并发送给预取窗口时长计算模块，然后，预取窗口时长计算模块根据式(3)即可得到NPackets与Th的关系，然后，预取窗口时长计算模块根据上述预取目标2)中管理员所下达的NPackets的具体数值，即可查找到对应的Th，这样，预取窗口时长就被确定了。然后，预取窗口时长计算模块将所计算出的预取窗口时长发送给预取指令下发模块。此时，普通DNS递归服务器将各个资源记录的剩余存活时间实时发送给预取指令下发模块，所谓剩余存活时间，就是资源记录的TTL值减去该资源记录在该递归服务器上已缓存的时间。
预取指令下发模块的工作流程如图3所示：递归服务器将资源记录的剩余存活时间发送给预取指令下发模块，预取指令下发模块根据资源记录的剩余存活时间以及对应的预取窗口时间来判断是否向递归服务器下发资源记录预取指令。如果资源记录的剩余存活时间小于预取窗口时间，且两次预取指令的下达时间间隔大于预取窗口时间(以防止在一个预取窗口时间内重复下达预取指令，换句话说，在一个预取窗口时间内，只需预取一次即可)，则向递归服务器下发资源记录预取指令，否则无需下达资源记录预取指令。递归服务器接收到预取指令下发模块下达的预取指令后，立即预取相应的资源记录。
下面进一步提供具体应用实例：
如果管理员通过预取功能配置模块下发预取目标：热度大于1次每秒的资源记录的缓存命中率需不小于90％。预取窗口时长计算模块接收到预取目标后，通过公式(2)可计算出预取窗口时长，即
Th＝-log(1-Phit)/λ
＝-log(1-90％)/1
＝2.3026秒
然后，预取窗口时长计算模块将计算出的预取窗口时长(即2.3026秒)下发给预取指令下发模块。然后，预取指令下发模块根据图3所示的流程图来确定何时下发预取指令。
如果管理员通过预取功能配置模块下发预取目标：某一域(以example.cn为例)在一个TTL周期内因预取机制而导致的额外DNS请求数小于800。这里，假设该example.cn域有1000个资源记录，这些资源记录的热度服从[0,1000]之间的均匀分布。预取窗口时长计算模块接收到预取目标后，通过公式(3)来计算预取窗口时长与额外请求数据包之间的关系，如图4所示，横轴为预取窗口时长，纵轴为数据包数目。由该图可得，如果希望数据包数目小于800，可将预取窗口时长设置为5秒。
Th＝-log(1-Phit)/λ
＝-log(1-90％)/1
＝2.3026秒
然后，预取窗口时长计算模块将计算出的预取窗口时长(即5秒)下发给预取指令下发模块。然后，预取指令下发模块根据图3所示的流程图来确定何时下发预取指令。
以上实施例仅用以说明本发明的技术方案而非对其进行限制，本领域的普通技术人员可以对本发明的技术方案进行修改或者等同替换，而不脱离本发明的精神和范围，本发明的保护范围应以权利要求所述为准。

Claims (10)

  1. 一种基于预取机制的DNS资源记录缓存和响应方法，其步骤包括：
    1)设定资源记录的TTL到期前的一小段时间为预取窗口时间；
    2)在所述预取窗口时间内，如果DNS递归服务器收到针对某资源记录的查询请求，则向相应的权威服务器发送请求，将该资源记录预取到本地并进行缓存；
    3)DNS递归服务器利用预取的资源记录对查询请求进行响应，将相应的资源记录发送至客户端。
  2. 如权利要求1所述的方法，其特征在于：资源记录的预取目标分为两类：a)热度大于某一阈值的资源记录，其缓存命中率不小于某给定值；b)某一域在一个TTL周期内因预取机制而导致的额外DNS请求数小于某一给定值。
  3. 如权利要求2所述的方法，其特征在于，采用下述方法计算预取窗口时长：
    对于a)类预取目标，依据下式计算预取窗口时长：
    Th＝-log(1-Phit)/λ，
    其中，Th为预取窗口时长；λ为资源记录请求的平均到达率；Phit为资源记录在Th内被预取的概率，Phit也是后续对该资源记录的请求被缓存命中的概率，称为缓存命中率；
    对于b)类预取目标，依据下式计算预取窗口时长：
    Figure PCTCN2014095165-appb-100001
    其中，N为一个域拥有的资源记录个数；λi为每个资源记录的热度，1≤i≤N；NPackets为在一个TTL周期内该域因预取机制而带来的额外流量，即发送该域的由于预取机制而导致的DNS请求的总数。
  4. 如权利要求1所述的方法，其特征在于：根据资源记录的剩余存活时间以及对应的预取窗口时长，判断是否向DNS递归服务器下发资源记录预取指令；DNS递归服务器接收到预取指令后，立即预取相应的资源记录。
  5. 如权利要求4所述的方法，其特征在于：如果资源记录的剩余存活时间小于预取窗口时间，且两次预取指令的下达时间间隔大于预取窗口时间，则向DNS递归服务器下发资源记录预取指令，否则无需下达资源记录预取指令。
  6. 一种采用权利要求1所述方法的DNS资源记录缓存和响应系统，其特征在于，包括DNS 递归服务器、预取功能配置模块、预取窗口时长计算模块和预取指令下发模块；所述预取功能配置模块设定资源记录的预取目标；所述预取窗口时长计算模块根据设定的预取目标计算预取窗口时长；所述预取指令下发模块根据资源记录的剩余存活时间以及对应的预取窗口时长，判断是否向DNS递归服务器下发资源记录预取指令；所述DNS递归服务器接收到预取指令后，立即预取相应的资源记录。
  7. 如权利要求6所述的系统，其特征在于：所述预取功能配置模块设定的预取目标分为两类：a)热度大于某一阈值的资源记录，其缓存命中率不小于某给定值；b)某一域在一个TTL周期内因预取机制而导致的额外DNS请求数小于某一给定值。
  8. 如权利要求7所述的系统，其特征在于，所述预取窗口时长计算模块采用下述方法计算预取窗口时长：
    对于a)类预取目标，依据下式计算预取窗口时长：
    Th＝-log(1-Phit)/λ，
    其中，Th为预取窗口时长；λ为资源记录请求的平均到达率；Phit为资源记录在Th内被预取的概率，Phit也是后续对该资源记录的请求被缓存命中的概率，称为缓存命中率；对于b)类预取目标，依据下式计算预取窗口时长：
    Figure PCTCN2014095165-appb-100002
    其中，N为一个域拥有的资源记录个数，λi(1≤i≤N)为每个资源记录的热度，NPackets为在一个TTL周期内该域因预取机制而带来的额外流量，即发送该域的由于预取机制而导致的DNS请求的总数。
  9. 如权利要求6所述的系统，其特征在于：所述预取指令下发模块根据资源记录的剩余存活时间以及对应的预取窗口时长，判断是否向DNS递归服务器下发资源记录预取指令。
  10. 如权利要求9所述的系统，其特征在于：如果资源记录的剩余存活时间小于预取窗口时间，且两次预取指令的下达时间间隔大于预取窗口时间，则所述预取指令下发模块向DNS递归服务器下发资源记录预取指令，否则无需下达资源记录预取指令。
PCT/CN2014/095165 2014-05-05 2014-12-26 基于预取机制的dns资源记录缓存和响应方法及系统 WO2015169094A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201410186376.6A CN103929509B (zh) 2014-05-05 2014-05-05 基于预取机制的dns资源记录缓存和响应方法及系统
CN201410186376.6 2014-05-05

Publications (1)

Publication Number Publication Date
WO2015169094A1 true WO2015169094A1 (zh) 2015-11-12

Family

ID=51147581

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2014/095165 WO2015169094A1 (zh) 2014-05-05 2014-12-26 基于预取机制的dns资源记录缓存和响应方法及系统

Country Status (2)

Country Link
CN (1) CN103929509B (zh)
WO (1) WO2015169094A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10587648B2 (en) 2017-04-13 2020-03-10 International Business Machines Corporation Recursive domain name service (DNS) prefetching

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103929509B (zh) * 2014-05-05 2017-06-16 中国科学院计算机网络信息中心 基于预取机制的dns资源记录缓存和响应方法及系统
CN106161669A (zh) * 2015-04-28 2016-11-23 阿里巴巴集团控股有限公司 一种快速域名解析方法和系统、及其终端和服务器
CN110830599A (zh) * 2018-08-09 2020-02-21 阿里巴巴集团控股有限公司 域名预热方法、地址发送方法及系统、计算设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8645501B2 (en) * 2011-05-05 2014-02-04 Qualcomm Innovation Center, Inc. Adaptive DNS pre-fetching
CN103701957A (zh) * 2014-01-14 2014-04-02 互联网域名系统北京市工程研究中心有限公司 Dns递归方法及其系统
CN103929509A (zh) * 2014-05-05 2014-07-16 中国科学院计算机网络信息中心 基于预取机制的dns资源记录缓存和响应方法及系统

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6643694B1 (en) * 2000-02-09 2003-11-04 Michael A. Chernin System and method for integrating a proxy server, an e-mail server, and a DHCP server, with a graphic interface

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8645501B2 (en) * 2011-05-05 2014-02-04 Qualcomm Innovation Center, Inc. Adaptive DNS pre-fetching
CN103701957A (zh) * 2014-01-14 2014-04-02 互联网域名系统北京市工程研究中心有限公司 Dns递归方法及其系统
CN103929509A (zh) * 2014-05-05 2014-07-16 中国科学院计算机网络信息中心 基于预取机制的dns资源记录缓存和响应方法及系统

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10587648B2 (en) 2017-04-13 2020-03-10 International Business Machines Corporation Recursive domain name service (DNS) prefetching
US10587649B2 (en) 2017-04-13 2020-03-10 International Business Machines Corporation Recursive domain name service (DNS) prefetching

Also Published As

Publication number Publication date
CN103929509B (zh) 2017-06-16
CN103929509A (zh) 2014-07-16

Similar Documents

Publication Publication Date Title
WO2015169094A1 (zh) 基于预取机制的dns资源记录缓存和响应方法及系统
US9015416B2 (en) Efficient cache validation and content retrieval in a content delivery network
CN104111900B (zh) 一种缓存中数据替换方法及装置
US10567493B2 (en) Intelligent predictive stream caching
US20160063577A1 (en) Handling of real-time advertisement with content prefetching
US20140019577A1 (en) Intelligent edge caching
US8380930B2 (en) Refreshing cached data based on content identifier map
WO2007102969A3 (en) Multi-cache cooperation for response output caching
WO2017097011A1 (zh) 基于集群节点间即时拷贝的会话同步方法
WO2017088225A1 (zh) Dns递归服务器分层缓存方法和系统
CN104079534B (zh) 一种http缓存实现方法和系统
US11330075B2 (en) One-time cache
CA2467933A1 (en) Method and system for network caching
WO2006057852A3 (en) Caching content and state data at a network element
WO2012072049A1 (zh) 协作缓存的方法和装置
US20160080262A1 (en) Domain name collaboration service using domain name dependency server
US10999371B2 (en) Request multiplexing
CN106066877A (zh) 一种异步更新数据的方法及系统
CN106899692A (zh) 一种内容中心网络节点数据缓存替换方法和装置
US9876873B1 (en) Caching techniques
US10705978B2 (en) Asynchronous tracking for high-frequency and high-volume storage
JP2003085032A (ja) 自己組織化キャッシュ方法およびその方法を利用可能なキャッシュサーバ
CN109729314B (zh) 一种视频处理方法、装置、电子设备及存储介质
US20220239723A1 (en) Proactive conditioned prefetching and origin flooding mitigation for content delivery
WO2019019382A1 (zh) 缓存处理方法、装置、计算机设备和存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14891183

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14891183

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 14891183

Country of ref document: EP

Kind code of ref document: A1