مقاله کامل آموزش Session در ASP.Net

این مقاله Session در ASP.Net توصیف میکند. انواع مختلف Session و پیکربندی آنها. همچنین Session ها را در Web Farm , Load Balancer و Web Garden scenarios توصیف میکند. پس با من در این آموزش جامع Session  در ASP.Net همراه باشید .توضیح زیادی در اینجا براتون نمینویسم در ادامه میتونید از فهرست استفاده کنید.

جدول عناوین

معرفی

• Session چیست؟
• مزایا و معایب Session
• ذخیره و دریافت مقادیر از Session
• Session ID
• Mode Session و State Provider
  • State Provider
  • رویداد Session
  • Session Mode
    • InProc Session Mode
      • دیدگاهی بر  InProc Session Mode
      • چه زمانی باید از InProc Session استفاده کنیم؟
      • مزایا و معایب
    •  StateServer Session Mode
      • دیدگاهی بر  StateServer Session Mode
      • پیکربندی برای  StateServer Session Mode
      • چگونه  StateServer Session Mode کار میکند؟
      • مثالی از  StateServer Session Mode
      • مزایا و معایب
    •  SQL Server Session Mode
      • چگونه  SQL Server Session Mode کار میکند؟
      • چه زمانی باید از  SQL Server Session Mode استفاده کنیم؟
      • پیکربندی برای  SQL Server Session Mode
      • مزایا و معایب
    •  Custom Session Mode
      • چگونه  Custom Session Mode کار میکند؟
      • چه زمانی باید از  Custom Session Mode استفاده کنیم؟
      • پیکربندی برای  Custom Session Mode
      • مزایا و معایب
• دیدگاهی بر گسترش تولید
  • Application Pool
    • هویت Application Pool
    • ساخت و اختصاص Application Pool
  • Web Garden
    • چگونه Web Garden بسازیم؟
    • چگونه Session به Web Garden بستگی دارد؟
  • Web Farm و Load Balance
    • کنترل Session در Web Farm و Load Balance Scenarios
• Session و Cookies
  • Cookie-Munging چیست؟
  • چگونه Cookie-Munging در ASP.Net کار میکند؟
• حذف Session
• فعال و غیر فعال کردن Session
• جمع بندی

معرفی

قبل از هر چیزی میخواهم از تمام خوانندگانی که مقاله های مرا میخوانند و نظر میدهند تشکر کنم. در سری راهنمایی به مبتدیان من تعدادی مقاله در State Managment نوشته ام. احتمالا این آخرین مقاله ی من در رابطه با State Managment میباشد.

Session چیست؟

وب Stateless است. به این معنا که یک مقدار جدید از هر کلاس Web Page در هر باری که صفحه به سرور فرستاده میشود بازسازی میشود. همانطور که همگی میدانیم HTTP یک پروتکول Stateless است. نمیتواند اطلاعات کاربر را بر روی صفحه نگه دارد. اگر که کاربر اطلاعاتی را وارد کند و به صفحه ی بعدی برود آن اطلاعات از دست میروند و کاربر قادر به بازیابی آن اطلاعات نخواهد بود. در اینجا به چه نیاز داریم ؟ احتیاج به ذخیره کردن اطلاعات داریم. Session امکان ذخیره اطلاعات بر روی حافظه ی سرور را ارائه میدهد. امکان ذخیره سازی هر نوع اشیایی به همراه اشیای اختصاصی خودتان را پشتیبانی میکند. به ازای هر کاربر داده های Session به صورت مجزا ذخیره میشود که به این معناست که داده های Session بر مبنای هر کاربر ذخیره میشوند. به دیاگرام زیر نگاهی بیاندازید :

Fig: به ازای هر کاربر داده های Session به صورت مجزا ذخیره میشود

State Management با استفاده از Session یکی از بهترین مزیت های ASP.Net است زیرا امن است , برای کاربران شفاف است و قادر به ذخیره ی هر نوع شئ در آن هستیم. به همراه این مزایا گاهی اوقات Session ممکن است اشکالات اجرایی در سایت هایی با ترافیک بالا بوجود آورد زیرا ذخیره سازی در حافظه ی سرور انجام میشود و کاربران داده ها را از سرور میخوانند. حال بیایید نگاهی بیاندازیم به مزایا و معایب استفاده از Session در برنامه های وب مان.

مزایا و معایب Session

در زیر مزایا و معایب پایه ای استفاده از Session آمده است. من بعدا آنها را در انواع Session ها به همراه جزئیات توصیف میکنم.

مزایا

به نگه داشتن حالت کاربر و داده در تمام برنامه کمک میکند

به سادگی اجرا میشود و قادر خواهیم بود تا هر نوع شئ را در آن ذخیره کنیم

داده های کاربر را به صورت مجزا ذخیره میکند

Session امن است و برای کاربر کاملا شفاف است.

معایب

اجرای Overhead در مواردی با حجم عظیمی از داده/کاربر زیرا داده های Session در حافظه ی سرور ذخیره میشود.

Overhead شامل مرتب کردن و به هم ریختن داده های Session است زیرا در موارد Mode Session StateServer و SQLServer Session Mode ما نیاز به مرتب سازی اشیا پیش از ذخیره سازی آنها داریم.

به غیر از این ها مزایا و معایب زیادی در Session وجود دارد که مختص به نوع خاص آن Session است. درباره همه ی آنها در بخش های مربوطه توضیح داده ام.

ذخیره و دریافت مقادیر از Session

ذخیره و دریافت مقادیر در Session مشابه به همان در ViewState میباشد. میتوانیم با Session State با کلاس System.Web.SessionState.HttpSessionState ارتباط برقرار کنیم زیرا این شئ Built-in Session را در صفحات ASP.Net ارائه میدهد.

