之前都是用ping和tracert/traceroute来检测线路的丢包率和延迟,最近发现mtr这个命令集合了以上两个命令的优势,在一个文本图形界面里traceroute出线路各个途径路由,然后连续ping各个节点,可以看出各个节点处的延迟、丢包情况,这样就能很容易看出来问题出在了网络的哪一步。

    通过命令展示出的数据可以看出丢包率:Loss,已发送的包数:Snt,最后一个包的延时:Last,平均延时:Avg,最低延时:Best,最差延时:Wrst,方差(稳定性):StDev。非常强大。

    按d可以切换各个视图,按一下后切换到的视图用?来表示丢包,点表示正常,不过右括号不知道什么意思。再按一下就更复杂了,还有字母数字等等。网上的资料貌似也没有提到,等有时间看看源码。不过默认视图就足够用了。

    刚刚试了一下,从国内到博客服务器,丢包大户是:202.97.53.242,现在丢包率在6个点。看延迟应该是在美国的一个路由。





Tags:

Thinkpad X200拆机及清灰

[| 不指定 2012/05/05 15:59]
    又到夏天了,电脑底面的温度直线上升,准备清一下灰尘,之前清过一次,用清洁气吹了下,但没有合适的工具,拧不开风扇,只能从散热器外侧向内侧吹,效果不好,吹过一次后还变响了,这次有了全套螺丝刀,准备彻底清洁一下。

   底面的螺丝很顺利,很快都拧开了,取下键盘和掌托,然后把屏幕的螺丝拧开,把屏幕下的u型塑料拿下来,开始准备拆主板,主板弄不下来,被无线网卡压住了,于是就开始拆无线网卡,结果悲剧发生了,拧下第一个螺丝后,第二个螺丝拧了几下没拧下来,因为选的十字螺丝刀头的尺寸大了点,又拧了几下,结果拧花了,鸭梨很大,搞了半天搞不下来,只能先将旁边的声卡/sd模块拆下来,腾出地方,捣鼓了半天搞不定,于是决定先搞个小刀把螺丝划出一个沟再拧,找不到小刀,去小区门口5角钱买了个,回来发现螺丝拧起来跟豆腐一样,用小刀划起来还挺硬,把小刀刀头都划平了,勉强在右边划了一个小沟,左边划了几个痕迹,螺丝刀还是吃不上力气,到了吃饭的日子,于是先吃了饭,吃完饭想起来指甲刀,指甲刀一般比较厉害,用指甲刀剪了几下左边,果然剪出一个凹槽,还是不好用力,但指甲刀也无能为力了,蛋疼,期间还试过用核桃夹夹住螺丝刀拧、用螺丝刀顶着侧边的凹槽用核桃夹敲等方法,都纹丝不动。搞了很久耐心快到极限了,之前屏幕还和主板上的无线网卡有信号线连接,现在把信号线拔掉,屏幕取下,然后换了一个稍小一点的一字螺丝刀大力拧了几下,期待奇迹的发生,结果发现螺丝真的动了。赶紧又拧了几下,终于拧下来了。

    主板取下后直接就开始拆散热器了,发现cpu上的三个大螺丝是用弹簧压的,估计防止力度过大把cpu压坏,之前以为铜散热器下有空间,里面是很多灰尘,结果拆下来后发现铜散热器直接是整个和cpu/gpu接触的,没有缝隙,cpu上是导热硅脂,gpu上是导热海绵(不知道是不是这么叫,不过样子挺像),由于手头没有新的,所以不能重涂了,怕灰尘进去,急忙又把散热器拧上了。
    然后拧风扇和散热器之间的三个螺丝,上次就是在拧三个螺丝中的一个的时候拧不下来放弃的,这次有了合适的螺丝刀,很快拧下来了,把风扇和散热器分离后,散热器内侧的景象展现在眼前,怪不得之前吹的没效果,原来散热器和风扇之间的那个界面上覆盖了一层黑乎乎毛毛的东西,把散热器的缝隙塞住了一半,急忙把脏东西清理出来,用清洁气吹了一下,干净了。

    然后开始拧螺丝,比较顺利,无线网卡右侧那个螺丝用旁边预留槽的螺丝替换了,发现那个位置的四个螺丝都跟豆腐一样,稍微一拧就花了,别的地方都还好,看来thinkpad也开始偷工减料了,我的还是08年的tp,现在出的估计更没法用了。

    拧好后用鲁大师看了看,貌似效果不错,不过压力压一会后还是比较烫,但平时使用时底座温度降下来了,爽。


Tags: ,
    最近几个开发环境都换成ubuntu了,但随之遇到一个问题,就是用git时perl老是报错,经常报错报的把正常信息都掩盖住了,报:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LANG = "zh_CN.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").


网上搜了一堆东东,都不是太有效,还是运行靠谱:

export LC_CTYPE=en_US.UTF-8
export LC_ALL=en_US.UTF-8

如果每次启动都自动执行的话就加到bashrc或bash_profile里。

有可能需要重新安装配置相应语言包:
sudo apt-get install --reinstall locales
sudo apt-get install language-pack-en-base



Tags: , ,
    现在很多比较大的站点会把访问顶级域的请求都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子域较好


Tags:
    五一节在家看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是指向自身的。
Tags: ,
    很久之前有过如下疑惑:比如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记录





Tags:

修改dns服务器

[| 不指定 2012/04/29 20:07]
    昨天晚上回家发现博客打不开了,查了下原来是dns解析失败,上监控宝看有一部分监控点也是连续几小时无法解析,看来he的dns也要挂掉了,于是开始换dnspod,注册了一个,把域名记录一个一个的搬了过去。

    今天早晨一看监控宝,发现域名倒是能解析了,但解析时间都在1s以上,实在无法忍受,不过不排除是监控宝的dns缓存还没过,还在找he要解析记录,准备再观察一下。不过看论坛说dnspod现在也不靠谱了。哎,实在不行自己解析,不过就是会牺牲一点稳定性。




    前两天在用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获取它的值,那么建议先在栈上复制一份,然后对于复制的值进行获取。





Tags:
    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时,会路由到离自己最近的服务器上。这样有效避免了数据的远程传输。



Tags: ,
    之前按字面意思理解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等)
分页: 7/33 第一页 上页 2 3 4 5 6 7 8 9 10 11 下页 最后页 [ 显示模式: 摘要 | 列表 ]