بروتوكول QUIC: هل سيعوض TCP في المستقبل؟

Sun Ray · 19 فبراير 2025

بسم الله الرحمن الرحيم

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

بروتوكول QUIC: هل سيعوض TCP في المستقبل؟

مقدمة: TCP وأهميته في الشبكات

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

مشاكل TCP:

زمن الانتظار وإعادة الإرسال:

واحد من أكبر عيوب TCP هو زمن الانتظار Latency ، حيث أنه كل مرة يتم إرسال بيانات، لازم المستقبل يرد بتأكيد (ACK). هذا الشيء يضيف وقت إضافي للعملية. المشكلة تزيد تعقيدًا لما تفقد بعض الحزم (Packets)، لأن TCP يضطر يعيد إرسالها كلها من جديد (في بعض الحالات)، مما يؤدي إلى بطء واضح، خاصة في الشبكات المتنقلة مثل 4G و 5G.

ما معناها؟ تخيل أنك تحكي مع صاحبك في الهاتف وكل مرة لازم يقولك "سمعتك" قبل ما تكمل كامل الجملة! معنتها لازم تنتظر حتى يؤكد لك أنه سمعها قبل أن تكمل الجملة! هذا يشبه طريقة عمل TCP، حيث يرسل كل حزمة بيانات وينتظر الرد قبل إرسال المزيد، مما يسبب تأخيرًا كبيرًا.

مشكلة فقدان الحزم:

في HTTP/2 الذي يعتمد على TCP، إذا فقدت حزمة واحدة، تتوقف كل التدفقات (Streams) حتى استرجاع الحزمة، مما يؤدي إلى تأخير في تحميل البيانات. أما في QUIC، كل تدفق مستقل، مما يعني أن فقدان حزمة في تدفق معين لا يؤثر على الآخرين.
كي تضيع حزمة بيانات في الطريق، TCP يمكن يعاود يرسل كلش من جديد! يعني لو كنت تشوف فيديو، ممكن يرجع يرجعلك جزء كامل منه باش يعوض حزمة وحدة ضاعت.

لماذا قلت يمكن يعاود يرسل كلش من جديد ومقلتش لازم؟؟ لأنه مش ديما يعيد إرسال كل شيء، لكن في بعض الحالات ممكن يعاود يرسل مجموعة كبيرة من الحزم، مش فقط وحدة.

كيف يعالج بروتوكول QUIC هذه المشاكل باستخدام UDP؟

Google طورت بروتوكول QUIC لحل هذه المشاكل، بحيث يعتمد على UDP لكنه يضيف ميزات متطورة، مثل:

تقليل زمن الانتظار بإلغاء المفاوضات الطويلة في البداية:

QUIC يوفر ميزة ميزة Zero RTT حيث يسمح بإنشاء اتصال فوري تقريبًا مقارنةً بـ TCP، الذي يتطلب عدة تبادلات قبل أن يبدأ نقل البيانات

TCP+TLS: في كل مرة يفتح المستخدم موقع جديد، لازم TCP يدير Handshake (التفاوض الأولي).
بعده، لازم TLS Handshake (لتأمين الاتصال)، وهذا يزيد التأخير.

النتيجة؟
4 RTT قبل ما تبدأ البيانات الحقيقية في التدفق.

QUIC: يتم دمج التفاوض الأمني (TLS Handshake) مع أول تبادل للبيانات.

النتيجة؟
تخفيض زمن الانتظار إلى 1 RTT فقط، وأحيانًا حتى 0 RTT لو كان فيه اتصال سابق!

إعادة إرسال الحزم الضائعة فقط، بدون إعادة إرسال البيانات الكاملة:

في HTTP/2 مع TCP (الجزء العلوي من الصورة المرفقة بالأسفل):

كل البيانات تمر عبر اتصال واحد (TCP Connection).
إذا ضاعت حزمة واحدة (

)، فإن كل ما بعدها يتوقف حتى يتم إعادة إرسال الحزمة المفقودة، مما يسبب تأخيرًا كبيرًا (Head-of-Line Blocking).

في QUIC (الجزء السفلي من الصورة المرفقة بالأسفل):

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

النتيجة؟

QUIC يتجنب مشكلة "الاختناق عند الرأس" (Head-of-Line Blocking)، مما يجعل تحميل المواقع والتطبيقات أسرع وأكثر سلاسة!

