php中cookie和session是我們常用的兩個變量了，一個是用戶客戶端的，一個用在服務器的但他們的區別與工作原理怎麼樣，下面我們一起來看看cookie和session機制原理吧。
cookie和session機制之間的區別和聯系
具體來說cookie機制采用的是在客戶端保持狀態的方案。它是在用戶端的會話狀態的存貯機制，他需要用戶打開客戶端的cookie支持。cookie的作用就是為了解決HTTP協議無狀態的缺陷所作的努力.
而session機制采用的是一種在客戶端與服務器之間保持狀態的解決方案。同時我們也看到，由於采用服務器端保持狀態的方案在客戶端也需要保存一個標識，所以session機制可能需要借助於cookie機制來達到保存標識的目的。而session提供了方便管理全局變量的方式
session是針對每一個用戶的，變量的值保存在服務器上，用一個sessionID來區分是哪個用戶session變量,這個值是通過用戶的浏覽器在訪問的時候返回給服務器，當客戶禁用cookie時，這個值也可能設置為由get來返回給服務器。
就安全性來說：當你訪問一個使用session的站點，同時在自己機子上建立一個cookie，建議在服務器端的SESSION機制更安全些.因為它不會任意讀取客戶存儲的信息。
正統的cookie分發是通過擴展HTTP協議來實現的，服務器通過在HTTP的響應頭中加上一行特殊的指示以提示浏覽器按照指示生成相應的cookie
從網絡服務器觀點看所有HTTP請求都獨立於先前請求。就是說每一個HTTP響應完全依賴於相應請求中包含的信息
狀態管理機制克服了HTTP的一些限制並允許網絡客戶端及服務器端維護請求間的關系。在這種關系維持的期間叫做會話(session)。
Cookies是服務器在本地機器上存儲的小段文本並隨每一個請求發送至同一個服務器。IETFRFC2965HTTPStateManagementMechanism是通用cookie規范。網絡服務器用HTTP頭向客戶端發送cookies，在客戶終端，浏覽器解析這些cookies並將它們保存為一個本地文件，它會自動將同一服務器的任何請求縛上這些cookies
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
理解session機制
session機制是一種服務器端的機制，服務器使用一種類似於散列表的結構（也可能就是使用散列表）來保存信息。
當程序需要為某個客戶端的請求創建一個session的時候，服務器首先檢查這個客戶端的請求裡是否已包含了一個session標識-稱為sessionid，如果已包含一個sessionid則說明以前已經為此客戶端創建過session，服務器就按照sessionid把這個session檢索出來使用（如果檢索不到，可能會新建一個），如果客戶端請求不包含sessionid，則為此客戶端創建一個session並且生成一個與此session相關聯的sessionid，sessionid的值應該是一個既不會重復，又不容易被找到規律以仿造的字符串，這個sessionid將被在本次響應中返回給客戶端保存。
保存這個sessionid的方式可以采用cookie，這樣在交互過程中浏覽器可以自動的按照規則把這個標識發揮給服務器。一般這個cookie的名字都是類似於SEEESIONID，而。比如weblogic對於web應用程序生成的cookie，JSESSIONID=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764，它的名字就是JSESSIONID。
由於cookie可以被人為的禁止，必須有其他機制以便在cookie被禁止時仍然能夠把sessionid傳遞回服務器。經常被使用的一種技術叫做URL重寫，就是把sessionid直接附加在URL路徑的後面，附加方式也有兩種，一種是作為URL路徑的附加信息，表現形式為http://...../xxx;jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764
另一種是作為查詢字符串附加在URL後面，表現形式為http://...../xxx?jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764
這兩種方式對於用戶來說是沒有區別的，只是服務器在解析的時候處理的方式不同，采用第一種方式也有利於把sessionid的信息和正常程序參數區分開來。
為了在整個交互過程中始終保持狀態，就必須在每個客戶端可能請求的路徑後面都包含這個sessionid。
另一種技術叫做表單隱藏字段。就是服務器會自動修改表單，添加一個隱藏字段，以便在表單提交時能夠把sessionid傳遞回服務器。比如下面的表單
在被傳遞給客戶端之前將被改寫成
這種技術現在已較少應用，筆者接觸過的很古老的iPlanet6(SunONE應用服務器的前身)就使用了這種技術。
實際上這種技術可以簡單的用對action應用URL重寫來代替。
在談論session機制的時候，常常聽到這樣一種誤解“只要關閉浏覽器，session就消失了”。其實可以想象一下會員卡的例子，除非顧客主動對店家提出銷卡，否則店家絕對不會輕易刪除顧客的資料。對session來說也是一樣的，除非程序通知服務器刪除一個session，否則服務器會一直保留，程序一般都是在用戶做logoff的時候發個指令去刪除session。然而浏覽器從來不會主動在關閉之前通知服務器它將要關閉，因此服務器根本不會有機會知道浏覽器已經關閉，之所以會有這種錯覺，是大部分session機制都使用會話cookie來保存sessionid，而關閉浏覽器後這個sessionid就消失了，再次連接服務器時也就無法找到原來的session。如果服務器設置的cookie被保存到硬盤上，或者使用某種手段改寫浏覽器發出的HTTP請求頭，把原來的sessionid發送給服務器，則再次打開浏覽器仍然能夠找到原來的session。
恰恰是由於關閉浏覽器不會導致session被刪除，迫使服務器為seesion設置了一個失效時間，當距離客戶端上一次使用session的時間超過這個失效時間時，服務器就可以認為客戶端已經停止了活動，才會把session刪除以節省存儲空間。
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
由JSESSIONID談cookie與SESSION的區別和聯系
在一些投票之類的場合，我們往往因為公平的原則要求每人只能投一票，在一些WEB開發中也有類似的情況，這時候我們通常會使用COOKIE來實現，例如如下的代碼：
<%
cookie[]cookies=request.getCookies();
if(cookies.lenght==0||cookies==null)
doStuffForNewbie();
//沒有訪問過
}
else
{
doStuffForReturnVisitor();//已經訪問過了
}
%>
這是很淺顯易懂的道理，檢測COOKIE的存在，如果存在說明已經運行過寫入COOKIE的代碼了，然而運行以上的代碼後，無論何時結果都是執行doStuffForReturnVisitor()，通過控制面板-Internet選項-設置-察看文件卻始終看不到生成的cookie文件，奇怪，代碼明明沒有問題，不過既然有cookie，那就顯示出來看看。
cookie[]cookies=request.getCookies();
if(cookies.lenght==0||cookies==null)
out.println("Hasnotvisitedthiswebsite");
}
else
{
for(inti=0;i<cookie.length;i++)
{
out.println("cookiename:"+cookies[i].getName()+"cookievalue:"+
cookie[i].getValue());
}
}
運行結果:
cookiename:JSESSIONIDcookievalue:KWJHUG6JJM65HS2K6為什麼會有cookie呢,大家都知道，http是無狀態的協議，客戶每次讀取web頁面時，服務器都打開新的會話，而且服務器也不會自動維護客戶的上下文信息，那麼要怎麼才能實現網上商店中的購物車呢，session就是一種保存上下文信息的機制，它是針對每一個用戶的，變量的值保存在服務器端，通過SessionID來區分不同的客戶,session是以cookie或URL重寫為基礎的，默認使用cookie來實現，系統會創造一個名為JSESSIONID的輸出cookie，我們叫做sessioncookie,以區別persistentcookies,也就是我們通常所說的cookie,注意sessioncookie是存儲於浏覽器內存中的，並不是寫到硬盤上的，這也就是我們剛才看到的JSESSIONID，我們通常情是看不到JSESSIONID的，但是當我們把浏覽器的cookie禁止後，web服務器會采用URL重寫的方式傳遞Sessionid，我們就可以在地址欄看到sessionid=KWJHUG6JJM65HS2K6之類的字符串。
明白了原理，我們就可以很容易的分辨出persistentcookies和sessioncookie的區別了，網上那些關於兩者安全性的討論也就一目了然了，sessioncookie針對某一次會話而言，會話結束sessioncookie也就隨著消失了，而persistentcookie只是存在於客戶端硬盤上的一段文本（通常是加密的），而且可能會遭到cookie欺騙以及針對cookie的跨站腳本攻擊，自然不如sessioncookie安全了。
通常sessioncookie是不能跨窗口使用的，當你新開了一個浏覽器窗口進入相同頁面時，系統會賦予你一個新的sessionid，這樣我們信息共享的目的就達不到了，此時我們可以先把sessionid保存在persistentcookie中，然後在新窗口中讀出來，就可以得到上一個窗口SessionID了，這樣通過sessioncookie和persistentcookie的結合我們就實現了跨窗口的sessiontracking（會話跟蹤）。
在一些web開發的書中，往往只是簡單的把Session和cookie作為兩種並列的http傳送信息的方式，sessioncookies位於服務器端，persistentcookie位於客戶端，可是session又是以cookie為基礎的，明白的兩者之間的聯系和區別，我們就不難選擇合適的技術來開發webservice了。
後來我看一篇關於 徹底理解PHP的SESSION機制
1.session.save_handler = files
* 1. session_start()
1. session_start()是session機制的開始，它有一定概率開啟垃圾回收,因為session是存放在文件中，
PHP自身的垃圾回收是無效的，SESSION的回收是要刪文件的，這個概率是根據php.ini的配置決定的，
但是有的系統是 session.gc_probability = 0，這也就是說概率是0，而是通過cron腳本來實現垃圾回收。
session.gc_probability = 1
session.gc_divisor = 1000
session.gc_maxlifetime = 1440//過期時間 默認24分鐘
//概率是 session.gc_probability/session.gc_divisor 結果 1/1000,
//不建議設置過小，因為session的垃圾回收，是需要檢查每個文件是否過期的。
session.save_path = //好像不同的系統默認不一樣，有一種設置是 "N;/path"
//這是隨機分級存儲，這個樣的話，垃圾回收將不起作用，需要自己寫腳本
2. session會判斷當前是否有$_COOKIE[session_name()];session_name()返回保存session_id的COOKIE鍵值，
這個值可以從php.ini找到
session.name = PHPSESSID //默認值PHPSESSID
3. 如果不存在會生成一個session_id,然後把生成的session_id作為COOKIE的值傳遞到客戶端.
相當於執行了下面COOKIE 操作，注意的是，這一步執行了setcookie()操作，COOKIE是在header頭中發送的，
這之前是不能有輸出的，PHP有另外一個函數 session_regenerate_id() 如果使用這個函數，這之前也是不能有輸出的。
setcookie(session_name(),
session_id(),
session.cookie_lifetime,//默認0
session.cookie_path,//默認'/'當前程序跟目錄下都有效
session.cookie_domain,//默認為空
)
4. 如果存在那麼session_id = $_COOKIE[session_name];
然後去session.save_path指定的文件夾裡去找名字為'SESS_' . session_id()的文件.
讀取文件的內容反序列化，然後放到$_SESSION中
* 2. 為$_SESSION賦值
比如新添加一個值$_SESSION['test'] = 'blah'; 那麼這個$_SESSION只會維護在內存中，當腳本執行結束的時候，
用把$_SESSION的值寫入到session_id指定的文件夾中，然後關閉相關資源. 這個階段有可能執行更改session_id的操作，
比如銷毀一個舊的的session_id，生成一個全新的session_id.一半用在自定義 session操作，角色的轉換上，
比如Drupal.Drupal的匿名用戶有一個SESSION的，當它登錄後需要換用新的session_id
if (isset($_COOKIE[session_name()])) {
setcookie(session_name(), '', time() - 42000, '/');//舊session cookie過期
}
session_regenerate_id();//這一步會生成新的session_id
//session_id()返回的是新的值
3.寫入SESSION操作
在腳本結束的時候會執行SESSION寫入操作，把$_SESSION中值寫入到session_id命名的文件中，可能已經存在，
可能需要創建新的文件。
* 4. 銷毀SESSION
SESSION發出去的COOKIE一般屬於即時COOKIE，保存在內存中，當浏覽器關閉後，才會過期，假如需要人為強制過期，
比如 退出登錄，而不是關閉浏覽器，那麼就需要在代碼裡銷毀SESSION，方法有很多，
o 1. setcookie(session_name(), session_id(), time() - 8000000, ..);//退出登錄前執行
o 2. usset($_SESSION);//這會刪除所有的$_SESSION數據，刷新後，有COOKIE傳過來，但是沒有數據。
o 3. session_destroy();//這個作用更徹底，刪除$_SESSION 刪除session文件，和session_id
當不關閉浏覽器的情況下，再次刷新，2和3都會有COOKIE傳過來，但是找不到數據
2.session.save_handler = user
用戶自定義session處理機制，更加直觀
* session_set_save_handler('open', 'close', 'read', 'write', 'destroy', 'gc');
1.session_start(),
執行open($save_path, $session_name)打開session操作句柄
$save_path 在session.save_handler = files的情況下它就是session.save_path，
但是如果用戶自定的話，這個兩個參數都用不上，直接返回TRUE
執行read($id)從中讀取數據.//這個參數是自動傳遞的就是session_id(),可以通過這個值進行操作。
* 2.腳本執行結束
執行write($id, $sess_data) //兩個參數，很簡單
* 3.假如用戶需要session_destroy()
先執行destroy.在執行第2步
一個實際例子：
代碼如下 //SESSION初始化的時候調用
function open($save_path, $session_name)
{
global $sess_save_path;
$sess_save_path = $save_path;
return(true);
}
//關閉的時候調用
function close()
{
return(true);
}
function read($id)
{
global $sess_save_path;
$sess_file = "$sess_save_path/sess_$id";
return (string) @file_get_contents($sess_file);
}
//腳本執行結束之前，執行寫入操作
function write($id, $sess_data)
{
echo "sdfsf";
global $sess_save_path;
$sess_file = "$sess_save_path/sess_$id";
if ($fp = @fopen($sess_file, "w")) {
$return = fwrite($fp, $sess_data);
fclose($fp);
return $return;
} else {
return(false);
}
}
function destroy($id)
{
global $sess_save_path;
$sess_file = "$sess_save_path/sess_$id";
return(@unlink($sess_file));
}
function gc($maxlifetime)
{
global $sess_save_path;
foreach (glob("$sess_save_path/sess_*") as $filename) {
if (filemtime($filename) + $maxlifetime < time()) {
@unlink($filename);
}
}
return true;
}
