服務器
摘要: 對于服務器程序而言，尤其是云計算時代的服務器程序，三高標準(高可用、高性能、高擴展)往往是衡量一個優秀的服務器程序的重要指標。本篇文章主要聊聊服務宕機恢復(高可用的重要內容)、負載均衡(高擴展、高可用的主要內容)。以下內容均屬個人工作中的見解，如有不妥之處，歡迎指正。 ----peakflys
閱讀全文
摘要: 項目終于上線了，伴隨著人數的逐步上升，最近查看日志，發現了大量連接超時的日志。項目中使用的是TCP長連接，為了保證網絡資源及時有效的釋放，程序中是1分鐘一次心跳，3分鐘無心跳即認為超時。此為本文的背景
相對于TCP連接建立時的三次握手，我想很多人對斷開連接的四次招呼就不是那么熟了，這里先談一下TCP的斷開，下面給出TCP斷開連接的過程圖：
閱讀全文
摘要: 前段時間研究分布式時寫了一個可擴展的服務器組程序，服務器組之間通信時老是達不到想要的性能。后來抓包排查，原來是TCP滑動窗口引起的問題，本來是很基礎的東西，奈何當初沒有太在意，導致錯誤的產生，現在詳細寫出來，忘不太清楚者警惕！
閱讀全文
摘要: 前段時間在寫《段錯誤造成的常見詭異宕機情況總結(中)》時，分析到 程序中數據寫超時有可能寫到this指針所在的地址里面，導致最終詭異的宕機。其實網絡攻防里常用的緩沖區溢出攻擊也是這個道理，除了使用戶程序甚至計算機掛掉外，還有可能執行攻擊者想執行的任何程序，這篇文章主要詳細剖析一下第二種攻擊的方法以及現在Linux(包括各種修改版本，例如Android)、Windows下常使用的防范措施。
閱讀全文
摘要: 國慶長假終于結束了，從擁堵的噩夢中醒來，該收收心重新回到工作中來了（順便吐槽一下鬧心的長假，平時工作沒時間出去，放了長假了 又不敢出去，路上耗費大量的時間和金錢也算了，弄的整個人也身心疲憊的……）
言歸正傳，接著上回宕機情況說。之前比較難找的宕機錯誤已經在前兩篇隨筆里說過了，這次要說的是前不久一個同事遇到的。他要做一個錄像功能，每次把客戶端的消息轉儲成文件時掛掉。大致代碼如下：
閱讀全文
摘要: 上面一種情況是自己內存寫超了，寫到了用戶態別的結構所在的內存，特點就是core文件顯示 別處對象的內容亂七八糟，且一般是在對象析構時發生，這次講解一下，自己把自己寫壞的情況。
閱讀全文
摘要: 因為內存問題，程序崩潰對于每一個c++程序員而言是很常見的問題，而段錯誤引起的宕機，恐怕是平時遇到的最多的情況，除了常見的指針未判空和野指針問題外，還有不少是比較頭疼的情況，空指針因為定位很直接方便，這里就不說了，野指針因為它的異時異地特性，很難排查，這個以后我會詳細說一下的，這里僅僅介紹一下其他也比較頭疼的段錯誤宕機情況，這是之前自己總結的筆記，前段時間又看到了，感覺對很多人 應該是有用的，于是總結出來供大家參考。
閱讀全文
摘要: 前幾天回答一個問題，是關于我們項目中使用的epoll模式的，因為記不大清了，感覺應該使用的就是epoll的高速模式，也就是ET(edge-trigger)模式。這兩天閑暇的時候，打開代碼又看了一下，在epoll事件注冊時并未標記ET模式，看來實際使用的是epoll默認的LT(level-trigger )模式，為什么呢？使用LT意味著 只要 fd 處于 readable/writable 狀態，每次 epoll_wait 時都會返回該 fd，系統開銷不說，自己處理時每次都要把這些fd輪詢一遍，如果fd很多的話，不管這些fd有沒有事件發生，epoll_wait 都會觸發這些fd的輪詢判斷。
閱讀全文
摘要: 最近挺忙的，也沒時間寫點東西，一直在忙下一個資料片的事情，前幾天在群里見有人問關于大小端的事情，這里說一下。
對于跨平臺的程序或者所用數據牽扯到不同平臺的程序(例如網絡編程)，大小端字節序是個值得考慮的事情。本文主要討論一下網絡編程方面的大小端問題。(by peakflys)
閱讀全文