關(guān)于requests里的timeout()用法

timeout(超時)

首先是：為防止服務(wù)器不能及時響應(yīng)，大部分發(fā)至外部服務(wù)器的請求都應(yīng)該帶著 timeout 參數(shù)。在默認(rèn)情況下，除非顯式指定了 timeout 值，requests 是不會自動進(jìn)行超時處理的。如果沒有 timeout，你的代碼可能會掛起若干分鐘甚至更長時間

其次是：連接超時指的是在你的客戶端實現(xiàn)到遠(yuǎn)端機(jī)器端口的連接時（對應(yīng)的是 connect() ），Request 會等待的秒數(shù)。一個很好的實踐方法是把連接超時設(shè)為比 3 的倍數(shù)略大的一個數(shù)值，因為 TCP 數(shù)據(jù)包重傳窗口 (TCP packet retransmission window) 的默認(rèn)大小是 3。

在爬蟲代理這一塊我們經(jīng)常會遇到請求超時的問題，代碼就卡在哪里，不報錯也沒有requests請求的響應(yīng)。

通常的處理是在requests.get()語句中加入timeout限制請求時間

req = requests.get(url, headers=headers, proxies=proxies, timeout=5)

如果發(fā)現(xiàn)設(shè)置timeout=5后長時間不響應(yīng)問題依然存在，可以將timeout里的參數(shù)細(xì)化

作出如下修改后，問題就消失了

req = requests.get(url, headers=headers, proxies=proxies, timeout=(3,7))

python requests timeout 分析

最近在搞爬蟲，很多小組件里面都使用了 Python 的 requests 庫，很好用，很強(qiáng)大。

但最近發(fā)現(xiàn)很多任務(wù)總是莫名其妙的卡住，不報錯，但是就是不繼續(xù)執(zhí)行。

排查了一圈，最后把問題鎖定在 requests 的 timeout 機(jī)制上。

注：

本文討論的是 Python 的第三方模塊 requests ，并不是 Python 內(nèi)建模塊 urllib 中的 request 模塊，請注意區(qū)分。

如何設(shè)置超時時間

requests 設(shè)置超時時間有兩種方式。

一種是設(shè)置單一值作為 timeout，如下所示：

r = requests.get('https://github.com', timeout=5)

這時， timeout 值將會用作 connect 和 read 二者的共同的超時時間。

另一種是分別制定連接超時和讀取超時的時間，如下所示：

r = requests.get('https://github.com', timeout=(3.05, 27))

這里前面的 3.05 表示連接超時時間， 27 表示讀取超時時間。

官方一般推薦大家把連接超時時間設(shè)置為比 3 的整數(shù)倍稍微大一點的時間，比如 3.05 、 6.05 這樣。

坑

上面提到的兩種超時時間，連接超時和讀取超時，并不是都有默認(rèn)超時時間。

連接超時的默認(rèn)時間是 21s ，而讀取超時沒有默認(rèn)時間，換句話說，不會超時。

也就是說，如果一個請求，連接成功了，正在讀取數(shù)據(jù)，但是此時服務(wù)器出現(xiàn)了什么問題，或者代理出現(xiàn)了什么問題，那么，這個請求就會一直卡住，不會報錯，也不會繼續(xù)。

天長地久。

避坑

所以，為了避免出現(xiàn)這樣的情況，給你的 requests 加上超時時間吧，尤其是請求量巨大的時候。

常在河邊走，哪有不濕鞋。

參考資料 Requests 官方文檔

總結(jié)

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論