تفاوت Nginx و Apache

من ، ارسلان میربزرگی قصد دارم تجربیات شخصی خودم را در اختیارتون قرار بدهم. شما در وبسایت من می‌توانید مثال ها و پروژه های عملی را مشاهده کنید و در پروژه های خودتون پیاده سازی کنید. در این بخش نیز به توضیح مختصری از تفاوت‌های مهم Nginx و Apache می‌پردازیم.

اینترنت “تسخیر” جهانی خود را در دهه 90 آغاز کرد. کل پروتکل “Web” را می‌توان به‌عنوان بازدیدکننده‌ای که درخواست یک Document از یک آدرس وب خاص را دارد خلاصه کرد که با DNS و IP، این درخواست را به کامپیوتر مناسب منتقل می‌کند. این کامپیوتر که میزبان صفحه‌ی وب درخواستی است، صفحه‌ی وب را به بازدیدکننده نمایش داده یا اصطلاحاً “serve” می‌کند.

صفحات وب در اصل Document های HTML هستند. برای اینکه بتوانند صفحات وب مختلفی را به بازدیدکنندگان ارائه دهند، ماشین “serving” به یک برنامه‌ی سرور نیاز دارد. نرم‌افزارهایی مانند Nginx  یا Apache درخواست‌ها را کنترل کرده، آن‌ها را تجزیه‌وتحلیل می‌کند و سپس Document های مربوطه را برای مشاهده در مرورگر بازدیدکننده تحویل می‌دهد.

Nginx و Apache از Web server های مشهوری هستند که برای انتقال صفحات وب به مرورگر کاربر استفاده می‌شوند. به‌طور خلاصه:

• Apache در سال 1995 منتشر و سپس Nginx در سال 2004 ارائه شد.

• هر دو مورد توسط شرکت‌های بزرگی در سراسر جهان مورداستفاده قرار می‌گیرند.

• سهم بازار Nginx سال‌هاست که به‌طور مداوم در حال رشد است.

• در برخی موارد، Nginx ازنظر عملکرد دارای مزیت رقابتی است.

بعد از Tim Berners-Lee’s CERN HTTPd و NCSA HTTPd در همان چند سال اول ظهور اینترنت، Apache اولین بار در سال 1995 منتشر شد و به‌سرعت بازار را تسخیر کرده و به محبوب‌ترین Web server جهان تبدیل شد. امروزه هنوز هم به همان دلایل قدیمی در بازار معروف است و تحت مجوز Apache توسط بنیاد Apache درحال‌ توسعه و نگهداری است.

دو داستان مختلف در مورد چگونگی نام‌گذاری Apache وجود دارد. یک نسخه می‌گوید که این نام از میراث معروف بومی آمریکا نشئت‌ گرفته است، درحالی‌که نسخه‌ی دیگر می‌گوید که این نام برگرفته از یک “Patchy server” است که یک سری Patch های نرم‌افزاری را نشان می‌دهد.

سهم عظیم بازار Apache تا حدودی به این دلیل است که تمام توزیع‌های اصلی Linux، مانند Red Hat / Centos و Ubuntu را دارد.

یک مثال از نقش مهم Apache در دنیای Linux این است که نام فرآیند سرور آن HTTPd است و باعث می‌شود Apache با نرم‌افزار Web server مترادف باشد. علاوه بر اینکه Apache در بازار Web server اولین است، بخشی از گسترش Apache به دلیل سیستم Configuration و فایل httaccess. آن است.

Apache برای Configuration خود از httaccess. استفاده می‌کند. با توجه به Flexibility زیادی که Apache برای نحوه‌ی Configure و رسیدگی به درخواست‌های ورودی فراهم می‌کند، در مورد نحوه‌ی Configure، ویرایش و کار با فایل httaccess. نیز آموزش‌های زیادی وجود دارد. به‌عنوان ‌مثال: قوانین مختلف Redirection، حداکثر اندازه‌ی Upload فایل، بازنویسی URL، محدودیت حافظه، حفاظت از Directory (htpasswd)، Header های منقضی شده، Header های Cache-control، Header های Encoding، cookie ها، دست‌کاری رشته‌های query.