کد زیر برای ذخیره سازی مقادیر در Session استفاده میشود:

//Storing UserName in Session
Session["UserName"] = txtUser.Text;

حال ببینیم که چگونه میتوان مقادیر را از Session دریافت نمود:

//Check weather session variable null or not
if (Session["UserName"] != null)
{
    //Retrieving UserName from Session
    lblWelcome.Text = "Welcome : " + Session["UserName"];
}
else
{
 //Do Something else
}

همچنین میتوانیم اشیا را در Session ذخیره کنیم. مثال زیر نشان میدهد که چگونه یک DataSet را در Session ذخیره کنیم.

//Storing dataset on Session
Session["DataSet"] = _objDataSet;

کد زیر نشان میدهد که چگونه DataSet را از Session دریافت کنیم:

Check weather session variable null or not
if (Session["DataSet"] != null)
{
    //Retrieving UserName from Session
    DataSet _MyDs = (DataSet)Session["DataSet"];
}
else
{
    //Do Something else
}

منبع:

http://msdn.microsoft.com/en-us/library/ms178581.aspx – CodeExamples

Session ID

ASP.Net از یک شناساگر ۱۲۰ بیتی برای ردیابی هر Session استفاده میکند. این به قدر کافی ایمن است و نمیتواند مهندسی معکوس شود. زمانی که یک کاربر با سرور ارتباط برقرار میکند فقط Session ID بین آنها رد و بدل میشود. زمانی که کاربر تقاضای دریافت داده میکند , ASP.Net به دنبال Session ID میگردد و داده های مربوط به آن را دریافت میکند. در گام های زیر این کار را ببینید :

کاربر وارد صفحه میشود و اطلاعات در Session ذخیره میشود.

سرور یک Session ID انحصاری برای آن کاربر میسازد و آن را در Session State Provider ذخیره میکند.

کاربر تقاضای یک سری اطلاعات با Session ID انحصاری از سرور میکند.

سرور درون Session Provider جستجو میکند و داده های مرتب شده از State Server را دریافت میکند و اشیا را تعیین نوع میکند.

به فلوچارت تصویری زیر نگاهی بیاندازید :

Fig:ارتباط بین کاربر , Web ServerوStateProvider

منبع :

http://msdn.microsoft.com/en-us/library/system.web.sessionstate.httpsessionstate.sessionid.aspx

Mode Session و State Provider

در ASP.Net مود های زیر موجود است :

InProc

StateServer

SQLServer

Custom

به ازای هر Session State یک Session Provider وجود دارد. دیاگرام زیر نحوه ی ارتباط آنها را نشان میدهد:

Fig: معماریSession State

میتوانیم Session State Provider را بر اساس Session State ای که انتخاب میکنیم , گزینش کنیم.

زمانی که ASP.Net تقاضای دریافت اطلاعات بر اساس Session ID را میکند , Session State و Provider مربوطه مسئول ارسال اطلاعات صحیح میشوند. جدول زیر Session Mode ها را همراه با نام Provider آنها نشان میدهد :

Session State Mode   –   State Provider

InProc                 –         In-memory object

StateServer         –           Aspnet_state.exe

SQLServer                               –           Database

Custom               –           Custome provider

جدا از آن مود دیگری بنام Off وجود دارد. اگر این گزینه را انتخاب کنیم Session برای برنامه غیرفعال خواهد شد. اما هدف ما استفاده از Session است پس تنها به ۴ مود Session State بالا نگاه می اندازیم:

Session State

اساسا Session State به معنای تمام تنظیماتی است که شما برای برنامه وب تان برای حفط Session وارد کرده اید. Session State خودش به تنهایی چیز بزرگی است. درباره ی پیکربندی همه ی Session هایتان است چه در web.config و چه از code-behind. در web.config , المان های <SessionState> برای تنظیم کردن پیکربندی Session بکار میرود. برخی از آنها Mode , Timeout , StateConnectionString , CustomProvider و غیره میباشد. من در رابطه هر بخش از رشته ی اتصال صحبت کرده ام. قبل از صحبت در رابطه با Session Mode نگاهی بیاندازیم به رویداد های Session.

رویداد های Session

دو نوع رویداد Session در ASP.Net وجود دارد:

Session_Start

Session_End

میتوانید هردو رویداد را در فایل global.aspx برنامه ی وب تان کنترل کنید. هرگاه Session جدیدی آغاز شد رویداد Session_Start فعال میشود و رویداد Session_End زمانی فعال میشود که Session ترک یا منقضی شود.

 

منبع:

http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/iisbook/c06_application_and_session_events.mspx?mfr=true

Session Mode

پیش تر درباره ی Session Mode ها در ASP.Net صحبت کردم. در زیر انواع مختلف Session Mode های موجود در ASP.Net آورده شده است:

Off

InProc

StateServer

SQLServer

Custom

اگر Session را بر روی Mode=”off” در web.config قرار دهیم , Session در برنامه غیرفعال میشود. برای این کار نیاز به پیکربندی web.config مانند زیر داریم:

Mode InProc Session

این یک Mode Session پیش فرض در ASP.Net میباشد. اطلاعات Session را در دامنه ی برنامه ی کنونی ذخیره میکند. این بهترین Mode Session برای اجرای برنامه های وب میباشد. اما عیب اصلی این است که داده ها را درصورت راه اندازی مجدد سرور از دست میدهد. تعداد دیگری معایب و محاسن در InProc Session Mode وجود دارد. جلوتر به آنها میپردازیم.

دیدگاهی بر InProc Session Mode

همانطور که قبلا گفتم در InProc Mode داده های Session بر روی دامنه ی همان برنامه ذخیره میشوند. پس به آسانی و سرعت در دسترس هستند.

