From 72f0ae6822dd3d2dcdf13fbd3b70c520eee1b28f Mon Sep 17 00:00:00 2001 From: Yusuke Nakamura Date: Fri, 19 Mar 2021 17:54:58 +0900 Subject: [PATCH 01/78] [why-tcpudp] [ja] Refine ja translation about SCTP-over-UDP (#195) original > SCTP is a reliable transport protocol with streams, and for WebRTC > there are even existing implementations using it over UDP. Current translate lack of meaning about "over". --- ja/why-tcpudp.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ja/why-tcpudp.md b/ja/why-tcpudp.md index 26db450e..dbf739db 100644 --- a/ja/why-tcpudp.md +++ b/ja/why-tcpudp.md @@ -7,7 +7,7 @@ TCP の枠組みで head-of-line ブロッキングを直せないのであれ 加えて、通常ネットワークスタックのトランスポートプロトコルレイヤーの中を変更することは、OS のカーネルによって実装されているプロトコルを変更することを意味しています。OS のカーネルを更新して展開することは、多大な努力を必要とする遅いプロセスです。IETF によって標準化された多くの TCP の改善は、広くサポートされていないため、広範囲に渡って展開されたり使用されたりしていません。 ## なぜ SCTP-over-UDP ではないのか -SCTP はストリームを用いた信頼性のあるプロトコルで、WebRTC には UDP を使用する実装さえ存在します。 +SCTP はストリームを用いた信頼性のあるプロトコルで、WebRTC には UDP を介してSCTPを使用する実装さえ存在します。 これは QUIC に取って代わるものとして十分ではありませんでした。以下を含む幾つかの理由に原因があります。 From 0fc640bb73ddb45a30ea6302fcd510e8af023aa0 Mon Sep 17 00:00:00 2001 From: Faraz Vahedi Date: Wed, 21 Apr 2021 15:28:46 +0000 Subject: [PATCH 02/78] [fa] Reformat all files (#197) --- fa/README.md | 36 +++++++++++++---- fa/criticism.md | 47 +++++++++++++++++----- fa/feature-handshakes.md | 12 +++++- fa/feature-http.md | 10 ++++- fa/feature-inorder.md | 16 ++++++-- fa/feature-nonhttp.md | 3 +- fa/feature-reliable.md | 7 +++- fa/feature-streams.md | 19 ++++++--- fa/feature-tls.md | 9 ++++- fa/feature-trans-app.md | 8 +++- fa/feature-udp.md | 29 +++++++++++--- fa/h3-altsvc.md | 31 +++++++++++---- fa/h3-h2.md | 39 +++++++++++++------ fa/h3-https.md | 28 +++++++++++--- fa/h3-prio.md | 13 +++++-- fa/h3-push.md | 26 ++++++++++--- fa/h3-streams.md | 31 +++++++++++---- fa/h3.md | 27 +++++++++---- fa/proc-h2.md | 12 ++++-- fa/proc-ietf.md | 48 ++++++++++++++++------- fa/proc-status.md | 84 ++++++++++++++++++++++++++++++---------- fa/proc.md | 22 ++++++++--- fa/quic-0rtt.md | 8 +++- fa/quic-api.md | 20 ++++++++-- fa/quic-connections.md | 32 +++++++++++---- fa/quic-spinbit.md | 19 ++++++--- fa/quic-streams.md | 58 ++++++++++++++++++++------- fa/quic-tls.md | 8 +++- fa/quic-userspace.md | 18 +++++++-- fa/quic-v2.md | 37 ++++++++++++++---- fa/quic.md | 6 ++- fa/specs.md | 21 ++++++---- fa/the-protocol.md | 3 +- fa/why-h2.md | 37 +++++++++--------- fa/why-latency.md | 25 +++++++++--- fa/why-ossification.md | 57 ++++++++++++++++++++------- fa/why-quic.md | 18 ++++----- fa/why-secure.md | 10 ++++- fa/why-tcphol.md | 40 ++++++++++++++----- fa/why-tcpudp.md | 52 ++++++++++++++++++------- 40 files changed, 767 insertions(+), 259 deletions(-) diff --git a/fa/README.md b/fa/README.md index 303329b9..49a50cc5 100644 --- a/fa/README.md +++ b/fa/README.md @@ -1,27 +1,47 @@ # تفسیر HTTP/3 -نوشتن این کتاب در ماه مارس سال ۲۰۱۸ آغاز شده و هدف مستندسازی HTTP/3 و پروتکل آن است: QUIC. چرایی‌ها، نحوه کارکرد، راه‌اندازی و غیره. +نوشتن این کتاب در ماه مارس سال ۲۰۱۸ آغاز شده و هدف مستندسازی HTTP/3 و پروتکل آن +است: QUIC. چرایی‌ها، نحوه کارکرد، راه‌اندازی و غیره. -این کتاب به صورت کامل رایگان و مبتنی بر همکاری است، بدین صورت که هر کسی مایل باشد می‌تواند یاری برساند. +این کتاب به صورت کامل رایگان و مبتنی بر همکاری است، بدین صورت که هر کسی مایل +باشد می‌تواند یاری برساند. ## پیش‌نیازها -از خواننده‌ی این کتاب انتظار می‌رود درک پایه‌ی از TCP/IP و شبکه، اصول اولیه‌ی HTTP و وِب داشته باشد. برای درک و بدست آوردن دیدی بهتر در خصوص HTTP/2 مطالعه‌ی [http2 explained](https://daniel.haxx.se/http2/) پیشنهاد می‌شود. +از خواننده‌ی این کتاب انتظار می‌رود درک پایه‌ی از TCP/IP و شبکه، +اصول اولیه‌ی HTTP و وِب داشته باشد. برای درک و بدست آوردن دیدی بهتر در خصوص +HTTP/2 مطالعه‌ی [http2 explained](https://daniel.haxx.se/http2/) پیشنهاد +می‌شود. ## نویسنده -این کتاب توسط [دنیل استنبرگ](https://daniel.haxx.se/) تهیه، ارائه و آغاز شده است. دنیل پایه‌گذار و توسعه‌دهنده ارشد [curl](https://curl.haxx.se/)، رایج‌ترین ابزارِ استفاده شده به عنوان HTTP client است. دنیل بیش از دو دهه با - و بر روی - پروتکل‌های HTTP و Internet کار کرده و همچنین نویسنده‌ی کتاب [http2 explained](https://daniel.haxx.se/http2/) است. +این کتاب توسط [دنیل استنبرگ](https://daniel.haxx.se/) تهیه، ارائه و آغاز شده +است. دنیل پایه‌گذار و توسعه‌دهنده ارشد [curl](https://curl.haxx.se/)، +رایج‌ترین ابزارِ استفاده شده به عنوان HTTP client است. دنیل بیش از دو دهه با +- و بر روی - پروتکل‌های HTTP و Internet کار کرده و همچنین نویسنده‌ی +کتاب [http2 explained](https://daniel.haxx.se/http2/) است. ## خانه -صفحه‌ی اصلی این کتاب قابل دسترس در [daniel.haxx.se/http3-explained](https://daniel.haxx.se/http3-explained) است. +صفحه‌ی اصلی این کتاب قابل دسترس در +[daniel.haxx.se/http3-explained](https://daniel.haxx.se/http3-explained) است. ## یاری‌رسانی -در صورت مشاهده‌ی هر گونه اشتباه، سهو و از قلم‌افتادگی، مشکل و یا موردی در نحوه‌ی نوشتار و یا نگارش، خواهشمند است نسخه‌ای اصلاح‌شده از پاراگراف مربوطه را برای ما ارسال کنید تا آن را اعمال و به روز کنیم. همچنین از هرکس که یاری رساند به صورت رسمی تقدیر به جا آورده خواهد شد. به امید بهتر کردن و کامل‌تر ساختن این دبیزه. +در صورت مشاهده‌ی هر گونه اشتباه، سهو و از قلم‌افتادگی، مشکل و یا موردی +در نحوه‌ی نوشتار و یا نگارش، خواهشمند است نسخه‌ای اصلاح‌شده از +پاراگراف مربوطه را برای ما ارسال کنید تا آن را اعمال و به روز کنیم. همچنین از +هرکس که یاری رساند به صورت رسمی تقدیر به جا آورده خواهد شد. به امید بهتر کردن و +کامل‌تر ساختن این دبیزه. -ترجیحا، یا مشکل مربوطه را در [errors](https://github.com/bagder/http3-explained/issues) و یا بر روی صفحه‌ی اصلی کتاب به عنوان درخواست [pull requests](https://github.com/bagder/http3-explained/pulls) ثبت کنید. +ترجیحا، یا مشکل مربوطه را در +[errors](https://github.com/bagder/http3-explained/issues) و یا بر روی +صفحه‌ی اصلی کتاب به عنوان درخواست [pull +requests](https://github.com/bagder/http3-explained/pulls) ثبت کنید. ## پروانه -این دبیزه و تمامی متعلقات تحت نسخه چهارم اجازه‌نامهٔ مشترکات خلاقانه (Creative Commons) به انتشار رسیده است. برای کسب اطلاعات بیشتر، به صفحه‌ی [Creative Commons Attribution 4.0 license](https://creativecommons.org/licenses/by/4.0/) مراجعه کنید. +این دبیزه و تمامی متعلقات تحت نسخه چهارم اجازه‌نامهٔ مشترکات خلاقانه +(Creative Commons) به انتشار رسیده است. برای کسب اطلاعات بیشتر، به صفحه‌ی +[Creative Commons Attribution 4.0 +license](https://creativecommons.org/licenses/by/4.0/) مراجعه کنید. diff --git a/fa/criticism.md b/fa/criticism.md index 305bc307..7137db7e 100644 --- a/fa/criticism.md +++ b/fa/criticism.md @@ -2,30 +2,57 @@ ## پروتکل UDP هرگز کار نخواهد کرد -بسیاری از شرکت‌ها، اپراتور‌ها و سازمان‌ها ترافیک UDP خارج از پورت ۵۳ (استفاده شده برای DNS) را از آنجایی که امروزه بیشتر در جهت حمله‌ها مورد سو‌ءاستفاده قرار می‌گیرد مسدود و یا محدود می‌کنند. همچنین به طور خاص، برخی از پروتکل‌های UDP موجود و سرور‌های پیاده‌سازی شده‌ی حاضر برای آنها در برابر حملات تقویت شده و بسیط که در آن یک حمله کننده می‌تواند ترافیک سنگینی را سمت یک هدف بی‌گناه مورد هدف‌گیری قرار می‌دهد آسیب پذیر و قابل حمله بوده است. - -پروتکل QUIC یک کاهش‌دهنده‌ی‌‌ داخلی در برابر چنین حملات تقویت شده‌ای دارد، بدین ترتیب که بسته‌ اولیه بایست حداقل ۱۲۰۰ بایت باشد و با این محدودیت که یک سرور اجازه ندارد در ازای هر پاسخ بیش از سه برابر از حجم درخواست را ارسال کند بدون آنکه ابتدا در پاسخ از سمت کاربر بسته‌ای دریافت کند. +بسیاری از شرکت‌ها، اپراتور‌ها و سازمان‌ها ترافیک UDP خارج از پورت +۵۳ (استفاده شده برای DNS) را از آنجایی که امروزه بیشتر در جهت حمله‌ها مورد +سو‌ءاستفاده قرار می‌گیرد مسدود و یا محدود می‌کنند. همچنین به طور +خاص، برخی از پروتکل‌های UDP موجود و سرور‌های پیاده‌سازی +شده‌ی حاضر برای آنها در برابر حملات تقویت شده و بسیط که در آن یک حمله کننده +می‌تواند ترافیک سنگینی را سمت یک هدف بی‌گناه مورد هدف‌گیری قرار +می‌دهد آسیب پذیر و قابل حمله بوده است. + +پروتکل QUIC یک کاهش‌دهنده‌ی‌‌ داخلی در برابر چنین حملات تقویت +شده‌ای دارد، بدین ترتیب که بسته‌ اولیه بایست حداقل ۱۲۰۰ بایت باشد و با +این محدودیت که یک سرور اجازه ندارد در ازای هر پاسخ بیش از سه برابر از حجم +درخواست را ارسال کند بدون آنکه ابتدا در پاسخ از سمت کاربر بسته‌ای دریافت +کند. ## پروتکل UDP در کرنل کند است -که به نظر درست می‌رسد، حداقل امروزه در ۲۰۱۸. ما نمی‌توانیم به ضرس قاطع بگوییم که این مسأله چگونه توسعه می‌یابد و چقدر از آن نتیجه‌ی سالیان در دیدرسِ توسعه دهندگان نبودنِ کیفیت انتقال در UDP است. +که به نظر درست می‌رسد، حداقل امروزه در ۲۰۱۸. ما نمی‌توانیم به ضرس قاطع +بگوییم که این مسأله چگونه توسعه می‌یابد و چقدر از آن نتیجه‌ی سالیان در +دیدرسِ توسعه دهندگان نبودنِ کیفیت انتقال در UDP است. برای اکثر کاربران این کندی هرگز قابل مشاهده نمی‌باشد. ## پروتکل QUIC مقدار قابل توجهی CPU مصرف می‌کند -همانند قسمت بالا، دلیل از آن روست که TCP و TLS زمان بیشتری برای بالغ شدن، بهبود یافتن و پشتیبانی سخت افزاری است. +همانند قسمت بالا، دلیل از آن روست که TCP و TLS زمان بیشتری برای بالغ شدن، بهبود +یافتن و پشتیبانی سخت افزاری است. -دلایلی وجود دارد که می‌توان انتظار بهبود این مورد را در طول زمان داشت. سوال این است که تا چه اندازه این کارکردِ CPU استفاده‌کنندگان را آزار خواهد داد. +دلایلی وجود دارد که می‌توان انتظار بهبود این مورد را در طول زمان داشت. سوال +این است که تا چه اندازه این کارکردِ CPU استفاده‌کنندگان را آزار خواهد داد. ## این فقط Google است -نه اینطور نیست. Google مشخصات اولیه را به IETF (کارگروه مهندسی اینترنت) آورد - بعد از آنکه در یک مقیاس بزرگ اینترنتی ثابت کرد راه‌اندازی چنین پروتکلی بر روی بستر UDP در واقع بسیار خوب عمل می‌کند. +نه اینطور نیست. Google مشخصات اولیه را به IETF (کارگروه مهندسی اینترنت) آورد - +بعد از آنکه در یک مقیاس بزرگ اینترنتی ثابت کرد راه‌اندازی چنین پروتکلی بر +روی بستر UDP در واقع بسیار خوب عمل می‌کند. -از آن موقع، افراد از شرکت‌ها و سازمان‌های متعددی در سازمان تأمین کننده بی‌طرفِ IETF گرد هم آمدند تا یک پروتکل انتقال استاندارد ایجاد کنند. در این کار، کارمندانِ Google بی‌شک حضور داشتند اما در کنارشان تعداد زیادی از کارمندان شرکت‌های دیگر نیز نقش داشتند که تلاششان بر این بود تا جایگاه پروتکل‌های انتقال در اینترنت را به جلو ببرند، از جلمه Mozilla، Fastly، Cloudflare، Akamai، Microsoft، Facebook و Apple. +از آن موقع، افراد از شرکت‌ها و سازمان‌های متعددی در سازمان تأمین کننده +بی‌طرفِ IETF گرد هم آمدند تا یک پروتکل انتقال استاندارد ایجاد کنند. در این +کار، کارمندانِ Google بی‌شک حضور داشتند اما در کنارشان تعداد زیادی از +کارمندان شرکت‌های دیگر نیز نقش داشتند که تلاششان بر این بود تا جایگاه +پروتکل‌های انتقال در اینترنت را به جلو ببرند، از جلمه Mozilla، Fastly، +Cloudflare، Akamai، Microsoft، Facebook و Apple. ## این پیشرفت بسیار کوچک است -این یک نقد نیست بلکه یک نظر است. شاید همینطور باشد، شاید این یک پیشرفت خیلی کوچک و با توجه به هنگامی که HTTP/2 ارائه شد باشد. +این یک نقد نیست بلکه یک نظر است. شاید همینطور باشد، شاید این یک پیشرفت خیلی کوچک +و با توجه به هنگامی که HTTP/2 ارائه شد باشد. -احتمالاً HTTP/3 در شبکه‌هایی که از دست رفتگی بسته زیاد است بهتر عمل می‌کند، همچنین handshake سریع‌تری را پیشنهاد می‌کند و در نتیجه تأخیر را چه در تشخیص و چه در حقیقت بهبود خواهد یافت. اما آیا این امکانات و مزایا برای ترغیب و تهییج مردم کافیست تا پشتیبانی این پروتکل را روی سرور‌ها و سرویس‌های خود اضافه کنند؟ بی‌شک زمان و اندازه‌گیری کیفی در آینده به ما خواهد گفت! +احتمالاً HTTP/3 در شبکه‌هایی که از دست رفتگی بسته زیاد است بهتر عمل +می‌کند، همچنین handshake سریع‌تری را پیشنهاد می‌کند و در نتیجه +تأخیر را چه در تشخیص و چه در حقیقت بهبود خواهد یافت. اما آیا این امکانات و مزایا +برای ترغیب و تهییج مردم کافیست تا پشتیبانی این پروتکل را روی سرور‌ها و +سرویس‌های خود اضافه کنند؟ بی‌شک زمان و اندازه‌گیری کیفی در آینده +به ما خواهد گفت! diff --git a/fa/feature-handshakes.md b/fa/feature-handshakes.md index e191f3f0..0918eb6f 100644 --- a/fa/feature-handshakes.md +++ b/fa/feature-handshakes.md @@ -1,7 +1,15 @@ # دست‌دهی‌های سریع -پروتکل QUIC نحوه اتصال 0-RTT و 1-RTT را ارائه می‌دهد، بدین معنا که در بهترین حالت QUIC نیازی به round-trip اضافی به هنگام برقراری اتصال ندارد. روش سریع‌تر بین این دو، دست‌دهی 0-RTT، تنها زمانی کار می‌کند که یک اتصال از قبل با یک میزبان برقرار شده باشد و یک secret از آن اتصال cache شده باشد. +پروتکل QUIC نحوه اتصال 0-RTT و 1-RTT را ارائه می‌دهد، بدین معنا که در +بهترین حالت QUIC نیازی به round-trip اضافی به هنگام برقراری اتصال ندارد. روش +سریع‌تر بین این دو، دست‌دهی 0-RTT، تنها زمانی کار می‌کند که یک +اتصال از قبل با یک میزبان برقرار شده باشد و یک secret از آن اتصال cache شده +باشد. ## داده اولیه -پروتکل QUIC به کارخواه اجازه می‌دهد تا داده‌ی موجود از دست‌دهی 0-RTT را شامل شود. این ویژگی به مخاطب این امکان را می‌دهد تا داده را هر چه سریع‌تر به همتای خود برساند، و البته همچنین سپس این امکان را به سرور می‌دهد تا حتی پاسخ‌دهی و ارسال داده در مرحله‌ی برگشت را زودتر انجام دهد. +پروتکل QUIC به کارخواه اجازه می‌دهد تا داده‌ی موجود از دست‌دهی +0-RTT را شامل شود. این ویژگی به مخاطب این امکان را می‌دهد تا داده را هر چه +سریع‌تر به همتای خود برساند، و البته همچنین سپس این امکان را به سرور +می‌دهد تا حتی پاسخ‌دهی و ارسال داده در مرحله‌ی برگشت را زودتر +انجام دهد. diff --git a/fa/feature-http.md b/fa/feature-http.md index 4f4b9dca..c03f5cef 100644 --- a/fa/feature-http.md +++ b/fa/feature-http.md @@ -1,5 +1,11 @@ ## پروتکل انتقال ابرمتن نگارش ۳ (HTTP/3) بر روی QUIC -در لایه‌ی HTTP، به نام HTTP/3، ترابردها به شیوه HTTP انجام می‌شود، مانند فشرده سازی سرایندها با استفاده از QPACK - که مشابه فشرده سازی سرایندها در HTTP/2 به نام HPACK است. +در لایه‌ی HTTP، به نام HTTP/3، ترابردها به شیوه HTTP انجام می‌شود، +مانند فشرده سازی سرایندها با استفاده از QPACK - که مشابه فشرده سازی سرایندها در +HTTP/2 به نام HPACK است. -الگوریتم HPACK وابسته به توزیع مرتبِ جریان‌هاست و در نتیجه امکان استفاده دوباره از آن در HTTP/3 بدون اعمال اصلاحات مقدور نبود، چرا که QUIC جریان‌هایی را ارائه می‌دهد که می‌توانند به صورت نامنظم تحویل داده شوند. QPACK را می‌توان نسخه‌‌ی سازوار با QUIC از [HPACK](https://httpwg.org/specs/rfc7541.html) در نظر گرفت. +الگوریتم HPACK وابسته به توزیع مرتبِ جریان‌هاست و در نتیجه امکان استفاده +دوباره از آن در HTTP/3 بدون اعمال اصلاحات مقدور نبود، چرا که QUIC جریان‌هایی +را ارائه می‌دهد که می‌توانند به صورت نامنظم تحویل داده شوند. QPACK را +می‌توان نسخه‌‌ی سازوار با QUIC از +[HPACK](https://httpwg.org/specs/rfc7541.html) در نظر گرفت. diff --git a/fa/feature-inorder.md b/fa/feature-inorder.md index 317caf60..e39d7ad6 100644 --- a/fa/feature-inorder.md +++ b/fa/feature-inorder.md @@ -1,9 +1,19 @@ ## توزیع منظم -پروتکل QUIC تحویل/توزیع منظم و کامل جریان‌ها را تضمین می‌کند، اما نه مابین جریان‌ها. بدین معنا که هر جریان داده را می‌فرستد و ترتیبش را حفظ می‌کند، اما هر جریانی ممکن است که با ترتیبی متفاوت از آنچه که نرم‌افزار فرستاده است به مقصد برسد! +پروتکل QUIC تحویل/توزیع منظم و کامل جریان‌ها را تضمین می‌کند، اما نه +مابین جریان‌ها. بدین معنا که هر جریان داده را می‌فرستد و ترتیبش را حفظ +می‌کند، اما هر جریانی ممکن است که با ترتیبی متفاوت از آنچه که +نرم‌افزار فرستاده است به مقصد برسد! -بطور مثال: جریان‌های A و B از یک سرور به یک کارخواه منتقل شده‌اند. جریان A نسبت به جریان B تقدم دارد. در QUIC، یک بسته‌ی گمشده تنها همان جریانی را که به آن تعلق دارد تحت تاثیر قرار می‌دهد. اگر جریان A یک بسته را گم ‌کند اما جریان B خیر، جریان B می‌تواند انتقال خود را ادامه دهد و تکمیل کند در حالیکه بسته‌ گمشده‌ی جریان A دوباره فرستاده می‌شود. چنین چیزی در HTTP/2 مقدور نبود. +بطور مثال: جریان‌های A و B از یک سرور به یک کارخواه منتقل شده‌اند. +جریان A نسبت به جریان B تقدم دارد. در QUIC، یک بسته‌ی گمشده تنها همان +جریانی را که به آن تعلق دارد تحت تاثیر قرار می‌دهد. اگر جریان A یک بسته را +گم ‌کند اما جریان B خیر، جریان B می‌تواند انتقال خود را ادامه دهد و +تکمیل کند در حالیکه بسته‌ گمشده‌ی جریان A دوباره فرستاده می‌شود. +چنین چیزی در HTTP/2 مقدور نبود. -در تصویر زیر یک جریان زرد و یک جریان آبی مابین دو پایانه‌ی QUIC بر روی یک اتصال فرستاده شده است. آنها مستقل‌ هستند و می‌توانند با ترتیبی متفاوت برسند، اما هر جریان دقیقاً به ترتیب تحویل نرم‌افزار داده می‌شود. +در تصویر زیر یک جریان زرد و یک جریان آبی مابین دو پایانه‌ی QUIC بر روی یک +اتصال فرستاده شده است. آنها مستقل‌ هستند و می‌توانند با ترتیبی متفاوت +برسند، اما هر جریان دقیقاً به ترتیب تحویل نرم‌افزار داده می‌شود. ![two QUIC streams between two computers](../images/quic-chain-streams.png) diff --git a/fa/feature-nonhttp.md b/fa/feature-nonhttp.md index 3fa03c06..a6ffd727 100644 --- a/fa/feature-nonhttp.md +++ b/fa/feature-nonhttp.md @@ -1,3 +1,4 @@ ## غیر HTTP بر روی QUIC -کار بر روی انتقال پروتکل‌هایی به غیر از HTTP بر روی بستر QUIC تا بعد از توزیع اولین نسخه‌ی ‌آن به تعویق افتاده است. +کار بر روی انتقال پروتکل‌هایی به غیر از HTTP بر روی بستر QUIC تا بعد از +توزیع اولین نسخه‌ی ‌آن به تعویق افتاده است. diff --git a/fa/feature-reliable.md b/fa/feature-reliable.md index 494361db..19fff814 100644 --- a/fa/feature-reliable.md +++ b/fa/feature-reliable.md @@ -1,5 +1,8 @@ ## انتقال داده‌های مطمئن -در حالی که UDP روش انتقال مطمئنی نیست، QUIC لایه‌ای بالای UDP قرار می‌دهد که موجب قابلیت اطمینان می‌شود. انتقال مجدد بسته‌ها، نظارت تراکم، pacing و امکانات دیگری که در TCP موجود است بدین جهت ارائه می‌شود. +در حالی که UDP روش انتقال مطمئنی نیست، QUIC لایه‌ای بالای UDP قرار +می‌دهد که موجب قابلیت اطمینان می‌شود. انتقال مجدد بسته‌ها، نظارت +تراکم، pacing و امکانات دیگری که در TCP موجود است بدین جهت ارائه می‌شود. -داده‌ا‌ی که از طریق QUIC از یک پایانه ارسال شده است دیر یا زود در پایانه دیگر ظاهر خواهد شد، تا زمانی که اتصال برقرار بماند. +داده‌ا‌ی که از طریق QUIC از یک پایانه ارسال شده است دیر یا زود در +پایانه دیگر ظاهر خواهد شد، تا زمانی که اتصال برقرار بماند. diff --git a/fa/feature-streams.md b/fa/feature-streams.md index 5b2e8562..be1fd76d 100644 --- a/fa/feature-streams.md +++ b/fa/feature-streams.md @@ -1,11 +1,20 @@ ## جریان‌های متعدد درون اتصالات -همانند SCTP، SSH و HTTP/2، پروتکل QUIC شامل جریان‌های منطقی‌ جداگانه‌ای درون اتصال‌های فیزیکی است. تعدادی از جریان‌های موازی که می‌توانند بدون آنکه جریان‌های دیگر را تحت تاثیر قرار دهند بطور همزمان انتقال داده بر روی یک اتصال واحد را انجام دهند. +همانند SCTP، SSH و HTTP/2، پروتکل QUIC شامل جریان‌های منطقی‌ +جداگانه‌ای درون اتصال‌های فیزیکی است. تعدادی از جریان‌های موازی +که می‌توانند بدون آنکه جریان‌های دیگر را تحت تاثیر قرار دهند بطور +همزمان انتقال داده بر روی یک اتصال واحد را انجام دهند. -یک اتصال یک چیدمانِ مذاکره شده بین دو پایانه است همانند حالتی که یک اتصال TCP کار می‌کند. یک اتصال QUIC به یک پورت UDP و آدرس IP انجام می‌گیرد، اما پس از برقراری ارتباط آن اتصال توسط "شناسه‌ی اتصال" شناخته می‌شود. +یک اتصال یک چیدمانِ مذاکره شده بین دو پایانه است همانند حالتی که یک اتصال TCP کار +می‌کند. یک اتصال QUIC به یک پورت UDP و آدرس IP انجام می‌گیرد، اما پس +از برقراری ارتباط آن اتصال توسط "شناسه‌ی اتصال" شناخته می‌شود. -بر روی یک اتصال برقرار شده، هردو طرف می‌توانند جریانی بسازند و داده را به پایانه دیگر انتقال دهند. جریان‌ها به شکلی مرتب دریافت می‌شوند و قابل اطمینان هستند، اما جریان‌های مختلف می‌توانند نامنظم دریافت شوند. +بر روی یک اتصال برقرار شده، هردو طرف می‌توانند جریانی بسازند و داده را به +پایانه دیگر انتقال دهند. جریان‌ها به شکلی مرتب دریافت می‌شوند و قابل +اطمینان هستند، اما جریان‌های مختلف می‌توانند نامنظم دریافت شوند. -پروتکل QUIC کنترل جریان بر روی هر دوی اتصال و جریان‌ها را ارائه می‌دهد. +پروتکل QUIC کنترل جریان بر روی هر دوی اتصال و جریان‌ها را ارائه +می‌دهد. -جزئیات بیشتر را در بخش‌های [اتصال‌ها](quic-connections.md) و [جریان‌ها](quic-streams.md) ببینید. +جزئیات بیشتر را در بخش‌های [اتصال‌ها](quic-connections.md) و +[جریان‌ها](quic-streams.md) ببینید. diff --git a/fa/feature-tls.md b/fa/feature-tls.md index 0cb76fa5..83aaedd0 100644 --- a/fa/feature-tls.md +++ b/fa/feature-tls.md @@ -1,7 +1,12 @@ ## پروتکل TLS 1.3 -امنیت انتقال استفاده شده در QUIC از TLS 1.3 استفاده می‌کند ([RFC 8446](https://tools.ietf.org/html/rfc8446)) و هرگز هیچ اتصال رمزگذاری نشده‌ای در QUIC وجود ندارد. +امنیت انتقال استفاده شده در QUIC از TLS 1.3 استفاده می‌کند ([RFC +8446](https://tools.ietf.org/html/rfc8446)) و هرگز هیچ اتصال رمزگذاری +نشده‌ای در QUIC وجود ندارد. -پروتکل TLS 1.3 نسبت به نسخه‌های پیشین TLS برتری‌هایی دارد که البته دلیل اصلی استفاده از آن در QUIC اینست که نسخه‌ی ۱.۳ دست‌دهی را به نحوی تغییر داده است تا شامل roundtrip های کمتری باشد. این امر تاخیر در پروتکل را کاهش می‌دهد. +پروتکل TLS 1.3 نسبت به نسخه‌های پیشین TLS برتری‌هایی دارد که البته +دلیل اصلی استفاده از آن در QUIC اینست که نسخه‌ی ۱.۳ دست‌دهی را به نحوی +تغییر داده است تا شامل roundtrip های کمتری باشد. این امر تاخیر در پروتکل را کاهش +می‌دهد. نسخه‌ی پیشین QUIC گوگل از یک رمزنگاری سفارشی استفاده می‌کرد. diff --git a/fa/feature-trans-app.md b/fa/feature-trans-app.md index 7acd6ff2..07c33fdc 100644 --- a/fa/feature-trans-app.md +++ b/fa/feature-trans-app.md @@ -1,7 +1,11 @@ ## سطح انتقال و کاربرد -پروتکل IETF QUIC یک پروتکل انتقال است، که در بالای آن پروتکل‌‌های کاربرد دیگر می‌توانند استفاده شوند. پروتکل اولیه لایه‌ی کاربرد HTTP/3 - یا (h3) - است. +پروتکل IETF QUIC یک پروتکل انتقال است، که در بالای آن پروتکل‌‌های +کاربرد دیگر می‌توانند استفاده شوند. پروتکل اولیه لایه‌ی کاربرد HTTP/3 - +یا (h3) - است. لایه‌ انتقال از اتصال‌ها و جریان‌ها پشتیبانی می‌کند. -نسخه‌ی پیشین QUIC گوگل، انتقال و HTTP را همراه با یکدیگر به شکلی همه‌کاره دارا بود و بیشتر یک پروتکل ارسالِ قاب‌های (frame) پروتکل HTTP/2 بر روی UDP با هدف خاص بود. +نسخه‌ی پیشین QUIC گوگل، انتقال و HTTP را همراه با یکدیگر به شکلی +همه‌کاره دارا بود و بیشتر یک پروتکل ارسالِ قاب‌های (frame) پروتکل +HTTP/2 بر روی UDP با هدف خاص بود. diff --git a/fa/feature-udp.md b/fa/feature-udp.md index ba65d147..fe0e02c1 100644 --- a/fa/feature-udp.md +++ b/fa/feature-udp.md @@ -1,17 +1,34 @@ ## پروتکل انتقال روی UDP -پروتکل QUIC یک پروتکل انتقال پیاده‌سازی شده بر روی UDP است. اگر گاهی ترافیک شبکه‌ی خود‌ را زیر نظر بگیرید، می‌بیند که QUIC به شکل بسته‌های UDP نمایان می‌شود. +پروتکل QUIC یک پروتکل انتقال پیاده‌سازی شده بر روی UDP است. اگر گاهی ترافیک +شبکه‌ی خود‌ را زیر نظر بگیرید، می‌بیند که QUIC به شکل +بسته‌های UDP نمایان می‌شود. -بر اساس UDP، این پروتکل نیز از شماره پورت‌های UDP برای شناسایی سرویس‌های مشخصِ شبکه روی یک آدرس IP خاص استفاده می‌کند. +بر اساس UDP، این پروتکل نیز از شماره پورت‌های UDP برای شناسایی +سرویس‌های مشخصِ شبکه روی یک آدرس IP خاص استفاده می‌کند. -تمام پیاده‌سازی‌های شناخته شده‌ی QUIC در حال حاضر در فضای کاربری هستند چرا که این امر منجر به بالا رفتن سرعت توسعه نسبت به آن چیزی خواهد بود که فضای هسته برای پیاده‌سازی‌ اجازه خواهد داد. +تمام پیاده‌سازی‌های شناخته شده‌ی QUIC در حال حاضر در فضای کاربری +هستند چرا که این امر منجر به بالا رفتن سرعت توسعه نسبت به آن چیزی خواهد بود که +فضای هسته برای پیاده‌سازی‌ اجازه خواهد داد. ## آیا کارساز خواهد بود؟ -شرکت‌ها و دیگر نهادهای شبکه‌ای وجود دارند که ترافیک UDP روی پورت‌های غیر از ۵۳ (که برای DNS استفاده می‌شود) را مسدود می‌کنند. دیگری‌ها نیز داده‌ها را به گونه‌ای محدود می‌کنند که باعث می‌شود QUIC از پروتکل‌های مبتنی بر TCP هم بدتر عمل کند. پایانی برای کارهای برخی از اپراتورها نیست. +شرکت‌ها و دیگر نهادهای شبکه‌ای وجود دارند که ترافیک UDP روی +پورت‌های غیر از ۵۳ (که برای DNS استفاده می‌شود) را مسدود می‌کنند. +دیگری‌ها نیز داده‌ها را به گونه‌ای محدود می‌کنند که باعث +می‌شود QUIC از پروتکل‌های مبتنی بر TCP هم بدتر عمل کند. پایانی برای +کارهای برخی از اپراتورها نیست. -تا آن‌جایی که می‌توان آینده را پیش‌بینی کرد، شاید تمام استفاده‌های انتقال‌های مبتنی بر QUIC باید بتوانند به طور خوشایند به دیگر جایگزین‌ها (مبتنی بر TCP) بازگردند. مهندس‌های گوگل پیشتر نرخِ شکست در درصدهای تک‌رقمیِ پایین را پیش‌بینی کرده‌اند. +تا آن‌جایی که می‌توان آینده را پیش‌بینی کرد، شاید تمام +استفاده‌های انتقال‌های مبتنی بر QUIC باید بتوانند به طور خوشایند به +دیگر جایگزین‌ها (مبتنی بر TCP) بازگردند. مهندس‌های گوگل پیشتر نرخِ شکست +در درصدهای تک‌رقمیِ پایین را پیش‌بینی کرده‌اند. ## آیا پیشرفت خواهد کرد؟ - اگر ثابت شود QUIC چیزی با ارزش به دنیای اینترنت اضافه می‌کند، آن‌وقت احتمال دارد افراد بخواهند از آن استفاده کنند و در نتیجه بخواهند تا آن در شبکه‌هایشان کار کند و بدین ترتیب ممکن است شرکت‌ها شروع به بازنگری و بررسی موانع موجودِ خود کنند. در طول سال‌هایی که توسعه‌ی QUIC پیشرفت کرده، نرخ موفقیت برای ایجاد و استفاده‌ی اتصال‌های QUIC در اینترنت افزایش یافته است. + اگر ثابت شود QUIC چیزی با ارزش به دنیای اینترنت اضافه می‌کند، آن‌وقت + احتمال دارد افراد بخواهند از آن استفاده کنند و در نتیجه بخواهند تا آن در + شبکه‌هایشان کار کند و بدین ترتیب ممکن است شرکت‌ها شروع به بازنگری و + بررسی موانع موجودِ خود کنند. در طول سال‌هایی که توسعه‌ی QUIC پیشرفت + کرده، نرخ موفقیت برای ایجاد و استفاده‌ی اتصال‌های QUIC در اینترنت + افزایش یافته است. diff --git a/fa/h3-altsvc.md b/fa/h3-altsvc.md index 0126bbc2..1e0d06cb 100644 --- a/fa/h3-altsvc.md +++ b/fa/h3-altsvc.md @@ -1,10 +1,24 @@ # سرایندِ Alt-svc -سرایندِ خدمات جایگزین (:Alt-svc) و چهارچوبِ متناظر `ALT-SVC` آن در HTTP/2 منحصراً برای QUIC یا HTTP/3 ساخته نشده‌اند. آنها بخشی از مکانیزمی از پیش طراحی و ساخته شده‌ برای سروری هستند که به کارخواه بگوید: *"نگاه کن، من دارم همین سرویس مشابه را روی این میزبان با استفاده از این پروتکل بر روی این درگاه اجرا می‌کنم"*. جزئیات را در [RFC 7838](https://tools.ietf.org/html/rfc7838) ببینید. - -کارخواهی که چنین پاسخ Alt-svc را دریافت می‌کند بهش پیشنهاد می‌شود که، اگر پشتیبانی می‌کند و می‌خواهد، به آن میزبانِ دیگر بطور موازی در پس زمینه متصل گردد - با استفاده از پروتکل مشخص شده - و چنانکه موفقیت‌آمیز باشد عملیاتش را به جای اتصال اولیه بر روی آن تغییر دهد. - -اگر اتصال اولیه از HTTP/2 یا حتی HTTP/1 استفاده کند، سرور می‌تواند پاسخ بدهد و به کارخواه بگوید که می‌تواند دوباره متصل شود و HTTP/3 را امتحان کند. این می‌تواند به سمت همان میزبان یا دیگر میزبانی که می‌داند چگونه به آن خاستگاه خدمت کند باشد. اطلاعاتی که در چنین پاسخ Alt-svc داده شده است دارای زمان سنجِ انقضا هستند که باعث می‌شود کارخواه‌ها بتوانند اتصال‌های سپسین و درخواست‌ها را با استفاده از پروتکل‌ جایگزینِ پیشنهادی یکراست به سمت میزبان برای زمانی مشخص‌ هدایت کنند. +سرایندِ خدمات جایگزین (:Alt-svc) و چهارچوبِ متناظر `ALT-SVC` آن در HTTP/2 منحصراً +برای QUIC یا HTTP/3 ساخته نشده‌اند. آنها بخشی از مکانیزمی از پیش طراحی و +ساخته شده‌ برای سروری هستند که به کارخواه بگوید: *"نگاه کن، من دارم همین +سرویس مشابه را روی این میزبان با استفاده از این پروتکل بر روی این درگاه اجرا +می‌کنم"*. جزئیات را در [RFC 7838](https://tools.ietf.org/html/rfc7838) +ببینید. + +کارخواهی که چنین پاسخ Alt-svc را دریافت می‌کند بهش پیشنهاد می‌شود که، +اگر پشتیبانی می‌کند و می‌خواهد، به آن میزبانِ دیگر بطور موازی در پس +زمینه متصل گردد - با استفاده از پروتکل مشخص شده - و چنانکه موفقیت‌آمیز باشد +عملیاتش را به جای اتصال اولیه بر روی آن تغییر دهد. + +اگر اتصال اولیه از HTTP/2 یا حتی HTTP/1 استفاده کند، سرور می‌تواند پاسخ +بدهد و به کارخواه بگوید که می‌تواند دوباره متصل شود و HTTP/3 را امتحان کند. +این می‌تواند به سمت همان میزبان یا دیگر میزبانی که می‌داند چگونه به آن +خاستگاه خدمت کند باشد. اطلاعاتی که در چنین پاسخ Alt-svc داده شده است دارای زمان +سنجِ انقضا هستند که باعث می‌شود کارخواه‌ها بتوانند اتصال‌های سپسین +و درخواست‌ها را با استفاده از پروتکل‌ جایگزینِ پیشنهادی یکراست به سمت +میزبان برای زمانی مشخص‌ هدایت کنند. ## نمونه @@ -12,6 +26,9 @@ Alt-Svc: h3=":50781" -این نشانگر این است که HTTP/3 بر روی درگاه UDP شماره ۵۰۷۸۱ با همان نام میزبانی که برای دریافت این پاسخ استفاده شده در دسترس است. +این نشانگر این است که HTTP/3 بر روی درگاه UDP شماره ۵۰۷۸۱ با همان نام میزبانی که +برای دریافت این پاسخ استفاده شده در دسترس است. -یک کارخواه بعد از آن می‌تواند اقدام به برقراری یک اتصال QUIC به سمت آن مقصد کند و اگر موفقیت آمیز بود، به جای نسخه اولیه HTTP همانطور به ارتباط برقرار کردن با خاستگاه ادامه دهد. +یک کارخواه بعد از آن می‌تواند اقدام به برقراری یک اتصال QUIC به سمت آن مقصد +کند و اگر موفقیت آمیز بود، به جای نسخه اولیه HTTP همانطور به ارتباط برقرار کردن +با خاستگاه ادامه دهد. diff --git a/fa/h3-h2.md b/fa/h3-h2.md index e2a0ab50..1bb71fb8 100644 --- a/fa/h3-h2.md +++ b/fa/h3-h2.md @@ -1,28 +1,45 @@ # پروتکل HTTP/3 در مقایسه با HTTP/2 -پروتکل HTTP/3 برای QUIC طراحی شده است، که پروتکل انتقالی است که به خودی خود جریان‌ها را مدیریت می‌کند. +پروتکل HTTP/3 برای QUIC طراحی شده است، که پروتکل انتقالی است که به خودی خود +جریان‌ها را مدیریت می‌کند. -پروتکل HTTP/2 برای TCP طراحی شده است، و در نتیجه جریان‌ها را در لایه‌ی HTTP مدیریت می‌کند. +پروتکل HTTP/2 برای TCP طراحی شده است، و در نتیجه جریان‌ها را در لایه‌ی +HTTP مدیریت می‌کند. ## شباهت‌ها -هر دوی پروتکل‌ها به کارخواهان مجموعه‌ای از ویژگی‌های کمابیش مشابه را ارائه می‌دهند. +هر دوی پروتکل‌ها به کارخواهان مجموعه‌ای از ویژگی‌های کمابیش مشابه +را ارائه می‌دهند. - هر دو پروتکل پشتیبانی از server push را ارائه می‌دهند -- هر دو پروتکل دارای فشرده سازی سرایند هستند، و QPACK و HPACK در طراحی شبیه هستند. +- هر دو پروتکل دارای فشرده سازی سرایند هستند، و QPACK و HPACK در طراحی شبیه + هستند. -- هر دو پروتکل توزیع بر روی یک تک-اتصال با استفاده از جریان‌ها را ارائه می‌دهند +- هر دو پروتکل توزیع بر روی یک تک-اتصال با استفاده از جریان‌ها را ارائه + می‌دهند ## تفاوت‌ها -تفاوت‌ها در جزئیات و عمدتاً در این حیطه هستند به لطف استفاده‌ی HTTP/3 از QUIC: +تفاوت‌ها در جزئیات و عمدتاً در این حیطه هستند به لطف استفاده‌ی HTTP/3 +از QUIC: -- پروتکل HTTP/3 به لطف دست‌دهی 0-RTT پروتکلِ QUIC از داده‌ اولیه پشتیبانی بهتری می‌کند، هنگامیکه TCP Fast Open و TLS هماره داده کمتری ارسال می‌کنند و با مشکل مواجه می‌شوند. +- پروتکل HTTP/3 به لطف دست‌دهی 0-RTT پروتکلِ QUIC از داده‌ اولیه + پشتیبانی بهتری می‌کند، هنگامیکه TCP Fast Open و TLS هماره داده کمتری + ارسال می‌کنند و با مشکل مواجه می‌شوند. -- پروتکل HTTP/3 به لطف QUIC در مقایسه با TCP + TLS از دست‌دهی‌های به مراتب سریع‌تری برخوردار است. +- پروتکل HTTP/3 به لطف QUIC در مقایسه با TCP + TLS از دست‌دهی‌های به + مراتب سریع‌تری برخوردار است. -- پروتکل HTTP/3 در نسخه‌ی نا-امن و بدون رمزگذاری وجود ندارد. پروتکل HTTP/2 می‌تواند بدون HTTPS پیاده‌سازی و استفاده شود - اگرچه در اینترنت کمتر بدین شکل دیده می‌شود. +- پروتکل HTTP/3 در نسخه‌ی نا-امن و بدون رمزگذاری وجود ندارد. پروتکل HTTP/2 + می‌تواند بدون HTTPS پیاده‌سازی و استفاده شود - اگرچه در اینترنت کمتر + بدین شکل دیده می‌شود. -- پروتکل HTTP/2 می‌تواند مستقیم داخل یک دست‌دهی TLS با افزونه ALPN قرار بگیرد، حال آنکه HTTP/3 بر روی QUIC است و ازینرو ابتدا به یک پاسخ سرایند `Alt-Svc:` نیاز دارد تا کارخواه را از این عامل آگاه سازد. -- پروتکل HTTP/3 اولویت‌بندی ندارد. رویکرد HTTP/2 در اولویت‌بندی پییچده تلقی می‌شود، و یا حتی صرفاً یک شکست، لذا کار بر روی ساخت موردی ساده‌تر در جریان است. لین طرح ساده‌تر هم برنامه‌ریزی شده تا پیش‌انتقال بتواند با استفاده از مکانیزم پسوند HTTP/2 بر روی HTTP/2 اجرا شود. +- پروتکل HTTP/2 می‌تواند مستقیم داخل یک دست‌دهی TLS با افزونه ALPN + قرار بگیرد، حال آنکه HTTP/3 بر روی QUIC است و ازینرو ابتدا به یک پاسخ سرایند + `Alt-Svc:` نیاز دارد تا کارخواه را از این عامل آگاه سازد. +- پروتکل HTTP/3 اولویت‌بندی ندارد. رویکرد HTTP/2 در اولویت‌بندی پییچده + تلقی می‌شود، و یا حتی صرفاً یک شکست، لذا کار بر روی ساخت موردی + ساده‌تر در جریان است. لین طرح ساده‌تر هم برنامه‌ریزی شده تا + پیش‌انتقال بتواند با استفاده از مکانیزم پسوند HTTP/2 بر روی HTTP/2 اجرا + شود. diff --git a/fa/h3-https.md b/fa/h3-https.md index 538e1b3c..729d647c 100644 --- a/fa/h3-https.md +++ b/fa/h3-https.md @@ -1,13 +1,31 @@ # نشانی وب‌های HTTPS:// -پروتکل HTTP/3 با استفاده از (URL) نشانی وب‌های HTTPS:// اجرا می‌شود. جهان پر است از این نشانی وب‌ها و معرفی کردنِ طرحی جدید برای آن در پروتکل جدید غیر عملی و به طور کامل غیر منطقی تلقی شده است. همانطور که HTTP/2 نیاز به طرحی جدید نداشت، HTTP/3 نیز نیازی نخواهد داشت. +پروتکل HTTP/3 با استفاده از (URL) نشانی وب‌های HTTPS:// اجرا می‌شود. +جهان پر است از این نشانی وب‌ها و معرفی کردنِ طرحی جدید برای آن در پروتکل +جدید غیر عملی و به طور کامل غیر منطقی تلقی شده است. همانطور که HTTP/2 نیاز به +طرحی جدید نداشت، HTTP/3 نیز نیازی نخواهد داشت. -پیچیدگی اضافه شده در HTTP/3 مانند همان زمانی است که HTTP/2 گرچه روشی کاملاً‌ جدید برای انتقال HTTP بود، هنوز هم همچون HTTP/1 مبتنی بر TLS و TCP بود. این حقیقت که HTTP/3 بر بستر QUIC انجام گرفته است یک سری چیزها را در زوایای مهمی تغییر می‌دهد. +پیچیدگی اضافه شده در HTTP/3 مانند همان زمانی است که HTTP/2 گرچه روشی کاملاً‌ +جدید برای انتقال HTTP بود، هنوز هم همچون HTTP/1 مبتنی بر TLS و TCP بود. این +حقیقت که HTTP/3 بر بستر QUIC انجام گرفته است یک سری چیزها را در زوایای مهمی +تغییر می‌دهد. -چیزهایی مانند legacy و clear-text و نشانی وب‌های HTTP:// همانگونه که هستند باقی می‌مانند و آنگاه که ما بیشتر به سوی آینده‌ای با انتقال‌های امن‌تر می‌رویم آنها احتمالاً کمتر و کمتر مورد استفاده قرار می‌گیرند. درخواست‌ها به چنین نشانی وب‌هایی برای استفاده از HTTP/3 بروزرسانی نخواهند شد. در حقیقت آنها به HTTP/2 هم به ندرت بروزرسانی می‌شوند، اما به دلایلی دیگر. +چیزهایی مانند legacy و clear-text و نشانی وب‌های HTTP:// همانگونه که هستند +باقی می‌مانند و آنگاه که ما بیشتر به سوی آینده‌ای با انتقال‌های +امن‌تر می‌رویم آنها احتمالاً کمتر و کمتر مورد استفاده قرار +می‌گیرند. درخواست‌ها به چنین نشانی وب‌هایی برای استفاده از HTTP/3 +بروزرسانی نخواهند شد. در حقیقت آنها به HTTP/2 هم به ندرت بروزرسانی می‌شوند، +اما به دلایلی دیگر. ## اتصال اولیه -اولین اتصال به یک میزبان جدید و از قبل دیده نشده برای یک نشانی وبِ HTTPS:// احتمالاً ناچار است بر روی TCP صورت بگیرد (احتمالاً علاوه بر اقدامی موازی برای اتصال توسط QUIC). میزبان ممکن است یک کارگزار موروثی (قدیمی) و فاقد پشتیبانی QUIC باشد یا ممکن است دستگاهی میانی باشد که با ایجاد موانعی از یک اتصال موفقیت آمیزِ QUIC جلوگیری کند. +اولین اتصال به یک میزبان جدید و از قبل دیده نشده برای یک نشانی وبِ HTTPS:// +احتمالاً ناچار است بر روی TCP صورت بگیرد (احتمالاً علاوه بر اقدامی موازی برای اتصال +توسط QUIC). میزبان ممکن است یک کارگزار موروثی (قدیمی) و فاقد پشتیبانی QUIC باشد +یا ممکن است دستگاهی میانی باشد که با ایجاد موانعی از یک اتصال موفقیت آمیزِ QUIC +جلوگیری کند. -یک کارخواه و کارگزارِ امروزی احتمالاً در اولین دست‌دهی‌شان بر سرِ HTTP/2 مذاکره می‌کنند. هنگامی که اتصال برقرار شد و کارگزار به درخواستِ HTTP کارخواه پاسخ داد، کارگزار می‌تواند در مورد پشتیبانی خود از و ترجیحش برای HTTP/3 به کارخواه بگوید. +یک کارخواه و کارگزارِ امروزی احتمالاً در اولین دست‌دهی‌شان بر سرِ HTTP/2 +مذاکره می‌کنند. هنگامی که اتصال برقرار شد و کارگزار به درخواستِ HTTP کارخواه +پاسخ داد، کارگزار می‌تواند در مورد پشتیبانی خود از و ترجیحش برای HTTP/3 به +کارخواه بگوید. diff --git a/fa/h3-prio.md b/fa/h3-prio.md index 90518c93..f20d5c31 100644 --- a/fa/h3-prio.md +++ b/fa/h3-prio.md @@ -1,9 +1,14 @@ # اولویت بندی پروتکل HTTP/3 -یکی از قاب‌های جریان در 3/HTTP قاب PRIORITY است. این قاب برای وضع اولویت و وابستگی بر روی یک جریان، مشابه روشی که در 2/HTTP صورت می‌گیرد، استفاده شده است. +یکی از قاب‌های جریان در 3/HTTP قاب PRIORITY است. این قاب برای وضع اولویت و +وابستگی بر روی یک جریان، مشابه روشی که در 2/HTTP صورت می‌گیرد، استفاده شده +است. -این قاب می‌تواند جریانی مشخص را مقرر کند که وابسته به جریان مشخص دیگری باشد و میتواند بر روی یک جریان معین شده یک ”وزن“ اختصاص دهد. +این قاب می‌تواند جریانی مشخص را مقرر کند که وابسته به جریان مشخص دیگری باشد +و میتواند بر روی یک جریان معین شده یک ”وزن“ اختصاص دهد. -این قاب می‌تواند جریانی مشخص را مقرر کند که وابسته به جریان مشخص دیگری باشد و میتواند بر روی یک جریان معین شده یک ”وزن“ اختصاص دهد. +این قاب می‌تواند جریانی مشخص را مقرر کند که وابسته به جریان مشخص دیگری باشد +و میتواند بر روی یک جریان معین شده یک ”وزن“ اختصاص دهد. -مقدار وزنِ یک جریان بین ۱ تا ۲۵۶ هست و این مقرر شده است که جریان‌هایی که از یک والد هستند باید منابع متناسب با وزنشان به آنها تخصیص گردد. +مقدار وزنِ یک جریان بین ۱ تا ۲۵۶ هست و این مقرر شده است که جریان‌هایی که از +یک والد هستند باید منابع متناسب با وزنشان به آنها تخصیص گردد. diff --git a/fa/h3-push.md b/fa/h3-push.md index be40f988..26a3993d 100644 --- a/fa/h3-push.md +++ b/fa/h3-push.md @@ -1,15 +1,29 @@ # فشارِ سرورِ HTTP/3 -فشار سرور HTTP/3 شبیه به آن چیزیست که در HTTP/2 ([RFC 7540](https://httpwg.org/specs/rfc7540.html)) توصیف شده است، اما از ساز و کار متفاوتی بهره می‌گیرد. +فشار سرور HTTP/3 شبیه به آن چیزیست که در HTTP/2 ([RFC +7540](https://httpwg.org/specs/rfc7540.html)) توصیف شده است، اما از ساز و کار +متفاوتی بهره می‌گیرد. -یک فشار سرور (server push) در واقع پاسخ به درخواستی است که کارخواه هرگز ارسال نکرد! +یک فشار سرور (server push) در واقع پاسخ به درخواستی است که کارخواه هرگز ارسال +نکرد! -فشار‌های سرور تنها در صورتی ایجاد می‌شوند که از سمت کارخواه با آنها موافقت شده باشد. در HTTP/3 کارخواه حتی محدودیتی برای تعداد فشارهایی که قبول می‌کند با اعلام بیشترین شناسه‌ی جریانِ فشار برای کارساز ایجاد می‌کند. و از آن حد بالاتر رفتن موجب خطا در اتصال می‌گردد. +فشار‌های سرور تنها در صورتی ایجاد می‌شوند که از سمت کارخواه با آنها +موافقت شده باشد. در HTTP/3 کارخواه حتی محدودیتی برای تعداد فشارهایی که قبول +می‌کند با اعلام بیشترین شناسه‌ی جریانِ فشار برای کارساز ایجاد +می‌کند. و از آن حد بالاتر رفتن موجب خطا در اتصال می‌گردد. -حتی هنگامی که که از پیش گفته شده باشد که فشار‌ها توسط کارخواه مورد قبول هستند، هر جریانِ فشار می‌تواند در هر زمان که کارخواه صلاح بداند لغو گردد. که در این صورت یک قاب CANCEL_PUSH به سمت سرور فرستاده می‌شود. +حتی هنگامی که که از پیش گفته شده باشد که فشار‌ها توسط کارخواه مورد قبول +هستند، هر جریانِ فشار می‌تواند در هر زمان که کارخواه صلاح بداند لغو گردد. که +در این صورت یک قاب CANCEL_PUSH به سمت سرور فرستاده می‌شود. ## دشواری -از همان زمانی که این ویژگی برای نخستین بار در توسعه‌ی HTTP/2 مطرح شد و بعد‌تر که پروتکل بر روی بستر اینترنت توسعه پیدا کرد و توزیع شد، در خصوص این ویژگی بحث شد، انتقاد شد و به کرّات به روش‌های گوناگون مورد حمله قرار گرفت تا که به حالتی قابل استفاده درآید. +از همان زمانی که این ویژگی برای نخستین بار در توسعه‌ی HTTP/2 مطرح شد و +بعد‌تر که پروتکل بر روی بستر اینترنت توسعه پیدا کرد و توزیع شد، در خصوص این +ویژگی بحث شد، انتقاد شد و به کرّات به روش‌های گوناگون مورد حمله قرار گرفت تا +که به حالتی قابل استفاده درآید. -فشار هرگز ”رایگان“ نیست چرا که در ذخیره و نگاه‌داشت یک نیم round-trip هنوز هم از پهنای باند استفاده می‌کند. این معمولاً‌ برای سمت کارساز سخت یا ناممکن است که به درستی و با سطح بالایی از اطمینان بداند که یک منبع آیا به فشار نیاز دارد یا خیر. +فشار هرگز ”رایگان“ نیست چرا که در ذخیره و نگاه‌داشت یک نیم round-trip هنوز +هم از پهنای باند استفاده می‌کند. این معمولاً‌ برای سمت کارساز سخت یا +ناممکن است که به درستی و با سطح بالایی از اطمینان بداند که یک منبع آیا به فشار +نیاز دارد یا خیر. diff --git a/fa/h3-streams.md b/fa/h3-streams.md index cce93925..1242d789 100644 --- a/fa/h3-streams.md +++ b/fa/h3-streams.md @@ -1,12 +1,18 @@ # جریان‌های QUIC و پروتکل HTTP/3 -پروتکل HTTP/3 برای QUIC ساخته شده است، در نتیجه از مزایای جریان‌ها در QUIC بهره کامل می‌برد، در حالی که HTTP/2 مجبور بود تا کل جریان و مفهوم multiplexing خود را بر روی TCP طراحی کند. +پروتکل HTTP/3 برای QUIC ساخته شده است، در نتیجه از مزایای جریان‌ها در QUIC +بهره کامل می‌برد، در حالی که HTTP/2 مجبور بود تا کل جریان و مفهوم +multiplexing خود را بر روی TCP طراحی کند. -درخواست‌های انجام شده‌ی HTTP بر روی HTTP/3 از یک مجموعه‌ی بخصوص از جریان‌ها استفاده می‌کنند. +درخواست‌های انجام شده‌ی HTTP بر روی HTTP/3 از یک مجموعه‌ی بخصوص +از جریان‌ها استفاده می‌کنند. ## قاب‌های HTTP/3 -پروتکل HTTP/3 به معنای راه اندازی جریان‌های QUIC و ارسال دسته‌ای از قاب‌ها به پایانه‌ی دیگر است. گرچه تعداد ثابت کمی (در واقع ۹ عدد در ۱۸ دسامبر ۲۰۱۸!) از قاب‌های شناخته شده در HTTP/3 وجود دارد. که مهم‌ترین آنها احتمالاً به شرح ذیل‌اند: +پروتکل HTTP/3 به معنای راه اندازی جریان‌های QUIC و ارسال دسته‌ای از +قاب‌ها به پایانه‌ی دیگر است. گرچه تعداد ثابت کمی (در واقع ۹ عدد در ۱۸ +دسامبر ۲۰۱۸!) از قاب‌های شناخته شده در HTTP/3 وجود دارد. که مهم‌ترین +آنها احتمالاً به شرح ذیل‌اند: - قاب HEADERS، که سرایند‌های فشرده‌ی HTTP را ارسال می‌کند - قاب DATA، محتوای داده‌ی دودویی ارسال می‌کند @@ -14,18 +20,27 @@ ## درخواست پروتکل انتقال ابرمتن -کارخواه درخواست HTTP خود را روی یک جریان دوطرفه‌ی QUIC آغاز شده از سمت خود ارسال می‌کند. +کارخواه درخواست HTTP خود را روی یک جریان دوطرفه‌ی QUIC آغاز شده از سمت خود +ارسال می‌کند. -یک درخواست از یک قاب HEADERS تشکیل می‌شود و ممکن است بطور اختیاری با یک یا دو قاب دیگر نیز همراه باشد: یک مجموعه از قاب‌های DATA و احتمالاً یک قاب HEADERS نهایی برای پشت‌بند‌هایش. +یک درخواست از یک قاب HEADERS تشکیل می‌شود و ممکن است بطور اختیاری با یک یا +دو قاب دیگر نیز همراه باشد: یک مجموعه از قاب‌های DATA و احتمالاً یک قاب +HEADERS نهایی برای پشت‌بند‌هایش. کارخواه پس از پس از ارسال یک درخواست، جریان را برای ارسال می‌بندد. ## پاسخ پروتکل انتقال ابرمتن -سرور پاسخ HTTP خود را روی جریان دوطرفه برمی‌گرداند. یک قاب HEADERS، مجموعه‌ای از قاب‌های DATA و احتمالاً پشت‌بندش یک قابِ HEADERS. +سرور پاسخ HTTP خود را روی جریان دوطرفه برمی‌گرداند. یک قاب HEADERS، +مجموعه‌ای از قاب‌های DATA و احتمالاً پشت‌بندش یک قابِ HEADERS. ## سرایندهای QPACK -قاب‌های HEADERS شامل سرایند‌های فشرده شده‌ی HTTP با استفاده از الگوریتم QPACK هستند. پروتکل QPACK در روش شبیه به فشرده‌سازی HPACK ([RFC 7541](https://httpwg.org/specs/rfc7541.html)) در HTTP/2 است، اما اصلاح شده برای کار با جریان‌های دریافت شده‌ی خارج از ترتیب. +قاب‌های HEADERS شامل سرایند‌های فشرده شده‌ی HTTP با استفاده از +الگوریتم QPACK هستند. پروتکل QPACK در روش شبیه به فشرده‌سازی HPACK ([RFC +7541](https://httpwg.org/specs/rfc7541.html)) در HTTP/2 است، اما اصلاح شده برای +کار با جریان‌های دریافت شده‌ی خارج از ترتیب. -لازم به ذکر که QPACK خودش از دو جریان اضافی QUIC یک‌طرفه مابین دو پایانه استفاده می‌کند. آنها، در هر دو جهت، برای حمل کردن اطلاعات جدول پویا استفاده می‌شوند. +لازم به ذکر که QPACK خودش از دو جریان اضافی QUIC یک‌طرفه مابین دو پایانه +استفاده می‌کند. آنها، در هر دو جهت، برای حمل کردن اطلاعات جدول پویا استفاده +می‌شوند. diff --git a/fa/h3.md b/fa/h3.md index 027a392e..984471ed 100644 --- a/fa/h3.md +++ b/fa/h3.md @@ -1,13 +1,26 @@ # پروتکل انتقال ابرمتن نگارش ۳ (HTTP/3) -همانطور که پیش‌تر اشاره شد، HTTP اولین و مهم‌ترین پروتکل برای انتقال بر روی بستر QUIC است. +همانطور که پیش‌تر اشاره شد، HTTP اولین و مهم‌ترین پروتکل برای انتقال +بر روی بستر QUIC است. -بسیار شبیه به هنگامیکه HTTP/2 معرفی شده بود تا HTTP را به شیوه‌ای کاملاً جدید انتقال‌دهی کند، HTTP/3 دارد دوباره راهی جدید را برای ارسال HTTP از طریق شبکه معرفی می‌کند. +بسیار شبیه به هنگامیکه HTTP/2 معرفی شده بود تا HTTP را به شیوه‌ای کاملاً جدید +انتقال‌دهی کند، HTTP/3 دارد دوباره راهی جدید را برای ارسال HTTP از طریق +شبکه معرفی می‌کند. -پروتکل HTTP هنوز هم همچون گذشته دارد همان الگو‌ها و نمونه‌ها را حفظ می‌کند. سرایند‌ها هستند و یک بدنه، یک درخواست هست و یک پاسخ. دستورالعمل‌ها، کوکی‌ها و حافظه نهان وجود دارد. آنچه که اساساً تغییر می‌کند با HTTP/3 این است که چگونه بیت‌ها به آن سوی ارتباط ارسال می‌شوند. +پروتکل HTTP هنوز هم همچون گذشته دارد همان الگو‌ها و نمونه‌ها را حفظ +می‌کند. سرایند‌ها هستند و یک بدنه، یک درخواست هست و یک پاسخ. +دستورالعمل‌ها، کوکی‌ها و حافظه نهان وجود دارد. آنچه که اساساً تغییر +می‌کند با HTTP/3 این است که چگونه بیت‌ها به آن سوی ارتباط ارسال +می‌شوند. -به منظورِ انجامِ HTTP بر روی QUIC، تغییراتی لازم بود و حاصل آن چیزیست که امروزه HTTP/3 می‌نامیم. این تغییرات نیاز بود، بدلیل طبیعت متفاوت QUIC در مقابل TCP. این تغییرات به شرح زیر هستند: +به منظورِ انجامِ HTTP بر روی QUIC، تغییراتی لازم بود و حاصل آن چیزیست که امروزه +HTTP/3 می‌نامیم. این تغییرات نیاز بود، بدلیل طبیعت متفاوت QUIC در مقابل +TCP. این تغییرات به شرح زیر هستند: -- در QUIC جریان‌ها توسط خودِ انتقال فراهم می‌گردند، حال آنکه در HTTP/2 جریان‌ها داخل لایه‌ی HTTP صورت میگرفتند. -- بخاطر آنکه جریان‌ها از یکدیگر مستقل‌اند، پروتکلِ فشرده‌سازیِ سرایندِ استفاده شده برای HTTP/2 نمی‌توانست بدون آنکه موجبِ یک موقعیت مسدود کننده‌ی سر شود استفاده گردد. -- جریان‌های QUIC کمی نسبت به جریان‌های HTTP/2 متفاوت هستند. بخش HTTP/3 تا حدی این جزئیات را پوشش خواهد داد. +- در QUIC جریان‌ها توسط خودِ انتقال فراهم می‌گردند، حال آنکه در HTTP/2 + جریان‌ها داخل لایه‌ی HTTP صورت میگرفتند. +- بخاطر آنکه جریان‌ها از یکدیگر مستقل‌اند، پروتکلِ فشرده‌سازیِ + سرایندِ استفاده شده برای HTTP/2 نمی‌توانست بدون آنکه موجبِ یک موقعیت مسدود + کننده‌ی سر شود استفاده گردد. +- جریان‌های QUIC کمی نسبت به جریان‌های HTTP/2 متفاوت هستند. بخش HTTP/3 + تا حدی این جزئیات را پوشش خواهد داد. diff --git a/fa/proc-h2.md b/fa/proc-h2.md index 142665c1..065bc54f 100644 --- a/fa/proc-h2.md +++ b/fa/proc-h2.md @@ -1,9 +1,15 @@ ## تجربه از HTTP/2 -مشخصات HTTP/2 توسط RFC 7540 در ماه مِه سال ۲۰۱۵، یک ماه قبل از آنکه QUIC برای اولین بار به IETF آورده شود انتشار یافت. +مشخصات HTTP/2 توسط RFC 7540 در ماه مِه سال ۲۰۱۵، یک ماه قبل از آنکه QUIC برای +اولین بار به IETF آورده شود انتشار یافت. -همراه با HTTP/2، مبانی تغییرات HTTP وضع شد و گروهی که HTTP/2 را ساختند این ذهنیت را داشتند که این امر به فرایند نوسازی نسخه‌های جدیدتر HTTP کمک می‌کند تا سریعتر از زمانی باشند که برای رفتن از نسخه ۱ به ۲ به طول انجامید (حدود ۱۶ سال). +همراه با HTTP/2، مبانی تغییرات HTTP وضع شد و گروهی که HTTP/2 را ساختند این ذهنیت +را داشتند که این امر به فرایند نوسازی نسخه‌های جدیدتر HTTP کمک می‌کند +تا سریعتر از زمانی باشند که برای رفتن از نسخه ۱ به ۲ به طول انجامید (حدود ۱۶ +سال). -با استفاده از HTTP / 2، کاربران و بسته‌های نرم افزاری به این ایده رسیدند که دیگر نمی‌توان انتظار داشت که HTTP با پروتکلی مبتنی بر متن به صورت زنجیره‌ای اجرا شود. +با استفاده از HTTP / 2، کاربران و بسته‌های نرم افزاری به این ایده رسیدند که +دیگر نمی‌توان انتظار داشت که HTTP با پروتکلی مبتنی بر متن به صورت +زنجیره‌ای اجرا شود. نام "HTTP بر روی بستر QUIC" در نوامبر ۲۰۱۸ به HTTP/3 تغییر یافت. diff --git a/fa/proc-ietf.md b/fa/proc-ietf.md index 2f247e7c..c6dcbb08 100644 --- a/fa/proc-ietf.md +++ b/fa/proc-ietf.md @@ -1,17 +1,35 @@ ## کارگروه مهندسی اینترنت (IETF) -کارگروه QUIC که برای استاندارسازی پروتکل در IETF پایه گذاری شد سریعاً تصمیم گرفت که پروتکل QUIC باید قادر باشد تا پروتکل‌هایی به غیر از "فقط" HTTP را هم انتقال دهد. پروتکل Google-QUIC تنها HTTP را انتقال داده است - در عمل آنچه را که بطور موثر قاب‌های HTTP/2 بوده است انتقال داده است، با استفاده از دستور و قواعد قاب HTTP/2. - -همچنین اعلام شد که IETF-QUIC باید رمزگذاری و امنیت خود را به جای نگرش "دستی-سفارشی" بکار گرفته شده توسط Google-QUIC روی TLS 1.3 بنا کند. - -به منظور برآوردن تقاضای بیش-از-HTTP-بفرست، معماری پروتکلِ QUIC کارگروه مهندسی اینترنت در دو لایه‌ی جدا تقسیم شد: انتقال QUIC و لایه‌ی "HTTP روی QUIC" (که دومی گاهی با عنوان "hq" یاد می‌شود). - -این جدایی لایه‌ها، در حالی ‌که ممکن است بی‌ضرر به نظر رسد، باعث شده است که IETF-QUIC تفاوت بسیاری نسبت به Google-QUIC اصلی پیدا کند. - -با این حال طولی نکشید که کارگروه تصمیم گرفت تا به منظور پیدا کردن تمرکز و توان مناسب برای تحویل به موقع QUIC نسخه ۱، تمرکزش را بر روی تحویل HTTP قرار ‌دهد و انتقال‌های غیر HTTP را برای بعد بگذارد. - -در مارس ۲۰۱۸، هنگامی ‌که ما کار بر روی این کتاب را شروع کردیم، برنامه آن بود که جزئیات نهایی برای QUIC نسخه ۱ را در نوامبر ۲۰۱۸ تحویل دهیم؛ بعدتر به تاریخ جولای ۲۰۱۹ موکول شد. - -در حالیکه کار بر روی IETF-QUIC پیش می‌رفت، تیم گوگل جزئیاتی از نسخه‌ی IETF را استفاده کرده و به آرامی در جهت آنچه نسخه‌ی IETF ممکن است تبدیل شود شروع به توسعه دادن نسخه پروتکل خود کرد. گوگل به استفاده از نسخه‌ی QUIC خود در مرورگر و سرویس‌های خود ادامه داده است. - -[اکثر پیاده‌سازی‌های تحت توسعه](https://github.com/quicwg/base-drafts/wiki/Implementations) تصمیم گرفته‌اند تا تمرکزشان را روی نسخه‌ی IETF قرار دهند و با نسخه‌ گوگل سازگار نیستند. +کارگروه QUIC که برای استاندارسازی پروتکل در IETF پایه گذاری شد سریعاً تصمیم گرفت +که پروتکل QUIC باید قادر باشد تا پروتکل‌هایی به غیر از "فقط" HTTP را هم +انتقال دهد. پروتکل Google-QUIC تنها HTTP را انتقال داده است - در عمل آنچه را که +بطور موثر قاب‌های HTTP/2 بوده است انتقال داده است، با استفاده از دستور و +قواعد قاب HTTP/2. + +همچنین اعلام شد که IETF-QUIC باید رمزگذاری و امنیت خود را به جای نگرش +"دستی-سفارشی" بکار گرفته شده توسط Google-QUIC روی TLS 1.3 بنا کند. + +به منظور برآوردن تقاضای بیش-از-HTTP-بفرست، معماری پروتکلِ QUIC کارگروه مهندسی +اینترنت در دو لایه‌ی جدا تقسیم شد: انتقال QUIC و لایه‌ی "HTTP روی QUIC" +(که دومی گاهی با عنوان "hq" یاد می‌شود). + +این جدایی لایه‌ها، در حالی ‌که ممکن است بی‌ضرر به نظر رسد، باعث +شده است که IETF-QUIC تفاوت بسیاری نسبت به Google-QUIC اصلی پیدا کند. + +با این حال طولی نکشید که کارگروه تصمیم گرفت تا به منظور پیدا کردن تمرکز و توان +مناسب برای تحویل به موقع QUIC نسخه ۱، تمرکزش را بر روی تحویل HTTP قرار +‌دهد و انتقال‌های غیر HTTP را برای بعد بگذارد. + +در مارس ۲۰۱۸، هنگامی ‌که ما کار بر روی این کتاب را شروع کردیم، برنامه آن +بود که جزئیات نهایی برای QUIC نسخه ۱ را در نوامبر ۲۰۱۸ تحویل دهیم؛ بعدتر به +تاریخ جولای ۲۰۱۹ موکول شد. + +در حالیکه کار بر روی IETF-QUIC پیش می‌رفت، تیم گوگل جزئیاتی از نسخه‌ی +IETF را استفاده کرده و به آرامی در جهت آنچه نسخه‌ی IETF ممکن است تبدیل شود +شروع به توسعه دادن نسخه پروتکل خود کرد. گوگل به استفاده از نسخه‌ی QUIC خود +در مرورگر و سرویس‌های خود ادامه داده است. + +[اکثر پیاده‌سازی‌های تحت +توسعه](https://github.com/quicwg/base-drafts/wiki/Implementations) تصمیم +گرفته‌اند تا تمرکزشان را روی نسخه‌ی IETF قرار دهند و با نسخه‌ +گوگل سازگار نیستند. diff --git a/fa/proc-status.md b/fa/proc-status.md index 7f120e8c..97c903eb 100644 --- a/fa/proc-status.md +++ b/fa/proc-status.md @@ -1,48 +1,92 @@ # وضعیت -کارگروه QUIC از اواخر ۲۰۱۶ سخت مشغول تبیین و به کارگیری پروتکل‌ها بوده‌اند و اکنون قرار بر این است که این امر تا تاریخ جولای ۲۰۱۹ به پایان رسیده باشد. +کارگروه QUIC از اواخر ۲۰۱۶ سخت مشغول تبیین و به کارگیری پروتکل‌ها +بوده‌اند و اکنون قرار بر این است که این امر تا تاریخ جولای ۲۰۱۹ به پایان +رسیده باشد. -از نوامبر ۲۰۱۸، هنوز آزمایش هم‌کنش‌پذیری بزرگتری در خصوص HTTP/3 انجام نگرفته است - تنها با دو پیاده سازی موجود که هیچ کدام توسط یک مرورگر یا یک نرم افزارِ باز سمتِ کارساز صورت نگرفته اند. +از نوامبر ۲۰۱۸، هنوز آزمایش هم‌کنش‌پذیری بزرگتری در خصوص HTTP/3 انجام +نگرفته است - تنها با دو پیاده سازی موجود که هیچ کدام توسط یک مرورگر یا یک نرم +افزارِ باز سمتِ کارساز صورت نگرفته اند. -در حال حاضر حدود ۱۵ [پیاده سازی QUIC](https://github.com/curl/curl/wiki/QUIC-implementation) در صفحات ویکی کارگروه QUIC فهرست شده است، اما توانایی هم‌کنش‌پذیری با آخرین نسخه‌ی پیش‌نویسِ تجدید شده راه طولانی‌ای پیش‌رو دارد. +در حال حاضر حدود ۱۵ [پیاده سازی +QUIC](https://github.com/curl/curl/wiki/QUIC-implementation) در صفحات ویکی +کارگروه QUIC فهرست شده است، اما توانایی هم‌کنش‌پذیری با آخرین +نسخه‌ی پیش‌نویسِ تجدید شده راه طولانی‌ای پیش‌رو دارد. پیاده سازی QUIC به این سادگی نیست و خود پروتکل دائم تغییر کرده است. ## کارگزار‌ها -پشتیبانی NGINX از QUIC و HTTP/3 در دست توسعه است و بنا است که در حین [چرخه‌ی توسعه NGINX 1.17](https://trac.nginx.org/nginx/milestone/nginx-1.17) توزیع گردد. +پشتیبانی NGINX از QUIC و HTTP/3 در دست توسعه است و بنا است که در حین +[چرخه‌ی توسعه NGINX +1.17](https://trac.nginx.org/nginx/milestone/nginx-1.17) توزیع گردد. هیچ اعلامیه رسمی از طرف Apache در ارتباط با پشتیبانی از QUIC وجود ندارد. ## کارخواه‌ها -هیچ یک از عرضه کنندگانِ مرورگرهای بزرگ نسخه‌ای که بتواند از نسخه‌ی QUIC کارگروه مهندسی اینترنت پشتیبانی کند را ارائه نکرده‌اند. +هیچ یک از عرضه کنندگانِ مرورگرهای بزرگ نسخه‌ای که بتواند از نسخه‌ی QUIC +کارگروه مهندسی اینترنت پشتیبانی کند را ارائه نکرده‌اند. -گوگل کروم سال‌هاست که همراه با نسخه‌ی توسعه داده شده‌ی خودش از QUIC عرضه شده است، اما در تعامل با نسخه‌ی کارگروه مهندسی اینترنت مشکل دار و پیاده سازیِ HTTP متفاوتی هم نسبت به HTTP/3 دارد. +گوگل کروم سال‌هاست که همراه با نسخه‌ی توسعه داده شده‌ی خودش از +QUIC عرضه شده است، اما در تعامل با نسخه‌ی کارگروه مهندسی اینترنت مشکل دار و +پیاده سازیِ HTTP متفاوتی هم نسبت به HTTP/3 دارد. -شرکت Mozilla در حال توسعه‌ی [Neqo](https://github.com/mozilla/neqo/) است - یک پیاده سازیِ QUIC و HTTP/3 نوشته شده با زبانِ [Rust](https://www.rust-lang.org/). [بناست که](https://github.com/mozilla/neqo/issues/10) Neqo داخل [Necko](https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Necko) (که یک کتابخانه‌ی شبکه‌ی مورد استفاده در بسیاری از برنامه‌های سمت کارخواهِ مبتنی بر Mozilla است - از جمله Firefox) کار گذاشته شود. +شرکت Mozilla در حال توسعه‌ی [Neqo](https://github.com/mozilla/neqo/) است - +یک پیاده سازیِ QUIC و HTTP/3 نوشته شده با زبانِ +[Rust](https://www.rust-lang.org/). [بناست +که](https://github.com/mozilla/neqo/issues/10) Neqo داخل +[Necko](https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Necko) (که یک +کتابخانه‌ی شبکه‌ی مورد استفاده در بسیاری از برنامه‌های سمت +کارخواهِ مبتنی بر Mozilla است - از جمله Firefox) کار گذاشته شود. -نرم‌افزار curl اولین پشتیبانی از نسخه‌ی آزمایشی HTTP/3 (پیش‌نویسِ ۲۲) را در نشرِ 7.66.0 در تاریخ ۱۱ سپتامبرِ سال ۲۰۱۹ عرضه کرد. برای انجام کار، curl یا از کتابخانه‌ی Quiche توسط Cloudflare یا خانواده‌ی کتابخانه‌های ngtcp2 استفاده می‌کند. +نرم‌افزار curl اولین پشتیبانی از نسخه‌ی آزمایشی HTTP/3 (پیش‌نویسِ +۲۲) را در نشرِ 7.66.0 در تاریخ ۱۱ سپتامبرِ سال ۲۰۱۹ عرضه کرد. برای انجام کار، curl +یا از کتابخانه‌ی Quiche توسط Cloudflare یا خانواده‌ی کتابخانه‌های +ngtcp2 استفاده می‌کند. ## موانع پیاده‌سازی -برای پروتکل QUIC تصمیم گرفته شده تا از TLS 1.3 به عنوان زیربنای رمزگذاری و لایه‌ی امنیت استفاده شود تا از ساخت و تولید یک چیز جدید اجتناب شود و در عوض بر روی یک پروتکل موجود و قابل اعتماد تأکید شود. گرچه، در همین هنگام، کارگروه تصمیم گرفت تا کاربرد TLS (پروتکل امنیتی لایه‌ی انتقال) در QUIC را بهینه سازد، بدین شکل که فقط باید از "پیغام‌های TLS" و نه "رکورد‌های TLS" برای پروتکل استفاده شود. - -این تغییر شاید به ظاهر بی‌ضرر باشد، اما در واقع یک مانع قابل توجهی برای بسیاری از پیاده‌سازانِ پشته‌ی QUIC ایجاد کرده است. کتابخانه‌های TLS موجود که از TLS 1.3 پشتیبانی می‌کنند از رابط برنامه‌نویسی کاربردیِ کافی برای دسترسی به این کارکرد و همچنین ایجاد امکان دسترسی به آن برای QUIC برخوردار نیستند. تعدادی از پیاده‌سازانِ QUIC از سازمان‌های بزرگتری می‌آیند که به موازات در حال کار بر روی پشته‌ی امنیت لایه‌ی انتقالِ (TLS) خود هستند، اما به هر حال این برای همه صادق نیست. - -بطور مثال OpenSSL متن‌باز بزرگ، هیچ API (رابط برنامه‌نویسی کاربردی) برای این منظور ندارد. به نظر می‌رسد که رسیدگی به این موضوع در درخواستِ انجامِ [PR -8797](https://github.com/openssl/openssl/pull/8797) اتفاق می‌افتد که مقصود معرفی یک رابط برنامه‌نویسی کاربردی بسیار شبیه به برای BoringSSL است. - -این موضوع در نهایت موجب موانعِ راه‌ اندازی می‌شود زیرا که پشته‌های QUIC نیاز خواهند داشت که یا خود را بر روی کتابخانه‌های امنیت لایه‌ی انتقالِ دیگر بنا کنند، یا از یک نسخه‌ی جدا و تصحیح شده‌ی OpenSSL استفاده کنند و یا نیازمند بروزرسانی‌ای در نسخه‌ای از OpenSSL درآینده باشند. +برای پروتکل QUIC تصمیم گرفته شده تا از TLS 1.3 به عنوان زیربنای رمزگذاری و +لایه‌ی امنیت استفاده شود تا از ساخت و تولید یک چیز جدید اجتناب شود و در عوض +بر روی یک پروتکل موجود و قابل اعتماد تأکید شود. گرچه، در همین هنگام، کارگروه +تصمیم گرفت تا کاربرد TLS (پروتکل امنیتی لایه‌ی انتقال) در QUIC را بهینه +سازد، بدین شکل که فقط باید از "پیغام‌های TLS" و نه "رکورد‌های TLS" +برای پروتکل استفاده شود. + +این تغییر شاید به ظاهر بی‌ضرر باشد، اما در واقع یک مانع قابل توجهی برای +بسیاری از پیاده‌سازانِ پشته‌ی QUIC ایجاد کرده است. کتابخانه‌های +TLS موجود که از TLS 1.3 پشتیبانی می‌کنند از رابط برنامه‌نویسی کاربردیِ +کافی برای دسترسی به این کارکرد و همچنین ایجاد امکان دسترسی به آن برای QUIC +برخوردار نیستند. تعدادی از پیاده‌سازانِ QUIC از سازمان‌های بزرگتری +می‌آیند که به موازات در حال کار بر روی پشته‌ی امنیت لایه‌ی انتقالِ +(TLS) خود هستند، اما به هر حال این برای همه صادق نیست. + +بطور مثال OpenSSL متن‌باز بزرگ، هیچ API (رابط برنامه‌نویسی کاربردی) +برای این منظور ندارد. به نظر می‌رسد که رسیدگی به این موضوع در درخواستِ انجامِ +[PR 8797](https://github.com/openssl/openssl/pull/8797) اتفاق می‌افتد که +مقصود معرفی یک رابط برنامه‌نویسی کاربردی بسیار شبیه به برای BoringSSL است. + +این موضوع در نهایت موجب موانعِ راه‌ اندازی می‌شود زیرا که پشته‌های +QUIC نیاز خواهند داشت که یا خود را بر روی کتابخانه‌های امنیت لایه‌ی +انتقالِ دیگر بنا کنند، یا از یک نسخه‌ی جدا و تصحیح شده‌ی OpenSSL +استفاده کنند و یا نیازمند بروزرسانی‌ای در نسخه‌ای از OpenSSL درآینده +باشند. ## بارِ هسته و پردازنده‌ی مرکزی -شرکت‌های Google و Facebook گفته‌‌اند که آنها برای راه اندازی QUIC در مقیاس گسترده تقریباً به دوبرابر میزان CPU ای که برای همان‌مقدار ترافیک به هنگام ارائه‌ی HTTP/2 بر روی TLS استفاده می‌شود نیاز دارند. +شرکت‌های Google و Facebook گفته‌‌اند که آنها برای راه اندازی QUIC +در مقیاس گسترده تقریباً به دوبرابر میزان CPU ای که برای همان‌مقدار ترافیک به +هنگام ارائه‌ی HTTP/2 بر روی TLS استفاده می‌شود نیاز دارند. برخی توضیحات در این مورد شامل موادر ذیل می‌شود: -- بخش‌های UDP در لینوکس از آنجا که بطور معمول برای انتقال‌های اینچنین پر‌سرعت استفاده نشده‌ است اساساً به هیچ وجه به اندازه‌ی پشته‌ی TCP بهینه نشده است. +- بخش‌های UDP در لینوکس از آنجا که بطور معمول برای انتقال‌های اینچنین + پر‌سرعت استفاده نشده‌ است اساساً به هیچ وجه به اندازه‌ی + پشته‌ی TCP بهینه نشده است. -- تخلیه‌ی بارِ TCP و TLS به سخت افزار موجود است، اما برای UDP بسیار نادرتر و برای QUIC اساساً ناموجود است. +- تخلیه‌ی بارِ TCP و TLS به سخت افزار موجود است، اما برای UDP بسیار نادرتر و + برای QUIC اساساً ناموجود است. -باور بر این است که کارایی و نیازمندی‌های CPU به مرور زمان بهبود خواهند یافت. +باور بر این است که کارایی و نیازمندی‌های CPU به مرور زمان بهبود خواهند +یافت. diff --git a/fa/proc.md b/fa/proc.md index 42a4bce1..b86763f5 100644 --- a/fa/proc.md +++ b/fa/proc.md @@ -1,11 +1,23 @@ # پردازش -پروتکل QUIC نخست توسط Jim Roskind در Google طراحی شد و ابتدا در سال ۲۰۱۲ پیاده سازی شد، و در سال ۲۰۱۳ به طور عمومی انتشار یافت هنگامیکه آزمایشات Google گسترش یافت. +پروتکل QUIC نخست توسط Jim Roskind در Google طراحی شد و ابتدا در سال ۲۰۱۲ پیاده +سازی شد، و در سال ۲۰۱۳ به طور عمومی انتشار یافت هنگامیکه آزمایشات Google گسترش +یافت. -در آن زمان، کماکان مدعی بودند که QUIC مخففی برای "Quick UDP Internet Connections" است، گرچه امروزه دیگر اینطور نیست و از همان زمان رد شد. +در آن زمان، کماکان مدعی بودند که QUIC مخففی برای "Quick UDP Internet +Connections" است، گرچه امروزه دیگر اینطور نیست و از همان زمان رد شد. -شرکت Google این پروتکل را پیاده‌سازی کرد و سپس آنرا در مرورگر متداول خود (Chrome) و همچنین سرویس‌های مرسوم و پُرکاربَرِ خود (همچو YouTube، Gmail، Google Search و غیره) گسترش داد. آنها نسخه‌های پروتکل را به طور مداوم تکرار کردند و با گذر زمان ثابت کردند که این پروتکل برای تعداد زیادی از کاربران به طرزی قابل اعتماد مناسب بوده و درست کار می‌کند. +شرکت Google این پروتکل را پیاده‌سازی کرد و سپس آنرا در مرورگر متداول خود +(Chrome) و همچنین سرویس‌های مرسوم و پُرکاربَرِ خود (همچو YouTube، Gmail، +Google Search و غیره) گسترش داد. آنها نسخه‌های پروتکل را به طور مداوم تکرار +کردند و با گذر زمان ثابت کردند که این پروتکل برای تعداد زیادی از کاربران به طرزی +قابل اعتماد مناسب بوده و درست کار می‌کند. -در ژوئن ۲۰۱۵، اولین پیش نویس اینترنتی QUIC برای استاندارد سازی به IETF فرستاده شد، اما تا اواخر سال ۲۰۱۶ به طول انجامید تا گروهی از متخصصانِ QUIC مور تأیید قرار گیرد و آغاز به کار کند. اما بعد از آن سریعاً رشد کرد و مورد توجه تعداد زیادی از گروه‌ها قرار گرفت. +در ژوئن ۲۰۱۵، اولین پیش نویس اینترنتی QUIC برای استاندارد سازی به IETF فرستاده +شد، اما تا اواخر سال ۲۰۱۶ به طول انجامید تا گروهی از متخصصانِ QUIC مور تأیید قرار +گیرد و آغاز به کار کند. اما بعد از آن سریعاً رشد کرد و مورد توجه تعداد زیادی از +گروه‌ها قرار گرفت. -در سال ۲۰۱۷، به نقل از مهندسین QUIC در Google تقریباً حدود ۷٪ از کل ترافیک اینترنت از این پروتکل استفاده می‌کرده‌اند. نسخه‌ی Google این پروتکل. +در سال ۲۰۱۷، به نقل از مهندسین QUIC در Google تقریباً حدود ۷٪ از کل ترافیک +اینترنت از این پروتکل استفاده می‌کرده‌اند. نسخه‌ی Google این +پروتکل. diff --git a/fa/quic-0rtt.md b/fa/quic-0rtt.md index f3405d97..a4b39476 100644 --- a/fa/quic-0rtt.md +++ b/fa/quic-0rtt.md @@ -1,3 +1,9 @@ # زمان تأخیر چرخشی صفر (0-RTT) -برای کاهش زمان مورد نیاز جهت برقراری یک اتصال جدید، کارخواهی که قبل‌تر به یک کارگزار متصل شده است ممکن است برخی پارامتر‌ها را از آن اتصال ذخیره کند و سپس یک اتصال برای کاهش زمان مورد نیاز جهت برقراری یک اتصال جدید، کارخواهی که قبل‌تر به یک کارگزار متصل شده است ممکن است برخی پارامتر‌ها را از آن اتصال ذخیره کند و سپس یک اتصال **0-RTT** با کارگزار برقرار کند. این به کارخواه اجازه می‌دهد تا داده را بدون آنکه برای تکمیل یک دست‌دهی منتظر بماند بلافاصله ارسال کند. +برای کاهش زمان مورد نیاز جهت برقراری یک اتصال جدید، کارخواهی که قبل‌تر به +یک کارگزار متصل شده است ممکن است برخی پارامتر‌ها را از آن اتصال ذخیره کند و +سپس یک اتصال برای کاهش زمان مورد نیاز جهت برقراری یک اتصال جدید، کارخواهی که +قبل‌تر به یک کارگزار متصل شده است ممکن است برخی پارامتر‌ها را از آن +اتصال ذخیره کند و سپس یک اتصال **0-RTT** با کارگزار برقرار کند. این به کارخواه +اجازه می‌دهد تا داده را بدون آنکه برای تکمیل یک دست‌دهی منتظر بماند +بلافاصله ارسال کند. diff --git a/fa/quic-api.md b/fa/quic-api.md index f3307587..d97257a0 100644 --- a/fa/quic-api.md +++ b/fa/quic-api.md @@ -1,9 +1,21 @@ # رابط برنامه‌نویسی کاربردی (API) -یکی از شاخص‌های موفقیت برای TCP و برنامه‌هایی که از آن استفاده می‌کنند، کانالِ رابط برنامه‌نویسی استاندارد شده‌ است. کانال رابط برنامه‌نویسی از قابلیت خوبی برخوردار است و با استفاده از این رابط برنامه‌نویسی می‌توانید برنامه‌ها را بین سیستم عامل‌های مختلف جا‌به‌جا کنید همانگونه که TCP کار می‌کند. +یکی از شاخص‌های موفقیت برای TCP و برنامه‌هایی که از آن استفاده +می‌کنند، کانالِ رابط برنامه‌نویسی استاندارد شده‌ است. کانال رابط +برنامه‌نویسی از قابلیت خوبی برخوردار است و با استفاده از این رابط +برنامه‌نویسی می‌توانید برنامه‌ها را بین سیستم عامل‌های مختلف +جا‌به‌جا کنید همانگونه که TCP کار می‌کند. -پروتکل QUIC به آنجا نرسیده است. هیچ رابط برنامه‌نویسی استانداردی برای QUIC وجود ندارد. +پروتکل QUIC به آنجا نرسیده است. هیچ رابط برنامه‌نویسی استانداردی برای QUIC +وجود ندارد. -با QUIC، شما لازم است یکی از کتابخانه‌های پیاده‌سازی شده‌ی موجود را انتخاب کنید و با رابط برنامه‌نویسی آن بمانید. این باعث می‌شود نرم‌افزار‌ها تا حدی بر روی یک کتابخانه "قفل" شوند. تغییر کتابخانه‌ به معنای تغییر رابط برنامه‌نویسی خواهد بود و بنا بر این می‌تواند مستلزم زحمت‌های فراوان باشد. +با QUIC، شما لازم است یکی از کتابخانه‌های پیاده‌سازی شده‌ی موجود +را انتخاب کنید و با رابط برنامه‌نویسی آن بمانید. این باعث می‌شود +نرم‌افزار‌ها تا حدی بر روی یک کتابخانه "قفل" شوند. تغییر +کتابخانه‌ به معنای تغییر رابط برنامه‌نویسی خواهد بود و بنا بر این +می‌تواند مستلزم زحمت‌های فراوان باشد. -همچنین، از آنجا که QUIC بطور معمول در فضای کاربر پیاده سازی شده است، نمی‌تواند به همین سادگی کانال رابط برنامه‌نویسی را بسط دهد یا مانند عملکرد TCP و UDP موجود ظاهر شود. استفاده از QUIC به معنای استفاده از رابط برنامه‌نویسی دیگری است تا کانال رابط برنامه‌نویسی. +همچنین، از آنجا که QUIC بطور معمول در فضای کاربر پیاده سازی شده است، +نمی‌تواند به همین سادگی کانال رابط برنامه‌نویسی را بسط دهد یا مانند +عملکرد TCP و UDP موجود ظاهر شود. استفاده از QUIC به معنای استفاده از رابط +برنامه‌نویسی دیگری است تا کانال رابط برنامه‌نویسی. diff --git a/fa/quic-connections.md b/fa/quic-connections.md index e1b954a9..edf79f27 100644 --- a/fa/quic-connections.md +++ b/fa/quic-connections.md @@ -1,21 +1,39 @@ # اتصالات -یک اتصال QUIC یک مکالمه واحد بین دو پایانه‌ی QUIC است. برقراری ارتباطِ QUIC، در جهت کاهش تأخیر در برقراری ارتباط، مذاکره‌ی نسخه را با رمزنگاری و دست‌دهی‌های انتقال ترکیب می‌کند. +یک اتصال QUIC یک مکالمه واحد بین دو پایانه‌ی QUIC است. برقراری ارتباطِ QUIC، +در جهت کاهش تأخیر در برقراری ارتباط، مذاکره‌ی نسخه را با رمزنگاری و +دست‌دهی‌های انتقال ترکیب می‌کند. -در واقع برای آنکه بتوان داده را از طریق چنین اتصالی ارسال کرد، یک یا تعداد بیشتری جریان باید ساخته و در نتیجه استفاده شود. +در واقع برای آنکه بتوان داده را از طریق چنین اتصالی ارسال کرد، یک یا تعداد +بیشتری جریان باید ساخته و در نتیجه استفاده شود. ## شناسه اتصال -هر اتصال یک مجموع از شناسه‌های اتصال را در اختیار می‌گیرد که هر کدام می‌تواند برای شناسایی اتصال استفاده شود. شناسه‌های اتصال بطور مستقل توسط پایانه‌ها انتخاب می‌شوند؛ هر پایانه شناسه اتصالی را که همتایش استفاده می‌کند انتخاب می‌کند. +هر اتصال یک مجموع از شناسه‌های اتصال را در اختیار می‌گیرد که هر کدام +می‌تواند برای شناسایی اتصال استفاده شود. شناسه‌های اتصال بطور مستقل +توسط پایانه‌ها انتخاب می‌شوند؛ هر پایانه شناسه اتصالی را که همتایش +استفاده می‌کند انتخاب می‌کند. -کارکرد اصلی این شناسه اتصال‌ها برای اطمینان حاصل کردن از آن است که تغییرهای اعمال شده در آدرس‌دهی در لایه‌های پروتکلِ پایین‌تر (UDP، IP، و پایین‌) باعث دریافت شدنِ بسته‌های اتصالِ QUIC به پایانه‌ اشتباه نشوند. +کارکرد اصلی این شناسه اتصال‌ها برای اطمینان حاصل کردن از آن است که تغییرهای +اعمال شده در آدرس‌دهی در لایه‌های پروتکلِ پایین‌تر (UDP، IP، و +پایین‌) باعث دریافت شدنِ بسته‌های اتصالِ QUIC به پایانه‌ اشتباه +نشوند. -از این قرار با بهره بردن از شناسه اتصال‌، اتصال‌ها می‌توانند بین آدرس IP ها و رابط‌های شبکه به طرقی که TCP هرگز نمی‌توانست حرکت کنند. بطور مثال، این جابه‌جایی اجازه می‌دهد تا یک بارگیری در حال انجام از یک اتصال تلفنی به یک اتصال سریع‌تر وای-فای انتقال پیدا کند - به هنگامی که کاربر دستگاهش را به مکانی ببرد که وای‌-فای داشته. به همین نحو، بارگیری می‌تواند از طریق اتصال تلفن همراه ادامه پیدا کند اگر وای-فای از دسترس خارج شود. +از این قرار با بهره بردن از شناسه اتصال‌، اتصال‌ها می‌توانند بین +آدرس IP ها و رابط‌های شبکه به طرقی که TCP هرگز نمی‌توانست حرکت کنند. +بطور مثال، این جابه‌جایی اجازه می‌دهد تا یک بارگیری در حال انجام از یک +اتصال تلفنی به یک اتصال سریع‌تر وای-فای انتقال پیدا کند - به هنگامی که +کاربر دستگاهش را به مکانی ببرد که وای‌-فای داشته. به همین نحو، بارگیری +می‌تواند از طریق اتصال تلفن همراه ادامه پیدا کند اگر وای-فای از دسترس خارج +شود. ## شماره درگاه -QUIC در بالای UDP ساخته شده است، پس یک جایگاه شماره درگاه ۱۶ بیتی برای تمیز دادن اتصال‌های دریافتی استفاده می‌شود. +QUIC در بالای UDP ساخته شده است، پس یک جایگاه شماره درگاه ۱۶ بیتی برای تمیز دادن +اتصال‌های دریافتی استفاده می‌شود. ## مذاکره‌ی نسخه -یک درخواستِ اتصال QUIC آغاز شده از سمت یک کارخواه به کارساز می‌گوید که با کدام نسخه‌ی پروتکل QUIC می‌خواهد صحبت کند، و کارساز با فهرستی از نسخه‌های پشتیبانی شده پاسخ می‌دهد تا کارخواه از روی آن انتخاب کند. +یک درخواستِ اتصال QUIC آغاز شده از سمت یک کارخواه به کارساز می‌گوید که با +کدام نسخه‌ی پروتکل QUIC می‌خواهد صحبت کند، و کارساز با فهرستی از +نسخه‌های پشتیبانی شده پاسخ می‌دهد تا کارخواه از روی آن انتخاب کند. diff --git a/fa/quic-spinbit.md b/fa/quic-spinbit.md index e6cb6b73..152973e9 100644 --- a/fa/quic-spinbit.md +++ b/fa/quic-spinbit.md @@ -1,15 +1,24 @@ # بیتِ چرخش (Spin Bit) -احتمالاً یکی از طولانی‌ترین بحث‌های طراحی در بین کارگروه QUIC که موضوع چند صد پیغام و ساعت‌ها مناظره بوده است مربوط به تنها یک بیت است: بیتِ چرخش (spin bit). +احتمالاً یکی از طولانی‌ترین بحث‌های طراحی در بین کارگروه QUIC که موضوع +چند صد پیغام و ساعت‌ها مناظره بوده است مربوط به تنها یک بیت است: بیتِ چرخش +(spin bit). -حامیان این بیت به نیازِ وجود امکان اندازه‌گیری تأخیر برای اپراتورها و مردمی که در مسیرِ میان دو پایانه‌ی QUIC هستند پافشاری می‌کنند. +حامیان این بیت به نیازِ وجود امکان اندازه‌گیری تأخیر برای اپراتورها و مردمی +که در مسیرِ میان دو پایانه‌ی QUIC هستند پافشاری می‌کنند. مخالفان این ویژگی علاقه‌ای به فاش شدن احتمالی اطلاعات ندارند. ## چرخاندن یک بیت -هر دو پایانه‌ها، کارخواه و کارگزار، برای هر اتصالِ QUIC یک مقدار چرخش (spin) را حفظ می‌کنند، ۰ یا ۱، و آن بیت چرخش را روی بسته‌هایی که برای آن اتصال ارسال می‌کنند به مقدار مناسب معین می‌کنند. +هر دو پایانه‌ها، کارخواه و کارگزار، برای هر اتصالِ QUIC یک مقدار چرخش (spin) +را حفظ می‌کنند، ۰ یا ۱، و آن بیت چرخش را روی بسته‌هایی که برای آن +اتصال ارسال می‌کنند به مقدار مناسب معین می‌کنند. -سپس هردو طرف بسته‌ها را با آن بیت چرخش در طرل یک round trip با مقداری یکسان ارسال می‌کنند و پس از آن، مقدار را تغییر می‌دهند. سپس نتیجه ضربانی از صفر و یک‌ها در آن بخش بیت است که ناظران می‌توانند مشاهده کنند. +سپس هردو طرف بسته‌ها را با آن بیت چرخش در طرل یک round trip با مقداری یکسان +ارسال می‌کنند و پس از آن، مقدار را تغییر می‌دهند. سپس نتیجه ضربانی از +صفر و یک‌ها در آن بخش بیت است که ناظران می‌توانند مشاهده کنند. -این اندازه‌گیری تنها هنگامی کار می‌کند که ارسال‌کننده محدود به نرم‌فزار یا کنترل جریان نباشد و همچنین سازمان‌دهی مجدد بسته‌ها برروی شبکه می‌تواند داده را اغوا کند. +این اندازه‌گیری تنها هنگامی کار می‌کند که ارسال‌کننده محدود به +نرم‌فزار یا کنترل جریان نباشد و همچنین سازمان‌دهی مجدد بسته‌ها +برروی شبکه می‌تواند داده را اغوا کند. diff --git a/fa/quic-streams.md b/fa/quic-streams.md index 63a684e2..a6bf8bd1 100644 --- a/fa/quic-streams.md +++ b/fa/quic-streams.md @@ -4,40 +4,70 @@ دو نوع ساده از جریان‌ها در QUIC وجود دارند: -- جریان‌های یک طرفه که داده‌ها را در یک جهت حمل می‌کنند: از آغازکننده جریان به سمت همتای خود. +- جریان‌های یک طرفه که داده‌ها را در یک جهت حمل می‌کنند: از + آغازکننده جریان به سمت همتای خود. -- جریان‌های دو طرفه که به داده‌ها اجازه می‌دهند تا در هر دو جهت ارسال شوند. +- جریان‌های دو طرفه که به داده‌ها اجازه می‌دهند تا در هر دو جهت + ارسال شوند. -هر دو نوع جریان‌ها می‌توانند توسط هرکدام از پایانه‌ها ساخته شوند، می‌توانند همزمان داده‌ها را متناوب با جریان‌های دیگر ارسال نماید، و همچنین می‌توانند لغو شوند. +هر دو نوع جریان‌ها می‌توانند توسط هرکدام از پایانه‌ها ساخته شوند، +می‌توانند همزمان داده‌ها را متناوب با جریان‌های دیگر ارسال نماید، +و همچنین می‌توانند لغو شوند. -برای ارسال داده‌ها بر روی یک اتصال QUIC، یک یا تعداد بیشتری جریان استفاده می‌شود. +برای ارسال داده‌ها بر روی یک اتصال QUIC، یک یا تعداد بیشتری جریان استفاده +می‌شود. ## نظارت جریان -جریان‌ها بطور انفرادی نظارت می‌شوند، بدین شکل که به یک پایانه اجازه‌ی محدود کردن و مدیریت تخصیص حافظه و اعمال دوباره‌ی فشار داده می‌شود. ساخت جریان‌ها نیز با اعلام حداکثر شناسه جریانِ مورد نظر برای پذیرش در یک زمان معین توسط هر همتا‌ نیز نظارت شده است. +جریان‌ها بطور انفرادی نظارت می‌شوند، بدین شکل که به یک پایانه +اجازه‌ی محدود کردن و مدیریت تخصیص حافظه و اعمال دوباره‌ی فشار داده +می‌شود. ساخت جریان‌ها نیز با اعلام حداکثر شناسه جریانِ مورد نظر برای +پذیرش در یک زمان معین توسط هر همتا‌ نیز نظارت شده است. ## معرف‌های جریان -جریان‌ها توسط یک عدد صحیح بدون علامت ۶۴ بیتی، به عنوان شناسه جریان، شناسایی می‌شوند. آخرین دو بیتِ شناسه جریان برای شناسایی نوع جریان (یک طرفه یا دو طرفه) و آغازکننده‌ی جریان استفاده می‌شوند. +جریان‌ها توسط یک عدد صحیح بدون علامت ۶۴ بیتی، به عنوان شناسه جریان، شناسایی +می‌شوند. آخرین دو بیتِ شناسه جریان برای شناسایی نوع جریان (یک طرفه یا دو +طرفه) و آغازکننده‌ی جریان استفاده می‌شوند. -اولین بیت از سمت راست (0x1) از شناسه جریان آغازکننده‌ی جریان را شناسایی می‌کند. کارخواه‌ها جریان‌های زوج را آغاز می‌کنند (آنهایی که اولین بیت‌شان از سمت راست برابر صفر قرار گرفته است)؛ کارگزار‌ها جریان‌های فرد را آغاز می‌کنند (آنهایی که اولین بیت‌شان از سمت راست برابر یک است). +اولین بیت از سمت راست (0x1) از شناسه جریان آغازکننده‌ی جریان را شناسایی +می‌کند. کارخواه‌ها جریان‌های زوج را آغاز می‌کنند (آنهایی که +اولین بیت‌شان از سمت راست برابر صفر قرار گرفته است)؛ کارگزار‌ها +جریان‌های فرد را آغاز می‌کنند (آنهایی که اولین بیت‌شان از سمت +راست برابر یک است). -دومین بیت از سمت راست (0x2) از شناسه جریان، جریان‌های یک طرفه و دو طرفه را از هم جدا می‌سازد. جریان‌های یک طرفه همیشه این بیت را روی یک قرار می‌دهند و جریان ‌های دو طرفه این بیت را روی صفر قرار می‌دهند. +دومین بیت از سمت راست (0x2) از شناسه جریان، جریان‌های یک طرفه و دو طرفه را +از هم جدا می‌سازد. جریان‌های یک طرفه همیشه این بیت را روی یک قرار +می‌دهند و جریان ‌های دو طرفه این بیت را روی صفر قرار می‌دهند. ## هم‌زمانی جریان -پروتکل QUIC به شماری از جریان‌های تصادفی اجازه می‌دهد که به شکل همزمان کار کنند. یک پایانه تعداد جریان‌های همزمان و فعال پیش‌رو را با محدود کردن حداکثر شناسه جریان محدود و مشخص می‌سازد. +پروتکل QUIC به شماری از جریان‌های تصادفی اجازه می‌دهد که به شکل همزمان +کار کنند. یک پایانه تعداد جریان‌های همزمان و فعال پیش‌رو را با محدود +کردن حداکثر شناسه جریان محدود و مشخص می‌سازد. -حداکثر شناسه جریان مختص هر پایانه‌ است و تنها شامل آن همتایی است که تنظیم را دریافت می‌کند. +حداکثر شناسه جریان مختص هر پایانه‌ است و تنها شامل آن همتایی است که تنظیم +را دریافت می‌کند. ## ارسال و دریافت داده‌ها -پایانه‌ها از جریان‌ها برای ارسال و دریافت داده‌ها استفاده می‌کنند. هرچه باشد مقصود نهایی آنها همین است. جریان‌ها یک جریان-بایتِ انتزاعی و متوالی هستند. گرچه جریان‌های جداگانه لزوماً به ترتیب اصلی تحویل داده نمی‌شوند. +پایانه‌ها از جریان‌ها برای ارسال و دریافت داده‌ها استفاده +می‌کنند. هرچه باشد مقصود نهایی آنها همین است. جریان‌ها یک جریان-بایتِ +انتزاعی و متوالی هستند. گرچه جریان‌های جداگانه لزوماً به ترتیب اصلی تحویل +داده نمی‌شوند. ## الویت بندی جریان -اگر منابع تخصیص داده شده به جریان‌ها بطور صحیح اولویت بندی شده باشند تسهیم جریان تاثیر بسزایی بر روی عملکرد برنامه می‌گذارد. تجربه با دیگر پروتکل‌های توزیع شده، همانند HTTP/2 نشان می‌دهد که استراتژی‌های اولویت بندیِ مؤثر اثر مثبتِ بسزایی بر روی عملکرد دارند. +اگر منابع تخصیص داده شده به جریان‌ها بطور صحیح اولویت بندی شده باشند تسهیم +جریان تاثیر بسزایی بر روی عملکرد برنامه می‌گذارد. تجربه با دیگر +پروتکل‌های توزیع شده، همانند HTTP/2 نشان می‌دهد که استراتژی‌های +اولویت بندیِ مؤثر اثر مثبتِ بسزایی بر روی عملکرد دارند. -پروتکل QUIC خودش قاب‌هایی برای تبادل اطلاعات اولویت بندی را ارائه نمی‌دهد. در عوض به دریافت اطلاعاتِ اولویت بندی توسط برنامه‌ای که از QUIC استفاده می‌کند اتکا می‌کند. پروتکل‌هایی که از QUIC استفاده می‌کنند این امکان و قابلیت را دارند که هر ترتیب اولویت بندی که متناسب با معنای برنامه آنها باشد تعریف کنند. +پروتکل QUIC خودش قاب‌هایی برای تبادل اطلاعات اولویت بندی را ارائه +نمی‌دهد. در عوض به دریافت اطلاعاتِ اولویت بندی توسط برنامه‌ای که از QUIC +استفاده می‌کند اتکا می‌کند. پروتکل‌هایی که از QUIC استفاده +می‌کنند این امکان و قابلیت را دارند که هر ترتیب اولویت بندی که متناسب با +معنای برنامه آنها باشد تعریف کنند. -هنگامی‌که HTTP/3 از طریق QUIC انجام می‌گیرد، اولویت بندی در لایه‌ی HTTP صورت می‌پذیرد. +هنگامی‌که HTTP/3 از طریق QUIC انجام می‌گیرد، اولویت بندی در لایه‌ی +HTTP صورت می‌پذیرد. diff --git a/fa/quic-tls.md b/fa/quic-tls.md index 0e54668c..2b0d1a52 100644 --- a/fa/quic-tls.md +++ b/fa/quic-tls.md @@ -1,5 +1,9 @@ # اتصال‌ها از TLS استفاده می‌کنند -بلافاصله بعد از اولین بسته‌ای که اتصال را برقرار می‌کند، آغازکننده یک قابِ رمزگذاری شده ارسال می‌کند که شروع به برقراری دست‌دهی لایه‌ی امن می‌کند. لایه‌ی امنیت از امنیت TLS 1.3 استفاده می‌کند. +بلافاصله بعد از اولین بسته‌ای که اتصال را برقرار می‌کند، آغازکننده یک +قابِ رمزگذاری شده ارسال می‌کند که شروع به برقراری دست‌دهی لایه‌ی +امن می‌کند. لایه‌ی امنیت از امنیت TLS 1.3 استفاده می‌کند. -هیچ راه خروج یا جلوگیری از استفاده‌ی TLS برای یک اتصال QUIC وجود ندارد. این پروتکل به نحوی طراحی شده است تا مداخله‌ و نفوذ برای دستگاه‌های میانی دشوار باشد، تا به جلوگیری از تغییرات و استخوان سازی زودرس پروتکل کمک کند. +هیچ راه خروج یا جلوگیری از استفاده‌ی TLS برای یک اتصال QUIC وجود ندارد. این +پروتکل به نحوی طراحی شده است تا مداخله‌ و نفوذ برای دستگاه‌های میانی +دشوار باشد، تا به جلوگیری از تغییرات و استخوان سازی زودرس پروتکل کمک کند. diff --git a/fa/quic-userspace.md b/fa/quic-userspace.md index 74ace83c..a46a6090 100644 --- a/fa/quic-userspace.md +++ b/fa/quic-userspace.md @@ -1,11 +1,21 @@ ## فضای کاربر -پیاده‌سازی یک پروتکل انتقال در فضای کاربر کمک به نسخه‌دهی و توسعه‌ی سریع‌تر پروتکل می‌کند، چرا که نسخه‌دهی و تکامل یافتن پروتکل بدون ناگزیر ساختن کارخواه و کارگزار به بهنگام در آوردن هسته‌‌ی سیستم عامل‌هایشان به جهت استفاده و قرار دادن نسخه‌های جدید نسبتاً ساده خواهد بود. +پیاده‌سازی یک پروتکل انتقال در فضای کاربر کمک به نسخه‌دهی و +توسعه‌ی سریع‌تر پروتکل می‌کند، چرا که نسخه‌دهی و تکامل یافتن +پروتکل بدون ناگزیر ساختن کارخواه و کارگزار به بهنگام در آوردن هسته‌‌ی +سیستم عامل‌هایشان به جهت استفاده و قرار دادن نسخه‌های جدید نسبتاً ساده +خواهد بود. -هیچ چیز در QUIC مانع از پیاده‌سازی و در اختیار گذاشتن آن توسط هسته‌ی سیستم عامل در آینده نمی‌شود، در صورتی که کسی فکر کند می‌تواند ایده خوبی باشد. +هیچ چیز در QUIC مانع از پیاده‌سازی و در اختیار گذاشتن آن توسط هسته‌ی +سیستم عامل در آینده نمی‌شود، در صورتی که کسی فکر کند می‌تواند ایده +خوبی باشد. ### پیاده‌سازی‌های فراوان -یک تأثیر آشکار از پیاده‌سازی یک پروتکلِ انتقال در فضای کاربر این است که می‌توانیم انتظار دیدن پیاده‌سازی‌های مستقل فراوانی را داشته باشیم. +یک تأثیر آشکار از پیاده‌سازی یک پروتکلِ انتقال در فضای کاربر این است که +می‌توانیم انتظار دیدن پیاده‌سازی‌های مستقل فراوانی را داشته +باشیم. -نرم‌افزار‌های مختلف احتمالاً شامل (یا لایه‌ بالا) پیاده‌سازی‌های مختلف HTTP/3 و QUIC برای آینده‌ی قابل پیش‌بینی خواهند بود. +نرم‌افزار‌های مختلف احتمالاً شامل (یا لایه‌ بالا) +پیاده‌سازی‌های مختلف HTTP/3 و QUIC برای آینده‌ی قابل +پیش‌بینی خواهند بود. diff --git a/fa/quic-v2.md b/fa/quic-v2.md index a16ced5c..92523665 100644 --- a/fa/quic-v2.md +++ b/fa/quic-v2.md @@ -1,25 +1,46 @@ # پروتکل QUIC نسخه ۲ -بمنظور آنکه بیشترین تمرکز ممکن بر روی هسته‌ی پروتکل QUIC دریافت شود و بتوان آنرا به موقع تحویل داد، برخی از ویژگی‌هایی که در اصل قرار بود تا بخشی از پروتکل مرکزی باشند به تعویق افتادند و اکنون بنا بر این است تا در نسخ بعدی QUIC قرار داده شوند. نسخه‌ی دوم QUIC یا فراتر. +بمنظور آنکه بیشترین تمرکز ممکن بر روی هسته‌ی پروتکل QUIC دریافت شود و بتوان +آنرا به موقع تحویل داد، برخی از ویژگی‌هایی که در اصل قرار بود تا بخشی از +پروتکل مرکزی باشند به تعویق افتادند و اکنون بنا بر این است تا در نسخ بعدی QUIC +قرار داده شوند. نسخه‌ی دوم QUIC یا فراتر. -گوی سحرآمیز نویسنده‌ی این کتاب‌ خراب است و ما نمی‌توانیم با اطمینان بگوییم کدام قابلیت‌ها در نسخه‌ی ۲ می‌آیند یا نمی‌آیند. هرچند می‌توانیم به برخی از قابلیت‌هایی که بطور صریح از نسخه ۱ حذف شده اند تا "بعدتر بر روی آن‌ها کار شود" و احتمالاً در نسخه ۲ پدیدار شوند اشاره کنیم. +گوی سحرآمیز نویسنده‌ی این کتاب‌ خراب است و ما نمی‌توانیم با +اطمینان بگوییم کدام قابلیت‌ها در نسخه‌ی ۲ می‌آیند یا +نمی‌آیند. هرچند می‌توانیم به برخی از قابلیت‌هایی که بطور صریح از +نسخه ۱ حذف شده اند تا "بعدتر بر روی آن‌ها کار شود" و احتمالاً در نسخه ۲ +پدیدار شوند اشاره کنیم. ## تصحیح خطای مستقیم (Forward Error Correction) -تصحیح خطای مستقیم (FEC) یا "کدگذاری کانال" روش به دست آوردن کنترل خطا در انتقال داده‌هاست که در آن فرستنده داده‌هایی زائد را ارسال می‌کند (برای مقابله با بروز خطا به هنگام انتقال) و دریافت‌کننده تنها قسمتی از داده که هیچ خطای مشهودی نداشته باشد را تشخیص می‌دهد. +تصحیح خطای مستقیم (FEC) یا "کدگذاری کانال" روش به دست آوردن کنترل خطا در انتقال +داده‌هاست که در آن فرستنده داده‌هایی زائد را ارسال می‌کند (برای +مقابله با بروز خطا به هنگام انتقال) و دریافت‌کننده تنها قسمتی از داده که +هیچ خطای مشهودی نداشته باشد را تشخیص می‌دهد. -گوگل این قابلیت را در کارهای اصلی خود با QUIC مورد آزمایش قرار داد اما این قابلیت بعدتر دوباره حذف شد چرا که آزمایش‌ها پاسخ مثبتی به همراه نداشتند. این قابلیت موضوع بحث QUIC نسخه ۲ است اما احتمالاً‌ نیاز دارد تا شخصی ثابت کند که این در واقع یک افزودنی مفید و بدون ضرر و زیان بیش از اندازه است. +گوگل این قابلیت را در کارهای اصلی خود با QUIC مورد آزمایش قرار داد اما این +قابلیت بعدتر دوباره حذف شد چرا که آزمایش‌ها پاسخ مثبتی به همراه نداشتند. +این قابلیت موضوع بحث QUIC نسخه ۲ است اما احتمالاً‌ نیاز دارد تا شخصی ثابت کند +که این در واقع یک افزودنی مفید و بدون ضرر و زیان بیش از اندازه است. ## چند مسیره -چند مسیره بدین معناست که انتقال می‌تواند به خودی خود از مسیر‌های شبکه گوناگون استفاده کند تا استفاده از منابع را بالا ببرد و افزونگی (redundancy) را افزایش ‌دهد. +چند مسیره بدین معناست که انتقال می‌تواند به خودی خود از مسیر‌های شبکه +گوناگون استفاده کند تا استفاده از منابع را بالا ببرد و افزونگی (redundancy) را +افزایش ‌دهد. -حامیان SCTP در جهان علاقه دارند تا به این موضوع اشاره کنند که SCTP هم اکنون از قابلیت چند مسیره برخوردار است و TCP مدرن نیز به همچنین. +حامیان SCTP در جهان علاقه دارند تا به این موضوع اشاره کنند که SCTP هم اکنون از +قابلیت چند مسیره برخوردار است و TCP مدرن نیز به همچنین. ## داده‌های نامعتبر -ارائه‌ی جریان‌های نامعتبر به عنوان یک امکان مورد بحث قرار گرفته است، که بعد به QUIC این اجازه را می‌دهد که نرم‌افزار‌های به سبک UDP را نیز جایگزین کند. +ارائه‌ی جریان‌های نامعتبر به عنوان یک امکان مورد بحث قرار گرفته است، +که بعد به QUIC این اجازه را می‌دهد که نرم‌افزار‌های به سبک UDP را +نیز جایگزین کند. ## سازگاری‌های غیر HTTP -قابلیت DNS روی QUIC یکی از اولین پروتکل‌های غیر HTTP اشاره شده است که احتمال می‌رود زمانی که QUIC نسخه ۱ و HTTP/3 عرضه شوند توجهات رو به خود جلب کند. اما با آورده شدن چنین انتقال جدیدی به دنیا نمی‌توانم تصور کنم که همینجا توقف پیدا کند. +قابلیت DNS روی QUIC یکی از اولین پروتکل‌های غیر HTTP اشاره شده است که +احتمال می‌رود زمانی که QUIC نسخه ۱ و HTTP/3 عرضه شوند توجهات رو به خود جلب +کند. اما با آورده شدن چنین انتقال جدیدی به دنیا نمی‌توانم تصور کنم که +همینجا توقف پیدا کند. diff --git a/fa/quic.md b/fa/quic.md index 3e857dc1..967e3e7c 100644 --- a/fa/quic.md +++ b/fa/quic.md @@ -1,6 +1,10 @@ # پروتکل QUIC چطور کار می‌کند -بدون توضیح دقیق ریز و درشت‌ها (بیت‌ و بایت‌ها) این بخش نحوه کارکردِ قطعاتِ اساسیِ سازنده‌یِ پروتکلِ انتقالِ QUIC را شرح می‌دهد. اگر شما قصد دارید تا پشته‌ی QUIC خودتان را پیاده‌سازی کنید، این تشریح‌ بایست یک فهم و دید کلی به شما بدهد، اما برای تمامی جزئیات، به پیش ‌نویس‌ها و RFC های کارگروه مهندسی اینترنت (IETF) رجوع نمایید. +بدون توضیح دقیق ریز و درشت‌ها (بیت‌ و بایت‌ها) این بخش نحوه +کارکردِ قطعاتِ اساسیِ سازنده‌یِ پروتکلِ انتقالِ QUIC را شرح می‌دهد. اگر شما +قصد دارید تا پشته‌ی QUIC خودتان را پیاده‌سازی کنید، این تشریح‌ +بایست یک فهم و دید کلی به شما بدهد، اما برای تمامی جزئیات، به پیش +‌نویس‌ها و RFC های کارگروه مهندسی اینترنت (IETF) رجوع نمایید. ۱. یک [اتصال](quic-connections.md) برقرار نمایید diff --git a/fa/specs.md b/fa/specs.md index 549f5a5b..497be0ea 100644 --- a/fa/specs.md +++ b/fa/specs.md @@ -1,27 +1,34 @@ # مشخصات -در اینجا مجموعی از آخرین پیش‌نویس‌های رسمی برای بخش‌های مختلف QUIC و HTTP/3 آورده شده است. +در اینجا مجموعی از آخرین پیش‌نویس‌های رسمی برای بخش‌های مختلف +QUIC و HTTP/3 آورده شده است. ## نامتغیر‌ها -[دارایی‌های غیروابسته به نسخه و مستقل پروتکل QUIC](https://tools.ietf.org/html/draft-ietf-quic-invariants) +[دارایی‌های غیروابسته به نسخه و مستقل پروتکل +QUIC](https://tools.ietf.org/html/draft-ietf-quic-invariants) ## انتقال -[پروتکل QUIC: یک انتقال امن و چندگانه‌ی UDP محور](https://tools.ietf.org/html/draft-ietf-quic-transport) +[پروتکل QUIC: یک انتقال امن و چندگانه‌ی UDP +محور](https://tools.ietf.org/html/draft-ietf-quic-transport) ## بازیابی -[تشخیص اتلاف و کنترل تراکم پروتکل QUIC](https://tools.ietf.org/html/draft-ietf-quic-recovery) +[تشخیص اتلاف و کنترل تراکم پروتکل +QUIC](https://tools.ietf.org/html/draft-ietf-quic-recovery) ## امنیت لایه انتقال -[استفاده از TLS برای امن‌سازی پروتکل QUIC](https://tools.ietf.org/html/draft-ietf-quic-tls) +[استفاده از TLS برای امن‌سازی پروتکل +QUIC](https://tools.ietf.org/html/draft-ietf-quic-tls) ## پروتکل انتقال ابرمتن -[پروتکل انتقال ابرمتن نسخه ۳ (HTTP/3)](https://tools.ietf.org/html/draft-ietf-quic-http) +[پروتکل انتقال ابرمتن نسخه ۳ +(HTTP/3)](https://tools.ietf.org/html/draft-ietf-quic-http) ## روش فشرده‌سازی سرایند QPACK -[روش QPACK: فشرده‌سازی سرایند برای HTTP/3](https://tools.ietf.org/html/draft-ietf-quic-qpack) +[روش QPACK: فشرده‌سازی سرایند برای +HTTP/3](https://tools.ietf.org/html/draft-ietf-quic-qpack) diff --git a/fa/the-protocol.md b/fa/the-protocol.md index a39c37a0..f7f2661a 100644 --- a/fa/the-protocol.md +++ b/fa/the-protocol.md @@ -2,6 +2,7 @@ پروتکل QUIC از سطحی بالا. -تصویر پایین پشته شبکه‌ی HTTP/2 در سمت چپ و پشته شبکه‌ی QUIC در سمت راست را نمایش می‌دهد، زمانی که به عنوان انتقالِ HTTP استفاده شود. +تصویر پایین پشته شبکه‌ی HTTP/2 در سمت چپ و پشته شبکه‌ی QUIC در سمت +راست را نمایش می‌دهد، زمانی که به عنوان انتقالِ HTTP استفاده شود. ![QUIC logo](../images/quic-stack.png) diff --git a/fa/why-h2.md b/fa/why-h2.md index d90cae88..d7a3cb30 100644 --- a/fa/why-h2.md +++ b/fa/why-h2.md @@ -1,35 +1,34 @@ ## آیا HTTP/2 را به یاد دارید؟ -مشخصات فنی پروتکل HTTP/2، -[RFC7540](https://httpwg.org/specs/rfc7540.html)، در ماه مِه سال ۲۰۱۵ -منتشر شد و پروتکل HTTP/2 از آن زمان به صورت گسترده در سراسر اینترنت و -شبکه جهانیِ وِب راه‌اندازی و مورد استفاده قرار گرفته است. +مشخصات فنی پروتکل HTTP/2، [RFC7540](https://httpwg.org/specs/rfc7540.html)، در +ماه مِه سال ۲۰۱۵ منتشر شد و پروتکل HTTP/2 از آن زمان به صورت گسترده در سراسر +اینترنت و شبکه جهانیِ وِب راه‌اندازی و مورد استفاده قرار گرفته است. در اوایل سال ۲۰۱۸، حدود ۴۰٪ از ۱۰۰۰ وب‌ سایت برتر از HTTP/2 استفاده می‌کردند، حدود ۷۰٪ از تمام درخواست‌های HTTPS ارسال شده توسط Firefox -پاسخ‌های HTTP/2 دریافت کرده‌اند و تمام مرورگرهای اصلی، سرورها و پروکسی‌ها -این پروتکل را پشتیبانی می‌کنند. +پاسخ‌های HTTP/2 دریافت کرده‌اند و تمام مرورگرهای اصلی، سرورها و +پروکسی‌ها این پروتکل را پشتیبانی می‌کنند. -پروتکل HTTP/2 بسیاری از مشکلات موجود در پروتکل HTTP/1 را برطرف می‌کند و -با ارائه نسخه دوم پروتکل HTTP کاربران قادر به کنارگذاشتن راه‌کارهای -موقت بسیاری هستند که برخی از آن راه‌کارهای موقت برای توسعه‌دهندگان وب -بسیار دشوار است. +پروتکل HTTP/2 بسیاری از مشکلات موجود در پروتکل HTTP/1 را برطرف می‌کند و با +ارائه نسخه دوم پروتکل HTTP کاربران قادر به کنارگذاشتن راه‌کارهای موقت +بسیاری هستند که برخی از آن راه‌کارهای موقت برای توسعه‌دهندگان وب بسیار +دشوار است. یکی از ویژگی‌های اصلی پروتکل HTTP/2 استفاده از روش تسهیم است، روش تسهیم این‌گونه است که بسیاری از جریان‌های منطقی بر روی یک ارتباط فیزیکیِ TCP ارسال می‌شوند. این روش باعث تسریع و بهبود در خیلی از مسائل می‌شود. این -روش باعث بهبود کنترل ازدحام، استفاده بهتر کاربر از ارتباط TCP و در -نتیجه استفاده بهینه از پهنای‌باند، و همچنین افزایش تداوم ارتباطات TCP -که نتیجه آن استفاده‌ی کامل از سرعت به نسبت قبل است می‌شود. فشرده‌سازی +روش باعث بهبود کنترل ازدحام، استفاده بهتر کاربر از ارتباط TCP و در نتیجه استفاده +بهینه از پهنای‌باند، و همچنین افزایش تداوم ارتباطات TCP که نتیجه آن +استفاده‌ی کامل از سرعت به نسبت قبل است می‌شود. فشرده‌سازی سرآیندها نیز منجر به استفاده‌ی کمتر از پهنای‌باند می‌شود. -با استفاده از HTTP/2 مرورگرها معمولاً از *یک* ارتباط TCP با هر میزبان -به جای *شش* ارتباط که در گذشته رایج بود، استفاده می‌کنند. در واقع، -تکنیک‌هایی مانند 'desharding' و 'coalescing' که همراه HTTP/2 استفاده -می‌شود، می‌تواند به مراتب تعداد ارتباطات را کاهش دهد. +با استفاده از HTTP/2 مرورگرها معمولاً از *یک* ارتباط TCP با هر میزبان به جای *شش* +ارتباط که در گذشته رایج بود، استفاده می‌کنند. در واقع، تکنیک‌هایی +مانند 'desharding' و 'coalescing' که همراه HTTP/2 استفاده می‌شود، +می‌تواند به مراتب تعداد ارتباطات را کاهش دهد. همچنین HTTP/2 مشکل 'Head-of-line (HOL) blocking' که باعث می‌شد تا کاربر -مجبور به انتظار برای اتمام درخواست اولِ در صف پیش از ارسال درخواست‌های -بعدی باشد را حل کرد. +مجبور به انتظار برای اتمام درخواست اولِ در صف پیش از ارسال درخواست‌های بعدی +باشد را حل کرد. ![http2 man](../images/h2-man.jpg) diff --git a/fa/why-latency.md b/fa/why-latency.md index 164ad00a..7030cf50 100644 --- a/fa/why-latency.md +++ b/fa/why-latency.md @@ -1,13 +1,28 @@ # داده‌های اولیه -QUIC هم دست‌دهی 0-RTT و هم دست‌دهی 1-RTT را ارائه می‌کند که باعث کاهش زمان لازم برای مذاکره و برقراری اتصال جدید می‌شود. مقایسه شود با دست‌دهی سه‌گانه‌ی TCP. +QUIC هم دست‌دهی 0-RTT و هم دست‌دهی 1-RTT را ارائه می‌کند که باعث +کاهش زمان لازم برای مذاکره و برقراری اتصال جدید می‌شود. مقایسه شود با +دست‌دهی سه‌گانه‌ی TCP. -علاوه بر آن، QUIC از همان ابتدا ”داده‌های اولیه“ را که برای پذیرفتن داده‌های بیشتر صورت می‌پذیرد و نسبت به TCP Fast Open هم سریعتر بکار گرفته می‌شود پشتیبانی می‌کرد. +علاوه بر آن، QUIC از همان ابتدا ”داده‌های اولیه“ را که برای پذیرفتن +داده‌های بیشتر صورت می‌پذیرد و نسبت به TCP Fast Open هم سریعتر بکار +گرفته می‌شود پشتیبانی می‌کرد. -با مفهموم جریان، یک اتصال به میزبان بدون آنکه ابتدا نیازی به انتظار کشیدن برای پایانِ اتصالِ موجود داشته باشد بی‌درنگ می‌تواند صورت پذیرد. +با مفهموم جریان، یک اتصال به میزبان بدون آنکه ابتدا نیازی به انتظار کشیدن برای +پایانِ اتصالِ موجود داشته باشد بی‌درنگ می‌تواند صورت پذیرد. ## قابلیت TCP Fast Open مشکل ساز است -قابلیت TCP Fast Open برای اولین بار در تاریخ دسامبر ۲۰۱۴ به عنوان [RFC 7413](https://tools.ietf.org/html/rfc7413) منتشر شد. این مشخصات واصفِ چگونگی انتقال داده‌ها توسط نرم‌افزار به سمت کارساز، به نحوی که در همان اولین بسته‌ی TCP SYN دریافت شوند، است. +قابلیت TCP Fast Open برای اولین بار در تاریخ دسامبر ۲۰۱۴ به عنوان [RFC +7413](https://tools.ietf.org/html/rfc7413) منتشر شد. این مشخصات واصفِ چگونگی +انتقال داده‌ها توسط نرم‌افزار به سمت کارساز، به نحوی که در همان اولین +بسته‌ی TCP SYN دریافت شوند، است. -پشتیبانی فعلی برای این ویژگی زمان بسیار برده است و حتی امروزه در ۲۰۱۸ نیز پر از مشکلات و مسائل است. پیاده‌‌سازانِ پشته‌ی TCP و همچنین برنامه‌هایی که سعی در بهره‌وری از این ویژگی دارند مشکلاتی داشته‌اند - هردو در فهمیدن آنکه در کدام نسخه از سیستم عامل سعی بر فعالسازی آن داشته باشند و همچنین در فهم آنکه چگونه با ملایمت و موقرانه کنار بکشند و هنگام بروز مشکلات با آن مقابله کنند. چندین شبکه به مداخله در ترافیک TFO شناخته شده‌اند و آنها بدین ترتیب چنین دست‌دهی‌های TCP را عمداً تخریب کرده‌اند. +پشتیبانی فعلی برای این ویژگی زمان بسیار برده است و حتی امروزه در ۲۰۱۸ نیز پر از +مشکلات و مسائل است. پیاده‌‌سازانِ پشته‌ی TCP و همچنین +برنامه‌هایی که سعی در بهره‌وری از این ویژگی دارند مشکلاتی +داشته‌اند - هردو در فهمیدن آنکه در کدام نسخه از سیستم عامل سعی بر فعالسازی +آن داشته باشند و همچنین در فهم آنکه چگونه با ملایمت و موقرانه کنار بکشند و هنگام +بروز مشکلات با آن مقابله کنند. چندین شبکه به مداخله در ترافیک TFO شناخته +شده‌اند و آنها بدین ترتیب چنین دست‌دهی‌های TCP را عمداً تخریب +کرده‌اند. diff --git a/fa/why-ossification.md b/fa/why-ossification.md index 4ac43e25..58d2ab7a 100644 --- a/fa/why-ossification.md +++ b/fa/why-ossification.md @@ -1,19 +1,50 @@ # استخوان‌سازی (Ossification) -اینترنت شبکه‌ای از شبکه‌هاست. در طول مسیر تجهیزاتی در جاهای مختلف بر روی اینترنت راه اندازی شده‌اند تا از کارکرد درست این شبکه‌ای از شبکه‌ها اطمینان حاصل کنند. این دستگاه‌ها، دستگاه‌هایی که در شبکه توزیع شده‌اند، همان‌هایی هستند که ما اغلب به عنوان دستگاه‌های میانی از آنها یاد می‌کنیم. دستگاه‌هایی که در جایی بین دو پایانه قرار گرفته‌اند و بخش‌های اصلی انتقال داده‌های شبکه مرسوم را تشکیل می‌دهند. - -این دستگاه‌ها در خدمت اهداف مشخصی هستند اما من فکر می‌کنم که می‌توان گفت بطور کلی به دلیل آنکه شخصی فکر می‌کند آنها باید در آنجا باشند تا همه چیز درست کار کند آنجا قرار گرفته‌اند. - -دستگاه‌های میانی بسته‌های IP را بین شبکه‌ها مسیریابی می‌کنند، آن‌ها ترافیک مخرب را مسدود می‌کنند، ‌عمل NAT (برگردان نشانی شبکه) را انجام می‌دهند، کارایی را بهبود می‌بخشند، برخی تلاش می‌کنند تا ترافیک در حال عبور را مورد بررسی و جاسوسی قرار دهند، و بیشتر. - -برای آنکه این دستگاه‌ها وظیفه‌ خود را انجام دهند ملزم هستند تا درباره‌ی شبکه و پروتکل‌هایی که توسط آن‌ها نظارت شده و یا تغییر یافته است آگاه باشند. آنها نرم افزار را به همین هدف اجرا می‌کنند. نرم افزاری که پیاپی بروزرسانی نمی‌شود. - -گرچه این‌ها اجزای متصل کننده‌ای هستند که اینترنت را در کنار هم نگاه می‌دارند معمولاً با آخرین تکنولوژی همراه نیستند. میانه‌ی شبکه معمولاً به سرعتِ لبه‌ها، کارخواه‌ها و کارگزار‌های سراسر جهان حرکت نمی‌کند. - -پروتکل‌هایی که این دستگاه‌ها ممکن است بخواهند بررسی کنند و ببینند تا که چه چیز درست هست و چه چیز خیر، چنین مشکلاتی را دارند: این دستگاه‌ها مدت‌ها قبل هنگامی که این پروتکل‌ها امکانات آن زمان را داشتند کار گذاشته شده‌اند. معرفی امکانات جدید‌تر یا تغییر در عملکرد به گونه‌ای که قبل‌تر شناخته نشده است می‌تواند خطرِ بد و یا غیرمجاز تلقی شدن توسط چنین دستگاه‌هایی به همراه داشته باشد. چنین ترافیکی می‌تواند افت یا تأخیر داشته باشد تا درجه‌ای که کاربران به راستی دیگر نخواهند از آن امکانات استفاده کنند. +اینترنت شبکه‌ای از شبکه‌هاست. در طول مسیر تجهیزاتی در جاهای مختلف بر +روی اینترنت راه اندازی شده‌اند تا از کارکرد درست این شبکه‌ای از +شبکه‌ها اطمینان حاصل کنند. این دستگاه‌ها، دستگاه‌هایی که در شبکه +توزیع شده‌اند، همان‌هایی هستند که ما اغلب به عنوان دستگاه‌های +میانی از آنها یاد می‌کنیم. دستگاه‌هایی که در جایی بین دو پایانه قرار +گرفته‌اند و بخش‌های اصلی انتقال داده‌های شبکه مرسوم را تشکیل +می‌دهند. + +این دستگاه‌ها در خدمت اهداف مشخصی هستند اما من فکر می‌کنم که +می‌توان گفت بطور کلی به دلیل آنکه شخصی فکر می‌کند آنها باید در آنجا +باشند تا همه چیز درست کار کند آنجا قرار گرفته‌اند. + +دستگاه‌های میانی بسته‌های IP را بین شبکه‌ها مسیریابی +می‌کنند، آن‌ها ترافیک مخرب را مسدود می‌کنند، ‌عمل NAT +(برگردان نشانی شبکه) را انجام می‌دهند، کارایی را بهبود می‌بخشند، برخی +تلاش می‌کنند تا ترافیک در حال عبور را مورد بررسی و جاسوسی قرار دهند، و +بیشتر. + +برای آنکه این دستگاه‌ها وظیفه‌ خود را انجام دهند ملزم هستند تا +درباره‌ی شبکه و پروتکل‌هایی که توسط آن‌ها نظارت شده و یا تغییر +یافته است آگاه باشند. آنها نرم افزار را به همین هدف اجرا می‌کنند. نرم +افزاری که پیاپی بروزرسانی نمی‌شود. + +گرچه این‌ها اجزای متصل کننده‌ای هستند که اینترنت را در کنار هم نگاه +می‌دارند معمولاً با آخرین تکنولوژی همراه نیستند. میانه‌ی شبکه معمولاً به +سرعتِ لبه‌ها، کارخواه‌ها و کارگزار‌های سراسر جهان حرکت +نمی‌کند. + +پروتکل‌هایی که این دستگاه‌ها ممکن است بخواهند بررسی کنند و ببینند تا +که چه چیز درست هست و چه چیز خیر، چنین مشکلاتی را دارند: این دستگاه‌ها +مدت‌ها قبل هنگامی که این پروتکل‌ها امکانات آن زمان را داشتند کار +گذاشته شده‌اند. معرفی امکانات جدید‌تر یا تغییر در عملکرد به +گونه‌ای که قبل‌تر شناخته نشده است می‌تواند خطرِ بد و یا غیرمجاز +تلقی شدن توسط چنین دستگاه‌هایی به همراه داشته باشد. چنین ترافیکی +می‌تواند افت یا تأخیر داشته باشد تا درجه‌ای که کاربران به راستی دیگر +نخواهند از آن امکانات استفاده کنند. چنین مشکلی را "سختی پروتکل" و یا "استخوان‌سازی پروتکل" می‌نامند. -تغییرات در TCP نیز دچار سختی می‌شوند: برخی دستگاه‌ها مابین یک کارخواه و کارگزار موارد ناشناخته‌ی جدید TCP را تشخیص می‌دهند و از آنجا که آنها نمی‌دانند این موادر چیستند چنین اتصالاتی را مسدود می‌کنند. سیستم‌ها اگر مجاز به بررسی جزئیات پروتکل‌ باشند، نحوه برخورد همیشگی آنها را یاد می‌گیرند و به مرور تغییر آنها ناممکن می‌شود. +تغییرات در TCP نیز دچار سختی می‌شوند: برخی دستگاه‌ها مابین یک کارخواه +و کارگزار موارد ناشناخته‌ی جدید TCP را تشخیص می‌دهند و از آنجا که آنها +نمی‌دانند این موادر چیستند چنین اتصالاتی را مسدود می‌کنند. +سیستم‌ها اگر مجاز به بررسی جزئیات پروتکل‌ باشند، نحوه برخورد همیشگی +آنها را یاد می‌گیرند و به مرور تغییر آنها ناممکن می‌شود. -تنها راهِ به‌راستی مؤثر برای "مقابله" با استخوان‌سازی، این است که ارتباطات به جهت جلوگیری از دیده شدن بیشتر محتوای در حال گذر پروتکل توسط دستگاه‌های میانی تا جای ممکن رمزگذاری شوند. +تنها راهِ به‌راستی مؤثر برای "مقابله" با استخوان‌سازی، این است که +ارتباطات به جهت جلوگیری از دیده شدن بیشتر محتوای در حال گذر پروتکل توسط +دستگاه‌های میانی تا جای ممکن رمزگذاری شوند. diff --git a/fa/why-quic.md b/fa/why-quic.md index d01103b4..0ff33ecb 100644 --- a/fa/why-quic.md +++ b/fa/why-quic.md @@ -4,19 +4,17 @@ کلمه‌ی انگلیسی 'quick' تلفظ می‌شود. از بسیاری جهات، QUIC همان چیزی است که می‌توان آن را روشِ نوینی برای -پیاده‌سازی یک پروتکل انتقال داده امن و قابل اعتماد دانست، به گونه‌ای که -مناسب پروتکلی مانند HTTP باشد. به علاوه این روش می‌تواند بسیاری از نقاط +پیاده‌سازی یک پروتکل انتقال داده امن و قابل اعتماد دانست، به گونه‌ای +که مناسب پروتکلی مانند HTTP باشد. به علاوه این روش می‌تواند بسیاری از نقاط ضعف در راه‌اندازی پروتکل HTTP/2 بر روی TCP و TLS را بهبود بخشد. در واقع -QUIC را میتوان گام منطقی بعدی در سیر تکامل نحوه انتقال اطلاعات بر بستر -وب دانست. +QUIC را میتوان گام منطقی بعدی در سیر تکامل نحوه انتقال اطلاعات بر بستر وب دانست. -قابل ذکر است که QUIC فقط به انتقال اطلاعات توسط پروتکل HTTP محدود -نمی‌شود. احتمالا تمایل به افزایش سرعت انتقال اطلاعات و تحویل وِب به -کاربران نهایی مهمترین دلیلی بوده که در ابتدا منجر به ایجاد این پروتکلِ -انتقالِ جدید شده است. +قابل ذکر است که QUIC فقط به انتقال اطلاعات توسط پروتکل HTTP محدود نمی‌شود. +احتمالا تمایل به افزایش سرعت انتقال اطلاعات و تحویل وِب به کاربران نهایی مهمترین +دلیلی بوده که در ابتدا منجر به ایجاد این پروتکلِ انتقالِ جدید شده است. -بنابراین چرا یک پروتکل انتقال جدید ایجاد می‌شود و چرا این پروتکل جدید -بر بستر UDP ایجاد می‌شود؟ +بنابراین چرا یک پروتکل انتقال جدید ایجاد می‌شود و چرا این پروتکل جدید بر +بستر UDP ایجاد می‌شود؟ ![QUIC logo](../images/QUIC.png) diff --git a/fa/why-secure.md b/fa/why-secure.md index 48b69d71..0e5363f4 100644 --- a/fa/why-secure.md +++ b/fa/why-secure.md @@ -1,5 +1,11 @@ ## امن -پروتکل QUIC همیشه امن است. هیچ نسخه‌ی متن‌آشکاری از این پروتکل وجود ندارد پس برای مذاکره‌ی یک اتصال QUIC باید رمزنگاری و امنیت همراه با TLS 1.3 صورت بگیرد. همانطور که در بالاتر آمد، این مانع از استخوان سازی (به معنای از بین رفتن انعطاف پذیری و امکان توسعه) و همچنین دیگر موانع و رفتار‌های خاص می‌شود - و همچنین اطمینان حاصل می‌کند تا QUIC تمام عوامل ایمنی HTTPS که کاربران وب انتظارش را دارند داشته باشد. +پروتکل QUIC همیشه امن است. هیچ نسخه‌ی متن‌آشکاری از این پروتکل وجود +ندارد پس برای مذاکره‌ی یک اتصال QUIC باید رمزنگاری و امنیت همراه با TLS 1.3 +صورت بگیرد. همانطور که در بالاتر آمد، این مانع از استخوان سازی (به معنای از بین +رفتن انعطاف پذیری و امکان توسعه) و همچنین دیگر موانع و رفتار‌های خاص +می‌شود - و همچنین اطمینان حاصل می‌کند تا QUIC تمام عوامل ایمنی HTTPS +که کاربران وب انتظارش را دارند داشته باشد. -تنها تعداد کمی بسته دست‌دهی اولیه وجود دارند که به صورت آشکارا پیش از آغاز مذاکره پروتکل‌های رمزنگاری ارسال می‌شوند. +تنها تعداد کمی بسته دست‌دهی اولیه وجود دارند که به صورت آشکارا پیش از آغاز +مذاکره پروتکل‌های رمزنگاری ارسال می‌شوند. diff --git a/fa/why-tcphol.md b/fa/why-tcphol.md index 6d0660f5..75f433f7 100644 --- a/fa/why-tcphol.md +++ b/fa/why-tcphol.md @@ -1,31 +1,53 @@ ## مسدود کننده سرِ صف TCP -ارتباطات HTTP/2 بر روی بستر TCP بنا شده و به نسبت نُسَخ قبلی از تعداد اتصالات بسیار کمتری استفاده می‌شود. TCP پروتکلی برای انتقالات قابل اعتماد است و می‌توان آن را اساسا زنجیره‌ای خیالی میان دو ماشین در نظر گرفت. آنچه در انتهایی از شبکه قرار داده شده است به همان ترتیب به انتهای دیگر در شبکه می‌رسد - در نهایت (وگرنه ارتباط قطع می‌شود). +ارتباطات HTTP/2 بر روی بستر TCP بنا شده و به نسبت نُسَخ قبلی از تعداد اتصالات بسیار +کمتری استفاده می‌شود. TCP پروتکلی برای انتقالات قابل اعتماد است و +می‌توان آن را اساسا زنجیره‌ای خیالی میان دو ماشین در نظر گرفت. آنچه در +انتهایی از شبکه قرار داده شده است به همان ترتیب به انتهای دیگر در شبکه +می‌رسد - در نهایت (وگرنه ارتباط قطع می‌شود). ![a TCP chain between two computers](../images/tcp-chain.png) -به کمک HTTP/2، مرورگرهای عادی ده‌ها و صدها انتقال موازی را بر روی یک اتصال TCP انجام می‌دهند. +به کمک HTTP/2، مرورگرهای عادی ده‌ها و صدها انتقال موازی را بر روی یک اتصال +TCP انجام می‌دهند. -در صورتی که یک بسته از بین رفته باشد، و یا جایی در شبکه بین دو نقطه که توسط HTTP/2 صحبت می‌کنند گم شده باشد، به این معناست که کل اتصال TCP متوقف می‌شود تا زمانی که بسته‌ی گم شده دوباره ارسال شود و راه خود را به سمت مقصد نهایی پیدا ‌کند. از آنجایی که TCP این 'زنجیره' است، به این معنی است که اگر یک پیوند به طور ناگهانی از دست رفته باشد، همه چیز پس از آن پیوندِ از دست رفته باید در حالت انتظار باقی بماند. +در صورتی که یک بسته از بین رفته باشد، و یا جایی در شبکه بین دو نقطه که توسط +HTTP/2 صحبت می‌کنند گم شده باشد، به این معناست که کل اتصال TCP متوقف +می‌شود تا زمانی که بسته‌ی گم شده دوباره ارسال شود و راه خود را به سمت +مقصد نهایی پیدا ‌کند. از آنجایی که TCP این 'زنجیره' است، به این معنی است که +اگر یک پیوند به طور ناگهانی از دست رفته باشد، همه چیز پس از آن پیوندِ از دست رفته +باید در حالت انتظار باقی بماند. -یک تصویر با استفاده از استعاره زنجیره‌ای هنگام ارسال دو جریان بر روی این اتصال. جریان قرمز و جریان سبز: +یک تصویر با استفاده از استعاره زنجیره‌ای هنگام ارسال دو جریان بر روی این +اتصال. جریان قرمز و جریان سبز: ![the chain showing links in different colors](../images/tcp-chain-streams.png) -این یک head-of-line block یا به اختصار HOL block مبتنی بر TCP (مسدود کننده سرِ صفِ TCP) می‌شود. +این یک head-of-line block یا به اختصار HOL block مبتنی بر TCP (مسدود کننده سرِ صفِ +TCP) می‌شود. -با افزایش درصد از دست رفتن بسته‌ها، HTTP/2 ضعیف و ضعیف‌تر عمل می‌کند. در شرایطی با ۲٪ packet loss (که نشان‌دهنده‌ی کیفیت بسیار پایین و وحشتناکی از شبکه است) آزمایش‌ ثابت کرده است که کاربران HTTP/1 معمولاً از عملکرد بهتری برخوردار خواهند بود - چرا که آنان ۶ اتصال برای توزیع بسته‌های گم شده دارند. که البته همچنین به این معنی است که در صورت از دست رفتن بسته‌ای، اتصال دیگر می‌تواند همچنان به کار خود ادامه دهد. +با افزایش درصد از دست رفتن بسته‌ها، HTTP/2 ضعیف و ضعیف‌تر عمل +می‌کند. در شرایطی با ۲٪ packet loss (که نشان‌دهنده‌ی کیفیت بسیار +پایین و وحشتناکی از شبکه است) آزمایش‌ ثابت کرده است که کاربران HTTP/1 معمولاً +از عملکرد بهتری برخوردار خواهند بود - چرا که آنان ۶ اتصال برای توزیع +بسته‌های گم شده دارند. که البته همچنین به این معنی است که در صورت از دست +رفتن بسته‌ای، اتصال دیگر می‌تواند همچنان به کار خود ادامه دهد. حل این مشکل با TCP اصلاً ساده نخواهد بود، البته اگر ممکن باشد. ## جریان‌های مستقل از انسداد جلوگیری می‌کنند -به کمک QUIC همچنان اتصالی بین دو نقطه وجود دارد که ارتباط را ایمن و ارسال اطلاعات را معتبر و قابل اطمینان می‌سازد. +به کمک QUIC همچنان اتصالی بین دو نقطه وجود دارد که ارتباط را ایمن و ارسال اطلاعات +را معتبر و قابل اطمینان می‌سازد. ![a QUIC chain between two computers](../images/tcp-chain.png) -زمانی که دو جریان مختلف بر روی این اتصال ایجاد شود، آن دو به صورت مجزا دیده می‌شوند، به گونه‌ای که اگر پیوندی برای یکی از دو جریان از دست رفته باشد، تنها آن جریان، آن زنجیره‌ی مشخص، باید منتظر بماند تا پیوند گم شده دوباره برای انتقال ارسال شود. +زمانی که دو جریان مختلف بر روی این اتصال ایجاد شود، آن دو به صورت مجزا دیده +می‌شوند، به گونه‌ای که اگر پیوندی برای یکی از دو جریان از دست رفته +باشد، تنها آن جریان، آن زنجیره‌ی مشخص، باید منتظر بماند تا پیوند گم شده +دوباره برای انتقال ارسال شود. -در اینجا به واسطه‌ی تصویری با یک جریان زرد و یک جریان آبیِ ارسال شده بین دو نقطه توضیح داده شده است. +در اینجا به واسطه‌ی تصویری با یک جریان زرد و یک جریان آبیِ ارسال شده بین دو +نقطه توضیح داده شده است. ![two QUIC streams between two computers](../images/quic-chain-streams.png) diff --git a/fa/why-tcpudp.md b/fa/why-tcpudp.md index d80f06fe..a57aa271 100644 --- a/fa/why-tcpudp.md +++ b/fa/why-tcpudp.md @@ -1,22 +1,48 @@ ## TCP یا UDP -اگر نتوانیم مشکلِ مسدودکننده‌ سرِ صف را در TCP حل کنیم، در اصول نظری باید قادر به تولید یک لایه‌ انتقال جدید در کنار UDP و TCP در پُشته‌ی شبکه باشیم. و یا حتی از [SCTP](https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol) استفاده کنیم که یک پروتکل انتقالِ استاندارد شده توسط IEEE در [RFC 4960](https://tools.ietf.org/html/rfc4960) و دارای چندی از مشخصات مورد نیاز است. - -هر چند، در سالیان اخیر تلاش‌های موبوط به ساخت و تولید لایه‌ انتقال جدید به دلیل سختی کار برای قرار دادن آن بر روی بستر اینترنت تقریباً به صورت کامل متوقف شده است. استفاده‌ی پروتکل‌های جدید توسط بسیاری از firewall ها، NAT ها، router ها و بسیاری از تجهیزات میانی‌ای که برای ارتباط بین کاربر و سرور عقب داشته و مختل شده است. معرفی یک پروتکل انتقالِ دیگر باعث رد شدن N% از اتصالات خواهد شد، چرا که آنان توسط تجهیزات میانی‌ به دلیل ناشناس بودن و در نتیجه تصور به مخرب و یا اشتباه بودنشان رد خواهند شد. و این N% خطا گاهی بسیار بالاتر از آنی که ارزش پیاده‌سازی و متحمل شدن را داشته باشد تلقی می‌شود. - -همچنین، تغییر مسائل در لایه‌ی پروتکل انتقالِ پشته‌ی شبکه معمولاً به معنی پروتوکل‌های راه‌اندازی شده در هسته‌های سیستم عامل (kernel) است. به روز رسانی و به‌کارگیری هسته‌های سیستم عامل روندی آهسته‌ست که مستلزم تلاش و تغییرات قابل توجهی است. بسیاری از بهسازی‌های TCP استاندارد شده توسط IEEE به دلیل عدم پشتیبانی رایج به صورت گسترده استفاده و به کار گرفته نشده‌اند. +اگر نتوانیم مشکلِ مسدودکننده‌ سرِ صف را در TCP حل کنیم، در اصول نظری باید +قادر به تولید یک لایه‌ انتقال جدید در کنار UDP و TCP در پُشته‌ی شبکه +باشیم. و یا حتی از +[SCTP](https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol) +استفاده کنیم که یک پروتکل انتقالِ استاندارد شده توسط IEEE در [RFC +4960](https://tools.ietf.org/html/rfc4960) و دارای چندی از مشخصات مورد نیاز است. + +هر چند، در سالیان اخیر تلاش‌های موبوط به ساخت و تولید لایه‌ انتقال جدید +به دلیل سختی کار برای قرار دادن آن بر روی بستر اینترنت تقریباً به صورت کامل متوقف +شده است. استفاده‌ی پروتکل‌های جدید توسط بسیاری از firewall ها، NAT ها، +router ها و بسیاری از تجهیزات میانی‌ای که برای ارتباط بین کاربر و سرور عقب +داشته و مختل شده است. معرفی یک پروتکل انتقالِ دیگر باعث رد شدن N% از اتصالات خواهد +شد، چرا که آنان توسط تجهیزات میانی‌ به دلیل ناشناس بودن و در نتیجه تصور به +مخرب و یا اشتباه بودنشان رد خواهند شد. و این N% خطا گاهی بسیار بالاتر از آنی که +ارزش پیاده‌سازی و متحمل شدن را داشته باشد تلقی می‌شود. + +همچنین، تغییر مسائل در لایه‌ی پروتکل انتقالِ پشته‌ی شبکه معمولاً به معنی +پروتوکل‌های راه‌اندازی شده در هسته‌های سیستم عامل (kernel) است. +به روز رسانی و به‌کارگیری هسته‌های سیستم عامل روندی آهسته‌ست که +مستلزم تلاش و تغییرات قابل توجهی است. بسیاری از بهسازی‌های TCP استاندارد شده +توسط IEEE به دلیل عدم پشتیبانی رایج به صورت گسترده استفاده و به کار گرفته +نشده‌اند. ## چرا SCTP-over-UDP نه -پروتکل انتقال کنترل جریان (SCTP) یک پروتکل لایه انتقال قابل‌اعتماد از جریان‌ها تست، و همچنین برای WebRTC هم پیاده‌سازی‌هایی از این پروتکل بر روی UDP موجود است. +پروتکل انتقال کنترل جریان (SCTP) یک پروتکل لایه انتقال قابل‌اعتماد از +جریان‌ها تست، و همچنین برای WebRTC هم پیاده‌سازی‌هایی از این +پروتکل بر روی UDP موجود است. به دلایل متعددی این روش به خوبی QUIC نبود، از جلمه: -- پروتکل انتقال کنترل جریان (SCTP) مشکل مسدود کننده‌ی سر صف را برای جریان‌ها حل نمی‌کند -- پروتکل انتقال کنترل جریان (SCTP) برای مرحله‌ی راه‌اندازی نیازمند معین شدن تعداد جریان‌ها است +- پروتکل انتقال کنترل جریان (SCTP) مشکل مسدود کننده‌ی سر صف را برای + جریان‌ها حل نمی‌کند +- پروتکل انتقال کنترل جریان (SCTP) برای مرحله‌ی راه‌اندازی نیازمند + معین شدن تعداد جریان‌ها است - پروتکل انتقال کنترل جریان (SCTP) سابقه محکمی از TLS و امنیت ندارد -- پروتکل انتقال کنترل جریان (SCTP) مبتنی بر دست‌دهی چهار مرحله‌ای است در حالی که QUIC روش 0-RTT را ارائه می‌دهد -- پروتکل QUIC همانند TCP یک bytestream است، در حالی که SCTP پروتکلی message-based است -- اتصالات QUIC می‌توانند بین آدرس‌های IP جابجا شوند در حالی که اتصالات SCTP نمی‌توانند - -برای مطالعه‌ی بیشتر در خصوص تفاوت، به [مقایسه‌ای بین SCTP و QUIC](https://tools.ietf.org/html/draft-joseph-quic-comparison-quic-sctp-00) رجوع شود. +- پروتکل انتقال کنترل جریان (SCTP) مبتنی بر دست‌دهی چهار مرحله‌ای است + در حالی که QUIC روش 0-RTT را ارائه می‌دهد +- پروتکل QUIC همانند TCP یک bytestream است، در حالی که SCTP پروتکلی + message-based است +- اتصالات QUIC می‌توانند بین آدرس‌های IP جابجا شوند در حالی که اتصالات + SCTP نمی‌توانند + +برای مطالعه‌ی بیشتر در خصوص تفاوت، به [مقایسه‌ای بین SCTP و +QUIC](https://tools.ietf.org/html/draft-joseph-quic-comparison-quic-sctp-00) +رجوع شود. From a5278df6354cdd2dcc14414cece326bd976adc8e Mon Sep 17 00:00:00 2001 From: Faraz Vahedi Date: Thu, 22 Apr 2021 11:15:19 +0000 Subject: [PATCH 03/78] [fa] Update README.md (#198) --- fa/README.md | 48 +++++++++++++++++++++++++----------------------- 1 file changed, 25 insertions(+), 23 deletions(-) diff --git a/fa/README.md b/fa/README.md index 49a50cc5..2cec2e04 100644 --- a/fa/README.md +++ b/fa/README.md @@ -1,47 +1,49 @@ # تفسیر HTTP/3 نوشتن این کتاب در ماه مارس سال ۲۰۱۸ آغاز شده و هدف مستندسازی HTTP/3 و پروتکل آن -است: QUIC. چرایی‌ها، نحوه کارکرد، راه‌اندازی و غیره. +است: QUIC. چرایی‌ها، نحوهٔ کارکرد، جزئیات پروتکل، راه‌اندازی‌ها و +غیره. -این کتاب به صورت کامل رایگان و مبتنی بر همکاری است، بدین صورت که هر کسی مایل -باشد می‌تواند یاری برساند. +این کتاب به‌طور کامل رایگان و مبتنی بر همکاری است، بدین صورت که هر کسی مایل +باشد می‌تواند یاری رساند. ## پیش‌نیازها -از خواننده‌ی این کتاب انتظار می‌رود درک پایه‌ی از TCP/IP و شبکه، -اصول اولیه‌ی HTTP و وِب داشته باشد. برای درک و بدست آوردن دیدی بهتر در خصوص -HTTP/2 مطالعه‌ی [http2 explained](https://daniel.haxx.se/http2/) پیشنهاد +از خوانندهٔ این کتاب انتظار می‌رود درک پایه از شبکهٔ TCP/IP، اصول اولیهٔ HTTP +و وِب داشته باشد. برای درک و بدست آوردن دیدی بهتر در خصوص HTTP/2 مطالعهٔ +[http2 explained](https://daniel.haxx.se/http2/) پیشنهاد می‌شود. ## نویسنده -این کتاب توسط [دنیل استنبرگ](https://daniel.haxx.se/) تهیه، ارائه و آغاز شده -است. دنیل پایه‌گذار و توسعه‌دهنده ارشد [curl](https://curl.haxx.se/)، -رایج‌ترین ابزارِ استفاده شده به عنوان HTTP client است. دنیل بیش از دو دهه با -- و بر روی - پروتکل‌های HTTP و Internet کار کرده و همچنین نویسنده‌ی +این کتاب توسط [دنیل استنبرگ](https://daniel.haxx.se/) تهیه و آغاز شده است. دنیل +پایه‌گذار و توسعه‌دهندهٔ ارشد [curl](https://curl.haxx.se/)، +رایج‌ترین ابزارِ استفاده شده به‌عنوان HTTP client است. دنیل بیش از دو +دهه با، و بر روی، پروتکل‌های HTTP و Internet کار کرده و همچنین نویسندهٔ کتاب [http2 explained](https://daniel.haxx.se/http2/) است. ## خانه -صفحه‌ی اصلی این کتاب قابل دسترس در -[daniel.haxx.se/http3-explained](https://daniel.haxx.se/http3-explained) است. +صفحهٔ اصلی این کتاب در نشانی +[daniel.haxx.se/http3-explained](https://daniel.haxx.se/http3-explained) قابل +دسترس است. ## یاری‌رسانی -در صورت مشاهده‌ی هر گونه اشتباه، سهو و از قلم‌افتادگی، مشکل و یا موردی -در نحوه‌ی نوشتار و یا نگارش، خواهشمند است نسخه‌ای اصلاح‌شده از -پاراگراف مربوطه را برای ما ارسال کنید تا آن را اعمال و به روز کنیم. همچنین از -هرکس که یاری رساند به صورت رسمی تقدیر به جا آورده خواهد شد. به امید بهتر کردن و -کامل‌تر ساختن این دبیزه. +در صورت مشاهدهٔ هر گونه اشتباه، سهو و از قلم‌افتادگی، مشکل و یا موردی در +نحوهٔ نوشتار و یا نگارش، خواهشمند است نسخه‌ای اصلاح‌شده از بند مربوطه +را برای ما ارسال کنید تا آن را اعمال و به‌روز کنیم. همچنین از هرکس که یاری +رساند به‌صورت رسمی تقدیر خواهد شد. به امید بهتر کردن و کامل‌تر ساختن +این دبیزه. -ترجیحا، یا مشکل مربوطه را در -[errors](https://github.com/bagder/http3-explained/issues) و یا بر روی -صفحه‌ی اصلی کتاب به عنوان درخواست [pull -requests](https://github.com/bagder/http3-explained/pulls) ثبت کنید. +ترجیحاً، یا مشکل مربوطه را در +[errors](https://github.com/bagder/http3-explained/issues) و یا به‌عنوان +[pull requests](https://github.com/bagder/http3-explained/pulls) بر روی صفحهٔ +GitHub کتاب ثبت کنید. ## پروانه -این دبیزه و تمامی متعلقات تحت نسخه چهارم اجازه‌نامهٔ مشترکات خلاقانه -(Creative Commons) به انتشار رسیده است. برای کسب اطلاعات بیشتر، به صفحه‌ی +این دبیزه و تمامی متعلقات تحت نسخهٔ چهارم اجازه‌نامهٔ مشترکات خلاقانه +(Creative Commons) به انتشار رسیده است. برای کسب اطلاعات بیشتر، به صفحهٔ [Creative Commons Attribution 4.0 license](https://creativecommons.org/licenses/by/4.0/) مراجعه کنید. From 18975f9a4f9d6ea17c34c43b45916ed939cd0fa5 Mon Sep 17 00:00:00 2001 From: Faraz Vahedi Date: Fri, 23 Apr 2021 09:26:06 +0000 Subject: [PATCH 04/78] [fa] Update criticism.md (#199) --- fa/criticism.md | 54 ++++++++++++++++++++++++------------------------- 1 file changed, 27 insertions(+), 27 deletions(-) diff --git a/fa/criticism.md b/fa/criticism.md index 7137db7e..37e2c061 100644 --- a/fa/criticism.md +++ b/fa/criticism.md @@ -4,39 +4,39 @@ بسیاری از شرکت‌ها، اپراتور‌ها و سازمان‌ها ترافیک UDP خارج از پورت ۵۳ (استفاده شده برای DNS) را از آنجایی که امروزه بیشتر در جهت حمله‌ها مورد -سو‌ءاستفاده قرار می‌گیرد مسدود و یا محدود می‌کنند. همچنین به طور -خاص، برخی از پروتکل‌های UDP موجود و سرور‌های پیاده‌سازی -شده‌ی حاضر برای آنها در برابر حملات تقویت شده و بسیط که در آن یک حمله کننده -می‌تواند ترافیک سنگینی را سمت یک هدف بی‌گناه مورد هدف‌گیری قرار -می‌دهد آسیب پذیر و قابل حمله بوده است. - -پروتکل QUIC یک کاهش‌دهنده‌ی‌‌ داخلی در برابر چنین حملات تقویت -شده‌ای دارد، بدین ترتیب که بسته‌ اولیه بایست حداقل ۱۲۰۰ بایت باشد و با -این محدودیت که یک سرور اجازه ندارد در ازای هر پاسخ بیش از سه برابر از حجم -درخواست را ارسال کند بدون آنکه ابتدا در پاسخ از سمت کاربر بسته‌ای دریافت -کند. +سو‌ءاستفاده قرار می‌گیرد مسدود و یا محدود می‌کنند. همچنین +به‌طور خاص، برخی از پروتکل‌های UDP موجود و سرور‌های +پیاده‌سازی شدهٔٔ حاضر برای آنها، در برابر حملات تقویت شده که در آن مهاجم +می‌تواند ترافیک سنگینی رابه‌سمت یک هدف بی‌گناه ارسال کند، +آسیب‌پذیر بوده‌اند. + +پروتکل QUIC یک کاهش‌دهندهٔ داخلی در برابر چنین حملات تقویت شده دارد، بدین +ترتیب که بستهٔ اولیه باید حداقل ۱۲۰۰ بایت باشد و با این محدودیت که یک سرور اجازه +ندارد در ازای هر پاسخ بیش از سه برابر حجم درخواست را، بدون آنکه ابتدا در پاسخ از +سمت کاربر بسته‌ای دریافت کند، ارسال کند. ## پروتکل UDP در کرنل کند است -که به نظر درست می‌رسد، حداقل امروزه در ۲۰۱۸. ما نمی‌توانیم به ضرس قاطع -بگوییم که این مسأله چگونه توسعه می‌یابد و چقدر از آن نتیجه‌ی سالیان در -دیدرسِ توسعه دهندگان نبودنِ کیفیت انتقال در UDP است. +که به نظر درست می‌رسد، حداقل در وهلهٔ نخست. ما نمی‌توانیم به ضرس قاطع +بگوییم که این مسئله چگونه توسعه می‌یابد و چقدر از آن نتیجهٔ سالیان سهو و +از نظر افتادگی کیفیت انتقال در UDP توسط توسعه‌دهندگان است. -برای اکثر کاربران این کندی هرگز قابل مشاهده نمی‌باشد. +برای اکثر کاربران اما، این کندی هرگز محسوس نیست. ## پروتکل QUIC مقدار قابل توجهی CPU مصرف می‌کند -همانند قسمت بالا، دلیل از آن روست که TCP و TLS زمان بیشتری برای بالغ شدن، بهبود -یافتن و پشتیبانی سخت افزاری است. +همانند قسمت «پروتکل UDP کند است» در بالا، تا حدی علت آن است که TCP و TLS زمان +بیشتری برای بالغ شدن، بهبود یافتن، و به پشتیبانی سخت افزاری رسیدن داشته است. -دلایلی وجود دارد که می‌توان انتظار بهبود این مورد را در طول زمان داشت. سوال -این است که تا چه اندازه این کارکردِ CPU استفاده‌کنندگان را آزار خواهد داد. +دلایلی وجود دارد که انتظار می‌رود این موضوع با گذشت زمان بهبود یابد، و در +حال حاضر نیز شاهد برخی پیشرفت‌ها در این فضا هستیم. سؤال این است که این +استفادهٔ مازاد CPU تا چه اندازه به راه‌اندازان آسیب وارد می‌کند. ## این فقط Google است -نه اینطور نیست. Google مشخصات اولیه را به IETF (کارگروه مهندسی اینترنت) آورد - -بعد از آنکه در یک مقیاس بزرگ اینترنتی ثابت کرد راه‌اندازی چنین پروتکلی بر -روی بستر UDP در واقع بسیار خوب عمل می‌کند. +نه اینطور نیست. Google مشخصات اولیه را، پس از اثبات کارآییِ این نوع +راه‌اندازی از پروتکل بر روی بستر UDP در مقیاس بزرگ، به IETF +()کارگروه مهندسی اینترنت) آورد. از آن موقع، افراد از شرکت‌ها و سازمان‌های متعددی در سازمان تأمین کننده بی‌طرفِ IETF گرد هم آمدند تا یک پروتکل انتقال استاندارد ایجاد کنند. در این @@ -47,12 +47,12 @@ Cloudflare، Akamai، Microsoft، Facebook و Apple. ## این پیشرفت بسیار کوچک است -این یک نقد نیست بلکه یک نظر است. شاید همینطور باشد، شاید این یک پیشرفت خیلی کوچک -و با توجه به هنگامی که HTTP/2 ارائه شد باشد. +این در واقع یک نقد نیست، یک نظر است. شاید همینطور باشد، شاید این یک پیشرفت خیلی +کوچک در مقایسه با زمانی که HTTP/2 ارائه شد باشد. -احتمالاً HTTP/3 در شبکه‌هایی که از دست رفتگی بسته زیاد است بهتر عمل +احتمالاًً HTTP/3 در شبکه‌هایی که از دست رفتگی بسته زیاد است بهتر عمل می‌کند، همچنین handshake سریع‌تری را پیشنهاد می‌کند و در نتیجه -تأخیر را چه در تشخیص و چه در حقیقت بهبود خواهد یافت. اما آیا این امکانات و مزایا -برای ترغیب و تهییج مردم کافیست تا پشتیبانی این پروتکل را روی سرور‌ها و +تأخیر را چه در تشخیص و چه در حقیقت بهبود خواهد داد. اما آیا این امکانات و مزایا +برای ترغیب و تهییج مردم کافیست که پشتیبانی این پروتکل را روی سرور‌ها و سرویس‌های خود اضافه کنند؟ بی‌شک زمان و اندازه‌گیری کیفی در آینده به ما خواهد گفت! From 94f868b7a40dab3849d59f14297eaad9d3d5032e Mon Sep 17 00:00:00 2001 From: Faraz Vahedi Date: Sun, 25 Apr 2021 07:50:28 +0000 Subject: [PATCH 05/78] [fa] Update feature-handshakes.md (#200) --- fa/feature-handshakes.md | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/fa/feature-handshakes.md b/fa/feature-handshakes.md index 0918eb6f..497d93c8 100644 --- a/fa/feature-handshakes.md +++ b/fa/feature-handshakes.md @@ -1,15 +1,14 @@ # دست‌دهی‌های سریع -پروتکل QUIC نحوه اتصال 0-RTT و 1-RTT را ارائه می‌دهد، بدین معنا که در -بهترین حالت QUIC نیازی به round-trip اضافی به هنگام برقراری اتصال ندارد. روش -سریع‌تر بین این دو، دست‌دهی 0-RTT، تنها زمانی کار می‌کند که یک -اتصال از قبل با یک میزبان برقرار شده باشد و یک secret از آن اتصال cache شده +پروتکل QUIC هر دو نحوه اتصال 0-RTT و 1-RTT را ارائه می‌دهد، بدین معنا که در +بهترین حالت QUIC نیازی به round-trip اضافی به‌هنگام برقراری اتصال ندارد. +روش سریع‌تر، دست‌دهی 0-RTT، تنها زمانی کار می‌کند که یک اتصالِ از +پیش برقرار شده با یک میزبان وجود داشته باشد و یک secret از آن اتصال cache شده باشد. -## داده اولیه +## دادهٔ اولیه -پروتکل QUIC به کارخواه اجازه می‌دهد تا داده‌ی موجود از دست‌دهی -0-RTT را شامل شود. این ویژگی به مخاطب این امکان را می‌دهد تا داده را هر چه -سریع‌تر به همتای خود برساند، و البته همچنین سپس این امکان را به سرور -می‌دهد تا حتی پاسخ‌دهی و ارسال داده در مرحله‌ی برگشت را زودتر -انجام دهد. +پروتکل QUIC به کارخواه اجازه می‌دهد تا دادهٔ موجود از دست‌دهی 0-RTT را +شامل شود. این ویژگی به کارخواه این امکان را می‌دهد تا داده را هر چه +سریع‌تر به جفت خود برساند، و البته از این رو همچنین این امکان را به سرور +می‌دهد تا حتی پاسخ‌دهی و ارسال داده در مرحلهٔ برگشت را زودتر انجام دهد. From d5f0cfebd94127803e7f4ed0bf04f8fe2de33ca4 Mon Sep 17 00:00:00 2001 From: Faraz Vahedi Date: Sun, 25 Apr 2021 08:03:33 +0000 Subject: [PATCH 06/78] [fa] Update feature-http.md (#201) --- fa/feature-http.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/fa/feature-http.md b/fa/feature-http.md index c03f5cef..e4d94bdb 100644 --- a/fa/feature-http.md +++ b/fa/feature-http.md @@ -1,11 +1,11 @@ ## پروتکل انتقال ابرمتن نگارش ۳ (HTTP/3) بر روی QUIC -در لایه‌ی HTTP، به نام HTTP/3، ترابردها به شیوه HTTP انجام می‌شود، -مانند فشرده سازی سرایندها با استفاده از QPACK - که مشابه فشرده سازی سرایندها در -HTTP/2 به نام HPACK است. +لایهٔ HTTP، به نام HTTP/3، انتقال را به‌شیوهٔ HTTP مدیریت می‌کند، از جمله +فشرده‌سازی سرایندها با استفاده از QPACK - که مشابه فشرده‌سازی سرایندها +در HTTP/2 به نام HPACK است. -الگوریتم HPACK وابسته به توزیع مرتبِ جریان‌هاست و در نتیجه امکان استفاده +الگوریتم HPACK وابسته به توزیع مرتبِ جریان‌هاست و در نتیجه امکان استفادهٔ دوباره از آن در HTTP/3 بدون اعمال اصلاحات مقدور نبود، چرا که QUIC جریان‌هایی را ارائه می‌دهد که می‌توانند به صورت نامنظم تحویل داده شوند. QPACK را -می‌توان نسخه‌‌ی سازوار با QUIC از +می‌توان نسخهٔ سازگار با QUIC از [HPACK](https://httpwg.org/specs/rfc7541.html) در نظر گرفت. From fc0393811d8837a3aeb1019a0ca2e4e3623beb41 Mon Sep 17 00:00:00 2001 From: Faraz Vahedi Date: Sun, 25 Apr 2021 08:14:58 +0000 Subject: [PATCH 07/78] [fa] Update feature-inorder.md (#202) --- fa/feature-inorder.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/fa/feature-inorder.md b/fa/feature-inorder.md index e39d7ad6..584b5966 100644 --- a/fa/feature-inorder.md +++ b/fa/feature-inorder.md @@ -1,19 +1,19 @@ ## توزیع منظم پروتکل QUIC تحویل/توزیع منظم و کامل جریان‌ها را تضمین می‌کند، اما نه -مابین جریان‌ها. بدین معنا که هر جریان داده را می‌فرستد و ترتیبش را حفظ -می‌کند، اما هر جریانی ممکن است که با ترتیبی متفاوت از آنچه که -نرم‌افزار فرستاده است به مقصد برسد! +مابین جریان‌ها. بدین معنا که هر جریان داده را با حفظ ترتیب آن ارسال +می‌کند، اما هر جریان ممکن است که با ترتیبی متفاوت از آنچه که نرم‌افزار +فرستاده است به مقصد رسد! -بطور مثال: جریان‌های A و B از یک سرور به یک کارخواه منتقل شده‌اند. -جریان A نسبت به جریان B تقدم دارد. در QUIC، یک بسته‌ی گمشده تنها همان -جریانی را که به آن تعلق دارد تحت تاثیر قرار می‌دهد. اگر جریان A یک بسته را -گم ‌کند اما جریان B خیر، جریان B می‌تواند انتقال خود را ادامه دهد و -تکمیل کند در حالیکه بسته‌ گمشده‌ی جریان A دوباره فرستاده می‌شود. -چنین چیزی در HTTP/2 مقدور نبود. +به‌طور مثال: جریان‌های A و B از یک سرور به یک کارخواه منتقل +شده‌اند. جریان A نسبت به جریان B تقدم دارد. در QUIC، یک بستهٔ گمشده تنها +همان جریانی را که به آن تعلق دارد تحت تأثیر قرار می‌دهد. اگر جریان A یک +بسته را گم کند اما جریان B خیر، جریان B می‌تواند انتقال خود را ادامه دهد و +تکمیل کند در حالی که بستهٔ گمشدهٔ جریان A دوباره فرستاده می‌شود. چنین چیزی در +HTTP/2 مقدور نبود. -در تصویر زیر یک جریان زرد و یک جریان آبی مابین دو پایانه‌ی QUIC بر روی یک -اتصال فرستاده شده است. آنها مستقل‌ هستند و می‌توانند با ترتیبی متفاوت -برسند، اما هر جریان دقیقاً به ترتیب تحویل نرم‌افزار داده می‌شود. +در تصویر زیر یک جریان زرد و یک جریان آبی مابین دو پایانهٔ QUIC بر روی یک اتصال +فرستاده شده است. آنها مستقل هستند و می‌توانند با ترتیبی متفاوت برسند، اما +هر جریان دقیقاًً منظم به نرم‌افزار تحویل داده می‌شود. ![two QUIC streams between two computers](../images/quic-chain-streams.png) From 3a1a0aef59715c488cb99355215ed25ab7affd67 Mon Sep 17 00:00:00 2001 From: Faraz Vahedi Date: Mon, 26 Apr 2021 06:41:13 +0000 Subject: [PATCH 08/78] [fa] Update feature-nonhttp.md (#203) --- fa/feature-nonhttp.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fa/feature-nonhttp.md b/fa/feature-nonhttp.md index a6ffd727..f9962aff 100644 --- a/fa/feature-nonhttp.md +++ b/fa/feature-nonhttp.md @@ -1,4 +1,4 @@ ## غیر HTTP بر روی QUIC کار بر روی انتقال پروتکل‌هایی به غیر از HTTP بر روی بستر QUIC تا بعد از -توزیع اولین نسخه‌ی ‌آن به تعویق افتاده است. +توزیع اولین نسخهٔ QUIC به تعویق افتاده است. From 84c571b9fbbbc8b4867fd707538c1ebc377e5a27 Mon Sep 17 00:00:00 2001 From: Faraz Vahedi Date: Mon, 26 Apr 2021 06:53:50 +0000 Subject: [PATCH 09/78] [fa] Update feature-reliable.md (#204) --- fa/feature-reliable.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fa/feature-reliable.md b/fa/feature-reliable.md index 19fff814..15cac761 100644 --- a/fa/feature-reliable.md +++ b/fa/feature-reliable.md @@ -4,5 +4,5 @@ می‌دهد که موجب قابلیت اطمینان می‌شود. انتقال مجدد بسته‌ها، نظارت تراکم، pacing و امکانات دیگری که در TCP موجود است بدین جهت ارائه می‌شود. -داده‌ا‌ی که از طریق QUIC از یک پایانه ارسال شده است دیر یا زود در -پایانه دیگر ظاهر خواهد شد، تا زمانی که اتصال برقرار بماند. +داده‌ای که از طریق QUIC از یک پایانه ارسال شده است، مادامی که اتصال برقرار +باشد، دیر یا زود در پایانهٔ دیگر ظاهر خواهد شد. From 12ccfda4268943dc476159f6f75123642975d464 Mon Sep 17 00:00:00 2001 From: Faraz Vahedi Date: Mon, 26 Apr 2021 07:10:58 +0000 Subject: [PATCH 10/78] [fa] Update feature-streams.md (#205) --- fa/feature-streams.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/fa/feature-streams.md b/fa/feature-streams.md index be1fd76d..9a2ca09f 100644 --- a/fa/feature-streams.md +++ b/fa/feature-streams.md @@ -1,20 +1,20 @@ ## جریان‌های متعدد درون اتصالات -همانند SCTP، SSH و HTTP/2، پروتکل QUIC شامل جریان‌های منطقی‌ +همانند SCTP، SSH و HTTP/2، پروتکل QUIC شامل جریان‌های منطقی جداگانه‌ای درون اتصال‌های فیزیکی است. تعدادی از جریان‌های موازی که می‌توانند بدون آنکه جریان‌های دیگر را تحت تاثیر قرار دهند بطور -همزمان انتقال داده بر روی یک اتصال واحد را انجام دهند. +همزمان انتقالِ داده بر روی یک اتصال واحد را انجام دهند. یک اتصال یک چیدمانِ مذاکره شده بین دو پایانه است همانند حالتی که یک اتصال TCP کار -می‌کند. یک اتصال QUIC به یک پورت UDP و آدرس IP انجام می‌گیرد، اما پس -از برقراری ارتباط آن اتصال توسط "شناسه‌ی اتصال" شناخته می‌شود. +می‌کند. یک اتصال QUIC، به یک پورت UDP و آدرس IP انجام می‌گیرد، اما پس +از برقراری ارتباط آن اتصال توسط "شناسهٔ اتصال" شناخته می‌شود. بر روی یک اتصال برقرار شده، هردو طرف می‌توانند جریانی بسازند و داده را به -پایانه دیگر انتقال دهند. جریان‌ها به شکلی مرتب دریافت می‌شوند و قابل +پایانهٔ دیگر انتقال دهند. جریان‌ها به شکلی مرتب دریافت می‌شوند و قابل اطمینان هستند، اما جریان‌های مختلف می‌توانند نامنظم دریافت شوند. پروتکل QUIC کنترل جریان بر روی هر دوی اتصال و جریان‌ها را ارائه می‌دهد. -جزئیات بیشتر را در بخش‌های [اتصال‌ها](quic-connections.md) و +جزئیات بیشتر را در بخش‌های [اتصالات](quic-connections.md) و [جریان‌ها](quic-streams.md) ببینید. From 7af11cb96e09ab2bd645c5466377781e0e8b5ce6 Mon Sep 17 00:00:00 2001 From: Faraz Vahedi Date: Tue, 27 Apr 2021 06:58:06 +0000 Subject: [PATCH 11/78] [fa] Update feature-tls.md (#206) --- fa/feature-tls.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/fa/feature-tls.md b/fa/feature-tls.md index 83aaedd0..78587f8d 100644 --- a/fa/feature-tls.md +++ b/fa/feature-tls.md @@ -1,12 +1,12 @@ ## پروتکل TLS 1.3 -امنیت انتقال استفاده شده در QUIC از TLS 1.3 استفاده می‌کند ([RFC +امنیت انتقالِ استفاده شده در QUIC از TLS 1.3 استفاده می‌کند ([RFC 8446](https://tools.ietf.org/html/rfc8446)) و هرگز هیچ اتصال رمزگذاری نشده‌ای در QUIC وجود ندارد. -پروتکل TLS 1.3 نسبت به نسخه‌های پیشین TLS برتری‌هایی دارد که البته -دلیل اصلی استفاده از آن در QUIC اینست که نسخه‌ی ۱.۳ دست‌دهی را به نحوی -تغییر داده است تا شامل roundtrip های کمتری باشد. این امر تاخیر در پروتکل را کاهش +پروتکل TLS 1.3 نسبت به نسخه‌های پیشین TLS برتری‌هایی دارد که البته یک +دلیل اصلی استفاده از آن در QUIC این است که نسخهٔ 1.3 دست‌دهی را به نحوی +تغییر داده است تا شامل roundtrip های کمتری باشد. این امر تأخیر در پروتکل را کاهش می‌دهد. -نسخه‌ی پیشین QUIC گوگل از یک رمزنگاری سفارشی استفاده می‌کرد. +نسخهٔ پیشین QUIC گوگل از یک رمزنگاری سفارشی استفاده می‌کرد. From e3b434ebcd73c8c2b10317011c55b2243a15aa79 Mon Sep 17 00:00:00 2001 From: Faraz Vahedi Date: Tue, 27 Apr 2021 07:13:25 +0000 Subject: [PATCH 12/78] [fa] Update feature-trans-app.md (#207) --- fa/feature-trans-app.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/fa/feature-trans-app.md b/fa/feature-trans-app.md index 07c33fdc..d6033d17 100644 --- a/fa/feature-trans-app.md +++ b/fa/feature-trans-app.md @@ -1,11 +1,11 @@ ## سطح انتقال و کاربرد پروتکل IETF QUIC یک پروتکل انتقال است، که در بالای آن پروتکل‌‌های -کاربرد دیگر می‌توانند استفاده شوند. پروتکل اولیه لایه‌ی کاربرد HTTP/3 - -یا (h3) - است. +کاربردی دیگر می‌توانند استفاده شوند. پروتکل اصلی لایهٔ کاربرد HTTP/3 +(یا h3) است. -لایه‌ انتقال از اتصال‌ها و جریان‌ها پشتیبانی می‌کند. +لایهٔ انتقال از اتصال‌ها و جریان‌ها پشتیبانی می‌کند. -نسخه‌ی پیشین QUIC گوگل، انتقال و HTTP را همراه با یکدیگر به شکلی -همه‌کاره دارا بود و بیشتر یک پروتکل ارسالِ قاب‌های (frame) پروتکل -HTTP/2 بر روی UDP با هدف خاص بود. +نسخهٔ پیشین QUIC گوگل، انتقال و HTTP را همراه با یکدیگر به شکلی همه‌کاره +دارا بود و بیشتر یک پروتکل ارسال برای قاب‌های (frame) پروتکل HTTP/2 بر +روی بستر UDP با هدف خاص بود. From 1b40c80401e6710b99775c84274f0c10f4c26adb Mon Sep 17 00:00:00 2001 From: Faraz Vahedi Date: Wed, 28 Apr 2021 12:35:27 +0000 Subject: [PATCH 13/78] [fa] Update feature-udp.md (#208) --- fa/feature-udp.md | 40 ++++++++++++++++++++-------------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/fa/feature-udp.md b/fa/feature-udp.md index fe0e02c1..5622ed0c 100644 --- a/fa/feature-udp.md +++ b/fa/feature-udp.md @@ -1,34 +1,34 @@ ## پروتکل انتقال روی UDP -پروتکل QUIC یک پروتکل انتقال پیاده‌سازی شده بر روی UDP است. اگر گاهی ترافیک -شبکه‌ی خود‌ را زیر نظر بگیرید، می‌بیند که QUIC به شکل -بسته‌های UDP نمایان می‌شود. +پروتکل QUIC یک پروتکل انتقالِ پیاده‌سازی شده بر روی UDP است. اگر گاهی ترافیک +شبکهٔ خود را زیر نظر بگیرید، می‌بیند که QUIC به شکل بسته‌های UDP نمایان +می‌شود. -بر اساس UDP، این پروتکل نیز از شماره پورت‌های UDP برای شناسایی -سرویس‌های مشخصِ شبکه روی یک آدرس IP خاص استفاده می‌کند. +بر اساس UDP، این پروتکل نیز از شماره درگاه‌های UDP برای شناسایی +خدمات خاص شبکه در یک نشانی IP داده شده استفاده می کند. -تمام پیاده‌سازی‌های شناخته شده‌ی QUIC در حال حاضر در فضای کاربری +تمام پیاده‌سازی‌های شناخته شدهٔ QUIC در حال حاضر در فضای کاربری هستند چرا که این امر منجر به بالا رفتن سرعت توسعه نسبت به آن چیزی خواهد بود که -فضای هسته برای پیاده‌سازی‌ اجازه خواهد داد. +فضای هسته برای پیاده‌سازی‌ اجازه می‌دهد. ## آیا کارساز خواهد بود؟ -شرکت‌ها و دیگر نهادهای شبکه‌ای وجود دارند که ترافیک UDP روی -پورت‌های غیر از ۵۳ (که برای DNS استفاده می‌شود) را مسدود می‌کنند. +شرکت‌ها و نهادهای شبکه‌ای دیگری وجود دارند که ترافیک UDP روی +درگاه‌های غیر از ۵۳ (که برای DNS استفاده می‌شود) را مسدود +می‌کنند. دیگری‌ها نیز داده‌ها را به گونه‌ای محدود می‌کنند که باعث -می‌شود QUIC از پروتکل‌های مبتنی بر TCP هم بدتر عمل کند. پایانی برای -کارهای برخی از اپراتورها نیست. +می‌شود QUIC از پروتکل‌های مبتنی بر TCP هم بدتر عمل کند. برای کارهای +احتمالی برخی از اپراتورها پایانی نیست. -تا آن‌جایی که می‌توان آینده را پیش‌بینی کرد، شاید تمام -استفاده‌های انتقال‌های مبتنی بر QUIC باید بتوانند به طور خوشایند به +تا آن‌جایی که می‌توان آینده را پیش‌بینی کرد، احتمالاً تمامی +استفاده از انتقال‌های مبتنی بر QUIC باید بتوانند به‌طور خوشایندی به دیگر جایگزین‌ها (مبتنی بر TCP) بازگردند. مهندس‌های گوگل پیشتر نرخِ شکست -در درصدهای تک‌رقمیِ پایین را پیش‌بینی کرده‌اند. +را در درصدهای تک‌رقمیِ پایین پیش‌بینی کرده‌اند. ## آیا پیشرفت خواهد کرد؟ - اگر ثابت شود QUIC چیزی با ارزش به دنیای اینترنت اضافه می‌کند، آن‌وقت - احتمال دارد افراد بخواهند از آن استفاده کنند و در نتیجه بخواهند تا آن در - شبکه‌هایشان کار کند و بدین ترتیب ممکن است شرکت‌ها شروع به بازنگری و - بررسی موانع موجودِ خود کنند. در طول سال‌هایی که توسعه‌ی QUIC پیشرفت - کرده، نرخ موفقیت برای ایجاد و استفاده‌ی اتصال‌های QUIC در اینترنت - افزایش یافته است. +اگر ثابت شود QUIC چیزی با ارزش به دنیای اینترنت اضافه می‌کند، آن‌وقت +احتمال دارد افراد بخواهند از آن استفاده کنند و در نتیجه بخواهند که آن در +شبکه‌هایشان کار کند و بدین ترتیب ممکن است شرکت‌ها شروع به بازنگری و +بررسی موانع موجودِ خود کنند. طی سال‌های پیشرفت در توسعهٔ QUIC، نرخ موفقیت +برای ایجاد و استفاده از اتصالات QUIC در اینترنت افزایش یافته است. From 5b84ceae9ae51ccc3ac65d9ecd412c1a5e699142 Mon Sep 17 00:00:00 2001 From: Faraz Vahedi Date: Thu, 29 Apr 2021 12:50:22 +0000 Subject: [PATCH 14/78] [fa] Update h3-altsvc.md (#209) --- fa/h3-altsvc.md | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/fa/h3-altsvc.md b/fa/h3-altsvc.md index 1e0d06cb..da05770c 100644 --- a/fa/h3-altsvc.md +++ b/fa/h3-altsvc.md @@ -1,34 +1,34 @@ # سرایندِ Alt-svc -سرایندِ خدمات جایگزین (:Alt-svc) و چهارچوبِ متناظر `ALT-SVC` آن در HTTP/2 منحصراً -برای QUIC یا HTTP/3 ساخته نشده‌اند. آنها بخشی از مکانیزمی از پیش طراحی و -ساخته شده‌ برای سروری هستند که به کارخواه بگوید: *"نگاه کن، من دارم همین +سرایندِ خدمات جایگزین (:Alt-svc) و قابِ متناظر `ALT-SVC` آن در HTTP/2 منحصراً +برای QUIC یا HTTP/3 ساخته نشده‌اند. آنها بخشی از یک مکانیزم از پیش طراحی و +ساخته شده هستند تا که یک سرور بتواند به کارخواه بگوید: *"نگاه کن، من دارم همین سرویس مشابه را روی این میزبان با استفاده از این پروتکل بر روی این درگاه اجرا می‌کنم"*. جزئیات را در [RFC 7838](https://tools.ietf.org/html/rfc7838) ببینید. -کارخواهی که چنین پاسخ Alt-svc را دریافت می‌کند بهش پیشنهاد می‌شود که، -اگر پشتیبانی می‌کند و می‌خواهد، به آن میزبانِ دیگر بطور موازی در پس -زمینه متصل گردد - با استفاده از پروتکل مشخص شده - و چنانکه موفقیت‌آمیز باشد -عملیاتش را به جای اتصال اولیه بر روی آن تغییر دهد. +به کارخواهی که چنین پاسخ Alt-svc را دریافت می‌کند پیشنهاد می‌شود که +با استفاده از پروتکل مشخص‌شده، در صورت پشتیبانی و تمایل، به آن میزبان معلوم +به‌طور موازی در پس‌زمینه متصل شود و چنانکه این امر موفقیت‌آمیز +باشد عملیاتش را به‌طور کامل از روی اتصال اولیه به آن تغییر دهد. اگر اتصال اولیه از HTTP/2 یا حتی HTTP/1 استفاده کند، سرور می‌تواند پاسخ بدهد و به کارخواه بگوید که می‌تواند دوباره متصل شود و HTTP/3 را امتحان کند. این می‌تواند به سمت همان میزبان یا دیگر میزبانی که می‌داند چگونه به آن -خاستگاه خدمت کند باشد. اطلاعاتی که در چنین پاسخ Alt-svc داده شده است دارای زمان -سنجِ انقضا هستند که باعث می‌شود کارخواه‌ها بتوانند اتصال‌های سپسین -و درخواست‌ها را با استفاده از پروتکل‌ جایگزینِ پیشنهادی یکراست به سمت -میزبان برای زمانی مشخص‌ هدایت کنند. +خاستگاه خدمت کند باشد. اطلاعاتی که در چنین پاسخ Alt-svc داده شده است دارای +زمان‌سنجِ انقضا هستند که باعث می‌شود کارخواه‌ها بتوانند +اتصال‌ها و درخواست‌های سپسین را با استفاده از پروتکل جایگزینِ پیشنهادی +مستقیماً به سمت آن میزبان جایگزین، برای زمانی مشخص، هدایت کنند. ## نمونه -یک سرور HTTP شامل یک سرایند `Alt-Svc:` در پاسخش است: +یک سرور HTTP در پاسخش شامل یک سرایند `Alt-Svc:` است: Alt-Svc: h3=":50781" -این نشانگر این است که HTTP/3 بر روی درگاه UDP شماره ۵۰۷۸۱ با همان نام میزبانی که +این نشانگر این است که HTTP/3 بر روی درگاه UDP شماره ٔ۵۰۷۸۱ در همان میزبانی که برای دریافت این پاسخ استفاده شده در دسترس است. -یک کارخواه بعد از آن می‌تواند اقدام به برقراری یک اتصال QUIC به سمت آن مقصد -کند و اگر موفقیت آمیز بود، به جای نسخه اولیه HTTP همانطور به ارتباط برقرار کردن -با خاستگاه ادامه دهد. +یک کارخواه سپس می‌تواند اقدام به برقراری یک اتصال QUIC به‌سمت آن مقصد +کند و اگر موفقیت آمیز بود، به‌جای ادامهٔ ارتباط اولیهٔ نسخهٔ HTTP، بدان شکل +با خاستگاه به ارتباط خود ادامه دهد. From 7eeed20238b04038b42942b94845986be3d40334 Mon Sep 17 00:00:00 2001 From: Faraz Vahedi Date: Fri, 30 Apr 2021 17:04:37 +0000 Subject: [PATCH 15/78] [fa] Update quic.md (#210) --- fa/quic.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/fa/quic.md b/fa/quic.md index 967e3e7c..aa6c13dc 100644 --- a/fa/quic.md +++ b/fa/quic.md @@ -1,13 +1,13 @@ # پروتکل QUIC چطور کار می‌کند -بدون توضیح دقیق ریز و درشت‌ها (بیت‌ و بایت‌ها) این بخش نحوه -کارکردِ قطعاتِ اساسیِ سازنده‌یِ پروتکلِ انتقالِ QUIC را شرح می‌دهد. اگر شما -قصد دارید تا پشته‌ی QUIC خودتان را پیاده‌سازی کنید، این تشریح‌ -بایست یک فهم و دید کلی به شما بدهد، اما برای تمامی جزئیات، به پیش -‌نویس‌ها و RFC های کارگروه مهندسی اینترنت (IETF) رجوع نمایید. +این بخش، بدون توضیح دقیق بیت‌ها و بایت‌ها، نحوهٔ کارکرد عناصر اصلی ساخت +پروتکل انتقال QUIC را شرح می‌دهد. اگر قصد دارید تا پشتهٔ QUIC خودتان را +پیاده‌سازی کنید، این توضیحات باید یک درک کلی به شما بدهد، اما برای تمامی +جزئیات، به پیش‌نویس‌ها و RFC های کارگروه مهندسی اینترنت (IETF) مراجعه +کنید. -۱. یک [اتصال](quic-connections.md) برقرار نمایید +۱. یک [اتصال](quic-connections.md) برقرار کنید ۲. ... که شامل [امنیت TLS](quic-tls.md) باشد -۳. سپس از [جریان‌ها](quic-streams.md) استفاده نمایید +۳. سپس از [جریان‌ها](quic-streams.md) استفاده کنید From 958ddd6b91d51d88a102b71474eee57f331139e0 Mon Sep 17 00:00:00 2001 From: Faraz Vahedi Date: Sun, 2 May 2021 11:28:09 +0000 Subject: [PATCH 16/78] [fa] Update why-secure.md (#211) --- fa/why-secure.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/fa/why-secure.md b/fa/why-secure.md index 0e5363f4..371e26de 100644 --- a/fa/why-secure.md +++ b/fa/why-secure.md @@ -1,11 +1,11 @@ ## امن -پروتکل QUIC همیشه امن است. هیچ نسخه‌ی متن‌آشکاری از این پروتکل وجود -ندارد پس برای مذاکره‌ی یک اتصال QUIC باید رمزنگاری و امنیت همراه با TLS 1.3 -صورت بگیرد. همانطور که در بالاتر آمد، این مانع از استخوان سازی (به معنای از بین -رفتن انعطاف پذیری و امکان توسعه) و همچنین دیگر موانع و رفتار‌های خاص -می‌شود - و همچنین اطمینان حاصل می‌کند تا QUIC تمام عوامل ایمنی HTTPS -که کاربران وب انتظارش را دارند داشته باشد. +پروتکل QUIC همیشه امن است. هیچ نسخهٔ متن‌آشکاری از این پروتکل وجود ندارد، +پس برای مذاکرهٔ یک اتصال QUIC باید رمزنگاری و امنیت همراه با TLS 1.3 صورت بگیرد. +همانطور که در بالاتر آمد، این امر مانع از استخوان‌سازی (به معنای از بین رفتن +انعطاف پذیری و امکان توسعه) و همینطور دیگر موانع و رفتار‌های خاص +می‌شود و همچنین اطمینان حاصل می‌کند تا QUIC تمام عوامل ایمنی HTTPS که +کاربران وب انتظارش را دارند دارا باشد. -تنها تعداد کمی بسته دست‌دهی اولیه وجود دارند که به صورت آشکارا پیش از آغاز -مذاکره پروتکل‌های رمزنگاری ارسال می‌شوند. +تنها تعداد کمی بستهٔ دست‌دهی اولیه وجود دارد که به صورت آشکارا پیش از آغاز +مذاکرهٔ پروتکل‌های رمزنگاری ارسال می‌شوند. From fc1329e215eae8bf0f2b4cfb50d59c8d4aa952e4 Mon Sep 17 00:00:00 2001 From: Faraz Vahedi Date: Mon, 10 May 2021 07:21:43 +0000 Subject: [PATCH 17/78] [fa] Update quic-0rtt.md (#212) --- fa/quic-0rtt.md | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/fa/quic-0rtt.md b/fa/quic-0rtt.md index a4b39476..41d93b9f 100644 --- a/fa/quic-0rtt.md +++ b/fa/quic-0rtt.md @@ -2,8 +2,5 @@ برای کاهش زمان مورد نیاز جهت برقراری یک اتصال جدید، کارخواهی که قبل‌تر به یک کارگزار متصل شده است ممکن است برخی پارامتر‌ها را از آن اتصال ذخیره کند و -سپس یک اتصال برای کاهش زمان مورد نیاز جهت برقراری یک اتصال جدید، کارخواهی که -قبل‌تر به یک کارگزار متصل شده است ممکن است برخی پارامتر‌ها را از آن -اتصال ذخیره کند و سپس یک اتصال **0-RTT** با کارگزار برقرار کند. این به کارخواه -اجازه می‌دهد تا داده را بدون آنکه برای تکمیل یک دست‌دهی منتظر بماند -بلافاصله ارسال کند. +سپس یک اتصال **0-RTT** با کارگزار برقرار کند. این به کارخواه اجازه می‌دهد +تا داده را بدون آنکه برای تکمیل یک دست‌دهی منتظر بماند بلافاصله ارسال کند. From 8786c1bb17ea8854636dbbd1bae013e0efd069fa Mon Sep 17 00:00:00 2001 From: Faraz Vahedi Date: Mon, 10 May 2021 09:58:27 +0000 Subject: [PATCH 18/78] [fa] Update specs.md (#213) --- fa/specs.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/fa/specs.md b/fa/specs.md index 497be0ea..7540afad 100644 --- a/fa/specs.md +++ b/fa/specs.md @@ -1,16 +1,16 @@ # مشخصات -در اینجا مجموعی از آخرین پیش‌نویس‌های رسمی برای بخش‌های مختلف -QUIC و HTTP/3 آورده شده است. +در اینجا مجموعه‌ای از آخرین پیش‌نویس‌های رسمی برای بخش‌های +مختلف QUIC و HTTP/3 آورده شده است. ## نامتغیر‌ها -[دارایی‌های غیروابسته به نسخه و مستقل پروتکل +[دارایی‌های مستقل و غیروابسته به نسخهٔ پروتکل QUIC](https://tools.ietf.org/html/draft-ietf-quic-invariants) ## انتقال -[پروتکل QUIC: یک انتقال امن و چندگانه‌ی UDP +[پروتکل QUIC: یک انتقال امن و چندگانهٔ UDP محور](https://tools.ietf.org/html/draft-ietf-quic-transport) ## بازیابی @@ -18,14 +18,14 @@ QUIC](https://tools.ietf.org/html/draft-ietf-quic-invariants) [تشخیص اتلاف و کنترل تراکم پروتکل QUIC](https://tools.ietf.org/html/draft-ietf-quic-recovery) -## امنیت لایه انتقال +## امنیت لایهٔ انتقال [استفاده از TLS برای امن‌سازی پروتکل QUIC](https://tools.ietf.org/html/draft-ietf-quic-tls) ## پروتکل انتقال ابرمتن -[پروتکل انتقال ابرمتن نسخه ۳ +[پروتکل انتقال ابرمتن نسخهٔ ۳ (HTTP/3)](https://tools.ietf.org/html/draft-ietf-quic-http) ## روش فشرده‌سازی سرایند QPACK From cfe51665a6dfb595a7756f608c6e2d6ba60c32d9 Mon Sep 17 00:00:00 2001 From: Faraz Vahedi Date: Thu, 13 May 2021 12:29:47 +0000 Subject: [PATCH 19/78] [fa] Update the-protocol.md (#214) --- fa/the-protocol.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fa/the-protocol.md b/fa/the-protocol.md index f7f2661a..0059fd5d 100644 --- a/fa/the-protocol.md +++ b/fa/the-protocol.md @@ -2,7 +2,7 @@ پروتکل QUIC از سطحی بالا. -تصویر پایین پشته شبکه‌ی HTTP/2 در سمت چپ و پشته شبکه‌ی QUIC در سمت -راست را نمایش می‌دهد، زمانی که به عنوان انتقالِ HTTP استفاده شود. +تصویر پایین پشتهٔ شبکهٔ HTTP/2 را در سمت چپ و پشتهٔ شبکهٔ QUIC را در سمت راست، +زمانی که به‌عنوان انتقالِ HTTP استفاده شوند، نمایش می‌دهد. ![QUIC logo](../images/quic-stack.png) From 9accecb5d9c9268aee402c9efe5a487b5a85290a Mon Sep 17 00:00:00 2001 From: Faraz Vahedi Date: Fri, 14 May 2021 22:07:19 +0000 Subject: [PATCH 20/78] [fa] Update h3-prio.md (#215) --- fa/h3-prio.md | 28 ++++++++++++++++++---------- 1 file changed, 18 insertions(+), 10 deletions(-) diff --git a/fa/h3-prio.md b/fa/h3-prio.md index f20d5c31..7341026e 100644 --- a/fa/h3-prio.md +++ b/fa/h3-prio.md @@ -1,14 +1,22 @@ -# اولویت بندی پروتکل HTTP/3 +# اولویت‌بندی پروتکل HTTP/3 -یکی از قاب‌های جریان در 3/HTTP قاب PRIORITY است. این قاب برای وضع اولویت و -وابستگی بر روی یک جریان، مشابه روشی که در 2/HTTP صورت می‌گیرد، استفاده شده -است. +همانطور که پیشتر اشاره شد، اولویت‌بندی بین جریان‌ها از مشخصات اصلی +HTTP/3 حذف شده است تا که به‌طور جداگانه روی آن کار شود. -این قاب می‌تواند جریانی مشخص را مقرر کند که وابسته به جریان مشخص دیگری باشد -و میتواند بر روی یک جریان معین شده یک ”وزن“ اختصاص دهد. +این به‌دلیل آموخته‌ها از مدل اولویت‌بندی HTTP/2 و پیاده‌سازی +آن (یا عدم وجود آن) در دنیای واقعی بود. -این قاب می‌تواند جریانی مشخص را مقرر کند که وابسته به جریان مشخص دیگری باشد -و میتواند بر روی یک جریان معین شده یک ”وزن“ اختصاص دهد. +یک [مدل اولویت‌بندی ساده‌تر از +HTTP/2](https://tools.ietf.org/html/draft-ietf-httpbis-priority) با استفاده از +بخش‌های سرامد HTTP به‌همراه تعداد محدودی تنظیمات اولویت‌بندی، +پیشنهاد شده است. این یک تغییر اساسی نسبت به پرچم‌های وابستگی و وزن در +قاب‌های سرامد HTTP/2 است و به شما امکان درک بهتر لایهٔ کاربرد را می‌دهد. -مقدار وزنِ یک جریان بین ۱ تا ۲۵۶ هست و این مقرر شده است که جریان‌هایی که از -یک والد هستند باید منابع متناسب با وزنشان به آنها تخصیص گردد. +امکان اولویت‌بندی دوباره و پشتیبانی از آن هنوز مورد بحث و گفتگو است. HTTP/2 +برای مدیریت این موضوع قاب‌های اولویت‌بندی را داشت، اما جریان‌های +مستقل در QUIC و HTTP/3 این مسئله را به‌مراتب پیچیده‌تر می‌سازد و +ازین‌رو مزایا و پیچیدگی آن هنوز در مرحلهٔ مناظره است. + +زمانی که (یا اگر!) مدل اولویت‌بندی بهتری برای HTTP/3 مورد توافق قرار گرفت، +به امکان پیش‌انتقال آن به HTTP/2 جهت رفع پیچیدگی و نگرانی‌های +پیاده‌سازی آن سمت نیز امید است. From f4a7e55e1b1cf07ca2abcd2f41141739cde01f53 Mon Sep 17 00:00:00 2001 From: Faraz Vahedi Date: Sun, 4 Jul 2021 19:54:16 +0000 Subject: [PATCH 21/78] [fa] Update why-latency.md (#217) --- fa/why-latency.md | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/fa/why-latency.md b/fa/why-latency.md index 7030cf50..575ddb58 100644 --- a/fa/why-latency.md +++ b/fa/why-latency.md @@ -1,28 +1,28 @@ # داده‌های اولیه -QUIC هم دست‌دهی 0-RTT و هم دست‌دهی 1-RTT را ارائه می‌کند که باعث -کاهش زمان لازم برای مذاکره و برقراری اتصال جدید می‌شود. مقایسه شود با -دست‌دهی سه‌گانه‌ی TCP. +پروتکل QUIC هم دست‌دهی 0-RTT و هم دست‌دهی 1-RTT را ارائه می‌کند +که باعث کاهش زمان لازم برای مذاکره و برقراری اتصال جدید می‌شود. مقایسه شود +با دست‌دهی سه‌گانهٔ TCP. -علاوه بر آن، QUIC از همان ابتدا ”داده‌های اولیه“ را که برای پذیرفتن -داده‌های بیشتر صورت می‌پذیرد و نسبت به TCP Fast Open هم سریعتر بکار -گرفته می‌شود پشتیبانی می‌کرد. +علاوه بر آن، QUIC از همان ابتدا پشتیبانی «داده‌های اولیه» را که برای +پذیرفتن داده‌های بیشتر است ارائه می‌دهد و ساده‌تر از +TCP Fast Open استفاده می‌شود. -با مفهموم جریان، یک اتصال به میزبان بدون آنکه ابتدا نیازی به انتظار کشیدن برای -پایانِ اتصالِ موجود داشته باشد بی‌درنگ می‌تواند صورت پذیرد. +با استفاده از مفهموم جریان، یک اتصال به میزبان می‌تواند یک‌باره و بدون +آنکه ابتدا نیازی به انتظار کشیدن برای پایانِ اتصالِ موجود داشته باشد صورت پذیرد. ## قابلیت TCP Fast Open مشکل ساز است قابلیت TCP Fast Open برای اولین بار در تاریخ دسامبر ۲۰۱۴ به عنوان [RFC -7413](https://tools.ietf.org/html/rfc7413) منتشر شد. این مشخصات واصفِ چگونگی -انتقال داده‌ها توسط نرم‌افزار به سمت کارساز، به نحوی که در همان اولین -بسته‌ی TCP SYN دریافت شوند، است. +7413](https://tools.ietf.org/html/rfc7413) منتشر شد. این مشخصات بیان می‌کند +که برنامه‌های کاربردی چگونه می‌توانند داده را به سمت کارساز، +به‌طوری که در همان اولین بستهٔ TCP SYN دریافت شوند، ارسال کنند. -پشتیبانی فعلی برای این ویژگی زمان بسیار برده است و حتی امروزه در ۲۰۱۸ نیز پر از -مشکلات و مسائل است. پیاده‌‌سازانِ پشته‌ی TCP و همچنین -برنامه‌هایی که سعی در بهره‌وری از این ویژگی دارند مشکلاتی -داشته‌اند - هردو در فهمیدن آنکه در کدام نسخه از سیستم عامل سعی بر فعالسازی -آن داشته باشند و همچنین در فهم آنکه چگونه با ملایمت و موقرانه کنار بکشند و هنگام -بروز مشکلات با آن مقابله کنند. چندین شبکه به مداخله در ترافیک TFO شناخته -شده‌اند و آنها بدین ترتیب چنین دست‌دهی‌های TCP را عمداً تخریب +پشتیبانی فعلی برای این ویژگی زمان بسیار برده است و حتی امروزه در ۲۰۱۸ نیز با +مشکلاتی همراه است. پیاده‌سازانِ پشتهٔ TCP و همچنین برنامه‌هایی که سعی در +بهره‌وری از این ویژگی دارند مشکلاتی به‌همراه داشته‌اند - هردو در +تشخیص آنکه در کدام نسخه از سامانه‌عامل سعی بر فعالسازی آن داشته باشند، +و همچنین در فهم آنکه چگونگه به‌هنگام بروز مشکلات با ملایمت از این روش کنار +بکشند و با آن مقابله کنند. شبکه‌های متعددی به مداخله در ترافیک TFO شناخته +شده‌اند و آنها بدین ترتیب چنین دست‌دهی‌های TCP را عمداً منهدم کرده‌اند. From 9d744d8d9e05d4cd7239ce4e09ac54fe0e4233e9 Mon Sep 17 00:00:00 2001 From: Faraz Vahedi Date: Mon, 5 Jul 2021 22:49:15 +0000 Subject: [PATCH 22/78] [fa] Update quic-tls.md (#218) --- fa/quic-tls.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/fa/quic-tls.md b/fa/quic-tls.md index 2b0d1a52..4a14e45f 100644 --- a/fa/quic-tls.md +++ b/fa/quic-tls.md @@ -1,9 +1,9 @@ # اتصال‌ها از TLS استفاده می‌کنند -بلافاصله بعد از اولین بسته‌ای که اتصال را برقرار می‌کند، آغازکننده یک -قابِ رمزگذاری شده ارسال می‌کند که شروع به برقراری دست‌دهی لایه‌ی -امن می‌کند. لایه‌ی امنیت از امنیت TLS 1.3 استفاده می‌کند. +بلافاصله بعد از اولین بسته‌ای که اتصال را برقرار می‌کند، آغازگر یک قاب +رمزنگاری ارسال می‌کند که شروع به تنظیم دست‌دهی لایهٔ امن می‌کند. +لایهٔ امنیت از امنیت TLS 1.3 استفاده می‌کند. -هیچ راه خروج یا جلوگیری از استفاده‌ی TLS برای یک اتصال QUIC وجود ندارد. این -پروتکل به نحوی طراحی شده است تا مداخله‌ و نفوذ برای دستگاه‌های میانی -دشوار باشد، تا به جلوگیری از تغییرات و استخوان سازی زودرس پروتکل کمک کند. +هیچ راهی برای انصراف یا جلوگیری از استفادهٔ TLS برای یک اتصال QUIC وجود ندارد. +این پروتکل، جهت جلوگیری از استخوان‌سازی، به نحوی طراحی شده است تا دستکاری +در آن برای دستگاه‌های میانی دشوار باشد. From 4b82e3ba47dfcce67bd17ae39fbf7094f4d91c27 Mon Sep 17 00:00:00 2001 From: Faraz Vahedi Date: Tue, 6 Jul 2021 22:52:33 +0000 Subject: [PATCH 23/78] [fa] Update h3-https.md (#219) --- fa/h3-https.md | 44 ++++++++++++++++++++++---------------------- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/fa/h3-https.md b/fa/h3-https.md index 729d647c..e955ac5f 100644 --- a/fa/h3-https.md +++ b/fa/h3-https.md @@ -1,31 +1,31 @@ # نشانی وب‌های HTTPS:// -پروتکل HTTP/3 با استفاده از (URL) نشانی وب‌های HTTPS:// اجرا می‌شود. -جهان پر است از این نشانی وب‌ها و معرفی کردنِ طرحی جدید برای آن در پروتکل -جدید غیر عملی و به طور کامل غیر منطقی تلقی شده است. همانطور که HTTP/2 نیاز به -طرحی جدید نداشت، HTTP/3 نیز نیازی نخواهد داشت. +پروتکل HTTP/3 با استفاده از URL های HTTPS:// اجرا می‌شود. جهان پر است از +این نشانی وب‌ها، و معرفی کردنِ طرح URL جدیدی برای پروتکل جدید، غیر عملی و +کاملاً غیر منطقی شمرده می‌شود. همانطور که HTTP/2 نیاز به طرحی جدید نداشت، +HTTP/3 نیز نیازی نخواهد داشت. -پیچیدگی اضافه شده در HTTP/3 مانند همان زمانی است که HTTP/2 گرچه روشی کاملاً‌ -جدید برای انتقال HTTP بود، هنوز هم همچون HTTP/1 مبتنی بر TLS و TCP بود. این -حقیقت که HTTP/3 بر بستر QUIC انجام گرفته است یک سری چیزها را در زوایای مهمی +پیچیدگی اضافه شده در وضعیت HTTP/3 این است که بر خلاف آن زمان که HTTP/2 روشی +جدید برای انتقال HTTP بود و هنوز همانند HTTP/1 بر اساس TLS و TCP، پروتکل +HTTP/3 بر روی بستر QUIC بنا شده است، و این موضوع از چند جنبهٔ مهم امور را تغییر می‌دهد. -چیزهایی مانند legacy و clear-text و نشانی وب‌های HTTP:// همانگونه که هستند -باقی می‌مانند و آنگاه که ما بیشتر به سوی آینده‌ای با انتقال‌های -امن‌تر می‌رویم آنها احتمالاً کمتر و کمتر مورد استفاده قرار -می‌گیرند. درخواست‌ها به چنین نشانی وب‌هایی برای استفاده از HTTP/3 -بروزرسانی نخواهند شد. در حقیقت آنها به HTTP/2 هم به ندرت بروزرسانی می‌شوند، -اما به دلایلی دیگر. +نشانی وب‌های قدیمی، متن‌آشکار، و `HTTP://` همانگونه که هستند باقی +می‌مانند، و همینطور که با انتقال‌های امن‌تر به‌سمت آینده +پیش می‌رویم، احتمالاً آنها کمتر و کمتر مورد استفاده قرار می‌گیرند. +درخواست چنین URL هایی برای استفاده از HTTP/3 ارتقا نخواهند یافت. در حقیقت، +آنها برای HTTP/2 هم به‌ندرت ارتقا پیدا می‌کنند، اما از برای دلایلی +دیگر. ## اتصال اولیه -اولین اتصال به یک میزبان جدید و از قبل دیده نشده برای یک نشانی وبِ HTTPS:// -احتمالاً ناچار است بر روی TCP صورت بگیرد (احتمالاً علاوه بر اقدامی موازی برای اتصال -توسط QUIC). میزبان ممکن است یک کارگزار موروثی (قدیمی) و فاقد پشتیبانی QUIC باشد -یا ممکن است دستگاهی میانی باشد که با ایجاد موانعی از یک اتصال موفقیت آمیزِ QUIC -جلوگیری کند. +اولین اتصال به یک میزبان جدید تابه‌حال بازدید نشده برای یک نشانی +`HTTPS://`، احتمالاً باید بر روی TCP صورت بگیرد (احتمالاً علاوه بر تلاش موازی +برای اتصال از طریق QUIC). میزبان ممکن است کارسازی قدیمی و بدون پشتیبانی +QUIC باشد، یا ممکن است در مسیر واسطی قرار گرفته باشد که مانع موفقیت +اتصال QUIC شود. -یک کارخواه و کارگزارِ امروزی احتمالاً در اولین دست‌دهی‌شان بر سرِ HTTP/2 -مذاکره می‌کنند. هنگامی که اتصال برقرار شد و کارگزار به درخواستِ HTTP کارخواه -پاسخ داد، کارگزار می‌تواند در مورد پشتیبانی خود از و ترجیحش برای HTTP/3 به -کارخواه بگوید. +یک کارخواه و کارساز امروزی احتمالاً در اولین مصافحه بر سر HTTP/2 مذاکره +می‌کنند. هنگامی که اتصال برقرار شد و کارساز به درخواست HTTP کارخواه +پاسخ داد، کارساز می‌تواند در مورد پشتیبانی خود از و ترجیحش برای HTTP/3 +به کارخواه بگوید. From 41a121b5db8f9e66a9f2228cbbe054b11353488a Mon Sep 17 00:00:00 2001 From: Faraz Vahedi Date: Tue, 16 Nov 2021 23:19:56 +0000 Subject: [PATCH 24/78] [fa] Update why-quic.md (#222) --- fa/why-quic.md | 22 +++++++++------------- 1 file changed, 9 insertions(+), 13 deletions(-) diff --git a/fa/why-quic.md b/fa/why-quic.md index 0ff33ecb..002e3a63 100644 --- a/fa/why-quic.md +++ b/fa/why-quic.md @@ -1,20 +1,16 @@ # چرا QUIC -کلمه QUIC یک اسم است و مخفف شده عبارت دیگری نیست. این کلمه دقیقا مانند -کلمه‌ی انگلیسی 'quick' تلفظ می‌شود. +واژهٔ QUIC یک اسم است، سرنام نیست. این واژه دقیقاً مانند واژهٔ انگلیسی «quick» +تلفظ می‌شود. -از بسیاری جهات، QUIC همان چیزی است که می‌توان آن را روشِ نوینی برای -پیاده‌سازی یک پروتکل انتقال داده امن و قابل اعتماد دانست، به گونه‌ای -که مناسب پروتکلی مانند HTTP باشد. به علاوه این روش می‌تواند بسیاری از نقاط -ضعف در راه‌اندازی پروتکل HTTP/2 بر روی TCP و TLS را بهبود بخشد. در واقع -QUIC را میتوان گام منطقی بعدی در سیر تکامل نحوه انتقال اطلاعات بر بستر وب دانست. +پروتکل QUIC یک پروتکل انتقالِ دادهٔ امن و قابل اعتماد جدید است که برای پروتکلی +مانند HTTP مناسب بوده و می‌تواند برخی از کاستی‌های استفاده از +HTTP/2 بر روی TCP و TLS را برطرف کند. گام منطقی بعدی در تکامل حمل و نقل وب. -قابل ذکر است که QUIC فقط به انتقال اطلاعات توسط پروتکل HTTP محدود نمی‌شود. -احتمالا تمایل به افزایش سرعت انتقال اطلاعات و تحویل وِب به کاربران نهایی مهمترین -دلیلی بوده که در ابتدا منجر به ایجاد این پروتکلِ انتقالِ جدید شده است. +پروتکل QUIC تنها به انتقال HTTP محدود نمی‌شود. تمایل به سرعت بخشیدن به وب +و تحویل داده‌ها به کاربران احتمالاً بزرگترین انگیزه و دلیلی است که در ابتدا +باعث ایجاد این پروتکل حمل و نقل جدید شد. - -بنابراین چرا یک پروتکل انتقال جدید ایجاد می‌شود و چرا این پروتکل جدید بر -بستر UDP ایجاد می‌شود؟ +پس چرا ایجاد یک پروتکل جدید و چرا بر روی بستر UDP؟ ![QUIC logo](../images/QUIC.png) From 24fcd30f990c54734d6a6e2af1fc2412ff25ec47 Mon Sep 17 00:00:00 2001 From: Faraz Vahedi Date: Thu, 18 Nov 2021 21:59:11 +0000 Subject: [PATCH 25/78] [fa] Update quic-userspace.md (#223) --- fa/quic-userspace.md | 23 ++++++++++------------- 1 file changed, 10 insertions(+), 13 deletions(-) diff --git a/fa/quic-userspace.md b/fa/quic-userspace.md index a46a6090..16bbe651 100644 --- a/fa/quic-userspace.md +++ b/fa/quic-userspace.md @@ -1,21 +1,18 @@ ## فضای کاربر -پیاده‌سازی یک پروتکل انتقال در فضای کاربر کمک به نسخه‌دهی و -توسعه‌ی سریع‌تر پروتکل می‌کند، چرا که نسخه‌دهی و تکامل یافتن -پروتکل بدون ناگزیر ساختن کارخواه و کارگزار به بهنگام در آوردن هسته‌‌ی -سیستم عامل‌هایشان به جهت استفاده و قرار دادن نسخه‌های جدید نسبتاً ساده -خواهد بود. +پیاده‌سازی پروتکل انتقال در فضای کاربری به نسخه‌دهی و توسعهٔ +سریع‌تر پروتکل کمک می‌کند، چرا که توسعهٔ آن بدون ناگزیر ساختن کارخواه +و کارگزار به به‌روز رسانی هستهٔ سیستم‌عامل‌هایشان برای استفادهٔ +نسخه‌های جدید به مراتب ساده‌تر خواهد بود. -هیچ چیز در QUIC مانع از پیاده‌سازی و در اختیار گذاشتن آن توسط هسته‌ی -سیستم عامل در آینده نمی‌شود، در صورتی که کسی فکر کند می‌تواند ایده -خوبی باشد. +هیچ چیز در QUIC مانع پیاده‌سازی و ارائهٔ توسط هستهٔ سیستم‌عامل +نمی‌شود، حتی ممکن است کسی آن را ایدهٔ خوبی بداند. ### پیاده‌سازی‌های فراوان -یک تأثیر آشکار از پیاده‌سازی یک پروتکلِ انتقال در فضای کاربر این است که -می‌توانیم انتظار دیدن پیاده‌سازی‌های مستقل فراوانی را داشته +یک تأثیر آشکار از پیاده‌سازی یک پروتکلِ انتقال در فضای کاربری این است که +می‌توانیم انتظار مشاهدهٔ پیاده‌سازی‌های مستقل فراوانی را داشته باشیم. -نرم‌افزار‌های مختلف احتمالاً شامل (یا لایه‌ بالا) -پیاده‌سازی‌های مختلف HTTP/3 و QUIC برای آینده‌ی قابل -پیش‌بینی خواهند بود. +در آینده نرم‌افزار‌های مختلف احتمالاً شامل (یا سوار) +پیاده‌سازی‌های مختلف HTTP/3 و QUIC باشند. From 9efb9f35a3ab1f5d3b9a8c4e3998f96275b0d04d Mon Sep 17 00:00:00 2001 From: Emanuele Torre Date: Tue, 21 Jun 2022 00:40:11 +0200 Subject: [PATCH 26/78] it: fix some accents MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * replace incorrect grave accents with acute accents. * replace "E'" with "È". * replace "alchè" (???) with "e dopo" ("and then"). --- SUMMARY.md | 2 +- it/README.md | 2 +- it/h3-h2.md | 2 +- it/h3-prio.md | 2 +- it/h3-push.md | 4 ++-- it/h3-streams.md | 2 +- it/h3.md | 2 +- it/quic-spinbit.md | 2 +- it/quic-v2.md | 2 +- it/why-quic.md | 4 ++-- it/why-tcphol.md | 2 +- it/why-tcpudp.md | 4 ++-- 12 files changed, 15 insertions(+), 15 deletions(-) diff --git a/SUMMARY.md b/SUMMARY.md index 624a00a9..94532cf3 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -155,7 +155,7 @@ * [Italiano](it/README.md) - * [Perchè QUIC](it/why-quic.md) + * [Perché QUIC](it/why-quic.md) * [Ricordi HTTP/2 ?](it/why-h2.md) * [Blocco ad inizio linea, "TCP head of line blocking"](it/why-tcphol.md) * [TCP o UDP](it/why-tcpudp.md) diff --git a/it/README.md b/it/README.md index cc900949..dd8877a5 100644 --- a/it/README.md +++ b/it/README.md @@ -1,7 +1,7 @@ # HTTP/3 spiegato Lo slancio per scrivere questo libro è partito in Marzo 2018. Il piano consiste -nel documentare HTTP/3 e il protocollo sottostante, ossia QUIC. Perchè sono +nel documentare HTTP/3 e il protocollo sottostante, ossia QUIC. Perché sono stati concepiti, come funzionano, dettagli sul protocollo, implementazioni, etc. Questo libro è inteso per essere libero, gratuito; consta dello sforzo condiviso diff --git a/it/h3-h2.md b/it/h3-h2.md index 8b3b03cf..c3f68eea 100644 --- a/it/h3-h2.md +++ b/it/h3-h2.md @@ -33,7 +33,7 @@ HTTP/3 usi QUIC: - Le negoziazioni (handshakes) sono molto più rapide in HTTP/3 grazie a QUIC - Non esistono versioni non crittate o non sicure di HTTP/3. HTTP/2 può ancora - essere implementato ed utilizzato senza HTTPS - benchè molto raro su Internet + essere implementato ed utilizzato senza HTTPS - benché molto raro su Internet - HTTP/2 può essere negoziato direttamente all'interno di una negoziazione TLS grazie all'estensione ALPN. Diversamente, in HTTP/3 (essendo su QUIC) si diff --git a/it/h3-prio.md b/it/h3-prio.md index be70efcc..ac5df8d8 100644 --- a/it/h3-prio.md +++ b/it/h3-prio.md @@ -1,7 +1,7 @@ # Prioritizzazione in HTTP/3 Uno dei frame facenti parte di ogni flusso HTTP/3 è il campo `PRIORITY`. -E' usato per segnalare la priorità e l'ordine di dipendenza fra flussi +È usato per segnalare la priorità e l'ordine di dipendenza fra flussi diversi molto similmente a quanto gia avveniva in HTTP/2. Il frame può essere impostato in modo che un flusso dipenda da un altro e diff --git a/it/h3-push.md b/it/h3-push.md index 7eef164e..96ee8f19 100644 --- a/it/h3-push.md +++ b/it/h3-push.md @@ -31,7 +31,7 @@ Questa caratteristica è stata messa in discussione, criticata e rigirata sin dal primo momento, sia durante lo sviluppo di HTTP/2 sia dopo la sua pubblicazione e impiego su larga scala, tentando di renderla utilizzabile. -Un invio in "push" non è mai gratis, benchè utilizzi solo metà del tempo di -round-trip, occupa banda passante. E' spesso difficile -impossibile- dal +Un invio in "push" non è mai gratis, benché utilizzi solo metà del tempo di +round-trip, occupa banda passante. È spesso difficile -impossibile- dal punto di vista del server stabilire con certezza se una determinata risorsa possa necessitare (beneficiare) del "push" o meno. diff --git a/it/h3-streams.md b/it/h3-streams.md index f9bd7a5d..94b4ab8f 100644 --- a/it/h3-streams.md +++ b/it/h3-streams.md @@ -36,7 +36,7 @@ frame HEADERS, una serie di DATA ed eventualmente un frame HEADERS di coda. I frames HEADERS contengono le intestazioni HTTP compresse con l'algoritmo QPACK. QPACK risulta simile al vecchio HPACK utilizzato in HTTP/2 ([RFC 7541 -](https://httpwg.org/specs/rfc7541.html)), benchè modificato per consegnare +](https://httpwg.org/specs/rfc7541.html)), benché modificato per consegnare i differenti flussi in modalità "disordinata" (out-of-order). QPACK si avvale di due streams QUIC unidirezionali fra i due estremi della diff --git a/it/h3.md b/it/h3.md index f5101ff4..ebdcedbb 100644 --- a/it/h3.md +++ b/it/h3.md @@ -22,7 +22,7 @@ alla diversa natura di QUIC rispetto a TCP. Le modifiche includono: - Per via del fatto che i flussi in QUIC sono independenti l'uno dall'altro, non è stato possibile utilizzare la stessa identica modalità di compressione - delle intestazioni gia impiegata in HTTP/2 poichè essa avrebbe provocato + delle intestazioni gia impiegata in HTTP/2 poiché essa avrebbe provocato "bloccaggi di inizio riga". - Gli streams QUIC sono lievemente diversi da quelli HTTP/2. La sezione diff --git a/it/quic-spinbit.md b/it/quic-spinbit.md index 3526344c..cc162f0b 100644 --- a/it/quic-spinbit.md +++ b/it/quic-spinbit.md @@ -17,7 +17,7 @@ singola connessione QUIC; client e server sono incaricati di impostare un valore all'interno di ciascun pacchetto spedito. Entrambi gli estremi inviano il pacchetto impostando lo stesso valore per -la durata di un solo round-trip, alchè invertono il valore. Il risultato è +la durata di un solo round-trip, e dopo invertono il valore. Il risultato è dunque una serie di pulsazioni di 0 e 1 utile al monitoraggio. Questo tipo di misurazione è efficace solo se il peer che invia non è diff --git a/it/quic-v2.md b/it/quic-v2.md index ce0c37af..b9cea4af 100644 --- a/it/quic-v2.md +++ b/it/quic-v2.md @@ -36,7 +36,7 @@ il multipath, così come il TCP più moderno. ## Dati inaffidabili -E' stato proposto di offrire streams "non-affidabili" come opzione, il che +È stato proposto di offrire streams "non-affidabili" come opzione, il che permetterebbe a QUIC di rimpiazzare qualsiasi applicazione che utilizzi UDP. ## Adattamenti che non riguardano HTTP diff --git a/it/why-quic.md b/it/why-quic.md index fd75d400..004511ee 100644 --- a/it/why-quic.md +++ b/it/why-quic.md @@ -1,4 +1,4 @@ -# Perchè QUIC +# Perché QUIC QUIC è un nome, non un acronimo. Si pronuncia esattamente come la parola Inglese "quick" (veloce). @@ -13,6 +13,6 @@ la distribuzione dei contenuti sempre più veloce agli occhi degli utenti è probabilmente la ragione principale ad aver stimolato la creazione di questo nuovo protocollo di trasporto. -Perchè creare un nuovo protocollo di trasporto e perchè mai basarlo su UDP ? +Perché creare un nuovo protocollo di trasporto e perché mai basarlo su UDP ? ![Logo di QUIC](../images/QUIC.png) diff --git a/it/why-tcphol.md b/it/why-tcphol.md index 9c122fc7..3a8f97b2 100644 --- a/it/why-tcphol.md +++ b/it/why-tcphol.md @@ -32,7 +32,7 @@ ottengano risultati di gran lunga migliori, stimando che un tasso di perdita del 2% distribuito su sei connessioni abbia meno influenza che su una sola, permettendo così alle rimanenti connessioni di proseguire senza intralcio. -Porre rimedio a tale empasse non sarà semplice -se non impossibile- finchè si +Porre rimedio a tale empasse non sarà semplice -se non impossibile- finché si continuerà ad usare il TCP.. ## L'impiego di flussi indipendenti evita il blocco diff --git a/it/why-tcpudp.md b/it/why-tcpudp.md index e535ac27..d21a419a 100644 --- a/it/why-tcpudp.md +++ b/it/why-tcpudp.md @@ -15,7 +15,7 @@ firewalls, NATs, routers e altri dispositivi di rete che si iterpongono fra l'ut e il server sono semplicemente troppi, e sono a conoscenza dei soli UDP o TCP. Introdurre un altro protocollo di trasporto fa si che un determinato tasso di connessioni N% fallisca, in quanto bloccato dalle suddette middle-boxes che -identificherebbero tale proto come malevolo, malformato, nè TCP nè UDP. Un tasso di +identificherebbero tale proto come malevolo, malformato, né TCP né UDP. Un tasso di fallimento N% in ambito internet rappresenta spesso una buona ragione per non intraprendere alcuno sforzo. @@ -26,7 +26,7 @@ In anni recenti, abbiamo visto features di TCP diventare standard IETF senza che sia stata corrispondenza -ad anni di distanza- con il tasso di distribuzione degli stessi, per via della mancanza di utilizzo o di supporto universale. -## Perchè no, SCTP-over-UDP +## Perché no, SCTP-over-UDP SCTP è un protocollo di trasporto di flussi affidabile, ed esistono persino alcune implementazioni in ambito WebRTC che utilizzano SCTP via UDP. From 460bbc91bad15d267be63293b7f2edb25618d113 Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Wed, 14 Sep 2022 10:29:55 +0200 Subject: [PATCH 27/78] [README.md] [Spanish] [README.md translated] --- es/README.md | 45 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 es/README.md diff --git a/es/README.md b/es/README.md new file mode 100644 index 00000000..ca23de97 --- /dev/null +++ b/es/README.md @@ -0,0 +1,45 @@ +# HTTP/3 explicado + +Este libro fue lanzado en Marzo del 2018. El plan consiste en documentar HTTP/3 +y su protocolo subyacente: QUIC. Por qué, cómo funcionan, los detalles del +protocolo, las implementaciones y más. + +Este libro es completamente gratis y se pretende ser un esfuerzo colaboración +en el que participen todas las personas que quieran ayudar. + +## Requerimientos + +Se supone que el lector de este libro tiene un conocimiento básico de redes +TCP/IP, los fundamentos de HTTP y la web. Para más información y +especificidades sobre HTTP/2, recomendamos leer primero los detalles en +[http2 explained (español)](https://http2-explained.haxx.se/es). + +## Autor + +Este libro es creado y el trabajo es iniciado por [Daniel +Stenberg](https://daniel.haxx.se/). Daniel es el fundador y desarrollador +principal de [curl](https://curl.haxx.se/), el software cliente HTTP más +utilizado del mundo. Daniel ha trabajado con y sobre HTTP y los protocolos de +Internet durante más de dos décadas y es autor de [http2 +explained (español)](https://daniel.haxx.se/http2/es). + +## Inicio + +La página de inicio de este libro se encuentra en +[daniel.haxx.se/http3-explained/es](https://daniel.haxx.se/http3-explained/es). + +## Ayuda + +Si encuentra errores, omisiones, equivocaciones o mentiras flagrantes en este +documento, envíenos una versión actualizada del párrafo afectado y haremos +versiones modificadas. Daremos el debido crédito a todos los que nos ayuden. +Espero que este documento mejore con el tiempo. + +De preferencia, envíe los [errores](https://github.com/bagder/http3-explained/issues) +o [pull requests](https://github.com/bagder/http3-explained/pulls) mediante la +página de GitHub del libro. + +## Licencia + +Este documento y todo su contenido estan bajo la licencia [Creative Commons +Attribution 4.0 license](https://creativecommons.org/licenses/by/4.0/). From 0dd52d096e2db79dadf6f3bdec51a8709160b79c Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Wed, 14 Sep 2022 10:36:40 +0200 Subject: [PATCH 28/78] [why-quic] [es] [why-quic.md translated] --- es/why-quic.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 es/why-quic.md diff --git a/es/why-quic.md b/es/why-quic.md new file mode 100644 index 00000000..0baf4df5 --- /dev/null +++ b/es/why-quic.md @@ -0,0 +1,19 @@ +# Por qué QUIC + +QUIC es un nombre, no un acrónimo. Se pronuncia exactamente como la palabra +"quick" en inglés. + +QUIC es un nuevo protocolo de transporte fiable y seguro que es adecuado +para un protocolo como HTTP y que puede solucionar algunas de las deficiencias +conocidas de hacer HTTP/2 sobre TCP y TLS. Es el siguiente paso lógico en la +evolución del transporte web. + +QUIC no se limita a transportar HTTP. El deseo de hacer que la web y los datos +en general lleguen más rápido a los usuarios finales es probablemente la mayor +razón y el impulso que desencadenó inicialmente la creación de este nuevo +protocolo de transporte. + +Entonces, ¿por qué crear un nuevo protocolo de transporte y por qué hacerlo +sobre UDP? + +![QUIC logo](../images/QUIC.png) From 52b8fc17559690ca2cc7d94404d3788516a88bc4 Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Wed, 14 Sep 2022 11:07:10 +0200 Subject: [PATCH 29/78] [why-tcphol] [es] [why-tcphol.md translated] --- es/why-tcphol.md | 51 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 es/why-tcphol.md diff --git a/es/why-tcphol.md b/es/why-tcphol.md new file mode 100644 index 00000000..91ef6478 --- /dev/null +++ b/es/why-tcphol.md @@ -0,0 +1,51 @@ +## Bloqueo de cabeza de línea TCP (_TCP head of line blocking_) + +HTTP/2 se realiza sobre TCP y con muchas menos conexiones TCP que cuando se +utilizan versiones anteriores de HTTP. TCP es un protocolo para transferencias +fiables y básicamente se puede pensar en él como una cadena imaginaria entre +dos máquinas. Lo que se pone en la red en un extremo terminará en el otro, +en el mismo orden - eventualmente. (O la conexión se rompe). + +![Una cadena TCP entre dos ordenadores](../images/tcp-chain.png) + +Con HTTP/2, los navegadores típicos realizan decenas o cientos de transferencias +paralelas a través de una única conexión TCP. + +Si un solo paquete se cae, o se pierde en la red en algún lugar entre dos puntos +finales que hablan HTTP/2, significa que toda la conexión TCP se detiene +mientras el paquete perdido se retransmite y encuentra su camino hacia el +destino. Dado que TCP es esta "cadena", significa que si un eslabón se pierde de +repente, todo lo que vendría después del eslabón perdido tiene que esperar. + +Una ilustración utilizando la metáfora de la cadena al enviar dos flujos a +través de esta conexión. Un flujo rojo y un flujo verde: + +![La cadena mostrando los enlaces en diferentes colores](../images/tcp-chain-streams.png) + +¡Se convierte en un bloqueo de cabeza de línea TCP! + +A medida que aumenta la tasa de pérdida de paquetes, HTTP/2 rinde cada vez +menos. Con un 2% de pérdida de paquetes (que es una calidad de red terrible, +ojo), las pruebas han demostrado que los usuarios de HTTP/1 suelen estar mejor, +porque suelen tener hasta seis conexiones TCP entre las que distribuir los +paquetes perdidos. Esto significa que por cada paquete perdido, las otras +conexiones pueden continuar. + +Arreglar este problema no es fácil, si acaso es posible, con TCP. + +## Los flujos independientes evitan el bloqueo + +Con QUIC todavía hay una configuración de conexión entre los dos puntos +finales que hace que la conexión sea segura y la entrega de datos fiable. + +![Una cadena QUIC entre dos ordenadores](../images/tcp-chain.png) + +Cuando se establecen dos flujos diferentes sobre esta conexión, se tratan +de forma independiente, de manera que si se pierde algún enlace para uno +de los flujos, sólo ese flujo, esa cadena en particular, tiene que hacer +una pausa y esperar a que el enlace perdido se retransmita. + +Ilustrado aquí con un flujo amarillo y otro azul enviados entre dos puntos +finales. + +![Dos flujos QUIC entre dos ordenadores](../images/quic-chain-streams.png) From f0d3af93f7d9e5d8a21ebc99bf50970773c4b5ca Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Wed, 14 Sep 2022 11:20:50 +0200 Subject: [PATCH 30/78] [why-tcpudp] [es] [why-tcpudp.md translated] --- es/why-tcpudp.md | 45 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 es/why-tcpudp.md diff --git a/es/why-tcpudp.md b/es/why-tcpudp.md new file mode 100644 index 00000000..a61f032a --- /dev/null +++ b/es/why-tcpudp.md @@ -0,0 +1,45 @@ +## TCP o UDP + +Si no podemos arreglar el bloqueo de cabecera en TCP, entonces en teoría +deberíamos ser capaces de hacer un nuevo protocolo de transporte junto a UDP y +TCP en la pila de la red. O quizás incluso utilizar +[SCTP](https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol) que +es un protocolo de transporte estandarizado por el IETF en [RFC +4960](https://tools.ietf.org/html/rfc4960) con varias de las características +deseadas. + +Sin embargo, en los últimos años los esfuerzos para crear nuevos protocolos de +transporte se han detenido casi por completo debido a las dificultades para +desplegarlos en Internet. El despliegue de nuevos protocolos se ve obstaculizado +por muchos cortafuegos, NATs, routers y otras cajas intermedias que sólo +permiten TCP o UDP se despliegan entre los usuarios y los servidores que +necesitan alcanzar. Introducir otro protocolo de transporte hace que el N% de +las conexiones fallen porque están siendo bloqueadas por cajas que ven que no es +UDP o TCP y que, por tanto, es malo o erróneo de alguna manera. La tasa de +fallos del N% se considera a menudo demasiado alta para que merezca la pena el +esfuerzo. + +Además, cambiar cosas en la capa de protocolo de transporte de la pila de red +suele significar protocolos implementados por los kernels del sistema operativo. +Actualizar y desplegar nuevos kernels de los sistemas operativos es un proceso +lento que requiere un esfuerzo considerable. Muchas de las mejoras de TCP +estandarizadas por el IETF no están ampliamente desplegadas o utilizadas porque +no están ampliamente soportadas. + +## Por qué no SCTP-sobre-UDP + +SCTP es un protocolo de transporte fiable con flujos, y para WebRTC +hay incluso implementaciones existentes que lo utilizan sobre UDP. + +Esto no se consideró lo suficientemente bueno como una alternativa a QUIC debido +a varias razones, incluyendo: + + - SCTP no soluciona el problema del bloqueo de la cabeza de línea para los flujos + - SCTP requiere que el número de flujos se decida al establecer la conexión + - SCTP no tiene una historia sólida de TLS/seguridad + - SCTP tiene un handshake de 4 vías, QUIC ofrece 0-RTT + - QUIC es un bytestream como TCP, SCTP está basado en mensajes + - Las conexiones QUIC pueden migrar entre direcciones IP, pero SCTP no + +Para más detalles sobre las diferencias, véase [A Comparison between SCTP and +QUIC](https://tools.ietf.org/html/draft-joseph-quic-comparison-quic-sctp-00). From 62247184a8a46a31a6bede8024a159b74948076a Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Wed, 14 Sep 2022 11:31:06 +0200 Subject: [PATCH 31/78] [es] Translated why-ossification.md --- es/why-ossification.md | 46 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 es/why-ossification.md diff --git a/es/why-ossification.md b/es/why-ossification.md new file mode 100644 index 00000000..139c8f3a --- /dev/null +++ b/es/why-ossification.md @@ -0,0 +1,46 @@ +# Osificación + +Internet es una red de redes. Hay equipos instalados en Internet en muchos +lugares diferentes a lo largo del camino para asegurarse de que esta red de +redes funciona como se supone que debe hacerlo. Estos dispositivos, las cajas +que están distribuidas en la red, son lo que a veces llamamos cajas intermedias. +Cajas que se sitúan en algún lugar entre los dos puntos finales que son las +partes principales implicadas en una transferencia de datos de red tradicional. + +Estas cajas sirven para muchos propósitos específicos diferentes, pero creo que +podemos decir que universalmente se ponen ahí porque alguien piensa que deben +estar ahí para que las cosas funcionen. + +Las cajas intermedias enrutan los paquetes IP entre las redes, bloquean el +tráfico malicioso, hacen NAT (traducción de direcciones de red), mejoran el +rendimiento, algunas intentan espiar el tráfico que pasa y mucho más. + +Para desempeñar sus funciones, estas cajas deben conocer las redes y los +protocolos que supervisan o modifican. Para ello ejecutan un software. Un +software que no siempre se actualiza con frecuencia. + +Aunque son componentes de pegamento que mantienen unida a Internet, a menudo no +se mantienen al día con la última tecnología. El centro de la red no suele +moverse tan rápido como los bordes, como los clientes y los servidores del +mundo. + +Los protocolos de red que estas cajas podrían querer inspeccionar, y tener ideas +sobre lo que está bien y lo que no, tienen entonces este problema: estas cajas +se desplegaron hace algún tiempo cuando los protocolos tenían un conjunto de +características de esa época. Al introducir nuevas características o cambios en +el comportamiento que no se conocían antes, se corre el riesgo de que dichas +cajas lo consideren malo o ilegal. Es muy posible que ese tráfico se elimine o +se retrase hasta el punto de que los usuarios no quieran utilizar esas +funciones. + +Esto se llama "osificación del protocolo". + +Los cambios en TCP también sufren de osificación: algunas cajas entre un cliente +y el servidor remoto detectarán nuevas opciones TCP desconocidas y bloquearán +dichas conexiones ya que no saben cuáles son las opciones. Si se permite +detectar los detalles del protocolo, los sistemas aprenden cómo se comportan +normalmente los protocolos y con el tiempo resulta imposible cambiarlos. + +La única forma realmente eficaz de "combatir" la osificación es cifrar la mayor +parte posible de la comunicación para evitar que las cajas intermedias vean gran +parte del protocolo que pasa. From d6f0f4083f98b875865e7227613cceeea5d7e109 Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Wed, 14 Sep 2022 11:34:52 +0200 Subject: [PATCH 32/78] [es] Translated why-secure.md --- es/why-secure.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 es/why-secure.md diff --git a/es/why-secure.md b/es/why-secure.md new file mode 100644 index 00000000..1084358a --- /dev/null +++ b/es/why-secure.md @@ -0,0 +1,12 @@ +## Seguro + +QUIC es siempre seguro. No hay una versión texto claro del protocolo, por lo que +negociar una conexión QUIC significa hacer criptografía y seguridad con TLS 1.3. +Como se mencionó anteriormente, esto evita la osificación, así como otros tipos +de bloqueos y tratamientos especiales, además de asegurar que QUIC tiene todas +las propiedades seguras de HTTPS que los usuarios de la web han llegado a +esperar y desear. + +Sólo hay unos pocos paquetes iniciales de intercambio de información que se +envían en claro antes de que los protocolos de encriptación hayan sido +negociados. From 0a1bce3d635bdc10bcde4e996843c3d886751b53 Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Wed, 14 Sep 2022 11:39:41 +0200 Subject: [PATCH 33/78] [es] Translated why-latency.md --- es/why-latency.md | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 es/why-latency.md diff --git a/es/why-latency.md b/es/why-latency.md new file mode 100644 index 00000000..f9cfe3a7 --- /dev/null +++ b/es/why-latency.md @@ -0,0 +1,26 @@ +# Datos tempranos + +QUIC ofrece handshakes de 0-RTT y 1-RTT que reducen el tiempo de negociación y +establecimiento de una nueva conexión. Compárese con el handshake de 3 vías de +TCP. + +Además de eso, QUIC ofrece soporte de "datos tempranos" desde el principio que +se hace para permitir más datos y se utiliza más fácilmente que TCP Fast Open. + +Con el concepto de flujo, se puede hacer otra conexión lógica al mismo host a la +vez sin tener que esperar a que la existente termine primero. + +## TCP Fast Open es problemático + +TCP Fast Open se publicó como [RFC 7413](https://tools.ietf.org/html/rfc7413) en +diciembre de 2014 y esa especificación describe cómo las aplicaciones pueden +pasar datos al servidor para que se entreguen ya en el primer paquete TCP SYN. + +El soporte real de esta característica en la naturaleza ha tomado tiempo y está +plagado de problemas incluso hoy en 2018. Los implementadores de la pila TCP han +tenido problemas y también lo han tenido las aplicaciones que intentan +aprovechar esta característica, tanto para saber en qué versión del sistema +operativo intentar activarla como para averiguar cómo retroceder con gracia y +lidiar cuando surgen problemas. Se han identificado varias redes que interfieren +con el tráfico TFO y, por tanto, han arruinado activamente estos handshakes TCP. + From 76b095d1fb6144ee121d75b7c3851f0a41536c4f Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Wed, 14 Sep 2022 11:40:17 +0200 Subject: [PATCH 34/78] [es] Translated why-h2.md --- es/why-h2.md | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 es/why-h2.md diff --git a/es/why-h2.md b/es/why-h2.md new file mode 100644 index 00000000..6e29248c --- /dev/null +++ b/es/why-h2.md @@ -0,0 +1,35 @@ +## ¿Te acuerdas de HTTP/2? + +La especificación de HTTP/2 [RFC 7540](https://httpwg.org/specs/rfc7540.html) +fue publicado en mayo de 2015 y desde entonces el protocolo se ha implementado +y desplegado ampliamente en Internet y en la World Wide Web. + +A principios de 2018, casi el 40% de los principales 1000 sitios web ejecutan +HTTP/2, alrededor del 70% de todas las solicitudes HTTPS que emite Firefox +obtienen respuestas HTTP/2 y todos los principales navegadores, servidores y +proxies lo soportan. + +HTTP/2 aborda toda una serie de deficiencias de HTTP/1 y con la introducción +de la segunda version de HTTP los usuarios pueden dejar de utilizar un montón +de métodos alternativos. Algunos de las cuales son bastante agobiante para los +desarrolladores web. + +Una de las principales características de HTTP/2 es que hace uso de la +multiplexación, de modo que que muchos flujos lógicos (_streams_) se envían a +través de la misma conexión TCP física. Esto hace que muchas cosas sean mejores +y más rápidas. Hace que el control de la congestión funcione mucho mejor, +permite a los usuarios usar TCP mucho mejor y así saturar adecuadamente el +ancho de banda, hace que las conexiones TCP sean más duraderas, lo que es bueno +para que para que puedan alcanzar su máxima velocidad con más frecuencia que +antes. La compresión de cabeceras hace que se utilice menos ancho de banda. + +Con HTTP/2, los navegadores suelen utilizar *una* conexión TCP a cada host en +lugar de de las *seis* anteriores. De hecho, las técnicas de coalescencia de la +conexión y de "desharding" utilizadas con HTTP/2 pueden incluso reducir el +número de conexiones mucho más que eso. + +HTTP/2 solucionó el problema de bloqueo de la cabecera de la línea HTTP +(_HTTP head of line blocking_), donde los clientes tenían que esperar a que +terminara la primera petición (_request_) para que pudiera salir la siguiente. + +![http2 man](../images/h2-man.jpg) From 9947555fa59e2f3b549e26397fbe20905d972d05 Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Wed, 14 Sep 2022 14:27:35 +0200 Subject: [PATCH 35/78] [es] Translated proc.md --- es/proc.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 es/proc.md diff --git a/es/proc.md b/es/proc.md new file mode 100644 index 00000000..3c624111 --- /dev/null +++ b/es/proc.md @@ -0,0 +1,24 @@ +# El proceso + +El protocolo QUIC inicial fue diseñado por Jim Roskind en Google y se implementó +inicialmente en 2012, anunciándose públicamente al mundo en 2013 cuando se +amplió la experimentación de Google. + +Por aquel entonces, QUIC seguía siendo un acrónimo de "Quick UDP Internet +Connections" (conexiones rápidas a Internet), pero desde entonces se ha +eliminado. + +Google implementó el protocolo y, posteriormente, lo desplegó tanto en su +ampliamente utilizado navegador (Chrome) como en sus ampliamente utilizados +servicios (búsqueda de Google, Gmail, YouTube y más). Han iterado versiones del +protocolo con bastante rapidez y, con el tiempo, han demostrado que el concepto +funciona de forma fiable para una gran parte de los usuarios. + +En junio de 2015, el primer borrador de Internet para QUIC se envió al IETF para +su estandarización, pero hubo que esperar hasta finales de 2016 para que se +aprobara y se pusiera en marcha un grupo de trabajo sobre QUIC. Pero luego +despegó de inmediato con un alto grado de interés de muchas partes. + +En 2017, las cifras citadas por los ingenieros de QUIC en Google mencionaban que +alrededor del 7% de *todo* el tráfico de Internet ya utilizaba este protocolo. +La versión de Google del protocolo. From a443f04be8cc6c754b3fb018e75bf9ca642323af Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Wed, 14 Sep 2022 14:27:58 +0200 Subject: [PATCH 36/78] [es] Translated proc-ietf.md --- es/proc-ietf.md | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 es/proc-ietf.md diff --git a/es/proc-ietf.md b/es/proc-ietf.md new file mode 100644 index 00000000..4ca87ef3 --- /dev/null +++ b/es/proc-ietf.md @@ -0,0 +1,38 @@ +## IETF + +El grupo de trabajo de QUIC que se creó para estandarizar el protocolo dentro de +la IETF decidió rápidamente que el protocolo QUIC debía ser capaz de transferir +otros protocolos además de "sólo" HTTP. Google-QUIC sólo transportaba HTTP - +en la práctica transportaba lo que era efectivamente tramas HTTP/2, utilizando +la sintaxis de tramas HTTP/2. + +También se afirmó que el IETF-QUIC debería basar su cifrado y seguridad en TLS +1.3 en lugar del enfoque "personalizado" utilizado por Google-QUIC. + +Con el fin de satisfacer la demanda de enviar-más-que-sólo-HTTP, la arquitectura +del protocolo IETF-QUIC se dividió en dos capas separadas: el transporte QUIC y +la capa "HTTP sobre QUIC" - esta última fue renombrada como HTTP/3 en noviembre +de 2018. + +Esta división de capas, aunque pueda parecer inocua, ha hecho que el IETF-QUIC +difiera bastante del Google-QUIC original. + +Sin embargo, el grupo de trabajo pronto decidió que para conseguir el enfoque +adecuado y la capacidad de entregar la versión 1 de QUIC a tiempo, se centraría +en entregar HTTP, dejando los transportes no HTTP para un trabajo posterior. + +En marzo de 2018, cuando comenzamos a trabajar en este libro, el plan era enviar +la especificación final para la versión 1 de QUIC en noviembre de 2018, pero +esto se ha pospuesto varias veces y, en el momento de escribir este artículo +(junio de 2020), está entrando en las etapas finales. + +Mientras el trabajo en IETF-QUIC ha progresado, el equipo de Google ha +incorporado detalles de la versión del IETF y ha comenzado a progresar +lentamente su versión del protocolo hacia lo que la versión del IETF podría +llegar a ser. Google ha seguido utilizando su versión de QUIC en su navegador y +sus servicios. + +[La mayoría de las nuevas implementaciones en +desarrollo](https://github.com/quicwg/base-drafts/wiki/Implementations) han +decidido centrarse en la versión del IETF y no son compatibles con la versión de +Google. From 877205c6baefc8202e857f05c93caf3bbe2a769e Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Wed, 14 Sep 2022 14:28:25 +0200 Subject: [PATCH 37/78] [es] Translated proc-h2.md --- es/proc-h2.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 es/proc-h2.md diff --git a/es/proc-h2.md b/es/proc-h2.md new file mode 100644 index 00000000..fdf556c4 --- /dev/null +++ b/es/proc-h2.md @@ -0,0 +1,16 @@ +## La experiencia de HTTP/2 + +La especificación RFC 7540 de HTTP/2 fue publicada en mayo de 2015, justo un mes +antes que QUIC fuera llevado a la IETF por primera vez. + +Con HTTP/2, se sentaron las bases para cambiar HTTP sobre la red y el grupo de +trabajo que creó HTTP/2 ya tenía la idea de que esto ayudaría a iterar a nuevas +versiones de HTTP mucho más rápido de lo que se había tardado en pasar a la +versión 2 desde la versión 1 (unos 16 años). + +Con HTTP/2, los usuarios y los stack de software se acostumbraron a la idea de +que HTTP ya no puede suponerse un protocolo basado en texto de forma serial. + +HTTP-over-QUIC (HTTP/3) se basa en HTTP/2 y sigue muchos de los mismos conceptos +pero traslada algunos de los aspectos específicos de la capa HTTP, ya que están +cubiertos por QUIC. From 717e8cd4b141e51fda5bf2a39a031cdf835c4fe4 Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Wed, 14 Sep 2022 14:28:40 +0200 Subject: [PATCH 38/78] [es] Translated proc-status.md --- es/proc-status.md | 82 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 82 insertions(+) create mode 100644 es/proc-status.md diff --git a/es/proc-status.md b/es/proc-status.md new file mode 100644 index 00000000..e2925330 --- /dev/null +++ b/es/proc-status.md @@ -0,0 +1,82 @@ +# Estado + +El grupo de trabajo de QUIC ha trabajado intensamente desde finales de 2016 en +la especificación de los protocolos y se está acercando a las etapas finales en +el momento de escribir este artículo (junio de 2020). + +Durante 2019 y 2020 ha habido un número creciente de [pruebas de +interoperabilidad con HTTP/3](https://docs.google.com/spreadsheets/d/1D0tW89vOoaScs3IY9RGC0UesWGAwE6xyLk0l4JtvTVg) +y las CDN y los navegadores han comenzado a lanzar el soporte inicial - aunque a +menudo detrás de flags. + +Hay un número de diferentes [implementaciones de QUIC +listadas](https://github.com/quicwg/base-drafts/wiki/Implementations) en las +páginas wiki de los grupos de trabajo de QUIC. + +Implementar QUIC no es fácil y el protocolo ha seguido moviéndose y cambiando +incluso hasta la fecha. + +## Servidores + +El soporte de NGINX para QUIC y HTTP/3 está en desarrollo y se ha anunciado una +[versión preliminar](https://www.nginx.com/blog/introducing-technology-preview-nginx-support-for-quic-http-3/). + +No ha habido ninguna declaración pública en términos de soporte para QUIC por +parte de Apache. + +## Clientes + +Ninguno de los grandes proveedores de navegadores ha lanzado aún ninguna +versión, en ningún estado, que pueda ejecutar la versión IETF de QUIC o HTTP/3. + +Google Chrome ha sido distribuido con una implementación funcional de la propia +versión de QUIC de Google desde hace muchos años y recientemente ha comenzado a +soportar la versión del IETF detrás de un flag. Firefox también lo soporta +con una flag. + +curl envió el primer soporte experimental de HTTP/3 (draft-22) en la versión +7.66.0 el 11 de septiembre de 2019. curl utiliza la biblioteca Quiche de +Cloudflare o la familia de bibliotecas ngtcp2 para realizar el trabajo. + +## Obstáculos de implementación + +QUIC decidió utilizar TLS 1.3 como base para la capa de criptografía y seguridad +para evitar inventar algo nuevo y en su lugar apoyarse en un protocolo existente +y de confianza. Sin embargo, al hacer esto, el grupo de trabajo también decidió +que para realmente racionalizar el uso de TLS en QUIC, sólo debería utilizar +"mensajes TLS" y no "registros TLS" para el protocolo. + +Esto puede parecer un cambio inocuo, pero en realidad ha causado un obstáculo +importante para muchos implementadores de la pila QUIC. Las librerías TLS +existentes que soportan TLS 1.3 simplemente no tienen APIs suficientes para +exponer esta funcionalidad y permitir a QUIC acceder a ella. Aunque varios +implementadores de QUIC provienen de organizaciones más grandes que trabajan en +su propia pila TLS en paralelo, esto no es cierto para todos. + +El dominante peso pesado de código abierto, OpenSSL, por ejemplo, no tiene +ninguna API para esto. El plan para abordar esto parece ocurrir en su [PR +8797](https://github.com/openssl/openssl/pull/8797) que pretende introducir una +API muy similar a la de BoringSSL. + +Esto eventualmente también conducirá a obstáculos en el despliegue, ya que las +pilas QUIC tendrán que basarse en otras bibliotecas TLS, utilizar una +construcción separada de OpenSSL parcheada o requerir una actualización a una +futura versión de OpenSSL. + +## Kernels y carga de la CPU + +Tanto Google como Facebook han mencionado que sus despliegues a gran escala de +QUIC requieren aproximadamente el doble de CPU que la misma carga de tráfico +cuando se sirve HTTP/2 sobre TLS. + +Algunas explicaciones para esto incluyen + +- las partes UDP principalmente en Linux no están tan optimizadas como la pila + TCP, ya que no se ha utilizado tradicionalmente para transferencias de alta + velocidad como esta. + +- la descarga de TCP y TLS al hardware existe, pero eso es mucho más raro para + UDP y básicamente inexistente para QUIC. + +Hay razones para creer que el rendimiento y los requisitos de la CPU mejorarán +con el tiempo. From 5ac7cc6cfa9aacbbdf7379d244da11839a1156ae Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Wed, 14 Sep 2022 17:17:52 +0200 Subject: [PATCH 39/78] [es] Translated the-protocol.md --- es/the-protocol.md | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 es/the-protocol.md diff --git a/es/the-protocol.md b/es/the-protocol.md new file mode 100644 index 00000000..bd50dda0 --- /dev/null +++ b/es/the-protocol.md @@ -0,0 +1,8 @@ +# Características del protocolo + +El protocolo QUIC desde un alto nivel. + +A continuación se ilustra la pila de red HTTP/2 a la izquierda y la pila de red +QUIC a la derecha, cuando se utiliza como transporte HTTP. + +![Vista general del stack HTTP/3 sobre QUIC](../images/quic-stack.png) From 0c2b83f68df0ceced4df99bdfb193ed58c993595 Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Wed, 14 Sep 2022 17:18:17 +0200 Subject: [PATCH 40/78] [es] Translated feature-udp.md --- es/feature-udp.md | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 es/feature-udp.md diff --git a/es/feature-udp.md b/es/feature-udp.md new file mode 100644 index 00000000..a222175a --- /dev/null +++ b/es/feature-udp.md @@ -0,0 +1,31 @@ +## Protocolo de transferencia sobre UDP + +QUIC es un protocolo de transferencia implementado sobre UDP. Si observas +casualmente el tráfico de tu red, verás que QUIC aparece como paquetes UDP. + +Basado en UDP también utiliza números de puerto UDP para identificar servicios +de red específicos en una dirección IP determinada. + +Todas las implementaciones conocidas de QUIC están actualmente en el espacio de +usuario, lo que permite una evolución más rápida de lo que suelen permitir las +implementaciones en el espacio del núcleo. + +## ¿Funcionará? + +Hay empresas y otras configuraciones de red que bloquean el tráfico UDP en otros +puertos que no sean el 53 (utilizado para el DNS). Otros estrangulan tales datos +de manera que hace que QUIC funcione peor que los protocolos basados en TCP. No +hay fin a lo que algunos operadores pueden hacer. + +En un futuro previsible, todo uso de transportes basados en QUIC probablemente +tendrá que ser capaz de retroceder con gracia a otra alternativa (basada en +TCP). Los ingenieros de Google han mencionado anteriormente tasas de fallo +medidas en porcentajes de un solo dígito. + +## ¿Mejorará? + +Lo más probable es que si QUIC demuestra ser una valiosa adición al mundo de +Internet, la gente querrá utilizarlo y querrá que funcione en sus redes y +entonces las empresas podrían empezar a reconsiderar sus obstáculos. Durante los +años en que ha progresado el desarrollo de QUIC, el índice de éxito para +establecer y utilizar conexiones QUIC en Internet ha aumentado. From 46a8ffc904dc26a4f15beedd539407e67598a8a1 Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Wed, 14 Sep 2022 17:19:00 +0200 Subject: [PATCH 41/78] [es] Translated feature-reliable.md --- es/feature-reliable.md | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 es/feature-reliable.md diff --git a/es/feature-reliable.md b/es/feature-reliable.md new file mode 100644 index 00000000..34e808d7 --- /dev/null +++ b/es/feature-reliable.md @@ -0,0 +1,9 @@ +## Transferencias de datos fiables + +Aunque UDP no es un transporte fiable, QUIC añade una capa sobre UDP que que +introduce la fiabilidad. Ofrece retransmisiones de paquetes, control de +congestión control de la congestión, ritmo y otras características presentes en +TCP. + +Los datos enviados a través de QUIC desde un end-point aparecerán en el otro +extremo tarde o temprano, siempre que se mantenga la conexión. From a2b82277f79d9bd586e18da47a72491419708b41 Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Wed, 14 Sep 2022 17:19:22 +0200 Subject: [PATCH 42/78] [es] Translated feature-streams.md --- es/feature-streams.md | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 es/feature-streams.md diff --git a/es/feature-streams.md b/es/feature-streams.md new file mode 100644 index 00000000..355066c4 --- /dev/null +++ b/es/feature-streams.md @@ -0,0 +1,20 @@ +## Múltiples flujos dentro de las conexiones + +Al igual que SCTP, SSH y HTTP/2, QUIC presenta flujos lógicos separados dentro +de las conexiones físicas. Una serie de flujos paralelos que pueden transferir +datos simultáneamente a través de una única conexión sin afectar a los otros +flujos. + +Una conexión es una configuración negociada entre dos end-points, similar a cómo +funciona una conexión TCP. Una conexión QUIC se realiza con un puerto UDP y una +dirección IP, pero una vez establecida la conexión se asocia por su "ID de +conexión". + +A través de una conexión establecida, cualquiera de las partes puede crear +flujos y enviar datos al otro extremo. Los flujos se entregan en orden y son +fiables, pero diferentes flujos pueden entregarse fuera de orden. + +QUIC ofrece control de flujo tanto en la conexión como en los flujos. + +Ver más detalles en las secciones [conexiones](quic-connections.md) y +[flujos](quic-streams.md) From ea86d4f205f9e865a2cb42d3761b68a9617a2787 Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Wed, 14 Sep 2022 17:19:55 +0200 Subject: [PATCH 43/78] [es] Translated feature-inorder.md --- es/feature-inorder.md | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 es/feature-inorder.md diff --git a/es/feature-inorder.md b/es/feature-inorder.md new file mode 100644 index 00000000..7fc37348 --- /dev/null +++ b/es/feature-inorder.md @@ -0,0 +1,20 @@ +## Entrega en orden + +QUIC garantiza la entrega en orden de los flujos, pero no entre flujos. Esto +significa que cada flujo enviará datos y mantendrá el orden de los mismos, ¡pero +cada flujo puede llegar al destino en un orden diferente al que la aplicación lo +envió! + +Por ejemplo: los flujos A y B son transferidos desde un servidor a un cliente. +El flujo A se inicia primero y luego el flujo B. En QUIC, un paquete perdido +sólo afecta al flujo al que pertenece el paquete perdido. Si el flujo A pierde +un paquete pero el flujo B no, el flujo B puede continuar sus transferencias y +completarlas mientras el paquete perdido del flujo A es retransmitido. Esto no +era posible con HTTP/2. + +Ilustrado aquí con un flujo amarillo y otro azul enviados entre dos end-points +de QUIC a través de una única conexión. Son independientes y pueden llegar en un +orden diferente, pero cada flujo se entrega de forma fiable a la aplicación en +orden. + +![Dos flujos QUIC entre dos ordenadores](../images/quic-chain-streams.png) From 6d728ba5de8509f86329b2ec75a938b73da48020 Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Wed, 14 Sep 2022 17:20:07 +0200 Subject: [PATCH 44/78] [es] Translated feature-handshakes.md --- es/feature-handshakes.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 es/feature-handshakes.md diff --git a/es/feature-handshakes.md b/es/feature-handshakes.md new file mode 100644 index 00000000..4b128315 --- /dev/null +++ b/es/feature-handshakes.md @@ -0,0 +1,14 @@ +# Rápido establecimiento de comunicación + +QUIC ofrece configuraciones de conexión 0-RTT y 1-RTT, lo que significa que, en +el mejor de los casos, QUIC no necesita ningún viaje de ida y vuelta adicional +al establecer una nueva conexión. El más rápido de los dos, el handshake 0-RTT, +sólo funciona si se ha establecido una conexión previa con un host y se ha +almacenado en caché un secreto de esa conexión. + +## Datos tempranos + +QUIC permite a un cliente incluir datos ya en el handshake 0-RTT. Esta +característica permite a un cliente entregar datos al peer tan rápido como sea +posible, y eso entonces, por supuesto, permite al servidor responder y enviar +datos de vuelta incluso antes. From 6cf49d47334808482f81fa177f450b6126ea4935 Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Wed, 14 Sep 2022 17:20:29 +0200 Subject: [PATCH 45/78] [es] Translated feature-tls.md --- es/feature-tls.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 es/feature-tls.md diff --git a/es/feature-tls.md b/es/feature-tls.md new file mode 100644 index 00000000..7528c38d --- /dev/null +++ b/es/feature-tls.md @@ -0,0 +1,12 @@ +## TLS 1.3 + +La seguridad de transporte utilizada en QUIC usa TLS 1.3 ([RFC +8446](https://tools.ietf.org/html/rfc8446)) y nunca hay conexiones QUIC sin +cifrar. + +TLS 1.3 tiene varias ventajas en comparación con las versiones anteriores de +TLS, pero una de las principales razones para usarlo en QUIC es que 1.3 cambió +el handshake para requerir menos viajes de ida y vuelta. Esto reduce la latencia +del protocolo. + +La versión heredada de Google de QUIC utilizaba una criptografía personalizada. From 37009664001bdf3f29c61b1e20203f4d46bc9d37 Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Wed, 14 Sep 2022 17:20:42 +0200 Subject: [PATCH 46/78] [es] Translated feature-trans-app.md --- es/feature-trans-app.md | 11 +++++++++++ 1 file changed, 11 insertions(+) create mode 100644 es/feature-trans-app.md diff --git a/es/feature-trans-app.md b/es/feature-trans-app.md new file mode 100644 index 00000000..4ae3d6c8 --- /dev/null +++ b/es/feature-trans-app.md @@ -0,0 +1,11 @@ +## Nivel de transporte y aplicación + +El protocolo IETF QUIC es un protocolo de transporte, sobre el que se pueden +utilizar otros protocolos de aplicación pueden ser utilizados. El protocolo +inicial de la capa de aplicación es HTTP/3 (h3). + +La capa de transporte soporta conexiones y flujos. + +La versión heredada de Google de QUIC tenía el transporte y HTTP pegados en una +sola y era un protocolo enviar-tramas-http/2-sobre-udp de propósito mas +espécifico. From 59b8dbec3030dd466c4c18b6a4967ab7c7d42677 Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Wed, 14 Sep 2022 17:20:59 +0200 Subject: [PATCH 47/78] [es] Translated feature-http.md --- es/feature-http.md | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 es/feature-http.md diff --git a/es/feature-http.md b/es/feature-http.md new file mode 100644 index 00000000..6b9fa478 --- /dev/null +++ b/es/feature-http.md @@ -0,0 +1,10 @@ +## HTTP/3 sobre QUIC + +La capa HTTP, llamada HTTP/3, realiza transportes de estilo HTTP, incluyendo la +compresión de cabeceras HTTP usando QPACK - que es similar a la compresión +HTTP/2 llamada HPACK. + +El algoritmo HPACK depende de una entrega *ordenada* de flujos, por lo que no +fue posible reutilizarlo para HTTP/3 sin modificaciones, ya que QUIC ofrece +flujos que pueden ser entregados fuera de orden. QPACK puede verse como la +versión adaptada a QUIC de [HPACK](https://httpwg.org/specs/rfc7541.html). From fc22870f394871f54e7c14d9ac56dc49f810d040 Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Wed, 14 Sep 2022 17:21:25 +0200 Subject: [PATCH 48/78] [es] Translated feature-nonhttp.md --- es/feature-nonhttp.md | 4 ++++ 1 file changed, 4 insertions(+) create mode 100644 es/feature-nonhttp.md diff --git a/es/feature-nonhttp.md b/es/feature-nonhttp.md new file mode 100644 index 00000000..12fa7347 --- /dev/null +++ b/es/feature-nonhttp.md @@ -0,0 +1,4 @@ +## No-HTTP sobre QUIC + +El trabajo sobre el envío de protocolos distintos de HTTP sobre QUIC se ha +pospuesto hasta después de que la versión 1 de QUIC haya sido enviada. From 82a1d885f053554205b7ebccd7882250bc6b1229 Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Thu, 15 Sep 2022 15:55:44 +0200 Subject: [PATCH 49/78] [es] Translated quic.md --- es/quic.md | 11 +++++++++++ 1 file changed, 11 insertions(+) create mode 100644 es/quic.md diff --git a/es/quic.md b/es/quic.md new file mode 100644 index 00000000..e29cb15d --- /dev/null +++ b/es/quic.md @@ -0,0 +1,11 @@ +# Cómo funciona QUIC + +Sin explicar los bits y bytes exactos en el cable, esta sección describe cómo +funcionan los bloques fundamentales del protocolo de transporte QUIC. Si quieres +implementar tu propio stack QUIC, esta descripción debería darte una comprensión +general, pero para todos los detalles, consulta los actuales borradores de +Internet del IETF y las RFC. + +1. Configura una [conexión](quic-connections.md) +2. ... que incluya [seguridad TLS](quic-tls.md) +3. Luego utiliza [flujos](quic-streams.md) From bf2d52eddff73ac2c81d6e641d4535af2753a556 Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Thu, 15 Sep 2022 15:58:35 +0200 Subject: [PATCH 50/78] [es] Translated quic-connections.md --- es/quic-connections.md | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 es/quic-connections.md diff --git a/es/quic-connections.md b/es/quic-connections.md new file mode 100644 index 00000000..88d6620f --- /dev/null +++ b/es/quic-connections.md @@ -0,0 +1,40 @@ +# Conexiones + +Una conexión QUIC es una conversación única entre dos end-points QUIC. El +establecimiento de la conexión de QUIC combina la negociación de la versión con +los handshakes criptográficos y de transporte para reducir la latencia del +establecimiento de la conexión. + +Para enviar realmente datos a través de una conexión de este tipo, hay que crear +y utilizar uno o más flujos. + +## Identificación de la conexión + +Cada conexión posee un conjunto de identificadores de conexión, o IDs de +conexión, cada uno de los cuales puede ser utilizado para identificar la +conexión. Los IDs de conexión son seleccionados de forma independiente por los +end-points; cada punto final selecciona los IDs de conexión que utiliza su +compañero. + +La función principal de estos IDs de conexión es asegurar que los cambios en el +direccionamiento en las capas inferiores del protocolo (UDP, IP, y por debajo) +no causen que los paquetes de una conexión QUIC sean entregados al end-point +equivocado. + +Aprovechando el ID de conexión, las conexiones pueden migrar entre direcciones +IP e interfaces de red de una manera que TCP nunca podría. Por ejemplo, la +migración permite que una descarga en curso pase de una conexión de red celular +a una conexión wifi más rápida cuando el usuario traslada su dispositivo a un +lugar que ofrece wifi. Del mismo modo, la descarga puede continuar a través de +la conexión celular si el wifi no está disponible. + +## Números de puerto + +QUIC está construido sobre UDP, por lo que se utiliza un campo de número de +puerto de 16 bits para diferenciar las conexiones entrantes. + +## Negociación de la versión + +Una petición de conexión QUIC originada por un cliente le dirá al servidor qué +versión del protocolo QUIC quiere hablar, y el servidor responderá con una lista +de versiones soportadas para que el cliente las seleccione. From 70f61359a03b477ee0fcdf47b80ad67a5a80190a Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Thu, 15 Sep 2022 15:59:32 +0200 Subject: [PATCH 51/78] [es] Translated quic-tls.md --- es/quic-tls.md | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 es/quic-tls.md diff --git a/es/quic-tls.md b/es/quic-tls.md new file mode 100644 index 00000000..b5fdb067 --- /dev/null +++ b/es/quic-tls.md @@ -0,0 +1,10 @@ +# Las conexiones utilizan TLS + +Inmediatamente después del paquete inicial que establece una conexión, el +iniciador envía una trama criptográfica que comienza a configurar el handshake +de la capa segura. La capa de seguridad capa de seguridad utiliza la seguridad +TLS 1.3. + +No hay forma de optar por no utilizar TLS en una conexión QUIC. El protocolo +está diseñado para que sea difícil de manipular por las cajas intermedias, con +el fin de para ayudar a prevenir la osificación del protocolo. From 075ea25c08315629d87733987d2623f02cb09e7d Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Thu, 15 Sep 2022 16:04:24 +0200 Subject: [PATCH 52/78] [es] Translated quic-streams.md --- es/quic-streams.md | 75 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 75 insertions(+) create mode 100644 es/quic-streams.md diff --git a/es/quic-streams.md b/es/quic-streams.md new file mode 100644 index 00000000..852c6c41 --- /dev/null +++ b/es/quic-streams.md @@ -0,0 +1,75 @@ +# Flujos + +Los flujos en QUIC proporcionan una abstracción ligera y ordenada de flujos de +bytes. + +Hay dos tipos básicos de flujos en QUIC: + + - Los flujos unidireccionales transportan datos en una dirección: desde el + iniciador del flujo a su par. + + - Los flujos bidireccionales permiten el envío de datos en ambas direcciones. + +Cualquier tipo de flujo puede ser creado por cualquier end-point, puede enviar +datos simultáneamente intercalados con otros flujos, y puede ser cancelado. + +Para enviar datos a través de una conexión QUIC, se utilizan uno o más flujos. + +## Control de flujo + +Los flujos se controlan individualmente, lo que permite a un end-point limitar +el compromiso de memoria y aplicar presión de retorno. La creación de flujos +también está controlada por el flujo, con cada par declarando el máximo ID de +flujo que está dispuesto a aceptar en un momento dado. + +## Identificadores de flujos + +Los flujos se identifican mediante un número entero sin signo de 62 bits, +denominado ID del flujo. Los dos bits menos significativos del ID de flujo se +utilizan para identificar el tipo de flujo (unidireccional o bidireccional) y el +iniciador del flujo. + +El bit menos significativo (0x1) del ID de flujo identifica al iniciador del +flujo. Los clientes inician los flujos pares (los que tienen el bit menos +significativo en 0); los servidores inician los flujos impares (con el bit en +1). + +El segundo bit menos significativo (0x2) del ID del flujo diferencia entre los +flujos unidireccionales y los bidireccionales. Los flujos unidireccionales +siempre tienen este bit a 1 y los bidireccionales a 0. + +## Concurrencia de flujos + +QUIC permite que un número arbitrario de flujos operen simultáneamente. Un +end-point limita el número de flujos entrantes concurrentemente activos +limitando el ID máximo del flujo. + +El ID de flujo máximo es específico para cada end-point y se aplica sólo al +peer que recibe la configuración. + +## Envío y recepción de datos + +Los end-points utilizan flujos para enviar y recibir datos. Ese es, después de +todo, su propósito final. Los flujos son una abstracción ordenada de flujos de +bytes. Sin embargo, los flujos separados no se entregan necesariamente en el +orden original. + +## Priorización de flujos + +La multiplexación de flujos tiene un efecto significativo en el rendimiento de +la aplicación si los recursos asignados a los flujos se priorizan correctamente. +La experiencia con otros protocolos multiplexados, como HTTP/2, muestra que las +estrategias de priorización eficaces tienen un impacto positivo significativo en +el rendimiento. + +El propio QUIC no proporciona tramas para intercambiar información de +priorización. En su lugar, depende de la recepción de información de prioridad +de la aplicación que utiliza QUIC. Los protocolos que utilizan QUIC pueden +definir cualquier esquema de priorización que se adapte a la semántica de su +aplicación. + +Se ha criticado el modelo de priorización de HTTP/2, y se teme que sea demasiado +complejo y que no sea utilizado ni implementado por muchos servidores HTTP/2. +Por ahora, la priorización en HTTP/3 se ha eliminado de la especificación +principal de HTTP/3 y se está trabajando en ella como una [especificación +separada] (https://tools.ietf.org/html/draft-ietf-httpbis-priority). From bfb8dc730be45250356cc980c90f4dd2f6d145ab Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Thu, 15 Sep 2022 16:06:36 +0200 Subject: [PATCH 53/78] [es] Translated quic-0rtt.md --- es/quic-0rtt.md | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 es/quic-0rtt.md diff --git a/es/quic-0rtt.md b/es/quic-0rtt.md new file mode 100644 index 00000000..a14057f5 --- /dev/null +++ b/es/quic-0rtt.md @@ -0,0 +1,7 @@ +# 0-RTT + +Para reducir el tiempo necesario para establecer una nueva conexión, un cliente +que se ha conectado previamente a un servidor puede almacenar en caché ciertos +parámetros de esa conexión y posteriormente establecer una conexión **0-RTT** +con el servidor. Esto permite al cliente enviar datos inmediatamente sin esperar +a que se complete el handshake. From b704c0ee81fb5b010768ba5f98ccf991c2621837 Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Thu, 15 Sep 2022 16:09:16 +0200 Subject: [PATCH 54/78] [es] Translated quic-spinbit.md --- es/quic-spinbit.md | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 es/quic-spinbit.md diff --git a/es/quic-spinbit.md b/es/quic-spinbit.md new file mode 100644 index 00000000..44b4801f --- /dev/null +++ b/es/quic-spinbit.md @@ -0,0 +1,27 @@ +# Spin Bit + +Una de las discusiones de diseño quizás más largas dentro del grupo de trabajo +de QUIC que ha sido objeto de varios cientos de correos y horas de discusiones +se refiere a un solo bit: el Spin Bit. + +Los defensores de este bit insisten en la necesidad de que los operadores y las +personas que se encuentran en la ruta entre dos puntos finales de QUIC puedan +medir la latencia. + +A los que se oponen a esta característica no les gusta la posible fuga de +información. + +## Girando un poco + +Ambos end-points, el cliente y el servidor, mantienen un valor de giro, 0 o 1, +para cada conexión QUIC, y establecen el spin bit en los paquetes que envían +para esa conexión al valor apropiado. + +A continuación, ambos lados envían paquetes con ese bit de giro fijado al mismo +valor durante el tiempo que dura un viaje de ida y vuelta y luego se alterna el +valor. El efecto es entonces un pulso de unos y ceros en ese campo de bits que +los observadores pueden monitorizar. + +Esta medición sólo funciona cuando el emisor no está limitado por la aplicación +ni por el control de flujo, y la reordenación de los paquetes en la red también +puede hacer que los datos sean ruidosos. From 0e212b58297c47fcea0d8dbba8aad16927cc5d5b Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Thu, 15 Sep 2022 16:11:05 +0200 Subject: [PATCH 55/78] [es] Translated quic-userspace.md --- es/quic-userspace.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 es/quic-userspace.md diff --git a/es/quic-userspace.md b/es/quic-userspace.md new file mode 100644 index 00000000..56ca808f --- /dev/null +++ b/es/quic-userspace.md @@ -0,0 +1,17 @@ +## Espacio de usuario + +Implementar un protocolo de transporte en el espacio de usuario ayuda a permitir +una rápida iteración del protocolo, ya que es comparativamente fácil evolucionar +el protocolo sin necesidad de que los clientes y servidores actualicen el núcleo +de su sistema operativo para desplegar nuevas versiones. + +Nada inherente a QUIC impide que sea implementado y ofrecido por los kernels de +los sistemas operativos en el futuro, si a alguien le parece una buena idea. + +### Muchas implementaciones + +Un efecto obvio de implementar un nuevo protocolo de transporte en el espacio de +usuario es que podemos esperar ver muchas implementaciones independientes. + +Es probable que diferentes aplicaciones incluyan (o se superpongan) diferentes +implementaciones de HTTP/3 y QUIC en un futuro previsible. From 71eb2daf3ad42a4f4e492b2c9390cb6d4314e09a Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Thu, 15 Sep 2022 16:12:29 +0200 Subject: [PATCH 56/78] [es] Translated quic-api.md --- es/quic-api.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 es/quic-api.md diff --git a/es/quic-api.md b/es/quic-api.md new file mode 100644 index 00000000..c9f32068 --- /dev/null +++ b/es/quic-api.md @@ -0,0 +1,18 @@ +# API + +Uno de los factores de éxito de TCP regular y de los programas que lo utilizan, +es la API de sockets estandarizada. Tiene una funcionalidad bien definida y +usando esta API puedes mover programas entre muchos sistemas operativos +diferentes ya que TCP funciona el mismo. + +QUIC no está ahí. No hay una API estándar para QUIC. + +Con QUIC, tienes que elegir una de las implementaciones de bibliotecas +existentes y y seguir su API. Esto hace que las aplicaciones estén "encerradas" +en una sola biblioteca hasta una sola biblioteca. Cambiar a otra biblioteca +significa otra API y eso podría implicar mucho trabajo. + +Además, como QUIC se implementa normalmente en el espacio de usuario, no puede +fácilmente extender la API del socket o aparecer de forma similar a la +funcionalidad existente de TCP y UDP. existentes. Usar QUIC significará usar +otra API además de la API de sockets. From 56d1a20f28ee7546e286645ca21c61f82f9d71e1 Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Fri, 16 Sep 2022 09:25:43 +0200 Subject: [PATCH 57/78] [es] Translated h3.md --- es/h3.md | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) create mode 100644 es/h3.md diff --git a/es/h3.md b/es/h3.md new file mode 100644 index 00000000..cfbf2358 --- /dev/null +++ b/es/h3.md @@ -0,0 +1,29 @@ +# HTTP/3 + +Como se ha mencionado anteriormente, el primer y principal protocolo que se +transporta a través de QUIC es HTTP. + +Al igual que HTTP/2 se introdujo en su día para transportar HTTP por el cable de +una forma completamente nueva, HTTP/3 vuelve a introducir una nueva forma de +enviar HTTP por la red. + +HTTP sigue manteniendo los mismos paradigmas y conceptos que antes. Hay +cabeceras y un cuerpo, hay una petición y una respuesta. Hay verbos, cookies y +caché. Lo que cambia principalmente con HTTP/3 es cómo se envían los bits al +otro lado de la comunicación. + +Para hacer HTTP sobre QUIC, fueron necesarios cambios y el resultado de esto es +lo que ahora llamamos HTTP/3. Estos cambios fueron necesarios debido a la +diferente naturaleza que QUIC proporciona en comparación con TCP. Estos cambios +incluyen: + + - En QUIC los flujos son proporcionados por el propio transporte, mientras que + en HTTP/2 los flujos se hacían dentro de la capa HTTP. + + - Debido a que los flujos son independientes unos de otros, el protocolo de + compresión de cabecera utilizado para HTTP/2 no podía ser utilizado sin que + causara una situación de cabeza de bloque. + + - Los flujos QUIC son ligeramente diferentes a los flujos HTTP/2. La sección + de HTTP/3 lo detallará un poco. + \ No newline at end of file From 041c73ff4a8aa11a848697c1e6d02199e5abeef3 Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Fri, 16 Sep 2022 09:26:07 +0200 Subject: [PATCH 58/78] [es] Translated h3-https.md --- es/h3-https.md | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 es/h3-https.md diff --git a/es/h3-https.md b/es/h3-https.md new file mode 100644 index 00000000..c8fcc1cb --- /dev/null +++ b/es/h3-https.md @@ -0,0 +1,30 @@ +# URLs HTTPS:// + +HTTP/3 se realizará utilizando URLs `HTTPS://`. El mundo está lleno de estas +URLs y se ha considerado poco práctico y francamente irrazonable introducir +otro esquema de URL para el nuevo protocolo. Al igual que HTTP/2 no necesitaba +un nuevo esquema, tampoco lo necesitará HTTP/3. + +La complejidad añadida en la situación de HTTP/3 es, sin embargo, que mientras +HTTP/2 era una forma completamente nueva de transportar HTTP a través del +cable, seguía basándose en TLS y TCP como lo hacía HTTP/1. El hecho de que +HTTP/3 se realice sobre QUIC cambia las cosas en algunos aspectos importantes. + +Las URLs heredadas, de texto claro, `HTTP://` se dejarán como están y, a medida +que avancemos hacia un futuro con transferencias más seguras, probablemente se +utilizarán cada vez con menos frecuencia. Las peticiones a estas URLs +simplemente no se actualizarán para utilizar HTTP/3. En realidad tampoco se +actualizan a HTTP/2, pero por otras razones. + +## Conexión inicial + +La primera conexión a un host nuevo, no visitado previamente, para una URL +HTTPS:// probablemente tenga que hacerse sobre TCP (posiblemente además de un +intento paralelo de conexión vía QUIC). El host puede ser un servidor heredado +sin soporte para QUIC o puede haber una caja intermedia que ponga obstáculos +que impidan el éxito de una conexión QUIC. + +Un cliente y un servidor modernos presumiblemente negociarían HTTP/2 en el +primer apretón de manos. Cuando la conexión se haya establecido y el servidor +responda a una petición HTTP del cliente, el servidor puede informar al cliente +sobre su soporte y preferencia por HTTP/3. From a1df9daa5c51c14c7f5a2cdc0cdfec6c66f586c6 Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Fri, 16 Sep 2022 09:26:29 +0200 Subject: [PATCH 59/78] [es] Translated h3-altsvc.md --- es/h3-altsvc.md | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 es/h3-altsvc.md diff --git a/es/h3-altsvc.md b/es/h3-altsvc.md new file mode 100644 index 00000000..8adb7657 --- /dev/null +++ b/es/h3-altsvc.md @@ -0,0 +1,34 @@ +# Alt-svc + +La cabecera de servicio alternativo (Alt-svc:) y su correspondiente trama +`ALT-SVC` HTTP/2 no han sido creadas específicamente para QUIC o HTTP/3. Son +parte de un mecanismo ya diseñado y creado para que un servidor le diga a un +cliente: *"mira, ejecuto el mismo servicio en ESTE HOST usando ESTE PROTOCOLO +en ESTE PUERTO "*. Vea los detalles en [RFC +7838](https://tools.ietf.org/html/rfc7838). + +Un cliente que reciba tal respuesta Alt-svc es entonces aconsejado para, si lo +soporta y lo desea, conectarse a ese otro host en paralelo en segundo plano - +usando el protocolo especificado - y si tiene éxito cambiar sus operaciones a +eso en lugar de la conexión inicial. + +Si la conexión inicial utiliza HTTP/2 o incluso HTTP/1, el servidor puede +responder e indicar al cliente que puede volver a conectarse e intentar HTTP/3. +Puede ser al mismo host o a otro que sepa servir ese origen. La información +dada en una respuesta Alt-svc de este tipo tiene un temporizador de caducidad, +lo que hace que los clientes puedan dirigir las siguientes conexiones y +peticiones directamente al host alternativo utilizando el protocolo alternativo +sugerido, durante un determinado periodo de tiempo. + +## Ejemplo + +Un servidor HTTP incluye una cabecera `Alt-Svc:` en su respuesta: + + Alt-Svc: h3=":50781" + +Esto indica que HTTP/3 está disponible en el puerto UDP 50781 en el mismo nombre +de host que se utilizó para obtener esta respuesta. + +Un cliente puede entonces intentar establecer una conexión QUIC con ese destino +y, si tiene éxito, seguir comunicándose con el origen así en lugar de con la +versión HTTP inicial. From 59c8db0ebf4967d719f6d1b672df5a1039be41f3 Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Fri, 16 Sep 2022 09:26:49 +0200 Subject: [PATCH 60/78] [es] Translated h3-streams.md --- es/h3-streams.md | 46 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 es/h3-streams.md diff --git a/es/h3-streams.md b/es/h3-streams.md new file mode 100644 index 00000000..b3af3319 --- /dev/null +++ b/es/h3-streams.md @@ -0,0 +1,46 @@ +# Flujos de QUIC y HTTP/3 + +HTTP/3 está hecho para QUIC, por lo que aprovecha al máximo los flujos de QUIC, +mientras que HTTP/2 tuvo que diseñar su propio concepto de flujo y +multiplexación sobre TCP. + +Las peticiones HTTP realizadas sobre HTTP/3 utilizan un conjunto específico de +flujos. + +## Tramas de HTTP/3 + +HTTP/3 implica la creación de flujos QUIC y el envío de un conjunto de tramas al +otro extremo. Sólo hay un pequeño número fijo (¡en realidad nueve al 18 de +diciembre de 2018!) de tramas conocidas en HTTP/3. Las más importantes son +probablemente + +- HEADERS, que envía cabeceras HTTP comprimidas +- DATA, envía contenidos de datos binarios +- GOAWAY, que cierra esta conexión + +## Solicitud HTTP + +El cliente envía su petición HTTP en un flujo QUIC *bidireccional* iniciado por +el cliente. + +Una petición consiste en una única trama HEADERS y, opcionalmente, puede ir +seguida de una o dos tramas más: una serie de tramas DATA y posiblemente una +última trama HEADERS para los trailers. + +Después de enviar una petición, un cliente cierra el flujo para su envío. + +## Respuesta HTTP + +El servidor devuelve su respuesta HTTP en el flujo bidireccional. Una trama +HEADERS, una serie de tramas DATA y posiblemente una trama HEADERS final. + +## Cabeceras QPACK + +Las tramas HEADERS contienen cabeceras HTTP comprimidas mediante el algoritmo +QPACK. QPACK es similar en estilo a la compresión HTTP/2 llamada HPACK ( +[RFC 7541](https://httpwg.org/specs/rfc7541.html)), pero modificada para +trabajar con flujos entregados fuera de orden. + +QPACK utiliza dos flujos QUIC unidireccionales adicionales entre los dos puntos +finales. Se utilizan para transportar información de la tabla dinámica en +cualquier dirección. From e655f18941de7775eade55f9a1418c04d04873d6 Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Fri, 16 Sep 2022 09:27:19 +0200 Subject: [PATCH 61/78] [es] Translated h3-prio.md --- es/h3-prio.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 es/h3-prio.md diff --git a/es/h3-prio.md b/es/h3-prio.md new file mode 100644 index 00000000..6edcc538 --- /dev/null +++ b/es/h3-prio.md @@ -0,0 +1,24 @@ +# Priorización de HTTP/3 + +Como se ha mencionado anteriormente, la priorización entre flujos se ha +eliminado de la especificación principal de HTTP/3 para trabajar en ella por +separado. + +Esto se debe a lo aprendido del modelo de priorización de HTTP/2 y su +implementación (o falta de ella) en el mundo real. + +Se ha propuesto un [modelo de priorización más sencillo que el de HTTP/2] +(https://tools.ietf.org/html/draft-ietf-httpbis-priority) que utiliza campos de +cabecera HTTP con un número limitado de ajustes de prioridad. Se trata de un +cambio clave con respecto a los indicadores de dependencia y peso en los marcos +de cabecera de HTTP/2 y permite una mejor comprensión en la capa de +aplicación. + +La repriorización, y la posibilidad de apoyarla, todavía se está debatiendo. +HTTP/2 tenía marcos de priorización para manejar esto, pero los verdaderos +flujos independientes en QUIC y HTTP/3 hacen que esto sea más complicado, por +lo que todavía se están debatiendo los beneficios frente a la complejidad. + +Cuando se acuerde (¡o si se acuerda!) un mejor modelo de priorización para +HTTP/3, se espera poder trasladarlo también a HTTP/2, para resolver la +complejidad y los problemas de implementación. From b7526f76132e611207ef779561a2efd426fe459f Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Fri, 16 Sep 2022 09:27:37 +0200 Subject: [PATCH 62/78] [es] Translated h3-push.md --- es/h3-push.md | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 es/h3-push.md diff --git a/es/h3-push.md b/es/h3-push.md new file mode 100644 index 00000000..348e54c7 --- /dev/null +++ b/es/h3-push.md @@ -0,0 +1,34 @@ +# Push del servidor HTTP/3 + +HTTP/3 server push es similar a lo descrito en HTTP/2 ([RFC 7540] +(https://httpwg.org/specs/rfc7540.html)), pero utiliza mecanismos diferentes. + +Un push de servidor es efectivamente la respuesta a una petición que el cliente +nunca envió. + +Los push del servidor sólo se permiten si la parte del cliente los ha aceptado. +En HTTP/3 el cliente incluso establece un límite para el número de pushes que +acepta, informando al servidor de cuál es el ID máximo del flujo de push. +Sobrepasar ese límite provocará un error de conexión. + +Si el servidor considera probable que el cliente quiera un recurso extra que no +ha pedido pero que debería tener de todas formas, puede enviar una trama +`PUSH_PROMISE` (sobre el flujo de petición) mostrando cómo es la petición a la +que el push es una respuesta, y luego enviar esa respuesta real sobre un nuevo +flujo. + +Aunque el cliente haya dicho que los envíos son aceptables de antemano, cada +flujo individual enviado puede ser cancelado en cualquier momento si el cliente +lo considera conveniente. Entonces envía una trama `CANCEL_PUSH` al servidor. + +## Problemática + +Desde que esta característica se discutió por primera vez en el desarrollo de +HTTP/2 y más tarde después de que el protocolo se enviara y se desplegara en +Internet, esta característica se ha discutido, no ha gustado y se ha machacado +de innumerables maneras diferentes con el fin de conseguir que sea útil. + +El push nunca es "gratuito", ya que, aunque ahorra medio viaje de ida y +vuelta, sigue utilizando ancho de banda. A menudo es difícil o imposible para +el servidor saber con un alto nivel de certeza si un recurso debe ser enviado +por push o no. From 3d3ef4cada1a81bf4694dd620703fe49440fbad6 Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Fri, 16 Sep 2022 09:27:55 +0200 Subject: [PATCH 63/78] [es] Translated h3-h2.md --- es/h3-h2.md | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 es/h3-h2.md diff --git a/es/h3-h2.md b/es/h3-h2.md new file mode 100644 index 00000000..f0c566b4 --- /dev/null +++ b/es/h3-h2.md @@ -0,0 +1,43 @@ +# HTTP/3 comparado con HTTP/2 + +HTTP/3 está diseñado para QUIC, que es un protocolo de transporte que maneja +flujos por sí mismo. + +HTTP/2 está diseñado para TCP, y por lo tanto maneja flujos en la capa HTTP. + +## Similitudes + +Los dos protocolos ofrecen a los clientes conjuntos de características +prácticamente idénticos. + +- Ambos protocolos ofrecen soporte para el push del servidor + +- Ambos protocolos tienen compresión de cabecera, y QPACK y HPACK tienen un + diseño similar. + +- Ambos protocolos ofrecen multiplexación a través de una única conexión + utilizando streams + +## Diferencias + +Las diferencias están en los detalles y principalmente están ahí gracias al uso +de QUIC por parte de HTTP/3: + +- HTTP/3 tiene un mejor y más probable soporte de datos tempranos gracias a los + handshakes 0-RTT de QUIC, mientras que TCP Fast Open y TLS suelen enviar + menos datos y a menudo tienen problemas. + +- HTTP/3 tiene handshakes mucho más rápidos gracias a QUIC frente a TCP + TLS. + +- HTTP/3 no existe en una versión insegura o sin cifrar. HTTP/2 puede ser + implementado y utilizado sin HTTPS - aunque esto es raro en Internet. + +- HTTP/2 puede ser negociado directamente en un handshake TLS con la extensión + ALPN, mientras que HTTP/3 es sobre QUIC por lo que necesita una respuesta de + cabecera `Alt-Svc:` primero para informar al cliente sobre este hecho. + +- HTTP/3 no tiene priorización. El enfoque de HTTP/2 para la priorización se ha + considerado demasiado complicado, o incluso un fracaso, y se está trabajando + en la creación de una toma más simple. Este esquema más simple planeado + también está planeado para poder ser retroportado para correr sobre HTTP/2 + usando el mecanismo de extensión de HTTP/2. From ec35c256d68fbcdd7fc380bf7a3c6ad5879bbfa8 Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Fri, 16 Sep 2022 09:33:49 +0200 Subject: [PATCH 64/78] [es] Translated criticism.md --- es/criticism.md | 63 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 63 insertions(+) create mode 100644 es/criticism.md diff --git a/es/criticism.md b/es/criticism.md new file mode 100644 index 00000000..a5257e72 --- /dev/null +++ b/es/criticism.md @@ -0,0 +1,63 @@ +# Crítica + +## UDP nunca funcionará + +Muchas empresas, operadores y organizaciones bloquean o limitan el tráfico UDP +fuera del puerto 53 (utilizado para DNS) ya que en los últimos días se ha +abusado de él para realizar ataques. En particular, algunos de los protocolos +UDP existentes y las implementaciones de servidores populares para ellos han +sido vulnerables a los ataques de amplificación en los que un atacante puede +hacer una gran cantidad de tráfico saliente para atacar a víctimas inocentes. + +QUIC tiene una mitigación incorporada contra los ataques de amplificación al +requerir que el paquete inicial sea de al menos 1200 bytes y mediante una +restricción en el protocolo que dice que un servidor no debe enviar más de tres +veces el tamaño de la solicitud en respuesta sin recibir un paquete del cliente +en respuesta. + +## UDP es lento en los núcleos + +Esto parece ser la verdad, al menos inicialmente. Por supuesto, no podemos saber +cómo evolucionará esto y cuánto de esto es simplemente el resultado de que el +rendimiento de la transferencia UDP no ha estado en el foco de los +desarrolladores durante muchos años. + +Para la mayoría de los clientes, es probable que esta "lentitud" ni siquiera se +note. + +## QUIC consume demasiada CPU + +Al igual que la observación anterior de que "UDP es lento", esto se debe en +parte a que el uso de TCP y TLS en el mundo ha tenido más tiempo para madurar, +mejorar y obtener asistencia de hardware. + +Hay razones para esperar que esto mejore con el tiempo, y ya [estamos viendo +algunas mejoras en este espacio] +(https://www.fastly.com/blog/measuring-quic-vs-tcp-computational-efficiency). +La cuestión es hasta qué punto este uso adicional de la CPU perjudicará a los +implantadores. + +## Esto es sólo Google + +No, no lo es. Google llevó la especificación inicial al IETF después de haber +demostrado, a gran escala en Internet, que el despliegue de este estilo de +protocolo sobre UDP realmente funciona y tiene un buen rendimiento. + +Desde entonces, personas de un gran número de empresas y organizaciones han +trabajado en la organización neutral de proveedores IETF para elaborar un +protocolo de transporte estándar a partir de él. En ese trabajo, los empleados +de Google han participado, por supuesto, pero también lo han hecho los +empleados de un gran número de otras empresas que están interesadas en promover +el estado de los protocolos de transporte en Internet, como Mozilla, Fastly, +Cloudflare, Akamai, Microsoft, Facebook y Apple. + +## Es una mejora demasiado pequeña + +Esto no es realmente una crítica, sino una opinión. Tal vez lo sea, y tal vez +sea una mejora demasiado pequeña desde que se lanzó HTTP/2. + +Es probable que HTTP/3 funcione mucho mejor en redes con pérdida de paquetes, +ofrece handshakes más rápidos, por lo que mejorará la latencia tanto percibida +como real. Pero, ¿es esto suficiente para motivar a la gente a desplegar el +soporte de HTTP/3 en sus servidores y servicios? El tiempo y las futuras +mediciones de rendimiento seguramente lo dirán. From 47c436ab039da0906e07ad12879c37aa3c68a3a6 Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Fri, 16 Sep 2022 09:34:03 +0200 Subject: [PATCH 65/78] [es] Translated specs.md --- es/specs.md | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 es/specs.md diff --git a/es/specs.md b/es/specs.md new file mode 100644 index 00000000..f212eeed --- /dev/null +++ b/es/specs.md @@ -0,0 +1,34 @@ +# Las especificaciones + +Aquí hay una colección de los últimos borradores oficiales para las distintas +partes y componentes de QUIC y HTTP/3. + +## Invariantes + +[Propiedades independientes de la versión de +QUIC](https://tools.ietf.org/html/draft-ietf-quic-invariants) + +## Transporte + +[QUIC: A UDP-Based Multiplexed and Secure +Transport](https://tools.ietf.org/html/draft-ietf-quic-transport) + +## Recuperación + +[Detección de Pérdidas y Control de Congestión de +QUIC](https://tools.ietf.org/html/draft-ietf-quic-recovery) + +## TLS + +[Usando TLS para asegurar +QUIC](https://tools.ietf.org/html/draft-ietf-quic-tls) + +## HTTP + +[Protocolo de Transferencia de Hipertexto Versión 3 +(HTTP/3)](https://tools.ietf.org/html/draft-ietf-quic-http) + +## QPACK + +[QPACK: Compresión de cabeceras para +HTTP/3](https://tools.ietf.org/html/draft-ietf-quic-qpack) From b64c8597b539893035173ec3bfb819595cc1ac56 Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Fri, 16 Sep 2022 09:34:17 +0200 Subject: [PATCH 66/78] [es] Translated quic-v2.md --- es/quic-v2.md | 47 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 es/quic-v2.md diff --git a/es/quic-v2.md b/es/quic-v2.md new file mode 100644 index 00000000..566dfca4 --- /dev/null +++ b/es/quic-v2.md @@ -0,0 +1,47 @@ +# QUIC v2 + +Con el fin de conseguir el mayor enfoque posible en el núcleo del protocolo QUIC +y ser capaz de enviarlo a tiempo, varias características que fueron +originalmente planificadas para ser parte del núcleo del protocolo se han +pospuesto y ahora están previstas para ser realizadas en una versión posterior +de QUIC. QUIC versión 2 o posterior. + +Sin embargo, el autor de este documento tiene una bola de cristal bastante +defectuosa, por lo que no podemos decir con seguridad qué características +aparecerán o no en la versión 2. Sin embargo, podemos mencionar algunas de las +características y cosas que explícitamente han sido eliminadas del trabajo de +la v1 para ser "trabajadas más tarde" y que entonces posiblemente podrían +aparecer en una versión 2. + +## Corrección de errores hacia delante + +La corrección de errores hacia adelante (FEC) es un método para obtener el +control de errores en la transmisión de datos en el que el transmisor envía +datos redundantes y el receptor reconoce sólo la parte de los datos que no +contiene errores aparentes. + +Google experimentó con esto en su trabajo original de QUIC, pero posteriormente +se eliminó de nuevo ya que los experimentos no salieron bien. Esta +característica es objeto de discusión para QUIC v2 pero probablemente se +necesita que alguien demuestre que realmente puede ser una adición útil sin +demasiada penalización. + +## Multipath + +Multipath significa que el transporte puede por sí mismo utilizar múltiples +rutas de red para maximizar el uso de recursos y aumentar la redundancia. + +A los defensores de SCTP del mundo les gusta mencionar que SCTP ya cuenta con +multipath y también lo hace el TCP moderno. + +## Datos no fiables + +Se ha discutido la posibilidad de ofrecer flujos "no fiables" como opción, lo +que permitiría a QUIC sustituir también a las aplicaciones de tipo UDP. + +## Adaptaciones no-HTTP + +DNS sobre QUIC fue uno de los primeros protocolos no-HTTP mencionados que podría +recibir algo de atención una vez que QUIC v1 y HTTP/3 sean lanzados. Pero con +un nuevo transporte como este que se ha traído al mundo no puedo imaginar que +se detenga ahí. From 045cde724db9a056125d52aabb23dc7063ef3734 Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Fri, 16 Sep 2022 09:48:00 +0200 Subject: [PATCH 67/78] [es] [Summary] Added Spanish sections --- SUMMARY.md | 41 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) diff --git a/SUMMARY.md b/SUMMARY.md index 94532cf3..2b773d72 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -39,6 +39,47 @@ * [The specifications](en/specs.md) * [QUIC v2](en/quic-v2.md) +* [Español](es/README.md) + * [Por qué QUIC](es/why-quic.md) + * [¿Te acuerdas de HTTP/2?](es/why-h2.md) + * [Bloqueo de cabeza de línea TCP](es/why-tcphol.md) + * [TCP o UDP](es/why-tcpudp.md) + * [Osificación](es/why-ossification.md) + * [Seguro](es/why-secure.md) + * [Datos tempranos](es/why-latency.md) + * [Proceso](es/proc.md) + * [IETF](es/proc-ietf.md) + * [La experiencia de HTTP/2](es/proc-h2.md) + * [Estado](es/proc-status.md) + * [Características del protocolo](es/the-protocol.md) + * [UDP](es/feature-udp.md) + * [Transferencias de datos fiables](es/feature-reliable.md) + * [Flujos múltiples](es/feature-streams.md) + * [Entrega en orden](es/feature-inorder.md) + * [Rápido establecimiento de comunicación](es/feature-handshakes.md) + * [TLS 1.3](es/feature-tls.md) + * [Nivel de transporte y aplicación](es/feature-trans-app.md) + * [HTTP/3 sobre QUIC](es/feature-http.md) + * [No-HTTP sobre QUIC](es/feature-nonhttp.md) + * [Cómo funciona QUIC](es/quic.md) + * [Conexiones](es/quic-connections.md) + * [TLS](es/quic-tls.md) + * [Flujos](es/quic-streams.md) + * [0-RTT](es/quic-0rtt.md) + * [Spin Bit](es/quic-spinbit.md) + * [Espacio de usuario](es/quic-userspace.md) + * [API](es/quic-api.md) + * [HTTP/3](es/h3.md) + * [HTTPS:// URLs](es/h3-https.md) + * [Bootstrap with Alt-svc](es/h3-altsvc.md) + * [QUIC streams and HTTP/3](es/h3-streams.md) + * [Prioritization](es/h3-prio.md) + * [Server push](es/h3-push.md) + * [Comparison with HTTP/2](es/h3-h2.md) + * [Common criticism](es/criticism.md) + * [The specifications](es/specs.md) + * [QUIC v2](es/quic-v2.md) + * [Deutsch](de/README.md) * [Warum QUIC](de/why-quic.md) * [Erinnerst du dich an HTTP/2?](de/why-h2.md) From 3cbfaec809157d528d5559be2559e17faf6cc86c Mon Sep 17 00:00:00 2001 From: Marcos Medrano Date: Fri, 16 Sep 2022 09:54:51 +0200 Subject: [PATCH 68/78] [es] [Summary] Translated last sections --- SUMMARY.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/SUMMARY.md b/SUMMARY.md index 2b773d72..5ffc7a18 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -71,13 +71,13 @@ * [API](es/quic-api.md) * [HTTP/3](es/h3.md) * [HTTPS:// URLs](es/h3-https.md) - * [Bootstrap with Alt-svc](es/h3-altsvc.md) - * [QUIC streams and HTTP/3](es/h3-streams.md) - * [Prioritization](es/h3-prio.md) - * [Server push](es/h3-push.md) - * [Comparison with HTTP/2](es/h3-h2.md) - * [Common criticism](es/criticism.md) - * [The specifications](es/specs.md) + * [Alt-svc](es/h3-altsvc.md) + * [Flujos de QUIC y HTTP/3](es/h3-streams.md) + * [Priorización](es/h3-prio.md) + * [Push del servidor](es/h3-push.md) + * [Comparación con HTTP/2](es/h3-h2.md) + * [Críticas habituales](es/criticism.md) + * [Especificaciones](es/specs.md) * [QUIC v2](es/quic-v2.md) * [Deutsch](de/README.md) From 910d0add710121291161eefea7dbd686bc3a0b93 Mon Sep 17 00:00:00 2001 From: Sumanth Date: Mon, 26 Dec 2022 04:31:28 +0530 Subject: [PATCH 69/78] Updated proc-ietf.md to add QUIC published date (#232) Updated proc-ietf.md to update the QUIC protocol published date. It was not known when this topic was previously written or updated. --- en/proc-ietf.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/en/proc-ietf.md b/en/proc-ietf.md index f55bba5d..9d148fc7 100644 --- a/en/proc-ietf.md +++ b/en/proc-ietf.md @@ -21,7 +21,8 @@ and ability to deliver QUIC version 1 on time, it would focus on delivering HTTP, leaving non-HTTP transports to later work. In March 2018 when we started working on this book, the plan was to ship the -final specification for QUIC version 1 in November 2018 but this has been postponed a number of times and, at the time of writing (June 2020), is entering final stages. +final specification for QUIC version 1 in November 2018 but this has been postponed a number of times. +The IETF QUIC protocol was standardized and published in May 2021 as [RFC 9000](https://www.rfc-editor.org/rfc/rfc9000.html). While the work on IETF-QUIC has progressed, the Google team has incorporated details from the IETF version and has started to slowly progress their version From 0476ac09004c8fee50b87c338a9d52a90ec04649 Mon Sep 17 00:00:00 2001 From: lucas Date: Thu, 4 May 2023 05:30:54 +0100 Subject: [PATCH 70/78] Tidy up text related to prioritization now that we have RFC 9218 --- en/h3-h2.md | 11 +++++++---- en/h3-prio.md | 31 +++++++++++++------------------ en/quic-streams.md | 10 +++++----- 3 files changed, 25 insertions(+), 27 deletions(-) diff --git a/en/h3-h2.md b/en/h3-h2.md index 263992d1..e9b88d7f 100644 --- a/en/h3-h2.md +++ b/en/h3-h2.md @@ -34,7 +34,10 @@ of QUIC: extension, while HTTP/3 is over QUIC so it needs an `Alt-Svc:` header response first to inform the client about this fact. -- HTTP/3 has no prioritization. The HTTP/2 approach to prioritization has been - deemed too complicated, or even a downright failure, and there's work on - creating a simpler take. This planned simpler scheme is also planned to be - able so backport to run over HTTP/2 using HTTP/2's extension mechanism. +- The base HTTP/3 specification doesn't define prioritization itself. The HTTP/2 + approach to prioritization has been deemed too complicated and is deprecated + by the latest revision of the HTTP/2 specification [RFC + 9113](https://www.rfc-editor.org/rfc/rfc9113.html). A simpler alternative, the + Extensible Prioritization Scheme for HTTP ([RFC + 9218](https://www.rfc-editor.org/rfc/rfc9218.html)), has been published + separately, which can be used in both HTTP/2 and HTTP/3. diff --git a/en/h3-prio.md b/en/h3-prio.md index ef14c371..a0d0fd17 100644 --- a/en/h3-prio.md +++ b/en/h3-prio.md @@ -1,21 +1,16 @@ # HTTP/3 Prioritization -As mentioned previously, priorisation between streams has been removed from the -main HTTP/3 specification to be worked on separately. +The base HTTP/3 specification doesn't define prioritization itself. The HTTP/2 +approach to prioritization has been deemed too complicated and is deprecated by +the latest revision of the HTTP/2 specification [RFC +9113](https://www.rfc-editor.org/rfc/rfc9113.html). A simpler alternative, the +Extensible Prioritization Scheme for HTTP ([RFC +9218](https://www.rfc-editor.org/rfc/rfc9218.html)), has been published +separately, which can be used in both HTTP/2 and HTTP/3. -This was due to learnings from the HTTP/2 prioritisation model and its -implementation (or lack there of) in the real world. - -A [simpler prioritisation model than HTTP/2 has been proposed](https://tools.ietf.org/html/draft-ietf-httpbis-priority) -using HTTP header fields with a limited number of priority settings. This is a -key change from the Dependency and Weight flags in the HTTP/2 Header frames and -allows better understanding at the application layer. - -Reprioritisation, and whether to support this, is still being discussed. HTTP/2 -had Prioritisation frames to handle this but the true independent streams in QUIC -and HTTP/3 makes this more complicated so the benefits versus the complexity are -still being debated. - -When (or if!) a better prioritisation model is agreed for HTTP/3 it is hoped to -be able to backport this to HTTP/2 too, to address the complexity and -implementation concerns there. +In HTTP/3, priority signals are sent in the form of the Priority header field +and/or the PRIORITY_UPDATE frame sent on the HTTP/3 Control Stream. Servers can +act on these signals to schedule sending of HTTP response content. +[RFC +9218](https://www.rfc-editor.org/rfc/rfc9218.html) provides scheduling guidance +that is intended to improve client web application performance. diff --git a/en/quic-streams.md b/en/quic-streams.md index 72c0551e..576ee7fb 100644 --- a/en/quic-streams.md +++ b/en/quic-streams.md @@ -59,12 +59,12 @@ resources allocated to streams are correctly prioritized. Experience with other multiplexed protocols, such as HTTP/2, shows that effective prioritization strategies have a significant positive impact on performance. -QUIC itself does not provide frames for exchanging prioritization information. +QUIC itself does not provide signals for exchanging prioritization information. Instead it relies on receiving priority information from the application that uses QUIC. Protocols that use QUIC are able to define any prioritization scheme that suits their application semantics. -There have been criticisms of the HTTP/2 prioritisation model, and concerns it -is overly complex and not used and implemented by many HTTP/2 servers. For now -prioritisation in HTTP/3 has been removed from the main HTTP/3 specification -and is being worked on as a [separate specification](https://tools.ietf.org/html/draft-ietf-httpbis-priority). +The Extensible Prioritization Scheme for HTTP ([RFC +9218](https://www.rfc-editor.org/rfc/rfc9218.html)) can be used for HTTP/3. It +defines signals and provides scheduling guidance. This scheme is simpler than +the original one defined for HTTP/2. From b17b12c36383e0cd22cb693a1488192cfa1d0ba8 Mon Sep 17 00:00:00 2001 From: Axel Beckert Date: Fri, 18 Feb 2022 07:30:26 +0100 Subject: [PATCH 71/78] Grammar fix: German has no genitive apostrophe --- de/proc.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/de/proc.md b/de/proc.md index d0139bab..956b0a52 100644 --- a/de/proc.md +++ b/de/proc.md @@ -1,6 +1,6 @@ # Prozess -Das ursprüngliche QUIC Protokoll wurde von Jim Roskind bei Google entworfen, im Jahr 2012 erstmals implementiert und der Welt 2013 vorgestellt, als Google's Experiment erweitert wurde. +Das ursprüngliche QUIC Protokoll wurde von Jim Roskind bei Google entworfen, im Jahr 2012 erstmals implementiert und der Welt 2013 vorgestellt, als Googles Experiment erweitert wurde. Damals galt QUIC noch als Akronym für "Quick UDP Internet Connections", aber das wurde seitdem eingestellt. @@ -8,4 +8,4 @@ Google implementierte das Protokoll und nutzte es anschließend sowohl in seinem Im Juni 2015 wurde der erste Internetentwurf von QUIC zur Standardisierung an die IETF übermittelt. Es dauerte jedoch bis Ende 2016, bis eine QUIC-Arbeitsgruppe genehmigt und gestartet wurde. Aber dann ist es mit großem Interesse von vielen Parteien sofort losgegangen. -Im Jahr 2017 gaben die QUIC-Ingenieuren bei Google an, dass rund 7% des *gesamten* Internetverkehrs bereits das Protokoll verwenden. Die Google-Version des Protokolls. \ No newline at end of file +Im Jahr 2017 gaben die QUIC-Ingenieuren bei Google an, dass rund 7% des *gesamten* Internetverkehrs bereits das Protokoll verwenden. Die Google-Version des Protokolls. From b97769ebfcdda0821f5726531a9daf8f3e6a5045 Mon Sep 17 00:00:00 2001 From: Daniel Stenberg Date: Sat, 19 Aug 2023 20:11:51 +0200 Subject: [PATCH 72/78] en/quic-v2.md: v2 already exists All the section "QUIC future" instead. Fixes #235 Report-by: Martin Thomson --- SUMMARY.md | 2 +- en/{quic-v2.md => quic-future.md} | 14 +++++++------- 2 files changed, 8 insertions(+), 8 deletions(-) rename en/{quic-v2.md => quic-future.md} (81%) diff --git a/SUMMARY.md b/SUMMARY.md index 5ffc7a18..0ad7663c 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -37,7 +37,7 @@ * [Comparison with HTTP/2](en/h3-h2.md) * [Common criticism](en/criticism.md) * [The specifications](en/specs.md) - * [QUIC v2](en/quic-v2.md) + * [QUIC future](en/quic-future.md) * [Español](es/README.md) * [Por qué QUIC](es/why-quic.md) diff --git a/en/quic-v2.md b/en/quic-future.md similarity index 81% rename from en/quic-v2.md rename to en/quic-future.md index 8a446ddd..56fa66d6 100644 --- a/en/quic-v2.md +++ b/en/quic-future.md @@ -1,15 +1,15 @@ -# QUIC v2 +# QUIC future In order to get the most possibly focus on the core QUIC protocol and be able to ship it on time, several features that were originally planned to be part of the core protocol have been postponed and are now planned to instead get -done in a subsequent QUIC version. QUIC version 2 or beyond. +done in a subsequent QUIC version. The author of this document does however have a rather faulty crystal ball so -we can not tell for sure exactly what features will or will not appear in -version 2. We can however mention some of the features and things that +we can not tell for sure exactly what features will or will not appear in such +a future version. We can however mention some of the features and things that explicitly have been removed from the v1 work to be "worked on later" and that -then possibly might appear in a version 2. +then possibly might appear in a future version. ## Forward Error Correction @@ -19,8 +19,8 @@ recognizes only the portion of the data that contains no apparent errors. Google experimented with this in their original QUIC work but it was subsequently removed again since the experiments did not turn out well. This -feature is subject for discussion for QUIC v2 but probably takes for someone -to prove that it actually can be a useful addition without too much penalty. +feature is subject for discussion for QUIC but probably takes for someone to +prove that it actually can be a useful addition without too much penalty. ## Multipath From b0a460abbcd8e4fba0466cf2a62713031bf4e103 Mon Sep 17 00:00:00 2001 From: Jing Luo <60296981+delgh1@users.noreply.github.com> Date: Tue, 24 Oct 2023 12:23:28 +0900 Subject: [PATCH 73/78] README.md: replacehyperlink description "Get the web or pdf versions on gitbook.com" would imply that the URL points to `gitbook.com`, but since the URL acutally points to `http3-explained.haxx.se`, the decription of the hyperlink is updated to match the URL destination to avoid confusion for readers. --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 12492b67..fd955204 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ QUIC protocols. Join in and help! Get the Web or PDF versions on -[gitbook.com](https://http3-explained.haxx.se/). +[http3-explained.haxx.se](https://http3-explained.haxx.se/). The contents get updated automatically on every commit to this git repository. From f44659fc33ebcdc7096eb704526c6837d8577def Mon Sep 17 00:00:00 2001 From: Vasco Franco <11303847+Vasco-jofra@users.noreply.github.com> Date: Mon, 11 Dec 2023 17:54:39 +0000 Subject: [PATCH 74/78] Fix language typo in h3.md --- en/h3.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/en/h3.md b/en/h3.md index 5396c41b..619d00d6 100644 --- a/en/h3.md +++ b/en/h3.md @@ -9,7 +9,7 @@ the network. HTTP still maintains the same paradigms and concepts like before. There are headers and a body, there is a request and a response. There are verbs, -cookies and caching. What primarily changes with HTTP/3 is how the bits gets +cookies and caching. What primarily changes with HTTP/3 is how the bits get sent over to the other side of the communication. In order to do HTTP over QUIC, changes were required and the results of this From fb3da9d0bf528be454ab5a14c301cc3a3c4ce51d Mon Sep 17 00:00:00 2001 From: Jacob Rothstein Date: Thu, 18 Jan 2024 10:37:38 -0800 Subject: [PATCH 75/78] Update specs.md to link to the proposed standards --- en/specs.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/en/specs.md b/en/specs.md index 3e38e707..3c84ee50 100644 --- a/en/specs.md +++ b/en/specs.md @@ -1,28 +1,28 @@ # The specifications -Here is a collection of the latest official drafts for the various parts and +Here is a collection of the RFCs for the various parts and components of QUIC and HTTP/3. ## Invariants -[Version-Independent Properties of QUIC](https://tools.ietf.org/html/draft-ietf-quic-invariants) +[Version-Independent Properties of QUIC](https://datatracker.ietf.org/doc/html/rfc8999) ## Transport -[QUIC: A UDP-Based Multiplexed and Secure Transport](https://tools.ietf.org/html/draft-ietf-quic-transport) +[QUIC: A UDP-Based Multiplexed and Secure Transport](https://datatracker.ietf.org/doc/html/rfc9000) ## Recovery -[QUIC Loss Detection and Congestion Control](https://tools.ietf.org/html/draft-ietf-quic-recovery) +[QUIC Loss Detection and Congestion Control](https://datatracker.ietf.org/doc/html/rfc9002) ## TLS -[Using TLS to Secure QUIC](https://tools.ietf.org/html/draft-ietf-quic-tls) +[Using TLS to Secure QUIC](https://datatracker.ietf.org/doc/html/rfc9001) ## HTTP -[Hypertext Transfer Protocol Version 3 (HTTP/3)](https://tools.ietf.org/html/draft-ietf-quic-http) +[Hypertext Transfer Protocol Version 3 (HTTP/3)](https://datatracker.ietf.org/doc/html/rfc9114) ## QPACK -[QPACK: Header Compression for HTTP/3](https://tools.ietf.org/html/draft-ietf-quic-qpack) +[QPACK: Header Compression for HTTP/3](https://datatracker.ietf.org/doc/html/rfc9204) From 6d6ed11fb3cdb899e6944ee2717af4562d778576 Mon Sep 17 00:00:00 2001 From: Jacob Rothstein Date: Thu, 18 Jan 2024 10:43:13 -0800 Subject: [PATCH 76/78] Update specs.md to link to RFC9368 instead of RFC8999 which it updates --- en/specs.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/en/specs.md b/en/specs.md index 3c84ee50..266551ab 100644 --- a/en/specs.md +++ b/en/specs.md @@ -3,9 +3,9 @@ Here is a collection of the RFCs for the various parts and components of QUIC and HTTP/3. -## Invariants +## Version Negotiation -[Version-Independent Properties of QUIC](https://datatracker.ietf.org/doc/html/rfc8999) +[Compatible Version Negotiation for QUIC](https://datatracker.ietf.org/doc/html/rfc9368) ## Transport From 3dfad0aa70eb8c443cf45e97bfdcdad74d73f3b3 Mon Sep 17 00:00:00 2001 From: Pierre-Yves Aillet Date: Sun, 18 Feb 2024 11:49:12 +0100 Subject: [PATCH 77/78] [fr] Fix some formulations and typos in the french translation --- fr/criticism.md | 3 ++- fr/feature-trans-app.md | 2 +- fr/why-secure.md | 2 +- 3 files changed, 4 insertions(+), 3 deletions(-) diff --git a/fr/criticism.md b/fr/criticism.md index 8c4aa93c..3883af3b 100644 --- a/fr/criticism.md +++ b/fr/criticism.md @@ -13,7 +13,8 @@ sortant afin de cibler des victimes innocentes. QUIC dispose d’une atténuation intégrée contre les attaques d’amplification en exigeant que le paquet initial soit au minimum de 1200 octets et par une restriction dans le protocole qui stipule qu’un serveur NE DOIT PAS envoyer -plus de trois fois ça en réponse sans recevoir un paquet du client en réponse. +plus de trois fois la taille de la requête en réponse sans recevoir un paquet +du client en réponse. ## UDP est lent dans les noyaux diff --git a/fr/feature-trans-app.md b/fr/feature-trans-app.md index fc49b9ba..c6f5cf43 100644 --- a/fr/feature-trans-app.md +++ b/fr/feature-trans-app.md @@ -7,5 +7,5 @@ est HTTP/3 (h3). La couche de transport prend en charge les connexions et les flux. L'ancienne version de QUIC de Google regroupait le transport et le protocole HTTP -dans un même fait-tout et constituait un protocole send-http/2-frames-over-udp plus +dans un même ensemble et constituait un protocole send-http/2-frames-over-udp plus spécifique. diff --git a/fr/why-secure.md b/fr/why-secure.md index a37380bd..4a7b02ad 100644 --- a/fr/why-secure.md +++ b/fr/why-secure.md @@ -1,6 +1,6 @@ ## Sécurisé -QUIC est toujours sécurisé. Il n'y a pas de version en texte clair clair du +QUIC est toujours sécurisé. Il n'y a pas de version en texte clair du protocole, donc négocier une connexion QUIC signifie faire de la cryptographie et de la sécurité avec TLS 1.3. Comme mentionné ci-dessus, cela empêche l'ossification ainsi que d'autres types de blocages et traitements spéciaux, et garantit que QUIC From 315e04cdc74e209820e337027649dcf46e7e40ae Mon Sep 17 00:00:00 2001 From: "JC (Jonathan Chen)" Date: Wed, 7 Aug 2024 16:27:12 -0400 Subject: [PATCH 78/78] Fix wording in `en/quic-future.md` --- en/quic-future.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/en/quic-future.md b/en/quic-future.md index 56fa66d6..ebf40a2a 100644 --- a/en/quic-future.md +++ b/en/quic-future.md @@ -1,6 +1,6 @@ # QUIC future -In order to get the most possibly focus on the core QUIC protocol and be able +In order to get the most focus possible on the core QUIC protocol and be able to ship it on time, several features that were originally planned to be part of the core protocol have been postponed and are now planned to instead get done in a subsequent QUIC version.