今天遇到了這個問題，于是研究了一下。要解決這個問題，首先就要明白一些Session的機理。Session在服務(wù)器是以散列表形式存在的，我們都知道Session是會話級的，每個用戶訪問都會生成一個Session。那么服務(wù)器是怎么區(qū)分不同用戶的Session？又是怎么將不同用戶的Session與不同的用戶綁定的呢？下面我們來研究一下，以下純屬我個人的理解，如有錯誤請指證。

Session在服務(wù)器端是以散列表的形式存在的，區(qū)分每一個Session是通過SessionID來實現(xiàn)的，所以可以說這個SessionID是一個Key是一個全局唯一的值。我們可以通過ASP.NET來打印出SessionID，如下代碼：

代碼如下:
protected void Page_Load(object sender, EventArgs e)      
{            
Response.Write(Session.SessionID.ToString());     
}

這樣我們就得到了這樣的值：0julmoedn0kz3gyfnr1vksv0,有點像是GUID，就算不是算法也都是類似的，主要就是為了保證全局唯一性。這樣就達到了區(qū)分不同用戶的Session的目的。接下來還有第二個問題，那就是SessionID有了，但是它又是怎么和相應(yīng)的訪問者（用戶）綁定的呢？比如說用戶A訪問維護了自己的SessionID,用戶B訪問也維護了自己的SessionID。我們都知道web是基于http無鏈接的，他們又是怎么做到的呢？沒錯，答案就是在客戶端存儲了自己的SessionID。瀏覽器存儲SessionID有兩種方式，一種就是利用Cookies;還有一種就是利用url參數(shù)(這種我們不常用,很不友好)。

話題說到Cookies上來了，怎么的？沒想到Session和Cookies還有這樣的關(guān)系吧？(很多人知道，別BS我)沒錯，當我們請求一個URL時候，服務(wù)器會生成一個全局的SessionID，并且把這個值以Cookies的形式保存在客戶端也就是瀏覽器（這里暫不討論url方式）。這樣當用戶再去請求的時候，在http頭把這個SessionID的Cookie發(fā)到服務(wù)器端，服務(wù)器就去找這個SessionID，如果找到了。就證明這個用戶的狀態(tài)是存在的。

知道了這個原理，我們的問題也就有眉頭了，即然是用Cookies來保存SessionID，那么我們就可以在Cooikes上做手腳了。我們都知道Cooikes記錄方式是以域(例如：//www.survivalescaperooms.com/)為區(qū)分的，這也是各種瀏覽器規(guī)定的。如果不這么做，安全性就會有問題。我們要做的就是讓指定Cookies的父域方式，不指定具體指域，這樣Cookies就可以跨子域了。Cookies可以像這樣指定域：

代碼如下:
protected void Page_Load(object sender, EventArgs e)       
{            
Response.Cookies["MyCook"].Domain = ".Vevb.com";   
}

  這樣，我們所有的二級域全部是認這一個主域的，比如a.Vevb.com;b.Vevb.com;user.Vevb.com等等。有了這個認識，我想大家心里也有數(shù)了，該怎么怎么做，但是現(xiàn)在問題是用來生成SessionID的方法是ASP.NET自動實現(xiàn)的，我們又怎么去干涉它呢？這是這樣做的，不主動干涉它，但是我可以操作它的Cookies啊。接下來我們就研究ASP.NET存SessionID的Cooike的名字是什么。經(jīng)過網(wǎng)上很容易就查找到了，名字是：ASP.NET_SessionId，這個就是SessionId的Cookies名字。我們可以在Session_Start中這樣寫：