InProc Session Mode داده های Session اش را در یک شئ حافظه بر روی دامنه ی برنامه ذخیره میکند. این کار توسط یک پردازش کارگر در application pool انجام میشود. پس اگر ما سرور را مجددا راه اندازی کنیم داده های Session را از دست خواهیم داد. اگر کاربر تقاضای دریافت داده کند , State Provider داده را از یک شئ حافظه داخلی میخواند و آن را به مشتری برمیگرداند. در web.config ما باید Session Mode را ذکر کنیم و همچنین Timeout را نیز تنظیم کنیم.

تنظیمات Session Timeout بالا Session را برای ۳۰ دقیقه پابرجا نگه میدارد. این قابل تغییر از قسمت code-behind نیز است.

Session.TimeOut=30;

دو نوع رویداد Session در ASP.Net وجود دارد: Session_Start() و Session_End() و این تنها مودی است که از رویداد Session_End پشتیبانی میکند. این رویداد پس از آنکه TimeOut به پایان رسید فراخوانی میشود. فلوچارت عمومی برای IncProc Session به صورت زیر خواهد بود:

هرگاه Session_End() فراخوانی شد بر اساس Session timeout خواهد بود. این یک مکانیزم بسیار سریع است زیرا هیچ مرتب سازی برای ذخیره سازی و دریافت داده رخ نمیدهد و داده داخل همان دامنه ی برنامه باقی میماند.

چه زمانی باید از InProc Session Mode استفاده کنیم؟

InProc , Session Mode پیش فرض میباشد. میتواند برای وب سایت ها و جاهایی که استفاده از اعداد کم است بسیار مفید باشد. باید از InProc در Web Garden Scenario دوری کرد ( به این مورد جلوتر خواهیم پرداخت)

مزایا و معایب

مزایا:

داده های Session را در یک شئ حافظه در دامنه ی برنامه ی موجود ذخیره میکند. از این رو دسترسی به داده ها بسیار سریع است و داده ها به راحتی در دسترس خواهند بود.

احتیاجی به مرتب سازی برای ذخیره داده در InProc Session Mode نیست.

سرعت اجرا بسیار بالاست. همانند استفاده از ViewState.

معایب:

با وجود اینکه InProc Session سریع ترین و معمول ترین و مکانیزم پیش فرض است , محدودیت های فراوانی دارد:

اگر پردازش کارگر یا دامنه ی برنامه پاک شود , همه ی داده های Session از بین خواهند رفت.

این که این سریع ترین راه است به این معناست که داده های Session بیشتر و کاربران بیشتری میتوانند بر اجرای آن تاثییر بگذارند به خاطر استفاده از حافظه.

نمیتوانیم از آن در Web Garden Scenario استفاده کنیم.

این Session Mode برای web farm scenarios مناسب نیست.

همانطور که در بحث بالا گفته شد , میتوان نتیجه گیری کرد که InProc یک Session با مکانیزم ذخیره سازی بسیار سریع است اما تنها برای برنامه های وب کوچک مناسب است. داده های InProc Session در صورت راه اندازی مجدد سرور یا پاک کردن دامنه ی برنامه از بین میروند و همچنین برای سناریو های Web Farm و Web Garden مناسب نمیباشد.

حال نگاهی میاندازیم به گزینه ای برای حل این مشکلات. ابتدا با StateServer mode شروع میکنیم.

StateServer Session Mode

دیدگاهی بر StateServer Session mode

این همچنین با نام Out-Proc Session mode نیز شناخته میشود. StateServer از یک سرویس پنجره ی مستقل استفاده میکند که مستقل از IIS است و همچنین میتواند بر روی یک سرور مجزا اجرا شود. این Session State کاملا توسط aspnet_state.exe مدیریت میشود. این سرور ممکن است بر روی سیستمی مشابه اجرا شود اما خارج از دامنه ی برنامه ی اصلی جایی که برنامه ی وب شما در حال اجراست. این به آن معناست که اگر شما پردازش ASP.Net خود را مجددا راه اندازی نمایید , داده های Session شما همچنان وجود خواهند داشت. این روش چندین عیب دارد که ناشی از overhead شدن شامل مرتب سازی و به هم ریختن است. همچنین هزینه ی دسترسی داده ها را افزایش میدهد زیرا هربار که کاربر داده های Session را دریافت میکند برنامه ی ما پردازش متفاوتی را انجام میدهد.

پیکربندی برای StateServer Session Mode

در StateServer mode داده های Session در سرور هایی مجزا ذخیره میشود که مجزا از IIS است و توسط aspnet_state.exe کنترل میشود. این پردازش به عنوان یک سرویس پنجره اجرا میشود. شما میتوانید این سرویس را از پنجره های MMC یا از command prompt اجرا کنید.

به طور پیش فرض “Startup Type” در ASP.Net , state service بر روی دستی تنطیم شده است ; باید آن را بر روی اتوماتیک تنظیم کنیم.

از قسمت command prompt تنها تایپ کنید “net start aspnet_state”. به طور پیش فرض این سرویس به TCP پورت ۴۲۴۲۴ گوش میدهد. اما میتوانیم پورت آن را از قسمت Registry editor همانطور که در شکل زیر نشان داده شده است تغییر دهیم :

حال نگاهی به پیکربندی web.config برای تنظیمات StateServer بیاندازید. برای تنظیمات StateServer ما نیاز داریم تا stateConnectingString را مشخص کنیم. این به سیستم میفهماند که در حال اجرای state server است.به طور پیش فرض stateConnectingString از IP 127.0.0.1 و پورت ۴۲۴۲۴ استفاده میکند.

زمانی که ما در حال استفاده از state server هستیم , میتوانیم پیکربندی خصوصیت stateNetworkTimeOut را برای مشخص کردن حداکثر زمان اتنظار برای پاسخ گویی سرویس قبل از کنسل کردن درخواست را انجام دهیم. مقدار timeout به صورت پیش فرض ۱۰ ثنیه است.

