IIS یا Apache، یک انتخاب

صفحه اصلی کارگروهها >> برنامه نویسان جاوا  >> IIS یا Apache، یک انتخاب
رضا علیمددی

رضا علیمددی

در کارگروه: برنامه نویسان جاوا
تعداد ارسالي: 69
17 سال پیش در تاریخ: شنبه, مرداد 06, 1386 11:50

IIS یا Apache، یک انتخاب








مهیار داعی‌الحق - ماهنامه شبکه


اشاره :


از زمان ارایه سیستم‌عامل شبکه‌ای ویندوز 0.4NT، وب سرورIIS یکی از اجزای سیستم‌عامل‌های سرور مایکروسافت بوده که نصب یا عدم نصب آن از طرف کاربر به صورت دلخواه و به راحتی در هر زمانی قابل انجام بوده است. به عنوان مثال ویندوز 0.4 NT همراه 4IIS ، ویندوز 2000 همراه 5 IIS و ویندوز XP به همراه 1.5 IIS به بازار ارایه شدند. تا قبل از ویندوز 2003، کلیه ویرایش‌ها و نسخه‌های مختلف IIS بسیار مشابه هم بودند و می‌شد آن‌ها را جزء یک خانواده به حساب آورد، اما پس از آن و با به میان آمدن ویندوز 2003، که نسخه ششم IIS را به همراه خود داشت، قضیه کاملاً متفاوت شد. در این نسخه که می‌توان آن را یک بازنویسی کامل از وب سرور قدیمی دانست، بسیاری از مدل‌های اجرای کد، تسهیلات مربوط به مدیریت و سرعت و کارایی آن، دچار تغییرات و بهبودهای قابل ملاحظه‌ای شده‌است. از طرف دیگرآپاچی با سابقه‌ای بیشتر که براساس کدینگ http کار می‌کرد، همواره به عنوان سمبل وب سرورهای دنیای یونیکس مطرح بود. نسخه1.3 x آپاچی که تا سال 2002 مورد استفاده قرار می‌گرفت، با استفاده از ترفندهای تکنیکی خاصی برروی سایر سیستم‌عامل‌ها و حتی ویندوز هم قابل نصب و اجرا بود. اما با پیدایش آپاچی نسخه 2، همین معادلات هم دچار تحولی بزرگ گردید. این نسخه که دارای محیطی کاملاً تغییر یافته بوده و توابع درون آن با ظرافت هر چه تمام‌تر استقلال خود را از سیستم‌عامل تثبیت کرده بودند، توانست بر روی کلیه سیستم‌عامل‌های ویندوز، یونیکس، لینوکس، مکOSX و حتی سیستم‌عامل‌های دیگری چونVMS و Be OS نصب و اجرا شود.




مقایسه


در مقام مقایسه IIS و آپاچی می‌توان گفت که هر کدام دارای مزایا و معایبی نسبت به یکدیگر هستند. IIS فقط برای اجرا در ویندوز ساخته شده ‌است به‌خصوص نسخه ششم آن فقط در ویندوز 2003 قابل‌اجرا می‌باشد. اگر چه بسیاری از کارشناسان، این مسئله را نوعی نقطه‌ضعف در ساختار IIS می‌دانند، برخی دیگر هماهنگی بسیار دقیق میان آن و ویندوز 2003 و سرویس‌های دیگر سیستم‌عامل را که باعث آسان‌تر بودن مدیریت IIS شده است، از نقاط برتری آن به حساب می‌آورند. به‌خصوص در نسخه ششم جدا شدن ماژول مخصوص دریافت درخواست‌ها(Request) از ماژول ویژه پردازش آن‌ها، سهم به‌سزایی در افزایش کارایی آن داشته است. در این روش ماژول Listener که در کرنل مستقر شده است (Http.sys)، درخواست‌های ارسالی از طرف کلاینت‌ها را دریافت‌‌‌کرده و آن‌ها را به ترتیب در داخل یک یا چند صف درخواست قرار می‌دهد. سپس IIS به این درخواست‌ها با اختصاص حداقل یک پروسه کاری (Worker Process) به هر درخواست، پاسخ می‌دهد. این ویژگی باعث می‌شود حتی زمانی که IIS به شدت مشغول پاسخ‌دهی به درخواست‌های قبلی است، ماژول جداگانه‌ای که در کرنل مستقر است، بتوانند درخواست‌های جدید را دریافت کرده و حداقل آن‌ها را در انتظار پاسخ قرار دهند. همچنین با این وضعیت، سیستم‌عامل می‌تواند کنترل بهتری را در اختصاص پروسه‌های لازم به IIS جهت پردازش درخواست‌ها انجام دهد. در آپاچی هم جریان تا حدودی مشابه همین روال است. در این جا تعدادی ماژول با قابلیت انجام چند پردازش در واحد زمان (Multi Processing module) وظیفه دریافت و پاسخ به درخواست‌ها را برعهده دارند. این ماژول‌ها که با استفاده از تکنولوژی APR یا Apache Portable Runtime برروی بسیاری از سیستم‌عامل‌هایی که از کدهای کامپایل شده زبان C پشتیبانی می‌کنند، قابل اجرا هستند، با استفاده از امکانات و قابلیت‌هایMultithreading همان سیستم‌عامل میزبان به سرعت و به صورت همزمان درخواست‌های رسیده از طرف کلاینت‌ها را دریافت و پردازش می‌کنند.

