會話（session）跟蹤是web程式中常用的技術，用來跟蹤使用者的整個會話。常用的會話跟蹤技術是cookie與session。cookie通過在客戶端記錄資訊確定使用者身份，session通過在伺服器端記錄資訊確定使用者身份。
在程式中，會話跟蹤是很重要的事情。理論上，乙個使用者的所有請求操作都應該屬於同乙個會話，而另乙個使用者的所有請求操作則應該屬於另乙個會話，二者不能混淆。例如，使用者a在超市購買的任何商品都應該放在a的購物車內，不論是使用者a什麼時間購買的，這都是屬於同乙個會話的，不能放入使用者b或使用者c的購物車內，這不屬於同乙個會話。
而web應用程式是使用http協議傳輸資料的。http協議是無狀態的協議。一旦資料交換完畢，客戶端與伺服器端的連線就會關閉，再次交換資料需要建立新的連線。這就意味著伺服器無法從連線上跟蹤會話。即使用者a購買了一件商品放入購物車內，當再次購買商品時伺服器已經無法判斷該購買行為是屬於使用者a的會話還是使用者b的會話了。要跟蹤該會話，必須引入一種機制。
cookie就是這樣的一種機制。它可以彌補http協議無狀態的不足。在session出現之前，基本上所有的**都採用cookie來跟蹤會話。
cookie意為「甜餅」，是由w3c組織提出，最早由netscape社群發展的一種機制。目前cookie已經成為標準，所有的主流瀏覽器如ie、netscape、firefox、opera等都支援cookie。
由於http是一種無狀態的協議，伺服器單從網路連線上無從知道客戶身份。怎麼辦呢？就給客戶端們頒發乙個通行證吧，每人乙個，無論誰訪問都必須攜帶自己通行證。這樣伺服器就能從通行證上確認客戶身份了。這就是cookie的工作原理。
cookie實際上是一小段的文字資訊。客戶端請求伺服器，如果伺服器需要記錄該使用者狀態，就使用response向客 戶端瀏覽器頒發乙個cookie。客戶端瀏覽器會把cookie儲存起來。當瀏覽器再請求該**時，瀏覽器把請求的**連同該cookie一同提交給服務 器。伺服器檢查該cookie，以此來辨認使用者狀態。伺服器還可以根據需要修改cookie的內容。
session 是存放在伺服器端的，類似於session結構來存放使用者資料，當瀏覽器 第一次傳送請求時，伺服器自動生成了乙個session和乙個session id用來唯一標識這個session，並將其通過響應傳送到瀏覽器。當瀏覽器第二次傳送請求，會將前一次伺服器響應中的session id放在請求中一併發送到伺服器上，伺服器從請求中提取出session id，並和儲存的所有session id進行對比，找到這個使用者對應的session。
一般情況下，伺服器會在一定時間內（預設30分鐘）儲存這個 session，過了時間限制，就會銷毀這個session。在銷毀之前，程式設計師可以將使用者的一些資料以key和value的形式暫時存放在這個 session中。當然，也有使用資料庫將這個session序列化後儲存起來的，這樣的好處是沒了時間的限制，壞處是隨著時間的增加，這個資料 庫會急速膨脹，特別是訪問量增加的時候。一般還是採取前一種方式，以減輕伺服器壓力，但現在伺服器已經發展至今，一些session資訊還是綽綽有餘的。。
一般瀏覽器提供了兩種方式來儲存
[1] 使用cookie來儲存，這是最常見的方法，本文「記住我的登入狀態」功能的實現正式基於這種方式的。伺服器通過設定cookie的方式將session id傳送到瀏覽器。如果我們不設定這個過期時間，那麼這個cookie將不存放在硬碟上，當瀏覽器關閉的時候，cookie就消失了，這個session id就丟失了。如果我們設定這個時間為若干天之後，那麼這個cookie會儲存在客戶端硬碟中，即使瀏覽器關閉，這個值仍然存在，下次訪問相應**時，同 樣會傳送到伺服器上。
cookie資料儲存在客戶端，session資料儲存在伺服器端。
簡 單的說，當你登入乙個**的時候，如果web伺服器端使用的是session,那麼所有的資料都儲存在伺服器上面，客戶端每次請求伺服器的時候會傳送 當前會話的sessionid，伺服器根據當前sessionid判斷相應的使用者資料標誌，以確定使用者是否登入，或具有某種許可權。由於資料是儲存在伺服器 上面，所以你不能偽造，但是如果你能夠獲取某個登入使用者的sessionid，用特殊的瀏覽器偽造該使用者的請求也是能夠成功的。sessionid是服務 器和客戶端鏈結時候隨機分配的，一般來說是不會有重複，但如果有大量的併發請求，也不是沒有重複的可能性。
如果瀏覽器使用的是 cookie，那麼所有的資料都儲存在瀏覽器端，比如你登入以後，伺服器設定了 cookie使用者名稱(username),那麼，當你再次請求伺服器的時候，瀏覽器會將username一塊傳送給伺服器，這些變數有一定的特殊標記。服 務器會解釋為 cookie變數。所以只要不關閉瀏覽器，那麼 cookie變數便一直是有效的，所以能夠保證長時間不掉線。如果你能夠截獲某個使用者的 cookie變數，然後偽造乙個資料報傳送過去，那麼伺服器還是認為你是合法的。所以，使用 cookie被攻擊的可能性比較大。如果設定了的有效時間，那麼它會將 cookie儲存在客戶端的硬碟上，下次再訪問該**的時候，瀏覽器先檢查有沒有 cookie，如果有的話，就讀取該 cookie，然後傳送給伺服器。如果你在機器上面儲存了某個論壇 cookie，有效期是一年，如果有人入侵你的機器，將你的 cookie拷走，然後放在他的瀏覽器的目錄下面，那麼他登入該**的時候就是用你的的身份登入的。所以 cookie是可以偽造的。當然，偽造的時候需要主意，直接copy cookie檔案到 cookie目錄，瀏覽器是不認的，他有乙個index.dat檔案，儲存了 cookie檔案的建立時間，以及是否有修改，所以你必須先要有該**的 cookie檔案，並且要從保證時間上騙過瀏覽器，
ession是由應用伺服器維持的乙個伺服器端的儲存空間，使用者在連線伺服器時，會由伺服器生成乙個唯一的sessionid,用該sessionid 為識別符號來訪問伺服器端的session儲存空間。而sessionid這一資料則是儲存到客戶端，用cookie儲存的，使用者提交頁面時，會將這一 sessionid提交到伺服器端，來訪問session資料。這一過程，是不用開發人員干預的。所以一旦客戶端禁用cookie，那麼session也會失效。
伺服器也可以通過url重寫的方式來傳遞sessionid的值，因此不是完全依賴cookie。如果客戶端cookie禁用，則伺服器可以自動通過重寫url的方式來儲存session的值，並且這個過程對程式設計師透明。
可以試一下，即使不寫cookie，在使用request.getcookies();取出的cookie陣列的長度也是1，而這個cookie的名字就是jsessionid，還有乙個很長的二進位制的字串，是sessionid的值。
cookies是屬於session物件的一種。但有不同，cookies不會佔伺服器資源，是存在客服端記憶體或者乙個cookie的文字檔案中；而「session」則會占用伺服器資源。所以，盡量不要使用session，而使用cookies。但是我們一般認為cookie是不可靠的，session是可靠地，但是目前很多著名的站點也都以來cookie。有時候為了解決禁用cookie後的頁面處理，通常採用url重寫技術，呼叫session中大量有用的方法從session中獲取資料後置入頁面。
（二）：另乙個重要的應用是「購物車」中類的處理和設計。使用者可能在一段時間內在同一家**的不同頁面選擇不同的商品，可以將這些資訊都寫入cookie，在最後付款時從cookie中提取這些資訊，當然這裡面有了安全和效能問題需要我們考慮了。
cookie與session的關聯
前提 cookie沒有被禁用。當用瀏覽器登入到某 伺服器時，先找對應的cookie檔案，當首次訪問是當然沒有cookie檔案，所以在請求頭部中沒有cookie的內容，即在請求頭部中沒有類似cookie jsessionid 的內容，這時當請求到達伺服器後，伺服器看請求頭中沒有jsessionid值，...
session與cookie的區別
讓我們用幾個例子來描述一下cookie和session機制之間的區別與聯絡。筆者曾經常去的一家咖啡店有喝5杯咖啡免費贈一杯咖啡的優惠，然而一次性消費5杯咖啡的機會微乎其微，這時就需要某種方式來紀錄某位顧客的消費數量。想象一下其實也無外乎下面的幾種方案 1 該店的店員很厲害，能記住每位顧客的消費數量，...
session與cookie的區別
1 session儲存在伺服器，客戶端不知道其中的資訊 cookie儲存在客戶端，伺服器能夠知道其中的資訊。2 session中儲存的是物件，cookie中儲存的是字串。3 session不能區分路徑，同乙個使用者在訪問乙個 期間，所有的session在任何乙個地方都可以訪問到。而cookie中如果...