برای استفاده از StateServer اشیایی که ما میخواهیم ذخیره کنیم باید مرتب شده باشند و در زمان دریافت باید آن را به صورت غیر مرتب برگردانیم. من این کار را با یک مثال در زیر توصیف کرده ام.

چگونه StateServer Session Mode کار میکند؟

ما از StateServer Session استفاده میکنیم که تا حد ممکن جلوی از دست رفتن داده های غیرضروری Session را در هنگام راه اندازی مجدد وب سرورمان بگیریم. StateServer توسط aspnet_state.exe حفظ میشود و به عنوان یک پنجره ی سرویس پردازش میشود. این پردازش تمام داده های Session را حفظ میکند. اما در StateServer Session Mode نیاز داریم که داده ها را پیش از ذخیره سازی مرتب کنیم.

همانطور که در شکل بالا میبینید زمانی که کاربر یک درخوایت به سرور میفرستد , وب سرور داده ی Session را در بر روی state server ذخیره میکند. StateServer ممکن است همین سیستم باشد یا سیستم دسگری. اما کاملا مجزا از IIS است. مقصد StateServer به تنظیمات web.config StateConnectionString بستگی دارد. اگر ما آن را بر روی ۱۲۷.۰.۰.۱:۴۲۴۲۴ تنظیم کنیم , خودش داده ها را در یک سیستم محلی ذخیره میکند. برای تغییر مقصد StateServer نیاز به تغییر IP داریم و مطمئن باشید که aspnet_state.exe در حال اجرا بر روی سیستمتان باشد.در غیر اینصورت در هنگام ذخیره ی داده بر روی Session با خطای زیر رو به رو خواهید شد.

زمانی که ما در حال ذخیره ی یک شئ در Session هستیم , باید مرتب شده باشد. آن داده در StateServer system با استفاده از State Provider ذخیره میشود و در زمان دریافت داده , State Provider داده را بازمیگرداند. فلو چارت کامل آن در زیر آمده است :

مثالی از StateServer Session Mode

در اینجا مثالی ساده با استفاده از StateServer session mode آورده شده است. من این نمونه برنامه ی وب را مستقیما بر روی IIS ساخنه ام که به ما در فهم استفاده از آن کمک میکند.

گام اول :

ویژوال استودیو را باز کنید. موقعیتی به عنوان HTTP انتخاب کنید و برنامه ی وب را بسازید.

حال اگر IIS را باز کردید میتوانید یک دایرکتوری مجازی تحت نام برنامه ی وب خودتان بسازید. برای من StateServer است.

گام دوم :

ساخت یک رابط کاربری ساده که شماره ی roll و نام یک دانش آموز را میگیرد. ما نام و شماره roll را در یک state server Session ذخیره میکنیم. همچنین من یک کلاس بنام StudentInfo ساخته ام. این کلاس در زیر آمده است:

[Serializable]
public class StudentInfo
{
    //Default Constructor
    public StudentInfo()
    {
       
    }
    /// <summary>
    /// Create object of student Class
    /// </summary>
    /// <param name="intRoll">Int RollNumber</param>
    /// <param name="strName">String Name</param>
    public StudentInfo(int intRoll, string strName)
    {
        this.Roll = intRoll;
        this.Name = strName;
    }

    private int intRoll;
    private string strName;
    public int Roll
    {
        get
        {
            return intRoll;
        }
        set
        {
            intRoll = value;
        }
    }

    public string Name
    {
        get
        {
            return strName;
        }
        set
        {
            strName = value;
        }
    }
}

حال نگاهی بیاندازید به قسمت code-behind. من دو button افزوده ام : یکی برای ذخیره ی Session و دیگری برای Session.

protected void btnSubmit_Click(object sender, EventArgs e)
{
    StudentInfo _objStudentInfo = 
      new StudentInfo(Int32.Parse( txtRoll.Text) ,txtUserName.Text);
    Session["objStudentInfo"] = _objStudentInfo;
    ResetField();
}
protected void btnRestore_Click(object sender, EventArgs e)
{
    StudentInfo _objStudentInfo = (StudentInfo) Session["objStudentInfo"];
    txtRoll.Text = _objStudentInfo.Roll.ToString();
    txtUserName.Text = _objStudentInfo.Name;
}

 گام سوم :

پیکربندی web.config برای state server را همانطور که قبلا توضیح داده ام انجام دهید و لطفا مطمئن باشید که aspnet_state.exe در حال اجرا بر روی سرور پیکربندی شده باشد.

گام چهارم :

برنامه را اجرا کنید.

داده را وارد کنید و بر روی ثبت کلیک کنید.

چندین تست وجود دارد که من درست کرده ام که کاملا درباره مفید بودن StateServer توضیح داده ام.

نکته ۱ : کلمه ی کلیدی [Serializable] را از کلاس StudentInfo پاک کنید و سعی به لجرا برنامه کنید. اگر بر روی دکمه ی ثبت کلیک کنید با خطای زیر رو به رو خواهید شد :

که به طور واضحی میگوید که که شما باید پیش از ذخیره اشیا آن ها را مرتب سازی نمایید.

نکته ۲ : برنامه را اجرا کنید. داده را با کلیک بر روی ثبت ذخیره نمایید . IIS را مجددا راه اندازی نمایید.

در بخش InProc شما در حال حاضر داده هایتان را از دست داده بودید اما با StateServer با کلیک بر روی بازیابی Session داده های اصلی را دریافت میکنید زیرا داده های State Server به IIS بستگی ندارد. آن را به صورت مجزا نگهداری میکند.

نکته ۳ : aspnet_state.exe را از پنجره ی سرویس MMC متوقف کنید و داده را ذخیره نمایید. خطای زیر را دریافت خواهید کرد :

