بروتوكول نقل النصوص HTTPHTTP Hypertext Transfer Protocol طريقة استخدام HTTP خارج متصفحات الويب، ومفهوم بروتوكول HTTP، ونشأة وتاريخ بروتوكول HTTP

تخيّل أنك في مطعم: أنت تطلب وجبة من القائمة، فيأخذ النادل طلبك إلى المطبخ ثم يعود إليك بالطبق جاهزاً. على شبكة الويب، يحدث الأمر نفسه في كل مرة تفتح فيها موقعاً؛ فالمتصفح على جهازك يطلب الصفحة، والسيرفر يردّ عليه بالمحتوى، واللغة المشتركة التي يتفاهمان بها تُسمى بروتوكول نقل النص التشعبي (Hypertext Transfer Protocol — HTTP‏).

لفهم معنى الاسم بسهولة، دعنا نفكك حروف الاختصار الأربعة (HTTP‏):

• النص المترابط والوسائط (HT — Hypertext‏): سُمّي قديماً بالنص المترابط لأن صفحات الويب (HTML‏) تحتوي على روابط قابلة للنقر (Links) تنقلك من صفحة لأخرى، ثم اتسع اليوم ليشمل نقل كل شيء على الويب: من صفحات وتنسيقات CSS وأكواد JavaScript إلى الصور والصوتيات والفيديو.
• النقل والتبادل (T — Transfer‏): أي عملية إرسال هذه الملفات والبيانات عبر الشبكة ذهاباً وإياباً بين جهازك وبين السيرفر.
• قواعد التخاطب المتفق عليها (P — Protocol‏): كلمة «بروتوكول» تعني ببساطة قواعد حوار موحدة يتفق عليها الجميع؛ وبفضلها يستطيع أي متصفح على هاتفك أو حاسوبك أن يتحدث مع أي سيرفر في العالم مهما اختلف نوع الجهاز.

شاهد في المثال العملي البسيط الآتي كيف يطلب المتصفح الصفحة الرئيسية من موقع closetag.com وكيف يردّ عليه السيرفر:

ولأن كل طلب في HTTP يطلب ملفاً واحداً محدداً، فعندما تفتح صفحة تحتوي على نص وصورتين وملف تنسيق، يجلب المتصفح ملف الصفحة أولاً ثم يرسل طلبات منفصلة وسريعة لجلب كل صورة وملف تنسيق ليعرض الصفحة كاملة أمامك كما يوضح الرسم الآتي:

• GET /tutorials HTTP/1.1
• Host: www.closetag.com
• HTTP/1.1 200 OK
• Content-Type: text/html; charset=utf-8

في عام 1989 داخل مختبر الأبحاث الأوروبي CERN في سويسرا، كان آلاف العلماء من دول مختلفة يواجهون مشكلة يومية: أبحاثهم محفوظة على أجهزة كمبيوتر مختلفة لا تفهم بعضها، فكان الاطلاع على بحث زميل في جهاز آخر أمراً بطيئاً ومعقداً. لحل هذه المشكلة، ابتكر عالم الحاسوب البريطاني تيم بيرنرز لي (Tim Berners-Lee) فكرة الويب، وصمم بين عامَي 1990 و1991 أول متصفح وأول سيرفر يتخاطبان بلغة بسيطة وموحدة هي بروتوكول HTTP.

لكي تعمل شبكة الويب العالمية (WWW‏)، جمع بيرنرز لي ثلاث ركائز أساسية تعمل معاً في كل نقرة رابط كما يوضح المثال العملي الآتي:

• عنوان الصفحة الموحد (URL‏): يحدد عنوان الصفحة ومكانها على الإنترنت.
• قواعد النقل والتخاطب (HTTP‏): تنقل طلبك للسيرفر وتعود بالصفحة إلى جهازك.
• لغة بناء الصفحة (HTML‏): تكتب محتوى الصفحة وتضع الروابط القابلة للنقر بداخلها.

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

• 1. URL (Address) : https://www.closetag.com/tutorials/http
• 2. HTTP (Transfer) : GET /tutorials/http HTTP/1.1 -> Returns 200 OK
• 3. HTML (Content) : <a href="/tutorials/url-encoding">Next Lesson</a>

