Cookies和Session的區別和理解

Cookies和Session的區別和理解

cookie機制

Cookies是服務器在本地機器上存儲的小段文本並隨每一個請求發送至同一個服務器。IETF RFC 2965 HTTP State Management Mechanism 是通用cookie規範。網絡服務器用HTTP頭向客戶端發送cookies，在客戶終端，瀏覽器解析這些cookies並將它們保存爲一個本地文件，它會自動將同一服務器的任何請求縛上這些cookies 。

具體來說cookie機制採用的是在客戶端保持狀態的方案。它是在用戶端的會話狀態的存貯機制，他需要用戶打開客戶端的cookie支持。cookie的作用就是爲了解決HTTP協議無狀態的缺陷所作的努力。

正統的cookie分發是通過擴展HTTP協議來實現的，服務器通過在HTTP的響應頭中加上一行特殊的指示以提示瀏覽器按照指示生成相應的cookie。然而純粹的客戶端腳本如JavaScript也可以生成cookie。而cookie的使用是由瀏覽器按照一定的原則在後臺自動發送給服務器的。瀏覽器檢查所有存儲的cookie，如果某個cookie所聲明的作用範圍大於等於將要請求的資源所在的位置，則把該cookie附在請求資源的HTTP請求頭上發送給服務器。

cookie的內容主要包括：名字，值，過期時間，路徑和域。路徑與域一起構成cookie的作用範圍。若不設置過期時間，則表示這個cookie的生命期爲瀏覽器會話期間，關閉瀏覽器窗口，cookie就消失。這種生命期爲瀏覽器會話期的cookie被稱爲會話cookie。會話cookie一般不存儲在硬盤上而是保存在內存裏，當然這種行爲並不是規範規定的。若設置了過期時間，瀏覽器就會把cookie保存到硬盤上，關閉後再次打開瀏覽器，這些cookie仍然有效直到超過設定的過期時間。存儲在硬盤上的cookie可以在不同的瀏覽器進程間共享，比如兩個IE窗口。而對於保存在內存裏的cookie，不同的瀏覽器有不同的處理方式。

而session機制採用的是一種在服務器端保持狀態的解決方案。同時我們也看到，由於採用服務器端保持狀態的方案在客戶端也需要保存一個標識，所以session機制可能需要藉助於cookie機制來達到保存標識的目的。而session提供了方便管理全局變量的方式 。

session是針對每一個用戶的，變量的值保存在服務器上，用一個sessionID來區分是哪個用戶session變量,這個值是通過用戶的瀏覽器在訪問的時候返回給服務器，當客戶禁用cookie時，這個值也可能設置爲由get來返回給服務器。

就安全性來說：當你訪問一個使用session 的站點，同時在自己機子上建立一個cookie，建議在服務器端的session機制更安全些，因爲它不會任意讀取客戶存儲的信息。

SESSION機制

session機制是一種服務器端的機制，服務器使用一種類似於散列表的結構（也可能就是使用散列表）來保存信息。

當程序需要爲某個客戶端的請求創建一個session時，服務器首先檢查這個客戶端的請求裏是否已包含了一個session標識（稱爲session id），如果已包含則說明以前已經爲此客戶端創建過session，服務器就按照session id把這個session檢索出來使用（檢索不到，會新建一個），如果客戶端請求不包含session id，則爲此客戶端創建一個session並且生成一個與此session相關聯的session id，session id的值應該是一個既不會重複，又不容易被找到規律以仿造的字符串，這個session id將被在本次響應中返回給客戶端保存。

保存這個session id的方式可以採用cookie，這樣在交互過程中瀏覽器可以自動的按照規則把這個標識發揮給服務器。一般這個cookie的名字都是類似於SEEESIONID。但cookie可以被人爲的禁止，則必須有其他機制以便在cookie被禁止時仍然能夠把session id傳遞迴服務器。

經常被使用的一種技術叫做URL重寫，就是把session id直接附加在URL路徑的後面。還有一種技術叫做表單隱藏字段。就是服務器會自動修改表單，添加一個隱藏字段，以便在表單提交時能夠把session id傳遞迴服務器。

Cookie和Session不的通

