反爬蟲的極致手段，幾行代碼直接炸了爬蟲服務器

大家好，我是 kuls。

作爲一個站長，你是不是對爬蟲不勝其煩？爬蟲天天來爬，速度又快，頻率又高，服務器的大量資源被白白浪費。

看這篇文章的你有福了，我們今天一起來報復一下爬蟲，直接把爬蟲的服務器給乾死機。

本文有一個前提：你已經知道某個請求是爬蟲發來的了，你不滿足於單單屏蔽對方，而是想搞死對方。

很多人的爬蟲是使用 Requests 來寫的，如果你閱讀過 Requests 的文檔，那麼你可能在文檔中的 Binary Response Content[1] 這一小節，看到這樣一句話：

The gzip and deflate transfer-encodings are automatically decoded for you.
（Request）會自動爲你把 gzip 和 deflate 轉碼後的數據進行解碼

網站服務器可能會使用gzip壓縮一些大資源，這些資源在網絡上傳輸的時候，是壓縮後的二進制格式。客戶端收到返回以後，如果發現返回的 Headers 裏面有一個字段叫做Content-Encoding，其中的值包含gzip，那麼客戶端就會先使用gzip對數據進行解壓，解壓完成以後再把它呈現到客戶端上面。瀏覽器自動就會做這個事情，用戶是感知不到這個事情發生的。而requests、Scrapy這種網絡請求庫或者爬蟲框架，也會幫你做這個事情，因此你不需要手動對網站返回的數據解壓縮。

這個功能原本是一個方便開發者的功能，但我們可以利用這個功能來做報復爬蟲的事情。

我們首先寫一個客戶端，來測試一下返回gzip壓縮數據的方法。

我首先在硬盤上創建一個文本文件text.txt，裏面有兩行內容，如下圖所示：

然後，我是用gzip命令把它壓縮成一個.gz文件：

cat text.txt | gzip > data.gz

接下來，我們使用 FastAPI 寫一個 HTTP 服務器server.py：

from fastapi import FastAPI, Response
from fastapi.responses import FileResponse


app = FastAPI()


@app.get('/')
def index():
    resp = FileResponse('data.gz')
    return resp

然後使用命令uvicorn server:app啓動這個服務。

接下來，我們使用 requests 來請求這個接口，會發現返回的數據是亂碼，如下圖所示：

返回的數據是亂碼，這是因爲服務器沒有告訴客戶端，這個數據是gzip壓縮的，因此客戶端只有原樣展示。由於壓縮後的數據是二進制內容，強行轉成字符串就會變成亂碼。

現在，我們稍微修改一下server.py的代碼，通過 Headers 告訴客戶端，這個數據是經過gzip壓縮的：

from fastapi import FastAPI, Response
from fastapi.responses import FileResponse


app = FastAPI()


@app.get('/')
def index():
    resp = FileResponse('data.gz')
    resp.headers['Content-Encoding'] = 'gzip'  # 說明這是gzip壓縮的數據
    return resp

修改以後，重新啓動服務器，再次使用 requests 請求，發現已經可以正常顯示數據了：

這個功能已經展示完了，那麼我們怎麼利用它呢？這就不得不提到壓縮文件的原理了。

文件之所以能壓縮，是因爲裏面有大量重複的元素，這些元素可以通過一種更簡單的方式來表示。壓縮的算法有很多種，其中最常見的一種方式，我們用一個例子來解釋。假設有一個字符串，它長成下面這樣：

1111111111111111
1111111111111111
1111111111111111
1111111111111111
1111111111111111
1111111111111111
1111111111111111
1111111111111111
1111111111111111
1111111111111111
1111111111111111
1111111111111111

我們可以用 5 個字符來表示：192個1。這就相當於把 192 個字符壓縮成了 5 個字符，壓縮率高達 97.4%。

如果我們可以把一個 1GB 的文件壓縮成 1MB，那麼對服務器來說，僅僅是返回了 1MB 的二進制數據，不會造成任何影響。但是對客戶端或者爬蟲來說，它拿到這個 1MB 的數據以後，就會在內存中把它還原成 1GB 的內容。這樣一瞬間爬蟲佔用的內存就增大了 1GB。如果我們再進一步增大這個原始數據，那麼很容易就可以把爬蟲所在的服務器內存全部沾滿，輕者服務器直接殺死爬蟲進程，重則爬蟲服務器直接死機。

你別以爲這個壓縮比聽起來很誇張，其實我們使用很簡單的一行命令就可以生成這樣的壓縮文件。

如果你用的是 Linux，那麼請執行命令：

dd if=/dev/zero bs=1M count=1000 | gzip > boom.gz

如果你的電腦是 macOS，那麼請執行命令：

dd if=/dev/zero bs=1048576 count=1000 | gzip > boom.gz

執行過程如下圖所示：

生成的這個boom.gz文件只有 995KB。但是如果我們使用gzip -d boom.gz對這個文件解壓縮，就會發現生成了一個 1GB 的boom文件，如下圖所示：

只要大家把命令裏面的count=1000改成一個更大的數字，就能得到更大的文件。

我現在把count改成10，給大家做一個演示（不敢用 1GB 的數據來做測試，害怕我的 Jupyter 崩潰）。生成的boom.gz文件只有 10KB：

服務器返回一個 10KB 的二進制數據，沒有任何問題。

現在我們用 requests 去請求這個接口，然後查看一下resp這個對象佔用的內存大小：

可以看到，由於 requests 自動會對返回的數據解壓縮，因此最終獲得的 resp 對象竟然有 10MB 這麼大。

如果大家想使用這個方法，一定要先確定這個請求是爬蟲發的，再使用。否則被你乾死的不是爬蟲而是真實用戶就麻煩了。

本文的寫作過程中，參考了文章網站 gzip 炸彈 – 王春偉的技術博客 [2]，特別感謝原作者。

參考文獻

[1] Binary Response Content: https://2.python-requests.org/en/master/user/quickstart/#binary-response-content

[2] 網站 gzip 炸彈 – 王春偉的技術博客: http://da.dadaaierer.com/?p=577

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/ynyVEqTcFy2EW8In3dDQ4g