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

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

حوار الطلب والاستجابة

مبدأ العمل الأساسي بسيط: يرسل العميل طلبًا، ويعيد الخادم استجابة. يكون العميل عادةً متصفح ويب أو تطبيقًا للهاتف أو تطبيق سطح مكتب أو أداة API أو زاحفًا أو جهازًا مدمجًا. أما الخادم فهو النظام الذي يستضيف المورد أو الخدمة المطلوبة.

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

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

قبل انتقال أول بايت

قبل أن يصل طلب HTTP إلى الخادم، يجب أن يعرف العميل إلى أين يرسله. عندما يدخل المستخدم اسم نطاق، ينفذ المتصفح عادةً حل DNS أولًا. ويحوّل DNS اسم النطاق المقروء بشريًا إلى عنوان IP.

بعد ذلك ينشئ العميل اتصالًا شبكيًا مع الخادم. في HTTP التقليدي عبر TCP يعني ذلك فتح اتصال TCP. أما في HTTPS فيُجرى أيضًا تبادل TLS حتى يمكن تشفير الاتصال والمصادقة عليه.

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

تشريح طلب العميل

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

قد يطلب طلب بسيط صفحة رئيسية. وقد يرسل طلب أكثر تعقيدًا بيانات تسجيل دخول، أو يرفع ملفًا، أو يرسل بيانات JSON إلى API، أو يطلب موردًا مخزنًا مؤقتًا فقط إذا تغيّر.

تشمل طرق الطلب الشائعة GET وPOST وPUT وPATCH وDELETE وHEAD وOPTIONS. ولكل طريقة معنى مختلف، ويجب استخدامها وفقًا لغرض العملية.

تُستخدم GET عادةً لاسترجاع البيانات. وتُستخدم POST غالبًا لإرسال البيانات. وتُستخدم PUT وPATCH لتحديث الموارد. وتُستخدم DELETE لطلب الإزالة. وتطلب HEAD رؤوس الاستجابة دون الجسم الكامل. وتتحقق OPTIONS من خيارات الاتصال المدعومة.

كيف يفسر الخادم الرسالة

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

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

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

تُغلف النتيجة النهائية داخل استجابة HTTP.

بنية الاستجابة ومعناها

تحتوي استجابة HTTP عادةً على رمز حالة ورؤوس وجسم اختياري. يخبر رمز الحالة العميل بما إذا كان الطلب ناجحًا أو فاشلًا أو تمت إعادة توجيهه أو يحتاج إلى إجراء إضافي.

تصف الرؤوس الاستجابة. وقد تشمل نوع المحتوى وطول المحتوى وقواعد التخزين المؤقت وملفات تعريف الارتباط ومعلومات الخادم وطريقة الضغط وسياسة الأمان وموقع إعادة التوجيه.

يحمل الجسم المحتوى الفعلي المُعاد. وقد يكون HTML أو JSON أو XML أو بيانات صور أو مقاطع فيديو أو ملفات نصية أو أوراق أنماط أو برامج نصية أو تنزيلات ثنائية.

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

رموز الحالة مثل إشارات المرور

تساعد رموز الحالة العملاء على فهم النتيجة بسرعة. وهي مجمعة حسب الفئات.

تعني استجابة 200 عادةً أن الطلب نجح. وتعني استجابة 301 أو 302 أن العميل يجب أن ينتقل إلى موقع آخر. وتعني استجابة 404 أن المورد المطلوب غير موجود. وتعني استجابة 500 أن الخادم واجه مشكلة داخلية.

رموز الحالة ليست للمتصفحات فقط. فعملاء API وأنظمة المراقبة والزواحف والوكلاء وموازنات الحمل تستخدمها أيضًا لاتخاذ القرارات.

الرؤوس تحمل السياق

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

على سبيل المثال، يمكن لرأس Accept أن يخبر الخادم بأنواع المحتوى التي يفضلها العميل. ويخبر رأس Content-Type المستقبِل بالتنسيق المستخدم في الجسم. وقد يحمل رأس Authorization بيانات اعتماد أو رموزًا. ويحدد رأس Cache-Control سلوك التخزين المؤقت.

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

تصميم بلا حالة ومعالجة الجلسات

يوصف HTTP غالبًا بأنه بلا حالة. وهذا يعني أن كل طلب مستقل افتراضيًا. ولا يتذكر الخادم تلقائيًا الطلبات السابقة كجزء من نموذج البروتوكول الأساسي.

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

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

تعريف الموارد باستخدام عناوين URL

