TCP مقابل UDP

TCP مقابل UDP

كل بايت تُرسله عبر الإنترنت يسافر داخل حزمة بروتوكول طبقة النقل. يهيمن بروتوكولان على هذه الطبقة: TCP (بروتوكول التحكم في الإرسال) وUDP (بروتوكول مخطط بيانات المستخدم). اختيار البروتوكول الخطأ قد يُقوّض موثوقية خدمة مصرفية، أو يُضاعف زمن الاستجابة في لعبة مباشرة. إتقان الفارق بين البروتوكولين — ليس مجرد التعريف النظري بل المقايضات الهندسية الحقيقية — ضرورة أساسية في تصميم الأنظمة.

ما هو TCP؟

TCP هو بروتوكول قائم على الاتصال، موثوق، مرتّب، ومُتحقَّق منه. قبل أن ينتقل أي بايت من بيانات التطبيق، يُجري TCP مصافحة ثلاثية الاتجاه:

1. يُرسل العميل SYN — "أريد الاتصال."
2. يردّ الخادم بـSYN-ACK — "موافق، جاهز."
3. يُرسل العميل ACK — "تمّ إنشاء الاتصال."

بعد ذلك، كل مقطع يُرسله أحد الطرفين تُقرّه رسالة تأكيد (ACK) من الطرف الآخر. إذا لم تصل رسالة التأكيد خلال نافذة المهلة المحددة، يُعيد المُرسل إرسال المقطع تلقائياً. يفرض TCP أيضاً التسليم بالترتيب الصحيح: إذا وصل المقطع 4 قبل المقطع 3، يحتفظ TCP بالمقطع 4 في المخزن المؤقت ولا يُسلّم أياً منهما للتطبيق حتى وصول المقطع 3. وأخيراً، تتحكم خوارزميات التحكم في الازدحام في TCP (البدء البطيء، AIMD) تلقائياً في معدل الإرسال عند ازدحام الشبكة.

ما هو UDP؟

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

يبدو هذا عيباً، لكنه أيضاً القوة الخارقة لـ UDP. غياب الحمل الزائد الناجم عن المصافحة وإعادة الإرسال يجعل UDP:

• أسرع — لا يلزم أي ذهاب وإياب قبل تدفق البيانات.
• أقل زمن استجابة — لا انتظار خلف مقاطع معاد إرسالها.
• أخف على طبقة الشبكة — ترويسة UDP 8 بايت فقط مقابل 20-60 بايت لـ TCP.

المقارنة جنباً إلى جنب

متى تستخدم TCP؟

استخدم TCP كلما كان فقدان البيانات أو إعادة ترتيبها يؤدي إلى نتيجة تالفة أو غير صحيحة:

• HTTP/HTTPS — بايت مفقود في صفحة HTML أو استجابة JSON API يجعلها معطوبة.
• قواعد البيانات عبر الشبكة — بايت مفقود في استعلام SQL أو مجموعة النتائج يُفسد العملية.
• نقل الملفات (FTP، رفع S3) — مقطع مفقود يُفسد الملف بصمت.
• البريد الإلكتروني (SMTP، IMAP) — يجب أن تصل الرسائل كاملةً وسليمةً.
• SSH / الإدارة عن بُعد — حرف مفقود في أمر Shell له عواقب وخيمة.

بعبارة مختصرة: إذا كنت ستحتاج إلى تنفيذ إعادة الإرسال والترتيب بنفسك على UDP، فاستخدم TCP مباشرة.

متى تستخدم UDP؟

استخدم UDP حين تكون التوقيت أهم من الاكتمال — الحزمة القديمة المعاد إرسالها أسوأ من عدم وجود حزمة أصلاً:

• بث الفيديو والصوت المباشر — إطار فيديو عمره 200 ملي ثانية لا قيمة له، تجاوزه وأظهر الإطار التالي. يعمل WebRTC (الذي تستخدمه Zoom وGoogle Meet) عبر DTLS/SRTP المبني على UDP.
• ألعاب الفيديو متعددة اللاعبين — تُرسل مواضع اللاعبين عشرات المرات في الثانية. حزمة معادة الإرسال لموضع عمره 50 ملي ثانية ستصل بعد تحديث الموضع الحالي أصلاً.
• DNS — طلب/استجابة أحادي الحزمة يتسع في مخطط بيانات واحد؛ مصافحة TCP ستضاعف وقت البحث.
• DHCP — تهيئة الشبكة قبل تعيين عنوان IP أصلاً.
• بيانات مستشعرات إنترنت الأشياء — قراءة حرارة فائتة مقبولة؛ الحمل المنخفض مهم على الأجهزة المقيدة الموارد.
• QUIC (HTTP/3) — بروتوكول QUIC من Google يعمل على UDP ليتمكن من تنفيذ طبقة موثوقية مضاعفة أكثر ذكاءً دون حجب رأس الصف على مستوى نظام التشغيل كما في TCP.

الأرقام الحقيقية: تكلفة زمن الاستجابة لمصافحة TCP

كل اتصال TCP جديد يدفع مسبقاً RTT واحدة (زمن الذهاب والإياب) على الأقل قبل أن تتدفق البيانات، بالإضافة إلى RTT أخرى لـ TLS إذا استُخدم HTTPS (قلّصت TLS 1.3 هذا إلى RTT واحدة). على رابط عابر للقارات حيث RTT ~100 ملي ثانية:

• مصافحة TCP وحدها: 100 ملي ثانية
• TCP + TLS 1.3: 200 ملي ثانية
• TCP + TLS 1.2 (أقدم): 300 ملي ثانية
• UDP (بلا مصافحة): 0 ملي ثانية للإعداد، الحزمة الأولى تنطلق فوراً

هذا هو السبب في أن تجميع الاتصالات (إعادة استخدام اتصالات TCP) بالغ الأهمية في HTTP/1.1، ولماذا تلغي التعددية في HTTP/2 وHTTP/3 (QUIC) تكلفة إنشاء الاتصال لكل طلب.

النهج الهجين: UDP مع الموثوقية على مستوى التطبيق

تختار أنظمة متطورة أحياناً UDP ثم تُنفّذ فقط الموثوقية التي تحتاجها فعلاً. على سبيل المثال، قد تُرسل لعبة متعددة اللاعبين:

• مواضع اللاعبين عبر UDP — غير موثوق، بلا ترتيب، الفقدان مقبول.
• أحداث اللعبة الحرجة (لاعب مات، عنصر تم التقاطه) عبر نفس مقبس UDP لكن مع مخطط مخصص برقم تسلسلي + تأكيد انتقائي — حد أدنى من الموثوقية لاتساق حالة اللعبة.

هذا التحكم الدقيق مستحيل مع TCP، حيث تحصل على موثوقية شاملة أو لا شيء للتدفق بأكمله.

مبادئ التصميم الأساسية

• افتراض TCP (عبر HTTP/2 أو HTTP/3) لأي خدمة تهمها سلامة البيانات.
• اختر UDP للوسائط في الزمن الحقيقي والألعاب وDNS — حين يكون زمن الاستجابة أهم من الاكتمال.
• تأمّل QUIC/HTTP/3 حين تحتاج موثوقية لكنك تهتم أيضاً بحجب رأس الصف وزمن إنشاء الاتصال.
• لا تجعل "UDP أسرع" هي السبب الوحيد للتبديل — قِس أولاً قيم RTT الفعلية ومعدلات فقدان الحزم في بيئتك.