زیرا پردازشگر State Server شما در حال اجرا نیست. پس لطفا این سه نکته را هرگاه که در حال استفاده از State Server Mode هستید مد نظر داشته باشید.

مزایا و معایب

بر اساس بحث بالا :

مزایا:

داده ها را جرا از IIS نگهداری میکند. پس هر مشکلی که با IIS پیش بیاید تاثیری بر داده های Session نمیگذارد.

مفید برای استفاده در سناریو های web farm و web garden میباشد.

معایب:

پردازش با توجه به مرتب سازی و به هم ریختن در آن کند است.

State Server باید در همه حال در حال اجرا باشد.

من تا همینجا بر روی State Server متوقف میشوم. اما شما میتوانید نکات جالب بیشتری در بخش هایLoad Balance , Web Farm و Web Garden ببینید.

منبع :

http://msdn.microsoft.com/en-us/library/ms178586.aspx

http://msdn.microsoft.com/en-us/library/ms972429.aspx

SQLServer Session Mode

دیدگاهی بر SQL Server Session Mode

این Session Mode مدیریت Session مطمئن تر با امنیت بالاتری را در ASP.Net ارائه میدهد. در این Session Mode داده های Session به صورت مرتب شده و ذخیره شده در یک پایگاه داده ی SQL Server هستند. عیب اصلی این متد ذخیره سازی Session , همان Overhead مرتبط با داده های مرتب شده و به هم ریخته است. این بهترین گزینه برای استفاده در web farm ها میباشد.

برای نصب SQL Server به SQl script های زیر احتیاج دارید :

برای نصب : InstallSqlState.sql

برای پاکسازی : UninstallSqlState.sql

آسان ترین راه برای پیکربندی SQL Server استفاده از دستور aspnet_regsql میباشد.

من کاربرد این فایل ها را با جزئیات در بخش پیکربندی توضیح داده ام. این مفیدترین State management در web farm scenarios است.

چه زمانی باید از SQLServer Session Mode استفاده کنیم؟

SQLServer Session Mode یک State Management ایمن تر و مطمئن تر است.

داده ها را در یک موقعیت متمرکز (پایگاه داده) نگهداری میکند.

زمانی که ایمنی Session برایمان مهم باشد باید از SQL Server Session Mode استفاده کنیم.

اگر در جایی هستید که راه اندازی های مجدد سرور رخ میدهد , یک انتخاب ایده آل است.

یک مود عالی برای web farm و web garden است.(جلوتر به طور کامل توضیح خواهم داد)

میتوانیم از SQLServer Session Mode برای زمانی که میخواهیم Session را بین دو برنامه ی متفاوت به اشتراک بگذاریم , استفاده کنیم.

پیکربندی برای SQLServer Session Mode

در SQLServer Session Mode ما داده های Session را در SQL Server ذخیره میکنیم. پس در ابتدا نیاز داریم که رشته ی اتصالی پایگاه داده در web.config ارائه دهیم. خاصیت sqlConnectionString به همین منظور استفاده میشود.

پس از آنکه رشته ی اتصال را برقرار کردیم باید بدنه ی SQL Server را بسازیم. اکنون توضیح میدهم که این کار با استفاده از دستور aspnet_regsql به چه صورت انجام میشود.

گام اول:

از قسمت command prompt به راهنمای نسخه ی framework بروید.

E.g.: c:\windows\microsoft.net\framework\<version>

گام دوم:

دستور aspnet_regsql  را با پارامتر های زیر اجرا کنید:

 

Parameters	Description
-ssadd	Add support for SQLServer mode session state.
-sstype p	P stands for Persisted. It persists the session data on the server.
-S	Server name.
-U	User name.
-P	Password.

پس از اجرای دستور پیغام زیر را مشاهده میکنید:

همین بود.

گام سوم:

SQL Server management Studio را باز کنید و چک کنید که آیا پایگاه داده جدیدی ASPState ساخته شده است و در آن دو جدول وجود خواهد داشت.

ASPStateTempApplications

ASPStateTempSessions

پیکربندی رشته ی مثال StateServer را تغییر دهید و برنامه ای شبیه آن را اجرا کنید.

تنها شماره ی roll و نام کاربری را ذخیره کنید و بر روی دکمه ی ثبت کلیک کنید. جدول ASPStateTempSessions از SQL Server Management Studio را باز کنید. این هم داده ی Session شما :

حال تست های زیر که قبلا در بخش StateServer Mode توضیح دادم را انجام دهید.

کلمه ی کلیدی Sereialize را از کلاس StydentInfo حذف کنید.

IIS را مجددا راه اندازی کنید و بر روی بازیابی Session کلیک کنید.

SQLServer Service را متوقف کنید.

به نظرم SQL Server Session Mode را به قدر کافی توضیح دادم.

مزایا و معایب

مزایا:

داده های Session در صورت راه اندازی مجدد IIS تاثیر نمیپذیرد.

مطمئن ترین و ایمن ترین Session Management

داده ها را به صورت متمرکز نگهداری میکند و دسترسی به آن از سایر برنامه ها به آسانی انجام میشود.

در سناریو های web farm و web garden بسیار مفید است

معایب:

پردازش در طبیعت بسیار کند است

مرتب سازی و بر هم زنی اشیا منجر به تولید Overhead در برنامه میشود.

در حالی که داده های Session در سروری متفاوت کنترل میشوند باید از SQL Server نیز مراقبت کنیم. باید همیشه در حال اجرا باشد.

منبع:

http://msdn.microsoft.com/en-us/library/ms178586.aspx

Custome Session Mode

دیدگاهی کلی بر Custom Session Mode

