چگونه HTTP2 سرعت مرور صفحات وب را افزایش می‌دهد؟

زمانی‌ که آخرین نسخه از پروتکل انتقال‌ابرمتن (HTTP 1.1) در سال 1999 میلادی منتشر شد، سریع‌ترین کامپیوترها مجهز به چیپ‌ست‌های پنتیوم 500 مگاهرتزی بودند. مهندسان نرم‌افزار در آن روزگار با تلاش بسیار مشکل Y2K را حل کردند. اداره فدرال امریکا پهنای باند 200 کیلوبایت بر ثانیه را تصویب کرد، و بیشتر کاربران از مودم‌های 56 کیلوبایت استفاده می‌کردند. اما همه چیز متحول شد، HTTP پروتکل‌ بنیادی وب نیز سرانجام خود را با زمانه هماهنگ کردند.

سازمان IETF (سرنام Internet Engineering Task Force) بعد از گذشت بیش دو از سال بررسی و تحقیق، سرانجام HTTP 2 را ‌تصویب کرد. HTTP 2  با دو ویژگی اساسی ساخته شد. اول آن‌که خود پروتکل جدیدی است و دوم آن‌که مجهز به ویژگی HPACK است که برای فشرده‌سازی سرآیند HTTP2 مورد استفاده قرار می‌گیرد. این پروتکل تجدیدنظر شده تجربه مرور و بازدید سریع‌تر صفحات، کم‌کردن نیاز به پهنای باند مصرفی زیاد و ساده‌تر کردن ارتباطات ایمن را فراهم کرد. بخش اصلی پروتکل HTTP 2 بر مبنای پروتکلی به‌نام SPDY (اسپیدی) متعلق به شرکت گوگل قرار دارد و بخش عمده‌ای از پیشرفت‌هایی که در زمینه سرعت داشته است را مدیون این پروتکل است. اما هیچ‌گاه رقابتی میان دو پروتکل اسپیدی و HTTP2 به وجود نیامد. در واقع اسپیدی، پدر پروتکل HTTP2 محسوب می‌شود و نه رقیب آن. در پیاده‌سازی پروتکل HTTP 2 از تکنیک‌ها و ابداعات مختلفی برای افزایس سرعت و راندمان استفاده شده است.

اولین روشی که HTTP 2 برای افزایش سرعت انتقال داده‌ها از آن استفاده می‌کند، به‌کارگیری یک فرمت باینری به جای فرمت متنی است. فرمت متنی یک فرمت قابل فهم انسانی بود که HTTP 1.1 برای انتقال پیام‌ها  استفاده می‌کرد. علاوه بر این و برای ساده‌تر کردن کار وب‌سرورها و مرورگرها، این فرمت جدید از فشرده‌سازی بیشتری بهره می‌برد. به دلیل این‌که هر چه مقدار فشرده‌سازی بیشتر باشد، زمان انتقال یک صفحه کاهش می‌یابد. دومین روشی که HTTP 2  از آن استفاده می‌کند، قابلیت تسهیم (multiplexing) است. این قابلیت واکنش‌پذیری بیشتر را برای سایت‌ها به‌همراه دارد و از بروز مشکل “head-of line-blocking” که HTTP 1.1 با آن دست به گریبان بود، رهایی می‌یابد. Head-of line یک مشکل محدودیت کارایی در شبکه‌های کامپیوتری است و زمانی رخ می‌دهد که ‌روی یک خط بسته‌ها توسط نخستین بسته در حالت انتظار نگهداری ‌شوند.

نسخه‌های پیشین HTTP فقط توانایی اداره‌کردن یک درخواست در یک زمان را داشتند، به این شکل هر بار یک صفحه را بازدید می‌کردید؛ یک ارتباط چهار به هشت TCP/IP را آغاز می‌کردید. با HTTP 2 هر سایت فقط یک ارتباط TCP/IP را  نیاز دارد، اما یک کاربر می‌تواند  چندین درخواست داده را به طور همزمان داشته باشد. تعداد دقیق استریم‌های موازی توسط مرورگر وب تعیین می‌شود. نتیجه این فرآیند یک ارتباط داده‌ای سریع‌تر و شفاف‌تر است.

ویژگی سوم، HTTP 2 مجهز به فن‌آوری Server Push است که امکان انتقال سریع‌تر اطلاعات را فراهم می‌کند. امروزه، زمانی‌که به یک سایت متصل می‌شوید، یک صفحه HTML در ابتدا ارسال می‌شود و سپس مرورگر شما برای جاوااسکرپیت، فلش و موارد دیگر درخواست ارائه می‌کند. در این حالت تعداد زیادی ارتباط برای یک صفحه ناقابل باز و بسته می‌شوند. اکنون، با فن‌آوری Server Push، سرور محتوای یک صفحه را به‌طور کامل ارسال می‌کند، مگر آن‌که اطمینان حاصل کند که شما قبلا آن را در حافظه کش محلی داشته‌اید. در HTTP 2 بعضی عناصر یک صفحه وب نسبت به دیگر عناصر دارای حق‌اولویت هستند که بستگی به مرورگر و سرور دارد. مرورگر بررسی می‌کند کدام عنصر ابتدا باید دریافت شود.

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

