Hyper Text Transfer Protocol (HTTP) پروتکل مسوول انتقال اطلاعات بر بستر World Wide Web (www) است. این پروتکل رفتاری Client-Server دارد. به این معنا که Client (برای نمونه، مرورگر کاربر)درخواستی (Request) را برای سرور (وبسروری که وبسایت روی آن قرار دارد) ارسال میکند و سرور با دریافت این درخواست، پاسخی (Response) را میفرستد.
نخستین نسخهی استاندارد این پروتکل با نام HTTP/1.1 در سال ۱۹۹۷ معرفی شد. در سالهای نخست ظهور این پروتکل، وبسایتها بیشتر دارای قالبی ساده و فاقد فایلهای چندرسانهای همچون عکس، فایلهای flash و... بودند. با گذشت سالها و پیچیده شدن قالب وبسایتها و افزایش تمایل به استفاده از فایلهای چندرسانهای در آنها، تعداد فایلهای موردنیاز برای بارگذاری (Load) صفحات وب، همچنین سایز این فایلهای کد نیز، افزایش یافت. این موارد سبب شد تا بهتدریج ضعف پروتکل HTTP/1.1 که حاصل کاستیهایی در شیوهی عملکرد آن بود، آشکار شود. این ضعف بزرگ، ناتوانی HTTP/1.1 در بارگذاری سریع صفحات وب پیشرفته و از سوی دیگر، نیاز به پهنای باند (bandwidth) بالا برای Load درست این صفحات بود.
کاستیها و ناتوانی HTTP/1.1 در برآوردن نیازهایی که روزبهروز در حال گسترش بودند، سبب شد تا ایدهی شکلگیری پروتکلی برای حل این مشکلات، ایجاد شود. نخستینبار، گوگل در سال ۲۰۰۹ در پروژهی SPDY، پروتکلی با همین نام را معرفی کرد که هدف از آن، رفع کاستیهای عملکردی HTTP/1.1 و افزایش سرعت بارگذاری صفحات وب، حتا با وجود پهنای باند کم و در نتیجه فراهم آوردن تجربهی کاربری خوب برای بازدیدکنندگان وبسایتها بود. در سال ۲۰۱۵، پروتکل SPDY گوگل با اندکی تغییر و افزودن تعاریف بیشتری به آن، بهکمک IETF، به استاندارد و نسخهی جدیدی برای HTTP با نام HTTP/2 مبدل شد.
در HTTP/1.1 پیامها میان Client و سرور در قالب پیامهای متنی ساده (plain text)، تبادل میشدند. این عمل، مشکلات امنیتی (همچون Response Splitting Attack) را در پی داشت.
HTTP/2 با تعریف یک لایهی جدید با نام Binary Framing، پیامهای HTTP را پیش از ارسال، با حفظ Semantic اصلی HTTP، به قالب باینری تبدیل و سپس آنها را ارسال میکند. تعریف این لایهی جدید سبب میشود تا در مواقعی که یکی از دو طرف ارتباط از HTTP/2 پشتیبانی نمیکند، در ارتباط تداخلی ایجاد نشود.
قالب باینری، امکان فریمبندی پیامها، کاهش سربار تجزیه و تحلیل آنها، همچنین کاهش خطاهایی که در هنگام تحلیل رخ میدهد و استفادهی بهینه از منابع شبکه را فراهم میآورد.
در HTTP/1.1 بهازای هر Request، یک ارتباط TCP مجزا برقرار میشد. در واقع ذات عملکردی HTTP/1.1، اطمینان از تحویل یک Response در هر ارتباط TCP بود. این ارتباط مجزا بهازای هر درخواست، افزونبر مصرف پهنای باند بالا، تاخیر در دریافت اطلاعات را نیز افزایش میداد.
در HTTP/2 میتوان در قالب یک ارتباط TCP، چند درخواست را ارسال کرد. در واقع، قالب باینری HTTP/2 این امکان را فراهم میآورد که بتوان پیام HTTP را به فریمهای کوچکتری تقسیم و آنها را از طریق یک ارتباط TCP ارسال کرد. در سمت دیگر، این فریمها سرهم میشود و پیام اصلی بهدست میآید.
در HTTP/1.1 بهازای هر درخواست برای دریافت یکی از منابع مورد نیاز برای Load صفحه، یک HTTP header نیز ارسال میشد. از سوی دیگر، سرور نیز به همراه پاسخ ارسالی، یک HTTP Header ارسال میکرد. به این ترتیب، برای بارگذاری یک صفحه، میان Client و سرور چند Header تبادل میشد که همگی سرباری اضافی بهشمار میآمدند.
HTTP/2 با بهرهگیری از الگوریتمی با عنوان HPACK اقدام به فشردهسازی Headerها میکند. قالب باینری HTTP/2 این امکان را فراهم میآورد که بتوان Headerها را از دادهها جدا کرد و به این ترتیب، فریمی برای Header و فریمی برای Data داشت. HPACK، با فشردهسازی فریمهای Header سبب کاهش حجم اطلاعات مورد تبادل میان Client و سرور میشود.
با استفاده از این خاصیت، سرور میتواند منابع بعدی که Client قرار است Request را در قبال دریافت آنها بفرستد، پیشبینی کند و پیش از ارسال درخواست برای دریافت آنها از جانب Client، آنها را برای Client بفرستد. برای نمونه، سرور پس از دریافت Request مربوط به فایل HTML، بهجای انتظار برای دریافت Requestهای مربوط به فایلهای CSS، JavaScript و... تمام این منابع را که اطمینان دارد Client برای دریافت آنها درخواستی را ارسال خواهد کرد، برای آن میفرستد.
ارسال همهی اطلاعات از جانب سرور پیش از دریافت Request در قبال آنها، ممکن است سبب ارسال اطلاعاتی شود که مرورگر در طی ارتباطی که پیش از این با سرور داشته، آنها را Cache میکند و نیازی به دریافت دوباره آنها ندارد. برای حل این مشکل و حفظ منابع شبکه، سرور با ارسال فریمی با نام PUSH-PROMISE منابعی که قصد ارسال آنها را دارد، به Client اطلاع میدهد. این فریم در واقع حاوی Header پیامهایی است که سرور قصد ارسال آنها را دارد. اگر Client این منابع را در Cache خود بیابد، در پاسخ، فریم RST_STREAM را ارسال میکند و ارسال نشدن این منابع را به سرور اطلاع میدهد. ارسال فریم PUSH_PROMISE از جانب سرور، از ارسال درخواستهای تکراری به سرور از جانب Client نیز جلوگیری میکند چرا که Client از طریق این فریم، از منابعی که سرور قصد ارسال آنها را دارد، مطلع میشود.
روشی که بهکمک آن مرورگر میتواند ترتیب دریافت منابع مورد نیاز خود را مشخص کند. برای نمونه، مرورگر میتواند مشخص کند که ابتدا فایل HTML، سپس CSS، بعد JS و... را دریافت کند. این عمل سبب سرعت بخشیدن به Render فایلها در مرورگر میشود.
Stream Prioritization (اولویتدهی به جریانها) مکملی برای Multiplexing است. Multiplexing با فراهم آوردن امکان ارسال درخواستها تنها از طریق یک ارتباط TCP، سبب حذف سربار TCP و Stream Prioritization با مشخص کردن اولویت پاسخهای دریافتی، سبب بهینهسازی زمان انتقال اطلاعات مابین سرور و مرورگر میشود.
استفاده از HTTP/1.1 بهدلایل کاستیهای ذاتی این پروتکل سبب میشد تا اعمالی اضافهتر بهمنظور بهینهسازی صفحات وب همانند کاهش تعداد ارتباطات TCP از طریق الحاق چند فایل CSS یا JS در یک فایل یا پخش منابع سایت روی چند دامنه (Domain Sharding)، انجام شود. با ظهور HTTP/2 و نوع عملکرد آن، انجام این اعمال نیز نهتنها غیرضروری بلکه در مواردی دارای تاثیر بدی بر عملکرد HTTP/2 بودند. از سوی دیگر مرورگرهای مدرن از HTTP/2 تنها بر بستر ارتباطی امن پشتیبانی میکنند. به این ترتیب پشتیبانی از HTTPS برای وبسایتها بهمنظور بهرهگیری از HTTP/2، ضروری است.
وظیفهی CDN تحویل محتوا به کاربران در کمترین زمان ممکن و بر بستری امن در حالی است که نیازی بر هیچ پیکربندی اضافهتری از جانب کاربران نباشد. خدمت گواهینامه رایگان SSL/TLS ابر آروان سبب میشود تا بدون نیاز به هیچ پیکربندی اضافهای، تمامی مزایای عملکردی HTTP/2 برای کاربران فراهم آید.