session ID or session token is a piece of data that is used in network communications (often over HTTP) to identify a session, a series of related message exchanges. Session identifiers become necessary in cases where the communications infrastructure uses a stateless protocol such as HTTP. For example, a buyer who visits a seller's site wants to collect a number of articles in a virtual shopping cart and then finalize the shopping by going to the site's checkout page. This typically involves an ongoing communication where several webpages are requested by the client and sent back to them by the server. In such a situation, it is vital to keep track of the current state of the shopper's cart, and a session ID is one way to achieve that goal.
A session ID is typically granted to a visitor on his first visit to a site. It is different from a user ID in that sessions are typically short-lived (they expire after a preset time of inactivity which may be minutes or hours) and may become invalid after a certain goal has been met (for example, once the buyer has finalized his order, he cannot use the same session ID to add more items).【短時間存在】
As session IDs are often used to identify a user that has logged into a website, they can be used by an attacker to hijack the session and obtain potential privileges. A session ID is often a long randomly-generated string to decrease the probability of obtaining a valid one by means of a brute-force search. Many servers perform additional verification of the client, in case the attacker has obtained the session ID. Locking a session ID to the client's IP address is a simple and effective measure as long as the attacker cannot connect to the server from the same address.
A session token is a unique identifier, usually in the form of a hash generated by a hash function that is generated and sent from a server to a client to identify the current interaction session. The client usually stores and sends the token as an HTTP cookie and/or sends it as a parameter in GET or POST queries. The reason to use session tokens is that the client only has to handle the identifier (a small piece of data which is otherwise meaningless and thus presents no security risk) - all session data is stored on the server (usually in a database, to which the client does not have direct access) linked to that identifier. There are many drawbacks of session id and it's not enough to fulfill the developer requirements.[vague] Many developers use other logic to identify the session.
具體來說cookie機制采用的是在客戶端保持狀態的方案。它是在用戶端的會話狀態的存貯機制，他需要用戶打開客戶端的cookie支持。cookie的作用就是為了解決HTTP協議無狀態的缺陷所作的努力.
而session機制采用的是一種在客戶端與服務器之間保持狀態的解決方案。同時我們也看到，由於采用服務器端保持狀態的方案在客戶端也需要保存一個標識，所以session機制可能需要借助於cookie機制來達到保存標識的目的。而session提供了方便管理全局變量的方式
session是針對每一個用戶的，變量的值保存在服務器上，用一個sessionID來區分是哪個用戶session變量,這個值是通過用戶的瀏覽器在訪問的時候返回給服務器，當客戶禁用cookie時，這個值也可能設置為由get來返回給服務器。
就安全性來說：當你訪問一個使用session 的站點，同時在自己機子上建立一個cookie，建議在服務器端的SESSION機制更安全些.因為它不會任意讀取客戶存儲的信息。
cookie機制。正統的cookie分發是通過擴展HTTP協議來實現的，服務器通過在HTTP的響應頭中加上一行特殊的指示以提示
瀏覽器按照指示生成相應的cookie。然而純粹的客戶端腳本如JavaScript或者VBScript也可以生成cookie。而cookie的使用
是由瀏覽器按照一定的原則在后台自動發送給服務器的。瀏覽器檢查所有存儲的cookie，如果某個cookie所聲明的作用范圍
大於等於將要請求的資源所在的位置，則把該cookie附在請求資源的HTTP請求頭上發送給服務器。
cookie的內容主要包括：名字，值，過期時間，路徑和域。路徑與域一起構成cookie的作用范圍。若不設置過期時間，則表示這
個cookie的生命期為瀏覽器會話期間，關閉瀏覽器窗口，cookie就消失。這種生命期為瀏覽器會話期的cookie被稱為會話cookie。
會話cookie一般不存儲在硬盤上而是保存在內存里，當然這種行為並不是規范規定的。若設置了過期時間，瀏覽器就會把cookie
保存到硬盤上，關閉后再次打開瀏覽器，這些cookie仍然有效直到超過設定的過期時間。存儲在硬盤上的cookie可以在不同的瀏
覽器進程間共享，比如兩個IE窗口。而對於保存在內存里的cookie，不同的瀏覽器有不同的處理方式
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，而。比如weblogic對於web應用程序生成的cookie，JSESSIONID= ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764，它的名字就是 JSESSIONID。
由於cookie可以被人為的禁止，必須有其他機制以便在cookie被禁止時仍然能夠把session id傳遞回服務器。經常被使用的一種技術叫做URL重寫，就是把session id直接附加在URL路徑的后面，附加方式也有兩種，一種是作為URL路徑的附加信息，表現形式為http://...../xxx;jsessionid= ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764
另一種是作為查詢字符串附加在URL后面，表現形式為http://...../xxx?jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764
這兩種方式對於用戶來說是沒有區別的，只是服務器在解析的時候處理的方式不同，采用第一種方式也有利於把session id的信息和正常程序參數區分開來。
為了在整個交互過程中始終保持狀態，就必須在每個客戶端可能請求的路徑后面都包含這個session id。
另一種技術叫做表單隱藏字段。就是服務器會自動修改表單，添加一個隱藏字段，以便在表單提交時能夠把session id傳遞回服務器。比如下面的表單
<form name="testform" action="/xxx">
<input type="text">
</form>
在被傳遞給客戶端之前將被改寫成
<form name="testform" action="/xxx">
<input type="hidden" name="jsessionid" value="ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764">
<input type="text">
</form>
這種技術現在已較少應用，筆者接觸過的很古老的iPlanet6(SunONE應用服務器的前身)就使用了這種技術。
實際上這種技術可以簡單的用對action應用URL重寫來代替。
在談論session機制的時候，常常聽到這樣一種誤解“只要關閉瀏覽器，session就消失了”。其實可以想象一下會員卡的例子，除非顧客主動對店家提出銷卡，否則店家絕對不會輕易刪除顧客的資料。對session來說也是一樣的，除非程序通知服務器刪除一個session，否則服務器會一直保留，程序一般都是在用戶做log off的時候發個指令去刪除session。然而瀏覽器從來不會主動在關閉之前通知服務器它將要關閉，因此服務器根本不會有機會知道瀏覽器已經關閉，之所以會有這種錯覺，是大部分session機制都使用會話cookie來保存session id，而關閉瀏覽器后這個 session id就消失了，再次連接服務器時也就無法找到原來的session。如果服務器設置的cookie被保存到硬盤上，或者使用某種手段改寫瀏覽器發出的HTTP請求頭，把原來的session id發送給服務器，則再次打開瀏覽器仍然能夠找到原來的session。
恰恰是由於關閉瀏覽器不會導致session被刪除，迫使服務器為seesion設置了一個失效時間，當距離客戶端上一次使用session的時間超過這個失效時間時，服務器就可以認為客戶端已經停止了活動，才會把session刪除以節省存儲空間。
http是無狀態的協議，客戶每次讀取web頁面時，服務器都打開新的會話，而且服務器也不會自動維護客戶的上下文信息，那么要怎么才能實現網上商店中的購物車呢，session就是一種保存上下文信息的機制，它是針對每一個用戶的，變量的值保存在服務器端，通過SessionID來區分不同的客戶,session是以cookie或URL重寫為基礎的，默認使用cookie來實現，系統會創造一個名為JSESSIONID的輸出cookie，我們叫做session cookie,以區別persistent cookies,也就是我們通常所說的cookie,注意session cookie是存儲於瀏覽器內存中的，並不是寫到硬盤上的，這也就是我們剛才看到的JSESSIONID，我們通常情是看不到JSESSIONID的，但是當我們把瀏覽器的cookie禁止后，web服務器會采用URL重寫的方式傳遞Sessionid，我們就可以在地址欄看到sessionid=KWJHUG6JJM65HS2K6之類的字符串。
明白了原理，我們就可以很容易的分辨出persistent cookies和session cookie的區別了，網上那些關於兩者安全性的討論也就一目了然了，session cookie針對某一次會話而言，會話結束session cookie也就隨着消失了，而persistent cookie只是存在於客戶端硬盤上的一段文本（通常是加密的），而且可能會遭到cookie欺騙以及針對cookie的跨站腳本攻擊，自然不如session cookie安全了。
通常session cookie是不能跨窗口使用的，當你新開了一個瀏覽器窗口進入相同頁面時，系統會賦予你一個新的sessionid，這樣我們信息共享的目的就達不到了，此時我們可以先把sessionid保存在persistent cookie中，然后在新窗口中讀出來，就可以得到上一個窗口SessionID了，這樣通過session cookie和persistent cookie的結合我們就實現了跨窗口的session tracking（會話跟蹤）。
在一些web開發的書中，往往只是簡單的把Session和cookie作為兩種並列的http傳送信息的方式，session cookies位於服務器端，persistent cookie位於客戶端，可是session又是以cookie為基礎的，明白的兩者之間的聯系和區別，我們就不難選擇合適的技術來開發web service了。
cookie與session的區別是， 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文件，並且要從保證時間上騙過瀏覽器，曾經在學校的vbb論壇上面做過試驗，copy別人的 cookie登錄，冒用了別人的名義發帖子，完全沒有問題。
cookie 和session 的區別
1、cookie數據存放在客戶的瀏覽器上，session數據放在服務器上。
2、cookie不是很安全，別人可以分析存放在本地的COOKIE並進行COOKIE欺騙
考慮到安全應當使用session
3、session會在一定時間內保存在服務器上。當訪問增多，會比較占用你服務器的性能
考慮到減輕服務器性能方面，應當使用COOKIE
4、單個cookie在客戶端的限制是3K，就是說一個站點在客戶端存放的COOKIE不能3K。
5、所以個人建議：
將登陸信息等重要信息存放為SESSION
其他信息如果需要保留，可以放在COOKIE中
比喻：
Cookie：
發給顧客一張卡片，上面記錄着消費的數量，一般還有個有效期限。每次消費時，如果顧客出示這張卡片，則此次消費就會與以前或以后的消費相聯系起來。這種做法就是在客戶端保持狀態。 【卡上記錄所有信息，而店家只認卡不認人。】
Session：
發給顧客一張會員卡，除了卡號之外什么信息也不紀錄，每次消費時，如果顧客出示該卡片，則店員在店里的紀錄本上找到這個卡號對應的紀錄添加一些消費信息。這種做法就是在服務器端保持狀態。 【只記用戶ID，而ID的詳細記錄放在店家的數據庫里；每次憑ID檢索服務器的記錄。】
【 這里用一個形象的比喻來解釋session的工作方式。假設Web Server是一個商場的存包處，HTTP Request是一個顧客，第一次來到存包處，管理員把顧客的物品存放在某一個櫃子里面（這個櫃子就相當於Session），然后把一個號碼牌交給這個顧客，作為取包憑證（這個號碼牌就是Session ID）。顧客（HTTP Request）下一次來的時候，就要把號碼牌（Session ID）交給存包處（Web Server）的管理員。管理員根據號碼牌（Session ID）找到相應的櫃子（Session），根據顧客（HTTP Request）的請求，Web Server可以取出、更換、添加櫃子（Session）中的物品，Web Server也可以讓顧客（HTTP Request）的號碼牌和號碼牌對應的櫃子（Session）失效。顧客（HTTP Request）的忘性很大，管理員在顧客回去的時候（HTTP Response）都要重新提醒顧客記住自己的號碼牌（Session ID）。這樣，顧客（HTTP Request）下次來的時候，就又帶着號碼牌回來了。 我們可以看到，Session ID實際上是在客戶端和服務端之間通過HTTP Request和HTTP Response傳來傳去的。】
為什么登陸后,只要不關閉瀏覽器,session就能一直存在?當然session的數據是保存在服務器上的,但服務器是怎么識別這些數據都是誰的呢?
答 案是sessionid,每一個瀏覽者都唯一的sessionid,這就很好的區分了不同瀏覽者的不同session了.
sessionid是怎么產生 的?
應該是第一次訪問服務器的時候隨即生成的.假如是111,然后他的登陸信息是true,服務器就知道sessionid為111已經登陸了,這些信息 都存在了服務器上了.
但當瀏覽者繼續操作的時候,也就是打開該系統的另一個頁面的時候sessionid怎么辦?如何傳遞?
打開另一個頁面的時候其實相當 於重新訪問系統,如果沒有特殊的處理機制,系統會再次重新分配一個sessionid的,這樣的話就失去意義了~!所以sessionid在第一次訪問后 應該存在了客戶端.
能寸哪呢?
當然,只能寸在cookie中了,這就是為什么關閉cookie,session就失去作用了
找到這么個例子來描述cookie session的關系再恰當不過了
一家咖啡店有喝5杯咖啡免費贈一杯咖啡的優惠，然而一次性消費5杯咖啡的機會微乎其微，這時就需要某種方式來紀錄某位顧客的消費數量。想象一下其實也無外乎下面的幾種方案：
1、該店的店員很厲害，能記住每位顧客的消費數量，只要顧客一走進咖啡店，店員就知道該怎么對待了。這種做法就是協議本身支持狀態。
2、發給顧客一張卡片，上面記錄着消費的數量，一般還有個有效期限。每次消費時，如果顧客出示這張卡片，則此次消費就會與以前或以后的消費相聯系起來。這種做法就是在客戶端保持狀態。
3、發給顧客一張會員卡，除了卡號之外什么信息也不紀錄，每次消費時，如果顧客出示該卡片，則店員在店里的紀錄本上找到這個卡號對應的紀錄添加一些消費信息。這種做法就是在服務器端保持狀態。
第 一種情況暫時不考慮.看第二種情況,卡片無疑就是cookie了,所有的數據如果都存在卡片上是不安全的,也是容易遺失的(卡片被修改了?卡片遺失了?這 都是有可能的).所以才用了第三種情況.客戶除了個會員號再什么信息也沒有,這是最安全的,但這個會員號必須是客戶自己知道的!也就是cookie中必須 存儲的.
個人理解:
cookie會較長時間留在客戶端硬盤里，session是在會話期內有效。Used by browser to keep the state
session可由cookie carry給服務器，就是session搭cookie的車。
session可用於hold住購物車等。
http://www.cnblogs.com/shiyangxt/archive/2008/10/07/1305506.html
http://cmjcmj8080.iteye.com/blog/901509
http://www.360doc.com/content/06/0503/12/73_109481.shtml
http://cs-pages.blogspot.com/2011/05/difference-between-cookies-and-sessions.html 例子