http2 explained
  • English
    • Background
    • HTTP Today
    • Things done to overcome latency pains
    • Updating HTTP
    • http2 concepts
    • The http2 protocol
    • Extensions
    • An http2 world
    • http2 in Firefox
    • http2 in Chromium
    • http2 in curl
    • After http2
    • Further reading
    • Thanks
  • Español
    • Antecedentes
    • HTTP hoy
    • Estrategias para evitar los dolores de latencia
    • Actualizando HTTP
    • Conceptos de http2
    • El protocolo http2
    • Extensiones
    • Un mundo http2
    • http2 en Firefox
    • http2 en Chromium
    • http2 en curl
    • Después de http2
    • Otras lecturas
    • Agradecimientos
  • فارسی
    • مقدمه و معرفی
    • پیش‌زمینه
    • HTTP امروز
    • کارهایی که برای غلبه بر تأخیرها انجام شده
    • آپدیت‌کردن HTTP
    • مفاهیم http2
    • پرتکل http2
    • افزونه‌ها
    • دنیایی با http2
    • http2 در فایرفاکس
    • http2 در کرومیوم
    • http2 در curl
    • بعد از http2
    • خواندن بیشتر
    • تقدیر و تشکر
    • واژه‌نامه
  • Français
    • Avant-propos
    • HTTP aujourd'hui
    • Rustines pour s'accommoder de la latence
    • Mettre à jour HTTP
    • Concepts http2
    • Le protocole http2
    • Extensions
    • Le monde http2
    • http2 et Firefox
    • http2 et Chromium
    • http2 et curl
    • Après http2
    • Lecture complémentaire
    • Remerciements
  • Italiano
    • Background
    • HTTP oggi
    • Tecniche applicate al contrasto della latenza
    • Aggiornare HTTP
    • http2 a grandi linee
    • Il protocollo http2
    • Estensioni
    • Un mondo di http2
    • http2 in Firefox
    • http2 in Chromium
    • http2 in curl
    • Dopo http2
    • Altre letture
    • Riconoscimenti, Ringraziamenti
  • 日本語
    • 背景
    • HTTPの現状確認
    • レイテンシーの闇を克服せよ
    • もうやめて、HTTP 1.1のライフはゼロよ
    • http2のコンセプト
    • http2プロトコル
    • http2は拡張の夢を見る
    • http2化される世界
    • Firefoxにおけるhttp2
    • Chromiumにおけるhttp2
    • curlにおけるhttp2
    • http2の次にくるもの
    • 参考文献
    • 謝辞
  • 한국어
    • 배경
    • HTTP 현재
    • 대기시간의 고통을 극복하기 위해 한일
    • HTTP 업데이팅
    • http2 컨셉
    • http2 프로토콜 (번역되지 않은)
    • 연장선 (번역되지 않은)
    • http2 세계 (번역되지 않은)
    • Firefox에서의 http2
    • Chromium에서의 http2
    • curl에서의 http2
    • HTTP2 다음에 오는 것
    • 참조
    • 감사의 말
  • Português
    • Antecedentes
    • HTTP Hoje
    • Estratégias para evitar as dores da latência
    • Atualizando HTTP
    • Conceitos de http2
    • O protocolo http2
    • Extensões
    • Um mundo http2
    • http2 e Firefox
    • http2 e Chromium
    • http2 e curl
    • Após o http2
    • Outras leituras
    • Agradecimentos
  • русском
    • История
    • HTTP сегодня
    • Шаги, предпринятые для преодоления задержки
    • Обновление HTTP
    • Концепция http2
    • Протокол http2
    • Расширения
    • Мир http2
    • http2 в Firefox
    • http2 в Chromium
    • http2 в curl
    • После http2
    • Дальнейшее чтение
    • Благодарности
  • Svenska
    • Bakgrund
    • HTTP idag
    • Tricks för att komma över fördröjningssmärtor
    • Uppdatera HTTP
    • http2-koncept
    • http2-protokollet
    • Utökningar
    • En http2-värld
    • http2 i Firefox
    • http2 i Chromium
    • http2 i curl
    • Efter http2
    • Fortsatt läsning
    • Tack
  • Türkçe
    • Arkaplan
    • HTTP'nin Bugünü
    • Gecikmelerin üstesinden gelmek için yapılanlar
    • HTTP'nin güncellenmesi
    • http2 konseptleri
    • http2 protokolü
    • Uzantılar
    • http2 dünyası
    • Firefox'da http2
    • Chromium'da http2
    • curl'de http2
    • http2 sonrası
    • Daha fazla bilgi için
    • Teşekkürler
  • 中文
    • 背景
    • HTTP的现状
    • 那些年,克服延迟之道
    • 升级HTTP
    • http2的观念
    • http2协议
    • 扩展
    • http2的世界
    • Firefox里的http2
    • Chromium里的http2
    • Curl里的http2
    • 后http2时代
    • 扩展阅读
    • 致谢