امنیت





نحوه عملکرد وب سرور



یکی از مزایای، IIS ارتباط تنگاتنگ موجود بین آن و سیستم‌عامل است. این عامل سبب می‌شود تا IIS با توجه به این‌که سیستم‌عامل بسیاری از موارد امنیتی را قبل از رسیدن درخواست به وب سرور مورد بررسی قرار می‌دهد و هویت کاربران متصل را ارزیابی (Authentication) می‌کند، با اطمینان بیشتری به کار خود ادامه دهد. ضمن این‌که مدیر سیستم هم به دلیل اشتراک روشی که در تأمین امنیت بین سیستم‌عامل و وب سرور وجود دارد، مجبور به دوباره کاری نمی‌شود. به عنوان مثال اگر شما در اکتیودایرکتوری ویندوز 2003 دسترسی به یک یا چند فایل خاص را برای یک گروه از کاربران مجاز و برای گروهی دیگر غیرمجاز تعریف کرده باشید، این کاربران از هر روشی که بخواهند به آن فایل‌ها دسترسی پیدا کنند (حتی از طریق وب سرور) باید تابع قواعد تنظیم شده در اکتیودایرکتوری باشند و این قوانین در IIS نیز حکمفرما است.
در مورد آپاچی نسخه دوم، مسئله به این سادگی و روانی نیست و قاعدتاً مدیریت امنیت در مورد آن پیچیده‌تر و وقت‌گیرتر از IIS است. البته اکنون ماژول‌ها و آداپتورهای جدیدی در آپاچی تعبیه شده که امکان ارتباط بین آن و اکتیودایرکتوری ویندوز یا Password یونیکس را به‌وجود می‌آورد، اما باز هم می‌توان گفت که اصولاً با وجود این ارتباط هم در آپاچی، سیستم‌عامل و وب سرور هر کدام ساز خود را می‌زنند و آپاچی چندان از قواعد امنیتی تعریف شده در سیستم‌عامل تبعیت نمی‌کند. البته بسیاری از طرفداران آپاچی این مسئله را نوعی نقطه قوت آپاچی دانسته و با ذکر این نکته که اولاً هر درخواست از طرف خارج باید از دو سد محکم سیستم‌عامل و وب سرور عبور کند و ثانیاً حفره‌های امنیتی در سیستم‌عامل‌های یونیکس و آپاچی بسیار کمتر از ویندوز و IIS است، استفاده از آپاچی را از لحاظ امنیتی دارای ریسک کمتری نسبت به IIS می‌دانند.
از لحاظ پروتکل‌های امنیتی، هر دو وب سرور کلیه پروتکل‌ها از جمله SSL ،IPsec و مکانیسم‌های هویت‌سنجی Basic Digest LDAP را پشتیبانی می‌کنند.


