要知道為什麼會有cookie和session，需要先理解http的特點：http協議是無狀態的協議。因此，cookie和session存在的作用是進行狀態管理。

Cookie和Session的簡單理解

我從哪裡來，我在哪裡，我到哪裡去

• Cookie是由服務端生成，儲存在響應頭中，返回給客戶端，客戶端會將cookie儲存下來

• Session是由服務端生成，儲存在伺服器端的記憶體、快取、資料庫等地方

• 在客戶端傳送請求時，user-agent會自動獲取本地儲存的cookie，將cookie資訊儲存在請求頭中，傳送給服務端

• 請求都是由客戶端發起的，當服務端生成了session，客戶端怎麼會知道呢？客戶端怎麼能對上這個session暗號？

  
  1）、在客戶端給服務端傳送請求後，服務端會根據請求資訊生成session，同時生成一個session_id，通過cookie返回給客戶端；

  
  2）、客戶端再次向服務端傳送請求時，會通過cookie將這個session_id傳送給服務端，這樣就對上了session的暗號。

• cookie可以作為管理session的一種方式，當cookie被禁用時，可以通過表單或重寫url傳送session_id

requests實現cookie操作

• cookie包含在響應中，要獲取響應中的cookie資訊，可以用r.cookies.get_dict()獲取到響應的cookies資訊，並傳遞給後續請求。

• 找一個不會被進行驗證的網站進行練習，從輸出資訊中，可以看到，第2個請求使用了第一個請求響應頭中的cookies資訊，保持了連線

  
  

  cookies.png

• 在已知cookie資訊時，需要構造成對應的cookie物件傳遞給請求時，可以採用Cookie 的返回物件為RequestsCookieJar或者採用字典構造。

• RequestsCookieJar構造cookies是已知登入響應返回的cookies資訊，通過建立物件，設定對應的值進行構造傳遞。

  
  

  RequestsCookieJar.png

• 採用字典構造cookies資訊，將構造方式更改為：

# 構造cookies

cookies = dict(zentaosid = '5qm86pvshjm3s8u729cmc0mb15')

會話物件session

會話物件讓你能夠跨請求保持某些引數。它也會在同一個 Session 例項發出的所有請求之間保持 cookie。所以如果你向同一主機發送多個請求，底層的 TCP 連線將會被重用，從而帶來顯著的效能提升。

• session會自動管理cookie，一個session物件會保持同一個會話中的所有請求之間的cookie資訊。

session.png

總結

• 會話物件session比cookies更方便管理請求的cookie資訊

• 伺服器返回的cookie資訊通常在響應頭中

• 如果需要將響應體中的部分資訊傳遞給後續請求的cookie，可以構造cookie資訊並傳遞