تخيّل أنك تكتب رسالة ورقية لصديق في مدينة أخرى: أنت تركز فقط على كتابة نص الرسالة بلغة مفهومة، ولا تشغل بالك بقيادة شاحنة البريد أو معرفة الطرق السريعة؛ لأن شركة البريد تتكفل بتغليف الرسالة وكتابة عنوان المبنى وتوصيلها سليمة. في شبكات الكمبيوتر، يعمل الإنترنت بنفس نظام الطبقات الأربع (TCP/IP‏)، ويقع بروتوكول HTTP في الطبقة العليا (طبقة التطبيقات):

• 1. طبقة التطبيقات (Application Layer — HTTP‏): هي الطبقة التي تكتب صيغة رسالة الطلب والاستجابة بين المتصفح والسيرفر (وتجاورها بروتوكولات أخرى مثل FTP لنقل الملفات وDNS لدليل الأسماء).
• 2. طبقة النقل (Transport Layer — TCP / UDP‏): هي المسؤولة عن استلام رسالة HTTP وتوصيلها كاملةً ومرتبةً من برنامج المتصفح إلى برنامج السيرفر؛ وتعتمد غالباً على بروتوكول TCP الذي يضمن وصول كل جزء بالترتيب وإعادة إرسال أي جزء مفقود (أو فوق UDP السريع بعد إضافة طبقة موثوقية حديثة فوقه).
• 3. طبقة الشبكة (Network Layer — IP‏): تضع عنوان الجهاز المرسل وعنوان السيرفر المستقبِل (عناوين IP‏) وتوجّه الحزم عبر الشبكات حتى تصل للمدينة والمبنى الصحيح.
• 4. طبقة الوصلة والوسائط المادية (Link & Physical‏): تحوّل البيانات الرقمية إلى إشارات كهربائية أو ضوئية أو لاسلكية تسير فعلياً في الواي فاي (Wi-Fi‏) وكابلات الشبكة والألياف الضوئية.

يوضح المثال العملي الآتي كيف تتعاون الطبقات الأربع معاً في لحظة فتحك لصفحة على closetag.com:

بفضل هذا الفصل بين الطبقات، يعمل موقعك بنفس الطريقة تماماً سواء فتحه الزائر عبر Wi-Fi أو كابل سلكي أو باقة بيانات الهاتف، ويستطيع المطور ومختص الأمن السيبراني تحديد مكان أي عطل بدقة (هل المشكلة في انقطاع الإنترنت أم في رسالة HTTP نفسها؟) كما يبين المخطط الآتي:

• Layer 4 (Application) : HTTP -> "GET /tutorials HTTP/1.1" (Message meaning)
• Layer 3 (Transport) : TCP -> Port 443 reliable stream (No missing bytes)
• Layer 2 (Network) : IP -> Route packet to server IP 203.0.113.10
• Layer 1 (Link/Phys) : Wi-Fi -> Transmit signals over radio/fiber cable

العميل في بروتوكول HTTP (HTTP Client) هو أي برنامج يبدأ الحوار مع السيرفر؛ فهو الذي يرسل رسالة الطلب أولاً وينتظر استلام رسالة الاستجابة. والقاعدة الذهبية هنا أن العميل هو المبادر دائماً، فلا يرسل السيرفر صفحات أو ملفات لجهازك من تلقاء نفسه دون أن يطلبها العميل أولاً.

أشهر مثال يومي للعميل هو متصفح الويب (Web Browser) مثل Chrome وFirefox وSafari وEdge؛ فعندما تضغط على رابط، يقوم المتصفح بطلب ملف الصفحة الأساسي (HTML‏) ثم يطلب تلقائياً ملفات التنسيق والصور ليرسم الصفحة أمامك. لكن العميل لا يقتصر على المتصفحات فقط، بل يشمل ثلاثة أنواع أخرى نستخدمها يومياً:

• تطبيقات الهواتف الذكية: مثل تطبيق البنك أو تطبيقات التوصيل والتواصل الاجتماعي التي تطلب البيانات من السيرفر خلف الكواليس وتعرضها داخل واجهة التطبيق.
• أدوات المطورين وفحص الأمان: مثل أداة سطر الأوامر curl وبرامج اختبار الواجهات التي يستخدمها المبرمج ومختص الأمن السيبراني لإرسال طلبات مخصصة وفحص رد السيرفر.
• برامج التحديث والتنزيل الآلية: مثل أداة تحديث نظام التشغيل التي تتصل بالسيرفر لتحميل التحديثات.

قارن في المثال العملي الآتي كيف يطلب كلٌّ من متصفح الويب وأداة curl نفس الصفحة من السيرفر باختلاف اسم البرنامج العميل (User-Agent‏):

• GET /tutorials/http HTTP/1.1
• Host: www.closetag.com
• User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/130.0
• GET /tutorials/http HTTP/1.1
• Host: www.closetag.com
• User-Agent: curl/8.7.1

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

يتكون خادم الويب من شقين يعملان معاً: جهاز كمبيوتر قوي متصل بالشبكة على مدار الساعة، وبرنامج خادم ويب (مثل Nginx أو Apache‏) يفهم لغة HTTP. وعندما يصل طلب زائر إلى الخادم الأصلي لموقع مثل closetag.com، فإنه يرد عبر إحدى ثلاث حالات عملية:

• 1. إرسال ملف جاهز ثابت ‏: مثل صورة شعار الموقع أو ملف تنسيق CSS محفوظ مسبقاً على القرص فيرسله كما هو.
• 2. بناء صفحة متغيرة لحظياً ‏: مثل صفحة لوحة تحكم الطالب أو نتائج البحث؛ حيث يشغّل السيرفر كود الموقع ويقرأ بيانات الطالب من قاعدة البيانات ليصنع الصفحة في نفس اللحظة.
• 3. إرسال رسالة خطأ واضحة: إذا طلب الزائر صفحة غير موجودة (404 Not Found‏) أو صفحة خاصة لا يملك صلاحية دخولها.

يوضح المثال العملي الآتي كيف يتعامل الخادم الأصلي مع هذه الحالات الثلاث:

• Case 1 (Static File) : GET /logo.png -> 200 OK (Reads file from disk)
• Case 2 (Dynamic Content) : GET /my-progress -> 200 OK (Queries DB + builds HTML)
• Case 3 (Missing Page) : GET /unknown-page -> 404 Not Found (Structured error)

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

ينقسم الخادم الوسيط حسب مكانه والجهة التي يعمل لصالحها إلى نوعين أساسيين يوضحهما المخطط أدناه:

• 1. الوسيط الأمامي (Forward Proxy — في جهة العميل): يوضع داخل شبكة شركة أو جامعة أمام أجهزة الموظفين والطلاب قبل خروجهم للإنترنت؛ وذلك لفلترة المواقع الممنوعة، أو حفظ نسخ من الملفات المتكررة لتسريع الإنترنت الداخلي (وإذا فُعِّل تلقائياً في الشبكة دون ضبط يدوي في المتصفح يُسمى وسيطاً شفافاً — Transparent Proxy).
• 2. الوسيط العكسي (Reverse Proxy — في جهة الخادم): يقف كدرع حماية وبوابة استقبال أمام الخوادم الأصلية للموقع (مثل خدمات Cloudflare أو خادم Nginx الأمامي)؛ فيستقبل طلبات الزوار من الإنترنت، ويحمي الخوادم الأصلية خلفه ويخفي عناوينها الحقيقية، ويعمل كموزّع أحمال (Load Balancer) يوزع الزوار بانتظام على عدة سيرفرات خلفية حتى لا يتعطل الموقع.

وتتلخص أهم الفوائد الخمس للخوادم الوسيطة في تطوير الويب والأمن السيبراني في:

