Add Arabic translations for QUIC and HTTP/3 documentation

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)

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/).

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 على السيرفرات بتاعتهم وللخدمات بتاعتهم؟ الوقت وقياسات الأداء المستقبلية أكيد هتقول!
+
+مثال مصري: زي ما تقول "الموبايل ده أحسن بس شوية من اللي عندي، يستاهل أغيره؟" الإجابة تعتمد على قد إيه الفرق مهم ليك ولاستخدامك.

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).

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 زي نظام ترقيم الفصول - كل فصل منفصل ومفهوم لوحده حتى لو وصل قبل اللي قبله.

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)

ar/feature-nonhttp.md

@@ -0,0 +1,5 @@
+## Non-HTTP over QUIC
+
+الشغل على إرسال بروتوكولات غير HTTP على QUIC اتأجل لحد بعد ما QUIC version 1 يتشحن.
+
+مثال مصري: فكر في الموضوع زي إنهم ركزوا على تشغيل السكة الحديد للقطر الأساسي الأول، والخطوط الفرعية (البروتوكولات التانية) هتتعمل لما الخط الأساسي يشتغل صح.

ar/feature-reliable.md

@@ -0,0 +1,7 @@
+## ‎نقل بيانات موثوق
+
+بينما UDP مش نقل موثوق، QUIC بيضيف طبقة على UDP بتقدم الموثوقية. بيقدم إعادة إرسال الpackets، congestion control، pacing والميزات التانية الموجودة في TCP.
+
+البيانات المبعوتة على QUIC من endpoint واحد هتظهر في الطرف التاني عاجلاً أو آجلاً، طالما الconnection متحافظ عليه.
+
+مثال مصري: فكر في UDP زي البريد العادي - سريع بس مش مضمون الوصول. QUIC بيضيف عليه خدمة "التوصيل المضمون" - بيتأكد إن الجواب وصل، ولو مووصلش يبعته تاني، زي البريد المسجل بس أسرع.

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 الواحد).

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 خطوات عشان تتأكد من هويتك، الجديد ياخد خطوة أو اتنين بس ويبقى أآمن برضو.

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 كانت زي عربية مخصوصة للخضار بس، النسخة الجديدة زي شاحنة تقدر تشيل أي حاجة.

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 على الإنترنت زاد.

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 تاني" وانت تختار.