عالم خوادم الويب: Apache مقابل Nginx

مقدمة إلى Apache و Nginx

تم تصميم خوادم الويب والبروتوكولات لتمكين المستخدمين من عرض صفحات الويب. حيث يقومون بإرسال طلب لعرض مستند يقبله الخادم. ثم يقوم المضيف أساساً بتقديم المستند أو المعلومات للمشاهد. يلعب خادم الويب دوراً رئيسياً في السماح لك بعرض صفحات الويب والوصول إليها على متصفحك.

هناك العديد من خوادم الويب التي يمكنك استخدامها لهذا الغرض. ومن بين أكثرها شعبية Nginx و Apache. في الواقع، تستضيف هذه الخوادم معظم مواقع الويب المتاحة حالياً على الإنترنت.

يتشابه Apache و Nginx تماماً في العديد من الجوانب. بادئ ذي بدء، كلا خادمي الويب مفتوحا المصدر. هذا يعني أنه يمكن لأي شخص في العالم استخدامهما دون أي تكلفة على الإطلاق. ولكن هناك العديد من الميزات الفريدة لكل من الخادمين. هذه الخصائص الخاصة تجعلهما الأكثر ملاءمة لمختلف التطبيقات والأغراض.

لمساعدتك في تحديد أي خادم ويب هو الأفضل أو المثالي بالنسبة لك، سنقوم بمقارنة Nginx و Apache. سيتم إجراء المقارنة عبر عدد من المعايير الأساسية المهمة لمستخدمي خوادم الويب. فلنبدأ!

نظرة عامة أساسية

سنبدأ بنظرة عامة على خادمي الويب. لقد بنى كل من Apache و Nginx سمعة طيبة في المجتمع. وهما معروفان بأدائهما وتستخدمهما العديد من المؤسسات الكبرى حول العالم.

Apache

ظهر Apache في عام 1995. قام Robert McCool بتطوير خادم HTTP هذا تحت مظلة the Apache Software Foundation، ومن هنا جاء الاسم. ومنذ إطلاقه، يستخدم مئات الآلاف من الأشخاص حول العالم Apache.

شعبيته الجارفة تعني أن الكثير من برامج ومصادر الطرف الثالث تتعاون معه بشكل متكرر. وبالتالي، إذا كنت تبحث عن شبكة دعم جيدة مع الكثير من عمليات التكامل، فإن Apache هو الخيار المناسب لك. يفضل الكثير من الناس Apache أيضاً لأنه أكثر ديناميكية ومرونة. كما أنه يوفر نطاقاً أوسع من اللغات التي يمكنه تفسيرها.

Nginx

Nginx هو خادم ويب أحدث نسبياً، حيث ظهر في عام 2004. وهو نتيجة لجهود Igor Syosev للتعامل مع مشكلة تُعرف الآن باسم مشكلة C10K. نشأت هذه المشكلة عندما بدأ يصبح من الصعب على الخوادم التعامل مع كميات هائلة من حركة المرور. ومع بدء زيادة عدد مستخدمي الإنترنت، بدأت خوادم مواقع الويب في التعرض للضغط الشديد. وقد أدى عدم قدرة هذه الخوادم على التعامل مع عدة آلاف من الاتصالات في نفس الوقت إلى تعطل المواقع وفشلها.

تم إصدار Nginx لمحاولة حل هذه المشكلة. ولهذا السبب تتميز بنيته بتصميم خفيف الوزن للغاية، وقادر على العمل بموارد وأجهزة محدودة. في حين أنه الأنسب للعمل مع المحتوى الثابت، إلا أنه يمكنه التكامل مع البرامج التي يمكنها التعامل مع المحتوى الديناميكي بشكل مناسب أيضاً.

قدرات التعامل مع حركة المرور

الآن بعد أن أخذنا فكرة أساسية عن كل من الخادمين، يمكننا الغوص في مزيد من التفاصيل. الميزة الأولى التي سنبدأ بها هي قدرات التعامل وحركة المرور لكل خادم على حدة. هذه واحدة من النقاط الرئيسية التي تفصل بين هاتين المنصتين. تعمل بنيتهما على مبادئ مختلفة عندما يتعلق الأمر بالتعامل مع اتصالات متعددة في نفس الوقت.