از طرف دیگر Kinsta از Nginx استفاده می‌کند که از فایل‌های htaccess. پشتیبانی نمی‌کند. بااین‌حال، تنظیمات و قوانین موجود در فایل‌های htaccess را می‌توان به‌راحتی به Syntax بازنویسی Nginx ترجمه کرد.

یکی از “مزایای” اصلی Apache این است که در Server root یا Directory اصلی وب‌سایت، هر Level یا Directory در Directory tree می‌تواند فایل httaccess. مخصوص خود و با Configuration خاص خود داشته باشد.

برای ارائه‌دهندگان Shared hosting، این یک رؤیا است زیرا آن‌ها می‌توانند صدها کاربر را در یک سیستم یکسان پشتیبانی کرده و بدون اینکه بر یکدیگر تأثیر بگذارند نحوه‌ی سرویس‌دهی وب‌سایت‌هایشان را Configure کنند. همچنین مشتریان می‌توانند بدون Configuration کلی سرور، بسیاری از جزئیات را در یک محیط Shared hosting محدود Configure کنند.

  همان‌طور که در Documentation های رسمی آمده است:

“به‌طورکلی، فقط درصورتی‌که به فایل Configuration اصلی سرور دسترسی ندارید، باید از فایل‌های htaccess. استفاده کنید.”

این انعطاف‌پذیری به ازای فایل‌های htaccess. باعث ضربه زدن به Performance می‌شود، حتی اگر واقعاً از آن‌ها استفاده نکنید!

هر زمان که فایل‌های htaccess. فعال می‌شوند، Apache باید کل Directory tree را از URL یا فایل درخواستی از طریق تمام سطوح بالاتر تا Server’s root directory پیموده و سپس آن‌ها را برای هر درخواست Load کند. سپس باید این فایل‌ها را پردازش کرده و مجدداً خود را برای هر یک از Directory های Configure شده به این روش، Configure کند.

با استفاده از وب‌سایت‌های WordPress، اوضاع کاملاً پیچیده می‌شود. یک وب‌سایت معمولی WordPress می‌تواند صدها درخواست از Directory های مختلف داشته باشد. از نوع /wp-content/uploads/yyyy/mm معمولاً چندین درخواست در یک صفحه Load می‌کند که اغلب Directory های ماه‌های مختلف را تشکیل می‌دهند. سپس /wp-content/themes/parent-theme static resources و /wp-content/themes/child-theme resources وجود خواهند داشت که شامل JavaScript، فایل‌های CSS و Image ها هستند. سپس / wp-content / plugins نیز با فایل‌های Static بارگیری شده از ده‌ها زیرشاخه از زیر Plugin ها وجود دارد که برای هر یک از این منابع، Apache برای جستجوی plugin ها باید کل Directory tree خود را پردازش کند.

یک تجزیه‌وتحلیل نشان داده است که یک تنظیم معمولی WordPress که تنظیمات معمولی برای وب‌سایت‌ها در Shared hosting نیست، شامل 42 اجرای جداگانه htaccess. و 249 جستجوی جداگانه برای فایل htaccess. خواهد بود.

این فقط در سطح Web server است و بازدیدکننده همچنان باید منتظر بماند تا PHP کل فرآیند Call stack های WordPress را اجرا کند و درخواست پایگاه داده را ایجاد کرده و آن را به MySQL بدهد تا صفحه ی وب را Assemble کند و برای بازدیدکننده ارسال کند.

مورد دیگری که باعث محبوبیت Apache شد، ماژولار بودن آن است.

Module ها، به‌عنوان یک ویژگی که به کاربران امکان می‌دهد قابلیت Web server را گسترش دهند، هم در Nginx و هم در Apache وجود دارند. Apache به کاربران اجازه می‌دهد پس از نصب و Deploy وب سرور، Module ها را نصب و سپس در صورت لزوم آن‌ها را فعال یا غیرفعال کند. Distribution های Debian-based دارای فرمانی هستند که امکان فعال و غیرفعال کردن این Module ها را بدون نیاز به ویرایش فایل‌های Configuration فراهم می‌کنند: a2enmod و a2dismod.

