Snooda

    很久沒寫blog了。今天考慮寫一篇，登陸過程中想起目前登陸還是http裸奔狀態，安全性實在是差。決定加一個登陸https保護。

    之前搞過一個startssl的免費證書，一年到期了。這次不想用他家了，一副濃濃山寨風。去namecheap搞了一個，很快就簽發了。

    給一個子域名部署上去，把博客登陸提交地址改成https地址。這樣密碼的提交操作就被https保護了。


     如果只這么做了，登陸是不會成功的。因為子域的session和主域session默認是不通的。

     在session_start前加一句：  ini_set("session.cookie_domain", '.snooda.com');


     然后重啟一下瀏覽器（此步驟必須）


     嘗試一下登陸，ok了。

    Thinkpad剛買回來的時候散熱性能是非常好的，夏天用也非常涼爽，但用上兩三年后，d殼就會非常熱，夏天感覺都能有五十度往上了。拆開徹底的清理過灰塵，好了一些，但遠沒有新機的時候好。

    看到網絡上很多人提到給筆記本風扇上了油或者換了新風扇，溫度下降很多。認為有可能是風扇老化了。

    查看風扇轉速，發現還是3000+轉啊，噪音是變大了。但轉速在那里，散熱器灰塵也吹干凈了，風量不小。


    為啥就是那么熱呢？



     今天終于找到了問題的答案。原來散熱器也是會老化的。


     筆記本的散熱器就是一個銅的家伙，之前一直以為是靠銅來導熱，還想那么長，導熱過去要多久。今天仔細一研究，發現小小的散熱器也用的熱管。時間長了，熱管里的導熱劑泄露，導致熱管導熱性能下降。于是就產生了這種結果：風扇狂轉，風量很大，但溫度就是降不下來。


      這個時候只更換風扇是不夠的了。要將整個散熱器更換才可以治本了。

    最近發現很多同學不知道線上操作替換文件的要點。所以又整理了一下。


    線上替換一個正在運行進程的文件時（包括二進制、動態庫、需要讀取的資源文件等）。應避免使用cp/scp操作。而需要使用mv/rsync作為替代。

    原因：cp是將源文件截斷然后寫入新內容。也就是說正在打開這個文件的進程可以立刻感知到修改。修改文件內容很可能導致程序邏輯錯誤甚至崩潰。而mv則是標記”刪除“老文件，然后放一個新的同名文件過去。也就是說老文件和新文件其實是兩個不同文件（inode不同），只是名字一樣而已。正在打開老文件的進程不會受到影響。如果進程使用了mmap打開某文件（比如載入so），如果目標文件被使用cp覆蓋并且長度變小。那么讀取差額部分的地址時（在新文件中其實已經不存在了），會導致SIGBUS信號。使進程崩潰。




    至于可執行文件本身。倒是不怕cp導致崩潰。。因為cp時會報”text file busy"。壓根cp不了。這時候也應該使用mv類操作。替換完成后重啟進程。執行的就是新的可執行文件了。

    lighttpd有一個功能，就是收到SIGHUP信號時會重新打開日志文件。這樣在日志切分時很有用。但最近發現了一個bug。

    就是如果有子進程掛掉。父進程新fork出的子進程accesslog會默認打日志到最最開始父進程啟動時的那個文件里。


   看了下代碼。原來父進程在收到SIGHUP的時候只是把errorlog重新打開了下。沒有重新打開accesslog（沒辦法，這個句柄是mod_accesslog模塊搞的）。所以父進程維護的accesslog句柄一直是最老的。它本身不打accesslog日志倒無所謂。但它fork出的子進程是打的。這樣就有問題了。



    一個最簡單方法。就是外部腳本判斷進程有更新的時候發一個SIGHUP信號過去。

    根治方法就是父進程重新啟動子進程時給其發一個SIGHUP信號。

    至于父進程自己處理SIGHUP時重新打開句柄這個我感覺不太好。畢竟那是模塊內部數據。lighttpd主干不應該關心。

    最近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賬號