爬蟲(Spider)，反爬蟲(Anti-Spider)，反反爬蟲(Anti-Anti-Spider) 之間恢宏壯闊的斗爭...
Day 1
- 小莫想要某站上所有的電影，寫了標準的爬蟲(基于HttpClient庫)，不斷地遍歷某站的電影列表頁面，根據(jù) Html 分析電影名字存進自己的數(shù)據(jù)庫。
- 這個站點的運維小黎發(fā)現(xiàn)某個時間段請求量陡增，分析日志發(fā)現(xiàn)都是 IP(xxx.xxx.xxx.xxx)這個用戶，并且 user-agent 還是 Python-urllib/2.7 ，基于這兩點判斷非人類后直接在服務器上封殺。
Day 2
- 小莫電影只爬了一半，于是也針對性的變換了下策略：1. user-agent 模仿百度("Baiduspider...")，2. IP每爬半個小時就換一個IP代理。
- 小黎也發(fā)現(xiàn)了對應的變化，于是在服務器上設置了一個頻率限制，每分鐘超過120次請求的再屏蔽IP。 同時考慮到百度家的爬蟲有可能會被誤傷，想想市場部門每月幾十萬的投放，于是寫了個腳本，通過 hostname 檢查下這個 ip 是不是真的百度家的，對這些 ip 設置一個白名單。
Day 3
- 小莫發(fā)現(xiàn)了新的限制后，想著我也不急著要這些數(shù)據(jù)，留給服務器慢慢爬吧，于是修改了代碼，隨機1-3秒爬一次，爬10次休息10秒，每天只在8-12，18-20點爬，隔幾天還休息一下。
- 小黎看著新的日志頭都大了，再設定規(guī)則不小心會誤傷真實用戶，于是準備換了一個思路，當3個小時的總請求超過50次的時候彈出一個驗證碼彈框，沒有準確正確輸入的話就把 IP 記錄進黑名單。
Day 4
- 小莫看到驗證碼有些傻臉了，不過也不是沒有辦法，先去學習了圖像識別（關(guān)鍵詞 PIL，tesseract），再對驗證碼進行了二值化，分詞，模式訓練之后，總之最后識別了小黎的驗證碼（關(guān)于驗證碼，驗證碼的識別，驗證碼的反識別也是一個恢弘壯麗的斗爭史...），之后爬蟲又跑了起來。
- 小黎是個不折不撓的好同學，看到驗證碼被攻破后，和開發(fā)同學商量了變化下開發(fā)模式，數(shù)據(jù)并不再直接渲染，而是由前端同學異步獲取，并且通過 JavaScript 的加密庫生成動態(tài)的 token，同時加密庫再進行混淆（比較重要的步驟的確有網(wǎng)站這樣做，參見淘寶和微博的登陸流程）。
Day 5
- 混淆過的加密庫就沒有辦法了么？當然不是，可以慢慢調(diào)試，找到加密原理，不過小莫不準備用這么耗時耗力的方法，他放棄了基于 HttpClient的爬蟲，選擇了內(nèi)置瀏覽器引擎的爬蟲(關(guān)鍵詞：PhantomJS，Selenium)，在瀏覽器引擎運行頁面，直接獲取了正確的結(jié)果，又一次拿到了對方的數(shù)據(jù)。
- 小黎：.....
爬蟲與發(fā)爬蟲的斗爭還在繼續(xù)...
通常情況下，在爬蟲與反爬蟲的對弈中，爬蟲一定會勝利。
換言之，只要人類能夠正常訪問的網(wǎng)頁，爬蟲在具備同等資源的情況下就一定可以抓取到。
關(guān)于爬蟲部分一些建議：
盡量減少請求次數(shù)，能抓列表頁就不抓詳情頁，減輕服務器壓力，程序員都是混口飯吃不容易。
不要只看 Web 網(wǎng)站，還有手機 App 和 H5，這樣的反爬蟲措施一般比較少。
實際應用時候，一般防守方做到根據(jù) IP 限制頻次就結(jié)束了，除非很核心的數(shù)據(jù)，不會再進行更多的驗證，畢竟成本的問題會考慮到。
如果真的對性能要求很高，可以考慮多線程(一些成熟的框架如 Scrapy都已支持)，甚至分布式...
