Snooda

    最近arm盒子想用下tun功能。结果发现内核编译时没开tun，所以决定编译一个。

    先去找到了当前内核的config文件。打开了tun支持。下一步就是去找内核的源码。找了半天。发现没有完全一样的。于是找了个版本相近的，编译完载入。显然加载不了。提示insmod: error inserting 'tun.ko': -1 Invalid module format。在dmesg里提示tun: no symbol version for module_layout。

    很多资料在这里提示没有Module.symvers云云。但我的编译目录是有这个文件的。所以不是这个问题。

    由于内核源码版本和当前内核版本并不完全一致。所以尝试关闭CONFIG_MODVERSIONS。编译后加载。

    insmod依旧提示invalid module format。dmesg里改为提示version magic 'xxxxxxxxxxxxxxxxxxxxxx' should be 'xxxxx'。


    modprobe是可以强制忽略version magic的。即--force-vermagic参数，使用后成功载入tun.ko。由于内核源码非常相近。故工作正常。
    查阅了一下2.4内核源码中对CONFIG_MODVERSIONS的说明，该参数有四种可能。即内核是否开启与要加载的扩展是否开启2*2。经观察发现在3时代内核上这个特性跟之前的文档不太一致。由于时间关系没有详细研究。

    modprobe还有个参数，即--force-modversion。是在编译时开启了CONFIG_MODVERSIONS的情况下忽略接口不一致的。这个参数没有实验。


    也就是说如果想给一个内核编译扩展。最好的方式当然是找到当时编译的环境。或者编译一个新内核+扩展给系统装上。但现实中往往无法这样做。这时找到相近的源码编译。最后强制载入也就行了。（生产环境不推荐）



    happy，tun可以用了。

    今天发现了一个现象。有一台io压力比较大的机器，基本iowait百分之七十左右。idle接近0。按我的理解是百分之七十的cpu都在等待或处理io。没有空闲的时间片了。

    但开启了一个视频转码服务后，iowait降到很低水平，usr和sys飙高，idle还是接近0。但此时发现视频转码和原io操作的服务均正常运行，未发生性能波动。

    马上感觉到其中的矛盾。cpu不是用完了么？为啥还能承受一个视频转码这种cpu密集的服务呢？

    
    仔细查看了一下iowait的解释。原来它的真实含义是：cpu空闲并且有进程在等待io就绪的时间。

    也就是说如果iowait很高。那么磁盘压力较大。但此时cpu是较为空闲的。此时如果运行诸如视频转码这种cpu密集型操作。是可以提高cpu利用率的。这一点在服务混布提高利用率上可以做文章。

    今天发现这样一种部署情况：
   a的文件放在b的目录下，a不想让b看到，所以设置了700权限。

   其实这样也是不安全的。b虽然看不到a的文件，但可以把a的文件删掉。

   因为linux里，目录也是一个“文件”，里面记录了它里面有哪些文件，这些文件的inode。b的目录里可以放啥，b说了算，也就是说，只要将那个目录“文件”里不顺眼的文件项删掉，就能删掉文件，而不管对那个文件本身有没有权限。

   至于文件是不是真的被删掉了。取决于文件的引用数，如果没有其他硬链存在。文件就真的被删了。

  
   这里有一个特殊的目录：tmp。大家都可以往里面写，但只有属主可以删掉自己的。
   可以看下tmp目录的权限，它是root所有，所以对于普通用户来说，生效的是最后三位：rwt。其实应该是rwxt。t是特殊权限，是建立在x权限上的，如果删掉x权限，可以看到t变成了T。即失效了。

   t：SBIT（Sticky Bit）目前只针对目录有效，对于目录的作用是：当用户在该目录下建立文件或目录时，仅有自己与 root才有权力删除。
最具有代表的就是/tmp目录，任何人都可以在/tmp内增加、修改文件（因为权限全是rwx），但仅有该文件/目录建立者与 root能够删除自己的目录或文件。




  

新增的HTTP返回码：
650：应用已删除或域名未绑定
651-654： 其他内部错误，请联系管理员