• التخزين المؤقت ‏: حفظ نسخة جاهزة من الصفحات والصور الشائعة للرد على الزوار فوراً دون إزعاج الخادم الأصلي.
• موازنة الأحمال ‏: توزيع آلاف الطلبات في الثانية بالتساوي على عدة خوادم خلفية.
• الفلترة والحماية الأمنية: فحص الطلبات وحجب الهجمات أو المواقع الضارة قبل وصولها للهدف.
• التحكم في الصلاحيات: التأكد من هوية المستخدم قبل السماح له بالعبور.
• تسجيل حركة المرور ‏: حفظ سجل بالطلبات لمراجعة الأداء واكتشاف الأنشطة المشبوهة.

• [Employee Browser] -> [Company Forward Proxy] -> (Internet) -> [Origin Server]
• [Visitor Browser] -> (Internet) -> [Reverse Proxy / Load Balancer] -> [Origin Server 1 or 2]

عنوان الموارد الموحد (URL — Uniform Resource Locator‏) هو الرابط الذي تكتبه في شريط المتصفح للوصول إلى أي صفحة أو صورة أو ملف على الويب. يشبه عنوان URL عنوان التوصيل البريدي الكامل؛ لأنه يخبر المتصفح أين يقع الملف؟ وبأي طريقة نصل إليه؟

يُقرأ الرابط دائماً من اليسار إلى اليمين، ويتكون من ستة أجزاء واضحة (بعضها أساسي وبعضها اختياري) تجتمع معاً في الرابط التطبيقي الموحد الآتي:

تبدأ قراءة الرابط بالمكونات الثلاثة المسؤولة عن تحديد بروتوكول الاتصال والوصول إلى خادم الويب وبوابته البرمجية:

• المخطط (Scheme) — بروتوكول التواصل: يظهر في مطلع روابط الويب لتحديد البروتوكول المستخدَم، مثل الاتصال القياسي غير المشفر عبر HTTP أو الاتصال المشفر الآمن عبر HTTPS. ويفهم المتصفح كذلك مخططات أخرى خارج الويب كفتح برنامج البريد الإلكتروني مباشرةً. ويُخبر المخطط المتصفح (العميل) بقواعد الاتصال (البروتوكول) اللازمة لجلب المورد، ولا يحدّد نوع ملفه؛ فقد يشير الرابط الآمن نفسه إلى صفحة ويب أو صورة أو ملف نصي.
• المضيف (Host) — عنوان خادم الويب: يحدّد الخادم الذي يستضيف المورد على الشبكة، وهو مكوّن إلزامي لا يصح أي رابط ويب كامل عبر HTTP أو HTTPS بدونه. ويُكتب غالباً على هيئة اسم نطاق (Domain Name) مقروء للبشر تترجمه خدمة نظام أسماء النطاقات DNS إلى عنوان رقمي، كما يمكن كتابته مباشرةً كعنوان IP صالح أو اسم المضيف المحلي (Localhost) المشير إلى جهاز المطور نفسه. وفي البنية القياسية للرابط، يشكّل اجتماع المضيف مع المنفذ الاختياري ما يُسمّى سلطة العنوان (Authority) المسؤولة عن استضافة موارد ذلك الخادم.
• المنفذ (Port) — البوابة الرقمية للخدمة: رقم اختياري يلي المضيف مباشرةً ويحدّد البوابة البرمجية التي يستمع عليها برنامج الخادم لاستقبال الاتصالات. ويُحذف غالباً في التصفح اليومي لاعتماد المتصفح تلقائياً على المنفذ الافتراضي القياسي للمخطط، كما سنفصّل في الموضوع التالي.

وتوضّح الأمثلة الآتية صيغة كتابة كلٍّ من المخطط والمضيف والمنفذ وسلطة العنوان عملياً:

وبعد الوصول إلى الخادم وبوابته، تتولّى المكونات الثلاثة التالية تحديد المورد المطلوب وتخصيص معطياته وتعيين الموضع المحلي داخل الصفحة:

