أصبح TCP معطلاً جداً بحيث لا يمكن إصلاحه، لذا بنى الإنترنت بروتوكولاً جديداً فوق UDP

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

ذلك الشيء الجديد هو QUIC، الذي تم توحيده بواسطة IETF في عام 2021 كـ RFC 9000. HTTP/3، أحدث إصدار من البروتوكول الذي يشغل الويب، يعمل على QUIC. قدمت Cloudflare HTTP/3 لأكثر من 40% من حركة المرور الخاصة بها. نشرت Google QUIC عبر خدماتها الخاصة منذ عام 2013. البروتوكول الذي كان من المفترض أن يكون تجربة أصبح الآن يحمل شريحة كبيرة من الإنترنت.

ما كان الخطأ في TCP

صمم TCP الأساسي لعالم من الاتصالات السلكية الثابتة والموثوقة. يفترض البروتوكول أنه إذا فُقدت حزمة، فإن الشبكة مزدحمة، ويجب أن يبطئ. كان هذا معقولاً في عام 1974. في عام 2026، مع المستخدمين المحمولين الذين يتحولون باستمرار بين Wi-Fi والخلوي، يتم إسقاط الحزم لأسباب لا علاقة لها بالازدحام — تداخل الإشارة، التبديل بين الأبراج، فجوات تغطية قصيرة. لا يستطيع TCP التمييز بين "الشبكة مزدحمة" و"المستخدم دخل للتو إلى المصعد"، ويبطئ في كلتا الحالتين.

المشكلة الهيكلية الأكبر هي حظر الرأس-في-الخط (head-of-line blocking). اتصال TCP واحد هو دفق بيانات مرتب. إذا فقدت الحزمة 7، فإن الحزم 8 إلى 100 تنتظر جميعًا حتى لو وصلت بشكل صحيح. عالج HTTP/2 نسخة واحدة من هذه المشكلة عن طريق تعدد الإرسال لطلبات متعددة عبر اتصال TCP واحد — لكن هذا جعل حظر الرأس-في-الخط أسوأ في طبقة TCP، وليس أفضل. يمكن لحزمة مفقودة واحدة الآن أن توقف جميع التدفقات متعددة الإرسال على الاتصال في وقت واحد.

كان هناك أيضًا عبء إنشاء الاتصال. يتطلب TCP مصافحة ثلاثية الاتجاه قبل أن تتدفق البيانات. يضيف TLS 1-2 رحلة ذهاب وإياب أخرى للتفاوض التشفيري. يتطلب تحميل مورد من خادم جديد 2-3 رحلات ذهاب وإياب كاملة قبل وصول أول بايت من المحتوى. لمستخدم في طوكيو يتصل بخادم في فيرجينيا، تستغرق كل رحلة ذهاب وإياب حوالي 170 مللي ثانية. اضرب ذلك في عدد الخوادم المميزة التي تتحدث إليها صفحة ويب حديثة، وسيكون عبء زمن الوصول كبيرًا.

لماذا بنوه على UDP

السؤال المنطقي هو: لماذا لا يصلحون TCP؟ الإجابة هي أن TCP منفذ في نواة كل نظام تشغيل، كل موجه، كل جدار ناري، كل موازن تحميل، وكل صندوق وسيط (middlebox) على الإنترنت. تغيير سلوك TCP سيتطلب تحديث مليارات الأجهزة. بعض تلك الأجهزة عمرها عقود ولن يتم تحديثها أبدًا. الصناديق الوسيطة للشبكة — الأجهزة التي تفحص وتوجه وتصفي حركة المرور — تفترض سلوك TCP وتتعطل بطرق غير متوقعة عندما يتم تعديل TCP. جربت IETF عدة إضافات لـ TCP على مر السنين ووجدت أنها ببساطة تم حظرها أو تجريدها بواسطة الصناديق الوسيطة في الميدان.

UDP، على النقيض من ذلك، هو لوحة بيضاء أساسًا. إنه بروتوكول إطلاق ونسيان (fire-and-forget) بدون حالة اتصال متأصلة، أو ترتيب، أو موثوقية. لا تتلاعب الصناديق الوسيطة بـ UDP بالطريقة التي تتعامل بها مع TCP لأنه لا يوجد شيء للتلاعب به. بناء QUIC على UDP يعني أن QUIC يمكنه تنفيذ إدارة الاتصال الخاصة به، والموثوقية، والترتيب، والتحكم في الازدحام في مساحة المستخدم — حيث يمكن تحديثه بدون تغييرات في النواة — مع الاستمرار في المرور عبر البنية التحتية الحالية للإنترنت دون تغيير.