Apache

يستخدم Apache شيئاً يسمى MPM- Multi-Processing Modules. يستخدم المسؤولون مجموعة متنوعة من وحدات MPM للتلاعب ببنية معالجة الاتصالات وتعديلها. جزء من جاذبية خادم ويب Apache هو المرونة التي توفرها بنيته. إن مثل هذه البنية التحتية القائمة على الوحدات والتي تقسم المعالجة إلى خيوط فردية ومجموعات تسهل التوسع والتكيف مع أنواع مختلفة من الاتصالات.

دعونا’ نلقي نظرة على بعض الوحدات الفردية المستخدمة في Apache:

• mpm_prefork

الأول هو mpm_prefork. هذه وحدة معالجة مسؤولة عن التعامل مع الطلبات الواردة من الزوار. وهي تنشئ خيط معالجة (thread) واحدًا أو عملية فرعية واحدة للتعامل مع اتصال واحد في أي وقت محدد. وهذا يعني أنه إذا كان عدد الطلبات أقل من عدد العمليات، فإن mpm_prefork تكون فعالة للغاية في وظيفتها.

تتم معالجة الطلبات بسرعة نظرًا لأن عملية فرعية منفصلة تعالج كل طلب على حدة. ولكن هذا يعني أيضًا أنه إذا تجاوز عدد الطلبات عدد العمليات، فقد يؤدي ذلك إلى إبطاء الأمور بشكل كبير. ونتيجة لذلك، فإن خطوة معالجة الطلبات تستهلك الكثير من ذاكرة الوصول العشوائي (RAM).

• mpm_worker

كما نعلم بالفعل، فإن خيط معالجة واحدًا مسؤول عن اتصال واحد. تذهب هذه الوحدة خطوة إلى الأمام وتمكنك من إدارة خيوط معالجة متعددة في وقت واحد. هذه وحدة أكثر قابلية للتوسع بكثير مقارنة بـ mpm_prefork التي تواجه صعوبة بعد حد معين. يمكن للاتصالات الجديدة الارتباط بخيط معالجة على الفور بدلاً من الاضطرار إلى الانتظار.

• mpm_event

إن mpm_event مسؤولة عن الحفاظ على اتصالات keep-alive (إبقاء الاتصال نشطًا). الغرض الأساسي من هذه الوحدة هو منع النظام من التباطؤ بسبب طلبات keep-alive. وهي تفعل ذلك من خلال تخصيص خيط معالجة للاتصال حتى بدون وجود طلب نشط. سيظل خيط المعالجة مخصصًا طالما أن الاتصال نشط. ويتم نقل أي طلبات واردة إلى خيوط معالجة غير شاغرة.

Nginx

على عكس Apache، تم بناء Nginx لغرض محدد للغاية. كنا نعرف بالفعل المشكلات التي كانت تنشأ مع الاتصال وقابلية التوسع على هذا المستوى. ولهذا السبب يستخدم خوارزمية غير متزامنة وغير مانعة (non-blocking). وهو لا يخصص خيوط معالجة فردية لكل اتصال. بدلاً من ذلك، ينتج Nginx العديد من عمليات العمل (worker processes) القادرة على التعامل مع آلاف الاتصالات في وقت واحد.

مبدأ العمل وراء بنية Nginx هو آلية التكرار الحلقي السريع (fast looping mechanism). تقوم هذه الخوارزمية بمعالجة الأحداث ومراقبتها باستمرار. وهذا يعني أن العمليات موجهة بالأحداث (event-driven) وكل عملية عمل تكون ملتزمة فقط باتصالاتها الخاصة. تقع جميع اتصالات عملية العمل في حلقة أحداث (event loop). وهنا، تتعايش وتخضع للمعالجة بشكل غير متزامن مع الاتصالات الأخرى التابعة لهذا العامل المحدد.

