از زمان ارايه سيستمعامل شبكهاي ويندوز 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 براي اين كار استفاده كند.