摘要：的作用就是為了解決協議無狀態的缺陷所作的努力。的內容主要包括名字，值，過期時間，路徑和域。這種生命期為瀏覽器會話期的被稱為會話。而機制采用的是一種在服務器端保持狀態的解決方案。中的有效期默認分鐘，也就是說，客戶端超過分鐘，當前就會失效。

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

因為HTTP協議是無狀態的，服務器不知道用戶上一次做了什么，這嚴重阻礙了交互式web應用程序的實現。HTTP不通過額外的手段，服務器并不知道用戶做了什么，為了做到這一點，就需要使用cookie和session了。服務器可以設置或者讀取cookie中包含信息，借此維護用戶跟服務器會話中的狀態。

cookie工作原理

cookie分為兩種

以文件方式存在硬盤空間上的持久cookie（網站的【記住密碼】【自動登錄】功能都是持久cookie）

存在瀏覽器中占用內存的臨時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的作用就是為了解決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機制更安全些，因為它不會任意讀取客戶存儲的信息。

默認情況下所有的用戶信息都存放在服務器的硬盤中。但是可以用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開始時，Servlet容器會創建一個HttpSession對象，那么在HttpSession對象中，可以存放用戶狀態的信息

Servlet容器為HttpSession對象分配一個唯一標識符即Sessionid，Servlet容器把Sessionid作為一種Cookie保存在客戶端的 瀏覽器 中

用戶每次發出Http請求時，Servlet容器會從HttpServletRequest對象中取出Sessionid,然后根據這個Sessionid找到相應的HttpSession對象，從而獲取用戶的狀態信息

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修改。

每一次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.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

如何設置一個嚴格30分鐘過期的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對象，但這個根據服務端的設定而不同。
.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對象。
     

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

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.存儲數據量不同

單個cookie保存的數據不能超過4k，很多瀏覽器都限制一個站點最多保存20個cookie

8.session和cookie的使用場景？

將登陸信息等重要信息存放為SESSION;其他信息如果需要保留，可以放在COOKIE中。