session和cookie

時間 2019-11-08

原文原文鏈接

會話控制是什麼？

cookie和session都是跟蹤整個會話過程的技術手段。而會話，就是用戶經過瀏覽器和服務器的一次通話。php

爲何要有會話控制？

由於HTTP協議是無狀態的，服務器不知道用戶上一次作了什麼，這嚴重阻礙了交互式web應用程序的實現。HTTP不經過額外的手段，服務器並不知道用戶作了什麼，爲了作到這一點，就須要使用cookie和session了。服務器能夠設置或者讀取cookie中包含信息，藉此維護用戶跟服務器會話中的狀態。html

※session的工做原理（運行機制）？

cookie的工做原理？

cookie工做原理web

cookie分爲兩種數據庫
1. 以文件方式存在硬盤空間上的持久cookie（網站的【記住密碼】【自動登陸】功能都是持久cookie）
2. 存在瀏覽器中佔用內存的臨時cookie
cookie採用的是在客戶端保持狀態的方案，它是客戶端的會話狀態的一種儲存機制。它是服務器在本地機器上存儲的小段文本或者是內存中的一段數據，並隨每個請求發送至同一個服務器 .

cookie工做原理：：：：跨域

cookie的工做原理，這須要有基本的HTTP協議基礎。瀏覽器

cookie是在RFC2109（已廢棄，被RFC2965取代）裏初次被描述的，每一個客戶端最多保持三百個cookie，每一個域名下最多20個Cookie（實際上通常瀏覽器如今都比這個多，如Firefox是50個），而每一個cookie的大小爲最多4K，不過不一樣的瀏覽器都有各自的實現。對於cookie的使用，最重要的就是要控制cookie的大小，不要放入無用的信息，也不要放入過多信息。安全

不管使用何種服務端技術，只要發送回的HTTP響應中包含以下形式的頭，則視爲服務器要求設置一個cookie：

Set-cookie:name=name;expires=date;path=path;domain=domain服務器

支持cookie的瀏覽器都會對此做出反應，即建立cookie文件並保存（也多是內存cookie），用戶之後在每次發出請求時，瀏覽器都要判斷當前全部的cookie中有沒有沒失效（根據expires屬性判斷）而且匹配了path屬性的cookie信息，若是有的話，會如下面的形式加入到請求頭中發回服務端：
Cookie: name="zj"; Path="/linkage"
服務端的動態腳本會對其進行分析，並作出相應的處理，固然也能夠選擇直接忽略。

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

具體來講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的工做原理？

默認狀況下全部的用戶信息都存放在服務器的硬盤中。可是能夠用memcache把這些數據放在內存中。
當客戶端向服務器發出請求時，要求服務器端產生一個 session時，服務器端會先檢查一下，客戶端的 cookie裏面有沒有session_id，是否已通過期。若是有這樣的 session_id的話，服務器端會根據cookie裏的session_id 把服務器的 session檢索出來。若是沒有這樣的session_id的話，服務器端會從新創建一個。 PHPSESSID是一串加了密的字符串，它的生成按照必定的規則來執行。同一客戶端啓動二次session_start的話，session_id是不同的。
因爲採用服務器端保持狀態的方案在客戶端也須要保存一個標識，因此 session機制藉助於cookie 機制來達到保存標識的目的
session產生的session_id 放在cookie裏面，若是用戶把 cookie禁止掉，是否是session也不能用了呢？禁止掉 cookie後，session 固然能夠用，不過經過其餘的方式來得到這個 sessionid，好比，能夠根在url的後面，或者以表單的形勢提交到服務器端。從而使服務器端了解客戶端的狀態。

再看一下session的原理：

生成全局惟一標識符（sessionid）；
開闢數據存儲空間。通常會在內存中建立相應的數據結構，但這種狀況下，系統一旦掉電，全部的會話數據就會丟失，若是是電子商務網站，這種事故會形成嚴重的後果。不過也能夠寫到文件裏甚至存儲在數據庫中，這樣雖然會增長I/O開銷，但session能夠實現某種程度的持久化，並且更有利於session的共享；
將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。下面通過比擬闡明兩者的特性以及適用的場所。

session的運行機制？

