Python3網絡爬蟲實戰---1八、Session和Cookies

時間 2019-12-09

標籤 python3 python 網絡爬蟲實戰 session cookies 欄目 Python 简体版

原文原文鏈接

上一篇文章： Python3網絡爬蟲實戰---1七、爬蟲基本原理
下一篇文章： Python3網絡爬蟲實戰---1九、代理基本原理

在瀏覽網站的過程當中咱們常常會遇到須要登陸的狀況，有些頁面只有登陸以後咱們才能夠訪問，並且登陸以後能夠連續訪問不少次網站，可是有時候過一段時間就會須要從新登陸。還有一些網站有時在咱們打開瀏覽器的時候就自動登陸了，並且很長的時間都不會失效，這種狀況又是爲何？其實這裏面涉及到 Session 和 Cookies 的相關知識，本節咱們就來揭開它們的神祕面紗。html

1. 靜態網頁和動態網頁

在開始以前咱們須要先了解一下靜態網頁和動態網頁的概念。
仍是前文中的示例代碼，內容以下：數據庫

<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8">
        <title>This is a Demo</title>
    </head>
    <body>
        <div id="container">
            <div class="wrapper">
                <h2 class="title">Hello World</h2>
                <p class="text">Hello, this is a paragraph.</p>
            </div>
        </div>
    </body>
</html>

這是最基本的 HTML 代碼，咱們將其保存爲一個 html 文件，而後把它放在某臺具備固定公網 IP 的主機上，主機上裝上 Apache 或 Nginx 等服務器，這樣這臺主機就能夠做爲服務器了，其餘人即可以經過訪問服務器看到這個頁面了，這就搭建了一個最簡單的網站。
這種網頁的內容是 HTML 代碼編寫的，文字、圖片等內容均是經過寫好的 HTML 代碼來指定的，這種頁面叫作靜態網頁。
這種網頁加載速度快，編寫簡單，可是存在很大的缺陷，如可維護性差，不能根據 URL 靈活多變地顯示內容等，例如咱們想要給這個網頁的 URL 傳入一個 name 參數，讓其在網頁中顯示出來，是沒法作到的。
因此動態網頁應運而生，它能夠動態解析 URL 中參數的變化，關聯數據庫並動態地呈現不一樣的頁面內容，很是靈活多變，咱們如今遇到的大多數網站都是動態網站，它們再也不是一個簡單的 HTML，而是可能由 JSP、PHP、Python 等語言編寫的，功能相比靜態網頁強大和豐富太多太多。
動態網站還能夠實現用戶登陸註冊的功能，再回到開篇提到的問題，不少頁面是須要登陸以後才能夠查看的，按照通常的邏輯來講，咱們輸入用戶名密碼登陸以後，確定是拿到了一種相似憑證的東西，有了它咱們才能保持登陸狀態，才能訪問登陸以後才能看到的頁面。
那麼這種神祕的憑證究竟是什麼呢？其實它就是 Session 和 Cookies 共同產生的結果，下面咱們來一探它們的究竟。segmentfault

2. 無狀態HTTP