لیست رسمی Module هایی که به‌عنوان بخشی از توزیع استاندارد Apache ارائه می‌شوند شامل Compression، Encryption، Logging، Redirection تا موارد پیشرفته‌تر مانند ویرایش درخواست‌ها و پاسخ‌دهی با Syntax پیشرفته است.

Nginx در سال 2004، برای اولین بار توسط Igor Sysoev، یک Developer روسی منتشر شد. همان‌طور که Owen Garrett، مدیر پروژه Nginx گفت:

“Nginx به‌طور خاص برای رفع محدودیت‌های عملکرد Web server های Apache نوشته شده است.”

این سرور اولین بار به‌عنوان ابزاری برای Scaling وب‌سایت rambler.ru در سال 2002 ایجاد شد و دو نسخه دارد: Open source، با مجوز از نوع BSD و Nginx Plus، با پشتیبانی و سایر ویژگی‌های Enterprise.

پس ‌از انتشار، از Nginx بیشتر برای سرویس‌دهی به فایل‌های Static و به‌عنوان Load-balancer یا Reverse proxy در نصب Apache استفاده شد. با تکامل وب و نیاز به افزایش سرعت و افزایش کارایی سخت افزار، وب‌سایت‌های بیشتری به لطف داشتن نرم‌افزار کاملاً پیشرفته، شروع به جایگزینی کامل Apache با Nginx کردند.

در مارس 2019، Nginx Inc توسط F5 Network به قیمت 670 میلیون دلار خریداری شد. در آن لحظه، همان‌طور که Techcrunch گزارش داد، سرور Nginx، 375 میلیون وب‌سایت با حدود 1500 مشتری را تأمین می‌کرد.

طبق داده‌های w3techs، سهم بازار Nginx به‌طور مداوم در حال رشد است و Apache را بیرون رانده و آن را از همان ابتدا برکنار کرد:

این داده‌ها مربوط به Web server های کلی در سطح جهان است، اما اگر از یک‌میلیون وب‌سایت برتر نمونه بگیریم، Nginx مدتی است که در آنجا حضور دارد:

روند جستجوی Google نیز این واقعیت را منعکس می‌کند:

نظرسنجی Netcraft نشان می‌دهد Nginx در آوریل 2019 از Apache پیشی گرفته است.

Nginx سیستم Configuration مانند Apache ندارد، بنابراین، باوجود کارایی و سرعت بسیار بیشتر، به‌طور گسترده‌ای در Hosting provider ها استفاده نمی‌شود و مانند Apache در محیط‌های اشتراکی درخشش ندارد.

از طرف دیگر، همان‌طور که گفته شد، با اجازه ندادن اعمال Configuration در سطح Directory، Nginx برتری قابل‌توجهی نسبت به Apache دارد. مقاله‌ای در ویکی Nginx وجود دارد که تأثیر عملکرد را به شرح زیر مقایسه می‌کند:

Module های Nginx یکی دیگر از مواردی است که Nginx را تبدیل به یک گزینه‌ی بهتر می‌کند. Module های Nginx معمولاً باید در زمان ساخت فعال شوند، این بدان معناست که مهارت فنی بیشتری در این امر وجود دارد و افزودن Module ها پس از نصب کمی پیچیده‌تر است.

در سال 2016، با نسخه‌ی 1.9.11، همه‌چیز تغییر کرده و مخزن Module های دینامیک official/verified به Paying user ها اختصاص داده‌شده است. از سال 2019، شروع Development و پشتیبانی از QUIC و HTTP / 3 اعلام شد.

Caching به‌منظور آماده‌سازی محتوا برای بازدیدکنندگان وب‌سایت قبل از بازدید آن‌ها است، بنابراین نیازی به جستجوی محتوای موردنظر آن‌ها نیست و شما قبلاً آن را آماده کرده‌اید و آن‌ها بدون منتظر ماندن به محتوا دست پیدا می‌کنند.