當一個Session開始時，Servlet容器會建立一個HttpSession對象，那麼在HttpSession對象中，能夠存放用戶狀態的信息
Servlet容器爲HttpSession對象分配一個惟一標識符即Sessionid，Servlet容器把Sessionid做爲一種Cookie保存在客戶端的 瀏覽器 中
用戶每次發出Http請求時，Servlet容器會從HttpServletRequest對象中取出Sessionid,而後根據這個Sessionid找到相應的HttpSession對象，從而獲取用戶的狀態信息

session的生命週期（有效期）？

cookie生命週期：

若是cookie不設定時間的話就表視它的生命週期爲瀏覽器會話的期間,只要關閉瀏覽器,cookie就消失了。若是設置了cokie的過時時間.那麼瀏覽器會把cookie保存到硬盤中,再次打IE時會依然有效.直到超過設置的有效期，$.cookie(key, value, {path:"/", expire: new Date("2017-01-01")}) 設置過時時間。注:存儲在硬盤中的cookie能夠在不一樣IE間共享。

session生命週期：

服務器會把長時間沒有活動的Session從服務器內存中清除，此時Session便失效。Tomcat中Session的默認失效時間爲20分鐘。調用Session的invalidate方法。注:當禁用cookie時也是不能使用session的。

PHP中的session有效期默認24分鐘，也就是說，客戶端超過24分鐘，當前session就會失效。固然，也能夠經過session.gc_maxlifetime修改。

session的垃圾回收機制？

每一次php請求，會有1/100的機率（默認值）觸發「session回收」。若是「session回收」發生，那就會檢查
/tmp/sess_*的文件，若是最後的修改時間到如今超過了1440秒（gc_maxlifetime的值），就將其刪除，意味着這些session過時失效。

因爲PHP的工做機制，它並無一個daemon線程，來定時地掃描session信息並判斷其是否失效。當一個有效請求發生時，PHP會根據全局變量session.gc_probability/session.gc_divisor（一樣能夠經過php.ini或者ini_set()函數來修改）的值，來決定是否啓動一個GC（Garbage Collector）。默認狀況下，session.gc_probability ＝1，session.gc_divisor ＝100，也就是說有1%的可能性會啓動GC。

GC 的工做，就是掃描全部的session信息，用當前時間減去session的最後修改時間（modifieddate），同session.gc_maxlifetime參數進行比較，若是生存時間已經超過gc_maxlifetime，就把該session刪除。

默認狀況下，每一次php請求，就會有1/100的機率發生回收，因此可能簡單的理解爲「每100次php請求就有一次回收發生」。這個機率是經過如下參數控制的
機率是gc_probability/gc_divisor

session.gc_probability = 1

session.gc_divisor = 100

注意1：假設這種狀況gc_maxlifetime=120，若是某個session文件最後修改時間是120秒以前，那麼在下一次回收（1/100的機率）發生前，這個session仍然是有效的。

注意2：若是你的session使用session.save_path中使用別的地方保存session，session回收機制有可能不會自動處理過時session文件。這時須要定時手動（或者crontab）的刪除過時的session：cd /path/to/sessions; find -cmin +24 | xargs rm

session.gc_maxlifetime

session.gc_probability

session.gc_divisor

session.gc_divisor 與 session.gc_probability 合起來定義了在每一個會話初始化時啓動 gc（garbage collection 垃圾回收）進程的機率。此機率用 gc_probability/gc_divisor 計算得來。例如 1/100 意味着在每一個請求中有 1% 的機率啓動 gc 進程。session.gc_divisor 默認爲 100。

好比：session.gc_maxlifetime=30，session.gc_divisor=1000，session.gc_probability=1，就表示每一千個用戶調用session_start()的時候，就百分百的會執行一次垃圾回收機制，將磁盤上沒用的session文件刪除。

注意：通常對於一些大型的門戶網站，建議將session.gc_divisor調大一點，減小開銷

接下來，我經過一個例子演示下，如何配置才能讓調用gc（垃圾回收）進程呢！

經過配置php.ini文件，修改如下幾個信息：