کارایی
مقایسه کارایی آپاچی و IIS همواره از مشکل‌ترین بحث‌های تکنیکی دنیای وب سرورها بوده است؛ چرا که این نوع مقایسه مستلزم به‌وجود آوردن شرایط یکسان آزمایش به صورت منصفانه‌ برای دو طرف رقابت است که دست یافتن به این شرایط، کاری آسان و صددرصد قابل انجام نمی‌باشد. شاید به تصور خیلی‌ها می‌توان زمان دریافت، پردازش و پاسخ هر دو وب سرور به یک صفحه CGI یا JSP (که مورد پشتیبانی هر است) را برروی یک سرور با مشخصات سخت‌افزاری یکسان به معرض آزمون گذاشت، اما این هم به نمی‌تواند تنهایی پاسخگوی معمای کارایی باشد. چرا که اولاً شاید هر دو وب سرور ادعای بهترین کارایی خود در تکنولوژی مشترکی مثل JSP را نداشته باشند. مثلاً شاید مایکروسافت ASP.NET را که فعلا در آپاچی پشتیبانی نمی‌شود، بهترین عرصه برای نمودار‌شدن کارایی IIS بداند. ثانیاًٌ نباید فراموش کرد که آپاچی، یک وب سرور چند سکویی می‌باشد و این باعث می‌شود تا صورت مسئله کمی پیچیده‌تر شود و کسانی که می‌خواهند به داوری مسابقه کارایی این دو وب سرور بنشینند را با سؤالی جدیدتر روبرو کند و آن هم این است که IIS ویندوز را با آپاچی کدام سیستم‌عامل مقایسه کنیم ؟ آیا اصولاً آپاچی ادعایی بر ارایه بهترین کیفیت و کارایی خود برروی سیستم‌عامل مشترک ویندوز را دارد یا این‌که کماکان به سرعت خود برروی سیستم‌عامل‌های یونیکس و لینوکس می‌بالد؟




نمودار میزان رشد کاربرد


وب سرورهای مختلف در ده سال اخیر




در IIS 6 وجود مدل‌های متعدد پردازشی که ویژه کار در محیط‌های چند پردازنده‌ای در نظر گرفته شده‌اند، سرعت اجرای برنامه‌های ASP و یا ISAPI را تا حد بسیار مطلوبی بالا برده‌اند. همچنین درایور HTTP.sys در این نسخه قادر است به صورت مستقیم به اطلاعات موجود در cache (چه هارددیسک و چه حافظه اصلی) دسترسی پیدا کند بدون آن‌که نیازمند وجود واسطه‌ای مثل پروسه‌های کاری برای انجام این کار باشد. IIS همچنین قادر است صفحاتی را که توسط عناصر دینامیک وب به صورت RunTime ساخته می‌شوند را در cache ذخیره کند تا در صورتی که کلاینت‌ بعدی هم بخواهد همین صفحه را تولید کند، به جای ساختن دوباره آن، از محل cache اطلاعات را بدون پردازش خاصی به سمت کلاینت مذکور بفرستد.
در آپاچی نیز اوضاع به همین گونه است. ماژول‌های modperl وmodphp با استفاده از همان مکانیسم cache سرعت تولید صفحات دینامیک را همانند صفحات استاتیک به حداکثر خود می‌رسانند. همچنین دقیقاً مشابه فیلترهای ASP و ISAPI در IIS، در این جا هم ماژول‌های Perl و PHP مستقیماً درخواست‌های کلاینت‌ها را مورد بررسی قرار داده و پاسخ لازم را ارسال می‌کنند و بدین وسیله از ارجاع درخواست‌ها به محیط خارج آپاچی و کند شدن روند پاسخ جلوگیری می‌کنند.


مدیریت
در مورد مدیریت وب سرور، اختلافاتی بین دو وب سرور مذکور وجود دارد. آپاچی در نسخه‌های اولیه خود، وب سروری کاملا TextBased به نظر می‌‌رسید که صرفاً با دستکاری مستقیم در فایل‌های پیکربندی، تنظیم وب سرور و یا با استفاده از دستورات خط فرمان مدیریت آن امکان‌پذیر بود. اما اکنون بسیاری از واسط کاربرهای گرافیکی مثل Comanche قادرند یک محیط گرافیکی کاربرپسند و در واقع یک لایه بیرونی برای کار با آپاچی فراهم کنند. در این زمینه لیستی از واسط کاربرهای گرافیکی تهیه شده در سایت آپاچی به نشانی
http://gui.apache.org موجود و قابل داونلود است. البته بسیاری از کاربران وجود مدیریت و تنظیمات Text Based را برای آپاچی یک مزیت عنوان می‌کنند. به عقیده این افراد، با این نوع پیکربندی آپاچی می‌توان به سادگی و صرفاً با کپی کردن چند فایل از کامپیوتری به کامپیوتر دیگر همه تنظیمات یک سرور آپاچی را به سرور دیگر منتقل و از صرف وقت برای تنظیم دستی آن خلا‌ص شد. این مسئله برای وب سروری مثل IIS که تنظیمات خود را در قالب فایل‌های باینری نگهداری می‌کند، قابل انجام نیست. البته در IIS 6 تنظیمات وب سرور در قالب فایل‌های XML قابل دسترسی است. و بدین‌وسیله و با روش Import و Export می‌توان تنظیمات یک وب‌‌سرور را به دیگری منتقل کرد. همچنین اینکه علاوه بر این کار، IIS 6 امکان مدیریت راه‌دور را از طریق دستورات خط فرمان و اجرای آن با پروتکل Telnet را مشابه آپاچی به کاربران خود داده است. در ضمن هر دو وب سرور، امکان مدیریت از طریق وب را به کاربران داده‌اند. IIS از طریق Web Based Administration و آپاچی با استفاده از ابزاری به نام Webmin این تسهیلات را مهیا کرده‌اند.