مانند Apache، در حالت معمول Nginx برای کاهش Performance hit در سایر زیرساخت‌ها، بین سرورها و End user قرار می‌گرفت. در این موارد، می‌تواند بدون اینکه نیازی باشد هر بار Static content را از سرور محافظت‌شده‌ی مبدأ Fetch کند، آن را Cache کند.

اگر از Nginx به‌عنوان یک Web server مستقل استفاده کنیم نیازی به Cache وجود ندارد و Nginx به‌تنهایی در ارائه‌ی Static content بسیار کارآمد است. همان‌طور که در مورد  container های Kinsta LXC نیز این‌طور است.

سپس مسئله‌ی Dynamic cache یا Page cache وجود دارد. در وب‌سایت‌های WordPress، این به معنای ذخیره کردن تمام صفحات WordPress تولیدشده برای هر URL در حافظه یا دیسک است.

 FastCGI caching به‌طورمعمول در نصب استاندارد Nginx موجود است که ساده و بسیار قدرتمند است و یکی از ویژگی‌های Nginx است که کمتر مورداستفاده قرار می‌گیرد.

از طرفی Apache دارای Module های Mod_cache است که ظاهراً با Module های دیگر مغایرت دارد؛ بنابراین راه‌حل Caching استاندارد با Apache، شتاب‌دهنده‌ی Varnish HTTP است. اگرچه Varnish یک راه‌حل اختصاصی برای صنعت است، اما برخی از آزمایش‌های اخیر نشان می‌دهد Nginx دارای Caching بهتری نسبت به Varnish است.

بیشترین تفاوت بین Apache و Nginx در معماری نحوه‌ی رسیدگی به Request ‌ها است.

Apache، Request ‌ها را با MPM-s یا Multi-Processing-Modules پردازش می‌کند که “وظیفه‌ی اتصال به پورت‌های شبکه بر روی دستگاه، پذیرش Request ‌ها و Dispatch پردازنده ها برای رسیدگی به درخواست‌ها را بر عهده دارد.”

قدیمی‌ترین MPM که قدمت آن از آغاز Apache است، ماژول Prefork است. این Module را به‌تنهایی می‌توان دلیل بدنامی عملکرد Apache دانست. تحت این شرایط، Apache فرآیندهای جدید را با یک Thread در هر درخواست تولید می‌کند.

این Module با mod_php استفاده می‌شود و به این معنی است که سرور Apache در هر فرایند یک interpreter PHP را تعبیه کرده است، حتی اگر مجبور باشد فایل‌های CSS یا Image ها را serve کند.

Prefork به‌عنوان Module پیش‌فرض با Apache همراه است و اتصال به HTTP / 1 را محدود می‌کند.

در سال‌های بعد، Apache، Multi-threaded برای mpm و پس‌ازآن، Event mpm را توسعه داد که هردوی آن‌ها بسیاری از مشکلات عملکرد Apache را کاهش می‌دهند. php-fpm این امکان را برای Apache فراهم می‌کند که امروزه همراه با از بین بردن استفاده از htaccess. همچنان در رقابت باقی بماند.

Nginx از معماری Asynchronous و Non-blocking استفاده می‌کند.

در دنیای Linux/ Unix، فرایندها برنامه‌ها را اجرا می‌کنند. Thread ها زیرمجموعه‌ای از پردازش‌ها هستند و می‌توانند به‌صورت Multiple thread در اجرای فرآیند وجود داشته باشند، مثل وجود چندین Tab در پنجره‌ی مرورگر. به‌این‌ترتیب یک برنامه می‌تواند از CPU های Multiple و CPU های Multi-core و Multi-thread استفاده کند تا سریع‌تر اجرا شود.

به‌طور خلاصه، Apache از فرایندها برای هر اتصال استفاده می‌کند (و با mpm از Thread ها استفاده می‌کند) و در زمان افزایش ترافیک، به‌سرعت و بیش‌ازحد گران می‌شود.

می‌توان فرایند جدید یا ایجاد Thread را مانند راه‌اندازی کامپیوتر یا راه‌اندازی برنامه‌ها به تصویر کشید. حتی در سریع‌ترین کامپیوترها هم هنوز مدتی طول می‌کشد. امروزه وب‌سایت‌ها صدها درخواست را در یک صفحه Load می‌کنند.