تحسين إدارة الازدحام في الشبكة لضمان استقرار وسرعة أفضل:

عبر آليات تحكم متقدمة تقلل التأخير وفقدان الحزم، مما يحسن أداء التطبيقات التفاعلية والبث المباشر.

مثال لتوضيح الفرق:

عند تحميل صفحة ويب تحتوي على صور ونصوص وجافاسكريبت باستخدام TCP، إذا فقدت إحدى الحزم، فإن المتصفح ينتظر إعادة إرسالها قبل متابعة تحميل باقي العناصر، مما يؤدي إلى تأخير ملحوظ في تحميل الصفحة.

أما مع QUIC، فإن المتصفح يستمر في تحميل باقي العناصر بشكل مستقل، حتى أثناء إعادة إرسال الحزم المفقودة، مما يجعل تصفح المواقع أسرع وأكثر سلاسة، خاصة في الشبكات المزدحمة.

مقارنة بين TCP و QUIC

الميزة	TCP	QUIC
زمن الانتظار	مرتفع بسبب التأكيدات	منخفض لأنه يتجنب المفاوضات الطويلة
فقدان البيانات	يعيد إرسال الحزم الكاملة	يعيد فقط البيانات المفقودة
التشفير	اختياري عبر TLS	مدمج افتراضيًا مع TLS 1.3
الأداء على الشبكات المتنقلة	يحتاج إلى إعادة الاتصال عند تغيير الشبكة	يستمر دون انقطاع

أين يُستخدم QUIC حاليًا؟ HTTP/3 كمثال

بروتوكول HTTP/3 مبني على QUIC، وهذا جعل تصفح المواقع أسرع وأكثر استقرارًا. الشركات الكبرى مثل Google, Cloudflare, وFacebook بدأوا يعتمدوا عليه بشكل رسمي، وهذا يعزز مكانته في المستقبل.
مثال عملي: لما تفتح موقعًا مثل YouTube، يتم تحميل الفيديو باستخدام HTTP/3 الذي يعتمد على QUIC، مما يجعل الفيديو يبدأ في التشغيل بسرعة حتى لو كانت الشبكة غير مستقرة. أما إذا كان يعتمد على TCP، فقد يواجه المستخدم تأخيرات متكررة عند فقدان الاتصال.

مستقبل QUIC: هل سيزيح TCP؟

مع زيادة تبني QUIC في المتصفحات والخوادم، من المحتمل أنه يكون بديلًا حقيقيًا لـ TCP. لكن، هذا ما يعنيش أن TCP راح يختفي بسرعة، بل راح يبقى مستخدمًا في بعض السيناريوهات، على الأقل في السنوات القادمة.

مصادر للتعلم والتعمق في بروتوكول QUIC

للمهتمين بمعرفة المزيد عن QUIC، سواء لفهمه نظريًا أو حتى لتطويره، فهذه بعض المصادر التي قد تساعد:

مراجع رسمية وتقنية:

RFC 9000 - تعريف بروتوكول QUIC
صفحة QUIC الرسمية على موقع Chromium
مجموعة عمل IETF المسؤولة عن تطوير QUIC

مشاريع مفتوحة المصدر لتجربة QUIC عمليًا:

QUICHE - مكتبة QUIC من Cloudflare (بلغة Rust)
ngtcp2 - مكتبة C لتنفيذ QUIC
QUIC-Go - مكتبة Go لتنفيذ QUIC

أوراق بحثية وتقارير أكاديمية:

تحليل أداء QUIC مقابل TCP
ورقة بحثية حول أمان وأداء QUIC

برأيك، هل يمكن أن يصبح بروتوكول QUIC بديلاً كاملاً لـ TCP في المستقبل، أم أن هناك تحديات قد تمنع ذلك؟ ولماذا؟؟

دمتم في حفظ الله ورعايته.

Block user · 19 فبراير 2025

بارك الله فيك على الطرح الرائع
ننتظر جديدك .. تحياتي

Sun Ray · 20 فبراير 2025

ALSLLM قال:
بارك الله فيك على الطرح الرائع
ننتظر جديدك .. تحياتي

وفيك بارك الله

STORM · 20 فبراير 2025

Sun Ray قال:
بسم الله الرحمن الرحيم

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

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