الفائدة الرئيسية لمثل هذه البنية هي أنها تتيح قدرة كبيرة على التوسع. ويصبح هذا قابلاً للتطبيق بشكل خاص إذا كانت لديك موارد محدودة أو كنت ترغب في العمل بأقل قدر من الأجهزة. وحتى لو كنت تواجه كميات كبيرة من حركة المرور (traffic)، فلن يكون هناك تأثير يذكر على استخدام ذاكرة الوصول العشوائي (RAM). وذلك لأنك لا تقوم بإنشاء خيوط معالجة فردية لكل اتصال.

التعامل مع المحتوى الثابت والديناميكي

هناك معيار آخر يمكننا استخدامه لمقارنة خادمي الويب وهو كيفية تعاملهما مع المحتوى الثابت و المحتوى الديناميكي.

Apache

يستخدم Apache طريقة تعتمد على الملفات للتعامل مع المحتوى الثابت. يتيح له نظام معالجة MPM الخاص به العمل بهذه الطريقة التقليدية.

عندما يتعلق الأمر بمعالجة المحتوى الديناميكي، يمكن لـ Apache القيام بذلك دون الحاجة إلى مساعدة من أي مكونات خارجية. يمكنك تمكين المعالجات الديناميكية عن طريق تحميل وحدة نمطية (module). ستقوم هذه الوحدة بمعالجة المحتوى من خلال تحليل اللغة ثم دمج المعالج ذي الصلة في عملية العمل (worker).

تتضح الفائدة الرئيسية لعدم الاضطرار إلى استخدام مكونات خارجية لمعالجة المحتوى الديناميكي أثناء التكوين والتنسيق. فمن الأسهل بكثير تنسيق المكونات الداخلية مع بعضها البعض فقط.

Nginx

إن أكبر اختلاف بين الطريقة التي يتعامل بها Apache و Nginx مع المحتوى هو أن Nginx ببساطة غير قادر على معالجة المحتوى الديناميكي داخليًا. يجب إقرانه بمكون خارجي لمعالجة طلبات المحتوى الديناميكي. هذا يعني أنك ستحتاج إلى استخدام خادم Nginx الخاص بك بالاشتراك مع معالج خارجي. سيتلقى المكون الطلب الخاص بـ PHP/المحتوى الديناميكي، ومعالجته، ثم إرساله مرة أخرى إلى الخادم.

بما أنه يجب نقل المعلومات بين المكونين، فستحتاج إلى تنسيق الاتصال بينهما. سيتعين عليك تحديد عدد الاتصالات التي تريد السماح بها وتكوين البروتوكول. سيتعين عليك استخدام البروتوكول الذي يمكن قراءته وفهمه بواسطة Nginx، مثل HTTP أو FastCGI أو SCGI أو uWSGI أو memcache من بين بروتوكولات أخرى.

من ناحية أخرى، يعمل Nginx بشكل جيد للغاية في التعامل مع المحتوى الثابت. وهو يحتاج بالفعل إلى مساعدة من أي مصادر خارجية للقيام بذلك. كما أنه لن يقوم بتنشيط المترجم إلا عند حاجته إليه. هذه إحدى فوائد استخدام Nginx. المترجم ليس مدمجًا في العملية. هذا يعني أنه سيكون موجودًا فقط لمعالجة المحتوى الديناميكي.

أدلة المحتوى: التكوين الموزع مقابل التكوين المركزي

لكل خادم ويب دليل محتوى خاص به. أحد أهم المعايير التي يتم على أساسها الحكم على Apache و Nginx هو ما إذا كانا يسمحان بالتكوين على مستوى الدليل أم لا.

Apache

هناك ملفات مخفية معينة في أدلة المحتوى تحتوي على توجيهات. هذه هي ملفات .htaccess. مع Apache، يمكنك تفسير هذه التوجيهات على أساس كل دليل على حدة. وبالتالي، عندما ترسل طلبًا، سيقوم Apache بفحص المسار المؤدي إلى الملف للعثور على ملف .htaccess. وعندما يفعل ذلك، سيقوم بتفسير وتطبيق التوجيهات الموجودة بداخله على الفور. لن يقوم Apache بإعادة تحميل الخادم لتنفيذ هذه التوجيهات.

تسمح العملية المحددة أعلاه بالتكوين اللامركزي للأدلة في خادم الويب. التكوين اللامركزي مفيد لإعادة كتابة عناوين URL، وتطبيق قيود الوصول، وتأكيد التفويضات، وتعيين سياسات التخزين المؤقت.

إحدى فوائد ملف .htaccess هي أن المستخدم، الذي ليس لديه مصادقة، يمكنه التحكم وتعديل جانب واحد على الأقل من المحتوى الذي يعرضه في متصفحه. لهذا السبب يتم استخدام Apache بشكل متكرر من قبل موفري الاستضافة المشتركة. يمتلك مقدمو الخدمة وصولاً مصرحًا به إلى التكوين المركزي. ويستطيع العملاء ممارسة التحكم في أدلة معينة دون الوصول إلى التكوين الرئيسي.

إذا أردت، فمن الممكن لك إيقاف تشغيل تفسير .htaccess في Apache.

Nginx

على عكس Apache، لا يعمل Nginx مع أي ملفات .htaccess. وهذا يجعله أقل مرونة نسبيًا. ومع ذلك، فإن Nginx يقدم عددًا من التحسينات في أسلوب التكوين الخاص به بدلاً من ذلك. بادئ ذي بدء، فهو قادر على معالجة الطلبات بمعدل أسرع بكثير من Apache. وذلك لأنه لا يبحث عن كل ملف .htaccess يجده في مساره ويقرأه ويفسره ثم ينفذه. وبدلاً من البحث في كل دليل رئيسي، يقوم Nginx بالبحث في دليل واحد فقط لطلب واحد.

بالإضافة إلى ذلك، يتمتع Nginx بميزة أمنية كبيرة مقارنة بـ Apache. لا يقوم Nginx بتسليم أي جزء من تكوين أدلة المحتوى إلى مستخدمين فرديين، على عكس Apache. بينما قد تحافظ أنت على إجراءات أمنية صارمة، فمن يضمن أن المستخدمين الفرديين قادرون على فعل الشيء نفسه؟ مع Nginx، تحتفظ بالتحكم في الحالة الأمنية وتكوين شبكة الأدلة بأكملها.

تفسير الطلب

طريقة أخرى للتمييز بين الخادمين هي الطريقة التي يفسران بها الطلبات.

Apache

عندما يتلقى الخادم طلبًا، فإنه يفسره ثم يربطه بموارد النظام ذات الصلة. يفسر الطلب إما كمورد مادي على نظام الملفات أو كـ URI موقع.

عند التفسير كمورد مادي، فإنه يستخدم كتل <Directory> أو <Files>  كتل. هذه هي طريقة التفسير الافتراضية للخادم. حيث يأخذ جذر المستند. ثم يتبع المضيف ورقم المنفذ في الطلب للعثور على الملف ذي الصلة في شجرة المستندات.

من ناحية أخرى، يحتاج موقع URI إلى تقييم مجرد. لذلك يستخدم Apache كتل <Location> للموارد المجردة بدلاً من العمل مع نظام الملفات.

هناك عدد من البدائل الأخرى لاستخدام النظام الافتراضي القائم على الملفات بصرف النظر عن URI. على سبيل المثال، يمكنك استخدام توجيه Alias للعثور على موقع بديل لربطه به. يمكنك أيضًا الاستفادة من متغيرات التعبير لجعل تكوين نظام الملفات أكثر مرونة.

Nginx

في حين أن Apache قد وُلد ليكون خادم ويب، فإن Nginx يؤدي دورًا مزدوجًا كخادم ويب وخادم وكيل أيضًا. ولهذا السبب، بدلاً من الميل نحو نظام الملفات، يفضل Nginx العمل مع معرفات URI. يمكنك تصور هذا التفضيل من حقيقة أنه لا توجد طريقة تتيح لك تحديد تكوين لدليل نظام الملفات في Nginx. ومع ذلك، يمكنه الترجمة إلى نظام الملفات إذا ومتى لزم الأمر.

تعد Server و location كتل التكوين الأساسية المستخدمة في Nginx. حيث يفسر الأول المضيف الذي يتم طلبه. بينما يطابق الآخر أجزاء URI بعد المضيف والمنفذ. ونتيجة لذلك، يفسر الخادم الطلب كموقع URI بدلاً من ملف فعلي على النظام.

بسبب نظام التفسير القائم على URI، فإن Nginx قادر على أداء دوره كخادم ويب، وخادم وكيل، وخادم بريد. وبما أنه لا يشير إلى نظام الملفات أثناء تفسير الطلب، فمن المفهوم سبب عدم تطبيقه لملفات .htaccess أيضًا.

أنظمة الوحدات

بينما يقدم كل من Apache و Nginx دعمًا لأنظمة الوحدات من أجل التوسعة، إلا أن هناك بعض الاختلافات الرئيسية في طريقة عملهما الداخلية.

Apache

مع Apache، يمكنك تحميل الوحدات وإلغاء تحميلها ديناميكيًا أثناء تشغيل الخادم. تظل النواة في مركز العمليات وتعمل الوحدات على توسيع الوظائف. يمكنك استخدام هذه الوحدات القابلة للإلحاق لإنجاز عدد من المهام. الخيارات لا حصر لها عمليًا مع مكتبة Apache الواسعة.

في الواقع، يمكنك حتى تعديل وظيفة نواة الخادم باستخدام وحدات مثل  mod_php. وكما ذكرنا سابقًا، تتيح لك هذه الوحدة دمج مفسر PHP في عمليات العمل الفردية. هذا مفيد عندما تحتاج إلى معالجة محتوى ديناميكي.

لكن القصة لا تنتهي عند هذا الحد. يمكنك أيضًا إضافة وحدات لتمكين وظائف مثل مصادقة العميل، وتحصين الخادم، والتخزين المؤقت، وإعادة كتابة عناوين URL، والوكلاء، وتحديد معدل الطلبات، والضغط، بالإضافة إلى التشفير.

Nginx

يختلف نظام الوحدات في Nginx من حيث أنه لا يمكنك تحميل الوحدات ديناميكيًا على الخادم الرئيسي. بدلاً من ذلك، يجب تجميعها وبناؤها مع البرنامج الأساسي. وهذا يترك الكثير مما هو مرغوب فيه من حيث المرونة وسهولة الاستخدام. في حين أن حزم التوزيع تحتوي على بعض الوحدات الشائعة، سيتعين عليك بناء الخادم للوحدات الأخرى. لذلك، تحتاج إلى معرفة كيفية صيانة برنامجك المترجم خارج نظام الحزم التقليدي.

بغض النظر عن ذلك، فإن ميزة نظام الوحدات غير القياسي هذا هي أنه يمنحك درجة عالية من التخصيص. يمكنك تخصيص وحداتك من خلال دمج الوظائف التي تحتاجها فقط. يتيح لك ذلك التخلي عن المكونات التي لا تحتاجها وتجنيب نفسك المخاطر الأمنية في هذه العملية. وفي الوقت نفسه، يمكنك إنجاز نفس المهام باستخدام وحدات Nginx كما تفعل مع Apache. وتشمل هذه المهام إعادة كتابة عناوين URL، وتسجيل الأحداث، والمصادقة، وما إلى ذلك.

النظام البيئي والدعم

تعد عمليات التكامل ودعم البرامج أمرًا مهمًا للغاية عندما يتعلق الأمر بخوادم الويب. بعد ذلك، سنستكشف التوافق والدعم المتاحين لكل من Apache و Nginx.

Apache

يعد Apache منصة أقدم وأكثر شعبية. وبالتالي، فمن المفهوم أنه يحتوي على مجموعة أكبر من الأدوات والبرامج الداعمة مقارنة بـ Nginx. هناك كم هائل من وثائق الطرف الثالث المتاحة تحت تصرفك لدعم الخادم الأساسي. ليس هذا فحسب، بل يمكنك أيضًا ربطه ببرامج أخرى لإنجاز مهام محددة. يمكنك إما إضافة هذه الأدوات إلى مشروعك أو حزمتك. وهي قادرة على التهيئة بسهولة داخل نظام Apache البيئي.

