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

یکی از نمونه‌های نقش مهم آپاچی در دنیای لینوکس این است که نام فرآیند سرور آن HTTPd است که Apache را مترادف با نرم‌افزار وب سرور می‌کند.

علاوه بر اینکه اولین بازیکن جدی در بازار وب سرور است، بخشی از گسترش آپاچی به دلیل سیستم پیکربندی و فایل htaccess آن است .

htaccess

آپاچی از .htaccess برای پیکربندی خود استفاده می کند. آموزش های زیادی در مورد نحوه پیکربندی، ویرایش و کار با این فایل وجود دارد، زیرا این فایل انعطاف پذیری زیادی را در پیکربندی نحوه رسیدگی به درخواست های دریافتی آپاچی فراهم می کند. برخی از نمونه‌ها عبارتند از: قوانین تغییر مسیر مختلف ، حداکثر اندازه فایل آپلود ، بازنویسی URL، محدودیت‌های حافظه ، حفاظت از دایرکتوری (htpasswd)، سرصفحه‌های منقضی ، سرصفحه‌های کنترل حافظه پنهان ، سرصفحه‌های رمزگذاری ، کوکی‌ها، دستکاری رشته‌های جستجو.

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

یکی از “مزایای” اصلی آپاچی این است که در ریشه سرور – دایرکتوری اصلی وب سایت – هر سطح یا دایرکتوری در درخت دایرکتوری می تواند فایل .htaccess خود را با پیکربندی خاص خود داشته باشد.

برای ارائه دهندگان میزبانی مشترک ، این یک رویا است زیرا آنها می توانند روشی را برای صدها کاربر در یک دستگاه ارائه کنند تا نحوه سرویس دهی وب سایت های خود را بدون تأثیرگذاری بر سایرین، پیکربندی کنند. مشتریان می توانند بسیاری از جزئیات را در یک محیط میزبانی مشترک محدود پیکربندی کنند، در حالی که هرگز به پیکربندی سرور جهانی دست نزنند.

همانطور که اسناد رسمی می گوید:

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

با این حال، این انعطاف‌پذیری به قیمت بهای عملکرد تمام می‌شود .

هر بار که فایل‌های .htaccess فعال می‌شوند، آپاچی باید کل درخت دایرکتوری را از URL یا فایل درخواستی در تمام سطوح بالاتر تا دایرکتوری ریشه سرور طی کند و سپس آنها را برای هر درخواست بارگذاری کند. سپس باید این فایل ها را پردازش کرده و خود را برای هر یک از دایرکتوری های پیکربندی شده به این روش پیکربندی مجدد کند.

با وب سایت های وردپرس، همه چیز می تواند واقعا پیچیده شود. یک وب سایت معمولی وردپرس می تواند صدها درخواست از دایرکتوری های مختلف داشته باشد.

از /wp-content/uploads/yyyy/mm نوع dir، معمولاً چندین درخواست در بارگذاری یک صفحه دارد که اغلب دایرکتوری‌های ماهانه متفاوتی را تشکیل می‌دهند. سپس منابع استاتیک /wp-content/themes/parent-theme، /wp-content/themes/child-theme منابع وجود خواهد داشت: این منابع شامل جاوا اسکریپت، فایل‌های css ، تصاویر می‌شوند.

سپس /wp-content/plugins با فایل های ثابت بارگذاری شده از ده ها زیرشاخه پلاگین نیز وجود خواهد داشت. برای هر یک از این منابع، آپاچی باید کل درخت خود را طی کند تا پیکربندی را جستجو کند.

یک تجزیه و تحلیل نشان داده است که یک تنظیم معمولی وردپرس، که برای وب‌سایت‌ها در میزبان‌های مشترک رایج است، شامل ۴۲ اجرای .htaccess و ۲۴۹ نگاه جداگانه برای فایل htaccess است.

این فقط در سطح وب سرور است. بازدیدکننده هنوز باید منتظر باشد تا فرآیند PHP کل پشته فراخوانی وردپرس را اجرا کند تا کوئری پایگاه داده را ایجاد کند و آن را به MySQL بدهد تا صفحه وب را جمع کند و برای بازدیدکننده ارسال کند.

ماژول ها

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

ماژول ها – به عنوان ویژگی که به کاربران اجازه می دهد تا عملکرد وب سرور را گسترش دهند – در Nginx و Apache وجود دارند. آپاچی به کاربران این امکان را می دهد که ماژول ها را پس از نصب و استقرار وب سرور نصب کنند و سپس در صورت نیاز آنها را فعال/غیرفعال کنند. توزیع‌های مبتنی بر دبیان دارای دستوراتی هستند که امکان فعال و غیرفعال کردن این ماژول‌ها را بدون نیاز به ویرایش فایل‌های پیکربندی فراهم می‌کنند: a2enmod و a2dismod.

لیست رسمی ماژول هایی که به عنوان بخشی از توزیع استاندارد آپاچی ارائه می شوند در اینجا آمده است و شامل مواردی از فشرده سازی، رمزگذاری، ثبت نام، تغییر مسیر تا موارد پیشرفته تر مانند ویرایش درخواست ها و پاسخ ها با نحو پیشرفته است.

Nginx