session.gc_maxlifetime = 60//當session文件在60s後尚未被訪問的話，則該session文件將會被視爲「垃圾文件」，而且等待gc（垃圾回收）進程的調用的時候被清理掉
session.gc_probability = 1000
由於gc進程被調用的機率是經過gc_probability/gc_divisor 計算得來的，這裏我將session.gc_probability改爲1000，而session.gc_divisor 默認狀況下也是1000。則gc進程在每次執行session_start()函數的時候都會被調用到。

如下我經過截圖簡單的說明下：

我開啓三個會話，則建立三個對應的session文件，當每一個文件在30秒內都沒被調用的話，就會被當成是「垃圾文件」，等到gc進程調用的時候，「垃圾文件」就會被unlink，由於以前我已經經過修改php.ini配置文件，將gc被調用的機率改爲百分百，因此接下來，若是我從新使用任何一個瀏覽器刷新下頁面的時候，三個session文件，應該只剩下一個了

如何永久化session？

如何銷燬session？

其實讓Session結束生命週期，有如下兩種辦法：

* 一個是Session.invalidate()方法，不過這個方法在實際的開發中，並不推薦，可能在強制註銷用戶的時候會使用；
* 一個是當前用戶和服務器的交互時間超過默認時間後，Session會失效

咱們知道Session是存在於服務器端的，當把瀏覽器關閉時，瀏覽器並無向服務器發送任何請求來關閉Session，天然Session也不會被銷燬，可是能夠作一點努力，在全部的客戶端頁面裏使用js的window.onclose來監視瀏覽器的關閉動做，而後向服務器發送一個請求來關閉Session，可是這種作法在實際的開發中也是不推薦使用的，最正常的辦法就是不去管它，讓它等到默認的時間後，自動銷燬。

SESSION發出去的COOKIE通常屬於即時COOKIE，保存在內存中，當瀏覽器關閉後，纔會過時，假如須要人爲強制過時，好比退出登陸，而不是關閉瀏覽器，那麼就須要在代碼裏銷燬SESSION，方法有不少，

setcookie(session_name(),session_id(),time() -8000000,..);//退出登陸前執行
usset($_SESSION);//這會刪除全部的$_SESSION數據，刷新後，有COOKIE傳過來，可是沒有數據。
session_destroy();//這個做用更完全，刪除$_SESSION 刪除session文件，和session_id

如何設置一個嚴格過時的sessioon?

如何設置一個嚴格30分鐘過時的Session | 風雪之隅

幾個問題

禁用cookie，session還能使用嗎？詳細說說

使用URL重寫，就是把session id直接附加在URL路徑的後面，做爲URL路徑的附加信息。

（當客戶端的Cookie被禁用或出現問題時，PHP會自動把Session ID附着在URL中，這樣再經過Session ID就能跨頁使用Session變量了。）

設置php.ini配置文件中的「session.use_trans_sid = 1」，或者編譯時打開「--enable-trans-sid」選項，讓PHP自動跨頁傳遞Session ID。
手動經過URL傳值、隱藏表單傳遞Session ID。
用文件、數據庫等形式保存Session ID，在跨頁過程當中手動調用。

一般狀況下 Cookie 裏記錄了 Session 的 id ，全部 Cookie 被禁用了也就意味着 Session 失效了。不過 Session id 還有另一種傳遞方式，就是在 URL 查詢中攜帶 Session id （既把全部的URL裏都帶上Session id的參數，如: http://xxx/index?sid=...）。不夠這種方法比較麻煩（全部的連接都要帶上），並且比較容易丟失 Session id（地址能夠認爲修改去掉ID），全部只是做爲備選方案，在 Cookie 不能使用的環境下能夠做爲替代。

常見的session實現方式是基於cookie的，因此禁用cookie，session隨之失效

理論上只要在返回的頁面裏裏能帶上一個標識會話的令牌，在瀏覽器下一次提交的時候，能帶上這個令牌，會話就能夠被保持

所以，cookie只是最優雅的實現session的方式，由於cookie對用戶來講不可見，同時會自動在HTTP報文中傳輸

但session也能夠經過其餘方式來保持，好比放一個sessionId在URL的參數裏

對關閉瀏覽器後Session失效的理解

關閉瀏覽器不能結束一個會話，.
session只是失效，可是並未被清除，關閉瀏覽器不等於退出登陸/結束會話了.....