قابلیت اطمینان
IIS 6 با جدا کردن حافظه و محل اجرای برنامه‌های وب از یکدیگر، باعث شده است در صورت بروز یک مشکل در هر یک از برنامه‌های در حال اجرا، این مشکل به سایر برنامه‌ها و پردازش‌های در حال اجرا سرایت نکند. در آپاچی نسخه دوم این عمل تا حدودی قابل انجام است. بدین‌معنی که اصولاً آپاچی با مکانیسم‌های تشخیص و ترمیم خطا، از سرایت مشکل به قسمت‌ها و پردازش‌های دیگر جلوگیری می‌کند، اما به طور کلی نمی‌تواند همانند IIS عمل جداسازی برنامه‌ها از یکدیگر را انجام دهد و در برخی موارد، بروز یک مشکل در یکی از پردازش‌ها، مدیر وب را ناچار به راه‌اندازی مجدد (Restart) وب سرور می‌کند.
نکته دوم در این مقایسه هم به نفع IIS تمام می‌شود. بدین صورت که در نسخه ششم آن امکان پیکربندی مجدد سیستم حتی در زمان اجرای پردازش‌ها و بدون‌نیاز به راه‌اندازی مجدد وب‌سرور امکان‌پذیر است. این امکان که به آن Live Configuration گفته می‌شود، سبب می‌شود مدیر سیستم بتواند بدون آن‌که وب سرور و در نتیجه بسیاری از پردازش‌های در حال اجرا و درخواست‌های در حال پاسخگیری را متوقف کند، تنظیمات IIS را تغییر دهد و وب‌ سرور را Refresh کند. در صورتی که در آپاچی نسخه دوم، این عمل بدون بوت کردن مجدد وب سرور میسر نیست.


Apache 2.1 Alpha
در نسخه 1/2 آپاچی که نسخه ابتدایی آلفای آن اکنون قابل دریافت و نصب است، وعده‌های بسیاری برای افزایش کارایی یا پوشاندن نقاط ضعف نسخه‌های قبلی داده شده‌است. بسیاری از ماژول‌های مربوط به chaching Authn/Authz مورد بازبینی قرار گرفته و نسبت به نسخه‌های سابقشان از کارایی بهتری برخوردارند. پروتکل http در این نسخه قادر است فایل‌ها یا درخواست‌های با بیش از دو گیگابایت را دریافت و پردازش کند. مکانیسم smart Filtering در آپاچی 1/2 از یک شیوه جدید فیلترگذاری پویا برخوردار است که باعث می‌شود تا هر فیلتر براساس نوع درخواست یا پاسخی که قرار است کنترل شود، فعال یا غیرفعال عمل کند. همچنین در این نسخه ماژول جدیدی برای ثبت کردن خطاهایی که در ارتباط با کلاینت‌ها رخ می‌دهد، تعبیه شده است. مدیریت حافظه stack برای پردازش‌های در حال اجرا تغییریافته و اکنون آپاچی قادر است براساس سکویی که برروی آن در حال اجرا است، میزان این حافظه را افزایش دهد. از لحاظ امنیتی به غیر از تغییرات ایجاد شده در ماژول‌های مربوط به هویت‌سنجی که بیشتر باعث افزایش سرعت فرآیندهای مربوط به آن‌ها شده است، ماژول modssl نیز اکنون با پشتیبانی از RFC7182، قادر‌است به جای برقراری ارتباط به روش متنی (chear text)، از روش کدگذاری TLS برای این کار استفاده کند.

حذف ارسالي ويرايش ارسالي