最近和眾屌絲一樣，在12306上面刷著春節回家的票。與她大戰無數個回合之后，終于搶到了一張回家的高鐵票，不斷感慨最近人品還不錯。當前，在使用12306的過程中，充滿很多的心酸，念叨了鐵道部的親人很多次（罪過），其中最讓人糾結的一項即是：驗證碼。 12306采用驗證碼， 無疑是一種很不錯的措施，可以在一定程度上阻止了黃牛們的瘋狂行為，不過也給正常使用驗證碼的童鞋帶了個很頭痛的問題，在選座提交訂單的關鍵時候，竟然驗證碼圖片拉取不下來又或者驗證過程非常耗時。鑒于自己也是無數碼農中的有這職業病的一員，為此也來談談關于驗證碼的優化方案。 驗證碼通常一張靜態的圖片，但是12306使用的卻是一張動態的圖片（GIF格式），動態圖片的驗證碼大大的提高了破解的難度，但無疑也具備比較高的生成成本。我們首先來看一下通常情況下的驗證碼校驗流程： 1）瀏覽器向驗證碼服務器發起獲取驗證碼圖片的請求； 2）驗證碼服務器返回驗證碼圖片文件和圖片文件對應的ID編號（ID編號一般下發到瀏覽器的Cookie中）； 3）瀏覽器提交用戶輸入的驗證碼和圖片文件ID編號； 4）Web服務器校驗用戶輸入的驗證碼與圖片中展示的驗證碼是否一致，根據校驗結果來向用戶展示不同的頁面； 下面我們來看一下系統的整體架構圖： ? ? 主要處理流程為： 1、獲取驗證碼 1）從配置中心中獲取當前可用的頻率控制、驗證碼庫、待驗證庫可用的服務地址列表 2）頻率控制，主要控制當前請求是否屬于惡意攻擊； 3）驗證碼庫，獲取可用的驗證碼信息，即獲取一個可用的驗證碼圖片文件地址； 4）將獲取到的驗證碼信息寫入到待驗證庫中，方便后續進行校驗驗證碼； 2、校驗驗證碼 1）根據從前端獲取到的圖片編號（獲取驗證碼時，下發的對應編號），來從待驗證庫中獲取驗證信息； 2）將驗證結果發送到校驗統計模塊； ? ? 在設計過程中需要考慮的點： ? ? 1）惡意刷新 來自某個IP頻繁的請求驗證碼，大體上就可以判定驗證碼正在被刷中，需要采取措施進行一定的頻率限制，降低繼續被刷的請求量，這里我們可以采用比較簡單限制來個某個IP請求次數，當然也可以根據業務特性，添加業務對應的頻率控制邏輯； 2）驗證碼有效期 驗證碼可以生成一條Key—Value的數據存放到Memcache中（即待驗證庫），Value為：驗證碼圖片文件ID、驗證碼Code、生成時間，每個請求驗證碼圖片的請求，均在緩存中插入一條記錄，每發送一個驗證請求，即將緩存中的這條記錄刪除失效。 3）圖片文件與圖片編號 兩者之間不可以建立一一對應的關系，否則，壞人只需要保存圖片編號，下次就可以重復提交對應的驗證碼；但是可以建立一對多的關系，也就是一張圖片對應多個圖片編號，但是一圖片編號只能唯一對應圖片； 4）驗證碼生成 驗證碼圖片文件的生成相比而言是比較慢的操作，所以需要采用離線計算成功的方案，避免瀏覽器獲取圖片驗證碼文件耗時比較久，影響用戶的體驗；這里存放一個問題，什么時機啟動驗證碼生成的流程，有以下幾種策略： a）每天定時生成更新，策略簡單實現； b）定時檢測驗證碼可用量，來生成一批新的驗證碼文件； 總之，驗證碼圖片文件的生成必須是離線進行的，同時在此時需要為圖片文件生成一個或者多個編號；服務部署的個數，完全取決于驗證碼的消耗量； ? ? ?5）驗證碼庫 驗證碼庫，應該采用那種數據結構？Mysql還是其他的數據結構。在這里，可以嘗試采用Redis的list結構來當作消息隊列來使用或者其他的可用的消息隊列。需要獲取驗證碼時，從消息隊列中Pop出一個值即可。每個記錄中至少需要存儲的字段為：圖片編號、圖片地址、驗證碼等信息。消息隊列中的記錄 < 50%時，可以出發驗證碼生成邏輯來定時插入新的驗證碼。面對更并發的驗證碼請求量，可以在集群中多部署幾套Redis消息隊列以及驗證碼生成系統來應對； 6）圖片編號的生成 驗證碼圖片文件需要支持在多臺機器上面部署多個服務，同時也要支持在單機上面部署多個服務，這里就需要解決如何來生成唯一驗證碼圖片編號的問題。可以通過根據機器IP和服務編號來解決這個問題，每臺機器上面的服務均存在一個服務編號（保證服務編號在單機上是唯一的），計算公式可以為：ID = MD5(IP+服務編號+時間戳+自動序列號）； 其實，上面寫的都是錯的，我壓根沒有做過類似的服務。

轉載于:https://www.cnblogs.com/may-25/p/4871626.html

總結

以上是生活随笔為你收集整理的[转载]从12306谈起验证码的架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。