HTTP/HTTPS: ما هي، بروتوكولات نقل البيانات وتشفير TLS

ما هما HTTP و HTTPS؟

HTTP (HyperText Transfer Protocol) هو بروتوكول طبقة تطبيق من نموذج OSI مصمم لنقل مستندات النص التشعبي والبيانات الأخرى على شبكة الويب العالمية. طوره تيم بيرنرز لي في عام 1989، مر HTTP بعدة إصدارات: من HTTP/0.9 (طلبات GET وردود HTML فقط) إلى HTTP/2 و HTTP/3 الحديثين. يعمل البروتوكول وفق نموذج طلب-استجابة: يرسل العميل طلباً إلى الخادم، يعالجه الخادم ويعيد الرد.

HTTPS (HTTP Secure) هو امتداد لبروتوكول HTTP يضيف طبقة تشفير عبر TLS (Transport Layer Security). HTTPS ليس بروتوكولاً منفصلاً — إنه مزيج من HTTP و TLS. يتم تشفير البيانات المنقولة عبر HTTPS من جانب العميل وفك تشفيرها على الخادم، مما يجعلها غير قابلة للاعتراض أو التزوير. يوفر HTTPS أيضاً مصادقة الخادم عبر شهادات SSL/TLS، مما يضمن أن العميل يتصل بالخادم الحقيقي وليس بمهاجم.

الفرق الرئيسي بين HTTP و HTTPS هو الأمان. ينقل HTTP البيانات بنص واضح: يمكن لأي عقدة شبكة بين العميل والخادم قراءة محتوى الطلب أو الرد. يشفر HTTPS جميع المحتويات، بما في ذلك عنوان URL والرؤوس وجسم الطلب، تاركاً مرئياً فقط عنوان IP للخادم ومنفذ الاتصال. للتطبيقات المحمولة التي تعمل عبر شبكات Wi-Fi العامة، HTTPS هو متطلب أمان إلزامي.

كيف يعمل HTTP

HTTP هو بروتوكول عديم الحالة (stateless) يعمل عبر TCP/IP. ينشئ العميل اتصال TCP مع الخادم (عادة على المنفذ 80 لـ HTTP أو 443 لـ HTTPS)، ويرسل طلب HTTP، ويتلقى رد HTTP، ويغلق الاتصال (في HTTP/1.1 يمكن إعادة استخدام الاتصال). يتكون كل تفاعل بين العميل والخادم من طلب ورد. يعني غياب الحالة أن الخادم لا يخزن معلومات حول طلبات العميل السابقة — كل طلب يعالج بشكل مستقل.

تتضمن عملية تفاعل HTTP الخطوات التالية:

• حل DNS — المتصفح أو العميل يحول اسم النطاق إلى عنوان IP عبر DNS
• مصافحة TCP — يتم إنشاء اتصال TCP عبر مصافحة ثلاثية (SYN, SYN-ACK, ACK)
• مصافحة TLS — لـ HTTPS، يتم إنشاء اتصال مشفر إضافي (تبادل الشهادات والمفاتيح)
• طلب HTTP — يرسل العميل الطريقة، URL، الرؤوس، وجسم الطلب اختيارياً
• رد HTTP — يعيد الخادم رمز الحالة، الرؤوس، وجسم الرد

خاصية مهمة لـ HTTP هي العزلية (Idempotency) للطرق. GET, HEAD, PUT, DELETE و OPTIONS هي عزلية: التنفيذ المتكرر لنفس الطلب لا يغير حالة الخادم بعد التنفيذ الأول. POST, PATCH و CONNECT ليست عزلية — كل استدعاء يمكن أن ينشئ مورداً جديداً أو يغير الحالة. لتطوير التطبيقات المحمولة، فهم العزلية أمر بالغ الأهمية: عند إعادة إرسال طلب بسبب خطأ في الشبكة، يجب أن يعرف العميل ما إذا كان من الآمن تكرار الطلب.

HTTPS وتشفير TLS

HTTPS يستخدم بروتوكول التشفير TLS (Transport Layer Security) لحماية البيانات المنقولة. TLS هو خليفة SSL (Secure Sockets Layer)، الذي طورته شركة Netscape في عام 1995. تعتبر إصدارات SSL 2.0 و 3.0 قديمة وغير آمنة؛ الإصدارات الحديثة TLS 1.2 (صدر في 2008) و TLS 1.3 (صدر في 2018) تستخدم في كل مكان. TLS 1.3، على وجه الخصوص، يقلل وقت إنشاء الاتصال من جولتين (round-trips) إلى جولة واحدة، مما يسرع التحميل بشكل كبير على الأجهزة المحمولة.