يخبر عنوان URL العميل بمكان وجود المورد وكيفية طلبه. ويتضمن عادةً مخططًا ومضيفًا ومسارًا وسلسلة استعلام، وأحيانًا منفذًا أو جزءًا.

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

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

ماذا يحدث عند تحميل صفحة ويب

قد يتضمن تحميل صفحة واحدة العديد من تبادلات HTTP. قد يسترجع الطلب الأول مستند HTML الرئيسي. وبعد قراءة ذلك المستند، يكتشف المتصفح موارد إضافية مثل ملفات CSS وJavaScript والصور والخطوط والأيقونات وبرامج التحليلات واستدعاءات API وملفات الوسائط.

قد يتطلب كل مورد طلبًا آخر. قد تأتي بعض الموارد من الخادم نفسه، بينما قد تأتي موارد أخرى من شبكات CDN أو خدمات طرف ثالث أو أنظمة إعلانات أو مزودي خرائط أو بوابات API.

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

التخزين المؤقت وتحسين الأداء

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

يُتحكم في سلوك التخزين المؤقت عبر رؤوس مثل Cache-Control وETag وLast-Modified وExpires. وتساعد هذه الرؤوس في تحديد ما إذا كان المورد يمكن إعادة استخدامه أو يجب إعادة التحقق منه أو يجب تنزيله مرة أخرى.

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

دور الوكلاء والبوابات وشبكات CDN

لا ينتقل مرور HTTP دائمًا مباشرة من المتصفح إلى خادم الأصل. فقد يمر عبر وكلاء عكسيين أو وكلاء أماميين أو بوابات API أو موازنات حمل أو جدران حماية أو عقد حافة CDN أو أنظمة فحص أمني.

قد يستقبل الوكيل العكسي الطلبات نيابة عن خوادم الخلفية. وقد يوزع موازن الحمل المرور على عدة خوادم تطبيقات. وقد تخزن CDN المحتوى بالقرب من المستخدمين. وقد تتحقق بوابة API من الرموز، وتحد من معدلات الطلب، وتحول الرؤوس، أو توجه المرور إلى الخدمات المصغرة.

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

HTTPS والاتصال الآمن

HTTPS هو HTTP محمول فوق تشفير TLS. وهو يحمي البيانات أثناء انتقالها عبر تشفير الاتصال بين العميل والخادم. كما يساعد في التحقق من هوية الخادم من خلال الشهادات الرقمية.

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

يعتمد الاتصال الآمن أيضًا على ضبط الشهادات بشكل صحيح، واستخدام إصدارات قوية من البروتوكول، وملفات تعريف ارتباط آمنة، وعمليات إعادة توجيه سليمة، وإعدادات خادم آمنة. HTTPS ضروري، لكنه يجب أن يُضبط بشكل صحيح.

تطور إصدارات البروتوكول

تطور HTTP لتحسين الأداء والكفاءة. استخدمت الإصدارات المبكرة معالجة طلبات أبسط. ثم أدخلت الإصدارات اللاحقة الاتصالات المستمرة وتعدد الإرسال وضغط الرؤوس ومفاهيم دفع الخادم وسلوك نقل محسّن.

حسّن HTTP/1.1 إعادة استخدام الاتصال وانتشر على نطاق واسع. وأدخل HTTP/2 تعدد الإرسال، مما يسمح لعدة طلبات واستجابات بمشاركة اتصال واحد بكفاءة أكبر. ويستخدم HTTP/3 بروتوكول QUIC فوق UDP لتحسين إنشاء الاتصال وتقليل بعض مشكلات التأخير في ظروف شبكية معينة.

يبقى مبدأ العمل هو اتصال الطلب والاستجابة، لكن آليات النقل والأداء أصبحت أكثر تقدمًا.

واجهات API والاتصال بين الآلات

لا يُستخدم HTTP في المتصفحات فقط. فهو أيضًا نمط البروتوكول السائد للعديد من واجهات API. فكثيرًا ما تتبادل تطبيقات الهاتف وتطبيقات الويب ومنصات IoT والخدمات السحابية وأنظمة الدفع وأدوات المراقبة وأنظمة المؤسسات بيانات JSON أو XML عبر HTTP.

في اتصال API، قد لا يكون جسم الاستجابة صفحة HTML. قد يكون بيانات منظمة ليعالجها برنامج آخر. وتصبح رموز الحالة والرؤوس ورموز المصادقة وطرق الطلب مهمة جدًا للتكامل المتوقع.

لذلك يجب على المطورين فهم نموذج العمل الأساسي والاتفاقيات العملية المستخدمة في تصميم API.

المشكلات الشائعة وأسبابها

قد يكون بطء الصفحة ناتجًا عن تأخير DNS أو ملفات كبيرة أو تخزين مؤقت ضعيف أو زيادة حمل الخادم أو تأخير قاعدة البيانات أو ازدحام الشبكة أو طلبات كثيرة جدًا أو برامج نصية غير فعالة.

قد يشير خطأ 404 إلى ملف مفقود أو URL خاطئ أو مسار محذوف أو قاعدة إعادة كتابة غير صحيحة أو رابط معطل. وقد يشير خطأ 500 إلى فشل كود الخادم أو مشكلة قاعدة بيانات أو مشكلة أذونات أو خدمة خلفية مضبوطة بشكل خاطئ.

قد تتضمن إخفاقات المصادقة رموزًا منتهية الصلاحية أو ملفات تعريف ارتباط مفقودة أو بيانات اعتماد خاطئة أو إعدادات أصل متقاطع محظورة أو معالجة غير صحيحة للرؤوس.

يساعد فهم مسار الطلب والاستجابة في تحديد مكان حدوث المشكلة.

طريقة عملية لاستكشاف الأخطاء

ابدأ بفحص URL وطريقة الطلب. ثم افحص رمز الحالة. بعد ذلك راجع رؤوس الطلب ورؤوس الاستجابة وملفات تعريف الارتباط وجسم الاستجابة. وتعد أدوات المطور في المتصفح مفيدة في هذه العملية.

بالنسبة إلى مشكلات الخادم، افحص سجلات الوصول وسجلات الأخطاء وسجلات التطبيق وسجلات الوكيل العكسي وحالة خدمات الخلفية. وفي الأنظمة الموزعة، يمكن أن تساعد معرّفات التتبع ومعرّفات الطلب في تتبع طلب واحد عبر عدة خدمات.

بالنسبة إلى مشكلات الأداء، افحص وقت DNS ووقت الاتصال ووقت TLS ووقت استجابة الخادم ووقت تنزيل المحتوى وسلوك التخزين المؤقت وحجم الموارد. تكشف هذه التفاصيل ما إذا كانت المشكلة مرتبطة بالشبكة أو بالخادم أو بالواجهة الأمامية.

لماذا يظل النموذج مهمًا

يظل مبدأ عمل HTTP مهمًا لأن كل خدمة رقمية حديثة تقريبًا تعتمد عليه. فالمواقع وواجهات API وتطبيقات الهاتف ولوحات التحكم السحابية ومنصات الإدارة وأنظمة الدفع وخدمات تسجيل الدخول وأنظمة المراقبة ومنصات IoT تستخدم الفكرة الأساسية نفسها: اطلب، عالج، استجب.

تأتي قوته من البساطة وقابلية التوسع وسهولة القراءة والتوافق الواسع. يستطيع حمل أنواع كثيرة من المحتوى ودعم أنواع كثيرة من التطبيقات مع الحفاظ على بنية اتصال متسقة.

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

الخلاصة

يعمل HTTP من خلال السماح للعميل بإرسال طلب منظم إلى الخادم وتلقي استجابة منظمة. وحول هذا النموذج البسيط، تضيف أنظمة الويب الحديثة DNS وTLS والتخزين المؤقت والوكلاء وشبكات CDN وواجهات API والمصادقة وتحسين الأداء وضوابط الأمان.

الأسئلة الشائعة

هل HTTP هو نفسه HTTPS؟

لا. يحدد HTTP نموذج تبادل الرسائل، بينما يضيف HTTPS تشفير TLS والتحقق من الهوية المعتمد على الشهادات لحماية الاتصال أثناء النقل.

لماذا تطلق صفحة ويب واحدة العديد من الطلبات؟

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

هل يمكن استخدام HTTP من دون متصفح؟

نعم. يمكن لتطبيقات الهاتف والخوادم وأدوات سطر الأوامر وأجهزة IoT وأنظمة المراقبة وواجهات API استخدام HTTP من دون متصفح ويب تقليدي.

لماذا تعيد بعض استدعاءات API بيانات بدلًا من صفحات ويب؟

غالبًا ما تعيد واجهات API بيانات منظمة مثل JSON أو XML. ويعالج البرنامج المستقبِل هذه البيانات بدلًا من عرضها كصفحة ويب.

ما الذي يجب فحصه أولًا عند فشل طلب HTTP؟

افحص URL وطريقة الطلب ورمز الحالة والرؤوس وحالة المصادقة واتصال الشبكة وسجلات الخادم، وما إذا كان أي وكيل أو بوابة يغيّر الطلب.