摘要：而在中對象用來存儲特定用戶會話所需的屬性及配置信息。當會話過期或被放棄后，服務器將終止該會話。，即該是否僅被使用安全協(xié)議傳輸。安全協(xié)議有，等，在網(wǎng)絡上傳輸數(shù)據(jù)之前先將數(shù)據(jù)加密。

上一篇文章：Python3網(wǎng)絡爬蟲實戰(zhàn)---17、爬蟲基本原理
下一篇文章：Python3網(wǎng)絡爬蟲實戰(zhàn)---19、代理基本原理

在瀏覽網(wǎng)站的過程中我們經常會遇到需要登錄的情況，有些頁面只有登錄之后我們才可以訪問，而且登錄之后可以連續(xù)訪問很多次網(wǎng)站，但是有時候過一段時間就會需要重新登錄。還有一些網(wǎng)站有時在我們打開瀏覽器的時候就自動登錄了，而且很長的時間都不會失效，這種情況又是為什么？其實這里面涉及到 Session 和 Cookies 的相關知識，本節(jié)我們就來揭開它們的神秘面紗。

在開始之前我們需要先了解一下靜態(tài)網(wǎng)頁和動態(tài)網(wǎng)頁的概念。
還是前文中的示例代碼，內容如下：

    
        
        
    
    
        

            

                
Hello World
                
Hello, this is a paragraph.
            
        
    

這是最基本的 HTML 代碼，我們將其保存為一個 html 文件，然后把它放在某臺具有固定公網(wǎng) IP 的主機上，主機上裝上 Apache 或 Nginx 等服務器，這樣這臺主機就可以作為服務器了，其他人便可以通過訪問服務器看到這個頁面了，這就搭建了一個最簡單的網(wǎng)站。
這種網(wǎng)頁的內容是 HTML 代碼編寫的，文字、圖片等內容均是通過寫好的 HTML 代碼來指定的，這種頁面叫做靜態(tài)網(wǎng)頁。
這種網(wǎng)頁加載速度快，編寫簡單，但是存在很大的缺陷，如可維護性差，不能根據(jù) URL 靈活多變地顯示內容等，例如我們想要給這個網(wǎng)頁的 URL 傳入一個 name 參數(shù)，讓其在網(wǎng)頁中顯示出來，是無法做到的。
所以動態(tài)網(wǎng)頁應運而生，它可以動態(tài)解析 URL 中參數(shù)的變化，關聯(lián)數(shù)據(jù)庫并動態(tài)地呈現(xiàn)不同的頁面內容，非常靈活多變，我們現(xiàn)在遇到的大多數(shù)網(wǎng)站都是動態(tài)網(wǎng)站，它們不再是一個簡單的 HTML，而是可能由 JSP、PHP、Python 等語言編寫的，功能相比靜態(tài)網(wǎng)頁強大和豐富太多太多。
動態(tài)網(wǎng)站還可以實現(xiàn)用戶登錄注冊的功能，再回到開篇提到的問題，很多頁面是需要登錄之后才可以查看的，按照一般的邏輯來說，我們輸入用戶名密碼登錄之后，肯定是拿到了一種類似憑證的東西，有了它我們才能保持登錄狀態(tài)，才能訪問登錄之后才能看到的頁面。
那么這種神秘的憑證到底是什么呢？其實它就是 Session 和 Cookies 共同產生的結果，下面我們來一探它們的究竟。