680：被应用防火墙ip黑名单封禁
681：超过应用防火墙设置的限额


配置功能（rewrite）新增点：

1，新增regex_url。该规则与url规则用法相同，区别是规则为标准正则。
例子：
         - regex_url: ^/[a-z0-9]\.html$
                   script: /index.php
                  
注意：regex_url和url规则在同一个app.conf不推荐混合使用。会有匹配顺序问题。

2，新增check_exist。检查文件和目录是否存在。支持的匹配规则：file_exist/dir_exist/not_exist
例子：
    - check_exist: not_exist
                   script: /index.php
                  
3，新增规则：status_code和location。
status_code指定返回的状态码。允许的值：301,302,403,404
location指定跳转地址（在status_code为301,302时使用）
例子：
         - regex_url: ^/secure_page$
                   status_code: 403

         - check_exist: not_exist
                   status_code: 302
                   location: http://example.com/error.html




url规则使用的lua正则由于使用比较晦涩，以后不推荐使用。本次新增的status_code和location也不再支持url规则。
原有url规则功能不受影响。

    在使用自有dns服务器时，一般会使用glue record。即使用ns01.snooda.com作为snooda.com的dns服务器，这样就会遇到一个先有鸡还是先有蛋的问题。为了解决此问题，会使用glue record，即由com域dns服务器提供ns01.snooda.com的ip地址。一般这个记录在域名注册商那里修改。但怎么查看是否修改成功了呢？这里dig就派上了用场。


    使用dig +trace +nosearch +all +norecurse snooda.com

    在返回的结果里，我们会在com域dns返回的结果中，看到一个”ADDITIONAL SECTION“，里面提供了两个a记录。这就是glue record。由于我们试图解析snooda.com，所以先从com域dns服务器获取snooda.com的dns服务器地址，com域dns判断结果是一个snooda.com的子域，所以是glue record。所以不但返回了dns地址，还返回了对应的a记录。

    用这个方式就可以检验设置的glue record是否生效。

    当使用国外服务器时，经常会发现，下载速度只有十几k。平时可能不太注意，认为服务器带宽不足，或者自己使用的宽带不给力，其实很有可能原因并不在此。

    由于光速的局限性，延迟会比较高（即使光沿直线传播，太平洋一个往返也要一百多毫秒）。并且由于距离较远，途径路由跳数较多，并且网络拥堵的原因。经常会发生丢包的情况。

    对于平时使用最广泛的TCP协议来讲，发送端发出包后，接收端会回复ACK，表示自己收到了。用这种机制来保证可靠性。但对于高延迟链路来讲，如果每发送一个包都等待应答，那么大部分时间都在等待数据包到达，而链路则空置了。为此一般会采用滑动窗口技术。即在窗口满之前，发送端一直发送包，然后收到应答后将确认收到的包从窗口中移除。这样可以提高链路利用率。

    TCP还有一个特性则是拥塞控制。当发送端检测到链路发生丢包时，则会主动缩小窗口大小以减慢发送速度，避免拥塞。不过对于跳数较多的链路来讲，只要有一个路由不够稳定丢包，就会被发送端判断为拥塞，从而影响网络速度。

    为了解决丢包问题，最简单粗暴的方法就是双倍发送，即同一份数据包发送两份。这样的话在服务器带宽充足情况下，丢包率会平方级降低。

    这种方式下，直接优点是降低丢包率，直接缺点是耗费双倍流量。一些延伸影响是更容易触发快速恢复逻辑，避免了丢包时窗口缩减过快。一定程度也能提高网络速度。


    最近比较忙，空闲时间做了一个最简单的程序，试用效果很好，在一台VPS上测试后发现，未开启时单线程下载、ssh管道速度在十几K级别。开启后可以达到平均300KB+的速度。效果非常明显。但对于不加速就可以跑满带宽的类型来讲（多线程下载），开启后反而由于多出来的无效流量，导致速度减半。所以对于多线程/高速链路，这个方案是不适合的。

     目前版本是最简单的逻辑，未来会进行细化（主动触发快速恢复、快速重传等），降低流量浪费，提升加速效果。

     目前程序起名net-speeder，相对于修改协议栈来讲，由于后者需要重新升级编译内核，使用用户态程序部署更方便，稳定性更高，兼容性更好。缺点则是性能开销稍大和自由度有损失。总体比较起来，个人使用还是使用用户态程序更合适一些，特别是在虚拟机中使用（OpenVZ，LXC等虚拟机无法自己定制内核）。




      项目托管地址：http://code.google.com/p/net-speeder/
                           https://github.com/snooda/net-speeder


      