Event mpm ازنظر Optimization کمی جلوتر است، اما برخی آزمایش‌ها نشان می‌دهد که نمی‌تواند Nginx را پشت سر بگذارد. به‌خصوص هنگامی‌که صحبت از فایل‌های Static می‌شود، سرعت درخواست‌هایی که Nginx برای ما serve می‌کند دو برابر Apache است.

Nginx در حالت ایدئال دارای یک فرایند Worker در هر CPU/core است. تفاوت فرایندهای Worker Nginx این است که هر یک می‌توانند صدها هزار اتصال شبکه ورودی را برای هر Worker مدیریت کند و برای ایجاد هر اتصال نیازی به ایجاد Thread یا فرآیند جدید نیست.

این دلیل آن است که شبکه‌های اصلی Content Delivery، مانند Cloudflare، MaxCDN و KeyCDN یا وب‌سایت‌هایی مانند Netflix، Nginx را برای Content Delivery خود بسیار مهم می‌دانند.

لیست شرکت‌هایی که از Nginx استفاده می‌کنند خیلی طولانی است. شرکت خصوصی WordPress.com و Automattic یکی از این موارد است. Automattic در سال 2008 تمام Load-balancer های خود را برای WordPress.com به Nginx تبدیل کرد و Stack سرور خود را به‌طور کامل به Nginx منتقل کرد.

اگر بخواهیم آنچه را که وب‌سایت‌ها در تولیدشان از آن استفاده کرده‌اند بررسی کنیم، معمولاً می‌توانیم این مورد را در Header های HTTP پیدا کنیم. این بدان معناست که باید روی یک وب‌سایت کلیک راست کرده و گزینه‌ی Inspect را بزنیم و سپس در قسمت Developer tool، گزینه‌ی Network panel را انتخاب کرده و وب‌سایت را Reload کنیم در نهایت همه‌ی منابعی را که وب‌سایت Load می‌کند مشاهده خواهیم کرد. اگر یک منبع خاص و Headers tab  آن را انتخاب کنیم، معمولاً اطلاعات سرور را مشاهده خواهیم کرد. اگر وب‌سایت از CDN استفاده کند ممکن است چیزی مانند Cloudflare و اگر از شتاب‌دهنده‌ی HTTP استفاده کند چیزی مانند Varnish را در Server line مشاهده کنیم.

این نمونه‌ای از وب‌سایت WordPress است که از تنظیمات معمول Shared hosting با cPanel، Apache و PHP استفاده می‌کند:

و این وب‌سایتی در Nginx است:

در سمت چپ، اگر آن را Expand کنیم، می‌توانیم زمان هر منبع را تجزیه‌وتحلیل کرده و تأثیر آن را بر روی زمان Load صفحه مشاهده کنیم.

در این مقاله، به بررسی تفاوت‌های Nginx و Apache پرداخته شد و تفاوت‌های اصلی در معماری این دو که باعث شد Nginx در فضای WebServer توجه بیشتری را به خود جلب کند را توضیح دادیم.

البته هر مورداستفاده، اولویت‌های یکسانی ندارد و Apache یا ابزارهای دیگری مانند Lighttpd، IIS، LiteSpeed ، Caddy نیز می‌توانند راه‌حل‌های خوبی باشند.

در Kinsta، از Nginx به‌عنوان بخشی از راه‌حل‌های Performance-optimized hosting برای WordPress و WooCommerce استفاده می‌شود. هر سایت WordPress در Container جداگانه خود قرار دارد که دارای تمام منابع نرم‌افزاری موردنیاز برای اجرای آن است (Nginx، Linux، PHP، MySQL). منابع 100٪ خصوصی هستند و بین هیچ سایت دیگری به اشتراک گذاشته نمی‌شوند.

Kinsta، یک شرکت میزبانی است که راه‌حلی مقیاس‌پذیر و امن برای WordPress ارائه داده است. برای استفاده از امکانات Kinsta می‌توانید به آدرس https://kinsta.com/ مراجعه کنید.