Nginx (همچنین به عنوان nginx یا NGINX نوشته شده است)، در سال ۲۰۰۴ وارد صحنه شد، زمانی که برای اولین بار توسط توسعه دهنده روسی ایگور سیسوف به صورت عمومی منتشر شد . همانطور که اوون گرت، مدیر پروژه Nginx گفت :

Nginx به طور خاص برای رفع محدودیت های عملکرد سرورهای وب آپاچی نوشته شده است.

این سرور برای اولین بار به عنوان یک ابزار مقیاس پذیر برای وب سایت rambler.ru در سال ۲۰۰۲ ایجاد شد. این سرور در دو نسخه ارائه می شود: منبع باز، با مجوز نوع BSD ، و Nginx Plus ، با پشتیبانی و ویژگی های سازمانی اضافی.

پس از انتشار، Nginx بیشتر برای ارائه فایل‌های استاتیک و به‌عنوان متعادل‌کننده بار یا پروکسی معکوس در مقابل نصب‌های آپاچی استفاده شد. با تکامل وب و نیاز به کاهش آخرین قطره سرعت و کارایی استفاده از سخت افزار با آن، وب سایت های بیشتری شروع به جایگزینی کامل Apache با Nginx کردند، همچنین به لطف یک نرم افزار بالغ تر.

در مارس ۲۰۱۹، Nginx Inc توسط F5 Networks به مبلغ ۶۷۰ میلیون دلار خریداری شد . در آن لحظه، همانطور که Techcrunch گزارش می دهد، سرور Nginx «۳۷۵ میلیون وب سایت با حدود ۱۵۰۰ مشتری پولی» را تامین می کرد.

بر اساس داده‌های w3techs ، سهم بازار Nginx به طور پیوسته در حال رشد بوده و آپاچی را بیرون می‌کشد و آن را از جایگاه اول پایین می‌آورد.

Web server usage

این داده ها مربوط به کل وب سرورهای جهانی است، اما اگر نمونه ای از یک میلیون وب سایت برتر را در نظر بگیریم، Nginx مدتی است که وجود دارد.

Percentage of websites using Nginx

به نظر می رسد Google Search Trends این واقعیت را نیز منعکس می کند.

Google Search Trends: Nginx vs Apache

پیکربندی Nginx

Nginx یک سیستم پیکربندی مانند Apache ندارد، بنابراین، با وجود کارآمدتر و سریع‌تر بودن، به طور گسترده در ارائه‌دهندگان میزبانی خرده‌فروشی استفاده نمی‌شود. در محیط های مشترک مانند آپاچی نمی درخشد.

از طرف دیگر، همانطور که گفتیم، با اجازه ندادن به تنظیمات در سطح دایرکتوری، Nginx برتری قابل توجهی نسبت به آپاچی به دست می آورد. مقاله ای در ویکی Nginx وجود دارد که تأثیر عملکرد را با هم مقایسه می کند.

Performance impact Nginx vs Apache.png

ماژول های Nginx

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

در سال ۲۰۱۶، با نسخه ۱.۹.۱۱، همه چیز تغییر کرد و مخزن رسمی/تأیید شده ماژول های پویا برای کاربران پرداخت کننده محفوظ است. از ماه می ۲۰۱۹، آنها شروع به توسعه پشتیبانی برای 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، و شریک ما KeyCDN – یا وب‌سایت‌هایی مانند Netflix – Nginx را برای ارائه محتوای خود ضروری می‌دانند.

فهرست شرکت‌هایی که از Nginx استفاده می‌کنند برای فهرست کردن همه آن‌ها بسیار طولانی است، بنابراین به Automattic، شرکت خصوصی پشت WordPress.com پایان می‌دهیم.

Automattic تمام بار متعادل کننده های خود را در سال ۲۰۰۸ به Nginx برای WordPress.com تبدیل کرد (شما می توانید در مورد آن در اینجا بخوانید ) و پشته سرور خود را به طور کامل به Nginx منتقل کرد .

بررسی آن در زندگی واقعی

اگر بخواهیم آنچه را که وب سایت در تولید استفاده می کند بررسی کنیم، معمولاً می توانیم آن را در سرفصل های پاسخ HTTP پیدا کنیم. این بدان معناست که باید روی یک وب‌سایت کلیک راست کنیم > Inspect ، در ابزارهای توسعه‌دهنده، پانل شبکه را انتخاب می‌کنیم و سپس وب‌سایت را دوباره بارگیری می‌کنیم. ما تمام منابعی که وب سایت در حال بارگیری است را خواهیم دید. اگر منبع خاصی و تب Headers آن را انتخاب کنیم ، معمولاً اطلاعات سرور را مشاهده می کنیم. اگر وب‌سایت از CDN استفاده می‌کند، اگر وب‌سایت از شتاب‌دهنده HTTP استفاده می‌کند، ممکن است چیزی شبیه Cloudflare در خط سرور یا چیزی شبیه Varnish ببینیم.

این نمونه ای از یک وب سایت وردپرسی است که از یک راه اندازی میزبانی مشترک معمولی با cPanel، Apache و PHP استفاده می کند:

Apache HTTP header

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

Nginx HTTP header

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

خلاصه

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

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

و بخوانید: