خوادم الويب والوكلاء العكسيين
nginx vs Apache: أي خادم يقوم بتشغيل حمل العمل؟
nginx وApache هما المحركان اللذان يمكن بناء مكدس الاستضافة عليهما، وينتهي القتال في اللحظة التي تتم فيها تسمية عبء العمل. nginx عبارة عن آلة منخفضة البصمة تعتمد على الأحداث للمحتوى الثابت والبروكسي العكسي؛ Apache هو خادم تطبيقات غني بالوحدات والذي يتجاوز دليله ونظامه البيئي يحمل استضافة مشتركة. هذا هو جدول القرار الصادق وراء كلا المقالتين المخصصتين.
النقاط الرئيسية
- يحدد نموذج التزامن الحافة: تتعامل حلقة الأحداث غير المتزامنة في nginx مع آلاف الاتصالات المتزامنة مع عدد قليل من العمليات المنفذة، ولهذا السبب تهيمن على طبقات الوكيل الثابت والوكيل العكسي؛ يقوم حدث Apache MPM بإغلاق الكثير من هذه الفجوة ولكنه لا يزال يخصص المزيد لكل اتصال على نفس الجهاز.
- تتعارض فلسفة التكوين: يحمل Apache .htaccess وتجاوزات لكل دليل (ملاءمة تأسيس الاستضافة المشتركة)، في حين أن تكوين nginx ثابت لكل موقع ويتضمن ملفات ذات نظام إعادة التحميل؛ التأثير اليومي هو على شكل فريق، ومن يقوم بتحرير التكوينات، وأين.
- المكدس المختلط شرعي، وليس انسحابًا: nginx في المقدمة كفاصل TLS وخادم ثابت، وApache في الخلف للتطبيق، هو شكل تم اختباره في المعركة ويحافظ على أدوات htaccess أثناء الاستيلاء على أداء nginx edge؛ التكلفة هي طبقة أخرى لاستكشاف الأخطاء وإصلاحها ومراقبتها.
- حيث يفوز كل محرك بشكل مباشر: يفوز nginx بالوكالة ذات الاتصال الكثيف، والعمل المستمر على الحافة، واستنزاف العميل البطيء؛ يفوز Apache بقوة التكوين لكل دليل، وتوافق الوحدة القديمة، وملكية الاستضافة المشتركة من فئة mod_security/mod_php حيث لا يوجد نظام بيئي آخر ناضج.
- LiteSpeed هو الخيار الثالث الذي يصل إليه العديد من المضيفين (تغطيه مقالتنا المخصصة): توافق Apache المنسدل مع التزامن المستند إلى الحدث، المرخص لكل نواة، لذلك يوجد المسار الأوسط "استبدال Apache، الاحتفاظ بالتكوين" لاقتصاديات الاستضافة المشتركة.
- إجراء القرار الذي يتم تطبيقه عبر فئة خوادم الويب لدينا: قم بتسمية حجم العمل (nginx على الحافة؛ Apache خلف تطبيقات htaccess الثقيلة)، اجعل كلا الدورين واضحين عند الدمج، وقياس حركة المرور الخاصة بك (وليس معايير المجلة)، وتذكر أن هذا هو أحد القرارات التي يمكنك التكرار عليها نظرًا لأن كلا المحركين يتعايشان بسعادة.
ملاحظة ميدانية
العميل الذي علمنا عادة المكدس الهجين: nginx في مقدمة TLS والإحصائيات، وApache في الخلف يحمل اثني عشر عامًا من تقاليد htaccess، لم يجرؤ أحد على إعادة كتابتها. لم تكن الإجابة الصادقة هي "الترحيل إلى nginx"، بل كانت "اسم عبء العمل لكل طبقة". ما زالوا يمارسون هذا الشكل حتى اليوم، غير متحمسين ومزخرفين بوقت التشغيل.
أسئلة شائعة
هل نحتاج إلى اختيار واحد على الإطلاق؟
لا: الوكيل العكسي أمام خادم التطبيق هو الشكل الحديث العادي. القرار الحقيقي الوحيد هو أي محرك يذهب إلى أين؛ إن تشغيل كليهما هو ممارسة معتادة، وليس اعترافًا بالهزيمة.
ما هو الأسرع في WordPress؟
مع طبقات التخزين المؤقت الجيدة، تعمل جميع الطبقات الثلاثة (nginx وApache وLiteSpeed) على خدمة WordPress جيدًا؛ جاء ترتيب النهاية في اختباراتنا لضبط ذاكرة التخزين المؤقت بدلاً من المحرك. يعد اختيار المحرك أمرًا مهمًا عند مستويات الحافة والوكيل أكثر من وجوده خلف ذاكرة التخزين المؤقت.
ما هو الأسهل للتعلم؟
كلاهما قابل للتعلم خلال أسبوع للاستضافة الافتراضية الأساسية وTLS؛ يختلف الاحتكاك: وثائق Apache مألوفة أكثر للخبراء في الصناعة، وتكوين nginx أقصر ولكنه يكشف عن مقابض الوكيل في وقت سابق.
هل هناك اختلافات أمنية مهمة؟
كلاهما يحمل CVEs وكلاهما آمن خارج الصندوق في الإصدارات التي تمت صيانتها؛ سطح الخطر هو سطح التكوين وثقافة htaccess والوحدات القديمة لـ Apache والوحدات المجمعة التابعة لجهات خارجية بالإضافة إلى أخطاء ترتيب التكوين لـ nginx. سرعة التصحيح مهمة أكثر من العلامة التجارية للمحرك.
كيف تساعدك Kinetikatech في خوادم الويب والوكلاء العكسيين
هذا ما نقوم به كل يوم: البرامج التي تقبل الاتصالات وتقرر كيفية تدفق الطلبات: nginx وApache وLiteSpeed وCaddy وTraefik، بالإضافة إلى عادات التكوين التي تجعلها سريعة ومخزنة مؤقتًا ويصعب إزالتها. تغطي خدمة تحسين سرعة المواقع و إدارة الخوادم ذلك من البداية إلى النهاية: التقييم والتنفيذ والمراقبة على مدار الساعة والاستجابة للطوارئ خلال 30 دقيقة.