人生苦短，我用 Python
前文傳送門(mén)：
小白學(xué) Python 爬蟲(chóng)（1）：開(kāi)篇
小白學(xué) Python 爬蟲(chóng)（2）：前置準備（一）基本類(lèi)庫的安裝
小白學(xué) Python 爬蟲(chóng)（3）：前置準備（二）Linux基礎入門(mén)
小白學(xué) Python 爬蟲(chóng)（4）：前置準備（三）Docker基礎入門(mén)
小白學(xué) Python 爬蟲(chóng)（5）：前置準備（四）數據庫基礎
小白學(xué) Python 爬蟲(chóng)（6）：前置準備（五）爬蟲(chóng)框架的安裝
小白學(xué) Python 爬蟲(chóng)（7）：HTTP 基礎
小白學(xué) Python 爬蟲(chóng)（8）：網(wǎng)頁(yè)基礎
小白學(xué) Python 爬蟲(chóng)（9）：爬蟲(chóng)基礎
先說(shuō)一個(gè)題外話(huà)，今天老司機翻車(chē)了，內容小編今天來(lái)不及寫(xiě)了，后面會(huì )整理下，分享給大家。
在介紹 Session 和 Cookies 之前，先介紹一個(gè)另外的概念 —— 靜態(tài)網(wǎng)頁(yè)和動(dòng)態(tài)網(wǎng)頁(yè)。
靜態(tài)網(wǎng)頁(yè)就是我們上一篇寫(xiě)的那種 html 頁(yè)面，后綴為 .html 的這種文件，直接部署到或者是放到某個(gè) web 容器上，就可以在瀏覽器通過(guò)鏈接直接訪(fǎng)問(wèn)到了，常用的 web 容器有 Nginx 、 Apache 、 Tomcat 、Weblogic 、 Jboss 、 Resin 等等，很多很多。
如果說(shuō)要舉例子的話(huà)那么小編的個(gè)人博客站：https://www.geekdigging.com/ 就是一個(gè)純粹的靜態(tài)網(wǎng)頁(yè)。
這種網(wǎng)頁(yè)的內容是通過(guò)純粹的 HTML 代碼來(lái)書(shū)寫(xiě)，包括一些資源文件：圖片、視頻等內容的引入都是使用 HTML 標簽來(lái)完成的。
它的好處當然是加載速度快，編寫(xiě)簡(jiǎn)單，訪(fǎng)問(wèn)的時(shí)候對 web 容器基本上不會(huì )產(chǎn)生什么壓力。但是缺點(diǎn)也很明顯，可維護性比較差，不能根據參數動(dòng)態(tài)的顯示內容等等。
有需求就會(huì )有發(fā)展么，這時(shí)動(dòng)態(tài)網(wǎng)頁(yè)就應運而生了。
我們先不說(shuō)動(dòng)態(tài)網(wǎng)頁(yè)的概念，先說(shuō)說(shuō)有哪些網(wǎng)站是由動(dòng)態(tài)網(wǎng)頁(yè)來(lái)構建的。大家常用的某寶、某東、拼夕夕等網(wǎng)站都是由動(dòng)態(tài)網(wǎng)頁(yè)組成的。
動(dòng)態(tài)網(wǎng)頁(yè)可以解析 URL 中的參數，或者是關(guān)聯(lián)數據庫中的數據，顯示不同的網(wǎng)頁(yè)內容。
現在各位同學(xué)訪(fǎng)問(wèn)的網(wǎng)站大多數都是動(dòng)態(tài)網(wǎng)站，它們不再簡(jiǎn)簡(jiǎn)單單是由 HTML 堆砌而成，可能是由 JSP 、 PHP 等語(yǔ)言編寫(xiě)的，當然，現在很多由前端框架編寫(xiě)而成的網(wǎng)頁(yè)小編這里也歸屬為動(dòng)態(tài)網(wǎng)頁(yè)。
說(shuō)到動(dòng)態(tài)網(wǎng)頁(yè)，各位同學(xué)可能使用頻率最高的一個(gè)功能是登錄，像各種電商類(lèi)網(wǎng)站，肯定是登錄了以后才能下單買(mǎi)東西。那么，問(wèn)題來(lái)了，后面的服務(wù)端是如何知道當前這個(gè)人已經(jīng)登錄了呢？
現在大多數的網(wǎng)站使用的協(xié)議都是 HTTP/1.1 ，而 HTTP/1.1 最大的特點(diǎn)就是無(wú)狀態(tài)、無(wú)連接的。
無(wú)狀態(tài)就是指 HTTP 協(xié)議對于請求的發(fā)送處理是沒(méi)有記憶功能的，也就是說(shuō)每次 HTTP 請求到達服務(wù)端，服務(wù)端都不知道當前的客戶(hù)端（瀏覽器）到底是一個(gè)什么狀態(tài)?？蛻?hù)端向服務(wù)端發(fā)送請求后，服務(wù)端處理這個(gè)請求，然后將內容響應回客戶(hù)端，完成一次交互，這個(gè)過(guò)程是完全相互獨立的，服務(wù)端不會(huì )記錄前后的狀態(tài)變化，也就是缺少狀態(tài)記錄。
這就產(chǎn)生了上面的問(wèn)題，服務(wù)端如何知道當前在瀏覽器面前操作的這個(gè)人是誰(shuí)？
其實(shí)，在用戶(hù)做登錄操作的時(shí)候，服務(wù)端會(huì )下發(fā)一個(gè)類(lèi)似于 token 憑證的東西返回至客戶(hù)端（瀏覽器），有了這個(gè)憑證，才能保持登錄狀態(tài)。
那么這個(gè)憑證是什么？
這就是本篇文章要解釋的核心內容，Session 和 Cookies 了。
Session 是會(huì )話(huà)的意思，會(huì )話(huà)是產(chǎn)生在服務(wù)端的，用來(lái)保存當前用戶(hù)的會(huì )話(huà)信息，而 Cookies 是保存在客戶(hù)端（瀏覽器），有了 Cookie 以后，客戶(hù)端（瀏覽器）再次訪(fǎng)問(wèn)服務(wù)端的時(shí)候，會(huì )將這個(gè) Cookie 帶上，這時(shí)，服務(wù)端可以通過(guò) Cookie 來(lái)識別本次請求到底是誰(shuí)在訪(fǎng)問(wèn)。
可以簡(jiǎn)單理解為 Cookies 中保存了登錄憑證，我們只要持有這個(gè)憑證，就可以在服務(wù)端保持一個(gè)登錄狀態(tài)。
在爬蟲(chóng)中，有時(shí)候遇到需要登錄才能訪(fǎng)問(wèn)的網(wǎng)頁(yè)，只需要在登錄后獲取了 Cookies ，在下次訪(fǎng)問(wèn)的時(shí)候將登錄后獲取到的 Cookies 放在請求頭中，這時(shí)，服務(wù)端就會(huì )認為我們的爬蟲(chóng)是一個(gè)正常登錄用戶(hù)。
那么，Cookies 是如何保持會(huì )話(huà)狀態(tài)的呢？
在客戶(hù)端（瀏覽器）第一次請求服務(wù)端的時(shí)候，服務(wù)端會(huì )返回一個(gè)請求頭中帶有 Set-Cookie 字段的響應給客戶(hù)端（瀏覽器），用來(lái)標記是哪一個(gè)用戶(hù)，客戶(hù)端（瀏覽器）會(huì )把這個(gè) Cookies 給保存起來(lái)。
我們來(lái)使用工具 PostMan 來(lái)訪(fǎng)問(wèn)下某東的登錄頁(yè)，看下返回的響應頭：
當我們輸入好用戶(hù)名和密碼時(shí)，客戶(hù)端會(huì )將這個(gè) Cookies 放在請求頭一起發(fā)送給服務(wù)端，這時(shí)，服務(wù)端就知道是誰(shuí)在進(jìn)行登錄操作，并且可以判斷這個(gè)人輸入的用戶(hù)名和密碼對不對，如果輸入正確，則在服務(wù)端的 Session 記錄一下這個(gè)人已經(jīng)登錄成功了，下次再請求的時(shí)候這個(gè)人就是登錄狀態(tài)了。
如果客戶(hù)端傳給服務(wù)端的 Cookies 是無(wú)效的，或者這個(gè) Cookies 根本不是由這個(gè)服務(wù)端下發(fā)的，或者這個(gè) Cookies 已經(jīng)過(guò)期了，那么接下里的請求將不再能訪(fǎng)問(wèn)需要登錄后才能訪(fǎng)問(wèn)的頁(yè)面。
所以， Session 和 Cookies 之間是需要相互配合的，一個(gè)在服務(wù)端，一個(gè)在客戶(hù)端。
我們還是打開(kāi)某東的網(wǎng)站，看下這些 Cookies到底有哪些內容：
具體操作方式還是在 Chrome 中按 F12 打開(kāi)開(kāi)發(fā)者工具，選擇 Application 標簽，點(diǎn)開(kāi) Cookies 這一欄。
那么有的網(wǎng)站為什么這次關(guān)閉了，下次打開(kāi)的時(shí)候還是登錄狀態(tài)呢？
這就要說(shuō)到 Cookie 的持久化了，其實(shí)也不能說(shuō)是持久化，就是 Cookie 失效的時(shí)間設置的長(cháng)一點(diǎn)，比如直接設置到 2099 年失效，這樣，在瀏覽器關(guān)閉后，這個(gè) Cookie 是會(huì )保存在我們的硬盤(pán)中的，下次打開(kāi)瀏覽器，會(huì )再從我們的硬盤(pán)中將這個(gè) Cookie 讀取出來(lái)，用來(lái)維持用戶(hù)的會(huì )話(huà)狀態(tài)。
第二個(gè)問(wèn)題產(chǎn)生了，服務(wù)端的會(huì )話(huà)也會(huì )無(wú)限的維持下去么，當然不會(huì )，這就要在 Cookie 和 Session 上做文章了， Cookie 中可以使用加密的方式將用戶(hù)名記錄下來(lái)，在下次將 Cookies 讀取出來(lái)由請求發(fā)送到服務(wù)端后，服務(wù)端悄悄的自己創(chuàng )建一個(gè)用戶(hù)已經(jīng)登錄的會(huì )話(huà)，這樣我們在客戶(hù)端看起來(lái)就好像這個(gè)登錄會(huì )話(huà)是一直保持的。
當我們關(guān)閉瀏覽器的時(shí)候會(huì )自動(dòng)銷(xiāo)毀服務(wù)端的會(huì )話(huà)，這個(gè)是錯誤的，因為在關(guān)閉瀏覽器的時(shí)候，瀏覽器并不會(huì )額外的通知服務(wù)端說(shuō)，我要關(guān)閉了，你把和我的會(huì )話(huà)銷(xiāo)毀掉吧。
因為服務(wù)端的會(huì )話(huà)是保存在內存中的，雖然一個(gè)會(huì )話(huà)不會(huì )很大，但是架不住會(huì )話(huà)多啊，硬件畢竟是會(huì )有限制的，不能無(wú)限擴充下去的，所以在服務(wù)端設置會(huì )話(huà)的過(guò)期時(shí)間就非常有必要。
當然，有沒(méi)有方式能讓瀏覽器在關(guān)閉的時(shí)候同步的關(guān)閉服務(wù)端的會(huì )話(huà)，當然是可以的，我們可以通過(guò)腳本語(yǔ)言 JS 來(lái)監聽(tīng)瀏覽器關(guān)閉的動(dòng)作，當瀏覽器觸發(fā)關(guān)閉動(dòng)作的時(shí)候，由 JS 像服務(wù)端發(fā)起一個(gè)請求來(lái)通知服務(wù)端銷(xiāo)毀會(huì )話(huà)。
由于不同的瀏覽器對 JS 事件的實(shí)現機制不一致，不一定保證 JS 能監聽(tīng)到瀏覽器關(guān)閉的動(dòng)作，所以現在常用的方式還是在服務(wù)端自己設置會(huì )話(huà)的過(guò)期時(shí)間。
聯(lián)系客服