• المسار (Path) — موقع المورد بالخادم: يحدّد موقع المورد المطلوب عبر مقاطع هرمية متدرجة تشبه المجلدات. وعند كتابة اسم الموقع وحده دون مسار، يعدّه البروتوكول مكافئاً للمسار الجذري (Root Path) الذي يمثّل الصفحة الرئيسية (جذر الموقع). وقديماً عكس المسار مجلداً وملفاً فيزيائياً على قرص الخادم، أمّا حديثاً فيمثّل غالباً مساراً منطقياً (Logical Route) يوجّهه برنامج الخادم ديناميكياً دون اشتراط مجلد فعلي بهذا الاسم.
• الاستعلام (Query) أو سلسلة الاستعلام (Query String) — معطيات تخصيص إضافية: جزء اختياري يلي المسار مباشرةً لإرسال معطيات إضافية للخادم للترشيح أو ترقيم الصفحات أو البحث. ويُكتب في الويب غالباً على هيئة أزواج مفتاح وقيمة مفصولة عند التعدد.
• الجزء المرجعي (Fragment) — موضع محلي داخل الصفحة: إشارة مرجعية اختيارية تأتي في نهاية الرابط لتشير إلى قسم فرعي أو عنوان محدد يحمل معرّفاً مطابقاً داخل الصفحة نفسها، فيقفز المتصفح بالعرض إليه محلياً دون تحميل صفحة جديدة.

ويوضّح المثال الآتي صيغة كتابة المسار وسلسلة الاستعلام والجزء المرجعي وعلامات الفصل الخاصة بها:

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

• Scheme : http:// | https:// | mailto: (delimiter ://)
• Host : www.closetag.com | 127.0.0.1 | localhost
• Port : :80 (preceded by colon : right after host)
• Authority : www.closetag.com:80 (Host + Optional Port)

• Path : /tutorials/http | / (Root Path when omitted)
• Query : ?page=1 | ?page=1&sort=latest (key=value pairs)
• Fragment : #overview (jumps locally to element id=overview)

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

وتُحجز الأرقام من 0 إلى 1023 عالمياً بوصفها المنافذ القياسية المعروفة (Well-Known Ports) المخصّصة للخدمات الأساسية. ومن أشهرها المنفذان 80 و443 للويب، والمنفذ 25 لبروتوكول نقل البريد البسيط SMTP (Simple Mail Transfer Protocol)، والمنفذ 53 لنظام أسماء النطاقات DNS. أمّا الأرقام خارج هذا النطاق المحجوز من 1024 إلى 65535 فلا تتطلب صلاحيات مدير النظام، وتشمل المنافذ الشائعة لتشغيل الخوادم البديلة وبيئات التطوير والتطبيقات المخصصة.

وفي عناوين الويب يرتبط كل مخطط بمنفذ قياسي ثابت؛ فعند كتابة رابط ويب غير مشفر عبر HTTP دون رقم منفذ يتوجه المتصفح تلقائياً إلى المنفذ الافتراضي (Default Port) رقم 80. وعند كتابة رابط ويب محمي بالتشفير عبر HTTPS دون رقم منفذ يتوجه المتصفح تلقائياً إلى المنفذ الافتراضي رقم 443 (والذي سندرس آلية حمايته لاحقاً). ولهذا السبب تختفي أرقام المنافذ القياسية من الروابط اليومية؛ إذ يستنتجها المتصفح مباشرةً من المخطط ويحذفها من شريط العنوان للتبسيط. وعليه يتكافأ الرابط المختصر تماماً مع الرابط الصريح في الحالتين كما يظهر في المثال الآتي:

أمّا حين يستمع خادم الويب على منفذ مخصص (Custom Port) غير افتراضي — مثل المنافذ الشائعة 8080 أو 8000 أو 3000 — فتصبح كتابة رقم المنفذ صراحةً بعد اسم المضيف في الرابط إلزامية. فالمتصفح يطرق باب المنفذ المحدّد في العنوان حصراً؛ فإذا شغّلت خادماً محلياً على المنفذ 8080 وأغفلت كتابته في الرابط، فسيطرق المتصفح المنفذ الافتراضي 80 بدلاً منه. وعندئذٍ يفشل الاتصال برسالة رفض الاتصال (Connection Refused) رغم أن خادمك المحلي يعمل بسلام على المنفذ 8080. وبالمثل، يؤدي الخلط بين منفذ الويب غير المشفر 80 ومنفذ الويب المشفر 443 إلى فشل التخاطب بين العميل والخادم، كما يوضّح المثال الآتي:

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

