خادم الويب

في مارس 1989، اقترح السير تيم بيرنرز لي مشروعًا جديدًا على جهة عمله، سيرن ، بهدف تسهيل تبادل المعلومات بين العلماء باستخدام نظام النص التشعبي . حمل الاقتراح عنوان "النص التشعبي وسيرن" ، وطلب تقديم التعليقات عليه، وقرأه عدد من الأشخاص. في أكتوبر 1990، أُعيدت صياغة الاقتراح وإثراؤه (بمشاركة روبرت كايليو كمؤلف مشارك )، وأُقرّ أخيرًا. ^{[ 8 ] [ 9 ] [ 10 ]}

بين أواخر عام 1990 وأوائل عام 1991، أسفر المشروع عن قيام بيرنرز لي ومطوريه بكتابة واختبار العديد من مكتبات البرامج إلى جانب ثلاثة برامج، والتي تم تشغيلها في البداية على نظام التشغيل NeXTSTEP المثبت على محطات عمل NeXT : ^{[ 11 ] [ 12 ] [ 10 ]}

• متصفح ويب رسومي ، يسمى WorldWideWeb ؛
• متصفح ويب محمول يعمل بنظام الخط ؛
• خادم ويب، عُرف لاحقًا باسم CERN httpd .

كانت تلك المتصفحات المبكرة تسترجع صفحات الويب المكتوبة بصيغة بسيطة مبكرة من لغة HTML من خوادم الويب باستخدام بروتوكول اتصال أساسي جديد يسمى HTTP 0.9 .

في أغسطس 1991، أعلن تيم بيرنرز لي عن ولادة تقنية شبكة الويب العالمية (WWW) وشجع العلماء على تبنيها وتطويرها. ^{[ 13 ]} بعد ذلك بوقت قصير، أُتيحت هذه البرامج، إلى جانب شفرتها المصدرية ، للأشخاص المهتمين باستخدامها. ^{[ 11 ]} على الرغم من أن الشفرة المصدرية لم تُرخص رسميًا أو تُنشر للعموم، إلا أن سيرن سمحت بشكل غير رسمي للمستخدمين والمطورين بالتجربة والتطوير عليها. بدأ بيرنرز لي بالترويج لتبني هذه البرامج واستخدامها، بالإضافة إلى نقلها إلى أنظمة تشغيل أخرى . ^{[ 10 ]}

في ديسمبر 1991، تم تركيب أول خادم ويب خارج أوروبا في مركز SLAC (الولايات المتحدة الأمريكية). ^{[ 12 ]} كان هذا حدثًا بالغ الأهمية لأنه دشّن الاتصالات عبر القارات بين متصفحات الويب وخوادم الويب.

في الفترة من 1991 إلى 1993، استمر تطوير برنامج خادم الويب الخاص بـ CERN بنشاط من قبل مجموعة www، وفي الوقت نفسه، وبفضل توفر شفرة المصدر الخاصة به والمواصفات العامة لبروتوكول HTTP، بدأ تطوير العديد من تطبيقات خوادم الويب الأخرى.

في أبريل 1993، أصدر مركز سيرن بيانًا رسميًا عامًا يفيد بأن المكونات الثلاثة لبرمجيات الويب (عميل وضع السطر الأساسي، وخادم الويب، ومكتبة التعليمات البرمجية المشتركة)، بالإضافة إلى شفرتها المصدرية ، أصبحت متاحة للعموم . ^{[ 14 ]} وقد أعفى هذا البيان مطوري خوادم الويب من أي مشكلة قانونية محتملة تتعلق بتطوير أعمال مشتقة بناءً على تلك الشفرة المصدرية (وهو تهديد لم يكن موجودًا في الواقع).

في مطلع عام ١٩٩٤، كان أبرز خوادم الويب الجديدة خادم NCSA httpd ، الذي كان يعمل على أنظمة تشغيل متعددة مبنية على يونكس، وكان قادرًا على عرض محتوى مُولّد ديناميكيًا باستخدام POSTبروتوكول HTTP وتقنية CGI للتواصل مع البرامج الخارجية. وقد أبرزت هذه الإمكانيات، إلى جانب ميزات الوسائط المتعددة لمتصفح Mosaic الخاص بـ NCSA (القادر أيضًا على إدارة نماذج HTML لإرسال البيانات إلى خادم الويب)، إمكانات تقنية الويب في مجال النشر وتطبيقات الحوسبة الموزعة .

