前幾天，我們的站點的速度忽然慢了下來，接著發生了當機，重新啟動後最初訪問不錯，不久又慢了下來，資料庫伺服器方面沒有顯示有什麼巨大壓力，並且在**根目錄下建立乙個靜態檔案，居然訪問速度也奇低，由於**最近正在更新，所以懷疑是不是邏輯有什麼問題，然而和同事交流發現最近並沒有更新關鍵的邏輯，在排除這種可能性後，焦點集中到了攻擊上
可是web伺服器端統計資料顯示也沒有很大的壓力，正納悶的時候，回去想看郵箱裡的錯誤報告（這是由程式把所有黃頁錯誤自動**過來的），由於**經常會被各種程式掃瞄，掃瞄會造成許多無法訪問的路徑錯誤，加上訪問超時等，這種報告每天都會有7-800封，所以一般都忽略掉:)，而今天由於**奇慢，錯誤報告瞬間超過了5000多封，郵箱已經無法開啟，後來據同事說，整個公司的郵件伺服器都當掉，所以只好請運維人員清空了我們郵箱
幸好本地的outlook中還保留了一些發生問題最初時候的錯誤郵件，發現有很多outofmemory錯誤，都是由一種特定的操作引起的（不妨稱為a操作）而這種錯誤本身並不能解釋問題，因為發生錯誤的模組是分布在和伺服器不同的另外一台機器上，去查了以下這個操作涉及的資源，（下稱為資源b）發現這個資源由於被反覆增加內容而巨大無比，而對這種資源的操作成本是和資源的大小成比例的，而且呼叫是同步而非非同步，也就是雖然整個對資源的操作過程是在另外一台機器上，但是呼叫端會一直阻塞等到操作完畢（或者超時）才會退出
這就造成請求排隊的原因.
攻擊者就是利用a操作沒有時間間隔的限制，反覆呼叫，而使得**癱瘓
整理邏輯發現，a操作首先是向資料庫中插入一條資料，然後更新資源b,開始時候b不大，而由於請求頻繁，資料庫的壓力大，請求可能有一些排隊，但是**還可以承受，後來隨著b資源的增大，請求開始排隊，這時反而資料庫的壓力反而小了，因為請求都堆在了對資源b的操作上
再次重啟動服務後，果然看到了這個現象，發現資料庫開始壓力很大(由於b資源已經無法操作,大概攻擊這開始操作其他的資源)
我們在解決的時候，首先在資料庫端對a操作加上了時間間隔，資料庫的壓力立刻降低，然而請求依然排隊，最後在前端也加入了限制，解決了這個問題
對這個問題進行總結
所以要想辦法減低惡意請求的處理時間，一方面是要識別他們，另外就是如果是惡意請求，就要盡快的返回，能夠盡量在前端判斷就在前端判斷，能多早判斷就多早判斷，盡量不要拖到資料層。比如在解決這個問題時，我們就認為1秒內兩次執行a操作為惡意操作,並且對時間間隔的判斷在請求一開始就執行。
不要忽略錯誤報告：無論錯誤報告有多長，請不要輕易刪除他們，因為他們永遠可能是你找到問題的鑰匙
從MVC模型看設計
從mvc 模型看設計 一己薄劍 2007 06 02 我們知道mvc模型中model view controller之間的關係如下 如圖所示，在這個物件建立時要做的就是建立各個內部物件，然後註冊各個物件之間的關係，這種關係由他們之間的互動來決定，並且決定了在接受到使用者輸入時他們之間互動的複雜性與有...
從《只狼》看現代遊戲設計
只狼 影逝二度 sekiro shadows die twice 是由from software開發的第三人稱動作遊戲，在2019年3月22日全球發布。遊戲的故事發生在十六世紀末的日本戰國時代，玩家將扮演一名忍者角色，為自己的領主執行任務，見證乙個不斷流血的世界。主角是乙個左臂是義肢的武士，戰鬥有一...
從Executor介面設計看設計模式之最少知識法則
首先說一下設計模式的六大原則 1 單一職責原則 乙個類只負責乙個功能領域中的相應職責，或者可以定義為 就乙個類而言，應該只有乙個引起它變化的原因。2 開閉原則 對修改關閉，對擴充套件開放。3 依賴倒轉原則 依賴倒轉原則，指高層模組不應該依賴低層模組，兩個都應該依賴抽象 抽象不應該依賴細節，細節應該依...