• http://www.closetag.com/tutorials/http -> Connects to port 80
• http://www.closetag.com:80/tutorials/http -> Equivalent: port 80
• https://www.closetag.com/tutorials/http -> Connects to port 443
• https://www.closetag.com:443/tutorials/http -> Equivalent: port 443

• http://localhost:8080/tutorials/http -> Mandatory :8080 port
• http://127.0.0.1:8080/tutorials/http -> Equivalent local IP
• http://localhost/tutorials/http -> Port 80 (Refused!)

يعمل بروتوكول HTTP وفق دورة الطلب والاستجابة (Request-Response Cycle) التي يقودها العميل دائماً. فلا يبادر خادم الويب بإرسال صفحات من تلقاء نفسه، بل ينتظر مستمعاً حتى يطلب المتصفح مورداً محدداً فيردّ عليه بالنتيجة خلال أجزاء من الثانية. وتبدأ الرحلة فور كتابة عنوان ويب في المتصفح أو النقر على رابط، مثل العنوان الكامل الآتي:

بمجرد إدخال هذا الرابط، يستخرج متصفح الويب (Web Browser) منه المخطط والمضيف والمنفذ والمسار لينفّذ خمس خطوات متسلسلة:

1. تحويل اسم النطاق إلى عنوان رقمي (DNS Lookup): توجّه الشبكات الحزم بالأرقام لا بالأسماء النصية، لذا يعمل نظام أسماء النطاقات DNS كدفتر عناوين للشبكة. يسأل متصفح الويب أولاً خادم النطاقات (DNS Server) — إن لم يكن العنوان محفوظاً مؤقتاً لديه — ليستلم منه عنوان IP الرقمي المقابل لاسم نطاق الموقع.
2. فتح قناة اتصال على المنفذ (TCP Connection): فور معرفة عنوان IP، يفتح المتصفح قناة اتصال موثوقة عبر بروتوكول النقل TCP مع خادم الويب (Web Server) على المنفذ المستنتج. ويكون هذا المنفذ 80 للروابط القياسية غير المشفرة عبر HTTP أو 443 للروابط المحمية عبر HTTPS مع تفعيل تشفير أمان طبقة النقل TLS (Transport Layer Security). وتُفتح هذه القناة الشبكية وجوباً قبل إرسال أي رسالة HTTP.
3. إرسال رسالة طلب المورد (HTTP Request): عبر قناة الاتصال المفتوحة، يرسل المتصفح رسالة طلب HTTP يحدّد فيها لخادم الويب الموردَ المطلوب والعملية المراد تنفيذها عليه. ويشمل هدف الطلب المسار ومعطيات الاستعلام إن وُجدت، بينما يبقى الجزء المرجعي المحلي داخل المتصفح لتحديد موضع التمرير في الصفحة دون إرساله عبر الشبكة.
4. إعادة رسالة الاستجابة بالمحتوى (HTTP Response): يستقبل خادم الويب الطلب على المنفذ المستمع، فيبحث عن الملف المطلوب أو يشغّل منطق التطبيق وقاعدة البيانات لتجهيز المحتوى. وإن كان المورد مفقوداً أو غير مسموح به يحدّد الخادم سبب التعذر، ثم يعيد رسالة استجابة HTTP للمتصفح بنتيجة المعالجة ونسخة المحتوى مثل وثيقة HTML أو رسالة الخطأ.
5. عرض الصفحة وطلب ملفاتها الفرعية (Render & Sub-Resources): يقرأ المتصفح وثيقة HTML المستلمة ويحلّلها لبناء هيكل الصفحة. وكلما صادف إشارةً لملف أو مورد فرعي خارجي — كملف تنسيق CSS أو ملف JavaScript (JS‏) أو صورة أو خط — أطلق تلقائياً طلبات إضافية مستقلة عبر HTTP لجلبه. وبعد استلام هذه الموارد الفرعية يدمجها المتصفح معاً ليرسم الصفحة كاملةً أمام المستخدم.