在了解 Session 和 Cookies 之前，我們還需要了解 HTTP 的一個特點，叫做無狀態(tài)。
HTTP 的無狀態(tài)是指 HTTP 協(xié)議對事務處理是沒有記憶能力的，也就是說服務器不知道客戶端是什么狀態(tài)。當我們向服務器發(fā)送一個 Requset 后，服務器解析此 Request，然后返回對應的 Response，服務器負責完成這個過程，而且這個過程是完全獨立的，服務器不會記錄前后狀態(tài)的變化，也就是缺少狀態(tài)記錄，這意味著如果后續(xù)需要處理需要前面的信息，則它必須要重傳，這也導致了需要額外傳遞一些前面的重復 Request 才能獲取后續(xù) Response，然而這種效果顯然不是我們想要的。為了保持前后狀態(tài)，我們肯定不能將前面的請求全部重傳一次，這太浪費資源了，對于這種需要用戶登錄的頁面來說，更是棘手。
所以，這時候，兩個用于保持 HTTP 連接狀態(tài)的技術就出現(xiàn)了，它們分別是 Session 和 Cookies，Session 在服務端，也就是網(wǎng)站的服務器，用來保存用戶的會話信息，Cookies 在客戶端，也可以理解為瀏覽器端，有了 Cookies，瀏覽器在下次訪問網(wǎng)頁時會自動附帶上它發(fā)送給服務器，服務器通過識別 Cookies 并鑒定出是哪個用戶，然后再判斷用戶是否是登錄狀態(tài)，然后返回對應的 Response。
所以我們可以理解為 Cookies 里面保存了登錄的憑證，有了它我們只需要在下次請求攜帶 Cookies 發(fā)送 Request 而不必重新輸入用戶名、密碼等信息重新登錄了。
因此在爬蟲中，有時候處理需要登錄才能訪問的頁面時，我們一般會直接將登錄成功后獲取的 Cookies 放在 Request Headers 里面直接請求，而不必重新模擬登錄。
好，大體了解什么是 Session 和 Cookies 之后，我們來詳細剖析一下它們的原理。

Session，即會話，其本來的含義是指有始有終的一系列動作/消息，比如打電話時從拿起電話撥號到掛斷電話這中間的一系列過程可以稱之為一個 Session。
而在 Web 中 Session 對象用來存儲特定用戶會話所需的屬性及配置信息。這樣，當用戶在應用程序的 Web 頁之間跳轉時，存儲在 Session 對象中的變量將不會丟失，而是在整個用戶會話中一直存在下去。當用戶請求來自應用程序的 Web 頁時，如果該用戶還沒有會話，則 Web 服務器將自動創(chuàng)建一個 Session 對象。當會話過期或被放棄后，服務器將終止該會話。

Cookie，有時也用其復數(shù)形式 Cookies，指某些網(wǎng)站為了辨別用戶身份、進行 Session 跟蹤而儲存在用戶本地終端上的數(shù)據(jù)。

那么利用 Cookies 我們是怎樣來保持狀態(tài)的呢？當客戶端第一次請求服務器時，服務器會返回一個 Headers 中帶有 Set-Cookie 字段的 Response 給客戶端，用來標記是哪一個用戶，客戶端瀏覽器會把Cookies 保存起來。當瀏覽器下一次再請求該網(wǎng)站時，瀏覽器會把此Cookies 放到 Request Headers 一起提交給服務器，Cookies 攜帶了 Session ID 信息，服務器檢查該 Cookies 即可找到對應的 Session 是什么，然后再判斷 Session 來以此來辨認用戶狀態(tài)。
所以我們在登錄某個網(wǎng)站的時候，登錄成功后服務器會告訴客戶端設置哪些 Cookies 信息，在后續(xù)訪問頁面時客戶端會把 Cookies 發(fā)送給服務器，服務器再找到對應的 Session 加以判斷，如果 Session 中的某些設置登錄狀態(tài)的變量是有效的，那就證明用戶是處于登錄狀態(tài)的，即可返回登錄之后才可以查看的網(wǎng)頁內容，瀏覽器進行解析便可以看到了。
反之，如果傳給服務器的 Cookies 是無效的，或者 Session 已經過期了，我們將不能繼續(xù)訪問頁面，可能會收到錯誤的 Response 或者跳轉到登錄頁面重新登錄。
所以 Cookies 和 Session 需要配合，一個處于客戶端，一個處于服務端，二者共同協(xié)作，就實現(xiàn)了登錄會話控制。

接下來我們來看看 Cookies 都有哪些內容，在這里以知乎為例，在瀏覽器開發(fā)者工具中打開 Application 選項卡，然后在左側會有一個 Storage 部分，最后一項即為 Cookies，將其點開，可以看到類似如下內容，這些就是 Cookies，如圖 2-14 所示：

圖 2-14 Cookies 列表
我們可以看到 Cookies 有一個個條目，每個條目我們可以稱之為 Cookie，取單數(shù)形式。它有這么幾個屬性：

