در ایم مقاله به بررسی Nginx در مقابل Apache می پردازیم. اینترنت، همانطور که امروز می شناسیم، “فتح” جهانی خود را در دهه 90 آغاز کرد. کل پروتکل “وب” را می توان به عنوان یک بازدید کننده خلاصه کرد که یک سند را از یک آدرس وب معین درخواست می کند، با سیستم DNS و IP که آن درخواست را به رایانه مناسب ارسال می کند. این رایانه که میزبان صفحه وب درخواستی است، صفحه وب را به بازدیدکننده “خدمت” می کند.
صفحات وب اساسا اسناد HTML هستند. برای اینکه بتواند صفحات وب مختلف را به بازدیدکنندگان ارائه دهد، ماشین سرویس دهنده به یک برنامه سرور نیاز دارد. نرمافزارهایی مانند Nginx در مقابل Apache درخواستها را بررسی میکنند، آنها را تجزیه و تحلیل میکنند و سپس اسناد مربوطه را برای مشاهده در مرورگر بازدیدکننده تحویل میدهند.
Nginx در مقابل Apache
Nginx و Apache وب سرورهای محبوبی هستند که برای ارائه صفحات وب به مرورگر کاربر استفاده می شوند. در مورد ما، از یک سایت وردپرس میزبانی شده است. آمار سریع:
- آپاچی ابتدا در سال 1995 منتشر شد و سپس Nginx در سال 2004 منتشر شد.
- هر دو توسط شرکت های بزرگ Fortune 500 در سراسر جهان استفاده می شوند.
- سهم بازار Nginx سالهاست که به طور پیوسته در حال رشد بوده است.
- در برخی موارد، Nginx از نظر عملکرد دارای مزیت رقابتی است.
آپاچی
از زمانی که آپاچی برای اولین بار منتشر شد، ابتدا به داخل آپاچی می پردازیم.
پس از CERN httpd تیم برنرز لی و HTTPd NCSA در چند سال اول اینترنت، آپاچی – اولین بار در سال 1995 منتشر شد – به سرعت بازار را تسخیر کرد و به محبوب ترین وب سرور جهان تبدیل شد. امروزه، هنوز در آن موقعیت بازار است، اما بیشتر به دلایل قدیمی. آپاچی توسط بنیاد آپاچی و تحت مجوز آپاچی در حال توسعه و نگهداری است.
دو داستان متفاوت در مورد چگونگی نامگذاری آپاچی وجود دارد. یک نسخه می گوید که این نام از میراث معروف بومیان آمریکا سرچشمه می گیرد، در حالی که نسخه دیگر می گوید که این نام یک جناس در “سرور ناهموار” است که به دنبال یک سری از وصله های نرم افزاری است.
لینوکس
سهم بزرگ Apache در بازار تا حدی به این دلیل است که با تمام توزیعهای اصلی لینوکس مانند Red Hat/Centos و Ubuntu از پیش نصب شده است.
یکی از نمونههای نقش مهم آپاچی در دنیای لینوکس این است که نام فرآیند سرور آن HTTPd است، که Apache را مترادف با نرمافزار وب سرور میکند.
علاوه بر اینکه اولین بازیکن جدی در بازار وب سرور است، بخشی از گسترش آپاچی به دلیل سیستم پیکربندی و فایل htaccess آن است.
htaccess
آپاچی از .htaccess برای پیکربندی خود استفاده می کند. آموزش های زیادی در مورد نحوه پیکربندی، ویرایش و کار با این فایل وجود دارد، زیرا این فایل انعطاف پذیری زیادی را در پیکربندی نحوه رسیدگی به درخواست های دریافتی آپاچی فراهم می کند. برخی از نمونهها عبارتند از: قوانین تغییر مسیر مختلف، حداکثر اندازه فایل آپلود، بازنویسی URL، محدودیتهای حافظه، حفاظت از دایرکتوری (htpasswd)، سرصفحههای منقضی، سرصفحههای کنترل حافظه پنهان، سرصفحههای رمزگذاری، کوکیها، دستکاری رشتههای جستجو.
از طرف دیگر، Nginx از فایل های htaccess. پشتیبانی نمی کند. با این حال، تنظیمات و قوانین فایلهای htaccess. شما را میتوان به راحتی به سینتکس قانون بازنویسی Nginx ترجمه کرد.
یکی از “مزایای” اصلی Apache این است که در ریشه سرور – دایرکتوری اصلی وب سایت – هر سطح یا دایرکتوری در درخت دایرکتوری می تواند فایل .htaccess خود را با پیکربندی خاص خود داشته باشد.
پیکربندی .htaccess
برای ارائه دهندگان میزبانی مشترک، این یک رویا است زیرا آنها می توانند روشی را برای صدها کاربر در یک دستگاه ارائه کنند تا نحوه سرویس دهی وب سایت هایشان را بدون اینکه روی دیگران تأثیر بگذارند، پیکربندی کنند. مشتریان می توانند بسیاری از جزئیات را در یک محیط میزبانی مشترک محدود پیکربندی کنند، در حالی که هرگز به پیکربندی سرور جهانی دست نزنند.
هر بار که فایلهای .htaccess فعال میشوند، آپاچی باید کل درخت دایرکتوری را از URL یا فایل درخواستی در تمام سطوح بالاتر تا دایرکتوری ریشه سرور طی کند و سپس آنها را برای هر درخواست بارگذاری کند. سپس باید این فایل ها را پردازش کرده و خود را برای هر یک از دایرکتوری های پیکربندی شده به این روش پیکربندی مجدد کند.
با وب سایت های وردپرس، همه چیز می تواند واقعا پیچیده شود. یک وب سایت معمولی وردپرس می تواند صدها درخواست از دایرکتوری های مختلف داشته باشد.
یک تجزیه و تحلیل نشان داده است که یک تنظیم معمولی وردپرس، که برای وبسایتها در میزبانهای مشترک رایج است، شامل 42 اجرای .htaccess و 249 نگاه جداگانه برای فایل htaccess است.
این فقط در سطح وب سرور است. بازدیدکننده هنوز باید منتظر باشد تا فرآیند PHP کل پشته فراخوانی وردپرس را اجرا کند تا کوئری پایگاه داده را ایجاد کند و آن را به MySQL بدهد تا صفحه وب را جمع کند و برای بازدیدکننده ارسال کند.
ماژول ها
یکی دیگر از مواردی که باعث محبوبیت آپاچی شد، سیستم ماژول پویا آن است.
ماژول ها – به عنوان ویژگی که به کاربران اجازه می دهد تا عملکرد وب سرور را گسترش دهند – در Nginx و Apache وجود دارند. آپاچی به کاربران این امکان را می دهد که ماژول ها را پس از نصب و استقرار وب سرور نصب کنند و سپس در صورت نیاز آنها را فعال/غیرفعال کنند. توزیعهای مبتنی بر دبیان دارای دستوراتی هستند که امکان فعال و غیرفعال کردن این ماژولها را بدون نیاز به ویرایش فایلهای پیکربندی فراهم میکنند: a2enmod و a2dismod.
لیست رسمی ماژول هایی که به عنوان بخشی از توزیع استاندارد آپاچی ارائه می شوند در اینجا آمده است و شامل مواردی از فشرده سازی، رمزگذاری، ورود به سیستم، تغییر مسیر تا موارد پیشرفته تر مانند ویرایش درخواست ها و پاسخ ها با نحو پیشرفته است.
Nginx
Nginx (همچنین به عنوان nginx یا NGINX نوشته شده است)، در سال 2004 وارد صحنه شد، زمانی که برای اولین بار توسط توسعه دهنده روسی ایگور سیسوف به صورت عمومی منتشر شد . همانطور که اوون گرت، مدیر پروژه Nginx گفت:
این سرور برای اولین بار به عنوان یک ابزار مقیاس پذیر برای وب سایت rambler.ru در سال 2002 ایجاد شد. این سرور در دو نسخه ارائه می شود: منبع باز، با مجوز نوع BSD، و Nginx Plus، با پشتیبانی و ویژگی های سازمانی اضافی.
پس از انتشار، Nginx بیشتر برای ارائه فایلهای استاتیک و بهعنوان متعادلکننده بار یا پروکسی معکوس در مقابل نصبهای آپاچی استفاده شد. با تکامل وب و نیاز به کاهش آخرین قطره سرعت و کارایی استفاده از سخت افزار با آن، وب سایت های بیشتری شروع به جایگزینی کامل Apache با Nginx کردند، همچنین به لطف یک نرم افزار بالغ تر.
در مارس 2019، Nginx Inc توسط F5 Networks به مبلغ 670 میلیون دلار خریداری شد. در آن لحظه، همانطور که Techcrunch گزارش می دهد، سرور Nginx «375 میلیون وب سایت با حدود 1500 مشتری پولی» را تامین می کرد.
بر اساس دادههای w3techs ، سهم بازار Nginx به طور پیوسته در حال رشد بوده و آپاچی را بیرون میکشد و آن را از جایگاه اول پایین میآورد:
این داده ها مربوط به کل وب سرورهای جهانی است، اما اگر نمونه ای از یک میلیون وب سایت برتر را در نظر بگیریم، Nginx مدتی است که وجود دارد:
به نظر می رسد Google Search Trends این واقعیت را نیز منعکس می کند:
نظرسنجی نت کرافت نشان می دهد که Apache در آوریل 2019 توسط Nginx پیشی گرفته است.
پیکربندی Nginx
Nginx یک سیستم پیکربندی مانند Apache ندارد، بنابراین، با وجود کارآمدتر و سریعتر بودن آن، به طور گسترده در ارائهدهندگان میزبانی خردهفروشی استفاده نمیشود. در محیط های مشترک مانند آپاچی نمی درخشد.
از طرف دیگر، همانطور که گفتیم، با اجازه ندادن به تنظیمات در سطح دایرکتوری، Nginx برتری قابل توجهی نسبت به آپاچی به دست می آورد. مقاله ای در ویکی Nginx وجود دارد که تأثیر عملکرد را با هم مقایسه می کند:
ماژول های Nginx
سیستم ماژول های Nginx یکی دیگر از مواردی است که آن را به عنوان یک انتخاب برتر قرار می دهد. ماژولهای Nginx معمولاً باید در زمان ساخت فعال شوند، به این معنی که مهارت فنی بیشتری درگیر است، و اضافه کردن ماژولها پس از نصب کمی پیچیدهتر است.
در سال 2016، با نسخه 1.9.11، همه چیز تغییر کرد و مخزن رسمی/تأیید شده ماژول های پویا برای کاربران پرداخت کننده محفوظ است. از ماه می 2019، آنها شروع به توسعه پشتیبانی برای QUIC و HTTP/3 را اعلام کردند.
موضوع ذخیره سازی: Nginx در مقابل آپاچی
ذخیره سازی – اگر بخواهیم آن را بیش از حد ساده کنیم – می تواند به عنوان آماده سازی محتوا برای بازدیدکنندگان وب سایت قبل از بازدید آنها تصویر شود، به طوری که وقتی آنها “در را می زنند”، نیازی نیست به دنبال محتوای مورد نظر آنها بگردید. شما از قبل آن را آماده کرده اید و بدون هیچ انتظاری آن را به آنها تحویل می دهید.
مانند Apache، نصب معمولی Nginx برای قرار دادن بین سرورها و کاربر نهایی برای کاهش ضربه عملکرد در بقیه زیرساخت ها بود. در این موارد، میتواند محتوای استاتیک را بدون نیاز به واکشی هر بار از سرور محافظتشده و مبدا کش کند.
اگر از Nginx به عنوان یک وب سرور مستقل استفاده کنیم. چنین نیازی وجود ندارد. Nginx در ارائه محتوای ثابت به تنهایی بسیار کارآمد است.
سپس موضوع کش پویا یا کش صفحه وجود دارد. در سناریوی یک وب سایت وردپرس، این به معنای ذخیره تمام صفحات وردپرس تولید شده برای هر URL در حافظه یا روی دیسک است.
ذخیره سازی FastCGI به صورت بومی در نصب استاندارد Nginx در دسترس است. این ساده، بسیار قدرتمند و یکی از ویژگی های Nginx است که کمتر مورد استفاده قرار می گیرد.
برای مقایسه آن با معادلهای آپاچی، باید بدانید که آپاچی دارای ماژول mod_cache است که طبق گزارشها، دارای مشکل است و با ماژولهای دیگر در تضاد است. بنابراین راه حل استاندارد کش که با آپاچی مستقر شده است، شتاب دهنده HTTP Varnish است. اگرچه وارنیش راهحل اختصاصی صنعت است، اما برخی از آزمایشهای اخیر به حافظه پنهان Nginx برتری بیشتری نسبت به Varnish میدهد.
رسیدگی به درخواست ها: Nginx در مقابل Apache
بزرگترین تفاوت بین Apache و Nginx در معماری زیربنایی نحوه رسیدگی به درخواست ها است.
آپاچی درخواستها را با MPM-s یا Multi-Processing-Modules پردازش میکند که «مسئول اتصال به پورتهای شبکه در دستگاه، پذیرش درخواستها و اعزام کودکان برای رسیدگی به درخواستها است».
قدیمیترین MPM که قدمت آن به آغاز آپاچی باز میگردد، ماژول prefork است. این ماژول به تنهایی می تواند به دلیل شهرت بد عملکرد Apache باشد. تحت این حالت، آپاچی فرآیند جدیدی را با یک رشته در هر درخواست ایجاد می کند.
این ماژول، که با mod_php استفاده میشود، به این معنی است که سرور آپاچی یک مفسر PHP را در هر فرآیند جاسازی میکند، حتی اگر مجبور باشد فایلها یا تصاویر CSS را ارائه دهد.
این ناکارآمد بود. ماژول Prefork با آپاچی به عنوان ماژول پیش فرض ارائه می شود. همچنین اتصالات به HTTP/1 را محدود می کند.
در سالهای بعد، آپاچی mpm ورکر چند رشتهای و پس از آن رویداد mpm را توسعه داد. هر دوی آنها بسیاری از مشکلات عملکرد آپاچی را کاهش می دهند. جابجایی به php-fpm این امکان را برای آپاچی فراهم میکند که امروزه در کنار حذف استفاده از htaccess، همچنان یک راهحل رقیب باشد، اما این نوع هدف آن را شکست میدهد.
Nginx از معماری رویداد محور غیرهمزمان و غیر مسدود کننده استفاده می کند. برای توضیح تفاوت: در دنیای لینوکس/یونیکس، فرآیندها برنامههایی هستند که در حال اجرا هستند.
Thread ها زیرمجموعه ای از فرآیندها هستند و می توانند چندین رشته در یک اجرای فرآیند وجود داشته باشند. این را به عنوان چندین برگه در یک پنجره مرورگر در نظر بگیرید. به این ترتیب یک برنامه می تواند از چندین CPU و CPU های چند هسته ای و چند رشته ای برای اجرای سریعتر استفاده کند. می توانید لینوس توروالدز را بخوانید که تفاوت ها را توضیح می دهد.
معماری وب سرور ها
به طور خلاصه، آپاچی از فرآیندها برای هر اتصال استفاده می کند (و با worker mpm از Thread ها استفاده می کند). با افزایش ترافیک، به سرعت بسیار گران می شود.
میتوانیم فرآیند جدید یا ایجاد رشته مانند راهاندازی رایانه یا راهاندازی برنامهها را به تصویر بکشیم. حتی در سریع ترین رایانه ها، باز هم کمی زمان می برد. امروزه با توجه به اینکه وبسایتها صدها درخواست را در یک صفحه بارگذاری میکنند، این به سرعت اضافه میشود.
Event mpm از نظر بهینه سازی کمی فراتر می رود، اما برخی آزمایشات نشان می دهد که نمی تواند از Nginx پیشی بگیرد. به خصوص وقتی در مورد فایلهای استاتیک صحبت میکنیم، جایی که Nginx به اندازه دو برابر درخواستهای آپاچی عمل میکند.
Nginx به طور ایدهآل یک فرآیند ورکردر هر CPU/core دارد. تفاوت فرآیندهای کارگر Nginx در این است که هر یک می تواند صدها هزار اتصال شبکه ورودی را به ازای هر کارگر اداره کند. نیازی به ایجاد موضوعات یا فرآیندهای جدید برای هر اتصال نیست.
به همین دلیل است که شبکههای اصلی تحویل محتوا، مانند Cloudflare ، MaxCDN یا وبسایتهایی مانند Netflix که Nginx را برای ارائه محتوای خود حیاتی میدانند.
فهرست شرکتهایی که از Nginx استفاده میکنند برای فهرست کردن همه آنها بسیار طولانی است، بنابراین به Automattic، شرکت خصوصی پشت WordPress.com پایان میدهیم.
Automattic تمام بار متعادل کننده های خود را در سال 2008 به Nginx برای WordPress.com تبدیل کرد (شما می توانید در مورد آن در اینجا بخوانید ) و پشته سرور خود را به طور کامل به Nginx منتقل کرد.
بررسی در دنیای واقعی
اگر بخواهیم آنچه را که وب سایت در تولید استفاده می کند بررسی کنیم، معمولاً می توانیم آن را در سرفصل های پاسخ HTTP پیدا کنیم. این بدان معناست که ما باید روی یک وبسایت کلیک راست کنیم > Inspect، در ابزارهای توسعهدهنده، پانل شبکه را انتخاب میکنیم و سپس وبسایت را دوباره بارگیری میکنیم. ما تمام منابعی که وب سایت در حال بارگیری است را خواهیم دید. اگر منبع خاصی و تب Headers آن را انتخاب کنیم، معمولاً اطلاعات سرور را مشاهده می کنیم. اگر وبسایت از CDN استفاده میکند، اگر وبسایت از شتابدهنده HTTP استفاده میکند، ممکن است چیزی شبیه Cloudflare در خط سرور یا چیزی شبیه Varnish ببینیم.
در این تصویر نمونه ای از یک وب سایت وردپرسی است که از یک راه اندازی میزبانی مشترک معمولی با cPanel، Apache و PHP استفاده می کند:
این یک وب سایت در Nginx است:
در سمت چپ، اگر آن را گسترش دهیم، همچنین میتوانیم زمان هر منبع را تجزیه و تحلیل کنیم و تأثیر آن را بر زمان بارگذاری کلی صفحه ببینیم.
منبع:
https://kinsta.com/blog/nginx-vs-apache/