track服务优化之一DNS和域名
track服务优化之一 ： DNS和域名 在互联网广告公司里，有一些服务是用作跟踪用户的，而这些代码嵌入的不多，qps也不高，然后文件大小也比较小，对于这样的应用我们如何进行优化呢。 我们http请求第一步开始说起。 大部分的http请求都是通过dns来进行的，这样dns解析的速度也关系到整个访问的速度。 下图中我们可以很明显的看到，这个请求最大的2个部分就是dns和内容下载。
我们知道DNS的缓存时间都由DNS设置TTL时间来决定的（除了部分local dns做强制缓存），而当一个域名在local dns中没有缓存时，local dns就会以迭代的方式去查询这个域名的解析。比如我们通过trace来模拟一个本地没有缓存的迭代过程。 下面是我们解析www.sohu.com的一个例子。 我们可以看到这里，首先是找到根域名的服务器，然后找到所有.com域名的根服务器，然后找到sohu.com域名的根服务器，然后解析了www.sohu.com， 而由于www.sohu.com做了一次cname，所以要进行解析，最终得到对应的IP地址。 而这个过程中，我们发现实际去dns.sohu.com的时间才52ms，而他去到根域名服务器和.com根域的解析时间加起来要452ms，而这个时间都是算在整个请求的时间内的。
从上可以看到加快DNS解析速度的重要性，而在local dns中缓存是重重之重。而这个第一步就是统一域名，发现国内某些广告商居然用好多域名来进行跟踪。而google却只用了一个单独域名来进行。 下图是我直接访问这家广告公司的跟踪域名，可以看到光dns解析的时间就903ms，这个还是他们使用了dnspod的服务器的情况下。
而他们的很多广告都使用了不同的域名，不过经过查询是应该用了泛域名解析。但是实际dns请求的时候还是会有延迟啊，local dns可不管是不是泛域名呢。 而这家广告商的这些域名指向最终都是同一个IP，那为什么不用单个域名呢？
而我们看google ga，所有的ga使用的域名都是同一个。这样从dns层面减少了响应的时间。
从上面我们得到，使用单一域名在dns层面的好处是比较大的。 加快DNS解析速度的另外一个因素就是TTL时间。这个从解析速度来看自然是越大越好，比如很多根域名服务器都是缓存1周的，但是我们看到大量的还是缓存1个小时的。毕竟时间放太长，一旦网络出了问题都没办法切换。所以有些请求量很大的域名的ttl时间都是120秒左右的，就是怕万一有问题来不及切换。 这个就没有绝对的要求，全看各自的dns服务器的分布和性能了。
多姿多彩的颜色可不光是靠钙化可以完成的，还有别的因素。 
远山的倒影就这样躺在了这个湖面上，而近处是芦苇摇曳着。 
来到山间，由于各种不同的植被导致了到了深秋大家各自的颜色，我想人工做的可没有这样的丰富啊。 
这个好像就是五色湖了，这里人可太多了，今天就拍到这个了，明日再来。 
找了一个高处，刚好一群大妈合影呢。 
那红色的倒影到底是什么呢？ 
当然不是枫叶啦。没那么简单啦。 
我们先来看看瀑布吧，这可是87版西游记的拍摄场地之一，是不是觉得很熟悉啊。 
换个熟悉的角度，不会还想不起来吧。 
好了，揭晓上面的答案了，那个红色是樱桃的倒影，为了验证一下，某人还吃了一个，这算破坏公物行为吗？ 
一些倒下的树干居然有生长了别的植物，难道嫁接就是这样来的？ 当然不是啦，有些土又有水，可不合适的植物就在这上面长大了。 
找到一棵红叶的，可这不是枫叶哦。 
也许没过多久，旁边那个树梢上也会长新东西。至于是什么，我不知道，你也不知道，风知道。 
好了，第一天心灵之旅就这样结束了，画个心吧，也算不虚此行了，明日再战。 
到九寨沟必须要经过九道拐，我们终于快到了。 
好了，好好休息一个晚上，我们第二天就正式进驻沟里了，这个深秋的九寨真是别有一番风情啊。 进了沟里，直接上了大巴然后去了原始森林。海拔3000米吧，我们一直从原始森林走到天鹅海。 这满山的绿叶，红叶，黄叶，在这里我们也呼吸了大量的负氧离子，回北京可没了，多吸点。 
枫叶也在由黄变红中。 
这个芦苇荡已经忘记是哪里了，应该是天鹅海的一部分吧。 
涓涓的山泉水随着小沟往下飞奔着留着，这些山泉水就是下面各种海的原始材料，加上各种钙化形成了各种各样的颜色。 
下面就是各种海了，具体的名字很多已经记不得了，反正就是各种漂亮啊。 
倒影，这个好像是镜海，据说每天早上来的时候湖水平静的就跟镜子一样，然后倒影着周围山川。 
而映秀也就在旁边了。而旁边就可以看到之前的塌方的一些地方还在建设中，而经常会发生边建设边塌方的情况，导致有些隧道就成了单行道了。 
而一旦逆行了，那对面必须是堵车上了，果然，一过去没多久就发现了堵车的车队了。而大部分都是可怜的长途车司机们。我们回来的时候也是堵车堵上了，不过是前面有车抛锚了。 
一路上带着这种激动终于到了汶川了，想着如果没有地震我们会知道这个地方吗？ 住在这里的少数民族应该是很多很多年以前被我们赶到这里的吧。而去往九寨沟的标识明白的告诉我们还有390公里，真是一个遥远的地方啊。 
汶川的旁边就是茂县了，感觉茂县可不像汶川这边高端大气，一辆辆破面包车出卖了茂县。 
过了汶川后就再也没有漫山的隧道了，有的都是沿着岷江走的国道了。走了又不知道多久，感觉岷江在这里水量比较充沛。这里就是叠海景区，来两张吧。 
这崇山峻岭一眼望不到头啊，其实我不知道，这根本就是一个开始呢。不知道过了多久，好像是在第4个下车点，到了千年大地震松潘的地界了，这里居然看到了蓝天，要说在这山里看到蓝天和太阳出来真是很难得啊。 而美丽的九寨是否也是蓝天呢？ 我盼望着！ 
可没走过几座山又是一会儿多云一会儿蓝天的，之前查过天气预报，九寨1年365天，蓝天的次数可少可少了，也就几十天的水平吧，我们得珍惜啊。 
现在问题是，2个IDC之间的服务器有些可以ping通，有些不行，刚好加监控的都可以。 端口也可以telnet， 但是无法建立连接，一建立连接就被reset， tcpdump的结果就是如下这样的，下面这个是建立rsync的一次连接。 
好了，情况都描述完成了，如何处理吧看。 这台rsync服务器检查了本身，发现没有问题，因为从本地机房进行rsync没有问题。 那问题就应该是在pptp 或者firewall上面了。 由于上周firewall做了一次升级，恢复了配置，发现问题依旧。 于是我思维凌乱了，这个是什么情况呢？ 两边可以ping，但是建立被reset， 让我感觉怎么像是gfw干的事情呢。 抱着最后一丝希望，就一点点排错吧。 首先确定了2边IDC各自内部都没有问题。 于是从pptp client上进行查，这下发现了奇怪的现象。 从pptp client服务器到另外IDC的rsync居然是可以建立连接的，那问题就应该是pptp client上了， 回想了一下之前的操作，发现了问题所在。 因为这个pptp client还拨到了c机房，之前在iptalbes中nat链里的out interface是写死了ppp0和ppp1的，但是由于不定时断线，所以哪条是ppp0，哪条是ppp1是不固定的。 于是这次本来去B IDC应该是走ppp1的，结果走了ppp0，从而导致了异常的故障发生。 从这个可以看出来, iptables的nat链是有点问题的，正常情况out interface指错了的话应该就是不通的。 但是查了man一下，发现如果没有指对的话它就会乱走，有没有规律那就再看源码了。 