به طور معمول ما از InProc , StateServer یا SQLServer Session برای برنامه هایمان استفاده میکنیم اما نیاز داریم که اصول Custom Session Mode را نیز بدانیم. این Session Mode کمی جالب است زیرا Custom Session به ما کنترل کامل برای استفاده از هرچیزی را میدهد حتی Session ID. میتوانید الگوریتم خودتان را برای تولید Session ID بنویسید.

میتوانید Custom Provider را اجرا کنیدکه داده های Session را در یک مکانیزم ذخیره سازی دیگر به سادگی با استخراج از کلاس SessionStateStoreProviderBase ذخیره نمایید. همچنین میتوانید یک Session ID جدید با اجرای ISessionIDManager تولید کنید.

این متد هایی است که در طول اجرای Custom Session فراخوانی میشود.

در متد Initialize میتوانیم یک Custom Provider تنظیم کنیم. این مقداردهی اولیه Connection با Provider انجام میدهد. SetItemExpireCallback برای تنظیم کردن SessionTimeOut استفاده میشود. میتوانیم یک متد ثبت کنیم که در زمان منقضی شدن Session فراخوانی میشود. InitializeRequest برای هر درخواست فراخوانی میشود و CreateNewStoreData نیز برای ساخت یک مقدار از SessionStateStoreData استفاده میشود.

چه زمانی باید از Custom Session Mode استفاده کنیم؟

میتوانیم از custom Mode در موارد زیر استفاده کنیم :

زمانی که میخواهیم داده های Session را در جایی غیر از SQL Server ذخیره نماییم.

زمانی که مجبور به استفاده از جدولی موجود برای ذخیره سازی داده های Session باشیم.

زمانی که نیاز به ساخت Session ID خودمان را داریم.

به چه پیکربندی برای استفاده از آن نیاز داریم؟

نیاز داریم که بدنه ی web.config مان را مانند زیر بسازیم :

اگر بخواهید که در این زمینه بیشتر کاوش کنید میتوانید به قسمت منابع رجوع کنید.

مزایا و معایب

مزایا:

میتوانیم از یک جدول موجود برای ذخیره سازی داده ها در Session استفاده کنیم. این در زمانی که بخواهیم از یک پایگاه داده ی موجود استفاده کنیم , بسیار مفید است.

این به IIS بستگی ندارد. پس راه اندازی مجدد وب سرور تاثیری بر داده های Session ندارد.

میتوانیم الگوریتم خودمان را برای تولید Session ID بسازیم.

معایب:

پردازش داده ها بسیار کند است.

ساختن یک Custom State Provider یک low-level task است که نیاز است با دقت به آن رسیدگی شود تا امنیت آن برقرار شود.

همیشه توصیه میشود که از یک third party provider به جای ساخت توسط خودتان استفاده کنید.

منبع:

http://msdn.microsoft.com/en-us/library/ms178586.aspx

دیدگاهی بر گسترش تولید

محیط تولید جایی است که ما برنامه ی مان را گسترش میدهیم بر یک سرور تولید زنده . این یک چالش بزرگ و اصلی برای web developers برای گسترش برنامه تان بر روی سرور های زنده است زیرا در محیط های تولید بزرگ تعداد زیادی از کاربران وجود دارند و کنترل بارگذاری برای بسیاری از کاربران با یک سرور تنها سخت میباشد. اینجا مفاهیم Web Farm , Load Balance , Web Garden و غیره به میان می آید.

چند ماه پیش من یک برنامه ی وب در محیط تولیدی زنده گسترش دادم که توسط میلیون ها کاربر مورد استفاده قرار گرفت و بیش از ۱۰ Directory instance فعال , بیش از ۱۰ web server در Load Balance و چندین سرور پایگاه داده , سرور تعویض , سرور LCS و غیره در آن وجود داشت. تصویر زیر نشان دهنده ی تولید دیاگرام محیط تولید است.

من سعی میکنم تا سناریو های متفاوت را که شما نیاز به دانستنشان دارید برایتان بگویم در همان حالی که در حال گسترش برنامه تان هستیم.

Application Pool

این یکی از مهمترین چیز هایی است که باید برای محیط تولید برنامه تان بسازید. Application Pool برای جداسازی سری های IIS worker processes که پیکربندی های مشابه را به اشتراک میگذارد. Application Pool به ما این امکان را میدهد تا برنامه ی وب مان را ایزوله کنیم برای امنیت و اطمینان بیشتر و در دسترس بودن بالاتر. پردازش worker به عنوان پردازش مرزی انجام میشود که Application Pool ها را از یکدیگر جدا میکند تا اگر یکی از پردازش های worker یا برنامه به مشکلی برخورد یا حذف شد برنامه ی دیگر یا پردازش worker تاثیری از آن نگیرند.

هویت Application Pool

پیکربندی هویت Application Pool یک وجه مهم از امنیت IIS 6.0 و IIS 7.0 است. زیرا هرگاه پردازش به یک منبع دسترسی داشته باشد , هویت پردازش worker را تعیین میکند. در IIS 7.0 سه هویت از پیش تعریف شده که مشابه همان ها در IIS 6.0 نیز هست وجود دارد.

Application Pool Identity	Description
LocalSystem	Built-in account that has administrative privileges on the server. It can access both local and remote resources. For any kind accessing of server files or resources, we have to set the identity of the application pool to LocalSystem.
LocalServices	Built-in account has privileges of an authenticated local user account. It does not have any network access permission.
NetworkServices	This is the default identity of Application Pool. NetworkServices has the privileges of an authenticated local user account.

ساخت و اختصاص Application Pool

کنسول IIS را باز کنید بر روی فولدر Application Pool راست کلیک کنید و Create New را برگزینید.

Application Pool ID را بدهید و بر روی OK کلیک کنید.