Powered by GitBook
On this page
  • ۶.۱. باینری
  • ۶.۲. قالب باینری
  • ۶.۳. تسهیم‌سازی (Multiplexing)
  • ۶.۴. اولویت‌ها و وابستگی‌ها
  • ۶.۵. فشرده‌سازی هدرها
  • ۶.۵.۱. فشرده‌سازی موضوع ریسک‌داری است
  • ۶.۶. ریست - نظرم عوض شد
  • ۶.۸. Push از سرور
  • ۶.۸. کنترل جریان

Was this helpful?

Export as PDF
  1. فارسی

پرتکل http2

Previousمفاهیم http2Nextافزونه‌ها

Last updated 5 years ago

Was this helpful?

فکر می‌کنم بحث درمورد پیش‌زمینه و اتفاقات گذشته بس باشد. برویم به سراغ استانداردهای پرتکل: چیزهایی که http2 را ساختند.

۶.۱. باینری

http2 یک پرتکل باینری است.

اگر شما با پرتکل‌های اینترنتی قبلا کار کرده باشید، احتمالا نسبت به این مورد واکنش نشان می‌دهید و شروع به ارائه‌ی دلایل مبنی بر این که چرا پرتکل‌های متنی (text/ascii) بهترند چون انسان‌ها می‌توانند آن‌ها را بخوانند، در telnet از آن‌ها استفاده کنند و ...

http2 باینری است تا فریم‌بندی را راحت‌تر کند. تشخیص اول و آخر یک فریم در HTTP 1.1 و بقیه‌ی پرتکل‌های متنی، کار پیچیده‌ای بود. با دور‌شدن از فضاهای خالی اختیاری و راه‌های متفاوت برای پیاده‌سازی یک چیز، پیاده‌سازی حالا راحت‌تر خواهد شد.

هم‌چنین، جدا‌کردن فریم‌های مربوط به قرارداد و پرتکل از فریم‌های مربوط به داده‌های پاسخ، راحت‌تر خواهد شد - قبلا این کار در HTTP1 بسیار گیج‌کننده بود.

در حقیقت، پرتکل قابلیت فشرده‌سازی را دارد و اجرا شدنش روی TLS، متن را مخفی می‌کند، بنابراین شخص ثالثی نمی‌تواند متن را از روی ترافیک جابجا‌شده بخواند. در واقع، باید عادت کنیم که از برنامه‌هایی مثل Wireshark برای خواندن داده‌های مبادله‌شده در سطح پرتکل http2 استفاده کنیم.

دیباگ‌کردن این پرتکل به ابزارهایی مثل curl یا برای آنالیز به Wireshark و مشابه‌های آن نیاز دارد.

۶.۲. قالب باینری

http2 فریم‌ها را به صورت باینری می‌فرستد. نوع فریم‌ها ممکن است مختلف باشد، ولی همه‌ی آن‌ها یک‌نوع مشخصات دارند: اندازه (Length)، نوع (Type)، نشان‌ها (Flags)، شناسه‌ی استریم (Stream Identifier) و داده‌های فریم.

در قرارداد http2، ده نوع فریم مختلف تعریف شده و اساسی‌ترین آن‌ها که به قابلیت‌های HTTP 1.1 نیز مربوط هستند، DATA و HEADERS است. بعضی از این نوع‌ها را در ادامه بررسی می‌کنیم.

۶.۳. تسهیم‌سازی (Multiplexing)