مشاكل TCP:
زمن الانتظار وإعادة الإرسال:
واحد من أكبر عيوب TCP هو زمن الانتظار Latency ، حيث أنه كل مرة يتم إرسال بيانات، لازم المستقبل يرد بتأكيد (ACK). هذا الشيء يضيف وقت إضافي للعملية. المشكلة تزيد تعقيدًا لما تفقد بعض الحزم (Packets)، لأن TCP يضطر يعيد إرسالها كلها من جديد (في بعض الحالات)، مما يؤدي إلى بطء واضح، خاصة في الشبكات المتنقلة مثل 4G و 5G.

وش معناها؟ تخيل أنك تحكي مع صاحبك في الهاتف وكل مرة لازم يقولك "سمعتك" قبل ما تكمل كامل الجملة! معنتها لازم تنتظر حتى يؤكد لك أنه سمعها قبل أن تكمل الجملة! هذا يشبه طريقة عمل TCP، حيث يرسل كل حزمة بيانات وينتظر الرد قبل إرسال المزيد، مما يسبب تأخيرًا كبيرًا.

مشكلة فقدان الحزم:
في HTTP/2 الذي يعتمد على TCP، إذا فقدت حزمة واحدة، تتوقف كل التدفقات (Streams) حتى استرجاع الحزمة، مما يؤدي إلى تأخير في تحميل البيانات. أما في QUIC، كل تدفق مستقل، مما يعني أن فقدان حزمة في تدفق معين لا يؤثر على الآخرين.
كي تضيع حزمة بيانات في الطريق، TCP يمكن يعاود يرسل كلش من جديد! يعني لو كنت تشوف فيديو، ممكن يرجع يرجعلك جزء كامل منه باش يعوض حزمة وحدة ضاعت.

لماذا قلت يمكن يعاود يرسل كلش من جديد ومقلتش لازم؟؟ لأنه مش ديما يعيد إرسال كل شيء، لكن في بعض الحالات ممكن يعاود يرسل مجموعة كبيرة من الحزم، مش فقط وحدة.

كيف يعالج بروتوكول QUIC هذه المشاكل باستخدام UDP؟
Google طورت بروتوكول QUIC لحل هذه المشاكل، بحيث يعتمد على UDP لكنه يضيف ميزات متطورة، مثل:
تقليل زمن الانتظار بإلغاء المفاوضات الطويلة في البداية:
QUIC يوفر ميزة ميزة Zero RTT حيث يسمح بإنشاء اتصال فوري تقريبًا مقارنةً بـ TCP، الذي يتطلب عدة تبادلات قبل أن يبدأ نقل البيانات

مشاهدة المرفق 16823

TCP+TLS: في كل مرة يفتح المستخدم موقع جديد، لازم TCP يدير Handshake (التفاوض الأولي).
بعده، لازم TLS Handshake (لتأمين الاتصال)، وهذا يزيد التأخير.

النتيجة؟
4 RTT قبل ما تبدأ البيانات الحقيقية في التدفق.

QUIC: يتم دمج التفاوض الأمني (TLS Handshake) مع أول تبادل للبيانات.

النتيجة؟
تخفيض زمن الانتظار إلى 1 RTT فقط، وأحيانًا حتى 0 RTT لو كان فيه اتصال سابق!

مشاهدة المرفق 16825

إعادة إرسال الحزم الضائعة فقط، بدون إعادة إرسال البيانات الكاملة:

في HTTP/2 مع TCP (الجزء العلوي من الصورة المرفقة بالأسفل):

كل البيانات تمر عبر اتصال واحد (TCP Connection).
إذا ضاعت حزمة واحدة ()، فإن كل ما بعدها يتوقف حتى يتم إعادة إرسال الحزمة المفقودة، مما يسبب تأخيرًا كبيرًا (Head-of-Line Blocking).

في QUIC (الجزء السفلي من الصورة المرفقة بالأسفل):

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

النتيجة؟

QUIC يتجنب مشكلة "الاختناق عند الرأس" (Head-of-Line Blocking)، مما يجعل تحميل المواقع والتطبيقات أسرع وأكثر سلاسة!

مشاهدة المرفق 16824

تحسين إدارة الازدحام في الشبكة لضمان استقرار وسرعة أفضل:
عبر آليات تحكم متقدمة تقلل التأخير وفقدان الحزم، مما يحسن أداء التطبيقات التفاعلية والبث المباشر.

مثال لتوضيح الفرق:

عند تحميل صفحة ويب تحتوي على صور ونصوص وجافاسكريبت باستخدام TCP، إذا فقدت إحدى الحزم، فإن المتصفح ينتظر إعادة إرسالها قبل متابعة تحميل باقي العناصر، مما يؤدي إلى تأخير ملحوظ في تحميل الصفحة.

أما مع QUIC، فإن المتصفح يستمر في تحميل باقي العناصر بشكل مستقل، حتى أثناء إعادة إرسال الحزم المفقودة، مما يجعل تصفح المواقع أسرع وأكثر سلاسة، خاصة في الشبكات المزدحمة.

مقارنة بين TCP و QUIC

الميزة
TCP
QUIC
زمن الانتظار
مرتفع بسبب التأكيدات
منخفض لأنه يتجنب المفاوضات الطويلة
فقدان البيانات
يعيد إرسال الحزم الكاملة
يعيد فقط البيانات المفقودة
التشفير
اختياري عبر TLS
مدمج افتراضيًا مع TLS 1.3
الأداء على الشبكات المتنقلة
يحتاج إلى إعادة الاتصال عند تغيير الشبكة
يستمر دون انقطاع

أين يُستخدم QUIC حاليًا؟ HTTP/3 كمثال
بروتوكول HTTP/3 مبني على QUIC، وهذا جعل تصفح المواقع أسرع وأكثر استقرارًا. الشركات الكبرى مثل Google, Cloudflare, وFacebook بدأوا يعتمدوا عليه بشكل رسمي، وهذا يعزز مكانته في المستقبل.
مثال عملي: لما تفتح موقعًا مثل YouTube، يتم تحميل الفيديو باستخدام HTTP/3 الذي يعتمد على QUIC، مما يجعل الفيديو يبدأ في التشغيل بسرعة حتى لو كانت الشبكة غير مستقرة. أما إذا كان يعتمد على TCP، فقد يواجه المستخدم تأخيرات متكررة عند فقدان الاتصال.

مستقبل QUIC: هل سيزيح TCP؟
مع زيادة تبني QUIC في المتصفحات والخوادم، من المحتمل أنه يكون بديلًا حقيقيًا لـ TCP. لكن، هذا ما يعنيش أن TCP راح يختفي بسرعة، بل راح يبقى مستخدمًا في بعض السيناريوهات، على الأقل في السنوات القادمة.

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

مراجع رسمية وتقنية:

RFC 9000 - تعريف بروتوكول QUIC
صفحة QUIC الرسمية على موقع Chromium
مجموعة عمل IETF المسؤولة عن تطوير QUIC

مشاريع مفتوحة المصدر لتجربة QUIC عمليًا:

QUICHE - مكتبة QUIC من Cloudflare (بلغة Rust)
ngtcp2 - مكتبة C لتنفيذ QUIC
QUIC-Go - مكتبة Go لتنفيذ QUIC

أوراق بحثية وتقارير أكاديمية:

تحليل أداء QUIC مقابل TCP
ورقة بحثية حول أمان وأداء QUIC

برأيك، هل يمكن أن يصبح بروتوكول QUIC بديلاً كاملاً لـ TCP في المستقبل، أم أن هناك تحديات قد تمنع ذلك؟ ولماذا؟؟

دمتم في حفظ الله ورعايته.

بارك الله فيك وجزاك الله كل خير،

موضوع مهم للأمانة والسؤال عميق
لأن امكانية أن يصبح بروتوكول QUIC بديلاً كاملاً ل TCP في المستقبل؟

الاستبدال بشكل عام يتطلب النظر بعدة اسباب، ومنها؟

الـ TCP يتم استخدامه من عقود طويلة وهذا يعني أن البنية التحتية التي تم صناعتها من Switches,Routers,Firewall's هي مبنية وتم تطويرها لتعمل على TCP كونه هو البروتوكول المعتمد عالمياً.
بينما ال UDP أيضاً يتم استخدامه من عقود طويلة ولكن الفرق بأنه محصور لإستخدامات معيّنة ومحدودة على حسب الحاجة!

ولا ننسى بأن بروتوكول ال UDP هو المنفذ الجميل بعيون هجمات ال DDOS وحتى أن شركة paloaltnetwork قد قامت بحظر هذا البروتوكول QUIC من باب الأمان!