ويوضّح التتبّع التقني الآتي مسار الرابط السابق وعنوانه الرقمي عبر الخطوات الخمس بالترتيب:

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

• 1. DNS Lookup : closetag.com -> 203.0.113.10 (DNS -> IP)
• 2. TCP Connection : 203.0.113.10:443 -> TLS channel (:80 HTTP)
• 3. HTTP Request : /tutorials/http -> (#overview stays local)
• 4. HTTP Response : HTML document -> Sent to Web Browser
• 5. Sub-Resources : /app.css, /app.js -> Separate HTTP requests

لماذا نجح بروتوكول HTTP في البقاء لأكثر من ثلاثين عاماً كعمود فقري للويب دون أن نضطر لاستبداله؟ السر يكمن في ثلاث ميزات عملية بُني عليها منذ اليوم الأول:

• 1. البساطة وسهولة القراءة للبشر (Simplicity & Human Readability): صُممت رسائل HTTP بكلمات إنجليزية واضحة ومباشرة (مثل GET للجلب و200 OK للنجاح) بدلاً من الشفرات المعقدة؛ مما يجعل قراءتها وفحصها وتشخيص أخطائها أمراً سهلاً للمبتدئ والمحترف.
• 2. نقل أي نوع من الملفات والبيانات ‏: رغم أن اسمه التاريخي «نقل النص التشعبي»، إلا أن HTTP لا يقتصر على النصوص؛ بل يعمل كشاحنة نقل ذكية تستطيع حمل أي ملف رقمي (صفحة HTML، صورة، فيديو، ملف PDF، أو بيانات JSON‏) بمجرد كتابة نوع الملف في رأس الرسالة (Content-Type‏).
• 3. القابلية للتوسع دون كسر التوافق ‏: يستطيع المطورون والشركات إضافة قدرات جديدة للبروتوكول (مثل ضغط الملفات، أو قواعد التخزين المؤقت، أو شروط الأمان) عن طريق إضافة أسطر رؤوس جديدة في الرسالة، مع بقاء المتصفحات والسيرفرات القديمة والحديثة قادرة على التفاهم معاً.

يوضح المثال العملي الآتي كيف ينقل بروتوكول HTTP نفسه ثلاثة أنواع مختلفة تماماً من المحتوى بمجرد تحديد النوع في سطر Content-Type:

• Response 1 (Web Page) : HTTP/1.1 200 OK | Content-Type: text/html; charset=utf-8
• Response 2 (API Data) : HTTP/1.1 200 OK | Content-Type: application/json
• Response 3 (PNG Image) : HTTP/1.1 200 OK | Content-Type: image/png

يُوصَف بروتوكول HTTP في جوهره بأنه بروتوكول عديم الحالة (Stateless Protocol)؛ ومعنى ذلك ببساطة أن السيرفر يعامل كل طلب يصله كأنه أول مرة يراك فيها! يشبه الأمر ماكينة البيع الذاتي أو موظف استعلامات لا يحتفظ بأي ذاكرة للمراجعين؛ فلو سألته سؤالاً وأجابك، ثم سألته بعد ثانية: «وماذا عن السعر؟» دون أن تعيد ذكر اسم المنتج، فلن يتذكرك؛ لأن كل طلب في HTTP يجب أن يكون مكتفياً بذاته (Self-Contained) ويحمل كل المعلومات اللازمة لتنفيذه.

لماذا صُمم HTTP بدون ذاكرة تلقائية؟ هذا ليس عيباً، بل ميزة هندسية كبرى؛ لأن السيرفر لا يضطر لحجز ذاكرة لملايين الزوار في نفس الوقت، مما يجعله سريعاً جداً وقادراً على خدمة ملايين المستخدمين بكفاءة (Scalability‏).

شاهد في المثال العملي الآتي كيف ينسى السيرفر الأساسي هوية المستخدم في الطلب الثاني ما لم يرسل المتصفح بطاقة تعريفه (مثل الكوكيز Cookie التي سندرسها في درسها المخصص) مع كل طلب جديد:

• Request 1 : POST /login (user=ahmed) -> Server replies 200 OK
• Request 2 : GET /my-cart -> Server: "Who are you? (No memory of Req 1)"
• Request 2 : GET /my-cart + Cookie: session_id=xyz987 -> Server returns Ahmed's cart!

تخيّل أنك تريد سؤال صديقك عن ثلاثة أشياء في الهاتف: هل تتصل به وتسأل السؤال الأول ثم تغلق الخط، وتعيد الاتصال للسؤال الثاني وتغلق الخط، ثم تتصل ثالثة؟ أم تفتح المكالمة مرة واحدة وتسأل الأسئلة الثلاثة ثم تغلق الخط عند الانتهاء؟ في HTTP، فتح قناة الاتصال (TCP‏) يستهلك وقتاً؛ ولذلك مرّت إدارة الاتصال بين المتصفح والسيرفر بطريقتين:

• 1. الاتصالات المؤقتة (Short-Lived Connections — قديماً): يفتح المتصفح قناة اتصال TCP جديدة لطلب ملف واحد فقط (مثل صفحة HTML‏)، وبمجرد استلام الرد يغلق القناة فوراً! ثم يضطر لفتح قناة ثانية لملف التنسيق CSS، وقناة ثالثة للصورة؛ مما يبطئ تحميل الموقع.
• 2. الاتصالات المستمرة (Persistent Connections — الافتراضي اليوم): يفتح المتصفح قناة اتصال TCP مرة واحدة فقط، ويستخدم نفس القناة المفتوحة لإرسال طلب الصفحة وطلب التنسيق وطلب الصورة واحداً تلو الآخر بسرعة فائقة، ثم يغلق القناة بعد انتهاء التحميل أو بعد فترة خمول قصيرة.

قارن في المثال العملي والمخطط البصري الآتيين بين عدد المرات التي يُفتح فيها اتصال الشبكة لجلب صفحة واحدة بمواردها الثلاثة في الطريقتين:

• [Open TCP #1 -> GET /page.html -> Close] + [Open TCP #2 -> GET /app.css -> Close] + [Open TCP #3 -> GET /logo.png -> Close]
• [Open TCP #1 -> GET /page.html -> GET /app.css -> GET /logo.png -> Close after idle timeout]

عندما نسمع كلمة HTTP يخطر ببالنا متصفح كروم أو سفاري فوراً، لكن الحقيقة أن متصفحات الويب لا تمثل سوى جزء واحد من استخدامات هذا البروتوكول! فأي برنامج أو جهاز ذكي يتصل بالإنترنت لتبادل البيانات يستخدم نفس قواعد HTTP في ثلاث بيئات يومية حولك:

• 1. تطبيقات الهواتف الذكية وسطح المكتب: عندما تفتح تطبيق البنك، أو تطلب سيارة أو وجبة، أو تتصفح تطبيقات التواصل على هاتفك، يرسل التطبيق طلبات HTTP للسيرفر في الخلفية دون أن ترى شريط عنوان.
• 2. تواصل السيرفرات مع بعضها عبر واجهات البرمجة (Web APIs‏): عندما تشتري منتجاً من متجر إلكتروني وتدفع بالبطاقة البنكية، يقوم سيرفر المتجر بإرسال طلب HTTP مباشر إلى سيرفر البنك وسيرفر شركة الشحن لإتمام العملية في أجزاء من الثانية.
• 3. الأجهزة الذكية والأنظمة الآلية (IoT‏): مثل التلفزيون الذكي والساعة الذكية وعناكب محركات البحث (Googlebot‏) وأدوات الفحص الأمني.

والفرق العملي الأهم هو شكل المحتوى في الرد: فالمتصفح يطلب صفحة HTML مرئية ليقرأها الإنسان، بينما تطلب تطبيقات الهاتف والـ API بيانات منظمة وخفيفة بصيغة JSON يقرؤها البرنامج بسرعة كما في المقارنة العملية الآتية:

• GET /courses/http HTTP/1.1 -> <h1>HTTP Course</h1><p>Price: $0 (Free)</p>
• GET /api/courses/http HTTP/1.1 -> {"course": "HTTP", "price": 0, "free": true}