关注微信公众号随时接收最新开发进度。近期将会推出加速效果体验ssh/pptp账号

      在服务器操作系统市场上，Linux因其开源、自由的特性赢得了很多人的亲睐。但相比于Windows系统简单直观的GUI界面，Linux的操作很大一部分是使用命令行方式来进行，这对于一部分初学者来讲是一个不小的挑战。操作失误轻则影响服务，重则丢失数据。那么，究竟怎样才能降低风险，更安全的使用Linux呢？

1，  vi的使用
vi是使用很广泛的文本编辑器，可以让双手在基本不离开字母区的情况下完成各种操作。应注意在查看超大文件时，不能使用vi。因为vi会将文件整体载入内存，打开大文件很容易造成服务器内存耗尽、IO占用率飙升。在这种场景下，推荐使用less命令。
2，  慎用rm
在日常操作用，应谨慎使用rm，尤其是-rf参数。对于不需要的文件应先mv到其他位置保留一段时间，待磁盘空间占用率较高需要清理文件时再进行清理。
3，  替换文件使用mv而不是cp
在替换文件时，应先备份原有文件，再使用mv操作将文件覆盖。对于正在使用该文件的进程来讲，mv操作不会在本次使用周期内被感知到，只有重新打开文件时才会生效。而cp则不然。使用cp覆盖文件，特别是覆盖动态链接库，很容易导致一些进程coredump。
4，  编写重要命令时前面加符号#
在编写重要/批量命令时，应在命令开头处先输入符号#（#在shell中为注释符）。确认无误后再去掉#，避免误按回车键导致不完整命令执行造成破坏。
5，  确保操作所依赖条件成立
对于依赖前面执行结果的操作来讲，可以使用&&来连接各条命令，确保前面执行都成功后才进行后面操作，避免前一步执行失败仍继续下一步造成破坏。
6，  使用rsync而不是scp
在拷贝大量文件时，scp无法查看具体进度，并且一但中断就要从头再来。相比之下rsync功能更为强大一些，支持增量传输，并且还可以随时查看进度。
7，  网络操作注意限速
对于rsync或wget等网络操作，应注意限速，避免耗尽带宽影响正常服务的通信。
8，  操作前设计好回滚方案
操作结果不符合预期时，需要将之前的操作回滚。应提前设计好回滚方案，避免到时候手忙脚乱导致操作失误，或操作时未注意备份文件和数据导致回滚失败。

    最近发现有个问题，一个自制的webserver在应答前端请求时，总是要处理1s以上，似乎是由于哪里等待了1秒。研究了下发现：Expect: 100-continue这个东东。

    100-continue这个状态码之前是很少遇到的。这个是http1.1协议为了提高效率设置的。当客户端要POST较大数据给webserver时，可以在发送http头时带上Expect: 100-continue，服务器如果接受这个请求，应答一个HTTP/1.1 100 Continue，那么客户端就继续传输正文，否则应答417，客户端就放弃传送剩余的数据了。这样就避免客户端吭哧吭哧传了一大堆数据上去，结果服务端发现不需要的情况。

    libcurl在不同版本里逻辑不同，有的版本libcurl会在POST数据大于1024字节的时候发送100-continue请求，有的版本则不会。我们用到的libcurl版本会发送，而自制webserver不会应答这个请求，客户端等待1s钟没有收到肯定或否定的应答，还是继续传输了正文，虽然逻辑上并没有问题，但速度上就慢了下来。

    加了下逻辑，对100-continue进行应答，速度马上提高很多。

    很久之前就有一个问题在困扰，就是明显感觉svn操作完后要顿一顿才结束。一直以为是svn机器性能问题，后来上了ssd也没效果。

   最近抽时间看了下。

   先strace一下看看时间，发现在操作末尾两个gettimeofday之间夹了个select操作。会阻塞几百ms到1s不等，然后超时。

   第一感觉是最后处理完了可能给服务器发回个什么数据之类的，服务器那里哪个规则配的不对，客户端连不上然后超时了。

   看svn源码，看不出来末尾做了啥网络操作，封装了好多层，不确定是不是哪一层注册了什么奇奇怪怪的回调函数，在最后析构时搞一把。

   用gdb单步跑了一下。

   发现svn_io_sleep_for_timestamps函数很可疑。

   查看代码，发现这是个延时函数。svn通过mtime获取文件修改信息，所以每次svn co操作末尾，svn会等待一小段时间再返回，svn客户端判断apr_stat返回的文件mtime是不是1000000整倍数（stat看到的mtime小数点后面是否全是0），如果是0，那么svn认为该文件系统不支持毫秒级粒度的mtime记录，就会等待系统时间秒的跳变，即等待平均0.5s，最长1s。如果不是0，那么只等待1ms。
  
   由于svn使用的apr_sleep为了实现较高精度的sleep延时，使用了select来做延时。这就是strace中select系统调用的由来。


   这里还有一个问题，就是如果文件mtime恰好是整数，那么svn就会判断失误，进而等待较长的时间。作者认为总比每次都等较长的时间好。

   之前用的文件系统是ext2，它只支持秒级精度的mtime，而ext4支持更高精度。

   找了一台机器，划了两个同样大小的分区，一个格式化为ext2，一个格式化为ext4，使用svn co向两个分区中checkout代码，前者耗时0.3到1s不等，后者稳定在100ms。性能提升非常明显。

    想上无风扇电源，所以调研下电源去掉噪声后其他地方如何降噪。开始拿cpu风扇入手。cpu散热器用的最便宜的超频三青鸟3。cpu是32nm Sandy Bridge 赛扬G550，比较节能。看网络上有些人在尝试G530无风扇工作，不过都比较简单，决定自己试一下。


    有很多人是在bios中对cpu进行降频以实现降温的，想了下，感觉这种方法灵活性不足，另外太过高端。决定不采用。还是用软件的cpufreq比较简单灵活。使用sensors工具查看cpu温度。


    首先拔掉cpu风扇电源，开机滴滴报警，忽略之，进入系统。看到温度在50度左右。cpu默认工作在1.6G频率下。


    写了个死循环程序，先单核跑满，单核心运行在2.6G频率下，温度缓慢上升。慢慢上升到83度左右稳定下来。

    然后尝试双核跑满，结果温度迅速冲上90+，我看sensors里提示的温度最高值为102度。急忙停了压力，温度1s内就降到了60+。还是挺快的。

     看来默认情况下双核满载单靠散热器是不行的了。下面尝试限制最高频率后的满载测试。

     首先限制双核1.6G，满载，温度没什么变化，很正常，cpu本来就在1.6G下跑着，满不满载没啥区别。
     2G+1.6G，温度上升至70+
     2G+2G，温度缓慢上涨2-3度，看来较低频率情况下，总温度和温度较高那个核的温度相关性大，与发热总核数关系不怎么大。
     2.1G+2.1G，温度上升至80+
     由于80度就已经算是较高的温度了，所以没有继续往上测试。


     当前室温在20度左右。

     也就是说2.1G是可以无风扇长时间稳定运行的一个频率。再高就不好说了。以后有需求就搞个自动限频脚本，温度升到指定值就降低频率防止过热。


     然后看看频率对性能的影响。在网上随便扒拉了一个算某某值的命令，大致跑了下，1.6G频率下跑完需要40多秒，而2G频率下跑完只要33s，再高频率的就没有试了。看来性能还是有一些影响的。