ومع كل العيوب والحسنات الموجودة في كل من ال TCP وال UDP عموماً الا أن ال UDP قد استمد تعريفه التقني من خلال آلية عمله اصلاً، ومع تطوير ال QUIC هذا سوف يُعيدنا الى اعادة تعريف ال UDP وما هي النتائج التي سوف يكون لها الأثر علينا مستقبلاً؟

وأعتقد أن معالم البروتوكول وحل المشاكل الأمنية وغيرها تُكشف مع الأيام.

تحياتي

Deploy SSL Decryption Using Best Practices

Following SSL Decryption deployment best practices help to ensure a smooth, prioritized rollout and that you decrypt the traffic you need to decrypt to safeguard your network.

docs.paloaltonetworks.com

Sun Ray · 20 فبراير 2025

STORM قال:
بارك الله فيك وجزاك الله كل خير،

وفيك بارك الله

STORM قال:
موضوع مهم للأمانة والسؤال عميق
لأن امكانية أن يصبح بروتوكول QUIC بديلاً كاملاً ل TCP في المستقبل؟

الاستبدال بشكل عام يتطلب النظر بعدة اسباب، ومنها؟

الـ TCP يتم استخدامه من عقود طويلة وهذا يعني أن البنية التحتية التي تم صناعتها من Switches,Routers,Firewall's هي مبنية وتم تطويرها لتعمل على TCP كونه هو البروتوكول المعتمد عالمياً.

صح كلامك TCP سيظل مستخدمًا لفترة طويلة بسبب البنية التحتية الحاليةلكن مع ذلك لا يمكن تجاهل التطورات التي يجلبها QUIC خاصة مع تبنيه في HTTP/3 ودعمه من قبل شركات كبرى مثل Google ومع تطور الشبكات والأمان يمكن ان نرى QUIC يفرض نفسه كبروتوكول أساسي للاتصالات الحديثة رغم التحديات الكبيرة للي تواجهه

STORM قال:
بينما ال UDP أيضاً يتم استخدامه من عقود طويلة ولكن الفرق بأنه محصور لإستخدامات معيّنة ومحدودة على حسب الحاجة!

ولا ننسى بأن بروتوكول ال UDP هو المنفذ الجميل بعيون هجمات ال DDOS وحتى أن شركة paloaltnetwork قد قامت بحظر هذا البروتوكول QUIC من باب الأمان!

صح، UDP معروف أنه اقل أمان من TCP لكن QUIC ما يستعمل UDP بطريقة تقليدية
فمثلا يخدم بالتشفير الافتراضي فكل اتصال في QUIC مشفر من البداية باستخدام TLS 1.3 وهذا يخليه ما يحتاج طبقات إضافية كما في TCP مع TLS هذا يخلي البيانات آمنة حتى لو البروتوكول مبني على UDP
كما انه يقدر يتجنب هجمات مثل IP Spoofing ف الQUIC يعتمد على Connection ID في مكان الـ IP والـ Port العاديين، وهذا يساعده في منع بعض انواع الهجمات اللي تعتمد على IP Spoofing فيصعب عليهم التلاعب بالاتصال بسهولة كما هو الحال في UDP العادي.
أيضًا الـ handshake الأولي في QUIC يطلب تأكيد الهوية مما يصعب استغلاله في هجمات التزييف.
QUIC أيضا يمنع استهلاك موارد السيرفر بسهولة كما في TCP لأنه يعتمد على Stateless Retry هذا يخلي السيرفر يقدر يتحقق من هوية العميل قبل ما يحجز له موارد لما يجي طلب اتصال السيرفر يرسل تحدي للعميل وإذا ما جاوب عليه السيرفر ما يخصص له أي موارد وهذا يخلي الهجمات أقل تأثيرا ففي TCP يمكن للمهاجمين إرسال طلبات اتصال واستهلاك موارد السيرفر قبل التأكد من هويتهم لكن QUIC يعالج هذه المشكلة فيطلب السيرفر تأكيد الهوية قبل تخصيص الموارد وهذا يقدر يقلل من تأثير الهجمات لكن من ناحية أخرى QUIC يواجه تحديات مثل صعوبة فحص الحزم Deep Packet Inspection بسبب التشفير الافتراضي وهذا ممكن يخلي بعض الشركات والمؤسسات الأمنية تتردد في اعتماده بسهولة