Nginx

بينما يتأخر Nginx عن Apache في هذا الصدد، فإنه بالتأكيد يبذل قصارى جهده للحاق بالركب. يتبنى المزيد والمزيد من الأفراد Nginx مع إدراكهم لإمكانياته الكاملة. ويستمر الدعم للمنصة في الارتفاع جنبًا إلى جنب مع نموها الطبيعي كخادم ويب مفيد وسريع المعالجة.

كانت إحدى عقبات الدعم الرئيسية التي تعين على Nginx تجاوزها هي العثور على وثائق باللغة الإنجليزية. ويرجع ذلك إلى أن غالبية Nginx كُتبت في الأصل باللغة الروسية، بما في ذلك معظم وثائقه. ومع ذلك، مع انتشار الخادم وزيادة شهرته، أصبحت الكثير من موارد الطرف الثالث متاحة الآن باللغة العالمية.

حل تعاوني؟

الآن، أصبح لديك فهم أفضل بكثير للمكونات الأساسية وآليات العمل الداخلية لـ Apache و Nginx. على الرغم من اختلافهما تمامًا عن بعضهما البعض، إلا أن بعض المستخدمين يستغلون هذه الحقيقة لتحقيق أقصى استفادة من كلا الخادمين. هذا صحيح’ - من الممكن لك استخدام Apache و Nginx معًا.

تقليديًا، يميل المستخدمون إلى استخدام Nginx كوكيل عكسي ووضعه أمام Apache. يتيح لك ذلك تعويض النقص في السرعة في معالجة طلبات Apache والتعامل معها. يستقبل Nginx جميع الطلبات ويتعامل معها بأقصى سرعة له. كما يتيح لك التعامل بسرعة مع عدد كبير من الطلبات المتزامنة دون الحاجة إلى استثمار الكثير من الموارد.

ميزة أخرى لـ Nginx يستغلها المستخدمون هي قدرته على التعامل مع المحتوى الثابت بكفاءة. لتعويض حقيقة أن Nginx يحتاج إلى مكون خارجي لمعالجة المحتوى الديناميكي، يمكننا توجيه PHP والطلبات الأخرى ذات الصلة إلى Apache من خلال وكيل. سيقوم Apache بتحويل الطلب إلى صفحة ويب وإرسالها مرة أخرى إلى Nginx حتى يتمكن من تقديمها للعميل.

إليك بعض الموارد التي يمكنك العثور عليها في مدونتنا والتي يمكن أن تساعدك في البدء مع كلا خادمي الويب:

Apache

• تثبيت خادم Apache على Ubuntu 18.04: دليل إرشادي
• إعداد مضيفين افتراضيين لـ Apache على Ubuntu 20.04
• كيفية تثبيت حزمة Linux و Apache و MySQL و PHP (LAMP) على CentOS 7
• تأمين Apache باستخدام Let’s Encrypt على Ubuntu 18.04

Nginx

• تثبيت Nginx على Ubuntu 18.04
• أتمتة تجديد شهادات SSL من LetsEncrypt لـ Nginx
• كيفية تأمين Nginx باستخدام Let’s Encrypt على Ubuntu 20.04
• كيفية تثبيت حزمة LEMP (Linux و Nginx و MySQL و PHP) على Ubuntu 20.04

الخاتمة

في نهاية المطاف، يمتلك كل من Apache و Nginx نقاط قوة ونقاط ضعف خاصة بهما. لا توجد قواعد صارمة أو توصيات بشأن الخادم الذي يجب عليك استخدامه لمشروعك. أنت الحكم الأفضل لما يناسب تطبيقك بناءً على متطلباتك الفريدة.

يتعين عليك تحديد الجوانب والميزات التي لا يمكنك التنازل عنها والاختيار بناءً على ذلك. إذا كان من الصعب اتخاذ القرار، يمكنك دائمًا اللجوء إلى استخدام كلا الخادمين معًا في حل مخصص.

حوسبة سعيدة!