حال بر روی Virtual Directory راست کلیک کنید (من از StateServer web sites استفاده میکنم) و StateServerAppPool را به StateServer Virtual Directory اختصاص دهید.

پس این StateServer web site به طور مستقل با StateServerAppPool اجرا میشود. هر مشکلی مرتبط با برنامه های دیگر بر روی این برنامه تاثیر نمیگذارد. این مزیت اصلی ساخت Application Pool به صورت مجزا است.

Web Garden

به صورت پیش فرض هر Application Pool با یک پردازش Single worker اجرا میشود (W3Wp.exe). میتوانیم چندین پردازش worker را به یک application Pool اختصاص دهیم. یک Application Pool با چندین پردازش worker , Web Garden نامیده میشود. بسیاری از پردازش های worker با همان Application Pool میتواند گاهی اوقات اجرا های سریعتر با زمان پاسخگویی بهتری ارائه دهد و هر پردازش worker باید thread و فصای حافظه ی خودش را داشته باشد.

همانطور که در شکل نشان داده شده است در IIS ممکن است چندین Application Pool وجود داشته باشد و هر application pool حداقل یک پردازش worker خواهد داشت. یک web Garden باید شامل چندین پردازش worker باشد.

محدودیت های معینی در استفاده از Web Garden دربرنامه های وب وجود دارد. اگر ما از InProc Session Mode استفاده کنیم , برنامه مان به درستی کار نمیکند زیرا Session توسط یک پردازش worker متفاوت کنترل میشود. برای رفع این مشکل باید از OutProc Session Mode استفاده کنیم و میتوانیم از Session State Server یا SQL Server Session State استفاده کنیم.

مزیت اصلی:

پردازش worker در web garden تقاضا های دریافتی برای یک Application Pool به خصوص را به اشتراک میگذارد. اگر یک پردازش worker ناموفق باشد یک پردازش worker دیگر میتواند آن پردازش نیمه تمام را به پایان برساند.

چگونه یک Web Garden بسازیم؟

بر روی Application Pool راست کلیک کنید و به تب Performance بروید و بخشWeb Garden را تیک بزنید.(مانند شکل) :

به صورت پیش فرض یکی خواهد بود. فقط آن را به بیشتر از یکی تغییر دهید.

چگونه Session به Web Garden بستگی دارد؟

قبلا توضیح دادم که InProc توسط یک پردازش worker کنترل میشود. داده ها را درون شئ حافظه اش نگهداری میکند. حال اگر ما چندین پردازش worker داشتیم آنگاه بسیار سخت خواهد بود تا Session را کنترل کنیم زیرا هر پردازش worker فضای حافظه ی مربوط به خودش را دارد پس اگر درخواست اول من به WP1 برود و داده های Session مرا نگه دارد و درخواست دوم به WP2 برود. من سعی به دریافت داده های Session میکنم و آن در دسترس نخواهد بود که یک خطا را ارسال خواهد کرد. پس لطفا از Web Garden در InProc Session Mode استفاده نکنید.

میتوانیم از StateServer یا SQL Server Session Mode در Web Garden استفاده کنیم زیرا همانطور که توضیح دادم این دو نوع مود Session بستگی به پردازش worker ندارند. در مثال من همچنین توضیح داده ام که اگر شما IIS را راه اندازی مجدد نمایید همچنان قادر به دسترسی به داده های Session تان هستید.

به طور خلاصه :

Session Mode	Recommended
InProc	No
StateServer	Yes
SQLServer	Yes

Web Farm و Load Balance

این معمول ترین و رایج ترین نظر است که در گسترش محصولات استفاده میشود. این نظرات زمانی میایند که ما از چندین وب سرور برای گسترش برنامه مان استفاده میکنیم. دلیل اصلی استفاده از این ها این است که ما باید بارگذاری را در طول چندین سرور توزیع کنیم. یک Load Balance نیاز است تا توزیع بارگذاری بر روی چندین سرور صورت گیرد.

اگر نگاهی به دیاگرام بالا بیاندازید , کاربر درخواست آدرس میکند و به یک Load Balance ضربه میزند که تصمیم میگیرد به کدام سرور دسترسی پیدا کند. Load Balance ترافیک را در طول تمام وب سرور های مختلف توزیع میکند.

حال این کار چگونه بر Session تاثیر میگذارد؟

کنترل Session در Web Farm و Load Balance scenarios

کنترل Session یکی از چالش برانگیزترین کار ها در web Farm است.

InProc: در InProc Session Mode داده های Session در یک شئ حافظه ی درونی از پردازش worker ذخیره میشود. هر سرور پردازش worker خود را خواهد داشت و داده های Session را در داخل حافظه خودش نگهداری میکند.

اگر یکی از سرور های از کار بیفتد و اگر درخواست به سرور دیگری برود , کاربر قادر نخواهد بود تا داده های Session را دریافت کند. پس توصیه نمیشود که از InProc در web farm استفاده نمایید.

StateServer : پیش تر توضیح دادم که State Server چیست و چگونه یک state Server پیکربندی میشود. برای web Farm Scenarios میتوانید به راحتی درک کنید که این چقدر مهم است زیرا تمام داده های Session در یک مکان ذخیره میشوند.

به یاد داشته باشید در یک web Farm باید مطمئن باشید که شما <machinekey> مشابهی را در همه ی وب سرور هایتان دارید. سایر چیز ها مشابه همان هایی هستند که قبلا توصیف کرده ام. تمام فایل های web.config پیکربندی مشابه (StateConnectionString) برای Session State خواهند داشت.

SQLServer : این یک روش دیگر است و بهترین روشی که میتوانیم در web farm استفاده کنیم. باید ابتدا پایگاه داده را پیکربندی کنیم. گام های مورد نیاز در زیر توضیح داده شده اند.