STORM قال:
ومع كل العيوب والحسنات الموجودة في كل من ال TCP وال UDP عموماً الا أن ال UDP قد استمد تعريفه التقني من خلال آلية عمله اصلاً، ومع تطوير ال QUIC هذا سوف يُعيدنا الى اعادة تعريف ال UDP وما هي النتائج التي سوف يكون لها الأثر علينا مستقبلاً؟

وأعتقد أن معالم البروتوكول وحل المشاكل الأمنية وغيرها تُكشف مع الأيام.

تحياتي

Deploy SSL Decryption Using Best Practices

Following SSL Decryption deployment best practices help to ensure a smooth, prioritized rollout and that you decrypt the traffic you need to decrypt to safeguard your network.

docs.paloaltonetworks.com

تطور QUIC مستمر ومع الوقت يمكن راح نشوف كيف راح تتعامل الشبكات والأمان مع تحدياته
أنا نشوف انه راح يكون عندنا سيناريو التعايش بدل الاستبدال لفترة طويلة لأنه كما تفضلت في تعليقك معظم الشبكات وأجهزة التوجيه والجدران النارية مصممة للتعامل مع TCP فمن غير المتوقع أن يتم استبعاده تماما فأتوقع راح يتم الاستمرار استخدام TCP في بعض الأماكن وQUIC في أخرى حسب الحاجة ربما مع مرور الوقت وزيادة دعم QUIC على مستوى البنية التحتية ممكن نشوفه يسيطر أكثر لكن هذا يحتاج سنوات طويلة وجهود أكثر لسد النقائص وحل المشكلات المتعلقة به
شكرًا على ردك ونقاشك القيم فعلا الموضوع عميق ويستحق التحليل من زوايا متعددة

STORM · 20 فبراير 2025

Sun Ray قال:
وفيك بارك الله

صح كلامك TCP سيظل مستخدمًا لفترة طويلة بسبب البنية التحتية الحاليةلكن مع ذلك لا يمكن تجاهل التطورات التي يجلبها QUIC خاصة مع تبنيه في HTTP/3 ودعمه من قبل شركات كبرى مثل Google ومع تطور الشبكات والأمان يمكن ان نرى QUIC يفرض نفسه كبروتوكول أساسي للاتصالات الحديثة رغم التحديات الكبيرة للي تواجهه

صح، UDP معروف أنه اقل أمان من TCP لكن QUIC ما يستعمل UDP بطريقة تقليدية
فمثلا يخدم بالتشفير الافتراضي فكل اتصال في QUIC مشفر من البداية باستخدام TLS 1.3 وهذا يخليه ما يحتاج طبقات إضافية كما في TCP مع TLS هذا يخلي البيانات آمنة حتى لو البروتوكول مبني على UDP
كما انه يقدر يتجنب هجمات مثل IP Spoofing ف الQUIC يعتمد على Connection ID في مكان الـ IP والـ Port العاديين، وهذا يساعده في منع بعض انواع الهجمات اللي تعتمد على IP Spoofing فيصعب عليهم التلاعب بالاتصال بسهولة كما هو الحال في UDP العادي.
أيضًا الـ handshake الأولي في QUIC يطلب تأكيد الهوية مما يصعب استغلاله في هجمات التزييف.
QUIC أيضا يمنع استهلاك موارد السيرفر بسهولة كما في TCP لأنه يعتمد على Stateless Retry هذا يخلي السيرفر يقدر يتحقق من هوية العميل قبل ما يحجز له موارد لما يجي طلب اتصال السيرفر يرسل تحدي للعميل وإذا ما جاوب عليه السيرفر ما يخصص له أي موارد وهذا يخلي الهجمات أقل تأثيرا ففي TCP يمكن للمهاجمين إرسال طلبات اتصال واستهلاك موارد السيرفر قبل التأكد من هويتهم لكن QUIC يعالج هذه المشكلة فيطلب السيرفر تأكيد الهوية قبل تخصيص الموارد وهذا يقدر يقلل من تأثير الهجمات لكن من ناحية أخرى QUIC يواجه تحديات مثل صعوبة فحص الحزم Deep Packet Inspection بسبب التشفير الافتراضي وهذا ممكن يخلي بعض الشركات والمؤسسات الأمنية تتردد في اعتماده بسهولة

