網站簡訊發送介面一直在被人循環調用, 嚴重影響到app 端的運行性能, 我是先把網站關掉了, 但是接口一直還在調用, 性能問題還是沒解決, 求問解決思路環境: windows server 2008 + apache + php + mysql
有幾個解決思路,我分別簡單介紹下。 第一種,可以查看access.log日誌,看一下接口訪問情況,某個IP如果一分鐘內幾十次那肯定是在刷了,可以對這個IP做一些限速或者封禁處理,比如這個IP再訪問你可以按照自訂的規則讓他去按一定時間訪問,或者乾脆直接黑名單,網絡層直接拒絕一切訪問。 第二種思路,記錄下訪問IP,和每分鐘最大訪問次數和訪問時間,當用戶訪問接口並提交成功後,相關信息放到Memcache或者Redis裡,做一個對比如果過期了再提交,沒過期就不提交。 第三種思路,做反向代理,內部才能呼叫接口,然後在代理層對訪問進行限制,其實跟第一種思路差不太多。
以上是我個人思考的,不一定是最優的解決方案,歡迎大家批評指正。
發送簡訊前需先驗證圖形驗證碼,圖形驗證碼也要在後端驗證
簡訊介面一定要做限制的。驗證碼限制 ip限制 手機號碼限制。要不然一天幾萬塊都能刷出去
1.服務端控制每個手機號碼 每天發送的次數,例如每天只能發3次
2.服務端每次發送簡訊,必須填寫驗證碼
mark下 網站簡訊介面被爬, 影響到網站效能
有幾個解決思路,我分別簡單介紹下。
第一種,可以查看access.log日誌,看一下接口訪問情況,某個IP如果一分鐘內幾十次那肯定是在刷了,可以對這個IP做一些限速或者封禁處理,比如這個IP再訪問你可以按照自訂的規則讓他去按一定時間訪問,或者乾脆直接黑名單,網絡層直接拒絕一切訪問。
第二種思路,記錄下訪問IP,和每分鐘最大訪問次數和訪問時間,當用戶訪問接口並提交成功後,相關信息放到Memcache或者Redis裡,做一個對比如果過期了再提交,沒過期就不提交。
第三種思路,做反向代理,內部才能呼叫接口,然後在代理層對訪問進行限制,其實跟第一種思路差不太多。
以上是我個人思考的,不一定是最優的解決方案,歡迎大家批評指正。
發送簡訊前需先驗證圖形驗證碼,圖形驗證碼也要在後端驗證
簡訊介面一定要做限制的。驗證碼限制 ip限制 手機號碼限制。要不然一天幾萬塊都能刷出去
1.服務端控制每個手機號碼 每天發送的次數,例如每天只能發3次
2.服務端每次發送簡訊,必須填寫驗證碼
mark下 網站簡訊介面被爬, 影響到網站效能