Cookie與Session都能夠進行會話跟蹤，但是完成的原理不太一樣。普通狀況下二者均能夠滿足需求，但有時分不能夠運用Cookie，有時分不能夠運用Session。下面經過比擬闡明二者的特性以及適用的場所。

1 .存取方式的不同

Cookie中只能保管ASCII字符串，假如需求存取Unicode字符或者二進制數據，需求先進行編碼。Cookie中也不能直接存取Java對象。若要存儲略微複雜的信息，運用Cookie是比擬艱難的。

而Session中能夠存取任何類型的數據，包括而不限於String、Integer、List、Map等。Session中也能夠直接保管Java Bean乃至任何Java類，對象等，運用起來十分便當。能夠把Session看做是一個Java容器類。

2 .隱私策略的不同

Cookie存儲在客戶端閱讀器中，對客戶端是可見的，客戶端的一些程序可能會窺探、複製以至修正Cookie中的內容。而Session存儲在服務器上，對客戶端是透明的，不存在敏感信息泄露的風險。

假如選用Cookie，比較好的方法是，敏感的信息如賬號密碼等儘量不要寫到Cookie中。最好是像Google、Baidu那樣將Cookie信息加密，提交到服務器後再進行解密，保證Cookie中的信息只要本人能讀得懂。而假如選擇Session就省事多了，反正是放在服務器上，Session裏任何隱私都能夠有效的保護。

3.有效期上的不同

使用過Google的人都曉得，假如登錄過Google，則Google的登錄信息長期有效。用戶不用每次訪問都重新登錄，Google會持久地記載該用戶的登錄信息。要到達這種效果，運用Cookie會是比較好的選擇。只需要設置Cookie的過期時間屬性爲一個很大很大的數字。

由於Session依賴於名爲JSESSIONID的Cookie，而Cookie JSESSIONID的過期時間默許爲–1，只需關閉了閱讀器該Session就會失效，因而Session不能完成信息永世有效的效果。運用URL地址重寫也不能完成。而且假如設置Session的超時時間過長，服務器累計的Session就會越多，越容易招致內存溢出。

4.服務器壓力的不同

Session是保管在服務器端的，每個用戶都會產生一個Session。假如併發訪問的用戶十分多，會產生十分多的Session，耗費大量的內存。因而像Google、Baidu、Sina這樣併發訪問量極高的網站，是不太可能運用Session來追蹤客戶會話的。

而Cookie保管在客戶端，不佔用服務器資源。假如併發閱讀的用戶十分多，Cookie是很好的選擇。關於Google、Baidu、Sina來說，Cookie或許是唯一的選擇。

5 .瀏覽器支持的不同

Cookie是需要客戶端瀏覽器支持的。假如客戶端禁用了Cookie，或者不支持Cookie，則會話跟蹤會失效。關於WAP上的應用，常規的Cookie就派不上用場了。

假如客戶端瀏覽器不支持Cookie，需要運用Session以及URL地址重寫。需要注意的是一切的用到Session程序的URL都要進行URL地址重寫，否則Session會話跟蹤還會失效。關於WAP應用來說，Session+URL地址重寫或許是它唯一的選擇。

假如客戶端支持Cookie，則Cookie既能夠設爲本瀏覽器窗口以及子窗口內有效（把過期時間設爲–1），也能夠設爲一切閱讀器窗口內有效（把過期時間設爲某個大於0的整數）。但Session只能在本閱讀器窗口以及其子窗口內有效。假如兩個瀏覽器窗口互不相干，它們將運用兩個不同的Session。（IE8下不同窗口Session相干）

6.跨域支持上的不同

Cookie支持跨域名訪問，例如將domain屬性設置爲“.biaodianfu.com”，則以“.biaodianfu.com”爲後綴的一切域名均能夠訪問該Cookie。跨域名Cookie如今被普遍用在網絡中，例如Google、Baidu、Sina等。而Session則不會支持跨域名訪問。Session僅在他所在的域名內有效。

僅運用Cookie或者僅運用Session可能完成不了理想的效果。這時應該嘗試一下同時運用Cookie與Session。Cookie與Session的搭配運用在實踐項目中會完成很多意想不到的效果。

我的理解：