شناسه‌ی استریم که در فریم قبلی به آن اشاره شد، با یک «استریم» در هر فریم همراه است. یک استریم، مجموعه‌ای از فریم‌های داده به طور مستقل و دوطرفه است که کلاینت و سرور می‌توانند در یک کانکشن http2 آن‌ها را مبادله کنند.

یک کانکشن مستقل http2 می‌تواند دارای چندین استریم‌های باز به طور هم‌زمان باشد، و یا یکی از طرفین، استریم‌های مختلف را با هم ترکیب کند تا چندین فریم را بسازد.

تسهیم‌سازی استریم به این معنی است که بسته‌های چندین استریم با هم ترکیب شده و در قالب یک کانکشن مبادله می‌شودن. دو (یا بیشتر) قطار از داده‌ها، تبدیل به یک قطار می‌شوند و در طرف دیگر، دوباره جدا می‌شوند. مثلا:

حالا اگر این دو قطار با هم ترکیب شوند یا اصطلاحا تسهیم‌سازی (Multiplex) شوند:

۶.۴. اولویت‌ها و وابستگی‌ها

هر استریم دارای اولویت است (هم‌چنین آن را به عنوان weight هم می‌شناسند)، که به طرف مقابل اطلاع می‌دهد که کدام استریم مهم‌تر است تا با توجه به محدودیت منابع، کدام را زودتر دریافت کند یا کدام را زودتر درخواست کند.

با استفاده از فریم PRIORITY، کلاینت می‌تواند به سرور اطلاع دهد که یک استریم، به چه استریم‌های دیگری وابسته است. این قابلیت به کلاینت اجازه می‌دهد که یک درخت از وابستگی‌ها ایجاد کند که هر «استریم فرزند» به «استریم‌های پدر» وابسته است.

اولویت‌ها و وابستگی‌ها می‌توانند در زمان اجرا به صورت پویا عوض شوند، که باعث می‌شود مرورگرها این توانایی را داشته باشند که هنگامی که کاربر در یک صفحه‌ی پر از عکس، پیمایش (Scroll) می‌کند، مرورگر به سرور اطلاع دهد که کدام عکس‌ها مهم‌تر هستند، یا اگر به یک Tab دیگر بروید، مرورگر به استریم‌های دیگری اولویت بالاتر می‌دهد که مربوط به صفحه‌ی جدید هستند.

۶.۵. فشرده‌سازی هدرها

HTTP یک پرتکل Stateless است، یعنی هر درخواست باید هدرهایی را همراه داشته باشد تا سرور بتواند به آن پاسخ دهد، بدون این‌که نیاز باشد سرور اطلاعات بسیاری را از درخواست‌های قبلی ذخیره کند. از آن‌جایی که http2 این پارادایم را تغییر نمی‌دهد، هم‌چنان به همین صورت کار می‌کند.

این روش باعث تکراری‌شدن درخواست‌های HTTP می‌شود. وقتی یک کلاینت از همان سرور، چندین بار درخواست عکس برای یک صفحه می‌کند، چندین درخواست تقریبا یکسان را می‌فرستند. این نوع داده‌هایی که تقریبا یکسان هستند، مناسب فشرده‌سازی هستند.

همان‌طور که قبلا هم اشاره کردیم، تعداد فایل‌های موردنیاز هر صفحه بالاتر رفته، هم‌چنین اندازه‌ی Cookies و درخواست‌ها هم به مرور زمان در حال افزایش هستند. Cookies باید در هر درخواست فرستاده شوند، معمولا در چندین درخواست یکی هستند.

اندازه‌ی درخواست‌های HTTP 1.1 در واقع این‌قدر بزرگ شده‌اند که گاهی وقت‌ها بیش از حجم مقبول TCP می‌شوند که باعث می‌شود ارسال‌شان بسیار کند‌تر شود، چون یک‌بار ناقص فرستاده می‌شوند تا از سرور ACK بگیرند و بعد از آن، به طور کامل ارسال می‌شود. این دلیل دیگری برای نیاز‌داشتن به فشرده‌سازی است.

۶.۵.۱. فشرده‌سازی موضوع ریسک‌داری است