ما الذي يغيره QUIC فعليًا

أول تحسن ملحوظ فوري هو وقت إنشاء الاتصال. يجمع QUIC مصافحة النقل ومصافحة TLS 1.3 التشفيرية في رحلة ذهاب وإياب واحدة. لاتصال أولي بخادم، يتطلب QUIC رحلة ذهاب وإياب واحدة قبل أن تتدفق البيانات، مقابل اثنتين أو ثلاث لـ TCP+TLS. لمستخدم عائد اتصل بالخادم من قبل، يدعم QUIC استئناف 0-RTT — يمكن للعميل إرسال بيانات التطبيق في أول حزمة، مع صفر رحلات ذهاب وإياب. تحسين الأداء أكثر وضوحًا في الشبكات المحمولة حيث يكون زمن الوصول مرتفعًا.

ترحيل الاتصال (Connection migration) يحل مشكلة التبديل المحمول مباشرة. يتم تحديد اتصال QUIC بواسطة معرف اتصال يختاره الطرف الطرفي، وليس بواسطة الرباعي (IP المصدر، منفذ المصدر، IP الوجهة، منفذ الوجهة) الذي يحدد اتصال TCP. عندما ينتقل هاتف من Wi-Fi إلى خلوي ويحصل على عنوان IP جديد، تنقطع جميع اتصالات TCP وتحتاج إلى إعادة تأسيس. اتصالات QUIC تنجو من تغيير IP — يعلن العميل عن عنوانه الجديد ويستمر الاتصال دون انقطاع.

التدفقات متعددة الإرسال بدون حظر الرأس-في-الخط هو الإصلاح الهيكلي الذي احتاجه HTTP/2 ولكن لم يستطع تحقيقه عبر TCP. ينفذ QUIC تدفقات مستقلة متعددة داخل الاتصال؛ حزمة مفقودة للتدفق A لا تمنع التدفقات B و C و D. لكل تدفق ضمان الترتيب الخاص به، لذا فإن الفقدان في تدفق واحد يوقف هذا التدفق فقط.

واقع النشر

كان التبني أسرع من معظم انتقالات البروتوكول في تاريخ الإنترنت، والتي لا تزال "تقاس بالسنوات". نشرت Google QUIC في Chrome في عام 2015، في البداية فقط لخدمات Google الخاصة. وحدت IETF QUIC وHTTP/3 في عام 2021. بحلول عام 2023، أظهرت بيانات W3Techs أن HTTP/3 مدعوم على حوالي 30% من مواقع الويب. تقارير Cloudflare أن QUIC يحمل حوالي 35-40% من حركة مرورها، وقد نما هذا الجزء بشكل مطرد سنة بعد سنة.

التبني من جانب الخادم قوي بين كبريات شبكات توصيل المحتوى (Cloudflare, Fastly, Akamai) ومقدمي الخدمات السحابية (AWS CloudFront, Google Cloud). تدعم معظم أطر العمل الحديثة للويب وموازنات التحميل HTTP/3. الجانب العميل مغطى: Chrome و Firefox و Safari و Edge جميعها تدعم HTTP/3 بشكل افتراضي، وكذلك المتصفحات المحمولة.

ليس كل اتصال QUIC يعمل بشكل أفضل من TCP. على اتصالات النطاق العريض الثابتة عالية الجودة، يكون الفرق ضئيلاً. تنفيذ مساحة المستخدم لـ QUIC يعني أنه لا يستفيد من تحسينات وحدة المعالجة المركزية (CPU) التي راكمها TCP على مدى عقود في النواة — العبء الزائد لمعالجة كل حزمة أعلى، وهو ما يهم في الاتصالات عالية الإنتاجية. لنقل الملفات الضخمة على روابط سريعة وموثوقة، لا يزال TCP تنافسيًا.

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

لا يصلح QUIC كل مشكلة في نقل الإنترنت — يظل التحكم في الازدحام، وتضخم المخزن المؤقت (bufferbloat)، وسعة الميل الأخير قيودًا حقيقية. لكنه يحل المشكلات التي كانت قابلة للإصلاح دون استبدال البنية التحتية المادية للشبكة. هذا تحسن ذو معنى، تم تقديمه عبر واحد من أسرع نشرات البروتوكول في تاريخ IETF.