تتضمن عملية مصافحة TLS المراحل التالية:

• Client Hello — يرسل العميل قائمة بإصدارات TLS المدعومة ومجموعات التشفير
• Server Hello — يختار الخادم إصدار TLS ومجموعة التشفير، ويرسل شهادة SSL/TLS الخاصة به
• التحقق من الشهادة — يتحقق العميل من شهادة الخادم عبر سلسلة الثقة حتى المرجع المصدق الجذر (CA)
• تبادل المفاتيح — يولد العميل والخادم مفتاحاً سرياً مشتركاً (مفتاح الجلسة)
• تبديل التشفير — يؤكد الطرفان الانتقال إلى الاتصال المشفر

التحقق من شهادة SSL/TLS هو مرحلة حاسمة للأمان. يتحقق العميل من أن الشهادة: لم تنته صلاحيتها، موقعة من مرجع مصدق (CA) موثوق، تطابق النطاق في عنوان URL، ولم يتم إبطالها (عبر CRL أو OCSP). في التطبيقات المحمولة، يوصى باستخدام تثبيت الشهادة (Certificate Pinning) — الربط بشهادة خادم محددة أو مفتاح عام. يمنع هذا هجمات MITM حتى في حالة اختراق المرجع المصدق. ومع ذلك، يتطلب pinning الحذر: عند تغيير الشهادة، يجب تحديث التطبيق مسبقاً.

هيكل طلب واستجابة HTTP

يتكون طلب HTTP من ثلاثة أجزاء: سطر الطلب، الرؤوس، وجسم اختياري. يحتوي سطر الطلب على طريقة HTTP، عنوان URL للطلب، وإصدار HTTP. تنقل الرؤوس معلومات وصفية: نوع المحتوى، رموز المصادقة، إعدادات التخزين المؤقت. الجسم موجود فقط في الطرق التي تنقل البيانات (POST, PUT, PATCH) وغائب في GET و DELETE.

مثال لطلب HTTP إلى REST API:

POST /api/v1/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Cache-Control: no-cache

{
    "name": "آنا",
    "email": "anna@example.com"
}

رد HTTP له هيكل مماثل: سطر حالة مع إصدار HTTP ورمز الحالة، رؤوس، وجسم. رمز الحالة هو رقم مكون من ثلاثة أرقام يحدد نتيجة معالجة الطلب. تشمل رؤوس الرد Content-Type, Content-Length, Cache-Control, Set-Cookie وغيرها. يحتوي جسم الرد على البيانات المطلوبة بالتنسيق المحدد في Content-Type (عادة JSON لواجهات API، HTML لصفحات الويب، صور للمحتوى الوسائطي).

تلعب الرؤوس دوراً حاسماً في عمل HTTP. Content-Type و Accept يتحكمان في تنسيق البيانات. Authorization ينقل رموز الوصول. Cache-Control يدير التخزين المؤقت. رؤوس CORS (Access-Control-Allow-Origin) تتحكم في الوصول من نطاقات أخرى في المتصفحات. User-Agent يعرّف تطبيق العميل. للتطبيقات المحمولة، رؤوس التحكم في التخزين المؤقت مهمة بشكل خاص — فهي تساعد في تقليل كمية البيانات المنقولة وتحسين الأداء عند الإشارة الضعيفة.

رموز حالة HTTP

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

للتطبيقات المحمولة، معالجة رمز 401 Unauthorized ذات أهمية خاصة. عند استلام هذا الرمز، يجب على العميل محاولة تحديث رمز الوصول عبر Refresh Token وإعادة محاولة الطلب الأصلي. إذا أعاد تحديث الرمز أيضاً 401، يجب إعادة توجيه المستخدم إلى شاشة تسجيل الدخول. هذا المنطق يُنفذ عادة في Interceptor (OkHttp) أو في طبقة الوسيط لعميل الشبكة.

HTTP/1.1 و HTTP/2 و HTTP/3