في النصف الثاني من عام ١٩٩٤، توقف تطوير خادم NCSA httpd لدرجة دفعت مجموعة من مطوري البرامج الخارجيين، ومديري المواقع الإلكترونية، وغيرهم من المتخصصين المهتمين بهذا الخادم، إلى كتابة وجمع التصحيحات بفضل توفر شفرة المصدر لخادم NCSA httpd للعموم. في بداية عام ١٩٩٥، طُبقت جميع هذه التصحيحات على آخر إصدار من شفرة مصدر NCSA، وبعد عدة اختبارات، انطلق مشروع خادم Apache HTTP . ^{[ ١٧ ] [ ١٨ ]}

في نهاية عام 1994، تم إطلاق خادم ويب تجاري جديد، يُدعى Netsite ، بميزات محددة. وكان هذا الخادم الأول من بين العديد من المنتجات المماثلة التي طورتها شركة Netscape أولاً ، ثم شركة Sun Microsystems ، وأخيراً شركة Oracle .

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

في النصف الثاني من عام 1995، بدأت خوادم الويب الخاصة بـ CERN و NCSA في الانخفاض (في النسبة المئوية العالمية للاستخدام) بسبب التبني الواسع النطاق لخوادم الويب الجديدة التي كانت تتمتع بدورة تطوير أسرع بكثير إلى جانب المزيد من الميزات والمزيد من الإصلاحات المطبقة والمزيد من الأداء مقارنة بالخوادم السابقة.

في نهاية عام 1996، كان هناك بالفعل أكثر من خمسين برنامجًا معروفًا ومختلفًا لخوادم الويب، متاحة لكل من يرغب في امتلاك اسم نطاق على الإنترنت أو استضافة مواقع ويب. ^{[ 20 ]} لم يدم الكثير منها طويلًا، وسرعان ما استُبدلت بخوادم ويب أخرى.

أجبر نشر وثائق RFC الخاصة بإصداري بروتوكول HTTP/1.0 (1996) وHTTP/1.1 (1997، 1999) معظم خوادم الويب على الامتثال (ليس دائمًا بشكل كامل) لهذه المعايير. وقد استلزم استخدام اتصالات TCP/IP المستمرة (HTTP/1.1) من خوادم الويب زيادة الحد الأقصى لعدد الاتصالات المتزامنة المسموح بها، وتحسين مستوى قابليتها للتوسع.

بين عامي 1996 و 1999، برزت Netscape Enterprise Server و IIS من Microsoft من بين الخيارات التجارية الرائدة، بينما احتل Apache HTTP Server الصدارة كخادم مفضل من بين البرامج المجانية والمفتوحة المصدر (بسبب موثوقيته وميزاته العديدة).

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

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

في الفترة ما بين عامي 2005 و2006، بدأ أباتشي بتحسين سرعته وقابليته للتوسع من خلال تقديم ميزات أداء جديدة (مثل إدارة موارد الأحداث المتعددة وذاكرة التخزين المؤقت للمحتوى). ^{[ 21 ] [ 22 ]} ولأن هذه التحسينات الجديدة في الأداء كانت في البداية تجريبية، لم يفعّلها المستخدمون لفترة طويلة، ولذلك عانى أباتشي أكثر من منافسة الخوادم التجارية، وخاصةً خوادم المصادر المفتوحة الأخرى التي كانت قد حققت أداءً متفوقًا بكثير (خاصةً عند تقديم المحتوى الثابت) منذ بداية تطويرها، وكانت قادرةً في وقت تراجع أباتشي على تقديم قائمة طويلة من الميزات المتقدمة التي تم اختبارها جيدًا.

بعد بضع سنوات من بداية عام 2000، لم تظهر فقط خوادم الويب التجارية الأخرى والمنافسة للغاية (مثل LiteSpeed ) ولكن أيضًا العديد من البرامج مفتوحة المصدر الأخرى مثل Hiawatha و Cherokee HTTP server و Lighttpd و Nginx وغيرها من المنتجات المشتقة والمتعلقة بها والمتاحة أيضًا بدعم تجاري.