Name，即該 Cookie 的名稱。Cookie 一旦創(chuàng)建，名稱便不可更改

Value，即該 Cookie 的值。如果值為 Unicode 字符，需要為字符編碼。如果值為二進制數(shù)據(jù)，則需要使用 BASE64 編碼

。Max Age，即該 Cookie 失效的時間，單位秒，也常和 Expires 一起使用，通過它可以計算出其有效時間。Max Age 如果為正數(shù)，則該Cookie 在 Max Age 秒之后失效。如果為負數(shù)，則關閉瀏覽器時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 是否僅被使用安全協(xié)議傳輸。安全協(xié)議。安全協(xié)議有 HTTPS，SSL 等，在網(wǎng)絡上傳輸數(shù)據(jù)之前先將數(shù)據(jù)加密。默認為 false。以上便是 Cookies 的基本結構。

表面意思來說，會話 Cookie 就是把 Cookie 放在瀏覽器內存里，瀏覽器在關閉之后該 Cookie 即失效，持久 Cookie 則會保存到客戶端的硬盤中，下次還可以繼續(xù)使用，用于長久保持用戶登錄狀態(tài)。
其實嚴格來說沒有會話 Cookie 和持久 Cookie 之分，它只是由 Cookie 的 Max Age 或 Expires 字段決定了過期的時間，通過它瀏覽器可以計算出其有效時間。Max Age 如果為正數(shù)，則該 Cookie 在 Max Age 秒之后失效，如果 Max Age 特別大，那就會保存非常長的時間。如果為負數(shù)，則關閉瀏覽器時 Cookie 即失效，瀏覽器也不會以任何形式保存該 Cookie。
所以一些持久化登錄的網(wǎng)站其實就是把 Cookie 的有效時間和 Session 有效期設置得比較長，下次我們再訪問頁面時仍然攜帶之前的 Cookies 就可以直接保持登錄狀態(tài)。

在談論 Session 機制的時候，常常聽到這樣一種誤解“只要關閉瀏覽器，Session 就消失了”，這種理解是錯誤的，可以想象一下會員卡的例子，除非顧客主動對店家提出銷卡，否則店家絕對不會輕易刪除顧客的資料。對 Session 來說也是一樣的，除非程序通知服務器刪除一個 Session，否則服務器會一直保留，比如程序一般都是在我們做注銷操作的時候才去刪除 Session。
但是當我們關閉瀏覽器時，瀏覽器不會主動在關閉之前通知服務器它將要關閉，所以服務器根本不會有機會知道瀏覽器已經關閉，之所以會有這種錯覺，是大部分 Session 機制都使用會話 Cookie 來保存 Session ID 信息，而關閉瀏覽器后 Cookies 就消失了，再次連接服務器時也就無法找到原來的 Session。如果服務器設置的 Cookies 被保存到硬盤上，或者使用某種手段改寫瀏覽器發(fā)出的 HTTP 請求頭，把原來的 Cookies 發(fā)送給服務器，則再次打開瀏覽器仍然能夠找到原來的 Session ID，依舊還是可以保持登錄狀態(tài)的。
而且恰恰是由于關閉瀏覽器不會導致 Session 被刪除，這就需要服務器為 Seesion 設置一個失效時間，當距離客戶端上一次使用 Session 的時間超過這個失效時間時，服務器就可以認為客戶端已經停止了活動，才會把 Session 刪除以節(jié)省存儲空間。

由于涉及到一些專業(yè)名詞知識，本節(jié)的部分內容參考來源如下：

Session 百度百科：https://baike.baidu.com/item/...

百度百科：https://baike.baidu.com/item/...

Cookie 維基百科：https://en.wikipedia.org/wiki...

Session和幾種狀態(tài)保持方案理解：http://www.mamicode.com/info-...

本節(jié)介紹了 Session 和 Cookies 的基本知識，后面我們可能會需要爬取一些需要登錄才可以訪問的頁面，這里就需要用到 Cookies 的相關知識，因此本節(jié)的內容同樣需要好好掌握。

上一篇文章：Python3網(wǎng)絡爬蟲實戰(zhàn)---17、爬蟲基本原理
下一篇文章：Python3網(wǎng)絡爬蟲實戰(zhàn)---19、代理基本原理