1. 由於HTTP協議是無狀態的協議，所以服務端需要記錄用戶的狀態時，就需要用某種機制來識具體的用戶，這個機制就是Session.典型的場景比如購物車，當你點擊下單按鈕時，由於HTTP協議無狀態，所以並不知道是哪個用戶操作的，所以服務端要爲特定的用戶創建了特定的Session，用用於標識這個用戶，並且跟蹤用戶，這樣才知道購物車裏面有幾本書。這個Session是保存在服務端的，有一個唯一標識。在服務端保存Session的方法很多，內存、數據庫、文件都有。集羣的時候也要考慮Session的轉移，在大型的網站，一般會有專門的Session服務器集羣，用來保存用戶會話，這個時候 Session 信息都是放在內存的，使用一些緩存服務比如Memcached之類的來放 Session。
2. 思考一下服務端如何識別特定的客戶？這個時候Cookie就登場了。每次HTTP請求的時候，客戶端都會發送相應的Cookie信息到服務端。實際上大多數的應用都是用 Cookie 來實現Session跟蹤的，第一次創建Session的時候，服務端會在HTTP協議中告訴客戶端，需要在 Cookie 裏面記錄一個Session ID，以後每次請求把這個會話ID發送到服務器，我就知道你是誰了。有人問，如果客戶端的瀏覽器禁用了 Cookie 怎麼辦？一般這種情況下，會使用一種叫做URL重寫的技術來進行會話跟蹤，即每次HTTP交互，URL後面都會被附加上一個諸如 sid=xxxxx 這樣的參數，服務端據此來識別用戶。
3. Cookie其實還可以用在一些方便用戶的場景下，設想你某次登陸過一個網站，下次登錄的時候不想再次輸入賬號了，怎麼辦？這個信息可以寫到Cookie裏面，訪問網站的時候，網站頁面的腳本可以讀取這個信息，就自動幫你把用戶名給填了，能夠方便一下用戶。這也是Cookie名稱的由來，給用戶的一點甜頭。

總結一下：

Session是在服務端保存的一個數據結構，用來跟蹤用戶的狀態，這個數據可以保存在集羣、數據庫、文件中；

Cookie是客戶端保存用戶信息的一種機制，用來記錄用戶的一些信息，也是實現Session的一種方式。

Cookies和Session的區別和理解

---

1.狀態保持

• http協議是無狀態的：每次請求都是一次新的請求，不會記得之前通信的狀態
• 客戶端與服務器端的一次通信，就是一次會話
• 實現狀態保持的方式：在客戶端或服務器端存儲與會話有關的數據
• 存儲方式包括cookie、session，會話一般指session對象
• 使用cookie，所有數據存儲在客戶端，注意不要存儲敏感信息
• 推薦使用sesison方式，所有數據存儲在服務器端，在客戶端cookie中存儲session_id
• 狀態保持的目的是在一段時間內跟蹤請求者的狀態，可以實現跨頁面訪問當前請求者的數據
• 注意：不同的請求者之間不會共享這個數據，與請求者一一對應

2.啓用session(舉例Django)

• 使用django-admin startproject創建的項目默認啓用
• 在settings.py文件中

項INSTALLED_APPS列表中添加：

'django.contrib.sessions',

項MIDDLEWARE_CLASSES列表中添加：

'django.contrib.sessions.middleware.SessionMiddleware',

• 禁用會話：刪除上面指定的兩個值，禁用會話將節省一些性能消耗

3.使用session

• 啓用會話後，每個HttpRequest對象將具有一個session屬性，它是一個類字典對象
• get(key, default=None)：根據鍵獲取會話的值
• request.session.get(‘uname’,’’)
• clear()：清除所有會話
• flush()：刪除當前的會話數據並刪除會話的Cookie
• del request.session['uname']：刪除會話

4.會話過期時間

• set_expiry(value)：設置會話的超時時間
• 如果沒有指定，則兩個星期後過期
• 如果value是一個整數，會話將在values秒沒有活動後過期
• 若果value是一個timedelta對象，會話將在當前時間加上這個指定的日期/時間過期
• 如果value爲0，那麼用戶會話的Cookie將在用戶的瀏覽器關閉時過期
• 如果value爲None，那麼會話永不過期