〖猫宅〗: TTL为何物? - 耳钉陈(带耳钉的猫)的个人BLOG

要想弄清TTL是什么鸟, 首先要清楚域名解析是怎么回事, 也就是从客户端浏览器键入网址并回车后, 直到打开网页这一个短暂的时间内, DNS上都经过了什么样的操作... 如果是学习过计算机网络基础的人, 这些都是在基础不过的知识, 想也不必我多废话了, 不过我想既然有兴趣来看这篇文章的人, 估计可能都是没有太深入了解过这方面的人. 所以, 一下文字, 我尽量避免使用"迭代查询", "递归查询"等这样的"行话(术语)"... 免得越看越迷糊. 其实个人认为也没必要了解到那么深, 我发现很多计算机书籍, 都喜欢频繁的使用"行话"... 有什么用啊??? 最终的目的不是让看书的人懂么... 不知道那些写书的人到底怎么想的... 一本死气沉沉的书, 还用了那么多术语... 除了天生对计算机网络很敏感的人, 谁能看进去啊~?? 好了, 废话不多说... (这废话就不少了...)

首先需要先了解一下, 域名解析到底是怎么回事. 为什么会有域名这个东西存在呢?

每个有效域名, 都会对应一个IP, 这个IP是固定的互联网IP, 目前通常都是一个WWW服务器的IP地址. 因为一个网站如果想让人记住, 用IP无疑是一个傻办法, 没有人会记住那一大串数值, 所以, 用域名就简单多了. 那么, 怎么知道每个域名对应哪个IP? 这些对应的记录有时储蓄到哪儿的呢? 这就是DNS服务器了, 通常情况下, 一个网页地址访问请求被发送后, 整个流程是这样的:

用户访问地址请求首先被发送至用户IP所在的DNS服务器(假设为DNS.1), DNS.1会在自身数据库中查找此地址对应的IP, 如果找到记录, 则返回记录给用户, 用户就会浏览到域名对应IP的网页. 如果DNS.1自身数据库中没有找到此域名的记录, 那么DNS.1会向其他DNS服务器发送查询请求, 其他DNS服务器(假设为DNS.2)会首先在自身数据库中查询记录, 如果找到记录, 这将记录返回给DNS.1, 如果没有找到记录, 则会记录发送查询请求给其他DNS服务器. 直到最后找到对应的记录, 或者无法找到记录.

文字的叙述可能不太好理解, 那么下面来看一组图片以加强理解...

基本上, 域名解析就是这样一个过程.
现在, 如果你理解了域名解析的整个过程, 那么对于TTL, 就很容易理解了. 按照上图的例子, 那么TTL就是记录储蓄在DNS.1和DNS.2上的时间, 如果你在你的域名服务器上设置的TTL是300秒, 那么这个解析记录就会在DNS.1和DNS.2上储蓄5分钟, 如果你设置的TTL是1800秒, 那么就储蓄30分钟... 以此类推...但有一点需要注意, 并不是TTL设置的时间越长越好. 你可能会认为, 我设置的时间长些, 这样以后就不用在重复的查询了, 域名解析到网页的速度也会快了啊~ 恩, 没错. 可是同时, 当你更改了域名解析的IP后, 其他DNS同步记录的时间也会变慢了啊~ 呵呵... 尤其是在中国, 加入你的DNS在国外, 你又不小心做了一个A记录到一个被封杀的IP, 或者CNAME到了ghs.google.com... 并且TTL设置的是86400秒... 那么, 当你发现你的这个域名被大陆封杀后, 重新修改了域名指向, 就要等24小时后, 其他DNS清空了缓存并更新了新的DNS记录后才能访问你的域名了... 是不是很惨? 呵呵... 当然, 这只是举例, 如果TTL设置的时间过长, 更改DNS解析记录后等待其他DNS同步可是件很痛苦的事... 呵呵... 所以, TTL时间设置的要适当. :) 再说DNS之间的查询相应是很快的, 所以, 不必太在乎那几乎用毫秒来计算的时间延迟了.... :)

恩, 基本上就是这些....
- 终了 -