HTTP/2 (در اصل به نام HTTP/2.0) یک بازنگری عمده بر روی پروتکل شبکه ای HTTP میباشد که در وب جهان گستر استفاده میگردد. پروتکل HTTP/2 از پروتکل تجربی SPDY، که توسط گوگل توسعه داده شده، مشتق شدهاست.[۱] HTTP/2[۲] توسط کار گروه پروتکل انتقال ابر متن موسوم به httpbis (که در آن bis به معنی "دوم") است توسعه داده شدهاست که این کارگروه خود بخشی از نیروی ضربت مهندسی اینترنت است. HTTP/2 اولین نسخه جدید HTTP از HTTP 1.1 بود که در سال ۱۹۹۷ در RFC 2068 به صورت یک استاندارد درآمده است. کار گروه، HTTP/2 را در دسامبر ۲۰۱۴ جهت در نظر گرفته شدن به صورت یک استاندارد پیشنهادی به گروه راهبری مهندسی اینترنت ارائه کردند و این نهاد در هفده فوریه ۲۰۱۵ اجازه انتشار آن را به عنوان یک استاندارد پیشنهادی صادر نمود.[۳] مشخصات HTTP/2 تحت عنوان RFC 7540 در مارس ۲۰۱۵ منتشر گردیدند.[۴]
در منشور کارگروه چند هدف و موضوع قابل توجه ذکر شدهاست:[۹]
ایجاد یک مکانیسم گفتگو که به کلاینتها و سرورها اجازه میدهد تا انتخاب نمایند که از HTTP 1.1, 2.0 یا بهطور بالقوه پروتکلهای دیگر غیر ازHTTP استفاده نمایند.
تغییرات پیشنهادی نیاز به هیچ گونه تغییراتی در چگونگی کارکرد برنامههای کاربردی وب موجود ندارند، اما برنامههای جدید میتوانند از ویژگیهای جدید برای افزایش سرعت استفاده کنند.
HTTP/2 بیشتر سینتکس سطح بالای HTTP 1.1، مانند متدها، کدهای وضعیت، فبلدهای سرآیند و Uri را به همان صورت حفظ کردهاست. آنچه جدید است این است که چگونه دادهها قاببندی شده و بین کلاینت و سرور انتقال داده شوند.[۱۰]
وب سایتهایی که کارآمد هستند، تعداد درخواستهای مورد نیاز برای رندر کردن کل صفحه را با عمل خلاصهسازی کد منبع (کاهش مقدار کد و بستهبندی قطعات کوچکتر از کد را در بستههای نرمافزاری، بدون کاهش توانایی عملکرد کد) مثلاً در مورد تصاویر و اسکریپتها، به حداقل میرسانند. اما خلاصهسازی کد منبع نه لزوماً مناسب و نه کارآمد است و ممکن است هنوز نیاز به اتصالات HTTP جداگانه ای برای دریافت صفحه و منابع خلاصهسازی شده داشته باشد. HTTP/2 به سرور اجازه میدهد تا محتوا را «فشار» دهد، این کار سبب میشود که داده لازم برای پاسخ به مواردی که پرسوجوها بیشتر از آنچه کلاینت حقیقتاً درخواست کرده هستند، فراهم گردد. این کار به سرور اجازه میدهد تا دادههایی را که میداند یک مرورگر وب برای ارائه یک صفحه وب به آنها نیاز خواهد داشت، بدون انتظار برای اینکه مرورگر به بررسی پاسخ اولیه بپردازد و بدون سربار اضافی برای یک چرخه درخواست اضافه تر، برای آن تأمین نماید.
افزون بر این، بهبودهای عملکرد دیگری هم در اولین پیشنویس از HTTP/2 (که یک کپی از SPDY بود) از طریق تسهیم درخواستها و پاسخها به منظور جلوگیری از مشکل مسدودسازی سر خط در HTTP 1 (حتی زمانی که خط لوله سازی HTTP استفاده شدهاست)، فشرده سازی سرآیند و اولویت بندی درخواستها حاصل شدهاست.HTTP/2 دیگر از مکانیسم انتقال رمزگذاری تکه بندی شده HTTP 1.1 را پشتیبانی نمیکند و به جای آن مکانیسم کارآمدتر خودش را برای جریان دهی دادهها استفاده میکند.
SPDY (تلفظ مانند "اسپیدی") بود یک پروتکل جایگزین قبلی برای HTTP بود که توسط یک پروژه تحقیقاتی پیشگام توسط گوگل توسعه یافته بود.[۱۱] SPDY در درجه اول بر کاهش زمان تأخیر متمرکز شده بود، از همان خط لوله TCP استفاده میکرد، اما به منظور دستیابی به این کاهش از پروتکلهای متفاوتی استفاده مینمود. پایه ایترین تغییرات اعمال شده بر روی HTTP 1.1 برای ایجاد SPDY شامل: «خط لوله سازی صحیح درخواستها بدون محدودیتهای FIFO، مکانیسم قاب بندی پیامها برای ساده سازی توسعه کلاینت و سرور، فشرده سازی اجباری (شامل سرآیندها)، زمان بندی اولویتها و حتی ارتباط دوسویه» بودند.[۱۲]
کارگروه httpbis پروتکل Google SPDY، پیشنهاد پروتکل مایکروسافتی HTTP Speed+Mobility (بر مبنایSPDY), و ارتقا شبکه-پسند HTTP را مورد تحقیق قرار دادند. در ژوئیه ۲۰۱۲ فیس بوک برای هر کدام از این پیشنهادها بازخوردی را ارائه کرد و توصیه نمود که HTTP/2 بر اساس SPDY بنا شود. پیشنویس اولیه HTTP/2 در ماه نوامبر سال ۲۰۱۲ منتشر شد و بر مبنای یک کپی مستقیم از SPDY تهیه شده بود.
بزرگترین تفاوت میان HTTP/1.1 و SPDY این بود که هر عمل کاربر در SPDY دارای یک "شناسه جریان " بود، که این به معنی وجود تنها یک کانال اتصال TCP از کاربر به سرور است. SPDY درخواستها را به دو دسته "کنترل" یا "داده " با استفاده از " پروتکل باینری آسان جهت پارسه کردن با دو نوع قاب" تقسیم میکرد. SPDY بهبود چشمگیری را نسبت به HTTP به نمایش گذاشت به طوری که سرعت بارگذاری صفحات بین ۱۱٫۸۱٪ تا ۴۷٫۷٪ سریعتر شده بود.
در فوریه ۹، ۲۰۱۵ گوگل اعلام کرد قصد دارد پشتیبانی از SPDY را در مرورگر کروم به نفع پشتیبانی از HTTP/2 حذف نماید؛ که این حذف از مرورگر کروم ۵۱ عملی گردید.
HTTP/2 برای هر دو HTTP Uri (یعنی بدون رمزگذاری) و HTTPS Uri (بر روی TLS یا استفاده از توسعه ALPN که در آن TLS 1.2 یا جدیدتر مورد نیاز است) تعریف شدهاست.
اگر چه خود استاندارد نیاز به استفاده از رمزگذاری ندارد، همه پیادهسازیهای اصلی کلاینت (فایرفاکس، کروم، سافاری، اوپرا، اینترنت اکسپلورر، ادج) اعلام کردهاند که آنها تنها از HTTP/2 بر روی TLS پشتیبانی میکنند که باعث میشود رمزگذاری عملاً الزامی باشد.
فرایند توسعه HTTP/2 و خود پروتکل با انتقاداتی مواجه شدهاند.
پل هنینگ کمپ توسعه دهنده ای که در فری بی اس دی و ورنیش فعالیت مینماید، ادعا میکند که استاندارد طی یک زمانبندی غیرواقع گرایانه و کوتاه آماده شده که نتیجه آن حذف کلیه مفاهیم جدید در HTTP/2 به جز آنها که در پروتکل SPDY آمدهاند بوده و در نتیجه سایر فرصتها برای بهینهسازی از دست رفتهاند. هنینگ کمپ از خود پروتکل نیز برای ناپایداری و داشتن پیچیدگی غیر ضروری و بیش از اندازه انتقاد میکند. او همچنین میگوید که این پروتکل، اصل لایه بندی پروتکلها را، به عنوان مثال با تکثیر کنترل جریان در لایه انتقال (TCP)، نقض میکند. با این وجود بیشترین نگرانیها مربوط به مسائل رمزگذاری میشوند.
در ابتدا برخی از اعضای کارگروه سعی در تعریف یک نیازمندی جهت رمزگذاری در پروتکل نمودند. این کار با انتقاداتی مواجه شد.
منتقدان اعلام کردند که رمزگذاری هزینههای رایانشی غیرقابل چشم پوشی در برخواهد داشت و بسیاری از برنامههای کاربردی HTTP در واقع نیاز به رمزگذاری ندارند و ارائه دهندگان هیچ تمایلی به صرف منابع اضافی بر روی آن نخواهند داشت. طرفداران رمزگذاری اعلام کردهاند که این سربار تولید شده توسط رمزگذاری در عمل قابل اغماض است.[۱۳] پل هنینگ کمپ از IETF به خاطر پیروی از یک رویه سیاسی خاص در مورد HTTP/2 انتقاد نمود.[۱۴][۱۵][۱۶] برای اعضای جامعه منبع باز، انتقاد از رویه رمزگذاری اجباری بر روی یک چارچوب صدور گواهی موجود، چیز جدید و منحصر به فردی نیست. یک کارمند سیسکو در سال ۲۰۱۳ اظهار داشت: که مدل گواهی دهی فعلی برای دستگاههای کوچک مانند روترها سازگار نیست، چرا که در مدل فعلی نه تنها نیاز به ثبت نام سالانه و عدم چشم پوشی از هزینههای ناچیز برای هر گواهی میباشد، بلکه باید این درآمدهای ناچیز طور مستمر در حساب درآمدهای سالانه شرکت تکرار شوند.[۱۷] کارگروه در نهایت بر سر اجباری بودن رمزگذاری به اجماع نرسیدند، اگر چه بیشتر پیادهسازیهای سمت کلاینت به آن نیاز دارند که باعث میشود رمزگذاری عملاً مورد نیاز باشد.
هم چنین پروتکل HTTP/2 در خصوص عدم پشتیبانی از رمزگذاری فرصت طلبانه با انتقاداتی مواجه شدهاست. رمزگذاری فرصت طلبانه یک معیار جهت مقاومت در برابر نظارت غیر محسوس است که شبیه به مکانیسم STARTTLS میباشد که از گذشته در پروتکلهای اینترنت مانند SMTP موجود بودهاست. منتقدان اعلام کردهاند که پیشنهاد HTTP/2 در تناقض با RFC7258 "نظارت غیرمحسوس یک حمله است " خود IETF میباشد، که آن نیز همچنین دارای یک وضعیت بهترین تجربه فعلی میباشد.[۱۸] RFC7258/BCP188 اجبار میکند که که نظارت غیرمحسوس به عنوان یک حمله در نظر گرفته شود. پروتکلهای طراحی شده توسط IETF باید گامهایی را جهت محافظت در برابر نظارت غیرمحسوس (برای مثال از طریق استفاده از رمزگذاری فرصت طلبانه) بردارند. تعدادی پیشنویس مشخصات برای رمزگذاری فرصت طلبانه HTTP/2 تهیه گردیدند[۱۹][۲۰][۲۱] که از بین آنها draft-nottingham-http2-encryption به عنوان آیتم کاری رسمی توسط کارگروه به تصویب رسید که در نهایت منجر به انتشار RFC 8164 در مارس ۲۰۱۷ گردید.
Apache 2.4.12 supports HTTP/2 via the module mod_h2,[۴۰] although appropriate patches must be applied to the source code of the server in order for it to support that module. As of Apache 2.4.17 all patches are included in the main Apache source tree, although the module itself was renamed mod_http2.[۴۱] Old versions of SPDY were supported via the module mod_spdy,[۴۲] however the development of the mod_spdy module has stopped.[۴۳]
Apache Tomcat supports HTTP/2 with version 8.5 and newer with a configuration change.[۴۴]
Akamai اولین CDN عمده پشتیبانیکننده از HTTP/2 و HTTP/2 فشار سرور . http2.akamai.com اجرای پیادهسازی HTTP/2 از جمله فشار سرور را توسط Akamai به نمایش میگذارد.
CDN77 با استفاده از nginx (۲۰ اوت ۲۰۱۵) از HTTP/2 پشتیبانی میکند . http2demo.io نمایشی از اجرای HTTP/2 توسط CDN77 میباشد.
Cloudflare با استفاده از nginx از HTTP/2 پشتیبانی میکند با SPDY به عنوان یک جایگزین برای مرورگرهای فاقد پشتیبانی در حالی که امنیت و عملکرد خدمات حفظ میشود.[۶۳] Cloudflare اولین CDN عمده بود که از فشار سرور HTTP/2 پشتیبانی کرد.[۶۴]
Fastly از HTTP/2 از جمله فشار سرور پشتیبانی میکند.[۶۶]
Duane baker Incapsula CDN از HTTP/2 پشتیبانی میکند.[۶۷]http2.incapsula.com پیادهسازی HTTP/2 توسط Incapsula را به نمایش میگذارد. پیادهسازی هم چنین شامل پشتیبانی برای WAF و جلوگیری از DDoS نیز میشود.
KeyCDN با استفاده از nginx (اکتبر ۶، ۲۰۱۵) از HTTP/2 پشتیبانی میکند. HTTP/2 تست یک صفحه تست است به منظور بررسی اینکه آیا سرور شما پشتیبانی از HTTP/2 مینماید.