在瞭解 Session 和 Cookies 以前，咱們還須要瞭解 HTTP 的一個特色，叫作無狀態。
HTTP 的無狀態是指 HTTP 協議對事務處理是沒有記憶能力的，也就是說服務器不知道客戶端是什麼狀態。當咱們向服務器發送一個 Requset 後，服務器解析此 Request，而後返回對應的 Response，服務器負責完成這個過程，並且這個過程是徹底獨立的，服務器不會記錄先後狀態的變化，也就是缺乏狀態記錄，這意味着若是後續須要處理須要前面的信息，則它必需要重傳，這也致使了須要額外傳遞一些前面的重複 Request 才能獲取後續 Response，然而這種效果顯然不是咱們想要的。爲了保持先後狀態，咱們確定不能將前面的請求所有重傳一次，這太浪費資源了，對於這種須要用戶登陸的頁面來講，更是棘手。
因此，這時候，兩個用於保持 HTTP 鏈接狀態的技術就出現了，它們分別是 Session 和 Cookies，Session 在服務端，也就是網站的服務器，用來保存用戶的會話信息，Cookies 在客戶端，也能夠理解爲瀏覽器端，有了 Cookies，瀏覽器在下次訪問網頁時會自動附帶上它發送給服務器，服務器經過識別 Cookies 並鑑定出是哪一個用戶，而後再判斷用戶是不是登陸狀態，而後返回對應的 Response。
因此咱們能夠理解爲 Cookies 裏面保存了登陸的憑證，有了它咱們只須要在下次請求攜帶 Cookies 發送 Request 而沒必要從新輸入用戶名、密碼等信息從新登陸了。
所以在爬蟲中，有時候處理須要登陸才能訪問的頁面時，咱們通常會直接將登陸成功後獲取的 Cookies 放在 Request Headers 裏面直接請求，而沒必要從新模擬登陸。
好，大致瞭解什麼是 Session 和 Cookies 以後，咱們來詳細剖析一下它們的原理。瀏覽器

2. Session

Session，即會話，其原本的含義是指善始善終的一系列動做/消息，好比打電話時從拿起電話撥號到掛斷電話這中間的一系列過程能夠稱之爲一個 Session。
而在 Web 中 Session 對象用來存儲特定用戶會話所需的屬性及配置信息。這樣，當用戶在應用程序的 Web 頁之間跳轉時，存儲在 Session 對象中的變量將不會丟失，而是在整個用戶會話中一直存在下去。當用戶請求來自應用程序的 Web 頁時，若是該用戶尚未會話，則 Web 服務器將自動建立一個 Session 對象。當會話過時或被放棄後，服務器將終止該會話。安全

3. Cookies

Cookie，有時也用其複數形式 Cookies，指某些網站爲了辨別用戶身份、進行 Session 跟蹤而儲存在用戶本地終端上的數據。服務器

會話維持

那麼利用 Cookies 咱們是怎樣來保持狀態的呢？當客戶端第一次請求服務器時，服務器會返回一個 Headers 中帶有 Set-Cookie 字段的 Response 給客戶端，用來標記是哪個用戶，客戶端瀏覽器會把Cookies 保存起來。當瀏覽器下一次再請求該網站時，瀏覽器會把此Cookies 放到 Request Headers 一塊兒提交給服務器，Cookies 攜帶了 Session ID 信息，服務器檢查該 Cookies 便可找到對應的 Session 是什麼，而後再判斷 Session 來以此來辨認用戶狀態。
因此咱們在登陸某個網站的時候，登陸成功後服務器會告訴客戶端設置哪些 Cookies 信息，在後續訪問頁面時客戶端會把 Cookies 發送給服務器，服務器再找到對應的 Session 加以判斷，若是 Session 中的某些設置登陸狀態的變量是有效的，那就證實用戶是處於登陸狀態的，便可返回登陸以後才能夠查看的網頁內容，瀏覽器進行解析即可以看到了。
反之，若是傳給服務器的 Cookies 是無效的，或者 Session 已通過期了，咱們將不能繼續訪問頁面，可能會收到錯誤的 Response 或者跳轉到登陸頁面從新登陸。
因此 Cookies 和 Session 須要配合，一個處於客戶端，一個處於服務端，兩者共同協做，就實現了登陸會話控制。cookie

屬性結構

接下來咱們來看看 Cookies 都有哪些內容，在這裏以知乎爲例，在瀏覽器開發者工具中打開 Application 選項卡，而後在左側會有一個 Storage 部分，最後一項即爲 Cookies，將其點開，能夠看到相似以下內容，這些就是 Cookies，如圖 2-14 所示：網絡

圖 2-14 Cookies 列表
咱們能夠看到 Cookies 有一個個條目，每一個條目咱們能夠稱之爲 Cookie，取單數形式。它有這麼幾個屬性：session

