HTTP و HTTPS

HTTP و HTTPS

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

نموذج الطلب / الاستجابة

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

كل طلب HTTP يتكون من ثلاثة أجزاء:

1. سطر الطلب — الميثود والمسار وإصدار البروتوكول (مثل GET /api/users HTTP/1.1)
2. الترويسات (Headers) — أزواج مفتاح/قيمة للبيانات الوصفية (المضيف، نوع المحتوى، رمز المصادقة، تلميحات التخزين المؤقت، إلخ)
3. الجسم (Body) — الحمولة الاختيارية (موجودة في POST وPUT وPATCH؛ غائبة في GET وDELETE)

كل استجابة HTTP تعكس هذه البنية: سطر الحالة، والترويسات، والجسم الاختياري.

ميثودات HTTP — الدلالة مهمة

يُعرّف HTTP مجموعة صغيرة من الميثودات (الأفعال). استخدام الفعل الصحيح ليس مجرد اتفاقية — فهو يتحكم في التخزين المؤقت وسلوك الوكلاء والمتصفحات وضمانات idempotency التي تهم عند الحجم الكبير.

• GET — استرجاع مورد. آمن (بلا آثار جانبية) وidempotent (الطلبات المتكررة تُعيد نفس النتيجة). يمكن أن تُخزَّن الاستجابات مؤقتًا من قِبل المتصفحات وشبكات CDN والوكلاء العكسيين.
• POST — إرسال بيانات لإنشاء مورد أو تشغيل إجراء. ليس آمنًا ولا idempotent — الطلبات المكررة قد تُنشئ سجلات مكررة. لا يُخزَّن مؤقتًا افتراضيًا.
• PUT — استبدال مورد كاملًا. idempotent — استدعاؤه مرتين له نفس أثر استدعائه مرة. يُرسل العميل التمثيل الكامل.
• PATCH — تحديث جزئي لمورد. idempotent عمليًا. مفيد حين تكون الحمولة كبيرة ويتغير حقل أو حقلان فقط.
• DELETE — حذف مورد. idempotent — حذف شيء مرتين لا يجب أن يكون خطأً.
• HEAD — كـ GET لكن يُعيد الترويسات فقط بلا جسم. يُستخدم للتحقق من وجود مورد أو تغييره (ETags, Last-Modified) دون تحميل الجسم كاملًا.
• OPTIONS — يسأل الخادم عن الميثودات والترويسات التي يقبلها. تستخدم طلبات CORS preflight هذه الميثود تلقائيًا.

رموز الحالة — إجابة الخادم

رموز الحالة أرقام ثلاثية مُجمَّعة بالمئات. على كل مصمم أنظمة معرفة أهمها عن ظهر قلب، لأنها تُحدّد سلوك العملاء وموازنات التحميل وأنظمة المراقبة.

• 1xx — معلوماتي: 100 Continue (تابع إرسال الجسم)، 101 Switching Protocols (ترقية WebSocket).
• 2xx — نجاح:
  • 200 OK — نجاح عام مع جسم.
  • 201 Created — تم إنشاء المورد؛ يجب أن تشير ترويسة Location إليه.
  • 204 No Content — نجاح بلا جسم (شائع لـ DELETE).
• 3xx — إعادة توجيه:
  • 301 Moved Permanently — يُخزَّن إلى الأبد؛ يُستخدم لترحيل عناوين URL.
  • 302 Found — إعادة توجيه مؤقتة؛ العملاء يتحققون في كل مرة.
  • 304 Not Modified — المورد لم يتغير منذ النسخة المؤقتة لدى العميل؛ الجسم يُحذف كليًا لتوفير النطاق الترددي.
• 4xx — خطأ العميل:
  • 400 Bad Request — مدخلات مشوّهة.
  • 401 Unauthorized — غير مصادَق.
  • 403 Forbidden — مصادَق لكن غير مُخوَّل.
  • 404 Not Found — المورد غير موجود.
  • 409 Conflict — تعارض في الحالة (مثل إنشاء مكرر).
  • 429 Too Many Requests — تجاوز حد المعدل. ينبغي تضمين ترويسة Retry-After.
• 5xx — خطأ الخادم:
  • 500 Internal Server Error — استثناء عام غير معالج.
  • 502 Bad Gateway — عاد الـ upstream باستجابة غير صالحة (شائع حين تنهار حاوية خلفية).
  • 503 Service Unavailable — الخادم مثقل أو في صيانة؛ موازن التحميل يُخرجه من الدوران.
  • 504 Gateway Timeout — لم يرد الـ upstream في الوقت المحدد.

ترويسات مهمة لمصممي الأنظمة

تحمل الترويسات البيانات الوصفية التي تجعل HTTP أقوى من مجرد نقل بيانات بسيط. الأهم منها لتصميم الأنظمة:

• Content-Type / Accept — التفاوض على الصيغة (JSON، protobuf، XML). اضبطهما بشكل صحيح وإلا قد لا يستطيع الوكيل العكسي تحليل الجسم.
• Authorization — يحمل رموز bearer (JWTs) ومفاتيح API وبيانات Basic auth. لا تسجّل هذه الترويسة أبدًا.
• Cache-Control — توجيهات مثل max-age=3600 وno-store وpublic وprivate تتحكم في تخزين شبكات CDN والمتصفحات للاستجابة مؤقتًا.
• ETag / If-None-Match — طلبات شرطية: يُوفّر الخادم رمز إصدار؛ يُعيده العميل؛ 304 يوفر النطاق الترددي إن لم يتغير المورد.
• X-Request-ID / Trace-ID — معرّفات ارتباط للتتبع الموزع. أنشئها عند الحافة ومررها في كل استدعاء downstream.
• Retry-After — يُخبر العملاء متى يُعيدون المحاولة بعد 429 أو 503. يمنع قطعان الرعد بعد الانقطاعات.

ما يُضيفه HTTPS: بروتوكول TLS

HTTPS هو HTTP محمول فوق TLS (أمان طبقة النقل). يُضيف TLS ثلاثة ضمانات تفتقر إليها HTTP العادية كليًا:

1. التشفير — جميع البيانات مشفّرة أثناء النقل. لا يستطيع مهاجم على نفس شبكة Wi-Fi أو مزود الإنترنت قراءة جسم الطلب أو الاستجابة أو الترويسات أو مسار URL (رغم أن اسم النطاق مرئي في TLS SNI).
2. المصادقة — يُقدّم الخادم شهادة X.509 موقَّعة من جهة إصدار شهادات (CA) يثق بها العميل. هذا يُثبت هوية الخادم ويمنع هجمات تزوير DNS والوسيط (MITM).
3. سلامة البيانات — كود MAC على كل سجل TLS يضمن عدم إمكانية التلاعب بالبيانات أثناء النقل دون كشف.

تكلفة TLS — ماذا يُكلّف فعلًا

قلق شائع هو الحمل الإضافي على الأداء من TLS. في الواقع، قلّص TLS 1.3 (2018) هذا إلى شبه صفر للاتصالات القائمة:

• تكلفة المصافحة: ينجز TLS 1.3 المصافحة في رحلة واحدة (1-RTT) للاتصالات الجديدة، مقارنةً برحلتين في TLS 1.2. استئناف الجلسة بـ 0-RTT ممكن للاتصالات المتكررة (رغم وجود تحفظات هجوم إعادة التشغيل).
• تكلفة المعالج: تتضمن المعالجات الحديثة تسريع AES-NI. يستطيع Nginx على عتاد عادي التعامل مع ~10,000 مصافحة TLS في الثانية، وحمل التشفير المتماثل على نقل البيانات لا يُذكر.
• زمن الاستجابة: تُضيف المصافحة ~1 RTT شبكي. على وصلة بـ 50 مللي ثانية RTT، هذا 50 مللي ثانية إضافية للطلب الأول فحسب. HTTP/2 والاتصالات المستمرة توزّع هذا على طلبات كثيرة.

HTTP/1.1 مقابل HTTP/2 مقابل HTTP/3

إصدار HTTP المستخدم له تأثير كبير على زمن الاستجابة والإنتاجية:

• HTTP/1.1 — طلب واحد لكل اتصال في كل مرة (حجب رأس الطابور). الحل البديل: المتصفحات تفتح 6 اتصالات موازية لكل أصل. Keep-Alive يُعيد استخدام الاتصالات، لكن التدفق المنقوصي لم ينجح عمليًا أبدًا.
• HTTP/2 — يُعدّد تدفقات متعددة عبر اتصال TCP واحد، مع ضغط الترويسات (HPACK) ودفع الخادم. يُزيل حجب رأس الطابور على مستوى HTTP، لكن حجب مستوى TCP لا يزال موجودًا عند فقدان الحزم. الافتراضي في معظم موازنات التحميل الحديثة اليوم.
• HTTP/3 — يعمل فوق QUIC (قائم على UDP) بدلًا من TCP. يُزيل حجب رأس الطابور على مستوى TCP كليًا. مفيد بشكل خاص على الاتصالات عالية الفقدان (الهاتف المحمول). يتطلب UDP مفتوحًا عبر الجدران النارية. يُنشر بشكل متزايد على الحافة (Cloudflare، Google).

تجميع الصورة: HTTPS في بنية حقيقية

في نظام إنتاجي، يعمل HTTPS كما يلي: يُرسل عميل طلبًا إلى نطاقك. يحل DNS العنوان إلى IP شبكة CDN أو موازن التحميل. تُنهي شبكة CDN/LB اتصال TLS — تحتفظ بشهادتك ومفتاحك الخاص. ثم تُعيد توجيه طلب HTTP المُفكَّك تشفيره إلى الواجهة الخلفية عبر شبكة داخلية موثوقة (غالبًا بـ HTTP/2). تُعيد الواجهة الخلفية استجابة؛ يُعيد LB تشفيرها (أو يُرسلها كما هي إن استخدمت TLS شاملًا) ويُعيدها للعميل. يضمن تدوير الشهادات وتثبيت OCSP وترويسات HSTS استمرارية سلسلة الثقة.

فهم هذه الطبقة — من سطر الطلب الخام، عبر الترويسات ورموز الحالة و TLS والتفاوض على الإصدار — هو الأساس لكل مفهوم شبكي آخر في هذه الدورة: بوابات API وWebSockets وgRPC كلها تبني مباشرةً فوقه.