1. 程序描述：
用戶通過登錄頁面向服務器提交登錄信息，如果在一定時間內，用戶提交登錄請求次數超過限制，則登錄頁面出現驗證碼，並要求用戶一併輸入才能正確登錄。
2. 程序面向問題：
針對電腦程序利用其高速性模擬真實用戶向服務其惡意提交請求，對服務器造成危害問題。
3. 解決要點：
1. 用戶識別：判別訪問同一接口的兩個用戶是否是同一個用戶；
2. 訪問頻率控制：判斷頻率超限的策略。
4. 要點解決方案：
1.用戶識別：利用ip + sessionId + uri組合的形式來標識同一接口的兩次請求是否是同一客戶端用戶。選用ip + sessionId + uri組合的原因是，如果只採用sessionId，那麼假使電腦模擬用戶提交程序每次請求的時候都不攜帶sessionId，到服務器端，那麼在服務器端看來每一次請求的是新請求，來自不同的用戶，顯然此種方式達不到判斷用戶是否以訪問過服務的目的。如果只採用ip來標識也會存在問題，當服務器程序掛到了互聯網上，如果有來自在相同網絡但是不在服務器程序所在網絡的用戶羣訪問時，服務器會將用戶羣識別爲同一用戶，顯然這不是想要的效果。另外，一個服務器程序上有不同的服務對應不同的uri，訪問頻率是針對指定接口的，所以uri必不可少。以上就是選取ip + sessionId + uri組合的原因。
2.訪問頻率控制：用定長隊列的思想來控制，具體方案如下：初始化一個存放訪問時間的隊列，容量爲限制的次數。 1）、若當前訪問時間入隊後隊列未滿，則本次訪問時間可以正常入隊，訪問頻率未超過限制; 2）、若當前訪問時間入隊後隊列剛好達到容量，則本次訪問時間可以正常入隊，此時若用入隊後的隊尾元素的值減去隊首元素的值的值小於限制的時間，則頻率超限制，否則頻率不超限; 3）、若當前訪問時間入隊後隊列元素個數超過容量大小，則在本次訪問時間入隊前先將隊首元素出隊，之後對頻率的判別方式如條目2）的判別方式，即，用隊尾元素值減去隊首元素值。
5. 實現過程：
採用面向切片編程的思想來實現。在每次接口請求執行完成後用spring AOP 給這個過程的末尾植入切片，對訪問頻率和驗證碼進行校驗。如果在接口請求中用戶數據都通過驗證，則在切片中先對驗證碼進行校驗，如若驗證碼驗證通過則本次請求合法且提交的信息都正確，服務器端向客戶端發送信號，允許用戶進行接下來的操作; 如果驗證碼驗證不通過，用戶輸入信息有誤，接下來對訪問頻率驗證，訪問頻率沒有超過限制則本次訪問合法，向客戶端返回信息錯誤信號，要求用戶從新登錄;如果驗證碼驗證不通過，且訪問頻率超過限制，則向客戶端發送獲取驗證碼並從新登錄信號。如果接口請求中的用戶數據驗證不通過，則切片中直接隊用戶訪問頻率校驗，然後向客戶端用戶發送相關校驗信號。
6. 程序評估：
1.程序面向restful api型前後端服務：後端對合法性和業務邏輯進行處理，前端根據後端處理完成後返回的數據進行顯示、跳轉或者發出其他後端服務調用請求。
7. 其他技術：
1.驗證碼生成和調用;
2.Spring MVC。
8. 編寫總結：
1. 編寫過程是一個逐漸完善的過程，學到了很多東西：
1.基本demo成型，完成了驗證碼編寫和調用方式的學習;
2.程序介紹，組員評價發現驗證碼生成策略有問題，驗證碼服務應該由單獨的接口提供，這樣刷新驗證碼操作將更加靈活;
3.程序完善和總結，對整個編寫流程和技術有一個概括式的瞭解，再一次複習關鍵問題所在和解決方案。
編寫前沒有對程序實現策略和編寫過程存在的進行詳細分析和預測，導致編寫效率低下，這一點
是需要改進的。
9. 代碼地址：http://download.csdn.net/detail/yangbo2921946188/9457895