DEV Community

Cover image for ما هو HTTP/3 (QUIC) وماذا يعني لواجهات برمجة التطبيقات الخاصة بك
Yusuf Khalidd
Yusuf Khalidd

Posted on Originally published at apidog.com

ما هو HTTP/3 (QUIC) وماذا يعني لواجهات برمجة التطبيقات الخاصة بك

HTTP/3 وQUIC: ما الذي يتغير فعليًا في واجهات برمجة التطبيقات؟

كل طلب HTTP تجريه واجهة برمجة التطبيقات (API) يعتمد على طبقة نقل لا يفكر فيها معظم المطورين. طوال 25 عامًا كانت هذه الطبقة هي TCP، إلى أن طوّرت Google بروتوكول QUIC فوق UDP، ثم وحّدته IETF. صُمم HTTP/3 للعمل فوق QUIC.

جرّب Apidog اليوم

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

تظل دلالات HTTP كما هي في HTTP/1.1 وHTTP/2 وHTTP/3: الطلبات، والاستجابات، وأكواد الحالة، وحمولات JSON. أدوات مثل Apidog تختبر API على هذا المستوى، لذلك تبقى اختبارات سلوك نقطة النهاية صالحة مهما كان إصدار النقل الذي تفاوضت عليه البنية التحتية. ويمكنك متابعة التفاصيل من مقال ما هو HTTP/2 وكيفية اختبار واجهات برمجة تطبيقات HTTP/2.

ما هو بروتوكول QUIC؟

QUIC هو بروتوكول نقل موحّد في RFC 9000. يعمل فوق UDP بدلًا من TCP، ويعيد تنفيذ الموثوقية، والترتيب، والتحكم في الازدحام في مساحة المستخدم، مع تشفير مدمج منذ أول حزمة.

تحدد QUIC أربعة قرارات تصميمية رئيسية:

  • العمل فوق UDP: نظرًا لأن TCP مدمج في نواة نظام التشغيل وفي كثير من الصناديق الوسيطة، يصعب تطويره. أما UDP فهو غلاف بسيط، لذلك يبني QUIC طبقة الموثوقية الخاصة به ويمكن تحديثها عبر المكتبات بدلًا من ترقيات أنظمة التشغيل.
  • دمج TLS 1.3: في TCP تحدث مصافحة TCP ثم مصافحة TLS منفصلة. يدمج QUIC المصافحتين، ما يجعل الاتصال الآمن جاهزًا بعد رحلة ذهاب وعودة واحدة. لا يوجد QUIC غير مشفّر.
  • استقلالية التدفقات (Streams): يحمل اتصال QUIC عدة تدفقات مستقلة. لا تؤدي الحزمة المفقودة إلا إلى إيقاف التدفق الذي تنتمي إليه.
  • استمرار الاتصال عند تبدّل الشبكة: يعرّف TCP الاتصال بعنوان IP والمنفذ. عند الانتقال من Wi-Fi إلى 5G ينقطع الاتصال. أما QUIC فيستخدم معرّف اتصال، ما يسمح بترحيل الاتصال إلى الشبكة الجديدة دون مصافحة كاملة.

يعرّف HTTP/3 في RFC 9114 ربط دلالات HTTP بتدفقات QUIC. الأساليب والرؤوس وأكواد الحالة نفسها، لكن تنسيق السلك وطبقة النقل مختلفان.

HTTP/3 مقابل HTTP/2: التغيير العملي

قدّم HTTP/2 تعدد الإرسال (multiplexing)، فسمح لطلبات متعددة بمشاركة اتصال TCP واحد. لكن TCP يضمن تسليم دفق بايت واحد بالترتيب. عند فقدان حزمة، يحتفظ TCP بكل البايتات اللاحقة حتى تصل إعادة الإرسال، بما فيها البايتات التابعة لتدفقات HTTP/2 غير المرتبطة.

نتيجة ذلك أن فقدان حزمة واحدة قد يوقف جميع الطلبات المتعددة الإرسال على الاتصال. تُعرف هذه المشكلة باسم حظر الرأس الأمامي (Head-of-Line Blocking)، وقد تجعل HTTP/2 أبطأ من HTTP/1.1 على الشبكات التي تعاني من فقدان الحزم.

يعالج HTTP/3 المشكلة بإسناد كل طلب إلى تدفق QUIC مستقل. إذا فُقدت حزمة تخص التدفق 5، تستمر التدفقات من 6 إلى 24 في العمل.

الخاصية HTTP/2 عبر TCP + TLS 1.3 HTTP/3 عبر QUIC
إعداد اتصال جديد رحلتا ذهاب وعودة: TCP ثم TLS رحلة ذهاب وعودة واحدة
استئناف الاتصال رحلة ذهاب وعودة واحدة 0-RTT
تأثير فقدان حزمة يحظر جميع التدفقات يحظر تدفقًا واحدًا
تبدّل الشبكة اتصال جديد ومصافحة كاملة ترحيل الاتصال واستمراره
التشفير طبقة منفصلة، واختياري نظريًا TLS 1.3 مدمج وإلزامي

