From 8e23ad92b3d56d598e264b55162bb2cc8b020fd7 Mon Sep 17 00:00:00 2001 From: kareem Date: Mon, 8 Sep 2025 08:46:56 +0300 Subject: [PATCH] Add Arabic translations for QUIC and HTTP/3 documentation --- SUMMARY.md | 41 +++++++++++++++++++++++++++++++++++ ar/README.md | 27 +++++++++++++++++++++++ ar/criticism.md | 35 ++++++++++++++++++++++++++++++ ar/feature-handshakes.md | 9 ++++++++ ar/feature-http.md | 7 ++++++ ar/feature-inorder.md | 11 ++++++++++ ar/feature-nonhttp.md | 5 +++++ ar/feature-reliable.md | 7 ++++++ ar/feature-streams.md | 13 +++++++++++ ar/feature-tls.md | 9 ++++++++ ar/feature-trans-app.md | 9 ++++++++ ar/feature-udp.md | 19 ++++++++++++++++ ar/h3-altsvc.md | 19 ++++++++++++++++ ar/h3-h2.md | 31 ++++++++++++++++++++++++++ ar/h3-https.md | 15 +++++++++++++ ar/h3-prio.md | 7 ++++++ ar/h3-push.md | 19 ++++++++++++++++ ar/h3-streams.md | 33 ++++++++++++++++++++++++++++ ar/h3.md | 17 +++++++++++++++ ar/proc-h2.md | 11 ++++++++++ ar/proc-ietf.md | 19 ++++++++++++++++ ar/proc-status.md | 47 ++++++++++++++++++++++++++++++++++++++++ ar/proc.md | 13 +++++++++++ ar/quic-0rtt.md | 5 +++++ ar/quic-api.md | 11 ++++++++++ ar/quic-connections.md | 23 ++++++++++++++++++++ ar/quic-future.md | 27 +++++++++++++++++++++++ ar/quic-spinbit.md | 17 +++++++++++++++ ar/quic-streams.md | 45 ++++++++++++++++++++++++++++++++++++++ ar/quic-tls.md | 7 ++++++ ar/quic-userspace.md | 13 +++++++++++ ar/quic.md | 12 ++++++++++ ar/specs.md | 29 +++++++++++++++++++++++++ ar/the-protocol.md | 9 ++++++++ ar/why-h2.md | 17 +++++++++++++++ ar/why-latency.md | 15 +++++++++++++ ar/why-ossification.md | 21 ++++++++++++++++++ ar/why-quic.md | 13 +++++++++++ ar/why-secure.md | 7 ++++++ ar/why-tcphol.md | 35 ++++++++++++++++++++++++++++++ ar/why-tcpudp.md | 24 ++++++++++++++++++++ 41 files changed, 753 insertions(+) create mode 100644 ar/README.md create mode 100644 ar/criticism.md create mode 100644 ar/feature-handshakes.md create mode 100644 ar/feature-http.md create mode 100644 ar/feature-inorder.md create mode 100644 ar/feature-nonhttp.md create mode 100644 ar/feature-reliable.md create mode 100644 ar/feature-streams.md create mode 100644 ar/feature-tls.md create mode 100644 ar/feature-trans-app.md create mode 100644 ar/feature-udp.md create mode 100644 ar/h3-altsvc.md create mode 100644 ar/h3-h2.md create mode 100644 ar/h3-https.md create mode 100644 ar/h3-prio.md create mode 100644 ar/h3-push.md create mode 100644 ar/h3-streams.md create mode 100644 ar/h3.md create mode 100644 ar/proc-h2.md create mode 100644 ar/proc-ietf.md create mode 100644 ar/proc-status.md create mode 100644 ar/proc.md create mode 100644 ar/quic-0rtt.md create mode 100644 ar/quic-api.md create mode 100644 ar/quic-connections.md create mode 100644 ar/quic-future.md create mode 100644 ar/quic-spinbit.md create mode 100644 ar/quic-streams.md create mode 100644 ar/quic-tls.md create mode 100644 ar/quic-userspace.md create mode 100644 ar/quic.md create mode 100644 ar/specs.md create mode 100644 ar/the-protocol.md create mode 100644 ar/why-h2.md create mode 100644 ar/why-latency.md create mode 100644 ar/why-ossification.md create mode 100644 ar/why-quic.md create mode 100644 ar/why-secure.md create mode 100644 ar/why-tcphol.md create mode 100644 ar/why-tcpudp.md diff --git a/SUMMARY.md b/SUMMARY.md index 0ad7663c..f9ec0753 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -1,3 +1,44 @@ +* [العربية](ar/README.md) + * [ليه QUIC](ar/why-quic.md) + * [فاكر HTTP/2؟](ar/why-h2.md) + * [TCP head of line blocking](ar/why-tcphol.md) + * [TCP ولا UDP](ar/why-tcpudp.md) + * [التجمد](ar/why-ossification.md) + * [آمن](ar/why-secure.md) + * [بيانات أسرع](ar/why-latency.md) + * [العملية](ar/proc.md) + * [IETF](ar/proc-ietf.md) + * [التجربة من HTTP/2](ar/proc-h2.md) + * [الحالة](ar/proc-status.md) + * [ميزات البروتوكول](ar/the-protocol.md) + * [UDP](ar/feature-udp.md) + * [موثوق](ar/feature-reliable.md) + * [Streams متعددة](ar/feature-streams.md) + * [توصيل مرتب](ar/feature-inorder.md) + * [Handshakes سريعة](ar/feature-handshakes.md) + * [TLS 1.3](ar/feature-tls.md) + * [مستوى النقل والتطبيق](ar/feature-trans-app.md) + * [HTTP/3 over QUIC](ar/feature-http.md) + * [Non-HTTP over QUIC](ar/feature-nonhttp.md) + * [إزاي QUIC بيشتغل](ar/quic.md) + * [Connections](ar/quic-connections.md) + * [Connections بتستخدم TLS](ar/quic-tls.md) + * [Streams](ar/quic-streams.md) + * [0-RTT](ar/quic-0rtt.md) + * [Spin Bit](ar/quic-spinbit.md) + * [User-space](ar/quic-userspace.md) + * [API](ar/quic-api.md) + * [HTTP/3](ar/h3.md) + * [HTTPS:// URLs](ar/h3-https.md) + * [Alt-svc](ar/h3-altsvc.md) + * [QUIC streams و HTTP/3](ar/h3-streams.md) + * [Prioritization](ar/h3-prio.md) + * [Server push](ar/h3-push.md) + * [مقارنة بـ HTTP/2](ar/h3-h2.md) + * [النقد العام](ar/criticism.md) + * [المواصفات](ar/specs.md) + * [مستقبل QUIC](ar/quic-future.md) + * [English](en/README.md) * [Why QUIC](en/why-quic.md) * [Remember HTTP/2](en/why-h2.md) diff --git a/ar/README.md b/ar/README.md new file mode 100644 index 00000000..99cb4dea --- /dev/null +++ b/ar/README.md @@ -0,0 +1,27 @@ +# HTTP/3 مشروح + +الكتاب ده اتبدأ في مارس 2018. الهدف منه إننا نوثق HTTP/3 والبروتوكول اللي تحته: QUIC. ليه، إزاي بيشتغلوا، تفاصيل البروتوكول، الإمبليمنتيشن وأكتر. + +الكتاب مجاني تماماً ومعمول عشان يكون جهد تشاركي يقدر يساعد فيه أي حد عايز يساهم. + +## متطلبات أساسية + +القارئ المفروض يكون عنده فهم أساسي لشبكات TCP/IP، أساسيات HTTP والويب. عشان تفهم أكتر عن HTTP/2 بننصحك تقرا الأول التفاصيل في [http2 مشروح](https://daniel.haxx.se/http2/). + +## المؤلف + +الكتاب ده عمله وبدأ فيه [Daniel Stenberg](https://daniel.haxx.se/). دانيال هو مؤسس ومطور [curl](https://curl.haxx.se/)، أكتر سوفتوير HTTP كلايِنت مستخدم في العالم. دانيال اشتغل مع وعلى HTTP وبروتوكولات الإنترنت لأكتر من 20 سنة وهو كاتب [http2 مشروح](https://daniel.haxx.se/http2/). + +## الصفحة الرئيسية + +الصفحة الرئيسية للكتاب ده موجودة على [daniel.haxx.se/http3-explained](https://daniel.haxx.se/http3-explained). + +## ساعدنا + +لو لقيت غلطات أو حاجات ناقصة أو أخطاء في الكتاب ده، يا ريت تبعتلنا نسخة محدثة من الجزء المحتاج تعديل وإحنا هنعدله. هنذكر كل اللي ساعدونا. عايزين نخلي الكتاب ده أحسن مع الوقت. + +الأفضل إنك تبعت [أخطاء](https://github.com/bagder/http3-explained/issues) أو [pull requests](https://github.com/bagder/http3-explained/pulls) على صفحة GitHub بتاعة الكتاب. + +## الرخصة + +الكتاب ده وكل محتواه مرخص تحت [Creative Commons Attribution 4.0 license](https://creativecommons.org/licenses/by/4.0/). \ No newline at end of file diff --git a/ar/criticism.md b/ar/criticism.md new file mode 100644 index 00000000..3441e279 --- /dev/null +++ b/ar/criticism.md @@ -0,0 +1,35 @@ +# النقد + +## UDP مش هيشتغل أبداً + +شركات ومشغلين ومؤسسات كتيرة بتحجب أو تقلل UDP traffic خارج port 53 (المستخدم للDNS) لأنه في الفترة الأخيرة اتساء استخدامه في هجمات. خاصة، بعض بروتوكولات UDP الموجودة وtimplementations الشائعة بتاعتها كانت معرضة لـ amplification attacks حيث مهاجم واحد يقدر يعمل traffic ضخم يروح لضحايا أبرياء. + +QUIC عنده حماية مبنية ضد amplification attacks عن طريق إنه يطلب إن الpacket الأول يكون على الأقل 1200 bytes وبقيد في البروتوكول بيقول إن السيرفر مايقدرش يبعت أكتر من تلات مرات حجم الrequest في الرد من غير ما يستقبل packet من الclient في الرد. + +## UDP بطيء في الkernels + +ده يبدو صحيح، على الأقل في الأول. مانقدرش نقول إزاي ده هيتطور وقد إيه ده ببساطة نتيجة إن أداء UDP transfer مكانش في تركيز المطورين لسنين كتيرة. + +بالنسبة لمعظم الclients، "البطء" ده مش هيتلاحظ أصلاً. + +مثال مصري: فكر في UDP زي طريق جديد لسه متعمل. مش هيكون سريع زي الطريق الدائري اللي اتطور على مدى سنين، بس مع الوقت هيبقى أسرع. + +## QUIC بياخد CPU كتير + +زي ملاحظة "UDP بطيء" فوق، ده جزئياً لأن استخدام TCP و TLS في العالم أخد وقت أطول عشان ينضج ويتحسن ويحصل على مساعدة hardware. + +في أسباب نتوقع ده يتحسن مع الوقت، وإحنا [بنشوف تحسينات في المجال ده](https://www.fastly.com/blog/measuring-quic-vs-tcp-computational-efficiency) فعلاً. السؤال هو قد إيه استخدام CPU الزيادة ده هيضر المستخدمين. + +## ده مجرد Google + +لأ مش كده. Google جابت المواصفة الأولى لـ IETF بعد ما أثبتت، على نطاق إنترنت واسع، إن نشر نوع البروتوكول ده على UDP فعلاً بيشتغل وأداؤه كويس. + +من وقتها، أفراد من عدد كبير من الشركات والمؤسسات اشتغلوا في منظمة IETF الحيادية عشان يعملوا بروتوكول نقل معياري منه. في الشغل ده، موظفين Google شاركوا، بس كمان موظفين من عدد كبير من الشركات التانية المهتمة بتطوير حالة بروتوكولات النقل على الإنترنت، زي Mozilla و Fastly و Cloudflare و Akamai و Microsoft و Facebook و Apple. + +## ده تحسين صغير أوي + +ده مش نقد حقيقي بس رأي. ممكن يكون، وممكن يكون تحسين قليل أوي قريب في الوقت من لما HTTP/2 اتطرح. + +HTTP/3 على الأرجح هيشتغل أحسن بكتير في الشبكات اللي فيها packet loss كتير، بيقدم handshakes أسرع فهيحسن latency المحسوس والحقيقي. بس ده كفاية فوائد عشان يحفز الناس ينشروا دعم HTTP/3 على السيرفرات بتاعتهم وللخدمات بتاعتهم؟ الوقت وقياسات الأداء المستقبلية أكيد هتقول! + +مثال مصري: زي ما تقول "الموبايل ده أحسن بس شوية من اللي عندي، يستاهل أغيره؟" الإجابة تعتمد على قد إيه الفرق مهم ليك ولاستخدامك. \ No newline at end of file diff --git a/ar/feature-handshakes.md b/ar/feature-handshakes.md new file mode 100644 index 00000000..ec86cbbd --- /dev/null +++ b/ar/feature-handshakes.md @@ -0,0 +1,9 @@ +# Handshakes سريعة + +QUIC بيقدم 0-RTT و 1-RTT connection setups، يعني في أحسن الأحوال QUIC مايحتاجش round-trips إضافية أبداً لما يعمل connection جديد. الأسرع من الاتنين، 0-RTT handshake، بس يشتغل لو كان في connection سابق اتعمل للhost ده وسر من الconnection ده متحفظ. + +## البيانات المبكرة + +QUIC بيسمح للclient إنه يحط بيانات في 0-RTT handshake. الميزة دي بتسمح للclient يوصل بيانات للطرف التاني أسرع ما يمكن، وده بالطبع بيسمح للسيرفر يرد ويبعت بيانات أسرع حتى. + +مثال مصري: فكر في الموضوع زي إنك تكلم صاحبك اللي بتكلمه كل يوم. مش محتاج تقوله "أهلاً أنا فلان" - تقدر تبدأ الكلام على طول (0-RTT). بس لو تكلم واحد مش تعرفه، لازم تعرف بنفسك الأول (1-RTT). \ No newline at end of file diff --git a/ar/feature-http.md b/ar/feature-http.md new file mode 100644 index 00000000..30810378 --- /dev/null +++ b/ar/feature-http.md @@ -0,0 +1,7 @@ +## HTTP/3 over QUIC + +طبقة HTTP، المسماة HTTP/3، بتعمل نقل HTTP-style، متضمنة ضغط HTTP header باستخدام QPACK - اللي شبيه لضغط HTTP/2 المسمى HPACK. + +خوارزمية HPACK بتعتمد على توصيل *مرتب* للstreams فمكانش ممكن إعادة استخدامها لـ HTTP/3 من غير تعديلات لأن QUIC بيقدم streams ممكن توصل out of order. QPACK ممكن يتشاف كنسخة HPACK المتكيفة مع QUIC. + +مثال مصري: فكر في HPACK زي نظام ترقيم الصفحات في كتاب - لازم تيجي بالترتيب عشان تفهم. QPACK زي نظام ترقيم الفصول - كل فصل منفصل ومفهوم لوحده حتى لو وصل قبل اللي قبله. \ No newline at end of file diff --git a/ar/feature-inorder.md b/ar/feature-inorder.md new file mode 100644 index 00000000..0a8d909c --- /dev/null +++ b/ar/feature-inorder.md @@ -0,0 +1,11 @@ +## ‎توصيل مرتب + +QUIC بيضمن in-order delivery للstreams، بس مش بين الstreams. ده يعني إن كل stream هيبعت بيانات ويحافظ على ترتيب البيانات، بس كل stream ممكن يوصل للمقصد بترتيب مختلف عن اللي الapplication بعته! + +مثلاً: stream A و B بيتنقلوا من سيرفر لclient. Stream A يبدأ الأول وبعدين stream B. في QUIC، packet ضائع بيأثر بس على الstream اللي الpacket الضائع ينتمي له. لو stream A فقد packet بس stream B مفقدش، stream B ممكن يكمل نقله ويخلص بينما stream A الpacket الضائع بتاعه يتبعت تاني. ده مكانش ممكن مع HTTP/2. + +مرسوم هنا بstream أصفر وstream أزرق متبعتين بين اتنين QUIC end-points على connection واحد. هما مستقلين وممكن يوصلوا بترتيب مختلف، بس كل stream بيوصل للapplication بشكل موثوق مرتب. + +مثال مصري: فكر في الموضوع زي إنك طلبت وجبتين مختلفتين من مطعمين مختلفين (streamين). لو الطلب الأول اتأخر، الطلب التاني ممكن يوصل الأول ومتستناش الأول. بس كل طلب جوا نفسه مرتب - الفراخ قبل الرز قبل السلطة. + +![two QUIC streams between two computers](../images/quic-chain-streams.png) \ No newline at end of file diff --git a/ar/feature-nonhttp.md b/ar/feature-nonhttp.md new file mode 100644 index 00000000..29c3a2c5 --- /dev/null +++ b/ar/feature-nonhttp.md @@ -0,0 +1,5 @@ +## Non-HTTP over QUIC + +الشغل على إرسال بروتوكولات غير HTTP على QUIC اتأجل لحد بعد ما QUIC version 1 يتشحن. + +مثال مصري: فكر في الموضوع زي إنهم ركزوا على تشغيل السكة الحديد للقطر الأساسي الأول، والخطوط الفرعية (البروتوكولات التانية) هتتعمل لما الخط الأساسي يشتغل صح. \ No newline at end of file diff --git a/ar/feature-reliable.md b/ar/feature-reliable.md new file mode 100644 index 00000000..84126984 --- /dev/null +++ b/ar/feature-reliable.md @@ -0,0 +1,7 @@ +## ‎نقل بيانات موثوق + +بينما UDP مش نقل موثوق، QUIC بيضيف طبقة على UDP بتقدم الموثوقية. بيقدم إعادة إرسال الpackets، congestion control، pacing والميزات التانية الموجودة في TCP. + +البيانات المبعوتة على QUIC من endpoint واحد هتظهر في الطرف التاني عاجلاً أو آجلاً، طالما الconnection متحافظ عليه. + +مثال مصري: فكر في UDP زي البريد العادي - سريع بس مش مضمون الوصول. QUIC بيضيف عليه خدمة "التوصيل المضمون" - بيتأكد إن الجواب وصل، ولو مووصلش يبعته تاني، زي البريد المسجل بس أسرع. \ No newline at end of file diff --git a/ar/feature-streams.md b/ar/feature-streams.md new file mode 100644 index 00000000..830d9726 --- /dev/null +++ b/ar/feature-streams.md @@ -0,0 +1,13 @@ +## ‎Streams متعددة جوا الconnections + +زي SCTP و SSH و HTTP/2، QUIC عنده streams منطقية منفصلة جوا الconnections الفيزيائية. عدد من الstreams المتوازية اللي تقدر تنقل بيانات في نفس الوقت على connection واحد من غير ما تأثر على الstreams التانية. + +Connection هو setup متفاوض عليه بين نقطتين زي ما TCP connection بيشتغل. QUIC connection بيتعمل لـ UDP port و IP address، بس بعد ما يتعمل الconnection بيتربط بـ "connection ID" بتاعه. + +على connection متعمل، أي ناحية تقدر تعمل streams وتبعت بيانات للناحية التانية. Streams بتوصل in-order وهي reliable، بس streams مختلفة ممكن توصل out-of-order. + +QUIC بيقدم flow control على الconnection والstreams. + +شوف تفاصيل أكتر في أجزاء [connections](quic-connections.md) و [streams](quic-streams.md) + +مثال مصري: فكر في QUIC زي بناية فيها شقق كتيرة (streams). كل شقة (stream) مستقلة عن التانية - لو واحدة فيها مشكلة، باقي الشقق تشتغل عادي. بس كلها في نفس البناية (connection الواحد). \ No newline at end of file diff --git a/ar/feature-tls.md b/ar/feature-tls.md new file mode 100644 index 00000000..02c0ece6 --- /dev/null +++ b/ar/feature-tls.md @@ -0,0 +1,9 @@ +## TLS 1.3 + +أمان النقل المستخدم في QUIC بيستخدم TLS 1.3 ([RFC 8446](https://tools.ietf.org/html/rfc8446)) ومافيش أبداً أي QUIC connections غير مشفرة. + +TLS 1.3 عنده مميزات عدة مقارنة بنسخ TLS الأقدم بس السبب الأساسي لاستخدامه في QUIC إن 1.3 غير الhandshake عشان يحتاج roundtrips أقل. بيقلل protocol latency. + +نسخة Google القديمة من QUIC استخدمت crypto مخصوص. + +مثال مصري: فكر في TLS 1.3 زي نظام الأمان الجديد في البنوك - أسرع وأقوى من الأنظمة القديمة. بدل ما تاخد 3 خطوات عشان تتأكد من هويتك، الجديد ياخد خطوة أو اتنين بس ويبقى أآمن برضو. \ No newline at end of file diff --git a/ar/feature-trans-app.md b/ar/feature-trans-app.md new file mode 100644 index 00000000..5edd424b --- /dev/null +++ b/ar/feature-trans-app.md @@ -0,0 +1,9 @@ +## مستوى النقل والتطبيق + +بروتوكول IETF QUIC بروتوكول نقل، يقدر يتستخدم فوقه بروتوكولات طبقة application تانية. بروتوكول application layer الأولي هو HTTP/3 (h3). + +طبقة النقل بتدعم connections و streams. + +نسخة Google القديمة من QUIC كان النقل و HTTP ملزقين مع بعض في واحد single do-it-all وكان أكتر special-purpose send-http/2-frames-over-udp protocol. + +مثال مصري: فكر في QUIC زي شاحنة نقل (transport) تقدر تحمل حاجات مختلفة. HTTP/3 زي البضاعة اللي راكبة عليها. النسخة القديمة من Google كانت زي عربية مخصوصة للخضار بس، النسخة الجديدة زي شاحنة تقدر تشيل أي حاجة. \ No newline at end of file diff --git a/ar/feature-udp.md b/ar/feature-udp.md new file mode 100644 index 00000000..e4bdff74 --- /dev/null +++ b/ar/feature-udp.md @@ -0,0 +1,19 @@ +## بروتوكول نقل على UDP + +QUIC هو بروتوكول نقل مطبق على UDP. لو راقبت network traffic بتاعك عادي، هتشوف QUIC يظهر كـ UDP packets. + +بناءً على UDP، بيستخدم برضو UDP port numbers عشان يعرف خدمات الشبكة المحددة على IP address معين. + +كل implementations QUIC المعروفة حالياً في user-space، وده بيسمح بتطور أسرع من implementations kernel-space عادة. + +## هيشتغل؟ + +في شركات وإعدادات شبكة تانية بتحجب UDP traffic على ports غير 53 (المستخدم للDNS). غيرها بيقلل البيانات دي بطريقة تخلي QUIC يشتغل أسوأ من بروتوكولات TCP. مافيش نهاية لاللي بعض المشغلين ممكن يعملوه. + +في المستقبل المنظور، كل استخدام لـ QUIC-based transports على الأرجح هيكون لازم يقدر يرجع بلطف لبديل تاني (TCP-based). مهندسين Google قالوا قبل كده إن معدلات الفشل المقاسة في نسب مئوية single-digit قليلة. + +مثال مصري: فكر في QUIC زي خدمة دليفري جديدة. في مناطق معينة ممكن متكونش متاحة أو تبقى بطيئة، فلازم يكون عندك خطة بديلة زي الطلب العادي من المحل. + +## هيتحسن؟ + +الاحتمالات إن لو QUIC أثبت إنه إضافة قيمة لعالم الإنترنت، الناس هتعوز تستخدمه وهتعوزه يشتغل في شبكاتها وساعتها الشركات ممكن تبدأ تعيد النظر في العقبات بتاعتها. خلال السنين اللي تطوير QUIC تقدم فيها، معدل نجاح إنشاء واستخدام QUIC connections على الإنترنت زاد. \ No newline at end of file diff --git a/ar/h3-altsvc.md b/ar/h3-altsvc.md new file mode 100644 index 00000000..8966f86a --- /dev/null +++ b/ar/h3-altsvc.md @@ -0,0 +1,19 @@ +# Alt-svc + +alternate service (Alt-svc:) header والـ `ALT-SVC` HTTP/2 frame المقابل له مش مصممين خصوصاً لـ QUIC أو HTTP/3. هما جزء من آلية مصممة ومعمولة فعلاً لسيرفر يقول للclient: *"شوف، أنا بشغل نفس الخدمة على HOST ده باستخدام PROTOCOL ده على PORT ده"*. شوف التفاصيل في [RFC 7838](https://tools.ietf.org/html/rfc7838). + +Client يستقبل Alt-svc response زي ده ساعتها مُستحسن، لو بيدعم وعايز، يتصل بالhost التاني ده بالتوازي في الbackground - باستخدام البروتوكول المحدد - ولو نجح ينقل عملياته لده بدلاً من الconnection الأولي. + +لو الconnection الأولي بيستخدم HTTP/2 أو حتى HTTP/1، السيرفر يقدر يرد ويقول للclient إنه يقدر يتصل تاني ويجرب HTTP/3. ممكن يكون لنفس الhost أو لhost تاني يعرف إزاي يخدم origin ده. المعلومات المديمة في Alt-svc response زي ده عندها expiry timer، بتخلي clients قادرة توجه connections وrequests تالية مباشرة للhost البديل باستخدام البروتوكول البديل المقترح، لفترة معينة. + +## مثال + +HTTP server يحط `Alt-Svc:` header في رده: + + Alt-Svc: h3=":50781" + +ده بيدل إن HTTP/3 متاح على UDP port 50781 في نفس host name اللي اتستخدم عشان نجيب الرد ده. + +Client ساعتها يقدر يحاول يعمل QUIC connection للمقصد ده ولو نجح، يكمل يتواصل مع origin زي كده بدلاً من نسخة HTTP الأولية. + +مثال مصري: فكر في Alt-svc زي لافتة في محطة القطر بتقولك "في قطر أسرع على الرصيف التاني". انت ممكن تكمل بالقطر اللي راكبه، أو تنزل وتركب الأسرع. السيرفر بيقولك "في HTTP/3 أسرع على port تاني" وانت تختار. \ No newline at end of file diff --git a/ar/h3-h2.md b/ar/h3-h2.md new file mode 100644 index 00000000..ab935144 --- /dev/null +++ b/ar/h3-h2.md @@ -0,0 +1,31 @@ +# HTTP/3 مقارنة بـ HTTP/2 + +HTTP/3 مصمم لـ QUIC، اللي هو بروتوكول نقل بيتعامل مع streams بنفسه. + +HTTP/2 مصمم لـ TCP، وعلشان كده بيتعامل مع streams في طبقة HTTP. + +## أوجه الشبه + +البروتوكولين بيقدموا للclients نفس مجموعة الميزات تقريباً. + +- البروتوكولين بيقدموا دعم server push + +- البروتوكولين عندهم header compression، و QPACK و HPACK شبيهين في التصميم. + +- البروتوكولين بيقدموا multiplexing على connection واحد باستخدام streams + +## الاختلافات + +الاختلافات في التفاصيل وأساساً موجودة بسبب استخدام HTTP/3 لـ QUIC: + +- HTTP/3 عنده دعم early data أحسن وأكتر احتمالاً إنه يشتغل بفضل QUIC's 0-RTT handshakes، بينما TCP Fast Open و TLS عادة يبعتوا بيانات أقل وكتير يواجهوا مشاكل. + +- HTTP/3 عنده handshakes أسرع بكتير بفضل QUIC مقابل TCP + TLS. + +- HTTP/3 مايوجدش في نسخة غير آمنة أو غير مشفرة. HTTP/2 يقدر يتطبق ويتستخدم من غير HTTPS - حتى لو ده نادر على الإنترنت. + +- HTTP/2 يقدر يتفاوض مباشرة في TLS handshake مع ALPN extension، بينما HTTP/3 على QUIC فهو محتاج `Alt-Svc:` header response الأول عشان يعلم الclient بالحقيقة دي. + +- مواصفة HTTP/3 الأساسية مابتعرفش prioritization بنفسها. طريقة HTTP/2 لل prioritization اتشافت معقدة أوي ومهجورة بواسطة آخر مراجعة لمواصفة HTTP/2 [RFC 9113](https://www.rfc-editor.org/rfc/rfc9113.html). بديل أبسط، Extensible Prioritization Scheme لـ HTTP ([RFC 9218](https://www.rfc-editor.org/rfc/rfc9218.html))، اتنشر منفصل، ويقدر يتستخدم في HTTP/2 و HTTP/3. + +مثال مصري: فكر في HTTP/2 زي الأتوبيس الحديث (أحسن من القديم بس لسه على طرق عادية)، وHTTP/3 زي المترو (نفس الخدمة تقريباً بس على سكة حديد أسرع وأكتر كفاءة). \ No newline at end of file diff --git a/ar/h3-https.md b/ar/h3-https.md new file mode 100644 index 00000000..698cfff5 --- /dev/null +++ b/ar/h3-https.md @@ -0,0 +1,15 @@ +# HTTPS:// URLs + +HTTP/3 هيتعمل باستخدام `HTTPS://` URLs. العالم مليان URLs زي دي واتشاف إن ده غير عملي ومش منطقي خالص إن نقدم URL scheme تاني للبروتوكول الجديد. زي ما HTTP/2 مكانش محتاج scheme جديد، HTTP/3 برضو مش محتاج. + +التعقيد المضاف في موقف HTTP/3 بقى إن حيث HTTP/2 كان طريقة جديدة تماماً لنقل HTTP على الشبكة، لسه كان مبني على TLS و TCP زي HTTP/1. حقيقة إن HTTP/3 بيتعمل على QUIC بيغير الحاجات في جوانب مهمة شوية. + +Legacy، clear-text، `HTTP://` URLs هتسيب زي ما هي ولما نكمل أكتر في مستقبل فيه نقل آمن أكتر، على الأرجح هتقل استخداماً أكتر وأكتر. الطلبات للURLs زي دي ببساطة مش هتتطور لاستخدام HTTP/3. في الواقع نادراً ما بتتطور لـ HTTP/2، بس لأسباب تانية. + +## الاتصال الأولي + +الاتصال الأول لhost جديد، مش متزار قبل كده لـ HTTPS:// URL على الأرجح لازم يتعمل على TCP (ممكن بالإضافة لمحاولة متوازية للاتصال عن طريق QUIC). الhost ممكن يكون سيرفر قديم من غير دعم QUIC أو ممكن يكون في middle box بين الاتنين بيعمل عوائق تمنع QUIC connection ينجح. + +Client وserver حديثين على الأرجح يتفاوضوا على HTTP/2 في أول handshake. لما الconnection يتعمل والسيرفر يرد على HTTP request من الclient، السيرفر يقدر يقول للclient عن دعمه وتفضيله لـ HTTP/3. + +مثال مصري: فكر في الموضوع زي إنك تروح مطعم جديد. أول زيارة ممكن تطلب من المنيو العادي (HTTP/2 على TCP)، بس النادل ممكن يقولك "عندنا منيو جديد أسرع وأحسن" (HTTP/3 على QUIC). المرة الجاية هتطلب من المنيو الجديد على طول. \ No newline at end of file diff --git a/ar/h3-prio.md b/ar/h3-prio.md new file mode 100644 index 00000000..c035e2b7 --- /dev/null +++ b/ar/h3-prio.md @@ -0,0 +1,7 @@ +# HTTP/3 Prioritization + +مواصفة HTTP/3 الأساسية مابتعرفش prioritization بنفسها. طريقة HTTP/2 لل prioritization اتشافت معقدة أوي ومهجورة بواسطة آخر مراجعة لمواصفة HTTP/2 [RFC 9113](https://www.rfc-editor.org/rfc/rfc9113.html). بديل أبسط، Extensible Prioritization Scheme لـ HTTP ([RFC 9218](https://www.rfc-editor.org/rfc/rfc9218.html))، اتنشر منفصل، ويقدر يتستخدم في HTTP/2 و HTTP/3. + +في HTTP/3، إشارات priority بتتبعت في شكل Priority header field و/أو PRIORITY_UPDATE frame متبعت على HTTP/3 Control Stream. السيرفرات تقدر تتعامل مع الإشارات دي عشان تجدول إرسال محتوى HTTP response. [RFC 9218](https://www.rfc-editor.org/rfc/rfc9218.html) بيقدم scheduling guidance مقصود إنه يحسن أداء تطبيق الويب للclient. + +مثال مصري: فكر في prioritization زي نظام الأولويات في المستشفى. الطوارئ لها أولوية أعلى من الكشف العادي. HTTP/3 بيقول للسيرفر إيه الأهم يوصل الأول - الصور المهمة في الصفحة ولا الإعلانات في الجنب. \ No newline at end of file diff --git a/ar/h3-push.md b/ar/h3-push.md new file mode 100644 index 00000000..701f248a --- /dev/null +++ b/ar/h3-push.md @@ -0,0 +1,19 @@ +# HTTP/3 Server push + +HTTP/3 server push شبيه باللي مشروح في HTTP/2 ([RFC 7540](https://httpwg.org/specs/rfc7540.html))، بس بيستخدم آليات مختلفة. + +server push فعلياً هو رد على request إن الclient مابعتوش أبداً! + +Server pushes مسموح بس لو الclient وافق عليها. في HTTP/3 الclient حتى بيحط حد لكام push يقبل عن طريق إنه يعلم السيرفر إيه أقصى push stream ID. تخطي الحد ده هيسبب connection error. + +لو السيرفر اعتبر إنه على الأرجح الclient عايز resource إضافي ماطلبوش بس المفروض يكون عنده، يقدر يبعت `PUSH_PROMISE` frame (على request stream) يوري الrequest إيه شكله إن الpush ده رد عليه، وبعدين يبعت الرد الحقيقي على stream جديد. + +حتى لما pushes اتقالت إنها مقبولة من الclient من قبل، كل pushed stream منفرد لسه ممكن يتلغي في أي وقت لو الclient شاف ده مناسب. ساعتها يبعت `CANCEL_PUSH` frame للسيرفر. + +## مشكوك فيه + +من لما الميزة دي اتناقشت أول مرة في تطوير HTTP/2 وبعدين لما البروتوكول اتشحن واتنشر على الإنترنت، الميزة دي اتناقشت واتكرهت واتخبطت بطرق كتيرة مختلفة عشان تبقى مفيدة. + +الpushing مش أبداً "مجاني"، لأنه رغم إنه بيوفر نص round-trip لسه بيستخدم bandwidth. صعب أو مستحيل للserver-side إنه فعلاً يعرف بمستوى عالي من اليقين لو resource لازم يتpush ولا لأ. + +مثال مصري: فكر في server push زي النادل في المطعم اللي يقولك "هجيبلك سلطة مع الأكل" قبل ما تطلبها. ممكن تعجبك (توفر وقت) أو ممكن متعجبكش (مش عايزها وهتدفع فيها). صعب النادل يخمن صح كل مرة. \ No newline at end of file diff --git a/ar/h3-streams.md b/ar/h3-streams.md new file mode 100644 index 00000000..086b4a51 --- /dev/null +++ b/ar/h3-streams.md @@ -0,0 +1,33 @@ +# QUIC streams و HTTP/3 + +HTTP/3 مصمم لـ QUIC فهو بيستغل streams بتاع QUIC بالكامل، بينما HTTP/2 كان لازم يصمم مفهوم stream و multiplexing بتاعه بنفسه على TCP. + +طلبات HTTP المعمولة على HTTP/3 بتستخدم مجموعة محددة من streams. + +## HTTP/3 frames + +HTTP/3 يعني إعداد QUIC streams وإرسال مجموعة من frames للطرف التاني. في عدد قليل ثابت (فعلاً تسعة في 18 ديسمبر 2018!) من frames المعروفة في HTTP/3. الأهم فيها على الأرجح: + +- HEADERS، اللي بيبعت HTTP headers مضغوطة +- DATA، بيبعت محتويات بيانات binary +- GOAWAY، من فضلك اقفل الconnection ده + +## HTTP Request + +الclient بيبعت HTTP request بتاعه على *bidirectional* QUIC stream مبدوء من الclient. + +الrequest يتكون من HEADERS frame واحد وممكن اختيارياً يتبعه frame واحد أو اتنين تانيين: سلسلة من DATA frames وممكن HEADERS frame أخير للtrailers. + +بعد بعت request، الclient بيقفل الstream للإرسال. + +## HTTP Response + +السيرفر بيبعت HTTP response بتاعه على bidirectional stream. HEADERS frame، سلسلة من DATA frames وممكن HEADERS frame أخير. + +مثال مصري: فكر في HTTP/3 streams زي نظام الأرقام في البنك. كل عميل (client) ياخد رقم (stream) ويبعت طلبه (request) للموظف، والموظف (server) يرد عليه على نفس الرقم (response). لكن عكس البنك، ممكن عدة عملاء يتكلموا مع الموظف في نفس الوقت على أرقام مختلفة. + +## QPACK headers + +HEADERS frames بتحتوي على HTTP headers مضغوطة باستخدام خوارزمية QPACK. QPACK شبيه في الأسلوب لضغط HTTP/2 المسمى HPACK ([RFC 7541](https://httpwg.org/specs/rfc7541.html))، بس متعدل عشان يشتغل مع streams موصلة out of order. + +QPACK نفسه بيستخدم اتنين إضافيين unidirectional QUIC streams بين النقطتين. بيتستخدموا لحمل معلومات dynamic table في أي اتجاه. \ No newline at end of file diff --git a/ar/h3.md b/ar/h3.md new file mode 100644 index 00000000..abfca222 --- /dev/null +++ b/ar/h3.md @@ -0,0 +1,17 @@ +# HTTP/3 + +زي ما قلنا قبل كده، أول وأهم بروتوكول يتنقل على QUIC هو HTTP. + +زي ما HTTP/2 اتقدم قبل كده عشان ينقل HTTP على الشبكة بطريقة جديدة خالص، HTTP/3 برضو بيقدم طريقة جديدة تاني عشان يبعت HTTP على الشبكة. + +HTTP لسه محتفظ بنفس المفاهيم والأفكار زي زمان. لسه في headers و body، لسه في request و response. لسه في verbs و cookies و caching. اللي بيتغير في HTTP/3 بشكل أساسي هو إزاي البيانات بتتبعت للطرف التاني في التواصل. + +عشان نعمل HTTP على QUIC، كان لازم تغييرات والنتيجة دي هي اللي إحنا بنسميها دلوقتي HTTP/3. التغييرات دي كانت ضرورية بسبب الطبيعة المختلفة اللي QUIC بيوفرها مقارنة بـ TCP. التغييرات دي تشمل: + +- في QUIC الـ streams بيوفرها الـ transport نفسه، بينما في HTTP/2 الـ streams كانت بتتعمل جوا طبقة HTTP. + +- بسبب إن الـ streams مستقلة عن بعض، بروتوكول ضغط الـ headers المستخدم في HTTP/2 مكانش ينفع يتستعمل من غير ما يسبب مشكلة head of block. + +- QUIC streams مختلفة شوية عن HTTP/2 streams. جزء HTTP/3 هيوضح ده أكتر. + +مثال مصري: فكر في الموضوع زي مطعم فيه طباخين كتير. HTTP/2 كان زي إنك تطلب كله على طباخ واحد - لو عطل في طبق واحد، كل الطلبات تتأخر. HTTP/3 زي إنك تطلب كل طبق من طباخ مختلف - لو طبق اتأخر، باقي الأطباق تتجهز عادي. \ No newline at end of file diff --git a/ar/proc-h2.md b/ar/proc-h2.md new file mode 100644 index 00000000..9d265493 --- /dev/null +++ b/ar/proc-h2.md @@ -0,0 +1,11 @@ +## التجربة من HTTP/2 + +مواصفة HTTP/2 RFC 7540 اتنشرت في مايو 2015، بس شهر قبل ما QUIC يجي لـ IETF لأول مرة. + +مع HTTP/2، الأساس لتغيير HTTP على الشبكة اتوضع وفريق العمل اللي عمل HTTP/2 كان فعلاً بعقلية إن ده هيساعد iteration لنسخ HTTP جديدة أسرع بكتير من اللي أخده الوصول لنسخة 2 من نسخة 1 (حوالي 16 سنة). + +مع HTTP/2، المستخدمين و software stacks اتعودوا على فكرة إن HTTP مايقدرش يتفترض إنه يتعمل ببروتوكول نص-based بطريقة serial. + +HTTP-over-QUIC (HTTP/3) بيبني على HTTP/2 ويتبع مفاهيم كتيرة نفسها بس بينقل بعض التفاصيل من طبقة HTTP لأنها متغطاة بواسطة QUIC. + +مثال مصري: فكر في HTTP/2 زي إنه علم الناس إن النقل ممكن يكون أسرع من العربيات العادية (HTTP/1) باستخدام الأتوبيس (multiplexing). HTTP/3 أخد الدرس ده وقال "طب ماهو ممكن نستخدم المترو بدل الأتوبيس ونبقى أسرع أكتر". \ No newline at end of file diff --git a/ar/proc-ietf.md b/ar/proc-ietf.md new file mode 100644 index 00000000..1274ee63 --- /dev/null +++ b/ar/proc-ietf.md @@ -0,0 +1,19 @@ +## IETF + +فريق عمل QUIC اللي اتعمل عشان يعاير البروتوكول جوا IETF قرر بسرعة إن بروتوكول QUIC لازم يقدر ينقل بروتوكولات غير HTTP "بس". Google-QUIC ماقولش نقل HTTP - عملياً نقل اللي كان فعلاً HTTP/2 frames، باستخدام HTTP/2 frame syntax. + +اتقال كمان إن IETF-QUIC لازم يبني التشفير والأمان بتاعه على TLS 1.3 بدلاً من الطريقة "المخصوصة" المستخدمة بواسطة Google-QUIC. + +عشان نلبي طلب send-more-than-HTTP، معمارية بروتوكول IETF QUIC اتقسمت لطبقتين منفصلتين: transport QUIC والطبقة "HTTP over QUIC" - اللي اتسمت HTTP/3 في نوفمبر 2018. + +انقسام الطبقات ده، رغم إنه ممكن يبدو مش مضر، خلى IETF-QUIC يختلف كتير عن Google-QUIC الأصلي. + +فريق العمل قرر بسرعة إنه عشان يحصل على التركيز المناسب والقدرة على تسليم QUIC version 1 في الوقت، هيركز على تسليم HTTP، وسيب non-HTTP transports لشغل أد بعدين. + +في مارس 2018 لما بدأنا نشتغل على الكتاب ده، الخطة كانت نشحن المواصفة النهائية لـ QUIC version 1 في نوفمبر 2018 بس ده اتأجل مرات عدة. بروتوكول IETF QUIC اتعاير واتنشر في مايو 2021 كـ [RFC 9000](https://www.rfc-editor.org/rfc/rfc9000.html). + +بينما الشغل على IETF-QUIC تقدم، فريق Google أدمج تفاصيل من نسخة IETF وبدأ يطور نسختهم من البروتوكول ببطء ناحية اللي نسخة IETF ممكن تبقى. Google فضلت تستخدم نسختها من QUIC في متصفحها وخدماتها. + +[معظم implementations الجديدة تحت التطوير](https://github.com/quicwg/base-drafts/wiki/Implementations) قررت تركز على نسخة IETF ومش متوافقة مع نسخة Google. + +مثال مصري: فكر في الموضوع زي إنك اخترعت وصفة أكل (Google-QUIC) وبقيت مشهورة. بعدين اللجنة الرسمية للطبخ (IETF) أخدت الوصفة وعدلت فيها شوية عشان تبقى معيار عالمي. النتيجة: في نسختين - الأصلية (Google) والرسمية (IETF) - والناس دلوقتي بيتبعوا الرسمية أكتر. \ No newline at end of file diff --git a/ar/proc-status.md b/ar/proc-status.md new file mode 100644 index 00000000..727eed80 --- /dev/null +++ b/ar/proc-status.md @@ -0,0 +1,47 @@ +# الحالة + +فريق عمل QUIC اشتغل بشراسة من أواخر 2016 على تحديد البروتوكولات وبيقرب من المراحل النهائية وقت الكتابة (يونيو 2020). + +خلال 2019 و 2020 كان في عدد متزايد من [اختبارات التشغيل المتبادل مع HTTP/3](https://docs.google.com/spreadsheets/d/1D0tW89vOoaScs3IY9RGC0UesWGAwE6xyLk0l4JtvTVg) و CDNs و Browsers بدأت تطلق دعم أولي - رغم إنه غالباً وراء flags. + +في عدد من [implementations QUIC مختلفة مدرجة](https://github.com/quicwg/base-drafts/wiki/Implementations) في صفحات wiki فرق عمل QUIC. + +تطبيق QUIC مش سهل والبروتوكول فضل يتحرك ويتغير حتى التاريخ ده. + +## Servers + +دعم NGINX لـ QUIC و HTTP/3 تحت التطوير و [نسخة preview اتعلنت](https://www.nginx.com/blog/introducing-technology-preview-nginx-support-for-quic-http-3/). + +مكانش في تصريحات عامة من ناحية دعم QUIC من Apache. + +## Clients + +مافيش من vendors المتصفحات الكبيرة شحن أي نسخة، في أي حالة، تقدر تشغل نسخة IETF من QUIC أو HTTP/3. + +Google Chrome شحن بـ implementation شغال لنسخة QUIC بتاعة Google من سنين كتيرة وبدأ مؤخراً يدعم نسخة IETF وراء flag. Firefox بنفس الطريقة بيدعم ده وراء flag. + +curl شحن أول دعم HTTP/3 تجريبي (draft-22) في إصدار 7.66.0 في 11 سبتمبر 2019. curl بيستخدم يا library Quiche من Cloudflare أو عائلة libraries ngtcp2 عشان يخلص الشغل. + +## عقبات التطبيق + +QUIC قرر يستخدم TLS 1.3 كأساس لطبقة crypto والأمان عشان يتجنب اختراع حاجة جديدة وبدلاً من كده يعتمد على بروتوكول موثوق وموجود. بس، بينما عمل ده، فريق العمل قرر كمان إنه عشان يبسط استخدام TLS في QUIC فعلاً، لازم يستخدم بس "TLS messages" ومش "TLS records" للبروتوكول. + +ده ممكن يبدو تغيير مش مضر، بس ده فعلاً سبب عائق كبير لمطبقين QUIC stack كتير. مكتبات TLS الموجودة اللي بتدعم TLS 1.3 ببساطة مالهاش APIs كفاية تكشف الوظيفة دي وتسمح لـ QUIC يوصل لها. بينما عدة مطبقين QUIC جايين من منظمات أكبر بتشتغل على TLS stack بتاعها بالتوازي، ده مش صحيح لكل حد. + +OpenSSL الوزن الثقيل المفتوح المصدر المهيمن مثلاً، مالوش أي API للموضوع ده. الخطة لمعالجة ده يبدو إنها هتحصل في [PR 8797](https://github.com/openssl/openssl/pull/8797) بتاعهم اللي بيهدف يقدم API شبيه جداً لده بتاع BoringSSL. + +ده في النهاية كمان هيؤدي لعقبات نشر لأن QUIC stacks هتحتاج يا تبني نفسها على مكتبات TLS تانية، تستخدم OpenSSL build منفصل مpatched أو تتطلب تحديث لنسخة OpenSSL مستقبلية. + +## Kernels وحمل CPU + +Google و Facebook ذكروا إن نشر QUIC على نطاق واسع بتاعهم يتطلب تقريباً ضعف مقدار CPU عن نفس حمولة traffic لما تخدم HTTP/2 على TLS. + +بعض التفسيرات لده تشمل + +- أجزاء UDP في أساساً Linux مش محسنة أبداً زي TCP stack، لأنها مش اتستخدمت تقليدياً لنقل عالي السرعة زي ده. + +- TCP و TLS offloading للhardware موجودة، بس ده أندر بكتير لـ UDP وأساساً مايوجدش لـ QUIC. + +في أسباب نصدق إن الأداء ومتطلبات CPU هتتحسن مع الوقت. + +مثال مصري: فكر في الوضع زي إنك بتشتغل نظام توصيل جديد (QUIC) بدل النظام القديم (HTTP/2). في الأول هيكون محتاج شغل ووقود أكتر لأن السوايق مش متعودين والعربيات مش محسنة للطريق الجديد، بس مع الوقت كله هيتحسن. \ No newline at end of file diff --git a/ar/proc.md b/ar/proc.md new file mode 100644 index 00000000..1a1abc8c --- /dev/null +++ b/ar/proc.md @@ -0,0 +1,13 @@ +# العملية + +بروتوكول QUIC الأصلي اتصمم بواسطة Jim Roskind في Google واتطبق أول مرة في 2012، واتعلن للعالم في 2013 لما تجربة Google اتوسعت. + +وقتها، QUIC لسه كان مطالب إنه اختصار لـ "Quick UDP Internet Connections"، بس ده اتلغى من بعدها. + +Google طبقت البروتوكول وبعدين نشرته في المتصفح المستخدم بكثرة (Chrome) وفي خدمات الخادم المستخدمة بكثرة (Google search و gmail و youtube وأكتر). عملوا iteration لنسخ البروتوكول بسرعة وأثبتوا مع الوقت إن المفهوم يشتغل بشكل موثوق لجزء كبير من المستخدمين. + +في يونيو 2015، أول internet draft لـ QUIC اتبعت لـ IETF للمعايرة، بس أخد لحد أواخر 2016 عشان QUIC working group تتقبل وتبدأ. بس بعدها انطلقت فوراً باهتمام كبير من أطراف كتيرة. + +في 2017، أرقام اتذكرت من مهندسين QUIC في Google قالت إن حوالي 7% من *كل* traffic الإنترنت كانت بتستخدم البروتوكول ده فعلاً. نسخة Google من البروتوكول. + +مثال مصري: فكر في QUIC زي اختراع جديد Google جربته في مختبرهم (2012)، بعدين عرضته على أصحابهم (2013)، وأخيراً قدموا الفكرة للجان الدولية عشان تبقى معيار عالمي (2015). زي ما واحد يخترع طبخة جديدة، يجربها مع أهله، بعدين يفتح بيها مطعم، وآخر حاجة يكتبها في كتاب طبخ رسمي. \ No newline at end of file diff --git a/ar/quic-0rtt.md b/ar/quic-0rtt.md new file mode 100644 index 00000000..7694641d --- /dev/null +++ b/ar/quic-0rtt.md @@ -0,0 +1,5 @@ +# 0-RTT + +عشان نقلل الوقت المطلوب لإنشاء connection جديد، client اتصل قبل كده بserver ممكن يحفظ معايير معينة من الconnection ده وبعدين يعمل **0-RTT** connection مع السيرفر. ده بيسمح للclient يبعت بيانات فوراً، من غير ما يستنى handshake يخلص. + +مثال مصري: فكر في 0-RTT زي إنك تروح للدكان اللي بتشتري منه كل يوم. مش محتاج تعرف بنفسك تاني، تقدر تطلب اللي عايزه على طول وصاحب الدكان يعرفك. على عكس لو رحت دكان جديد، هتحتاج تعرف بنفسك الأول قبل ما تطلب. \ No newline at end of file diff --git a/ar/quic-api.md b/ar/quic-api.md new file mode 100644 index 00000000..227e2215 --- /dev/null +++ b/ar/quic-api.md @@ -0,0 +1,11 @@ +# API + +واحد من عوامل نجاح TCP العادي والبرامج اللي بتستخدمه، هو socket API المعاير. عنده وظائف محددة وواضحة واستخدام API ده تقدر تنقل برامج بين نظم تشغيل مختلفة كتيرة لأن TCP بيشتغل نفس الطريقة. + +QUIC مش هناك. مافيش API معياري لـ QUIC. + +مع QUIC، محتاج تختار واحد من library implementations الموجودة وتلتزم بـ API بتاعه. ده بيخلي applications "محبوسة" في library واحد لحد ما. تغيير لlibrary تاني يعني API تاني وده ممكن يتضمن شغل كتير. + +كمان، بما إن QUIC عادة مطبق في user-space، مايقدرش بسهولة يمد socket API أو يظهر شبيه لإزاي TCP و UDP functionality الموجودة بتعمل. استخدام QUIC هيعني استخدام API تاني غير socket API. + +مثال مصري: فكر في TCP زي السواقة - كل العربيات تقريباً نفس الطريقة (دركسيون، فرامل، بنزين). QUIC زي طيارة - كل شركة لها نظام تحكم مختلف، فالطيار لازم يتدرب على كل نوع لوحده. \ No newline at end of file diff --git a/ar/quic-connections.md b/ar/quic-connections.md new file mode 100644 index 00000000..dda42f0e --- /dev/null +++ b/ar/quic-connections.md @@ -0,0 +1,23 @@ +# Connections + +QUIC connection هو محادثة واحدة بين طرفين من QUIC endpoints. إعداد connection في QUIC بيجمع version negotiation مع cryptographic و transport handshakes عشان يقلل latency إعداد الـ connection. + +عشان تبعت داتا فعلاً على connection زي ده، لازم تعمل stream واحد أو أكتر وتستخدمه. + +## Connection ID + +كل connection عنده مجموعة من connection identifiers، أو connection IDs، وكل واحد منهم يقدر يعرف الـ connection. Connection IDs بتتختار بشكل مستقل من endpoints؛ كل endpoint بيختار connection IDs اللي الطرف التاني هيستخدمها. + +الوظيفة الأساسية للـ connection IDs دي هي التأكد إن تغييرات العناوين في طبقات البروتوكول الأقل (UDP, IP, وتحت) متخليش packets بتاعة QUIC connection توصل للمكان الغلط. + +باستغلال connection ID، connections تقدر كده تنتقل بين IP addresses وشبكات مختلفة بطرق TCP مكانش يقدر يعملها أبداً. مثلاً، migration يخلي download شغال ينتقل من شبكة موبايل لwifi أسرع لما المستخدم ياخد جهازه لمكان فيه wifi. وبنفس الطريقة، الـ download يقدر يكمل على شبكة الموبايل لو الwifi بقى مش متاح. + +## Port numbers + +QUIC مبني على UDP، فـ 16 bit port number field بتستخدم عشان تميز بين connections الجاية. + +## Version negotiation + +QUIC connection request اللي جاي من client هيقول للسيرفر أي نسخة QUIC protocol عايز يتكلم بيها، والسيرفر هيرد بقائمة النسخ المدعومة عشان الـ client يختار منها. + +مثال مصري: فكر في Connection ID زي رقم الموبايل بتاعك. حتى لو غيرت مكانك من البيت للشغل أو من wifi للموبايل، رقمك نفسه وأي حد عايز يكلمك يقدر يوصلك. ده عكس TCP اللي زي التليفون الأرضي - لازم تكون في مكان معين عشان حد يقدر يكلمك. \ No newline at end of file diff --git a/ar/quic-future.md b/ar/quic-future.md new file mode 100644 index 00000000..96fa0db3 --- /dev/null +++ b/ar/quic-future.md @@ -0,0 +1,27 @@ +# مستقبل QUIC + +عشان نحصل على أكبر تركيز ممكن على بروتوكول QUIC الأساسي ونقدر نشحنه في الوقت، عدة ميزات كانت أصلاً مخطط تكون جزء من البروتوكول الأساسي اتأجلت ودلوقتي مخطط بدلاً من كده تتعمل في نسخة QUIC تالية. + +مؤلف المستند ده بقى عنده كرة بلورية معيوبة نوعاً ما فمانقدرش نقول بالضبط إيه الميزات اللي هتظهر أو متظهرش في نسخة مستقبلية زي دي. نقدر بقى نذكر بعض الميزات والحاجات اللي صراحة اتشالت من شغل v1 عشان "نشتغل عليها بعدين" واللي ممكن تظهر في نسخة مستقبلية. + +## Forward Error Correction + +Forward error correction (FEC) طريقة للحصول على error control في نقل البيانات اللي فيها المرسل يبعت بيانات إضافية والمستقبل يتعرف بس على جزء البيانات اللي مافيهوش أخطاء واضحة. + +Google جربت ده في شغل QUIC الأصلي بتاعها بس اتشال تاني لأن التجارب مطلعتش كويسة. الميزة دي موضوع للنقاش لـ QUIC بس على الأرجح تاخد حد يثبت إنها فعلاً ممكن تكون إضافة مفيدة من غير عقوبة كتيرة. + +## Multipath + +Multipath يعني إن النقل يقدر بنفسه يستخدم مسارات شبكة متعددة عشان يعظم استخدام الموارد ويزيد التكرار. + +مؤيدين SCTP في العالم بيحبوا يذكروا إن SCTP عنده multipath فعلاً وكمان TCP الحديث. + +## بيانات غير موثوقة + +اتناقش إنه يقدم "unreliable" streams كخيار، ده ممكن يسمح لـ QUIC إنه يحل محل UDP-style applications. + +مثال مصري: فكر في مستقبل QUIC زي خطط التطوير للمترو - النسخة الأولى تشغل الخط الأساسي، والنسخ الجاية هتضيف خطوط فرعية وميزات جديدة زي multipath (خطوط متعددة) وunreliable streams (قطر سريع بدون توقفات). + +## Non-HTTP adaptions + +DNS over QUIC كان واحد من البروتوكولات non-HTTP المذكورة مبكراً اللي ممكن تحصل على شوية اهتمام لما QUIC v1 و HTTP/3 يتشحنوا. بس مع نقل جديد زي ده اتجاب للعالم مانقدرش نتخيل إنه هيقف هنا. \ No newline at end of file diff --git a/ar/quic-spinbit.md b/ar/quic-spinbit.md new file mode 100644 index 00000000..5861fd10 --- /dev/null +++ b/ar/quic-spinbit.md @@ -0,0 +1,17 @@ +# Spin Bit + +واحدة من أطول مناقشات التصميم جوا فريق عمل QUIC اللي كانت موضوع مئات الmails وساعات من المناقشات تخص bit واحد: Spin Bit. + +مؤيدين الbit ده بيصروا إن في حاجة لمشغلين وناس على المسار بين نقطتين QUIC endpoints إنهم يقدروا يقيسوا latency. + +معارضين الميزة دي مابيحبوش information leak المحتمل. + +## تدوير bit + +النقطتين، الclient والserver، بيحافظوا على spin value، 0 أو 1، لكل QUIC connection، وبيحطوا spin bit على packets اللي بيبعتوها للconnection ده للقيمة المناسبة. + +الناحيتين بعدين يبعتوا packets مع spin bit محطوط لنفس القيمة طول ما round trip واحد يستمر وبعدين يغيروا القيمة. الأثر ساعتها نبضة من واحدات وأصفار في bitfield ده اللي المراقبين يقدروا يراقبوها. + +القياس ده بس يشتغل لما الsender مش application ولا flow control limited وإعادة ترتيب packet على الشبكة ممكن كمان يخلي البيانات مليانة noise. + +مثال مصري: فكر في Spin Bit زي الإشارة الدورانية (الفلاشر) في العربية. بتفتح وتقفل عشان اللي ورا يعرف إنك هتلف. مؤيدينها يقولوا مهمة للأمان، معارضينها يقولوا بتفضح مكانك وحركتك للمتتبعين. \ No newline at end of file diff --git a/ar/quic-streams.md b/ar/quic-streams.md new file mode 100644 index 00000000..9d3b7013 --- /dev/null +++ b/ar/quic-streams.md @@ -0,0 +1,45 @@ +# Streams + +Streams في QUIC بتوفر abstraction خفيف ومرتب للbyte-stream. + +في نوعين أساسيين من stream في QUIC: + +- Unidirectional streams بتحمل بيانات في اتجاه واحد: من اللي بدأ الstream لطرفه التاني. + +- Bidirectional streams بتسمح بإن البيانات تتبعت في الاتجاهين. + +أي نوع من الstream يقدر يتعمل من أي endpoint، يقدر يبعت بيانات متداخلة مع streams تانية في نفس الوقت، ويقدر يتلغي. + +عشان نبعت بيانات على QUIC connection، stream واحد أو أكتر بيتستخدم. + +## Flow control + +Streams معمولها flow control منفرد، ده بيسمح للendpoint إنه يحدد memory commitment ويطبق back pressure. إنشاء الstreams برضو معمولها flow control، مع كل peer بيعلن أقصى stream ID مستعد يقبله في وقت معين. + +## Stream Identifiers + +Streams بتتعرف برقم 62-bit unsigned integer، واللي بيتسمى Stream ID. أقل bitين مهمين في Stream ID بيستخدموا عشان يعرفوا نوع الstream (unidirectional ولا bidirectional) ومين اللي بدأ الstream. + +أقل bit مهم (0x1) في Stream ID بيعرف مين اللي بدأ الstream. Clients بيبدأوا streams أرقام زوجي (اللي فيها أقل bit مهم = 0)؛ servers بيبدأوا streams أرقام فردي (مع الbit = 1). + +تاني أقل bit مهم (0x2) في Stream ID بيفرق بين unidirectional streams و bidirectional streams. Unidirectional streams دايماً الbit ده = 1 و bidirectional streams الbit ده = 0. + +## Stream concurrency + +QUIC بيسمح بعدد streams عشوائي يشتغل concurrently. Endpoint بيحدد عدد الstreams الactive الداخلة عن طريق تحديد أقصى stream ID. + +أقصى stream ID مخصوص لكل endpoint ويتطبق بس على الpeer اللي بيستقبل الإعداد. + +## إرسال واستقبال البيانات + +Endpoints بتستخدم streams عشان تبعت وتستقبل بيانات. ده آخر حاجة هدفها الأساسي. Streams هي ordered byte-stream abstraction. بس streams منفصلة مش بالضرورة توصل بالترتيب الأصلي. + +مثال مصري: فكر في الstreams زي خطوط التليفون في السنترال. كل خط (stream) له رقم مميز، وممكن يشتغل في اتجاه واحد (زي الراديو) أو اتجاهين (زي التليفون العادي). السنترال (QUIC) بيقدر يدير خطوط كتيرة في نفس الوقت. + +## Stream Prioritization + +Stream multiplexing له تأثير كبير على أداء الapplication لو الموارد المخصصة للstreams اتحددت أولوياتها صح. التجربة مع بروتوكولات multiplexed تانية، زي HTTP/2، بتوري إن استراتيجيات prioritization الفعالة لها تأثير إيجابي كبير على الأداء. + +QUIC نفسه مابيوفرش إشارات لتبادل معلومات prioritization. بدلاً من كده بيعتمد على استقبال معلومات priority من الapplication اللي بيستخدم QUIC. البروتوكولات اللي بتستخدم QUIC تقدر تعرف أي prioritization scheme يناسب application semantics بتاعها. + +Extensible Prioritization Scheme لـ HTTP ([RFC 9218](https://www.rfc-editor.org/rfc/rfc9218.html)) ممكن يتستخدم لـ HTTP/3. بيعرف إشارات ويقدم scheduling guidance. المخطط ده أبسط من الأصلي المعرف لـ HTTP/2. \ No newline at end of file diff --git a/ar/quic-tls.md b/ar/quic-tls.md new file mode 100644 index 00000000..77699ddb --- /dev/null +++ b/ar/quic-tls.md @@ -0,0 +1,7 @@ +# Connections بتستخدم TLS + +فوراً بعد الpacket الأولي اللي بيعمل connection، المبادر بيبعت crypto frame يبدأ يعمل secure layer handshake. طبقة الأمان بتستخدم TLS 1.3 security. + +مافيش طريقة تطلع أو تتجنب استخدام TLS لـ QUIC connection. البروتوكول مصمم إنه يكون صعب على middle-boxes إنها تتدخل فيه، عشان تساعد تمنع ossification البروتوكول. + +مثال مصري: فكر في QUIC زي محادثة سرية مشفرة - مافيش طريقة تتكلم من غير تشفير. ده عشان يضمن إن محدش في الوسط يقدر يتدخل أو يغير الكلام، زي الرسايل المشفرة على الواتساب. \ No newline at end of file diff --git a/ar/quic-userspace.md b/ar/quic-userspace.md new file mode 100644 index 00000000..61dbbe84 --- /dev/null +++ b/ar/quic-userspace.md @@ -0,0 +1,13 @@ +## User-space + +تطبيق بروتوكول نقل في user-space بيساعد يمكن iteration سريع للبروتوكول، لأنه سهل نسبياً تطوير البروتوكول من غير ما نحتاج إن clients وservers يحدثوا kernel نظام التشغيل بتاعهم عشان ينشروا نسخ جديدة. + +مافيش حاجة أساسية في QUIC تمنعه إنه يتطبق ويتقدم بواسطة kernels نظم التشغيل في المستقبل، لو حد شاف ده فكرة كويسة. + +### Implementations كتيرة + +أثر واضح واحد لتطبيق بروتوكول نقل جديد في user-space إننا نقدر نتوقع نشوف implementations مستقلة كتيرة. + +applications مختلفة على الأرجح هتضم (أو تبني فوق) HTTP/3 و QUIC implementations مختلفة في المستقبل المنظور. + +مثال مصري: فكر في user-space زي إنك تعمل تطبيق على الموبايل بدل ما تعدل في نظام الأندرويد نفسه. أسرع وأسهل، وكل مطور يقدر يعمل نسخته الخاصة من غير ما يستنى تحديث النظام. \ No newline at end of file diff --git a/ar/quic.md b/ar/quic.md new file mode 100644 index 00000000..532f6bdd --- /dev/null +++ b/ar/quic.md @@ -0,0 +1,12 @@ +# إزاي QUIC بيشتغل + +من غير ما نشرح البتات والبايتات بالضبط على الشبكة، الجزء ده هيوصف إزاي اللبنات الأساسية لبروتوكول نقل QUIC بتشتغل. لو عايز تعمل QUIC stack بتاعك، الوصف ده هيديك فهم عام، بس لكل التفاصيل، ارجع لـ IETF Internet Drafts و RFCs الأصلية. + +1. اعمل [connection](quic-connections.md) +2. ... اللي يشمل [أمان TLS](quic-tls.md) +3. بعدين استخدم [streams](quic-streams.md) + +مثال مصري: فكر في QUIC زي إنك بتفتح خط تليفون جديد مع صاحبك: +1. الأول تتصل وتتأكد إن الخط واصل (Connection) +2. تتأكد إن محدش بيسمعكم وتتكلموا بكود سري (TLS Security) +3. بعد كده تبدأوا تتكلموا في مواضيع مختلفة في نفس الوقت (Streams) \ No newline at end of file diff --git a/ar/specs.md b/ar/specs.md new file mode 100644 index 00000000..f2a67ab6 --- /dev/null +++ b/ar/specs.md @@ -0,0 +1,29 @@ +# المواصفات + +دي مجموعة من RFCs للأجزاء والمكونات المختلفة لـ QUIC و HTTP/3. + +## Version Negotiation + +[Compatible Version Negotiation for QUIC](https://datatracker.ietf.org/doc/html/rfc9368) + +## Transport + +[QUIC: A UDP-Based Multiplexed and Secure Transport](https://datatracker.ietf.org/doc/html/rfc9000) + +## Recovery + +[QUIC Loss Detection and Congestion Control](https://datatracker.ietf.org/doc/html/rfc9002) + +## TLS + +[Using TLS to Secure QUIC](https://datatracker.ietf.org/doc/html/rfc9001) + +## HTTP + +[Hypertext Transfer Protocol Version 3 (HTTP/3)](https://datatracker.ietf.org/doc/html/rfc9114) + +## QPACK + +[QPACK: Header Compression for HTTP/3](https://datatracker.ietf.org/doc/html/rfc9204) + +مثال مصري: المواصفات دي زي "دليل الاستعمال" بتاع QUIC و HTTP/3. كل RFC زي كتيب تعليمات لجزء معين - واحد للنقل، واحد للأمان، واحد لضغط البيانات، وهكذا. زي ما عندك دليل استعمال منفصل للموبايل والعربية والتكييف. \ No newline at end of file diff --git a/ar/the-protocol.md b/ar/the-protocol.md new file mode 100644 index 00000000..f50dd993 --- /dev/null +++ b/ar/the-protocol.md @@ -0,0 +1,9 @@ +# ميزات البروتوكول + +بروتوكول QUIC من مستوى عالي. + +مرسوم تحت HTTP/2 network stack على الشمال و QUIC network stack على اليمين، لما يتستخدم كـ HTTP transport. + +مثال مصري: الصورة دي بتوضح الفرق بين النظام القديم (HTTP/2) والجديد (QUIC). فكر فيها زي مقارنة بين برج قديم (HTTP/2) مبني بطريقة تقليدية مع أدوار منفصلة، وبرج حديث (QUIC) مصمم بتقنيات جديدة كله وحدة واحدة أكتر كفاءة. + +![HTTP/3 over QUIC stack overview](../images/quic-stack.png) \ No newline at end of file diff --git a/ar/why-h2.md b/ar/why-h2.md new file mode 100644 index 00000000..bdaac806 --- /dev/null +++ b/ar/why-h2.md @@ -0,0 +1,17 @@ +## فاكر HTTP/2؟ + +مواصفة HTTP/2 [RFC 7540](https://httpwg.org/specs/rfc7540.html) اتنشرت في مايو 2015 والبروتوكول ده بقى مطبق ومستخدم على نطاق واسع على الإنترنت والويب. + +في أوائل 2018، تقريباً 40% من أول 1000 موقع ويب بيستخدموا HTTP/2، حوالي 70% من كل طلبات HTTPS اللي Firefox بيعملها بيجيلها ردود HTTP/2، وكل المتصفحات والسيرفرات والproxies الكبيرة بتدعمه. + +HTTP/2 عالج مشاكل كتيرة في HTTP/1 ومع دخول النسخة التانية من HTTP المستخدمين بطلوا يحتاجوا يستخدموا workarounds كتيرة. بعضها كان صعب جداً على مطوري الويب. + +واحدة من أهم ميزات HTTP/2 إنه بيستخدم multiplexing، يعني streams منطقية كتيرة بتتبعت على نفس TCP connection الفيزيائي. ده بيخلي حاجات كتيرة أحسن وأسرع. بيخلي congestion control يشتغل أحسن، بيخلي المستخدمين يستخدموا TCP أحسن وبالتالي يملوا الbandwidth صح، بيخلي TCP connections تعيش أكتر - وده كويس عشان توصل للسرعة الكاملة أكتر من الأول. ضغط الHeaders بيخليه يستخدم bandwidth أقل. + +مع HTTP/2، المتصفحات عادة بتستخدم TCP connection *واحد* لكل host بدل *ستة* زي الأول. في الحقيقة، تقنيات connection coalescing و "desharding" المستخدمة مع HTTP/2 ممكن تقلل عدد connections أكتر من كده حتى. + +HTTP/2 حل مشكلة HTTP head of line blocking، اللي كانت بتخلي الclients تستنى أول request في الصف يخلص قبل ما التاني يطلع. + +مثال مصري: فكر في HTTP/2 زي محطة بنزين جديدة فيها طلمبة واحدة بس تقدر تملي عربيات كتير في نفس الوقت، بدل من الطلمبات القديمة اللي كانت تملي عربية واحدة بس في المرة الواحدة وباقي العربيات تقف في الطابور تستنى. + +![http2 man](../images/h2-man.jpg) \ No newline at end of file diff --git a/ar/why-latency.md b/ar/why-latency.md new file mode 100644 index 00000000..d99c0cd2 --- /dev/null +++ b/ar/why-latency.md @@ -0,0 +1,15 @@ +# بيانات أسرع + +QUIC بيقدم 0-RTT و 1-RTT handshakes اللي بتقلل الوقت اللي بياخده التفاوض وإعداد connection جديد. قارن ده بـ 3-way handshake بتاع TCP. + +بالإضافة لده، QUIC بيقدم دعم "early data" من البداية وده بيتعمل عشان يسمح ببيانات أكتر وبيتستخدم أسهل من TCP Fast Open. + +مع مفهوم الـ stream، connection منطقي تاني لنفس الـ host يقدر يتعمل فوراً من غير ما نستنى الموجود يخلص الأول. + +## TCP Fast Open فيه مشاكل + +TCP Fast Open اتنشر كـ [RFC 7413](https://tools.ietf.org/html/rfc7413) في ديسمبر 2014 والمواصفة دي بتوصف إزاي الأبليكيشن يقدر يبعت داتا للسيرفر عشان توصل في أول TCP SYN packet. + +الدعم الحقيقي للميزة دي في الواقع أخد وقت وفيه مشاكل كتيرة حتى دلوقتي في 2018. اللي بيعملوا TCP stack عندهم مشاكل وكمان الأبليكيشن اللي بتحاول تستفيد من الميزة دي - في معرفة أي نسخة OS تجرب تفعلها فيها وكمان في معرفة إزاي تتعامل مع المشاكل لما تحصل. شبكات كتيرة اتحددت إنها بتتدخل في TFO traffic وبالتالي بتخرب TCP handshakes زي دي. + +مثال مصري: فكر في TCP Fast Open زي إنك تطلب أكل وتدفع فلوس قبل ما الدليفري يوصل. الفكرة حلوة بس في الواقع مطاعم كتير مش بتقبل ده والدليفري أحياناً مش بيعرف يتعامل معاه صح. \ No newline at end of file diff --git a/ar/why-ossification.md b/ar/why-ossification.md new file mode 100644 index 00000000..90e9917e --- /dev/null +++ b/ar/why-ossification.md @@ -0,0 +1,21 @@ +# التجمد + +الإنترنت شبكة من الشبكات. في أجهزة متنصبة على الإنترنت في أماكن مختلفة كتيرة على الطريق عشان تتأكد إن شبكة الشبكات دي تشتغل زي ما مفروض. الأجهزة دي، الboxes المنتشرة في الشبكة، هي اللي أحياناً نشير لها كـ middle-boxes. Boxes قاعدة في حتة ما بين النقطتين اللي هما الأطراف الأساسية المشاركة في نقل البيانات العادي للشبكة. + +Boxes دي بتخدم أغراض مختلفة كتيرة بس أعتقد نقدر نقول إنها بشكل عام متحطة هناك لأن حد فكر إنها لازم تكون هناك عشان الحاجات تشتغل. + +Middle-boxes بتوجه IP packets بين الشبكات، بتحجب traffic خبيث، بتعمل NAT (Network Address Translation)، بتحسن الأداء، بعضها بيحاول يتجسس على traffic العابر وأكتر. + +عشان تعمل واجباتها الboxes دي لازم تعرف عن الshبكات والبروتوكولات اللي بتراقبها أو تعدل فيها. بتشغل software للغرض ده. Software مش دايماً بيتحدث بكثرة. + +بينما هي مكونات لزق بتخلي الإنترنت مترابط، كمان مش بتواكب آخر تكنولوجيا. وسط الشبكة عادة مابيتحركش بسرعة الأطراف، زي clients وservers العالم. + +بروتوكولات الشبكة اللي الboxes دي ممكن تعوز تفحصها، وعندها أفكار عن إيه اللي okay وإيه اللي لأ، لها المشكلة دي: الboxes دي اتنشرت من شوية لما البروتوكولات كان عندها مجموعة ميزات الوقت ده. تقديم ميزات جديدة أو تغييرات في السلوك مكانتش معروفة من قبل بتخاطر تخلاص تتعتبر وحشة أو غير قانونية بواسطة الboxes دي. Traffic زي ده ممكن يتنف أو يتأخر لدرجة إن المستخدمين فعلاً مايحبوش يستخدموا الميزات دي. + +ده بيتسمى "protocol ossification". + +تغييرات في TCP كمان بتعاني من ossification: بعض boxes بين client وremote server هتكتشف TCP options جديدة مجهولة وتحجب connections زي دي لأنها متعرفش الoptions إيه. لو اتسمحلها تكتشف تفاصيل البروتوكول، الأنظمة تتعلم إزاي البروتوكولات عادة بتسلك ومع الوقت بيبقى مستحيل تغييرها. + +الطريقة الوحيدة الفعالة حقاً "لمحاربة" ossification هي تشفير أكبر قدر ممكن من التواصل عشان نمنع middle-boxes إنها تشوف كتير من البروتوكول العابر. + +مثال مصري: فكر في ossification زي الحاجز الأمني القديم في شارعك. اتعود على نوع العربيات اللي بتعدي كل يوم، فلو شاف عربية جديدة مختلفة هيوقفها ويشك فيها حتى لو مافيهاش أي مشكلة. عشان كده QUIC بيشفر كل حاجة عشان الحاجز مايشوفش إيه اللي جوا العربية. \ No newline at end of file diff --git a/ar/why-quic.md b/ar/why-quic.md new file mode 100644 index 00000000..949ab4fc --- /dev/null +++ b/ar/why-quic.md @@ -0,0 +1,13 @@ +# ليه QUIC + +QUIC اسم مش اختصار. بيتنطق زي كلمة "quick" بالإنجليزي بالضبط. + +QUIC هو بروتوكول جديد موثوق وآمن مناسب لبروتوكول زي HTTP ويقدر يحل بعض المشاكل المعروفة في استخدام HTTP/2 على TCP و TLS. الخطوة المنطقية الجاية في تطور نقل البيانات على الويب. + +QUIC مش محدود بنقل HTTP بس. الرغبة في خلي الويب والبيانات بشكل عام توصل أسرع للمستخدمين هي أكبر سبب ودافع خلى البروتوكول الجديد ده يتعمل. + +طب ليه نعمل بروتوكول نقل جديد وليه نعمله على UDP؟ + +مثال مصري: فكر في QUIC زي خدمة الدليفري الجديدة اللي بتوصل الطلبات أسرع من البوستا العادية. TCP زي البوستا - بطيء بس مضمون. UDP زي الموبايل - سريع بس مش مضمون دايماً. QUIC بيجمع الاتنين - سرعة الموبايل مع ضمان البوستا. + +![QUIC logo](../images/QUIC.png) \ No newline at end of file diff --git a/ar/why-secure.md b/ar/why-secure.md new file mode 100644 index 00000000..ac7bf583 --- /dev/null +++ b/ar/why-secure.md @@ -0,0 +1,7 @@ +## آمن + +QUIC آمن دايماً. مافيش نسخة clear-text من البروتوكول، فعشان تتفاوض على QUIC connection يعني إنك تعمل cryptography وأمان مع TLS 1.3. زي ما اتذكر فوق، ده بيمنع ossification وأنواع blocks وmعاملات خاصة تانية، وكمان بيتأكد إن QUIC عنده كل الخصائص الآمنة بتاعة HTTPS اللي مستخدمين الويب اتعودوا عليها وعايزينها. + +في packets قليلة بس من handshake الأولي اللي بتتبعت واضحة قبل ما بروتوكولات التشفير تتفاوض. + +مثال مصري: فكر في QUIC زي خزينة البنك - مافيش طريقة تفتحها من غير الكود السري. حتى لو حاولت تتكلم معاها، لازم تثبت هويتك الأول. على عكس TCP العادي اللي زي الكلام في الشارع - أي حد يقدر يسمع. \ No newline at end of file diff --git a/ar/why-tcphol.md b/ar/why-tcphol.md new file mode 100644 index 00000000..6cbc7897 --- /dev/null +++ b/ar/why-tcphol.md @@ -0,0 +1,35 @@ +## TCP head of line blocking + +HTTP/2 بيشتغل على TCP ومع TCP connections أقل بكتير من لما نستخدم نسخ HTTP الأقدم. TCP هو بروتوكول للنقل الموثوق وممكن تفكر فيه زي سلسلة وهمية بين جهازين. اللي بيتحط على الشبكة في ناحية هيوصل للناحية التانية، بنفس الترتيب - في الآخر. (أو الconnection ينقطع.) + +![a TCP chain between two computers](../images/tcp-chain.png) + +مع HTTP/2، المتصفحات العادية بتعمل عشرات أو مئات من النقل المتوازي على TCP connection واحد. + +لو packet واحد وقع، أو ضاع في الشبكة في أي مكان بين النقطتين اللي بتتكلم HTTP/2، ده معناه إن كل TCP connection يتوقف بينما الpacket الضائع يتبعت تاني ويلاقي طريقه للمكان المطلوب. بما إن TCP هو "السلسلة" دي، ده معناه إن لو حلقة واحدة ضاعت فجأة، كل حاجة كانت هتيجي بعد الحلقة الضائعة لازم تستنى. + +رسم توضيحي باستخدام استعارة السلسلة لما نبعت streamين على connection ده. stream أحمر وstream أخضر: + +![the chain showing links in different colors](../images/tcp-chain-streams.png) + +ده بيبقى TCP-based head of line block! + +كلما معدل فقدان الpackets يزيد، HTTP/2 يشتغل أسوأ وأسوأ. عند فقدان 2% من الpackets (اللي هو جودة شبكة وحشة جداً، خد بالك)، التجارب أثبتت إن مستخدمين HTTP/1 عادة يكونوا أحسن - لأنهم عادة عندهم لغاية ستة TCP connections يوزعوا الpackets الضائعة عليها. ده معناه إن مع كل packet ضائع الconnections التانية تقدر تكمل. + +إصلاح المشكلة دي مش سهل، لو أصلاً ممكن، مع TCP. + +مثال مصري: فكر في TCP زي قطار واحد طويل. لو عربة واحدة في النص عطلت، كل القطار يوقف لحد ما العربة دي تتصلح، حتى لو العربيات اللي ورا كانت شغالة كويس. + +## Independent streams بتتجنب الblock + +مع QUIC لسه في connection setup بين النقطتين اللي بيخلي الconnection آمن ونقل البيانات موثوق. + +![a QUIC chain between two computers](../images/tcp-chain.png) + +لما نعمل streamين مختلفين على connection ده، بيتعاملوا بشكل مستقل بحيث إن لو أي حلقة ضاعت لواحد من الstreams، بس الstream ده، السلسلة المعينة دي، اللي هتتوقف وتستنى الحلقة المفقودة تتبعت تاني. + +مرسوم هنا بstream أصفر وstream أزرق متبعتين بين نقطتين. + +مثال مصري: QUIC زي إن عندك شارعين منفصلين بدل من شارع واحد. لو حصل زحمة في شارع، الشارع التاني يفضل شغال عادي. + +![two QUIC streams between two computers](../images/quic-chain-streams.png) \ No newline at end of file diff --git a/ar/why-tcpudp.md b/ar/why-tcpudp.md new file mode 100644 index 00000000..3d050984 --- /dev/null +++ b/ar/why-tcpudp.md @@ -0,0 +1,24 @@ +## TCP ولا UDP + +لو مانقدرش نصلح head-of-line blocking جوا TCP، في النظرية المفروض نقدر نعمل بروتوكول نقل جديد جنب UDP و TCP في network stack. أو ممكن حتى نستخدم [SCTP](https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol) اللي هو بروتوكول نقل معايرة بواسطة IETF في [RFC 4960](https://tools.ietf.org/html/rfc4960) مع عدة من الخصائص المرغوب فيها. + +بس، في السنين الأخيرة مجهودات إنشاء بروتوكولات نقل جديدة تقريباً اتوقفت خالص بسبب صعوبات نشرها على الإنترنت. نشر بروتوكولات جديدة بيتعرقل بواسطة firewalls كتيرة و NATs و routers و middle-boxes تانية اللي بتسمح بس بـ TCP أو UDP ومنتشرة بين المستخدمين والسيرفرات اللي محتاجين يوصلولها. تقديم بروتوكول نقل تاني بيخلي N% من الconnections تفشل لأنها بتتحجب بواسطة boxes بتشوفها مش UDP أو TCP وبالتالي شر أو غلط بطريقة ما. معدل الفشل N% بيتعتبر عالي أوي إن المجهود ميستحقش. + +بالإضافة لده، تغيير حاجات في طبقة بروتوكول النقل في network stack عادة يعني بروتوكولات مطبقة بواسطة kernels نظام التشغيل. تحديث ونشر kernels جديدة لنظم التشغيل عملية بطيئة تتطلب مجهود كبير. تحسينات TCP كتيرة معايرة بواسطة IETF مش منتشرة أو مستخدمة على نطاق واسع لأنها مش مدعومة بشكل واسع. + +## ليه مش SCTP-over-UDP + +SCTP بروتوكول نقل موثوق بـ streams، ولـ WebRTC في حتى implementations موجودة بتستخدمه على UDP. + +ده ماتعتبرش كويس كفاية كبديل لـ QUIC لأسباب عدة، منها: + +- SCTP مايحلش مشكلة head-of-line-blocking للstreams +- SCTP بيتطلب عدد الstreams يتحدد في connection setup +- SCTP مالوش قصة TLS/security قوية +- SCTP عنده 4-way handshake، QUIC بيقدم 0-RTT +- QUIC bytestream زي TCP، SCTP message-based +- QUIC connections تقدر تنتقل بين IP addresses بس SCTP مايقدرش + +للتفاصيل أكتر عن الفروق، شوف [A Comparison between SCTP and QUIC](https://tools.ietf.org/html/draft-joseph-quic-comparison-quic-sctp-00). + +مثال مصري: فكر في الوضع زي إنك عايز تعمل نوع نقل جديد في الشوارع. TCP زي الأتوبيس - بطيء بس موجود في كل حتة. UDP زي التوك توك - سريع بس مش مضمون. SCTP كان زي الميكروباص - أحسن من الأتوبيس بس مش كل الشوارع تقبله. QUIC زي إنك تاخد التوك توك وتديله مميزات الأتوبيس - سرعة مع أمان. \ No newline at end of file