همانطور که در شکل بالا مشاهده میکنید تمام داده های web server Session در یک پایگاه داده ی سرور SQL ذخیره میشوند. و به راحتی در دسترس هستند. یک چیز را به خاطر بسپارید. باید اشیا را در هر دو حالت StateServer و SQLServer مرتب کنید اگر یکی از وب سرور ها از کار بیفتد , Load Balance بارگذاری را به سرور های دیگر توزیع میکند و کاربر همچنان قادر خواهد بود تا داده های Session را از سرور بخواند زیرا داد ها در یک سرور پایگاه داده ی متمرکز ذخیره شده اند.

به صورت خلاصه میتوانیم هم از StateServer یا SQLServer برای یک web Farm استفاده کنیم و باید از InProc دوری کنیم.

Session و Cookies

کاربران از Cookies برای کار با Session استفاده میکنند. زیرا کاربران باید Session ID ای مناسب برای ارائه با هر درخواستی داشته باشند. میتوانیم این کار را با روش های زیر انجام دهیم:

استفاده از Cookies

ASP.Net یک Cookie ویژه بنام ASP.NET_SessionId به صورت اتوماتیک هربار یک Session Collection استفاده میشود , میسازد. Session ID در طول Cookie انتقال میابد.

Cookie Munging

برخی از مرورگر های قدیمی از Cookies پشتیبانی نمیکنند یا کاربر ممکن است Cookies را در مرورگر غیرفعال کند. در این مورد ASP.Net , Session ID را در یک آدرس اصلاح شده ی خاص (munged) منتقل میکند.

چگونه Cookie Munging کار میکند؟

زمانی که کاربر درخواست صفحه ای را بر روی یک سرور میکند , سرور Session ID را رمزی میکند و آن را به هر لینک HREF درون صفحه اضافه میکند. زمانی که کاربر بر روی لینکی کلیک میکند , ASP.Net آن Session ID را رمزگشایی میکند و آن را به صفحه ای که کاربر درخواست کرده است پاس میدهد. حال صفحه ی درخواست میتواند مقادیر Session را دریافت کند. همه ی این انفاقات به صورت اتوماتیک اتفاق می افتد اگر ASP.Net تشخیص دهد که مرورگر کاربر از Cookies پشتیبانی نمیکند.

چگونه Cookie Munging را اجرا کنیم؟

برای این کار باید Session State مان را به Cookie-less تبدیل کنیم.

حذف Session

در زیر لیست متد های مورد نیاز برای حذف Session آورده شده است.

Method	Description
Session.Remove(strSessionName);	Removes an item from the session state collection.
Session.RemoveAll()	Removes all items from the session collection.
Session.Clear()	Remove all items from session collection. Note: There is no difference between Clear and RemoveAll. RemoveAll() calls Clear() internally.
Session.Abandon()	Cancels the current session.

فعال و غیرفعال کردن Session

برای بهینه سازی اجرا میتوانیم Session را فعال یا غیرفعال کنیم زیرا هر صفحه دسترسی صفحه را که شامل برخی اجرا های over head میشود را میخواند و مینویسد.

پس بهتر است که با توجه به نیازمان از Session فعال و غیر فعال در جای جای برنامه به جای Session های همیشه فعال استفاده کنیم. میتوانیم Session ها را با دو روش فعال و غیرفعال کنیم:

Page level

Application level

Page level

میتوانیم Session State را در سطح صفحه با استفاده از خاصیت EnableSessionState در راهنمای Page غیرفعال کنیم.

این میتواند فعالیت Session را برای آن صفحه ی به خصوص غیرفعال کند.

با همین روش میتوانیم آن را به صورت فقط خواندنی دربیاوریم. این به ما اجازه ی دسترسی به داده های Session را میدهد ولی نمیتوانیم بر روی Session داده ای بنویسیم.

Application level

میتوانیم Session ها را برای کل برنامه ی وب با استفاده از خصوصیت EnableSessionState در web.config غیرفعال کنیم.

به صورت عمومی ما از page level استفاده میکنیم زیرا برخی از صفحات ممکن است اصلا نیازی به داده های Session نداشته باشند یا تنها Session های خواندنی باشند.

منابع:

http://support.microsoft.com/kb/306996

جمع بندی

امیدوارم که اکنون شما با Session ها و کاربرد هایشان و چگونه آنها را در web farm ها و غیره وارد کنیم آشنا شده باشید. برای حمع بندی :

InProc Session Provider سریع ترین است زیرا هرچیزی درون حافظه ذخیره میشود. داده های Session در صورت راه اندازی مجدد سرور یا حذف پردازش worker از بین خواهند رفت. میتوانید از آن در برنامه های کوچک وب جایی که تعداد کاربران کم است استفاده کنید. از InProc در web Farm ها استفاده نکنید.

در StateServer session Mode داده های Session توسط aspnet_State.exe حفظ میشوند. داده های Session را در خارج از وب سرور نگه میدارد. پس هر مشکلی با وب سرور تاثیری بر داده های Session نمیگذارد. احتیاج به مرتب سازی داده ها پیش از ذخیره کردنشان دارید. میتوانیم از آن با امنیت در web Farm استفاده نماییم.

میتوانیم از Custom Provider برای سورس های داده ای اختصاصی استفاده کنیم یا وقتی که میخواهیم از یک جدوا موجود برای ذخیره کردن داده ها در Session استفاده کنیم. همچنین میتوانیم یک Session ID منحصر به فرد بسازیم. اما توصیه نمییشود که Custom Provider منحصر به فرد بسازید. توصیه میشود تا از آن برایthird party provider استفاده کنید.

امیدوارم که شما از این مقاله لذت برده باشید. لطفا نظرات و پیشنهادات خود را برای بهتر شدن آن با من در میان بگذارید. باز هم از شما بابت خواندن این مقاله متشکرم!