تنبيه حول 0-RTT

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

لذلك يجب قبول الطلبات الثابتة (idempotent) فقط في 0-RTT:

  • إعادة تشغيل طلب GET عادةً غير ضارة.
  • إعادة تشغيل طلب POST ينفذ عملية دفع أو يخصم بطاقة ائتمان خطيرة.

إذا فعّلت 0-RTT على الحافة، فاستبعد طلبات API غير الثابتة أو تأكد من أن شبكة CDN تتولى ذلك.

ماذا يعني HTTP/3 لواجهات برمجة التطبيقات؟

مصافحة أقل تكلفة

على اتصال بزمن انتقال دائري (RTT) يبلغ 60 مللي ثانية، قد يستغرق إعداد TCP + TLS نحو 120 مللي ثانية قبل إرسال أول طلب API. يخفض HTTP/3 ذلك إلى نحو 60 مللي ثانية، ويقترب من الصفر عند الاستئناف.

يظهر الفرق بوضوح في:

  • التشغيل البارد لتطبيقات الهاتف.
  • استيقاظ تطبيقات الهاتف في الخلفية.
  • الجلسات القصيرة التي تنشئ اتصالات جديدة باستمرار.

أما خدمات الخادم إلى الخادم التي تستخدم تجمعات اتصالات دافئة، فعادةً لا يكون وقت المصافحة عاملًا مهمًا.

اتصالات أكثر استقرارًا للعملاء المتنقلين

قد يبدأ المستخدم طلبًا عبر Wi-Fi ثم ينتقل هاتفه إلى الشبكة الخلوية. في TCP يفشل الطلب الجاري وتحتاج آلية إعادة المحاولة إلى اتصال جديد. في QUIC يمكن للاتصال الانتقال إلى الشبكة الجديدة مع الحفاظ على الاتصال المنطقي.

هذا يعني:

  • أخطاء مهلة أقل في سجلات العملاء.
  • عمليات كتابة غير مكتملة أقل.
  • حاجة أقل إلى إعادة المصافحة.

تعدد إرسال دون حظر شامل

يهم إصلاح HOL بشكل خاص عندما يرسل العميل عدة طلبات متوازية، مثل:

  • لوحة تحكم تحدّث 15 ويدجت.
  • محرك مزامنة يرسل مجموعة من التحديثات.
  • تطبيق جوال يجري عدة استدعاءات عند فتح الشاشة.

على شبكة نظيفة، يكون HTTP/2 وHTTP/3 متقاربين. لكن عند فقدان حزم بنسبة 1–2%، يحافظ HTTP/3 على استقلالية الطلبات، بينما قد يوقف HTTP/2 الطلبات معًا.

gRPC ما زال يعتمد غالبًا على HTTP/2

يرتبط gRPC بـ HTTP/2 حسب التصميم، إذ يعتمد على تأطير HTTP/2 والمُذيّلات (trailers). لم يوحّد نظام gRPC البيئي خرائط HTTP/3، كما لا توفرها التطبيقات الرئيسية في Go وJava وPython وNode.

يمكن لخادم Kestrel في .NET تقديم gRPC عبر HTTP/3 كقدرة تجريبية، لكنه استثناء حاليًا. إذا كانت بنيتك تعتمد على gRPC وHTTP/2 لأداء واجهات API الداخلية، فلا حاجة ملحّة إلى التخطيط لترحيلها إلى HTTP/3 هذا العام.

التدفق وحركة المرور في الوقت الفعلي

تعمل أحداث الخادم المرسلة (SSE) فوق HTTP/3 دون تغيير؛ فهي مجرد استجابة HTTP طويلة الأمد.

أما WebSockets فهي أكثر تعقيدًا:

  • صُممت ترقية WebSocket الأصلية لـ TCP.
  • يوفّر HTTP/3 نظيرًا لها في RFC 9220.
  • ما تزال واجهة WebTransport ودعمها في مراحل التوسع.

لذلك، عند الاختيار بين WebSockets وHTTP العادي، لا تجعل توفر HTTP/3 العامل الحاسم بعد.

متى لن يساعد HTTP/3؟

معظم مشكلات تأخير API لا تتعلق بالنقل. إذا استغرقت نقطة النهاية 400 مللي ثانية بسبب استعلام قاعدة بيانات غير مفهرس، فلن يجعل HTTP/3 الاستجابة سريعة. غالبًا ما يكون تأثير التخزين المؤقت، وتصميم الحمولات، واستعلامات N+1، وإعادة استخدام الاتصال أكبر بكثير. ابدأ بـ اختبار أداء API قبل ترقية البروتوكول.

يتألق HTTP/3 خصوصًا في:

  • الاتصالات ذات زمن الانتقال العالي.
  • الشبكات التي تعاني من فقدان الحزم.
  • العملاء المتنقلين الذين يبدّلون الشبكات أثناء الجلسة.
  • الاتصالات القصيرة الكثيرة بدلًا من الاتصالات الطويلة القليلة.

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