في الفترة ما بين عامي 2007 و2008، رفعت معظم متصفحات الويب الشائعة الحد الافتراضي السابق للاتصالات الدائمة لكل نطاق مضيف (وهو حد موصى به في RFC-2616) ^{[ 23 ]} إلى 4 أو 6 أو 8 اتصالات دائمة لكل نطاق مضيف، وذلك لتسريع استرجاع صفحات الويب ذات المحتوى الكبير من الصور، وللتخفيف من مشكلة نقص الاتصالات الدائمة المخصصة للكائنات الديناميكية المستخدمة في الإشعارات ثنائية الاتجاه للأحداث في صفحات الويب. ^{[ 24 ]} وفي غضون عام، أدت هذه التغييرات، في المتوسط، إلى زيادة عدد الاتصالات الدائمة التي يتعين على خوادم الويب إدارتها إلى ثلاثة أضعاف تقريبًا. وقد أعطى هذا التوجه (زيادة عدد الاتصالات الدائمة) دفعة قوية لاعتماد الخوادم الوكيلة العكسية أمام خوادم الويب الأبطأ، كما منح فرصة إضافية لخوادم الويب الجديدة الناشئة التي أظهرت سرعتها وقدرتها على التعامل مع أعداد كبيرة جدًا من الاتصالات المتزامنة دون الحاجة إلى موارد أجهزة ضخمة (أجهزة كمبيوتر باهظة الثمن مزودة بمعالجات مركزية وذاكرة وصول عشوائي وأقراص تخزين سريعة). ^{[ 25 ]}

في عام 2015، نشرت وثائق RFC الإصدار الجديد من البروتوكول [HTTP/2]، ونظرًا لأن تطبيق المواصفات الجديدة لم يكن بالأمر الهين، فقد نشأ معضلة بين مطوري خوادم الويب الأقل شيوعًا (على سبيل المثال، بنسبة استخدام أقل من 1% إلى 2%)، حول إضافة دعم لهذا الإصدار الجديد من البروتوكول من عدمه. ^{[ 26 ] [ 27 ]}

في الواقع، غالبًا ما تطلب دعم HTTP/2 تغييرات جذرية في تنفيذه الداخلي نظرًا للعديد من العوامل (الحاجة الدائمة تقريبًا إلى اتصالات مشفرة، والقدرة على التمييز بين اتصالات HTTP/1.x وHTTP/2 على نفس منفذ TCP، والتمثيل الثنائي لرسائل HTTP، وأولوية الرسائل، وضغط رؤوس HTTP، واستخدام التدفقات المعروفة أيضًا باسم اتصالات TCP/IP الفرعية والتحكم في التدفق ذي الصلة، وما إلى ذلك)، ولذلك اختار عدد قليل من مطوري خوادم الويب هذه عدم دعم إصدار HTTP/2 الجديد (على الأقل في المستقبل القريب) أيضًا لهذه الأسباب الرئيسية: ^{[ 26 ] [ 27 ]}

• كان من الممكن أن تدعم المتصفحات بروتوكولات HTTP/1.x لفترة طويلة جدًا (ربما إلى الأبد) بحيث لا يكون هناك عدم توافق بين العملاء والخوادم في المستقبل القريب؛
• كان يُنظر إلى تطبيق بروتوكول HTTP/2 على أنه مهمة بالغة التعقيد يمكن أن تفتح الباب أمام فئة جديدة تمامًا من الأخطاء التي لم تكن موجودة حتى عام 2015، وبالتالي كان سيتطلب الأمر استثمارات كبيرة في تطوير واختبار تنفيذ البروتوكول الجديد؛
• يمكن دائمًا إضافة دعم HTTP/2 في المستقبل إذا كانت الجهود مبررة.

بدلاً من ذلك، سارع مطورو معظم خوادم الويب الشائعة إلى توفير البروتوكول الجديد ، ليس فقط لتوافر القوى العاملة والوقت لديهم، بل أيضاً لأن تطبيقهم السابق لبروتوكول SPDY كان قابلاً لإعادة الاستخدام كنقطة انطلاق، ولأن معظم متصفحات الويب الشائعة طبقته بسرعة كبيرة لنفس السبب. ومن الأسباب الأخرى التي دفعت هؤلاء المطورين إلى التحرك بسرعة، شعور مديري المواقع الإلكترونية بضغط حركة المرور المتزايدة باستمرار ، ورغبتهم الشديدة في تثبيت وتجربة أي شيء - في أسرع وقت ممكن - من شأنه أن يقلل بشكل كبير من عدد اتصالات TCP/IP ويسرع الوصول إلى المواقع المستضافة. ^{[ 28 ]}