با گذشت زمان، این سرآیندها بزرگ‌تر و پیچیده‌تر می‌شوند. زمانی‌که سرآیندها در سال 2005 استانداردسازی شدند، 116 فیلد سرآیند مختلف وجود داشت. همه این سرآیندها با هر عنصری از هر صفحه ارسال می‌شد که بیشتر آن‌ها اطلاعات تکراری حمل می‌کردند. بنابراین، برای کاهش سربار و ساخت صفحاتی سریع‌تر، فشرده‌سازی HPACK روی داده‌های سرآیند انجام شد. پاتریک مک مانوس مهندس نرم‌افزار در پلت‌فرم موزیلا به این نکته اشاره می‌کند که هر ارتباط در مجموع دارای 1400 بایت است و یک صفحه تکی اغلب دارای 80 دارایی (assets) است که هر کدام نیاز به یک ارتباط دارند. اگر همه آن‌ها را در کنار هم قرار دهیم، میانگین اندازه صفحات وب در حدود یک مگابایت می‌شود.

در ابتدای کار،  قرار بود از الگوریتم GZIP برای فشرده‌سازی داده‌ها در HTTP/2 استفاده شود. با این حال وجود یک نشتی CRIME (سرنام  Compression Ratio Info-leak Made Easy) موجب شد تا فشرده‌سازی استریم‌ها و پروتکل‌ با استفاده از GZIP ناامن شود. بنابراین HTTP /2 از الگوریتم دیگری استفاده کرد که کارایی کمتر اما در مقابل ایمنی بیشتری را ارائه کرد.

درنظر داشته باشید مواردی که به آن‌ها اشاره شد فقط در صورتی تأثیرگذار بوده و باعث افزایش سرعت خواهند شد که هر دو طرف مرورگر وب و سروری که سایت را انتقال می‌دهد از پروتکل HTTP2 استفاده کند. در زمان نگارش این مقاله، جدیدترین نسخه‌های ارائه شده از مرورگرها: کروم 40، فایرفاکس 36، اینترنت‌اکسپلورر 11 روی ویندوز 10 و اپرا 21 از پیاده‌سازی HTTP2 پشتیبانی می‌کنند. وب‌سرورهای سطح بالایی همچون آپاچی، IIS(سرنام Internet Information Server) و nginx خود را با HTTP2 هماهنگ کرده‌اند.

بازگردیم به مفهوم امنیت، چنان‌که رییس کارگروه HTTP2/IETF به آن اشاره می‌کند، HTTP2 نیازی ندارد که شما از TLS (فرم استاندارد SSL، لایه رمزگذاری وب) استفاده کنید، اما عملکرد بالای آن به کارگیری رمزنگاری را ساده‌تر می‌کند، از این رو تأثیری که روی مشاهده سریع سایت‌ها می‌گذارد را کم می‌کند.

گوگل و موزیلا هر دو از مدت‌ها قبل تصمیم گرفته‌اند که کروم و موزیلا از HTTP2 فقط روی ارتباطات رمزنگاری TLS  استفاده کند. درابتدا مایکروسافت با دید بازتری به این موضوع نگاه کرد، اما در نسخه بتا اینترنت‌اکسپلورر 11، که از HTTP 2 پشتیبانی می‌کند، اصرار دارد که HTTP2 از ارتباطات ایمن استفاده کند.

مارک ناتینگهام  درباره این که چرا رمزنگاری به‌طور ویژه در HTTP2 در نظر گرفته نشده است، به این نکته اشاره می‌کند که HTTP2 یک پروتکل گسترش‌یافته با سهام‌دارن گسترده‌ای همچون فروشندگان پروکسی، اپراتورهای شبکه، شرکت‌های فعال در زمینه دیوارآتش و غیره است. پیاده‌سازی رمزنگاری روی HTTP2 به معنی محروم ساختن این ذی‌نفعان از ارائه این خدمات می‌شود.

در حالی‌که IETF حرف نهایی خود را در رابطه با تصمیمی که اتخاذ کرده زده است، شرکت‌های سازنده مرورگر علاقمندی خود به رمزنگاری را اعلام کرده‌اند. همچنین با ابتکار "اجازه دهید رمزنگاری انجام شود" که توسط گروه پژوهشی امنیت اینترنت ISRG حمایت مالی می‌شود، سعی دارد که رمزنگاری در هر مکان از وب را به تصویب برساند. ایده‌ای که HTTP 2 را یک قدم دیگر برای پیاده‌سازی این درخواست به جلو برده است. این موضوع نشان می‌دهد که وب قصد دارد هرچه زودتر سریع‌تر و ایمن‌تر شود.

در واقع، بسیاری از سایت‌ها که صفحات خود را برای HTTP 1.1 بهینه‌سازی کرده‌اند، همچون آمازون، ممکن است دریابند که به‌سادگی با تغییر به HTTP 2 ممکن است صفحات آن‌ها با کندی سرعت همراه شود. به لحاظ امنیتی، بیشتر وب به صورت “middleboxe” است. از قبیل پروکسی‌سرورها و دیوارهای آتش که نمی‌توانند خود را با HTTP2 هماهنگ کنند. این‌ها سرویس‌هایی هستند که اگر می‌خواهند از مزایای کامل پروتکل جدید در تجارت استفاده کنند باید به‌روزرسانی شده یا جایگزین شوند.

سرانجام، HTTP 2 در هر دو طرف به طرز قابل توجهی سرعت صفحات وب و ایمنی بیشتر را فراهم می‌کند. متاسفانه، به نظر می‌رسد نمی‌توانیم مزایای HTTP2 را تا پیش از آغاز سال 2016 میلادی مشاهده کنیم، استاندارد ممکن است آماده به اجرا باشد، اما پیاده‌سازی و بهینه‌سازی آن حداقل ممکن است یک سال به‌طول بیانجامد.