小白學 Python 爬蟲（10）：Session 和 Cookies

靜態網頁就是咱們上一篇寫的那種 html 頁面，後綴爲 .html 的這種文件，直接部署到或者是放到某個 web 容器上，就能夠在瀏覽器經過連接直接訪問到了，經常使用的 web 容器有 Nginx 、 Apache 、 Tomcat 、Weblogic 、 Jboss 、 Resin 等等，不少不少。

若是說要舉例子的話那麼小編的我的博客站：https://www.geekdigging.com/ 就是一個純粹的靜態網頁。

這種網頁的內容是經過純粹的 HTML 代碼來書寫，包括一些資源文件：圖片、視頻等內容的引入都是使用 HTML 標籤來完成的。

它的好處固然是加載速度快，編寫簡單，訪問的時候對 web 容器基本上不會產生什麼壓力。可是缺點也很明顯，可維護性比較差，不能根據參數動態的顯示內容等等。

有需求就會有發展麼，這時動態網頁就應運而生了。

動態網頁

咱們先不說動態網頁的概念，先說說有哪些網站是由動態網頁來構建的。你們經常使用的某寶、某東、拼夕夕等網站都是由動態網頁組成的。

動態網頁能夠解析 URL 中的參數，或者是關聯數據庫中的數據，顯示不一樣的網頁內容。

如今各位同窗訪問的網站大多數都是動態網站，它們再也不簡簡單單是由 HTML 堆砌而成，多是由 JSP 、 PHP 等語言編寫的，固然，如今不少由前端框架編寫而成的網頁小編這裏也歸屬爲動態網頁。

說到動態網頁，各位同窗可能使用頻率最高的一個功能是登陸，像各類電商類網站，確定是登陸了之後才能下單買東西。那麼，問題來了，後面的服務端是如何知道當前這我的已經登陸了呢？

HTTP/1.1

如今大多數的網站使用的協議都是 HTTP/1.1 ，而 HTTP/1.1 最大的特色就是無狀態、無鏈接的。

無狀態就是指 HTTP 協議對於請求的發送處理是沒有記憶功能的，也就是說每次 HTTP 請求到達服務端，服務端都不知道當前的客戶端（瀏覽器）究竟是一個什麼狀態。客戶端向服務端發送請求後，服務端處理這個請求，而後將內容響應回客戶端，完成一次交互，這個過程是徹底相互獨立的，服務端不會記錄先後的狀態變化，也就是缺乏狀態記錄。

這就產生了上面的問題，服務端如何知道當前在瀏覽器面前操做的這我的是誰？

其實，在用戶作登陸操做的時候，服務端會下發一個相似於 token 憑證的東西返回至客戶端（瀏覽器），有了這個憑證，才能保持登陸狀態。

那麼這個憑證是什麼？

這就是本篇文章要解釋的核心內容，Session 和 Cookies 了。

Session 是會話的意思，會話是產生在服務端的，用來保存當前用戶的會話信息，而 Cookies 是保存在客戶端（瀏覽器），有了 Cookie 之後，客戶端（瀏覽器）再次訪問服務端的時候，會將這個 Cookie 帶上，這時，服務端能夠經過 Cookie 來識別本次請求究竟是誰在訪問。

能夠簡單理解爲 Cookies 中保存了登陸憑證，咱們只要持有這個憑證，就能夠在服務端保持一個登陸狀態。

在爬蟲中，有時候遇到須要登陸才能訪問的網頁，只須要在登陸後獲取了 Cookies ，在下次訪問的時候將登陸後獲取到的 Cookies 放在請求頭中，這時，服務端就會認爲咱們的爬蟲是一個正常登陸用戶。

Session 保持

那麼，Cookies 是如何保持會話狀態的呢？

在客戶端（瀏覽器）第一次請求服務端的時候，服務端會返回一個請求頭中帶有 Set-Cookie 字段的響應給客戶端（瀏覽器），用來標記是哪個用戶，客戶端（瀏覽器）會把這個 Cookies 給保存起來。

咱們來使用工具 PostMan 來訪問下某東的登陸頁，看下返回的響應頭：

當咱們輸入好用戶名和密碼時，客戶端會將這個 Cookies 放在請求頭一塊兒發送給服務端，這時，服務端就知道是誰在進行登陸操做，而且能夠判斷這我的輸入的用戶名和密碼對不對，若是輸入正確，則在服務端的 Session 記錄一下這我的已經登陸成功了，下次再請求的時候這我的就是登陸狀態了。

若是客戶端傳給服務端的 Cookies 是無效的，或者這個 Cookies 根本不是由這個服務端下發的，或者這個 Cookies 已通過期了，那麼接下里的請求將再也不能訪問須要登陸後才能訪問的頁面。

因此， Session 和 Cookies 之間是須要相互配合的，一個在服務端，一個在客戶端。

Cookies

咱們仍是打開某東的網站，看下這些 Cookies到底有哪些內容：

具體操做方式仍是在 Chrome 中按 F12 打開開發者工具，選擇 Application 標籤，點開 Cookies 這一欄。

Name：這個是 Cookie 的名字。一旦建立，該名稱便不可更改。
Value：這個是 Cookie 的值。
Domain：這個是能夠訪問該 Cookie 的域名。例如，若是設置爲 .jd.com ，則全部以 jd.com ，結尾的域名均可以訪問該Cookie。
Max Age：Cookie 失效的時間，單位爲秒，也常和 Expires 一塊兒使用。 Max Age 若是爲正數，則在 Max Age 秒以後失效，若是爲負數，則關閉瀏覽器時 Cookie 即失效，瀏覽器也不會保存該 Cookie 。
Path：Cookie 的使用路徑。若是設置爲 /path/ ，則只有路徑爲 /path/ 的頁面能夠訪問該 Cookie 。若是設置爲 / ，則本域名下的全部頁面均可以訪問該 Cookie 。
Size：Cookie 的大小。
HTTPOnly：若是此項打勾，那麼經過 JS 腳本將沒法讀取到 Cookie 信息，這樣能有效的防止 XSS 攻擊，竊取 Cookie 內容，能夠增長 Cookie 的安全性。
Secure：若是此項打勾，那麼這個 Cookie 只能用 HTTPS 協議發送給服務器，用 HTTP 協議是不發送的。

那麼有的網站爲何此次關閉了，下次打開的時候仍是登陸狀態呢？

這就要說到 Cookie 的持久化了，其實也不能說是持久化，就是 Cookie 失效的時間設置的長一點，好比直接設置到 2099 年失效，這樣，在瀏覽器關閉後，這個 Cookie 是會保存在咱們的硬盤中的，下次打開瀏覽器，會再從咱們的硬盤中將這個 Cookie 讀取出來，用來維持用戶的會話狀態。

第二個問題產生了，服務端的會話也會無限的維持下去麼，固然不會，這就要在 Cookie 和 Session 上作文章了， Cookie 中可使用加密的方式將用戶名記錄下來，在下次將 Cookies 讀取出來由請求發送到服務端後，服務端悄悄的本身建立一個用戶已經登陸的會話，這樣咱們在客戶端看起來就好像這個登陸會話是一直保持的。