في الفترة 2020-2021، تم تكرار ديناميكيات HTTP/2 المتعلقة بتنفيذها (من قبل أفضل خوادم الويب ومتصفحات الويب الشائعة) جزئيًا بعد نشر مسودات متقدمة من RFC المستقبلية حول بروتوكول HTTP/3 .

على الرغم من اختلاف برامج خادم الويب في طريقة تنفيذها، إلا أن معظمها يقدم الميزات المشتركة التالية.

هذه ميزات أساسية تتوافر عادةً في معظم خوادم الويب.

• تقديم المحتوى الثابت : القدرة على تقديم المحتوى الثابت (ملفات الويب) للعملاء عبر بروتوكول HTTP.
• HTTP : دعم إصدار واحد أو أكثر من بروتوكول HTTP من أجل إرسال إصدارات من استجابات HTTP متوافقة مع إصدارات طلبات HTTP الخاصة بالعميل (على سبيل المثال، HTTP/1.0، HTTP/1.1، HTTP/2 ، HTTP/3 ).
• التسجيل : عادة ما تمتلك خوادم الويب أيضًا القدرة على تسجيل بعض المعلومات، حول طلبات العميل واستجابات الخادم، لملفات السجل لأغراض أمنية وإحصائية.

بعض الميزات الأخرى الأكثر تقدماً وشعبية ( وهي مجرد مجموعة صغيرة جداً ) هي كالتالي.

• تقديم المحتوى الديناميكي : القدرة على تقديم محتوى ديناميكي (يتم إنشاؤه أثناء التشغيل) للعملاء عبر بروتوكول HTTP.
• الاستضافة الافتراضية : القدرة على خدمة العديد من مواقع الويب ( أسماء النطاقات ) باستخدام عنوان IP واحد فقط .
• التفويض : القدرة على السماح أو منع أو السماح بالوصول إلى أجزاء من مسارات مواقع الويب (موارد الويب).
• ذاكرة التخزين المؤقت للمحتوى : القدرة على تخزين المحتوى مؤقتًا من أجل تسريع استجابات الخادم؛
• دعم الملفات الكبيرة : القدرة على عرض الملفات التي يزيد حجمها عن 2 جيجابايت على نظام التشغيل 32 بت .
• تقييد عرض النطاق الترددي : للحد من سرعة استجابات المحتوى من أجل عدم تشبع الشبكة والقدرة على خدمة المزيد من العملاء؛
• محرك إعادة الكتابة : لربط أجزاء من عناوين URL النظيفة (الموجودة في طلبات العميل) بأسمائها الحقيقية.
• صفحات الخطأ المخصصة : دعم رسائل خطأ HTTP المخصصة.

يقوم برنامج خادم الويب، عند تشغيله، عادةً بتنفيذ عدة مهام عامة : ^{[ 1 ]}

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

برامج خادم الويب قادرة على: ^{[ 29 ] [ 30 ] [ 31 ]}

• لقراءة رسالة طلب HTTP؛
• لتفسيره؛
• للتحقق من صحة تركيبها النحوي؛
• لتحديد رؤوس HTTP المعروفة واستخراج قيمها منها.

بعد فك تشفير رسالة طلب HTTP والتحقق منها، يمكن استخدام قيمها لتحديد ما إذا كان بالإمكان تلبية هذا الطلب أم لا. ويتطلب ذلك العديد من الخطوات الأخرى، بما في ذلك عمليات التحقق الأمني .

http://www.example.com/path/file.html

GET /path/file.html HTTP/1.1 Host: www.example.com Connection: keep-alive

/home/www/www.example.com/path/file.html

http://www.example.com/directory1/directory2/

GET /directory1/directory2 HTTP/1.1 Host: www.example.com Connection: keep-alive

/home/www/www.example.com/directory1/directory2/

http://www.example.com/cgi-bin/forum.php?action=view&orderby=thread&date=2021-10-15

طلب GET إلى /cgi-bin/forum.php?action=view&ordeby=thread&date=2021-10-15 HTTP/1.1 Host: www.example.com Connection: keep-alive

/home/www/www.example.com/cgi-bin/forum.php