ضع في الحسبان أيضًا:

  • قد يُحظر UDP 443 في بعض شبكات الشركات؛ يتراجع العميل تلقائيًا إلى HTTP/2، لذلك لا يتعطل الاتصال.
  • قد يستهلك تشفير QUIC في مساحة المستخدم حاليًا وحدة معالجة مركزية أكبر لكل اتصال من TCP داخل النواة المحسّن.

الدعم الحالي: من يتحدث HTTP/3؟

  • المتصفحات: Chrome وEdge وFirefox وSafari تدعم HTTP/3 ومفعّلة افتراضيًا.
  • شبكات CDN والحافة: Cloudflare وFastly وAkamai وCloudFront تدعمه. في Cloudflare يكفي تفعيله. النمط العملي لمعظم الفرق هو إنهاء HTTP/3 عند الحافة، ثم استخدام HTTP/1.1 أو HTTP/2 بين الحافة والمصدر.
  • الخوادم: أضاف Nginx دعمًا تجريبيًا في الإصدار 1.25 باستخدام listen 443 quic;. يفعّله Caddy افتراضيًا، كما يدعمه LiteSpeed وHAProxy. لا يدعمه Apache httpd.
  • بيئات التشغيل: لا يوفّر Node.js خادم HTTP/3 مدمجًا ومستقرًا، وهو سبب آخر لشيوع الإنهاء عند الحافة.
  • curl: يمكن استخدامه مع --http3 عند بنائه مع مكدس TLS يدعم HTTP/3. راجع وثائق curl HTTP/3.

كيف تتحقق من أن API تقدم HTTP/3؟

يُعلن الخادم عن HTTP/3 عادةً عبر رأس الاستجابة Alt-Svc:

alt-svc: h3=":443"; ma=86400
Enter fullscreen mode Exit fullscreen mode

يعني ذلك أن الخدمة متاحة عبر HTTP/3 على UDP 443 لمدة 24 ساعة.

تحقق من الرأس باستخدام curl:

curl -sI https://www.cloudflare.com | grep -i alt-svc
# alt-svc: h3=":443"; ma=86400
Enter fullscreen mode Exit fullscreen mode

وأرسل طلبًا مباشرًا عبر HTTP/3:

curl --http3 -I https://cloudflare-quic.com
# HTTP/3 200
Enter fullscreen mode Exit fullscreen mode

يجب أن يظهر HTTP/3 في سطر الحالة بدلًا من HTTP/2.

في Chrome DevTools:

  1. افتح تبويب Network.
  2. انقر بزر الفأرة الأيمن على عناوين الأعمدة.
  3. فعّل عمود Protocol.
  4. ابحث عن h3 بجوار استدعاءات API.

وفي الإنتاج، أضف البروتوكول المتفاوض عليه إلى سجلات الوصول حتى تعرف نسبة حركة h2 وh3.

لا تكتفِ بفحص النقل. وجّه Apidog إلى نقاط النهاية نفسها، وتحقق من:

  • أكواد الحالة.
  • مخططات الاستجابة.
  • ميزانيات التأخير.
  • سلوك الطلبات قبل وبعد تفعيل HTTP/3.

يمكنك تنزيل Apidog مجانًا وتشغيل مجموعة الاختبارات نفسها قبل وبعد التفعيل. قِس النتائج على شبكات الهاتف؛ فهي أكثر فائدة من الاعتماد على عناوين المعايير.

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

هل HTTP/3 أسرع من HTTP/2؟

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

قِس الأداء باستخدام حركة المرور الفعلية لديك. وإذا ظهرت أخطاء اتصال في HTTP/2، فغالبًا تكون المشكلة في TLS، مثل خطأ SSLV3_ALERT_HANDSHAKE_FAILURE، وليس في حدود HTTP/2 نفسها.

هل يستخدم HTTP/3 بروتوكول TCP؟

لا. يعمل HTTP/3 فوق QUIC، ويعمل QUIC فوق UDP، عادةً على المنفذ 443. يعيد QUIC تنفيذ الموثوقية والترتيب والتحكم في الازدحام، لكن لكل تدفق وفي مساحة المستخدم.

إذا حُظر UDP 443، يتراجع العميل تلقائيًا إلى HTTP/2 عبر TCP.

هل أحتاج إلى تغيير كود API من أجل HTTP/3؟

تقريبًا لا. الأساليب والرؤوس وأكواد الحالة والهيئات لم تتغير. يتركز العمل في البنية التحتية: CDN، أو موازن التحميل، أو الخادم.

الاستثناء المهم هو 0-RTT: تأكد من قصر البيانات المبكرة على الطلبات الثابتة (idempotent).

هل يمكن استخدام gRPC عبر HTTP/3؟

غالبًا لا في الوقت الحالي. تنسيق gRPC السلكي مرتبط بـ HTTP/2، ومكتبات gRPC الرئيسية لا توفر نقل HTTP/3 على نطاق واسع. يدعم .NET ذلك تجريبيًا.

أبقِ خدمات gRPC على HTTP/2، واستخدم HTTP/3 أولًا حيث تكون فائدته أوضح: نقاط REST العامة الموجهة إلى المتصفحات والأجهزة المحمولة.

Top comments (0)