Session:

Session是“會話”的意思，然而，因為http協議是無狀態的，那麽每次客戶端請求服務器端，服務器端都會以“嶄新”的頁面展示給客戶端，這在靜態的html頁面中是不會存在任何影響，但是在動態頁面中，需要與用戶交互，要保持與客戶端用戶的聯系，則需要一些東西來保持，而Session的話，則是具有“保持狀態，保持會話”的能力。

註意的是，Session是保存在服務器端的。（Cookie是保存在客戶端的）需要註意的是，如果用戶突然關閉了客戶端頁面，那麽Session就會丟失，即“會話丟失”。

服務器端創建session的三個步驟（網上參考）：

1. 生成全局唯一標識符（sessionid）；

2. 開辟數據存儲空間。一般會在內存中創建相應的數據結構，但這種情況下，系統一旦掉電，所有的會話數據就會丟失，如果是電子商務網站，這種事故會造成嚴重的後果。不過也可以寫到文件裏甚至存儲在數據庫中，這樣雖然會增加I/O開銷，但session可以實現某種程度的持久化，而且更有利於session的共享；

3. 將session的全局唯一標示符發送給客戶端。

問題的關鍵就在服務端如何發送這個session的唯一標識上。聯系到HTTP協議，數據無非可以放到請求行、頭域或Body裏，基於此，一般來說會有兩種常用的方式：cookie和URL重寫。

1. Cookie（sessionid會保存在Cookie裏，並且失效時間為0，就是瀏覽器進程的有效時間，如果關閉了瀏覽器，那麽session就會失效，原理就是如此）

讀者應該想到了，對，服務端只要設置Set-cookie頭就可以將session的標識符傳送到客戶端，而客戶端此後的每一次請求都會帶上這個標識符，由於cookie可以設置失效時間，所以一般包含session信息的cookie會設置失效時間為0，即瀏覽器進程有效時間。至於瀏覽器怎麽處理這個0，每個瀏覽器都有自己的方案，但差別都不會太大（一般體現在新建瀏覽器窗口的時候）；

2. URL重寫（平時網上url地址上有 ?sessionID=xxxx 字樣）

所謂URL重寫，顧名思義就是重寫URL。試想，在返回用戶請求的頁面之前，將頁面內所有的URL後面全部以get參數的方式加上session標識符（或者加在path info部分等等），這樣用戶在收到響應之後，無論點擊哪個鏈接或提交表單，都會在再帶上session的標識符，從而就實現了會話的保持。讀者可能會覺得這種做法比較麻煩，確實是這樣，但是，如果客戶端禁用了cookie的話，URL重寫將會是首選。

Session在ASP.Net的基本用法

定義的時候： Session["ddd"]=xxxx;

使用的時候：Session["ddd"]即可

如果需要保存類的對象的話，用法跟ViewState是一樣的：

發送端：

UserInfo ui = new UserInfo();
Session["ui"] = ui;
ui.name = name.Text;
ui.age = age.Text;
ui.sex = sex.Text;
ui.password = password.Text;
Response.Redirect("a.aspx");

接收端：

UserInfo ui = Session["ui"] as UserInfo;
name.Text = ui.name;
age.Text = ui.age;
password.Text = ui.password;
sex.Text = ui.sex;

Session時間（銷毀方式：超時和手動銷毀）：

asp.net Session的默認時間設置是20分鐘，即超過20分鐘後,服務器會自動放棄Session信息.

Session Hijack （網上參考）：

Session hijack即會話劫持是一種比較嚴重的安全威脅，也是一種廣泛存在的威脅，在session技術中，客戶端和服務端通過傳送session的標識符來維護會話，但這個標識符很容易就能被嗅探到，從而被其他人利用，這屬於一種中間人攻擊。

Cookie

cookie的最大好處使用的就是"Remember Me"的服務。

cookie保存在客戶端，如果用戶禁用了cookie的話，可能會存在一些問題，所以在設計的時候要註意（判斷cookie是否為null）

需要cookie的原因跟需要session一樣，因為http協議是無狀態的，每次都是新的頁面，不會保存任何信息，而cookie的話，會保存在客戶端的電腦上，那麽到時需要用的時候，可以利用後臺的服務器端調用，也可以就用客戶端來進行調用。

Cookie只是一段文本，所以它只能保存字符串。而且瀏覽器對它有大小限制以及 它會隨著每次請求被發送到服務器，所以應該保證它不要太大。 Cookie的內容也是明文保存的，有些瀏覽器提供界面修改，所以， 不適合保存重要的或者涉及隱私的內容。（網上參考）

Cookie的限制：

大多數瀏覽器支持最大為 4096 字節的 Cookie。由於這限制了 Cookie 的大小，最好用 Cookie 來存儲少量數據，或者存儲用戶 ID 之類的標識符。用戶 ID 隨後便可用於標識用戶，以及從數據庫或其他數據源中讀取用戶信息。 瀏覽器還限制站點可以在用戶計算機上存儲的 Cookie 的數量。大多數瀏覽器只允許每個站點存儲 20 個 Cookie；如果試圖存儲更多 Cookie，則最舊的 Cookie 便會被丟棄。有些瀏覽器還會對它們將接受的來自所有站點的 Cookie 總數作出絕對限制，通常為 300 個。

Cookie中的屬性：（網上參考）