بمجرد قراءة الطلب وتفسيره والتحقق منه، يجب إدارته بناءً على طريقته وعنوان URL الخاص به ومعلماته، والتي قد تتضمن قيم رؤوس HTTP.

من الناحية العملية، يتعين على خادم الويب معالجة الطلب باستخدام أحد مسارات الاستجابة التالية: ^{[ 33 ]}

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

عرض محتوى ثابت

إذا كان برنامج خادم الويب قادرًا على تقديم محتوى ثابت وتمت تهيئته للقيام بذلك، فإنه يستطيع إرسال محتوى الملف عندما تحتوي رسالة الطلب على مسار URL صالح يطابق (بعد تعيين عنوان URL وترجمته وإعادة توجيهه) مسار ملف موجود ضمن الدليل الجذر لموقع الويب، ويكون للملف سمات تتطابق مع تلك المطلوبة وفقًا للقواعد الداخلية لبرنامج خادم الويب. ^{[ 33 ]}

يُطلق على هذا النوع من المحتوى اسم المحتوى الثابت لأنه عادةً لا يتم تغييره بواسطة خادم الويب عند إرساله إلى العملاء ولأنه يظل كما هو حتى يتم تعديله (تعديل الملف) بواسطة برنامج ما.

ملاحظة: عند تقديم محتوى ثابت فقط ، لا يقوم برنامج خادم الويب عادةً بتغيير محتويات ملفات مواقع الويب التي يتم تقديمها (لأنها تُقرأ فقط ولا تُكتب أبدًا)، وبالتالي يكفي دعم طرق HTTP التالية فقط :

• OPTIONS
• HEAD
• GET

يمكن تسريع استجابة محتوى الملفات الثابتة عن طريق ذاكرة التخزين المؤقت للملفات .

ملفات فهرس الدليل

إذا تلقى برنامج خادم الويب رسالة طلب من العميل تحتوي على عنوان URL يتطابق مساره مع أحد مسارات دليل موجود ، وكان هذا الدليل قابلاً للوصول إليه، وتم تمكين خدمة ملفات فهرس الدليل، فقد يحاول برنامج خادم الويب خدمة أول اسم ملف فهرس ثابت معروف (أو مُكوَّن) ( ملف عادي ) موجود في ذلك الدليل؛ إذا لم يتم العثور على ملف فهرس أو لم يتم استيفاء الشروط الأخرى، فسيتم إرجاع رسالة خطأ.

أكثر الأسماء استخدامًا لملفات الفهرس الثابتة هي: index.html، index.htmو Default.htm.

الملفات العادية

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

عادةً، ولأسباب أمنية، تُهيأ معظم برامج خوادم الويب مسبقًا لخدمة الملفات العادية فقط أو لتجنب استخدام أنواع الملفات الخاصة مثل ملفات الأجهزة ، بالإضافة إلى الروابط الرمزية أو الروابط الصلبة إليها. والهدف من ذلك هو تجنب الآثار الجانبية غير المرغوب فيها عند خدمة موارد الويب الثابتة. ^{[ 35 ]}

عرض محتوى ديناميكي

إذا كان برنامج خادم الويب قادرًا على عرض محتوى ديناميكي ، وتمت تهيئته لذلك، فإنه يستطيع التواصل مع الوحدة الداخلية المناسبة أو البرنامج الخارجي (المرتبط بمسار عنوان URL المطلوب) لتمرير معلمات طلب العميل إليه. بعد ذلك، يقرأ برنامج خادم الويب استجابة البيانات (التي أنشأها، غالبًا بشكل فوري) ثم يعيد إرسالها إلى برنامج العميل الذي أرسل الطلب. ^{[ 36 ]}

ملاحظة: عند تقديم محتوى ثابت وديناميكي ، يجب أن يدعم برنامج خادم الويب عادةً طريقة HTTP التالية أيضًا لكي يتمكن من استقبال البيانات من العملاء بأمان، وبالتالي لكي يتمكن من استضافة مواقع الويب التي تحتوي على نماذج تفاعلية قد ترسل مجموعات بيانات كبيرة (مثل إدخال الكثير من البيانات أو تحميل الملفات ) إلى خادم الويب أو البرامج أو الوحدات الخارجية:

• POST

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

الواجهات الثلاث القياسية والتاريخية للبوابات هي كالتالي.

الصور المولدة بالحاسوب