Name，即該 Cookie 的名稱。Cookie 一旦建立，名稱便不可更改
Value，即該 Cookie 的值。若是值爲 Unicode 字符，須要爲字符編碼。若是值爲二進制數據，則須要使用 BASE64 編碼
。Max Age，即該 Cookie 失效的時間，單位秒，也常和 Expires 一塊兒使用，經過它能夠計算出其有效時間。Max Age 若是爲正數，則該Cookie 在 Max Age 秒以後失效。若是爲負數，則關閉瀏覽器時Cookie 即失效，瀏覽器也不會以任何形式保存該 Cookie。 Path，即該 Cookie 的使用路徑。若是設置爲 /path/，則只有路徑爲 /path/ 的頁面能夠訪問該 Cookie。若是設置爲 /，則本域名下的全部頁面均可以訪問該 Cookie。
Domain，便可以訪問該 Cookie 的域名。例如若是設置爲 .zhihu.com，則全部以 zhihu.com，結尾的域名均可以訪問該Cookie。
Size字段，即此 Cookie 的大小。
Http字段，即 Cookie 的 httponly 屬性。若此屬性爲 true，則只有在 HTTP Headers 中會帶有此 Cookie 的信息，而不能經過 document.cookie 來訪問此 Cookie。
Secure，即該 Cookie 是否僅被使用安全協議傳輸。安全協議。安全協議有 HTTPS，SSL 等，在網絡上傳輸數據以前先將數據加密。默認爲 false。以上即是 Cookies 的基本結構。

會話Cookie、持久Cookie

表面意思來講，會話 Cookie 就是把 Cookie 放在瀏覽器內存裏，瀏覽器在關閉以後該 Cookie 即失效，持久 Cookie 則會保存到客戶端的硬盤中，下次還能夠繼續使用，用於長久保持用戶登陸狀態。
其實嚴格來講沒有會話 Cookie 和持久 Cookie 之分，它只是由 Cookie 的 Max Age 或 Expires 字段決定了過時的時間，經過它瀏覽器能夠計算出其有效時間。Max Age 若是爲正數，則該 Cookie 在 Max Age 秒以後失效，若是 Max Age 特別大，那就會保存很是長的時間。若是爲負數，則關閉瀏覽器時 Cookie 即失效，瀏覽器也不會以任何形式保存該 Cookie。
因此一些持久化登陸的網站其實就是把 Cookie 的有效時間和 Session 有效期設置得比較長，下次咱們再訪問頁面時仍然攜帶以前的 Cookies 就能夠直接保持登陸狀態。app

4. 常見誤區

在談論 Session 機制的時候，經常聽到這樣一種誤解「只要關閉瀏覽器，Session 就消失了」，這種理解是錯誤的，能夠想象一下會員卡的例子，除非顧客主動對店家提出銷卡，不然店家絕對不會輕易刪除顧客的資料。對 Session 來講也是同樣的，除非程序通知服務器刪除一個 Session，不然服務器會一直保留，好比程序通常都是在咱們作註銷操做的時候纔去刪除 Session。
可是當咱們關閉瀏覽器時，瀏覽器不會主動在關閉以前通知服務器它將要關閉，因此服務器根本不會有機會知道瀏覽器已經關閉，之因此會有這種錯覺，是大部分 Session 機制都使用會話 Cookie 來保存 Session ID 信息，而關閉瀏覽器後 Cookies 就消失了，再次鏈接服務器時也就沒法找到原來的 Session。若是服務器設置的 Cookies 被保存到硬盤上，或者使用某種手段改寫瀏覽器發出的 HTTP 請求頭，把原來的 Cookies 發送給服務器，則再次打開瀏覽器仍然可以找到原來的 Session ID，依舊仍是能夠保持登陸狀態的。
並且偏偏是因爲關閉瀏覽器不會致使 Session 被刪除，這就須要服務器爲 Seesion 設置一個失效時間，當距離客戶端上一次使用 Session 的時間超過這個失效時間時，服務器就能夠認爲客戶端已經中止了活動，纔會把 Session 刪除以節省存儲空間。