网站默认域名是否带www的问题（选择统一到顶级域还是www子域）--dns角度
[
| 
2012/05/03 15:21]
| 2012/05/03 15:21]
现在很多比较大的站点会把访问顶级域的请求都url重定向到www子域上，主要是为了网站权重统一的考虑。google站长工具里面也提供了将搜索结果统一到www子域或顶级域上，但为什么大的站点都是从顶级域统一到www子域而不是相反呢，最近看dns，也写写从域名解析角度看统一到哪个比较好。
如果请求访问顶级域，则顶级域的a记录是由顶级域dns指定，而顶级域dns由上级域dns的ns记录指定，这个ns记录的缓存时间是不可控的，有可能会比较短，而访问www子域的话，a记录由顶级域ns记录指定的dns解析，这个ns记录是可以自己控制的，可以设置成比较长的值，并且如果用户访问过其他子域，那么会缓存子域dns地址，这样的话访问www子域直接找子域dns服务器解析即可，无需了解顶级域dns服务器，而如果访问顶级域，就需要查顶级域dns地址了，很有可能要去请求上级dns，像com等域名dns很多同时是由根dns解析的，而根dns均在国外（虽然通过anycast技术可能有国内节点，负载也是不小的）。所以总体来说统一到www子域较好
如果请求访问顶级域，则顶级域的a记录是由顶级域dns指定，而顶级域dns由上级域dns的ns记录指定，这个ns记录的缓存时间是不可控的，有可能会比较短，而访问www子域的话，a记录由顶级域ns记录指定的dns解析，这个ns记录是可以自己控制的，可以设置成比较长的值，并且如果用户访问过其他子域，那么会缓存子域dns地址，这样的话访问www子域直接找子域dns服务器解析即可，无需了解顶级域dns服务器，而如果访问顶级域，就需要查顶级域dns地址了，很有可能要去请求上级dns，像com等域名dns很多同时是由根dns解析的，而根dns均在国外（虽然通过anycast技术可能有国内节点，负载也是不小的）。所以总体来说统一到www子域较好
dns研究进阶-多ns记录（dns服务器）运行原理及设置
[| 2012/05/03 15:05]
| 2012/05/03 15:05]
五一节在家看rfc看的比较晕，rfc的英文貌似都比较晦涩，组织不够有条理，表述也比较模糊，很难了解到详细的东西，昨天公司同事推荐了DNS & BIND（DNS and BIND）这本书，大致浏览了一下，豁然开朗，写出一些总结。
之前有一个二级域是自己解析的，而顶级域是用一些dns商提供的域名解析服务，最近各个dns提供商的服务都不太靠谱了，国外的老是访问不了，国内的dnspod又很不稳定（高峰期动辄就几s的解析时间），于是开始考虑自建dns了。
自建dns首先要考虑的问题就是稳定性，毕竟vps稳定性比服务器还是要差一点，并且出了故障的恢复可能也没有那么及时，这样就需要研究在在线率只有99.5%这个级别的vps上如何搭建一个稳定性较高的dns服务。
经过研究dns的实现原理，发现dns从设计上就是一个高可用性的架构。
首先dns要求域名最少要有两条ns记录（我之前自己的二级域就设了一个貌似也没啥，但顶级域要求最少设置两个），以保证服务的稳定性。如果只有两台dns服务器，则设置成一主一从即可，从dns周期性从主dns获取最新结果，同步参数由SOA记录指定。如果dns比较多，可以设置多主dns，不过需要维护各个zone文件的统一性（可用rdist），每个域名受限于udp包的大小，最多设置10个左右的ns记录（从该书看到的，未详细考证）。
对于多个ns记录，windows的客户端和ubuntu的客户端会首先查询第一个记录，如果失败或超时，则查询下一个。对于某些客户端则会随机挑选一个。
这样的话需要把速度比较优秀的dns服务器放在第一个位置上，把备份服务器放在后面，这样即使第一个dns挂掉，后面的服务器一样能提供服务，只是速度会慢一点而已。但对于随机选ns的客户端就比较蛋疼了，会选到比较慢的服务器，不过这个还是待考证的，可以先搭建一下试试，看看比例如何。
另外搞清了上篇文章所说的域名自身ns记录的问题。很多顶级域的dns都会有@域的ns记录指向自己，之前理解有误，其实这些ns记录是对二级域生效的。这样设置是表示二级域和顶级域由相同的ns服务器负责解析。即使不设置这个记录，顶级域dns服务器也是可以解析子域的，但顶级域的ns记录缓存时间是不可控的（设置时没有ttl），有可能很快过期，这样的话解析二级域时就需要多次去com域dns上查询，而有了ns记录，可以自己控制ttl，在ttl没有过期的时间内，查询时可以直接命中ns记录去查询二级域，有效提高速度。
理论上顶级域dns只负责解析顶级域自身的a、mx、cname、ns记录等，其他二级域记录需要顶级域的ns记录指定的dns来解析，而一般大家使用dns托管的话，二级域名和顶级域往往是一起管理的，所以ns是指向自身的。
之前有一个二级域是自己解析的，而顶级域是用一些dns商提供的域名解析服务，最近各个dns提供商的服务都不太靠谱了，国外的老是访问不了，国内的dnspod又很不稳定（高峰期动辄就几s的解析时间），于是开始考虑自建dns了。
自建dns首先要考虑的问题就是稳定性，毕竟vps稳定性比服务器还是要差一点，并且出了故障的恢复可能也没有那么及时，这样就需要研究在在线率只有99.5%这个级别的vps上如何搭建一个稳定性较高的dns服务。
经过研究dns的实现原理，发现dns从设计上就是一个高可用性的架构。
首先dns要求域名最少要有两条ns记录（我之前自己的二级域就设了一个貌似也没啥，但顶级域要求最少设置两个），以保证服务的稳定性。如果只有两台dns服务器，则设置成一主一从即可，从dns周期性从主dns获取最新结果，同步参数由SOA记录指定。如果dns比较多，可以设置多主dns，不过需要维护各个zone文件的统一性（可用rdist），每个域名受限于udp包的大小，最多设置10个左右的ns记录（从该书看到的，未详细考证）。
对于多个ns记录，windows的客户端和ubuntu的客户端会首先查询第一个记录，如果失败或超时，则查询下一个。对于某些客户端则会随机挑选一个。
这样的话需要把速度比较优秀的dns服务器放在第一个位置上，把备份服务器放在后面，这样即使第一个dns挂掉，后面的服务器一样能提供服务，只是速度会慢一点而已。但对于随机选ns的客户端就比较蛋疼了，会选到比较慢的服务器，不过这个还是待考证的，可以先搭建一下试试，看看比例如何。
另外搞清了上篇文章所说的域名自身ns记录的问题。很多顶级域的dns都会有@域的ns记录指向自己，之前理解有误，其实这些ns记录是对二级域生效的。这样设置是表示二级域和顶级域由相同的ns服务器负责解析。即使不设置这个记录，顶级域dns服务器也是可以解析子域的，但顶级域的ns记录缓存时间是不可控的（设置时没有ttl），有可能很快过期，这样的话解析二级域时就需要多次去com域dns上查询，而有了ns记录，可以自己控制ttl，在ttl没有过期的时间内，查询时可以直接命中ns记录去查询二级域，有效提高速度。
理论上顶级域dns只负责解析顶级域自身的a、mx、cname、ns记录等，其他二级域记录需要顶级域的ns记录指定的dns来解析，而一般大家使用dns托管的话，二级域名和顶级域往往是一起管理的，所以ns是指向自身的。
dns glue record来由及其在godaddy上的设置（summary record）
[| 2012/05/01 20:07]
| 2012/05/01 20:07]
很久之前有过如下疑惑：比如baidu.com的域名dns设置为ns2.baidu.com。也就是说baidu.com这个域名由ns2.baidu.com解析。但问题是，ns2.baidu.com对应的ip又需要找到baidu.com的解析服务器去解析，这样就陷入一个循环。如何解决这个问题呢？周末看了下相关rfc，原来对于ns记录用到的域名，可以设置一下glue record，用来给这些域名提供解析，显然，这个记录需要由一级dns服务器解析。也就是.com dns服务器。显然，这个记录需要去域名注册商那里设置，我用的域名是godaddy注册的，研究了一下，godaddy将这个记录叫做“summary record”，设置的位置也相当偏僻，在域名管理面板的左下角，有个“Host Summary”框，点击add即可添加相关记录，这个从字面意思上并不太能看出来跟dns有关，找了很多资料才找到这里。
对于很多dns提供商和服务程序，当添加一个域名时，会默认带有这个域名的ns记录，这个会比较令人疑惑，因为这个记录正常情况下是不会生效的，域名的dns服务器是上级域服务器指定的，在本级指定看起来没意义，不知道有何原因，个人猜测是为了在多ns记录情况下，从任意dns server查询的时候都能获取到所有的ns记录
对于很多dns提供商和服务程序，当添加一个域名时，会默认带有这个域名的ns记录，这个会比较令人疑惑，因为这个记录正常情况下是不会生效的，域名的dns服务器是上级域服务器指定的，在本级指定看起来没意义，不知道有何原因，个人猜测是为了在多ns记录情况下，从任意dns server查询的时候都能获取到所有的ns记录
修改dns服务器
[| 2012/04/29 20:07]
| 2012/04/29 20:07]
昨天晚上回家发现博客打不开了，查了下原来是dns解析失败，上监控宝看有一部分监控点也是连续几小时无法解析，看来he的dns也要挂掉了，于是开始换dnspod，注册了一个，把域名记录一个一个的搬了过去。
今天早晨一看监控宝，发现域名倒是能解析了，但解析时间都在1s以上，实在无法忍受，不过不排除是监控宝的dns缓存还没过，还在找he要解析记录，准备再观察一下。不过看论坛说dnspod现在也不靠谱了。哎，实在不行自己解析，不过就是会牺牲一点稳定性。
今天早晨一看监控宝，发现域名倒是能解析了，但解析时间都在1s以上，实在无法忍受，不过不排除是监控宝的dns缓存还没过，还在找he要解析记录，准备再观察一下。不过看论坛说dnspod现在也不靠谱了。哎，实在不行自己解析，不过就是会牺牲一点稳定性。
lua_tolstring导致调用lua_next时的lua PANIC问题
[| 2012/04/28 17:49]
| 2012/04/28 17:49]
前两天在用lua_next遍历一个lua表的时候遇到了：PANIC: unprotected error in call to Lua API (invalid key to 'next') 仔细检查了下代码和堆栈信息，发现没有问题，但为什么会说遍历失败呢？
找到文档看了下，原来lua_tolstring只支持number和string类型，但是对于number类型，在取值后也会转换其在表中的实际内容为string，而我遍历的表是使用默认自增索引作为key的，这样对key调用这个函数会导致key变成字符串，因而遍历有问题。
如果表的key不一定是string，而又要用lua_tolstring获取它的值，那么建议先在栈上复制一份，然后对于复制的值进行获取。
找到文档看了下，原来lua_tolstring只支持number和string类型，但是对于number类型，在取值后也会转换其在表中的实际内容为string，而我遍历的表是使用默认自增索引作为key的，这样对key调用这个函数会导致key变成字符串，因而遍历有问题。
如果表的key不一定是string，而又要用lua_tolstring获取它的值，那么建议先在栈上复制一份，然后对于复制的值进行获取。
什么是BGP和anycast，它们有什么作用
[| 2012/04/27 01:20]
| 2012/04/27 01:20]
BGP的全称是Border Gateway Protocol, 边界网关协议。最近在很多机房和服务器/VPS介绍时提到了BGP这个词。并且凡是带了BGP的，价格就要高很多。那么到底什么是BGP，BGP又有什么用呢。
从一些英文资料上来看，bgp主要用于多个不同as用户访问目标时都能有很好的访问速度，参考国内的跨运营商访问。很久之前记得双线主机是给两个ip的，也就是说双线靠同时接入两个运营商的线路实现，这样双ip的站点要想让用户能够访问到和自己同运营商的ip，往往是通过不同的域名，然后让用户手动选择的（之前很多网站都有电信入口或网通入口的链接供选择，现在很多下载站还有这种设置）高级一点就是使用智能dns，自动解析给用户同线路的ip，cdn就是基于这个原理。至于bgp，就更高级了，同一个ip，对于不同的来源会有不同的路由方式。按我的理解就是将同一个ip广播到多个子网络中，这样各个子网络上的访问者都可以从本网络路由访问到指定ip，避免了跨运营商访问。
还有一个类似的东西叫anycast，看了一会资料没有太看懂跟bgp是什么关系，貌似是说anycast是bgp的一种增强版实现？
anycast是更进一步的实现，是多server绑定同一个ip，用户在访问时会路由到离自己最近的server上。比如google.com。同一个ip在全球范围内ping的话值都比较低。原因就是每个地区用户访问该ip时，会路由到离自己最近的服务器上。这样有效避免了数据的远程传输。
从一些英文资料上来看，bgp主要用于多个不同as用户访问目标时都能有很好的访问速度，参考国内的跨运营商访问。很久之前记得双线主机是给两个ip的，也就是说双线靠同时接入两个运营商的线路实现，这样双ip的站点要想让用户能够访问到和自己同运营商的ip，往往是通过不同的域名，然后让用户手动选择的（之前很多网站都有电信入口或网通入口的链接供选择，现在很多下载站还有这种设置）高级一点就是使用智能dns，自动解析给用户同线路的ip，cdn就是基于这个原理。至于bgp，就更高级了，同一个ip，对于不同的来源会有不同的路由方式。按我的理解就是将同一个ip广播到多个子网络中，这样各个子网络上的访问者都可以从本网络路由访问到指定ip，避免了跨运营商访问。
还有一个类似的东西叫anycast，看了一会资料没有太看懂跟bgp是什么关系，貌似是说anycast是bgp的一种增强版实现？
anycast是更进一步的实现，是多server绑定同一个ip，用户在访问时会路由到离自己最近的server上。比如google.com。同一个ip在全球范围内ping的话值都比较低。原因就是每个地区用户访问该ip时，会路由到离自己最近的服务器上。这样有效避免了数据的远程传输。
lighttpd中handle_start_backend钩子（hook）函数的理解
[| 2012/04/25 19:59]
| 2012/04/25 19:59]
之前按字面意思理解handle_start_backend是说连接后端服务端口（webserver，fastcgi等等），今天发现并非如此。
这个hook是在CON_STATE_HANDLE_REQUEST_HEADER状态时，
如果con->mode仍旧是DIRECT类型且con->physical.path为空，会先调用：
plugins_call_handle_uri_raw
plugins_call_handle_uri_clean
plugins_call_handle_docroot
plugins_call_handle_physical
如果con->mode还是DIRECT，那么会判断con->physical.path指定的文件是否存在，
若存在，如果是软链但是con->conf.follow_symlink为0，那么403，如果是目录但请求url不是路径名，则301跳转到目录路径（在末尾加/）
若无权限访问，返回403
若找不到文件，返回404
若ENOTDIR（对文件做了目录操作），则考虑path_info
若EMFILE（进程句柄不足），则返回HANDLER_WAIT_FOR_FD
若不是以上情况，打印错误日志，返回500
如果con->physical.path存在且无错误发生，或为ENOTDIR，那么又判断了一次是否存在（这里代码设计比较恶心）
如果是普通文件且没有软链问题，那么break出去执行plugins_call_handle_start_backend。
反之则一直向上遍历，直到遍历到一个真实存在的文件，如果找不到，那么404，如果找到了，将pathinfo串放入con->request.pathinfo。然后截短con->uri.path。
然后才会去调用plugins_call_handle_start_backend。
所以对于很多动态请求是不会调用plugins_call_handle_start_backend的。
这个钩子被mod_access调用用来实现deny_all功能。
被mod_indexfile调用用来实现默认文件功能（请求/时映射到index.php等）
这个hook是在CON_STATE_HANDLE_REQUEST_HEADER状态时，
如果con->mode仍旧是DIRECT类型且con->physical.path为空，会先调用：
plugins_call_handle_uri_raw
plugins_call_handle_uri_clean
plugins_call_handle_docroot
plugins_call_handle_physical
如果con->mode还是DIRECT，那么会判断con->physical.path指定的文件是否存在，
若存在，如果是软链但是con->conf.follow_symlink为0，那么403，如果是目录但请求url不是路径名，则301跳转到目录路径（在末尾加/）
若无权限访问，返回403
若找不到文件，返回404
若ENOTDIR（对文件做了目录操作），则考虑path_info
若EMFILE（进程句柄不足），则返回HANDLER_WAIT_FOR_FD
若不是以上情况，打印错误日志，返回500
如果con->physical.path存在且无错误发生，或为ENOTDIR，那么又判断了一次是否存在（这里代码设计比较恶心）
如果是普通文件且没有软链问题，那么break出去执行plugins_call_handle_start_backend。
反之则一直向上遍历，直到遍历到一个真实存在的文件，如果找不到，那么404，如果找到了，将pathinfo串放入con->request.pathinfo。然后截短con->uri.path。
然后才会去调用plugins_call_handle_start_backend。
所以对于很多动态请求是不会调用plugins_call_handle_start_backend的。
这个钩子被mod_access调用用来实现deny_all功能。
被mod_indexfile调用用来实现默认文件功能（请求/时映射到index.php等）
lighttpd中钩子（hook）函数的使用
[| 2012/04/24 22:57]
| 2012/04/24 22:57]
lighttpd内部使用了状态机处理每个请求，在状态机中插入了若干个钩子来供扩展使用，在执行到钩子函数那里时，会按扩展载入顺序，依次回调使用了该钩子的各扩展指定的函数，这样会有一些编程中隐藏的易错点。
1，顺序在后面的钩子不能假定前面的钩子函数一定会被执行到。
之前遇到过这样的问题，在一个扩展中使用了两个钩子函数，第一个里面申请了一些资源，第二个里面使用并释放，结果实际中发现对于某些请求，第一个钩子可能没有被执行就到了第二个钩子那里，于是出core。
查了一下原因，原来排在该扩展前面的mod_access扩展在第一个钩子被调用时返回了HANDLER_FINISH，这样，对于后续调用该钩子的其他扩展不会被回调。于是该扩展的第一个钩子函数未被调用到。
2，同一个钩子可能会被调用多次。
一些情况下，连接状态会rollback，这样的话同一个hook会被回调多次，还有一些情况会导致调用多次，比如给多个钩子指定了同一个处理函数。
有时我们需要为每个扩展在每个连接生命周期内维护一个变量，这时可以用到con->plugin_ctx[p->id]，这是一个void *指针，把数据指针存入该变量，并在连接释放时释放掉即可。
1，顺序在后面的钩子不能假定前面的钩子函数一定会被执行到。
之前遇到过这样的问题，在一个扩展中使用了两个钩子函数，第一个里面申请了一些资源，第二个里面使用并释放，结果实际中发现对于某些请求，第一个钩子可能没有被执行就到了第二个钩子那里，于是出core。
查了一下原因，原来排在该扩展前面的mod_access扩展在第一个钩子被调用时返回了HANDLER_FINISH，这样，对于后续调用该钩子的其他扩展不会被回调。于是该扩展的第一个钩子函数未被调用到。
2，同一个钩子可能会被调用多次。
一些情况下，连接状态会rollback，这样的话同一个hook会被回调多次，还有一些情况会导致调用多次，比如给多个钩子指定了同一个处理函数。
有时我们需要为每个扩展在每个连接生命周期内维护一个变量，这时可以用到con->plugin_ctx[p->id]，这是一个void *指针，把数据指针存入该变量，并在连接释放时释放掉即可。
phpLiteAdmin-很强大的sqlite管理面板
[| 2012/04/23 22:14]
| 2012/04/23 22:14]
很久之前用过sqlite，当时是做邮件转发器的时候，遇到的一个问题是没有好的面板，装过一个，页面特效还不错，不过很难用，功能也少，桌面版的也搞过，不过也是很简陋的类型。纯命令行操作实在不行，于是很久没用。
最近搞了新的监控程序，有较大量的监控数据要存储，由于查询很少（也就自己看看），数据重要性不高，放在mysql里不必要（mysql是定期备份的，放mysql里会占用大量备份空间），所以决定放到sqlite里。按月分库，这样查询方便，节省资源。
遇到的问题又是面板，本来打算自己写一个，不过还是先搜搜，放狗搜关键字搜了几个，发现都是停止开发若干时间的不靠谱产品，不过上sqlite官网上的链接里看，排第一位的是phpLiteAdmin，一看这个就眼前一亮，看名字像是跟phpmyadmin有关系，点进位于google code的项目主页上看了看，原来是界面上仿phpmyadmin的，看了截图相当靠谱，看更新时间是1月4号，开发比较活跃，下载了源码看了看，原来整个程序写在了一个php文件中，大概5千行左右，用起来相当方便。装上用了下，功能很不错，界面美观，连帮助文档都有。最新版本是1.9.1，官网说明上说准备写2.0版，改成多文件模式，不过现在的版本也够用了。
最近搞了新的监控程序，有较大量的监控数据要存储，由于查询很少（也就自己看看），数据重要性不高，放在mysql里不必要（mysql是定期备份的，放mysql里会占用大量备份空间），所以决定放到sqlite里。按月分库，这样查询方便，节省资源。
遇到的问题又是面板，本来打算自己写一个，不过还是先搜搜，放狗搜关键字搜了几个，发现都是停止开发若干时间的不靠谱产品，不过上sqlite官网上的链接里看，排第一位的是phpLiteAdmin，一看这个就眼前一亮，看名字像是跟phpmyadmin有关系，点进位于google code的项目主页上看了看，原来是界面上仿phpmyadmin的，看了截图相当靠谱，看更新时间是1月4号，开发比较活跃，下载了源码看了看，原来整个程序写在了一个php文件中，大概5千行左右，用起来相当方便。装上用了下，功能很不错，界面美观，连帮助文档都有。最新版本是1.9.1，官网说明上说准备写2.0版，改成多文件模式，不过现在的版本也够用了。
vps的系统时间不准确问题
[| 2012/04/21 17:50]
| 2012/04/21 17:50]
最最早买burst NET的vps时，就是因为其时间老是不准确，最后不使用了，后来用的一些vps都没什么时间问题，openvz的一般时间都比较准，xen的可以自己用ntpdate校准，也不存在问题。
今天发现最近搞的一个vps时间又不准了，前几天发现时间差了半分钟，找客服校准后今天看又差了4秒，平均每天要差1秒多点，相当不爽。发ticket希望客服能加个crontab任务定期校准一下服务器时间。
在印象中电脑主板时钟已经做的不错了，怎么还会有每天差1秒这种问题。。。会不会主机商用的服务器有问题。比较囧。由于那个vps未来想观察一段时间稳定后作为主力机的。所以要求还是比较高。
今天发现最近搞的一个vps时间又不准了，前几天发现时间差了半分钟，找客服校准后今天看又差了4秒，平均每天要差1秒多点，相当不爽。发ticket希望客服能加个crontab任务定期校准一下服务器时间。
在印象中电脑主板时钟已经做的不错了，怎么还会有每天差1秒这种问题。。。会不会主机商用的服务器有问题。比较囧。由于那个vps未来想观察一段时间稳定后作为主力机的。所以要求还是比较高。