يتم تشغيل برنامج CGI خارجي بواسطة برنامج خادم الويب لكل طلب ديناميكي، ثم يقرأ برنامج خادم الويب استجابة البيانات التي تم إنشاؤها ثم يعيد إرسالها إلى العميل.

SCGI

يتم تشغيل برنامج SCGI خارجي (عادة ما يكون عملية) مرة واحدة بواسطة برنامج خادم الويب أو بواسطة برنامج أو عملية أخرى، ثم ينتظر اتصالات الشبكة؛ في كل مرة يكون هناك طلب جديد له، يقوم برنامج خادم الويب بإنشاء اتصال شبكة جديد به من أجل إرسال معلمات الطلب وقراءة استجابة البيانات الخاصة به، ثم يتم إغلاق اتصال الشبكة.

فاست سي جي آي

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

قوائم الدليل

قد يكون برنامج خادم الويب قادراً على إدارة الإنشاء الديناميكي (أثناء التشغيل) لقائمة فهرس الدليل للملفات والأدلة الفرعية. ^{[ 37 ]}

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

Some web server programs allow the customization of directory listings by allowing the usage of a web page template—an HTML document containing placeholders, (e.g., $(FILE_NAME), $(FILE_SIZE), etc.) that are replaced with the field values of each file entry found in directory by web server (e.g., index.tpl) or the usage of HTML and embedded source code that is interpreted and executed (e.g.,, index.asp) or by supporting the usage of dynamic index programs such as CGIs, SCGIs, FCGIs (e.g., index.cgi, index.php, index.fcgi).

Usage of dynamically generated directory listings is usually avoided or limited to a few selected directories of a website because that generation takes much more OS resources than sending a static index page.

The main usage of directory listings is to allow the download of files (usually when their names, sizes, modification date-times or file attributes may change randomly and frequently) as they are, without requiring to provide further information to requesting user.^[38]

Program or module processing

An external program or an internal module (processing unit) can execute some sort of application function that may be used to get data from or to store data to one or more data repositories:

• files (file system);
• databases (DBs);
• other sources located in local computer or in other computers.

A processing unit can return any kind of web content, also by using data retrieved from a data repository:

• a document (e.g., HTML, XML, etc.);
• an image;
• a video;
• structured data (e.g., that may be used to update one or more values displayed by a dynamic page (DHTML) of a web interface and that maybe was requested by an XMLHttpRequestAPI) (see also: dynamic page).

In practice whenever there is content that may vary, depending on one or more parameters contained in client request or in configuration settings, then, usually, it is generated dynamically.

Web server programs are able to send response messages as replies to client request messages.^[29]

An error response message may be sent because a request message could not be successfully read or decoded or analyzed or executed.^[30]

NOTE: the following sections are reported only as examples to help to understand what a web server, more or less, does; these sections are by any means neither exhaustive nor complete.

بهدف تسريع استجابات خادم الويب عن طريق تقليل متوسط ​​أوقات استجابة HTTP والموارد المادية المستخدمة، تقوم العديد من خوادم الويب الشائعة بتطبيق ذاكرة تخزين مؤقتة واحدة أو أكثر للمحتوى ، كل منها متخصص في فئة محتوى معينة. ^{[ 44 ] [ 45 ]}

عادةً ما يتم تخزين المحتوى مؤقتًا حسب مصدره:

• المحتوى الثابت:
  • ذاكرة التخزين المؤقت للملفات ؛
• محتوى ديناميكي:
  • ذاكرة تخزين مؤقتة ديناميكية (مخرجات الوحدة أو البرنامج).

يمكن دمج برنامج خادم الويب في نظام التشغيل وتنفيذه في مساحة النواة ، أو يمكن تنفيذه في مساحة المستخدم (مثل التطبيقات العادية الأخرى).

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

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

في الوقت الحاضر، تُنفَّذ معظم برامج خوادم الويب في وضع المستخدم (لأن العديد من العيوب الطفيفة المذكورة آنفًا قد تم التغلب عليها بفضل الأجهزة الأسرع، وإصدارات أنظمة التشغيل الجديدة، وسرعة استدعاءات نظام التشغيل، وبرامج خوادم الويب المُحسَّنة). راجع أيضًا مقارنة برامج خوادم الويب لمعرفة أيها يعمل في وضع النواة أو في وضع المستخدم (يُشار إليه أيضًا بمساحة النواة أو مساحة المستخدم).