那當咱們關閉瀏覽器以後，服務器端原來的session對象是否還存在呢？
答案是確定的。服務端根本不知道咱們是否關閉了瀏覽器，也不關心這個。客戶端與服務端之間進行通訊的惟一途徑就是經過請求。服務器有本身的一套機制來管理session，好比多長時間會清除沒有使用過的session對象，等等。

那麼爲何當咱們關閉瀏覽器後，就再也訪問不到以前的session了呢？
因此說，關閉瀏覽器session就被清除只是咱們所看到的表面現象(其實是新建了一個session對象)，一般狀況下，服務器並不會立刻清除session對象，但這個根據服務端的設定而不一樣。
.0

其實以前的Session一直都在服務器.端，而當咱們關閉瀏覽器時，此時的Cookie是存在於瀏覽器的進程中的，當瀏覽器關閉時，Cookie也就不存在了。
其實Cookie有兩種:

* 一種是存在於瀏覽器的進程中;
* 一種是存在於硬盤上

而session的Cookie是存在於瀏覽器的進程中，那麼這種Cookie咱們稱爲會話Cookie，
當咱們從新打開瀏覽器窗口時，以前的Cookie中存放的Sessionid已經不存在了，此時
服務器從HttpServletRequest對象中沒有檢查到sessionid，服務器會再發送一個新的存
有Sessionid的Cookie到客戶端的瀏覽器中，此時對應的是一個新的會話，而服務器上
原先的session等到它的默認時間到以後，便會自動銷燬。

...so，以此類推
當在同一個瀏覽器中同時打開多個標籤，發送同一個請求或不一樣的請求，還是同一個session;
當不在同一個窗口中打開相同的瀏覽器時，發送請求，還是同一個session;
當使用不一樣的瀏覽器時，發送請求，即便發送相同的請求，是不一樣的session;

當把當前某個瀏覽器的窗口全關閉，再打開，發起相同的請求時，就是本文所闡述的，是不一樣的session,可是它和session的生命週期是沒有關係的.
PS：cookie通常分爲兩種：一種是會話cookie，即服務端爲session自動建立的cookie，這個cookie存放在瀏覽器進程中。另外一種是能夠存放在硬盤上的，能夠經過服務端的某些設置，將一些信息放到cookie中並返回給客戶端存放在硬盤上。

Session是在客戶端請求到達服務器時，服務器爲此請求發出的客戶所建立的一個對象，保存在服務器端。購物車是一個很好的例子，一個用戶能夠有不少session，但每一個session只針對一個用戶，這就保證了不一樣session之間的信息獨立。

首先說明一點，在一般意義上，session所能發揮做用是基於cookie機制。針對所須要解釋的問題，作這樣一個假設：咱們第一次訪問一個網頁。當客戶端發送請求後，服務端會創建一個針對此請求發出客戶的session對象，並且每一個session都會有一個sessionID。服務端會自動將這個sessionID做爲一個cookie附加到response上返回給客戶端，這個cookie存放在瀏覽器內存中。咱們每次對此網頁發送的request都會附帶着這個cookie，服務端收到這個請求後會都去cookie中取得這個sessionID，而後查詢服務端是否存在一個對應此ID的session對象。若是有，能夠直接使用此session；若是沒有，則會新建一個。當瀏覽器關閉後，其所佔的內存就會是放掉，cookie天然也就被清除了，此時咱們再也不保存有這個sessionID。因此再打開瀏覽器訪問同一個頁面時，因爲沒有sessionID，也就查不到對應的session對象，此時從新建立一個新的session對象。

session和cookie的區別？

存儲位置，隱私策略和安全性，數據類型，有效期，服務器壓力，瀏覽器支持，跨域支持，數據量

cookie在客戶端，session在服務器端
cookie在本地，能夠隨便修改，session更安全
cookie只支持ascII字符串，須要解碼。session支持全部的數據類型。
cookie存在本地，能夠永久有效。而session在服務器上，設置永久有效以後，服務器上session會不斷累積，會致使內存溢出。
session會在必定時間內保存在服務器上。當訪問增多，會比較佔用你服務器的性能，若是主要考慮到減輕服務器性能方面，應當使用cookie。
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的搭配運用在實踐項目中會完成不少意想不到的效果。

7.存儲數據量不一樣