تطور QUIC مستمر ومع الوقت يمكن راح نشوف كيف راح تتعامل الشبكات والأمان مع تحدياته
أنا نشوف انه راح يكون عندنا سيناريو التعايش بدل الاستبدال لفترة طويلة لأنه كما تفضلت في تعليقك معظم الشبكات وأجهزة التوجيه والجدران النارية مصممة للتعامل مع TCP فمن غير المتوقع أن يتم استبعاده تماما فأتوقع راح يتم الاستمرار استخدام TCP في بعض الأماكن وQUIC في أخرى حسب الحاجة ربما مع مرور الوقت وزيادة دعم QUIC على مستوى البنية التحتية ممكن نشوفه يسيطر أكثر لكن هذا يحتاج سنوات طويلة وجهود أكثر لسد النقائص وحل المشكلات المتعلقة به
شكرًا على ردك ونقاشك القيم فعلا الموضوع عميق ويستحق التحليل من زوايا متعددة

كل الل تكلمت عنه صحيح ولا غُبار عليه
لكن عندي ملاحظة بسيطة تجاه ردود فعل أصحاب الشركات تجاه Deep Packet Inspection
الخاصية هاي من أهم خصائص ال Firewall's في كل شركات المزودة وحتى المسوّقة لكل أنواع جدران الحماية.
بالمعنى الأشمل هي أسلوب عمل، يعني ردود فعل أصحاب الشركات رح تكون بالرفض القطعي.

الآن الجدار الناري واقف تماماً عاجزاً عن تحليل هذا ال Packet ف كيف له أن يُميّز إن كان Packet مرغوب به أم مشبوه؟
وهذا فعلاً اللي حصل مع شركة PaloAlt واللي حطيت مصدرها في الأعلى وهذا برضه توضيح للخطوة الخامسة من الاعدادات المخصصة ل Deploy SSL Decryption Using Best Practices حيث أنهم وضحوا ذلك من خلال أن هناك Packets خطيرة قد تدخل الشبكة تحت مُسمى "encrypted traffic"

وفكرة ان Google,Meta,Cloudflare طبقوهم عندهم ف هذول أصلاً اكبر الشبكات العالمية وعندهم شبكات خاصة فيهم ومختبرات تطوير
وزي ما تفضلت، من الصعب الحكم عليه الآن

تحياتي

Sun Ray · 20 فبراير 2025

STORM قال:
كل الل تكلمت عنه صحيح ولا غُبار عليه
لكن عندي ملاحظة بسيطة تجاه ردود فعل أصحاب الشركات تجاه Deep Packet Inspection
الخاصية هاي من أهم خصائص ال Firewall's في كل شركات المزودة وحتى المسوّقة لكل أنواع جدران الحماية.
بالمعنى الأشمل هي أسلوب عمل، يعني ردود فعل أصحاب الشركات رح تكون بالرفض القطعي.

الآن الجدار الناري واقف تماماً عاجزاً عن تحليل هذا ال Packet ف كيف له أن يُميّز إن كان Packet مرغوب به أم مشبوه؟
وهذا فعلاً اللي حصل مع شركة PaloAlt واللي حطيت مصدرها في الأعلى وهذا برضه توضيح للخطوة الخامسة من الاعدادات المخصصة ل Deploy SSL Decryption Using Best Practices حيث أنهم وضحوا ذلك من خلال أن هناك Packets خطيرة قد تدخل الشبكة تحت مُسمى "encrypted traffic"

وفكرة ان Google,Meta,Cloudflare طبقوهم عندهم ف هذول أصلاً اكبر الشبكات العالمية وعندهم شبكات خاصة فيهم ومختبرات تطوير
وزي ما تفضلت، من الصعب الحكم عليه الآن

مشاهدة المرفق 16830

تحياتي

أتفق معك خاصة بخصوص DPI والحزم المشفرة وانا بصراحة نعتقد انو مع الوقت ممكن راح تطلع تقنيات جديدة تخلي تحليل الحزم أسهل حتى لو كانت مشفرة مثلا الذكاء الاصطناعي وتحليل الـ metadata ممكن يقدروا يكشفوا الأنماط الغريبة بدون الحاجة لفك التشفير وحتى الأنظمة الأمنية اعتقد راح تتطور تدريجيا لتواكب تقنيات مثل QUIC فالموضوع ما راح يكون توقف تام بل تطور مستمر واشكرك على النقاش والإضافة القيمة فعلا هالمواضيع تحتاج نقاشات مثل هذي لنفهم الأبعاد المختلفة تحياتي

بروتوكول QUIC: هل سيعوض TCP في المستقبل؟

./عضو جديد