name: 每個cookie由一個唯一的名稱代表，這個名稱可以包含字母、數字、下劃線。cookie的名稱是不分大小寫，所以mycookie和MyCookie是一樣。但考慮到服務器端語言可能區分大小寫，建議定義和使用時還是區分大小寫。

value: 保存在cookie中的字符串值。這個值在存儲之前必須使用encodeURIComponent()對其進行編碼，以免丟失數據或占用了cookie。註意：cookie名字和值加起來的字節數不能超過4095字節，也即4KB。

domain: 出於安全考慮，網站不能訪問由其他域所創建的cookie。創建cookie以後，域的信息會作為cookie的一部分存儲下來。關於域，這裏給一個例子，如http://ibm.com/foo/index.aspx, 它的域為：ibm.com。

path: cookie的另一個安全特征，限制對web服務器上特定目錄的訪問。即控制哪些訪問能觸發發送.例如請求的地址是上面的url,如果path=/foo,這個cookie就會被發送,但是path為其他的話,該cookie會被忽略。

expires: cookie的過期時間。

secure: 一個true/false值，用於表示cookie是否只能從安全網站（使用SSL和https協議的網站）中訪問。如果這個值被設置為true

Cookie的基本步驟：（網上參考）

瀏覽器對於Web服務器應答包頭中Cookie的操作步驟：

a. 從Web服務器的應答包頭中提取所有的cookie。

b. 解析這些cookie的組成部分（名稱，值，路徑等等）。

c. 判定主機是否允許設置這些cookie。允許的話，則把這些cookie存儲在本地。

瀏覽器對Web服務器請求包頭中所有的cookie進行篩選的步驟：

a. 根據請求的url和本地存儲cookie的屬性，判斷那些cookie能被發送給Web服務器。

b. 對於多個cookie，判定發送的順序。
c. 把需要發送的cookie加入到請求http包頭中一起發送。

Cookie在ASP.Net中的基本用法：

發送端：

HttpCookie cookie = new HttpCookie("UserInfo");

cookie["name"] = name.Text;

cookie["age"] = age.Text;

cookie["sex"] = sex.Text;

cookie["language"] = language.Text;

cookie.Expires = DateTime.MaxValue;

Response.Cookies.Add(cookie);

Response.Redirect("cookie2.aspx");

接收端：

HttpCookie cookie = Request.Cookies["UserInfo"];

if(cookie!=null)

{

name.Text = cookie["name"];
age.Text = cookie["age"];
language.Text = cookie["language"];
sex.Text = cookie["sex"];

}

else

{ }

最好在接收端上加上一個條件判斷，這樣則避免如果禁用了cookie，就不會導致出錯，也可以確定cookie是否存在。

Cookie的用途：

防止網上重復投票；
通過cookie實現自動登陸
單點登陸 ( Single Sign On, SSO)，是目前比較流行的企業業務整合的解決方案之一. 簡單的說, 就是在多個應用系統中，用戶只需要登錄一次就可以訪問所有相互信任的應用系統。它包括可以將這次主要的登錄映射到其他應用中用於同一個用戶的登錄的機制。

Session和Cookie比較：（網上參考）

1. 應用場景

Cookie的典型應用場景是Remember Me服務，即用戶的賬戶信息通過cookie的形式保存在客戶端，當用戶再次請求匹配的URL的時候，賬戶信息會被傳送到服務端，交由相應的程序完成自動登錄等功能。當然也可以保存一些客戶端信息，比如頁面布局以及搜索歷史等等。

Session的典型應用場景是用戶登錄某網站之後，將其登錄信息放入session，在以後的每次請求中查詢相應的登錄信息以確保該用戶合法。當然還是有購物車等等經典場景；

2. 安全性

cookie將信息保存在客戶端，如果不進行加密的話，無疑會暴露一些隱私信息，安全性很差，一般情況下敏感信息是經過加密後存儲在cookie中，但很容易就會被竊取。而session只會將信息存儲在服務端，如果存儲在文件或數據庫中，也有被竊取的可能，只是可能性比cookie小了太多。

Session安全性方面比較突出的是存在會話劫持的問題，這是一種安全威脅，這在下文會進行更詳細的說明。總體來講，session的安全性要高於cookie；

3. 性能

Cookie存儲在客戶端，消耗的是客戶端的I/O和內存，而session存儲在服務端，消耗的是服務端的資源。但是session對服務器造成的壓力比較集中，而cookie很好地分散了資源消耗，就這點來說，cookie是要優於session的；

4. 時效性

Cookie可以通過設置有效期使其較長時間內存在於客戶端，而session一般只有比較短的有效期（用戶主動銷毀session或關閉瀏覽器後引發超時）；

5. 其他

Cookie的處理在開發中沒有session方便。而且cookie在客戶端是有數量和大小的限制的，而session的大小卻只以硬件為限制，能存儲的數據無疑大了太多。

關於Session和Cookie兩方面的知識還有太多太多要學，現在理解只是皮毛。

網上資源來自：

http://www.cnblogs.com/shoru/archive/2010/02/19/1669395.html 大話session

http://www.cnblogs.com/fish-li/archive/2011/07/03/2096903.html 細說cookie

http://www.cnblogs.com/langzi127/archive/2009/04/08/1431730.html cookie的應用

文章來自：http://www.cnblogs.com/japanbbq/archive/2011/08/31/2160494.html

Session與Cookie