فشرده‌سازی محتوای پویا در یک پرتکل - بدون این‌که به یکی از این حملات آسیب‌پذیر باشد - به فکر و تصمیم‌های محتاطانه نیاز دارد. این همان چیزی است که کارگروه HTTPbis سعی کردند انجام دهند.

به گفته‌ی Roberto Peon (یکی از سازندگان HPACK): (مترجم: این نقل‌قول به طور تحت‌اللفظی ترجمه نشده).

HPACK احتمال نا‌امن‌بودن پیاده‌سازی و در نتیجه نشت اطلاعات را کاهش می‌دهد روند رمزنگاری/رمزگشایی را آسان‌تر و به‌صرفه‌تر می‌کند، و به دریافت‌کننده این امکان را می‌دهد که بر Context Size فشرده‌سازی کنترل داشته باشد یا اجازه‌ی ایجاد پراکسی برای Re-Indexing (مثل وضعیت مشترک بین فرانت‌اند و بک‌اند در یک پراکسی) را بدهد و هم‌چنین امکان مقایسه‌ی سریع رشته‌هایی که به روش هافمن رمزنگاری شده‌اند را می‌دهد.

۶.۶. ریست - نظرم عوض شد

یکی دیگر از معایب HTTP 1.1، عدم وجود پشیمانی است! یعنی وقتی یک درخواست با Content-Length مشخص فرستاده شد، نمی‌توانید به این راحتی متوقفش کنید. البته، شما می‌توانید کانکشن TCP را قطع کنید، ولی باید دوباره یک ارتباط TCP جدید ایجاد کنید.

راه‌حل بهتر این است که درخواست قبلی را متوقف کنید و یک درخواست جدید بفرستید. این کار در http2 با ارسال فریم RST_STREAM ممکن است که از هدر‌رفت پهنای باند و هم‌چنین از بین رفتن کانکشن‌ها جلوگیری می‌کند.

۶.۸. Push از سرور

این ویژگی را با نام «cache push» نیز یاد می‌کنند. ایده‌ی اصلی این است که هنگامی که کلاینت درخواست فایل X را می‌کند، سرور می‌داند که احتمالا فایل Z را هم می‌خواهد و آن را به کلاینت،‌ بدون این‌که درخواست کرده باشد، می‌فرستد. این ویژگی باعث می‌شود که کلاینت ، فایل Z را هم در Cache قرار دهد و هنگامی که نیاز است از آن استفاده کند.

Server push ویژگی‌ای است که کلاینت باید به سرور اجازه‌ی انجام آن را بدهد. در آن صورت، کلاینت می‌تواند یک استریم پوش‌شده را در هر زمانی با RST_STREAM کنسل کند.

۶.۸. کنترل جریان

هر استریم http2، ظرفیت جریان را تعیین می‌کند تا سمت دیگر مطلع باشد که چه مقدار می‌تواند داده بفرستید. اگر با پرتکل SSH و چگونگی کار آن آشنا باشید، می‌دانید که این ویژگی بسیار شبیه به SSH است.

در هر استریم، هر دو طرف باید به طرف دیگر اطلاع دهند که فضای کافی برای دریافت داده‌ها را دارند و طرف دیگر تنها در صورتی اجازه‌ی ارسال دارد که ظرفیت اجازه می‌دهد. تنها فریم‌های DATA کنترل می‌شوند.

قطار ترکیب‌شده

فشرده‌سازی‌های HTTPS و SPDY دربرابر حملات و آسیب‌پذیر بودند. با قرار‌دادن یک متن شناخته در استریم و یافتن این‌که چگونه تغییر می‌کند، حمله‌کننده می‌توانست بفهمد که چیزی به صورت Encrypt شده ارسال می‌شده است.

[HPACK] وارد می‌شود!(). Header Compression for HTTP/2 یا فشرده‌سازی هدرها برای HTTP/2، یک فرمت فشرده‌سازی است که مخصوصا برای هدرهای http2 طراحی شده است و در یک پیش‌نویس اینترنتی جداگانه تبیین شده.

BREACH
CRIME
https://www.rfc-editor.org/rfc/rfc7541.txt
یک قطار
قطار دیگر