Vahid
August 19th, 2009, 17:56
از زمان ارایه سیستم‌عامل شبکه‌ای ویندوز 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 و آپاچی می‌توان گفت که هر کدام دارای مزایا و معایبی نسبت به یکدیگر هستند. 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 را پشتیبانی می‌کنند.