مفاهیم http2

http2 چه فایده‌ای دارد؟ مرزهای تعیین‌شده برای کارگروه HTTPbis چه هستند؟

این مرزها در واقع بسیار محدود بودند و اختیارات کمی به گروه برای نوآوری می‌دادند:

• http2 باید از پارادایم‌های HTTP پشتیبانی کند. یعنی هم‌چنان پرتکلی است که کلاینت از طریق TCP به سرور درخواستی می‌فرستند.

• پیش‌وندهای http:// و https:// نباید تغییر کنند. هیچ پیشوند تازه‌ای نمی‌توان ایجاد کرد. محتوایی که تحت این پیشوندها دردسترس هستند، بیشتر از آن هستند که بتوان تغییرشان داد.

• سرورها و کلاینت‌های HTTP1 تا دهه‌ها وجود خواهند داشت، پس باید بتوان آن‌ها را با سرورهای http2 پراکسی کرد.

• تبعا، پراکسی‌ها باید بتوانند قابلیت‌های http2 را به کلاینت‌های HTTP 1.1، یک‌به‌یک مربوط کنند.

• حذف یا کاهش قسمت‌های اختیاری پرتکل. این کار واقعا لازم نبود، در واقع یک حرکت بود که از گوگل و SPDY شروع شد. وقتی مطمئن باشیم که همه‌چیز ضروری هستند، می‌توانید بدون این‌که چیزی جا بیندازید، آن را پیاده‌سازی کنید که بعدا گرفتار نشوید.

• نسخه‌های جزئی نداشته باشیم. ما تصمیم گرفتیم که کلاینت‌ها یا سرورها یا با http2 سازگارند یا نیستند. اگر نیاز به توسعه‌ی پرتکل وجود داشت، نسخه‌ی بعدی، http3 خواهد بود. هیچ نسخه‌ی جزئی (Minor) در http2 نخواهیم داشت.

۵.۱. http2 برای پیشوندهای URI موجود

همان‌طور که قبلا هم اشاره شد، پیشوند‌ها و ساختارهای کنونی URI را نمی‌توان تغییر داد، پس http2 باید از آن‌هایی که الان هستند استفاده کند. از آن‌جایی آن‌ها در HTTP 1.x استفاده می‌شوند، به یک راه نیاز داریم که پرتکل را به http2 ارتقا دهیم یا از سرور بخواهیم که از http2 به جای پرتکل‌های قدیمی استفاده کند.

HTTP 1.1 قبلا یک راه برای این منظور تعریف کرده: استفاده از هدر Upgrade: که به سرور اجازه می‌دهد که پاسخ درخواست را با پرتکل جدید بدهد، که هزینه‌ی این کار، پذیرش دو درخواست به جای یکی است.

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

۵.۲. http2 برای https://

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

دلایل اجباری‌کردن TLS، احترام به حریم‌خصوصی کاربر است، هم‌چنین آزمایش‌های اولیه نشان داد که پرتکل‌های جدید، میزان موفقیت بیشتری دارند، اگر بر مبنای TLS باشند. این به این‌خاطر است که معمولا فرض بر این گذاشته می‌شود که ترافیکی که از پورت ۸۰ عبور می‌کند، با پرتکل HTTP 1.1 کار می‌کند. وقتی پرتکل‌های دیگری از این پورت استفاده می‌کنند، بعضی از واسطه‌ها (مثلا آنتی‌ویروس‌ها) ممکن است اختلال ایجاد کنند یا حتی داده‌های رسیده را از بین ببرند.

موضوع اجباری‌شدن TLS مناقاشات زیادی را در لیست‌های ایمیل و دیدارها به‌وجود آورد - آیا این کار درست است یا غلط؟ موضوعی که بسیار جدال‌آمیز است - مواظب باشید که آن را ناگهانی از یکی از اعضای کارگروه HTTPbis نپرسید!

به طور مشابه، بحثی هم درمورد این وجود داشته که آیا http2 باید لیستی از روش‌های رمزنگاری را برای TLS اجباری کند، یا لیست‌سیاهی از این الگوریتم‌ها درست کند، یا شاید هیچ‌کاری به لایه‌ی TLS نداشته باشد و اجازه دهد که کارگروه TLS کار خودشان را انجام دهند. نتیجه آن شد که استاندارد تعیین کرد که نسخه‌ی TLS باید حداقل ۱.۲ باشد و هم‌چنین در انتخاب روش‌های رمزنگاری (Cipher Suite) نیز محدودیت‌هایی وجود دارد.

۵.۳. ارتباط اولیه http2 روی TLS

NPN پرتکلی بود که SPDY برای مذاکره یا همان ارتباط اولیه با سرورهای TLS استفاده می‌کرد. از آن‌جایی که این پرتکل استاندارد نبود، NPN از IETF گذشت و نتیجه شد: ALPN. ALPN در حال‌حاضر برای http2 استفاده می‌شود،‌ در حالی که کلاینت‌ها و سرورهای SPDY هنوز از NPN استفاده می‌کنند.

در حقیقت، NPN اول وجود داشته و در زمانی که ALPN در فرآیند استانداردسازی قرار داشته، کلاینت‌ها و سرورهای http2 بسیاری به‌وجود‌آمدند که از هردوی آن‌ها پشتیبانی می‌کردند. هم‌چنین، از NPN در SPDY استفاده می‌شود و سرورهای بسیاری SPDY و http2 ارائه می‌دهند. پس پشتیبانی هم‌زمان از NPN و ALPN در این سرورها، کاملا منطقی است.

ALPN با NPN تفاوتشان در در این است که چه کسی تصمیم می‌گیرد که با چه پرتکلی صحبت کند. در ALPN، کلاینت لیستی از پرتکل‌هایی که پشتیبانی می‌کند را به سرور می‌دهد و سرور برحسب کارایی و اولویت، یکی را انتخاب می‌کند، در حالی که در NPN، کلاینت تصمیم نهایی را می‌گیرد.

۵.۴. http2 برای http://

همان‌طور که قبلا اشاره کردم، برای HTTP 1.1 که از متن ساده (plain text) استفاده می‌کند، ارتباط اولیه‌ی http2 با هدر Upgrade: انجام می‌شود. اگر سرور به http2 صحبت می‌کند، با کد "101 Switching" پاسخ می‌دهد و پس از آن، با کلاینت http2 صحبت می‌کند. البته، این فرآیند، باعث دوبرابر‌شدن درخواست‌ها و پاسخ‌ها می‌شود، ولی مزیت آن این است که معمولا ممکن است یک کانکشن http2 را مدت بیشتری زنده نگه داشت و از آن استفاده بیشتری نسبت به یک کانکشن HTTP1 کرد.

در حالی که بعضی از سخنگوهای مرورگرها اعلام کردند این مورد را پیاده‌سازی می‌کنند، تیم Internet Explorer یک‌بار اعلام کردند که این کار را می‌کنند، هر چند تا به الان به قول خود عمل نکردند. هم‌چنین curl و چند کلاینت دیگر که مرورگر نیستند اعلام کردند که از http2 به صورت متن‌ساده (clear-text/رمز‌نگاری‌نشده) پشتیبانی می‌کنند.

امروزه، هیچ مرورگری بدون TLS از http2 پشتیبانی نمی‌کند.