وقتی درخواستی از سمت client به سمت server می رسد، پردازش ها بسیاری بر روی درخواست توسط IIS قبل از ارسال پاسخ به کاربر صورت می پذیرند. در این مقاله سعی بر شرح Page Life Cycle صفحات ASP.NET نمی باشد و تماما مربوط به پردازش های سطح IIS می باشد.
قبل از وارد شد به جزئیات، ابتدا مفاهیم ابتدایی را مطرح می کنیم تا همه با هر سطح اطلاعات بتوانند تمامی جزئیات مربوطه را متوجه شوند.
وب سرور چیست؟
وقتی وب اپلیکیشن ASP.NET خود را در محیط Visual Studio اجرا می کنید، Integrated ASP.NET Engine مسئولیت پردازش تمامی درخواست و response های ASP.NET را برعهده دارد. در واقع پردازش گر WebDev.WebServer.Exe می باشد که پیگیری تمای درخواست و response های وب اپلیکیشن ای که در محیط Visual Studio در حال اجرا می باشد را بر عهده دارد.
وقتی قرار باشد تا اپلیکیشن خود را در یک مکان مرکزی با امکان دسترسی از هرجای دنیا میزبانی کنیم، اینجاست که نام وب سرور (Web Server) به میان می آید.برای کسب اطلاعات بیشتر در این حوزه به شما پیشنهاد می کنیم مقاله ی ما با موضوع وب سرور چیست؟ را برای کسب اطلاعات در این حوزه مطاله نمایید.
IIS چیست؟
IIS (Internet Information Server) یکی از قدرتمندترین وب سرورهای موجود ارائه شده توسط مایکروسافت می باشد که برای میزبانی وب اپلیکیشن ASP.NET شما به کار برده می شود.
IIS موتور پردازش خود را برای handle کردن درخواست های ASP.NET دارد بنابراین وقتی درخواستی از سمت کلاینت به سرور ارسال می شود IIS آن در خواست را دریافت و پردازش کرده و پاسخ آن را به سمت کلاینت می فرستند.
نحوه ی پردازش درخواست ها
قبل از توضیح اینکه درخواست ها به چه صورت در وب سرور و IIS پردازش می شوند لازم است با دو مفهوم زیر آشنایی داشته باشید.
1. Worker Process
2. Application Pool
Worker Process: اجرای اپلیکیشن ASP.NET در IIS توسط Worker Process (w3wp.exe) صورت می گیرد. ورکر پراسس مسئول مدیریت تمامی درخواست دریافتی و پاسخ های ارسالی به سیستم کلاینت می باشد. تمامی قابلیت های ASP.NET تحت قلمرو (حوزه) Worker Process به اجرا در می آیند.
وقتی درخواستی از سمت سیستم کلاینت به وب سرور می رسد، worker process مسئولیت ایجاد درخواست و پاسخ دهی به آن را به عهده می گیرد. به زبان ساده تر Worker Process قلب وب اپلیکیشن ASP.NET می باشد که در IIS اجرا می شود.
Application Pool: اپلیکیشن پول به زبان ساده ظرفی است که Worker Process را در خود جای داده است.
Application Pool برای جداکردن ورکر پراسس/ورکر پراسس هایی که configuration یکسانی را مشترکا استفاده می کنند از سایر Worker Process بکار می رود و هر ورکر پراسس/ورکر پراسس های دارای Configuration یکسان در Application Pool مجزای خود اجرا می شوند.
Application Pool امنیت، قابلیت اطمینان و دسترس پذیر بودن بیشتری را برای هر وب اپلیکیشن فراهم میکند به اینصورت که مرزی بین Worker Process ها ایجاد میکند(زیرا هر ورکر پراسس در Application Pool مجزای خود اجرا می گردد) و به وجود آمدن مشکلی و یا Recycle شدن Worker Process ای بر روی سایر Worker Process ها تاثیری نخواهد گذاشت و این اطمینان را خواهد داد که هیچ وب اپلیکیشن ای نخواهد توانست اختلالی در کارکرد سایر وب اپلیکیشن ها ایجاد کند چرا که هریک در Application Pool خود پیکره بندی شده اند.
به Application Pool ای با چند Worker Process درحال اجرای همزمان در داخل خود، Web Garden می گویند.(مانند اپلیکیشن پول اول از سمت چپ در تصویر بالا)
تا این قسمت تمامی مفاهیم ابتدایی لازم مانند Web Server، Application Pool و Worker Process را شرح دادیم و هم اکنون می توانیم نحوه ی پردازش IIS وقتی درخواست جدیدی از سمت کلاینت می رسد را بررسی کنیم.
با توجه به نحوه ی معماری و ساختار IIS می توانیم آن را به دو لایه تقسیم کنیم:
1. Kernel Mode
2. User Mode
Kernel Mode که با ظهور IIS6 معرفی گردید در بردارنده سرویس HTTP.SYS می باشد. وقتی درخواستی از سمت کلاینت به سمت وب سرور ارسال می شود در اولین مرحله به دست سرویس HTTP.SYS خواهد رسید.
بعد از دریافت درخواست توسط سرویس HTTP.SYS، این سرویس مسوول ارجاع درخواست به Application Pool مربوطه می باشد. سوالی که در اینجا پیش می آید این است که چگونه HTTP.SYS می فهمد که درخواست را به کجا باید ارسال کند؟
انتخاب به صورت تصادفی صورت نمی گیرد زیرا هر درخواست مربوط به وب اپلیکیشن خاصی می باشد و باید به Application Pool مختص به آن وب اپلیکیشن ارجاع داده شود.
هر زمان که Application Pool ای ایجاد می شود ID اپلیکیشن پول ایجاد و در HTTP.SYS ثبت می شود. بنابراین هر زمان که HTTP.SYS درخواست های مربوط به وب اپلیکیشن ای را دریافت می کند، Application Pool مربوطه را یافته و بر اساس آن درخواست را ارجاع می دهد.
این اولین مرحله ی پروسه ی “پردازش درخواست” کلاینت در IIS بود.
تا اینجا کلاینت درخواستی برای دریافت اطلاعات/صفحات کرده و این درخواست به لایه ی Kernel Level در IIS یعنی HTTP.SYS رسیده است و HTTP.SYS مشخص کرده است که درخواست می بایست برای کدام Application Pool ارسال شود. حالا باید دید این درخواست چگونه از لایه ی HTTP.SYS به سمت Application Pool مربوطه انتقال پیدا می کند.
در لایه ی User Level وب سرور IIS، سرویس (Web Admin Services (WAS را داریم که درخواست را از HTTP.SYS دریافت و به Application Pool مربوطه انتقال می دهد.
وقتی Application Pool درخواست را دریافت می کند آن را به ورکر پراسس ( w3wp.exe ) واگذار می کند. ورکر پراسس “w3wp.exe” ی،URL درخواست را جهت لود کردن ISAPI extension صحیح بررسی می کند. ISAPI extension ها شیوه ی وب سرور IIS برای Handle کردن درخواست های مربوط به Resource های مختلف می باشد. در هنگام نصب ماژول ASP.NET در وب سرور، این ماژول ISAPI extension خود (aspnet_isapi.dll) را نصب کرده و mapping مربوطه را در IIS اضافه می نماید.
وقتی ورکر پراسس aspnet_isapi.dll را لود کرد یک HTTPRuntime شروع می شود که نقطه ی آغازین یک وب اپلیکیشن می باشد. HTTPRuntime یک Class می باشد که ProcessRequest method(متود پردازش درخواست) را برای شروع پردازش فرا می خواند.
وقتی متود پردازش درخواست فراخوانده می شود یک HTTPContext ساخته می شود که از طریق پراپرتی های(Properties) HTTPContext.Current قابل دسترسی می باشد.
این object (HTTPContext) تا زمان اتمام درخواست خود فعال باقی می ماند. با استفاده از پراپرتی HttpContext.Current می توانیم به سایر object ها مانند Request، Response و Session و … دسترسی داشته باشیم.
بعد از آن HttpRuntime با کمک HttpApplicationFactory class یک HttpApplication object را لود می کند. تمامی درخواست ها می بایست از HTTPModule مربوطه برای رسیدن به HTTPHandler عبور کنند و این لیست module ها توسط HTTPApplication پیکربندی شده است.
در اینجا مفهوم HTTPPipeline به میان می آید. به این علت HTTPPipeline (خط لوله پردازش http) نامیده می شود چون متشکل از مجموعه ای از HTTPModule ها (برای هر دو سطح web.config و machine.config) که حائل بین مسیر حرکت درخواست به سمت HttpHandler می باشند، است.
HTTPModules ها Class هایی هستند که به درخواست دریافت شده دسترسی دارند. همچنین در صورتیکه نیاز به Handle کردن چیزی در پروسه ی درخواست و ارسال پاسخ داریم، می توانیم HTTPModule خودمان را ایجاد کنیم.
HTTP Handler ها نقطه ی پایانی در خط لوله ی پردازش HTTPی(HTTP pipeline) می باشند. تمامی درخواست هایی که از HTTPModule ها عبور می کنند باید در انتها به HTTPHandler برسند. HTTPHandler محتوای خروجی برای منابع(اطلاعات/صفحات) درخواست شده را ایجاد می کند. بنابراین هر زمان که ما درخواست صفحات وب aspx را می کنیم، HTTPHandler در جواب خروجی HTML (HTML output) مربوطه را باز می گرداند.
تمامی درخواست ها از httpModule به HTTPHandler مربوطه و سپس متود پردازش انتقال داده می شوند و چرخه‌ی حیات صفحات ASP.NET شروع می شود (ASP.NET Page life cycle) و در این قسمت پروسه ی پردازش درخواست توسط IIS به پایان می رسد و Lifecycle صفحات ASP.NET شروع می شود.
وقتی کلاینتی درخواست یکسری اطلاعات از وب سرور می کند، درخواست ارسال شده ابتدا به HTTP.SYS در IIS می رسد. HTTP.SYS درخواست را به Application Pool مربوطه ارجاع داده و Application Pool آن را به ورکرپراسس Forward می نماید تا ISAPI Extension مربوطه لود شود که این منجر به ایجاد یک HTTPRuntime Object شده تا درخواست از طریق HTTPModule و HTTPHandler پردازش شود و بعد از آن Event های چرخه ی حیات صفحات ASP.NET شروع شود.
سخن پایانی
این مطلب مروری مختصر (متناسب برای تازه کارها) بر پروسه ی پردازش درخواست ها در IIS بود. جهت کسب اطلاعات بیشتر لازم است لینک های منابع استفاده شده را بررسی و مطالعه نمایید.
