بدأ الإنترنت ، كما نعرفه اليوم ، “غزوه” العالمي في التسعينيات. يمكن تلخيص بروتوكول “الويب” بأكمله كزائر يطلب مستندًا من عنوان ويب معين ، مع نظام DNS ونظام IP لإعادة توجيه هذا الطلب إلى الكمبيوتر الصحيح. هذا الكمبيوتر ، الذي يستضيف صفحة الويب المطلوبة ، سوف “يخدم” صفحة الويب مرة أخرى للزائر.
صفحات الويب هي في الأساس مستندات HTML. لكي تتمكن من خدمة صفحات الويب المختلفة للزوار ، تحتاج آلة “الخدمة” إلى برنامج خادم. تقوم برامج مثل Nginx vs Apache بمعالجة الطلبات وتحليلها ثم تسليم المستندات المقابلة لعرضها في متصفح الزائر.
Nginx مقابل Apache
إن Nginx و Apache من خوادم الويب الشائعة المستخدمة لتقديم صفحات الويب إلى متصفح المستخدم. في حالتنا ، من موقع وورد بريس مستضاف. احصائيات سريعة:
تم إصدار Apache أولاً في عام 1995 ، ثم جاء Nginx في عام 2004.
يتم استخدام كلاهما من قبل شركات Fortune 500 الكبيرة في جميع أنحاء العالم.
نمت حصة Nginx في السوق بشكل مطرد لسنوات.
في بعض الحالات ، تتمتع Nginx بميزة تنافسية من حيث الأداء.
الدعم
سنغوص في Apache أولاً منذ إصداره أولاً.
بعد CERN httpd و NCSA HTTPd من Tim Berners-Lee في أول عامين من الإنترنت ، غزا Apache – الذي تم إصداره لأول مرة في عام 1995 – السوق بسرعة وأصبح خادم الويب الأكثر شعبية في العالم. في الوقت الحاضر ، لا تزال في وضع السوق هذا ولكن في الغالب لأسباب قديمة. يتم تطوير وصيانة أباتشي من قبل مؤسسة أباتشي ، بموجب ترخيص أباتشي .
هناك قصتان مختلفتان حول كيفية حصول Apache على اسمها. تقول إحدى النسخ أن الاسم نشأ من التراث الأمريكي الأصلي الشهير ، بينما تقول الأخرى أن الاسم عبارة عن تورية على “خادم غير مكتمل” ، والذي يتبع سلسلة من تصحيحات البرامج.
ترجع حصة Apache الضخمة في السوق جزئيًا إلى حقيقة أنها تأتي مثبتة مسبقًا مع جميع توزيعات Linux الرئيسية ، مثل Red Hat / Centos و Ubuntu.
صفحة أوبونتو الافتراضية
صفحة أوبونتو الافتراضية
أحد الأمثلة على الدور المهم لـ Apache في عالم Linux هو أن اسم عملية الخادم الخاص به هو HTTPd ، مما يجعل Apache مرادفًا لبرنامج خادم الويب.
إلى جانب كونه أول لاعب جاد في سوق خوادم الويب ، يرجع جزء من انتشار Apache إلى نظام التكوين وملف htaccess الخاص به .
يستخدم Apache .htaccess لتكوينه. هناك الكثير من البرامج التعليمية حول كيفية تكوين هذا الملف وتحريره والعمل به لأنه يوفر قدرًا كبيرًا من المرونة في تكوين كيفية معالجة Apache للطلبات الواردة. بعض الأمثلة هي: قواعد إعادة التوجيه المختلفة ، الحد الأقصى لأحجام ملفات التحميل ، إعادة كتابة عناوين URL ، حدود الذاكرة ، حماية الدليل (htpasswd) ، عناوين انتهاء الصلاحية ، رؤوس التحكم في ذاكرة التخزين المؤقت ، رؤوس التشفير ، ملفات تعريف الارتباط ، معالجة سلسلة الاستعلام.
من ناحية أخرى ، يستخدم Kinsta Nginx الذي لا يدعم ملفات .htaccess. ومع ذلك ، يمكن بسهولة “ترجمة” الإعدادات والقواعد من ملفات .htaccess إلى صيغة قواعد إعادة الكتابة الخاصة بـ Nginx.
أحد “الإيجابيات” الرئيسية في Apache هو أنه في جذر الخادم – دليل الموقع الرئيسي – يمكن أن يكون لكل مستوى أو دليل في شجرة الدليل ملف htaccess خاص به مع تكوينه الخاص.
بالنسبة لموفري الاستضافة المشتركة ، يعد هذا حلمًا لأنهم يستطيعون تزويد مئات المستخدمين على نفس الجهاز بطريقة لتهيئة كيفية تقديم مواقع الويب الخاصة بهم ، دون أن يؤثر ذلك على الآخرين. يمكن للعملاء تكوين الكثير من التفاصيل في بيئة استضافة مشتركة مقيدة ، مع عدم لمس تكوين الخادم العالمي.
كما تقول الوثائق الرسمية:
“بشكل عام ، يجب ألا تستخدم ملفات .htaccess إلا عندما لا يكون لديك حق الوصول إلى ملف تكوين الخادم الرئيسي.”
ومع ذلك ، تأتي هذه المرونة على حساب الأداء ” يؤدي السماح لملفات .htaccess إلى حدوث نتيجة أداء ، سواء كنت تستخدمها بالفعل أم لا!”
في كل مرة يتم فيها تمكين ملفات .htaccess ، يتعين على Apache اجتياز شجرة الدليل بالكامل من عنوان URL أو الملف المطلوب عبر جميع المستويات الأعلى حتى الدليل الجذر للخادم ثم تحميلها لكل طلب. يحتاج بعد ذلك إلى معالجة هذه الملفات وإعادة تكوين نفسه لكل دليل تم تكوينه بهذه الطريقة.
مع مواقع وورد بريس ، يمكن أن تصبح الأمور معقدة حقًا. يمكن أن يحتوي موقع وورد بريس النموذجي على مئات الطلبات من أدلة مختلفة.
من نوع / wp-content / uploads / yyyy / mm من dirs ، عادة ما يكون لها طلبات متعددة عند تحميل صفحة واحدة ، وغالبًا ما تشكل أدلة شهرية مختلفة. ثم سيكون هناك / wp-content / theme / parent-theme static resources ، / wp-content / theme / child-theme resources: هذه ستتضمن javascript ، ملفات css ، الصور.
ثم سيكون هناك أيضًا / wp-content / plugins بملفات ثابتة يتم تحميلها غالبًا من عشرات الدلائل الفرعية للمكونات الإضافية. لكل من هذه الموارد ، يتعين على Apache اجتياز شجرتها بالكامل للبحث عن التكوين.
أظهر أحد التحليلات أن إعداد وورد بريس النموذجي ، الشائع إلى حد ما لمواقع الويب على المضيفين المشتركين ، سيتضمن 42 عملية تنفيذ .htaccess منفصلة و 249 بحثًا منفصلاً عن ملف .htaccess.
هذا فقط على مستوى خادم الويب. لا يزال الزائر بحاجة إلى انتظار عملية PHP لتنفيذ مكدس مكالمات وورد بريس بالكامل لإنشاء استعلام قاعدة البيانات ومنحه إلى MySQL لتجميع صفحة الويب وإرسالها إلى الزائر.
الشيء الآخر الذي جعل Apache مشهورًا هو نظام الوحدة الديناميكي الخاص به .
الوحدات النمطية – كميزة تسمح للمستخدمين بتوسيع وظائف خادم الويب – موجودة في كل من Nginx و Apache. يسمح Apache للمستخدمين بتثبيت الوحدات بمجرد تثبيت خادم الويب بالفعل ونشره ثم تمكينه / تعطيله حسب الحاجة. تحتوي التوزيعات المبنية على دبيان على أوامر تسمح بتمكين هذه الوحدات وتعطيلها دون الحاجة إلى تعديل أي ملفات تكوين: a2enmod و a2dismod.
القائمة الرسمية من وحدات التي تأتي كجزء من توزيع القياسية أباتشي هي هنا وهذه تشمل اشياء من ضغط، والتشفير، وقطع الأشجار، إعادة توجيه إلى أشياء أكثر تقدما مثل تحرير الطلبات والردود مع تركيب المتقدم.
ظهرت Nginx (المكتوبة أيضًا باسم nginx أو NGINX) في عام 2004 ، عندما تم إصدارها لأول مرة من قبل المطور الروسي Igor Sysoev . كما أوين غاريت، مدير المشروع إنجن إكس ” وقال :
“تمت كتابة Nginx خصيصًا لمعالجة قيود أداء خوادم الويب Apache.”
تم إنشاء الخادم لأول مرة كأداة توسيع لموقع الويب rambler.ru في عام 2002. يأتي في نسختين: مفتوح المصدر ، مع ترخيص من نوع BSD ، و Nginx Plus ، مع دعم وميزات إضافية للمؤسسات.
بعد إصداره ، تم استخدام Nginx في الغالب لخدمة الملفات الثابتة وكموازن تحميل أو وكيل عكسي أمام تثبيتات Apache. مع تطور الويب ، والحاجة إلى الضغط على كل قطرة أخيرة من السرعة وكفاءة استخدام الأجهزة معها ، بدأت المزيد من مواقع الويب في استبدال Apache بـ Nginx تمامًا ، وذلك بفضل برنامج أكثر نضجًا.
استحوذت شركة NGINX Inc على F5 Networks
استحوذت شركة NGINX Inc على F5 Networks
في مارس 2019 ، استحوذت F5 Networks على Nginx Inc مقابل 670 مليون دولار . في تلك اللحظة ، وفقًا لتقرير Techcrunch ، كان خادم Nginx يدعم “375 مليون موقع ويب مع 1500 عميل يدفعون”.
وفقًا لبيانات w3techs ، نمت حصة Nginx في السوق بشكل مطرد ، مما دفع شركة Apache للخروج وإخراجها من المرتبة الأولى:
استخدام خادم الويب
استخدام خادم الويب
تتعلق هذه البيانات بخوادم الويب الإجمالية على مستوى العالم ، ولكن إذا أخذنا عينة من أفضل مليون موقع ويب ، فإن Nginx كان موجودًا منذ بعض الوقت الآن:
النسبة المئوية للمواقع التي تستخدم Nginx
النسبة المئوية للمواقع التي تستخدم Nginx
يبدو أن مؤشرات بحث Google تعكس هذه الحقيقة أيضًا:
اتجاهات بحث Google: Nginx مقابل Apache
اتجاهات بحث Google: Nginx مقابل Apache
يشير استطلاع Netcraft إلى أن Nginx قد تجاوز Apache في أبريل 2019.
تريد أن تعرف كيف زدنا من حركة المرور لدينا أكثر من 1000 ٪؟
انضم إلى أكثر من 20000 آخرين ممن يتلقون رسائلنا الإخبارية الأسبوعية مع نصائح من الداخل حول وورد بريس!
إشترك الآن
لا يحتوي Nginx على نظام تكوين مثل Apache ، لذلك ، على الرغم من كونه أكثر كفاءة وسرعة ، إلا أنه لا يعمل على نطاق واسع مع موفري خدمات استضافة التجزئة. لا يتألق في البيئات المشتركة كما يفعل Apache.
بنية استضافة Kinsta.
بنية استضافة Kinsta.
من ناحية أخرى ، كما قلنا ، من خلال عدم السماح بالتكوينات على مستوى الدليل ، يكتسب Nginx ميزة كبيرة على Apache. هناك مقال على Nginx wiki يقارن تأثير الأداء:
تأثير الأداء على Nginx vs Apache.png
تأثير الأداء على Nginx vs Apache.png
نظام وحدات Nginx هو شيء آخر يجعله خيارًا أكثر تميزًا. عادةً ما تحتاج وحدات Nginx إلى التمكين في وقت الإنشاء ، مما يعني أن هناك مزيدًا من البراعة التقنية ، كما أن إضافة الوحدات بعد التثبيت تكون أكثر تعقيدًا بعض الشيء.
في عام 2016 ، مع الإصدار 1.9.11 ، تغيرت الأمور وتم حجز مستودع الوحدات الديناميكية الرسمية / التي تم التحقق منها للمستخدمين الذين يدفعون. اعتبارًا من مايو 2019 ، أعلنوا عن بدء تطوير دعم QUIC و HTTP / 3 .
التخزين المؤقت – إذا أردنا المبالغة في تبسيطه – يمكن تصويره على أنه تحضير المحتوى لزوار موقع الويب قبل زيارتهم لذلك عندما “يطرقون الباب” ، لن تحتاج إلى البحث عن المحتوى الذي يبحثون عنه . لقد أعددتها بالفعل وقمت بتسليمها لهم دون أي انتظار.
مثل Apache ، كان إعداد Nginx النموذجي يتمثل في الجلوس بين الخوادم والمستخدم النهائي لتخفيف الأداء على بقية البنية التحتية. في هذه الحالات ، يمكنه تخزين المحتوى الثابت مؤقتًا دون الحاجة إلى جلبه من الخادم الأصلي المحمي في كل مرة.
إذا استخدمنا Nginx كخادم ويب مستقل – كما هو الحال مع حاويات Kinsta LXC – فلا داعي لذلك. إن Nginx فعال للغاية في تقديم المحتوى الثابت بمفرده.
ثم هناك مسألة التخزين المؤقت الديناميكي أو ذاكرة التخزين المؤقت للصفحة . في سيناريو موقع وورد بريس على الويب ، يعني هذا تخزين جميع صفحات وورد بريس التي تم إنشاؤها لكل عنوان URL في الذاكرة أو على القرص.
يتوفر التخزين المؤقت FastCGI أصلاً في تثبيت Nginx القياسي. إنها بسيطة وقوية للغاية وواحدة من ميزات Nginx الأقل استخدامًا.
لمقارنة هذا مع مكافئات Apache ، يجب أن تعلم أن Apache يحتوي على وحدة mod_cache والتي يقال إنها تميل إلى أن تكون معقدة وتتعارض مع الوحدات الأخرى. لذا فإن حل التخزين المؤقت القياسي الذي يتم نشره مع Apache هو مسرع Varnish HTTP. على الرغم من أن الورنيش هو الحل المخصص للصناعة ، إلا أن بعض الاختبارات الحديثة تمنح Nginx للتخزين المؤقت ميزة واضحة على الورنيش.
في Kinsta ، نستخدم Nginx للتخزين المؤقت الديناميكي في وورد بريس ، جنبًا إلى جنب مع مكون إضافي خاص بالتخزين المؤقت يسمح بالتحكم الدقيق في الصفحات المخزنة مؤقتًا ، والأصول الثابتة المخزنة مؤقتًا بواسطة Kinsta CDN.
هل تعبت من بطء استضافة وورد بريس؟ نستخدم التخزين المؤقت للصفحة الكاملة على مستوى الخادم لتقديم المحتوى للزائرين على الفور تقريبًا. تحقق من خطط الاستضافة لدينا
يتمثل الاختلاف الأكبر بين Apache و Nginx في البنية الأساسية للطريقة التي يتعاملون بها مع الطلبات.
تعالج Apache الطلبات باستخدام MPM-s أو Multi-Processing-Modules ، وهي “مسؤولة عن الارتباط بمنافذ الشبكة على الجهاز ، وقبول الطلبات ، وإرسال الأطفال للتعامل مع الطلبات.”
أقدم MPM ، والتي يعود تاريخها إلى بدايات Apache ، هي وحدة Prefork . يمكن أن تُنسب هذه الوحدة وحدها إلى السمعة السيئة لأداء Apache. في ظل هذا الوضع ، يولد Apache عملية جديدة بخيط واحد لكل طلب.
هذه الوحدة ، المستخدمة مع mod_php ، تعني أن خادم Apache قام بتضمين مترجم PHP في كل عملية مفردة ، حتى لو كان عليه أن يخدم ملفات أو صور CSS.
كان هذا غير فعال. تأتي وحدة Prefork مع Apache كوحدة افتراضية. كما أنه يقيد الاتصالات بـ HTTP / 1.
في السنوات اللاحقة ، طور Apache متعدد الخيوط mpm للعمال وبعد ذلك ، حدث mpm . كلاهما يخفف من العديد من مشكلات أداء Apache. إن التبديل إلى php-fpm يجعل من الممكن أن يظل Apache حلاً منافسًا اليوم ، إلى جانب التخلص من استخدام .htaccess ، لكن هذا النوع من هزيمة الغرض منه.
يستخدم Nginx بنية غير متزامنة وقائمة على الأحداث.
لشرح الاختلاف: في عالم Linux / Unix ، العمليات هي برامج تعمل.
الخيوط هي مجموعة فرعية من العمليات ويمكن أن يكون هناك عدة خيوط في تنفيذ عملية واحدة. فكر في هذا على أنه عدة علامات تبويب في نافذة المتصفح. بهذه الطريقة يمكن للبرنامج الاستفادة من وحدات المعالجة المركزية المتعددة ووحدات المعالجة المركزية متعددة النواة ومتعددة الخيوط للتنفيذ بشكل أسرع. يمكنك قراءة لينوس تورفالدس وهو يوضح الاختلافات .
باختصار ، يستخدم Apache عمليات لكل اتصال (ومع عامل mpm يستخدم الخيوط). مع زيادة حركة المرور ، سرعان ما تصبح باهظة الثمن.
يمكننا تصور عملية جديدة أو إنشاء خيط مثل تمهيد الكمبيوتر أو بدء تشغيل البرامج. حتى على أسرع أجهزة الكمبيوتر ، لا يزال الأمر يستغرق بعض الوقت. نظرًا لأن مواقع الويب اليوم تقدم مئات الطلبات عند تحميل صفحة واحدة ، فإن هذا يضيف بسرعة.
يذهب حدث mpm إلى أبعد من ذلك قليلاً من حيث التحسين ، لكن بعض الاختبارات تظهر أنه لا يمكن تجاوز Nginx. خاصة عندما نتحدث عن الملفات الثابتة ، حيث يعمل Nginx بقدر ضعف الطلبات التي يقوم بها Apache.
يحتوي Nginx بشكل مثالي على عملية عاملة واحدة لكل وحدة معالجة مركزية / مركز. يتمثل الاختلاف في عمليات العاملين في Nginx في أن كل واحدة يمكنها التعامل مع مئات الآلاف من اتصالات الشبكة الواردة لكل عامل . ليست هناك حاجة لإنشاء سلاسل رسائل أو عمليات جديدة لكل اتصال.
هذا هو السبب في أن شبكات توصيل المحتوى الرئيسية ، مثل Cloudflare و MaxCDN وشريكنا KeyCDN – أو مواقع الويب مثل Netflix – تجد Nginx أمرًا ضروريًا لتقديم المحتوى الخاص بهم.
قائمة الشركات التي تستفيد من Nginx طويلة جدًا لإدراجها جميعًا ، لذلك سننتهي بـ Automattic ، الشركة الخاصة وراء وورد بريس.com.
قام Automattic بتحويل جميع موازنات التحميل الخاصة بهم إلى Nginx لـ وورد بريس.com في عام 2008 (يمكنك القراءة عنها هنا ) وترحيل مكدس الخادم الخاص بهم بالكامل إلى Nginx .
إذا أردنا فحص ما يستخدمه موقع الويب في الإنتاج ، فيمكننا عادةً العثور عليه في رؤوس استجابة HTTP. هذا يعني أننا سنحتاج إلى النقر بزر الماوس الأيمن فوق موقع ويب> فحص ، في أدوات المطور ، سنختار لوحة الشبكة ، ثم نعيد تحميل موقع الويب. سنرى جميع الموارد التي يتم تحميلها على موقع الويب. إذا اخترنا أي مورد معين وعلامة تبويب الرؤوس الخاصة به ، فسنرى عادةً معلومات الخادم. إذا كان موقع الويب يستخدم CDN ، فقد نرى شيئًا مثل Cloudflare في سطر الخادم أو شيء مثل Varnish إذا كان موقع الويب يستخدم مسرع HTTP.
هذا مثال لموقع وورد بريس الذي يستخدم إعداد استضافة مشتركة نموذجي مع cPanel و Apache و PHP:
عنوان Apache http
رأس Apache HTTP
هذا موقع على Nginx:
رأس HTTP في Nginx
رأس Nginx HTTP
على الجانب الأيسر ، إذا قمنا بتوسيعه ، فسنكون قادرين أيضًا على تحليل وقت كل مورد ومعرفة تأثيره على إجمالي وقت تحميل الصفحة.
Nginx vs Apache: أيهما يوفر حلولاً أسرع لمواقع وورد بريس الخاصة بك؟ 🚀 تحقق من عرض خادم الويب الخاص بنا!
انقر للتغريد
في هذه المقالة ، ركزت على Nginx و Apache وشرحت الاختلافات المعمارية الرئيسية التي ساعدت Nginx على اكتساب المزيد من الجذب والاهتمام داخل ساحة خادم الويب. هذه هي السمات الرئيسية التي تمنحها ميزة الأداء في صناعتنا المتعطشة للموارد.
بالطبع ، ليست كل حالة استخدام لها نفس الأولويات وقد تكون Apache أو الأدوات الأخرى مثل Lighttpd و IIS و LiteSpeed و Caddy حلولًا جيدة.
في Kinsta ، نستخدم Nginx كجزء من حلول الاستضافة المحسّنة للأداء لكل من وورد بريس و WooCommerce. يوجد كل موقع وورد بريس في حاوية منعزلة خاصة به ، والتي تحتوي على جميع موارد البرامج المطلوبة لتشغيله (Nginx ، Linux ، PHP ، MySQL). الموارد خاصة بنسبة 100٪ ولا تتم مشاركتها بين أي مواقع أخرى.
وفر الوقت والتكاليف وحقق أقصى قدر من أداء الموقع من خلال:
مساعدة فورية من خبراء استضافة وورد بريس ، 24/7.
تكامل Cloudflare Enterprise.
يصل الجمهور العالمي إلى 28 مركز بيانات حول العالم.
التحسين من خلال مراقبة أداء التطبيقات المضمنة لدينا.
كل ذلك وأكثر من ذلك بكثير ، في خطة واحدة بدون عقود طويلة الأجل ، وعمليات الترحيل المدعومة ، وضمان استرداد الأموال لمدة 30 يومًا. تحقق من خططنا أو تحدث إلى قسم المبيعات للعثور على الخطة المناسبة لك.