بالنسبة لبرامج خادم الويب، فإن مقاييس الأداء الرئيسية (التي يتم قياسها في ظل ظروف تشغيل مختلفة ) عادة ما تكون على الأقل ما يلي: ^{[ 54 ]}

• عددعدد الطلبات في الثانية (RPS، على غرارQPS، اعتمادًا على إصدار HTTP وتكوينه ونوع طلبات HTTP وظروف التشغيل الأخرى)؛
• عدد الاتصالات في الثانية ( CPS )، هو عدد الاتصالات في الثانية التي يقبلها خادم الويب (مفيد عند استخدام HTTP/1.0 أو HTTP/1.1 مع حد منخفض جدًا للطلبات أو الاستجابات لكل اتصال، أي 1 .. 20)؛
• زمن انتقال الشبكة + وقت الاستجابة لكل طلب عميل جديد؛ عادةً ما تُظهر أداة القياس عدد الطلبات التي تم تلبيتها ضمن نطاق زمني محدد (على سبيل المثال، في غضون 1 مللي ثانية، 3 مللي ثانية، 5 مللي ثانية، 10 مللي ثانية، 20 مللي ثانية، 30 مللي ثانية، 40 مللي ثانية) أو أقصر وقت استجابة، ومتوسط ​​وقت الاستجابة، وأطول وقت استجابة؛
• معدل نقل الاستجابات ، بالبايت في الثانية.

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

تصميم ونموذج برنامج خادم الويب المحدد المعتمد :

• عملية واحدة أو عمليات متعددة؛
• خيط واحد (بدون خيط) أو خيوط متعددة لكل عملية؛
• usage of coroutines or not;

... and other programming techniques, such as:

• minimization of possible CPU cache misses;
• minimization of possible CPU branch mispredictions in critical paths for speed;
• minimization of the number of system calls used to perform a certain function or task;
• other tricks;

... used to implement a web server program, can bias a lot the performances and in particular the scalability level that can be achieved under heavy load or when using high end hardware (many CPUs, disks and lots of RAM).

In practice some web server software models may require more OS resources (specially more CPUs and more RAM) than others to be able to work well and so to achieve target performances.

There are many operating conditions that can affect the performances of a web server; performance values may vary depending on:

• the settings of web server (including the fact that log file is or is not enabled, etc.);
• the HTTP version used by client requests;
• the average HTTP request type (method, length of HTTP headers and optional body);
• whether the requested content is static or dynamic;
• whether the content is cached or not cached (by server or client);
• whether the content is compressed on the fly (when transferred), pre-compressed (i.e., when a file resource is stored on disk already compressed so that web server can send that file directly to the network with the only indication that its content is compressed) or not compressed at all;
• whether the connections are or are not encrypted;
• the average network speed between web server and its clients;
• the number of active TCP connections;
• the number of active processes managed by web server (including external CGI, SCGI, FCGI programs);
• the hardware and software limitations or settings of the OS of the computers on which the web server runs;
• other minor conditions.

Performances of a web server are typically benchmarked by using one or more of the available automated load testing tools.

قد تتعرض خوادم الويب في أي وقت لحمل زائد بسبب واحد أو أكثر من الأسباب التالية:

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

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

• يتم تلبية الطلبات مع تأخيرات (قد تكون طويلة) (من ثانية واحدة إلى بضع مئات من الثواني).
• يقوم خادم الويب بإرجاع رمز خطأ HTTP ، مثل 500، 502، ^{[ 55 ] [ 56 ]} 503، ^{[ 57 ]} 504، ^{[ 58 ]} 408، أو حتى 404 متقطع .
• يرفض خادم الويب أو يعيد ضبط (يقاطع) اتصالات TCP قبل أن يعيد أي محتوى.
• في حالات نادرة جدًا، لا يُعيد خادم الويب سوى جزء من المحتوى المطلوب. يُمكن اعتبار هذا السلوك خللًا ، حتى وإن كان عادةً ما يظهر كعرض من أعراض التحميل الزائد.

للتغلب جزئياً على حدود التحميل التي تتجاوز المتوسط ​​ولمنع التحميل الزائد، تستخدم معظم المواقع الإلكترونية الشهيرة تقنيات شائعة مثل التقنيات التالية:

• ضبط معلمات نظام التشغيل وفقًا لإمكانيات الأجهزة واستخدامها.
• ضبط معلمات خوادم الويب لتحسين أمانها وأدائها.
• نشر تقنيات التخزين المؤقت للويب (ليس فقط للمحتويات الثابتة ولكن، كلما أمكن ذلك، للمحتويات الديناميكية أيضًا).
• إدارة حركة مرور الشبكة، باستخدام:
  • جدران الحماية لحظر حركة المرور غير المرغوب فيها القادمة من مصادر عناوين IP سيئة أو التي تحتوي على أنماط سيئة؛
  • مديرو حركة مرور HTTP لإسقاط أو إعادة توجيه أو إعادة كتابة الطلبات التي تحتوي على أنماط HTTP سيئة؛
  • إدارة عرض النطاق الترددي وتشكيل حركة المرور ، من أجل تخفيف ذروة استخدام الشبكة.
• باستخدام أسماء نطاقات وعناوين IP وأجهزة كمبيوتر مختلفة لتقديم أنواع مختلفة من المحتوى (الثابت والديناميكي)؛ الهدف هو فصل الملفات الكبيرة أو الضخمة download.*(يمكن استبدال هذا النطاق أيضًا بشبكة توصيل محتوى CDN ) عن الملفات الصغيرة والمتوسطة الحجم static.*وعن الموقع الديناميكي الرئيسي (ربما حيث يتم تخزين بعض المحتويات في قاعدة بيانات خلفية ) www.*؛ الفكرة هي القدرة على تقديم الملفات الكبيرة أو الضخمة (أكثر من 10-1000 ميجابايت) بكفاءة (ربما عن طريق تقييد التنزيلات) وتخزين الملفات الصغيرة والمتوسطة الحجم مؤقتًا بالكامل، دون التأثير على أداء الموقع الديناميكي تحت ضغط عالٍ، وذلك باستخدام إعدادات مختلفة لكل (مجموعة) من أجهزة خادم الويب:
  • https://download.example.com
  • https://static.example.com
  • https://www.example.com
• استخدام العديد من خوادم الويب (أجهزة الكمبيوتر) التي يتم تجميعها معًا خلف موازن التحميل بحيث تعمل أو تُرى كخادم ويب واحد كبير.
• إضافة المزيد من موارد الأجهزة (مثل ذاكرة الوصول العشوائي ، والأقراص الصلبة السريعة ) إلى كل جهاز كمبيوتر.
• استخدام برامج حاسوبية أكثر كفاءة لخوادم الويب (انظر أيضًا: كفاءة البرامج ).
• إن استخدام واجهة بوابة خادم الويب الأكثر كفاءة لمعالجة الطلبات الديناميكية (تشغيل برنامج خارجي واحد أو أكثر في كل مرة يتم فيها استرداد صفحة ديناميكية، يؤدي إلى انخفاض الأداء).
• استخدام تقنيات البرمجة الأخرى والحلول البديلة ، خاصة إذا كان المحتوى الديناميكي متضمنًا، لتسريع استجابات HTTP (أي عن طريق تجنب المكالمات الديناميكية لاسترداد الكائنات، مثل أوراق الأنماط والصور والبرامج النصية)، التي لا تتغير أبدًا أو تتغير نادرًا جدًا، عن طريق نسخ هذا المحتوى إلى ملفات ثابتة مرة واحدة ثم الحفاظ على مزامنتها مع المحتوى الديناميكي.
• يُستخدم أحدث إصدارات بروتوكول HTTP الفعّالة (على سبيل المثال، بالإضافة إلى HTTP/1.1 الشائع، يُمكن تفعيل HTTP/2 وربما HTTP/3 أيضًا، كلما توفرت برامج خوادم الويب التي تدعم البروتوكولين الأخيرين بشكل موثوق) لتقليل عدد اتصالات TCP/IP التي يبدأها كل عميل وحجم البيانات المتبادلة بشكل كبير (بفضل تمثيل رؤوس HTTP الأكثر إحكامًا وربما ضغط البيانات). قد لا يمنع هذا التحميل الزائد على ذاكرة الوصول العشوائي (RAM) ووحدة المعالجة المركزية (CPU) الناتج عن الحاجة إلى التشفير. كما قد لا يعالج التحميل الزائد الناتج عن الملفات الكبيرة جدًا التي يتم تحميلها بسرعة عالية، لأنها مُحسّنة للتزامن. ^{[ 59 ] [ 60 ]}