最近接触到一个Transfer-Encoding: chunked相关的问题,原来http在应答时,有两种方式来标示应答body的长度,一种就是用content-length方式直接指明body长度,还有一种就是chunk模式。

    在这种模式下,应答正文分段发送,每个chunk由长度段和数据段组成,每个段均由\r\n结束,当服务器发送完数据后,发送一个长度为0的chunk,即:0\r\n\r\n。其中长度段为十六进制表示。


举例一个长度11的chunk:

b\r\n12345678901\r\n



    chunk模式多用于结果长度未定的情况下,比如用php输出一个长字符串的时候,就默认使用的chunk模式,当然可以通过header来指定使用content-length模式。不过需要自己算出应答body的长度。

    chunk模式的一个好处是可以进行分段压缩,服务器对每个chunk进行gzip压缩发送给客户端。


Tags:

vi/vim设置语法搜索高亮

[| 不指定 2012/05/07 23:16]
    公司的电脑vi是有搜索高亮的,我自己的几个系统都没有,不过之前用搜索功能不算太多,也就忍了,今天终于决定要也给我的加上配置。

    在.vimrc里加上:set hlsearch即可。

    如果想单次搜索高亮,则:match Search /word/

    还有一个功能:set incsearch,这个是在搜索过程中动态高亮,就是在搜索时,随着单词的输入高亮其被找到的位置,不过作用感觉比较一般。



Tags: ,
    今天发现一个问题,发现博客的js和css都没有gzip压缩,大号js动辄就20几k,很奇怪,以为是迁移导致的某个地方忘了开,查了下,发现之前的也没开,疑惑。

    我明明在ngix配置文件里加了gzip  on;了,但为啥js和css没有开呢,查了下nginx文档,原来默认只对text/html类型的压缩。

    加了一句:gzip_types application/x-javascript text/css
    ok,现在js和css都压缩了,加载速度又提高了不少。




Tags:

博客迁移至台湾

[| 不指定 2012/05/06 20:09]
    一个月前入了台湾vps,考察了一个月,感觉稳定性和速度上都还不错(废话,价格在那里),决定要把博客迁移过来,劳动节前动力还挺大,过了五一反而感觉一般般了。这周末搞了个监控程序,需要部署,正要往新vps上布的时候想想还是把系统重装一下,把测试用的那一坨东西都清理掉后再部署,以后再迁移的时候就不用重新布了。

   系统重装后开始安装基础环境,各项都搭好后心想,都基本搞定了,一不做二不休,直接迁过来得了,于是先用rsync把程序同步过来,webserver配置配了下,然后数据库导入,跑了一下正常了,然后切域名,搞定。
    然后去超市了,在麦当劳休息了一下,期间用手机访问了下,发现在线人数很高,突然想起来忘了部署我写的那个分辨爬虫的php扩展,从超市回来后把php错误日志打开,部署好php扩展,发现没装gd库,验证码出不来,装了一下gd库,搞定,速度很快。

   这时看日志发现google的爬虫异常活跃,大概以4s一个的频率重新抓站,莫非是看到了换ip要重新跑跑?baidu的爬虫毫无动静,又被bs了。



Tags:

debian6安装字体简易方法

[| 不指定 2012/05/06 14:05]
    今天用了一个debian6的系统,啥字体也没装,用locale -a看时只有C和POSIX,没有en_US.utf8,怎么办呢,很简单,执行:dpkg-reconfigure locales (root权限),然后根据提示选择要装的字体就ok了。






Tags:
   之前都是用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: ,
分页: 7/31 第一页 上页 2 3 4 5 6 7 8 9 10 11 下页 最后页 [ 显示模式: 摘要 | 列表 ]