HTTP/1.1، المنشور في عام 1999، لا يزال إصداراً مستخدماً على نطاق واسع من البروتوكول. عيبه الرئيسي هو حظر الرأس (head-of-line blocking): الطلبات إلى نفس الخادم تُنفذ بشكل تسلسلي، كل طلب ينتظر اكتمال السابق. للالتفاف حول هذا القيد، تفتح المتصفحات 6-8 اتصالات TCP متوازية لنفس النطاق، مما يزيد من حمل الخادم واستهلاك الذاكرة. HTTP/1.1 أيضاً ينقل الرؤوس بنص واضح ولا يدعم server push.

HTTP/2 (2015) يحل مشكلة الحظر عبر تعدد الإرسال (multiplexing) — تيارات بيانات متعددة تُنقل عبر اتصال TCP واحد في وقت واحد. يمكن للخادم إرسال الموارد إلى العميل قبل أن يطلبها العميل (server push). HTTP/2 أيضاً يضغط الرؤوس عبر HPACK، مما يقلل كمية البيانات المنقولة. للتطبيقات المحمولة، HTTP/2 مفيد بشكل خاص: اتصال واحد يحل محل عدة اتصالات، مما يقلل وقت مصافحة TLS واستهلاك البطارية.

HTTP/3 (2022) هو أحدث إصدار من البروتوكول، والذي يستخدم QUIC (Quick UDP Internet Connections) بدلاً من TCP. يعمل QUIC عبر UDP، مما يلغي مشكلة حظر الرأس على مستوى بروتوكول النقل. يقلل HTTP/3 وقت إنشاء الاتصال إلى 0 جولات (round-trips) في أفضل الحالات (على الاتصالات المتكررة) وإلى جولة واحدة عند الاتصال الأول، وهو أسرع بكثير من HTTP/2 مع 2-3 جولات. للأجهزة المحمولة، HTTP/3 فعال بشكل خاص عند التبديل بين Wi-Fi والشبكات المحمولة — لا ينقطع الاتصال لأن QUIC يستخدم معرف اتصال بدلاً من عنوان IP.

HTTPS في تطوير التطبيقات المحمولة

استخدام HTTPS في التطبيقات المحمولة ليس توصية بل متطلب إلزامي. بدءاً من Android 9 (API 28) و iOS 9 (ATS — App Transport Security)، يجب أن تستخدم جميع طلبات الشبكة HTTPS افتراضياً. يتم حظر طلبات HTTP من قبل النظام، ويتطلب السماح بها استثناءً صريحاً في تكوين التطبيق. يرفض Google Play Store و App Store التطبيقات التي تنقل بيانات حساسة عبر HTTP، بما في ذلك كلمات المرور ورموز الوصول والبيانات الشخصية.

يتضمن تكوين HTTPS في تطبيق Android المحمول:

<!-- AndroidManifest.xml — إذن طلب الشبكة -->
<uses-permission android:name="android.permission.INTERNET" />

<!-- network_security_config.xml — إعداد HTTPS -->
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-12-31">
            <pin digest="SHA-256">rDjsFv3bGf...</pin>
        </pin-set>
    </domain-config>
</network-security-config>

على iOS، يتم تكوين مماثل عبر Info.plist باستخدام المفتاح NSAppTransportSecurity. لتصحيح حركة مرور HTTPS في التطبيقات المحمولة، تُستخدم أدوات الوكيل: Charles Proxy أو Proxyman أو mitmproxy. تتطلب تثبيت شهادة SSL موثوقة على الجهاز. في إصدارات الإنتاج، يجب تعطيل إمكانيات التصحيح والتحقق من تكوين Certificate Pinning بشكل صحيح. استخدام OkHttp على Android مع CertificatePinner الخاص به أو TrustManager على iOS مع SecTrustEvaluate هي طرق قياسية لتنفيذ pinning.

جانب أمان مهم لـ HTTPS في تطوير التطبيقات المحمولة هو تثبيت SSL (SSL Pinning). بدون pinning، يثق التطبيق في أي شهادة موقعة من CA معروف. إذا تم اختراق CA، يمكن للمهاجم اعتراض حركة مرور التطبيق. يربط pinning التطبيق بشهادة خادم محددة أو مفتاح عام. عندما تتغير شهادة الخادم، يجب إصدار تحديث للتطبيق، لذلك يُخطط pinning بهامش — الربط بشهادة CA أعلى أو استخدام عدة مفاتيح احتياطية.