程序猿對：飛豬IP爬蟲代理分析評測

媒介

跟著年夜數據時代的到來，爬蟲已經當作了獲取數據的必不成少的體例，做過爬蟲的想必都深有體味，爬取的時辰莫名其妙 IP 就被網站封失落了，究竟結果各年夜網站也不想本身的數據被等閑地爬走。

對于爬蟲來說，為領會決封禁 IP 的問題，一個有用的體例就是利用代辦署理，利用代辦署理之后可以讓爬蟲偽裝本身的真實 IP，若是利用年夜量的隨機的代辦署理進行爬取，那么網站就不知道是我們的爬蟲一向在爬取了，如許就有用地解決了反爬的問題。

那么問題來了，利用什么代辦署理好呢？這里指的代辦署理一般是 HTTP 代辦署理，本家兒要用于數據爬取。此刻打開搜刮引擎一搜 HTTP 代辦署理，免費的、付費的太多太多品牌，我們該若何選擇呢？看完這一篇文章，想必你心中就有了謎底。

對于免費代辦署理，其實想都不消想了，可用率能跨越 10% 就已經是謝天謝地了。真正靠譜的代辦署理仍是需要花錢買的，那這么多家到底哪家可用率高？哪家響應速度快？哪家比力不變？哪家性價比比力高？為此，我對市道上比力風行的多家付費代辦署理針對可用率、爬取速度、爬取不變性、價錢、平安性、請求限制等做了具體的評測，讓我們來一路看一下到底哪家更強！

東西/原料

測試對象：以飛豬IP代辦署理為例

測評規模（免費版和付條目費）

1
免費代辦署理
在這里我本家兒要測試的是付費代辦署理，免費代辦署理可用率太低，幾乎不會跨越 10%
2
付費代辦署理
付費代辦署理我以飛豬IP爬蟲代辦署理，進行了評測，采辦了分歧級此外套餐利用同樣的收集情況進行了測評，詳情如

飛豬IP代辦署理評測方針

1
本次測評本家兒要闡發代辦署理的可用率、響應速度、不變性、價錢、平安性、利用頻率等身分，下面我們來一一進行申明。
2
可用率
可用率就是提取的這些代辦署理中可以正常利用的比率。假如我們無法利用這個代辦署理請求某個網站或者拜候超時，那么就代表這個代辦署理不成用，在這里我的測試樣本巨細為 500，即提取 500 個代辦署理，看看里面可用的比率幾多。
3
響應速度
響應速度可以用花費時候來權衡，即計較利用這個代辦署理請求網站一向到獲得響應所花費的時候。時候越短，證實代辦署理的響應速度越快，這里同樣是 500 個樣本，計較時只對正常可用的代辦署理做統計，計較花費時候的平均值。
4
不變性
因為爬蟲時我們需要利用年夜量代辦署理，若是一個代辦署理響應速度出格快，很快就能獲得響應，而下一次請求利用的代辦署理響應速度出格慢，等了三十秒才獲得響應，那勢必會影響爬取效率，所以我們需要看下商家供給的這些代辦署理不變性如何，總不克不及這一個出格快，下一個又慢的不可。所以這里我們需要統計一下花費時候的方差，方差越年夜，證實不變性越差。
5
價錢
價錢，這個當然是需要考慮的內容，若是一個代辦署理非論是響應速度仍是不變性都出格不錯，可是價錢很是很是高，這也是不成接管的。
6
平安性
這簡直也是需要考慮的身分，好比一旦不小心把代辦署理提取的 API 泄露出去了，別人就肆意利用我們的 API 提代替理利用，而一向花費的是我們的套餐。別的一旦別人經由過程某些手段獲取了我們的代辦署理列表，而這些代辦署理是沒有平安驗證的，這也會導致別人偷偷利用我們的代辦署理。在出產情況上，這方面尤其需要注重。
7
利用頻率
有些代辦署理套餐在 API 挪用提代替理時有頻率限制，有的代辦署理套餐則會限制請求頻率，這些身分城市或多或少影響爬蟲的效率，這部門身分我們也需要考慮進來。
8
測評尺度
要做尺度的測評，那就必需在尺度的測評情況下進行，且盡可能解除一些雜項的干擾，如收集波動、傳輸延遲等一系列的影響。
9
本家兒機拔取
因為我的小我筆記本是利用 WiFi 上彀的，所以可能會有收集波動，并且現實帶寬其實并不太好把控，是以它并不適合來做尺度評測利用。評測需要在一個收集不變的前提下進行，并且多個代辦署理的評測情況必需不異，在此我選擇了一臺騰訊云本家兒機作為測試，本家兒機設置裝備擺設如下：
如許我們就可以包管一個尺度同一的測試情況了。
10
現取現測
別的在評測時還需要遵循一個原則，那就是現取現測，即取一個測一個。此刻良多付費代辦署理網站都供給了 API 接口，我們可以一次性提取多個代辦署理，可是如許會導致一個問題，每個代辦署理在提掏出來的時辰，商家是會盡量包管它的可用性的，但過一段時候，這個代辦署理可能就欠好用了，所以假如我們一次性提掏出來了 100 個代辦署理，可是這 100 個代辦署理并沒有同時介入測試，后面的代辦署理就會履歷一個的期待期，過一段時候再測這些代辦署理的話，必定會影響后半部門代辦署理的有用性，所以這里我們將提取的數目同一設置當作 1，即請求一次接口獲取一個代辦署理，然后當即進行測試，如許可以包管測試的公允性，解除了分歧代辦署理有用期的干擾。
11
時候計較
因為我們有一項是測試代辦署理的響應速度，所以我們需要計較法式請求之前和獲得響應之后的時候差，這里我們利用的測試 Python 庫是 requests，所以我們就計較倡議請乞降獲得響應之間的時候差即可，時候計較方式如下所示：
這里 used_time 就是利用代辦署理請求的耗時，如許測試的就僅僅是倡議請求到獲得響應的時候。
12
超時限制
在測試時免不了的會碰到代辦署理請求超時的問題，所以這里我們也需要同一一個超不時間，這里設置為 60 秒，若是利用代辦署理請求百度，60 秒還沒有獲得響應，那就視為該代辦署理無效。
測試數目
要做測評，那么樣本不克不及太小，如只有十幾回測試是不克不及等閑下結論的，這里我拔取了一個適中的測評數目 500，即每個套餐獲取 500 個代辦署理進行測試。
13
測評過程
嗯，測評過程這邊本家兒要說一下測評的代碼邏輯，起首測的時辰是取一個測一個的，所以這里界說了一個 test_proxy() 方式：
14
這里需要傳入一個參數 proxy，代表一個代辦署理，即 IP 加端口構成的代辦署理，然后這里利用了 requests 的 proxies 參數傳遞給 get() 方式。對于代辦署理無效的檢測，這里判定了 ProxyError, ConnectTimeout, SSLError, ReadTimeout, ConnectionError 這幾種異常，若是發生了這些異常十足視為代辦署理無效，返回錯誤。若是在 timeout 60 秒內獲得了響應，那么就計較其花費時候并返回。
在本家兒法式里，就是獲取 API 然后統計成果了，代碼如下：
15
測評得出的結論
用飛豬IP代辦署理，進行收集爬蟲，經由過程利用率很高，響應速度快，并且不變，價錢廉價，平安性也高，值得大師利用，保舉指數5顆星。