كل مطور اشتغل بتطبيق لحظي (دردشة، إشعارات، لعبة بالمتصفح) بيعرف WebSocket. بس بالفترة الأخيرة صار في اسم جديد يظهر بجانبه: WebTransport. هاد شرح عملي: شو الفرق الفعلي، ومتى فعلاً تحتاج الجديد.
WebSocket: قناة وحيدة، موثوقة، فوق TCP
WebSocket بيبدأ كطلب HTTP عادي، وبعد "ترقية" الاتصال (101 Switching Protocols) بيتحول لقناة واحدة ثنائية الاتجاه ومفتوحة طول الوقت فوق نفس اتصال TCP. كل رسالة بتوصل، وبالترتيب الصحيح، وإلا الاتصال بيوقف وينتظر — لأن TCP نفسه بروتوكول تسلسلي بطبيعته.
هاد الضمان مثالي لدردشة أو إشعارات، بس مبالغة بأحيان تانية: تطبيق لعبة بيبعث موضع اللاعب عشرات المرات بالثانية ما بيحتاج رسالة قديمة ضايعة تنعاد — بيحتاج فقط أحدث موضع، بأسرع وقت.
WebTransport: عدة طرق نقل على اتصال واحد فوق HTTP/3
WebTransport واجهة جديدة مبنية فوق HTTP/3 (ومن ورائه QUIC، البروتوكول المبني فوق UDP يلي حل مشكلة Head-of-Line Blocking بـ HTTP/3). بدل قناة وحيدة، بيعطيك:
- Datagrams غير موثوقة: رسائل صغيرة ممكن تضيع أو توصل بترتيب مختلف، بلا إعادة إرسال تلقائية.
- تدفقات ثنائية الاتجاه (Bidirectional Streams): موثوقة ومرتبة، وفيك تفتح أكتر من تدفق مستقل بنفس الاتصال.
- تدفقات باتجاه واحد (Unidirectional Streams): موثوقة، لكن باتجاه واحد فقط.
لأن الاتصال مبني فوق QUIC، فقدان حزمة بتدفق وحدة ما بيوقف باقي التدفقات ولا قناة الـ datagrams — امتداد مباشر لنفس ميزة QUIC يلي خلّت HTTP/3 أسرع من HTTP/2 بالشبكات المتقلبة.
WebSocket → قناة واحدة موثوقة، فوق TCP
WebTransport → streams موثوقة + datagrams غير موثوقة، فوق QUIC (HTTP/3)
جدول المقارنة
| المعيار | WebSocket | WebTransport |
|---|---|---|
| بروتوكول النقل | TCP | QUIC (فوق HTTP/3) |
| نوع القناة | قناة واحدة موثوقة | streams موثوقة + datagrams غير موثوقة، بالتوازي |
| فقدان حزمة | يوقف القناة كاملة | يأثر بتدفق واحد فقط، والـ datagrams أصلًا مصممة لتحمّل الفقد |
| دعم المتصفحات | شامل تقريبًا بكل المتصفحات | وصل للمتصفحات الأربعة الكبار (Chrome، Edge، Firefox، Safari) لكن أضيق من WebSocket |
| بداية الاتصال | ترقية طلب HTTP (ws:// أو wss://) | اتصال مباشر عبر HTTP/3 (https://) |
امتى تختار كل واحد؟
- دردشة، إشعارات، أوامر تحكّم لازم توصل كلها بالترتيب: WebSocket، أو تدفق موثوق بـ WebTransport لو عندك حاجة إضافية لـ datagrams بنفس الاتصال.
- بث حي منخفض التأخير، مواضع لاعبين بلعبة، بيانات حساسات لحظية: WebTransport مع datagrams — الأحدث أهم من ضمان وصول كل رسالة قديمة.
- مشروع موجود شغّال بـ WebSocket بلا مشاكل: ما في داعي تبديله فقط لأن الاسم الجديد صار موجود.
الخلاصة
WebTransport ما بيلغي WebSocket — الاثنين موجودين لحاجات مختلفة. WebSocket لسا الأنسب لما تحتاج ضمان وصول كل رسالة بالترتيب ودعم متصفحات أوسع، وWebTransport بيصير مفيد فعليًا لما يكون بمشروعك سيناريو لحظي بيستفيد من نقل بيانات غير موثوقة أو تعدد تدفقات على اتصال واحد فوق HTTP/3.
تعلّم أساسيات الشبكات كاملة بالعربي — من نموذج OSI لـ HTTP/2 وHTTP/3 وWebSocket وWebTransport.