موضوع مقاله: پروتکل انتقال ابرمتن نگارش ۲ | مخاطب: عمومی | لحن: دانشنامه‌ای | ساختار: عنوان، مقدمه، 3 بخش، جمع‌بندی | مقاله: | # پروتکل انتقال ابرمتن نگارش ۲ | مقدمه: HTTP/2 توسط کار گروه پروتکل انتقال ابر متن موسوم به httpbis (که در آن به معنی "دوم") است توسعه داده شده‌است که این کارگروه خود بخشی از نیروی ضربت مهندسی اینترنت است. | ## بخش 1: پروتکل انتقال ابرمتن نگارش ۲ | کار گروه، HTTP/2 را در دسامبر ۲۰۱۴ جهت در نظر گرفته شدن به صورت یک استاندارد پیشنهادی به گروه راهبری مهندسی اینترنت ارائه کردند و این نهاد در هفده فوریه ۲۰۱۵ اجازه انتشار آن را به عنوان یک استاندارد پیشنهادی صادر نمود. این استاندارد توسط مرورگرهای کروم، اپرا، فایرفاکس، اینترنت اکسپلورر ۱۱، سافاری ،آمازون سیلک و ادج پشتیبانی شده‌است. از پایان سال ۲۰۱۵، اکثر مرورگرهای اصلی پشتیبانی از HTTP/2 را به قابلیت‌هایشان افزوده‌اند. اهداف در منشور کارگروه چند هدف و موضوع قابل توجه ذکر شده‌است: ایجاد یک مکانیسم گفتگو که به کلاینت‌ها و سرورها اجازه می‌دهد تا انتخاب نمایند که از HTTP 1.1, 2.0 یا به‌طور بالقوه پروتکل‌های دیگر غیر ازHTTP استفاده نمایند. فراهم کردن سطح بالایی از سازگاری با HTTP 1.1 (برای مثال با متدها، کدهای وضعیت ،Uriها و اغلب فیلدهای سرآیند). کاهش زمان تأخیر به منظور بهبود سرعت لود صفحه در مرورگرهای وب با توجه به: فشرده سازی داده‌ها ی HTTP headers HTTP/2 فشار سرور خط لوله سازی درخواستها رفع مشکل مسدودسازی سر خط در HTTP 1.x تسهیم درخواست‌های متعدد بر روی یک اتصال TCP پشتیبانی از موارد استفاده عمومی موجود HTTP، مانند مرورگرهای وب دسکتاپ، مرورگرهای وب موبایل، رابط‌های برنامه‌نویسی کاربردی وب، وب سرورها در مقیاس‌های مختلف، پروکسی سرورها، پروکسی معکوس سرورها، فایروال‌ها و شبکه‌های تحویل محتوا. تفاوت‌ها از HTTP 1.1 تغییرات پیشنهادی نیاز به هیچ گونه تغییراتی در چگونگی کارکرد برنامه‌های کاربردی وب موجود ندارند، اما برنامه‌های جدید می‌توانند از ویژگی‌های جدید برای افزایش سرعت استفاده کنند. آنچه جدید است این است که چگونه داده‌ها قاب‌بندی شده و بین کلاینت و سرور انتقال داده شوند. وب سایت‌هایی که کارآمد هستند، تعداد درخواست‌های مورد نیاز برای رندر کردن کل صفحه را با عمل خلاصه‌سازی کد منبع (کاهش مقدار کد و بسته‌بندی قطعات کوچکتر از کد را در بسته‌های نرم‌افزاری، بدون کاهش توانایی عملکرد کد) مثلاً در مورد تصاویر و اسکریپت‌ها، به حداقل می‌رسانند. HTTP/2 به سرور اجازه می‌دهد تا محتوا را «فشار» دهد، این کار سبب می‌شود که داده لازم برای پاسخ به مواردی که پرس‌وجوها بیشتر از آنچه کلاینت حقیقتاً درخواست کرده هستند، فراهم گردد. این کار به سرور اجازه می‌دهد تا داده‌هایی را که می‌داند یک مرورگر وب برای ارائه یک صفحه وب به آن‌ها نیاز خواهد داشت، بدون انتظار برای اینکه مرورگر به بررسی پاسخ اولیه بپردازد و بدون سربار اضافی برای یک چرخه درخواست اضافه تر، برای آن تأمین نماید. افزون بر این، بهبودهای عملکرد دیگری هم در اولین پیش‌نویس از HTTP/2 (که یک کپی از SPDY بود) از طریق تسهیم درخواست‌ها و پاسخ‌ها به منظور جلوگیری از مشکل مسدودسازی سر خط در HTTP 1 (حتی زمانی که خط لوله سازی HTTP استفاده شده‌است)، فشرده سازی سرآیند و اولویت بندی درخواست‌ها حاصل شده‌است.HTTP/2 دیگر از مکانیسم انتقال رمزگذاری تکه بندی شده HTTP 1.1 را پشتیبانی نمی‌کند و به جای آن مکانیسم کارآمدتر خودش را برای جریان دهی داده‌ها استفاده می‌کند. | ## بخش 2: پروتکل انتقال ابرمتن نگارش ۲ | پیدایش از روی SPDY و تفاوتهای بعدی با آن SPDY (تلفظ مانند "اسپیدی") بود یک پروتکل جایگزین قبلی برای HTTP بود که توسط یک پروژه تحقیقاتی پیشگام توسط گوگل توسعه یافته بود. SPDY در درجه اول بر کاهش زمان تأخیر متمرکز شده بود، از همان خط لوله TCP استفاده می‌کرد، اما به منظور دستیابی به این کاهش از پروتکل‌های متفاوتی استفاده می‌نمود. پایه ای‌ترین تغییرات اعمال شده بر روی HTTP 1.1 برای ایجاد SPDY شامل: «خط لوله سازی صحیح درخواستها بدون محدودیت‌های FIFO، مکانیسم قاب بندی پیامها برای ساده سازی توسعه کلاینت و سرور، فشرده سازی اجباری (شامل سرآیندها)، زمان بندی اولویت‌ها و حتی ارتباط دوسویه» بودند. در ژوئیه ۲۰۱۲ فیس بوک برای هر کدام از این پیشنهادها بازخوردی را ارائه کرد و توصیه نمود که HTTP/2 بر اساس SPDY بنا شود. پیش‌نویس اولیه HTTP/2 در ماه نوامبر سال ۲۰۱۲ منتشر شد و بر مبنای یک کپی مستقیم از SPDY تهیه شده بود. SPDY درخواست‌ها را به دو دسته "کنترل" یا "داده " با استفاده از " پروتکل باینری آسان جهت پارسه کردن با دو نوع قاب" تقسیم می‌کرد. SPDY بهبود چشمگیری را نسبت به HTTP به نمایش گذاشت به طوری که سرعت بارگذاری صفحات بین ۱۱٫۸۱٪ تا ۴۷٫۷٪ سریعتر شده بود. در میان بسیاری از تفاوت‌های مفصل بین پروتکل‌ها، قابل توجه‌ترین تفاوت این است که HTTP/2، به جای استفاده از فشرده سازی پویای مبتنی بر جریان در SPDY، از یک الگوریتم فشرده سازی سرآیند ثابت بر مبنای کد هافمن استفاده می‌کند. این امر به کاهش خطر بالقوه حملات فشرده سازی اوراکل در پروتکل، مانند حملات CRIME کمک می‌نماید. در فوریه ۹، ۲۰۱۵ گوگل اعلام کرد قصد دارد پشتیبانی از SPDY را در مرورگر کروم به نفع پشتیبانی از HTTP/2 حذف نماید؛ که این حذف از مرورگر کروم ۵۱ عملی گردید. اگر چه خود استاندارد نیاز به استفاده از رمزگذاری ندارد، همه پیاده‌سازی‌های اصلی کلاینت (فایرفاکس، کروم، سافاری، اوپرا، اینترنت اکسپلورر، ادج) اعلام کرده‌اند که آن‌ها تنها از HTTP/2 بر روی TLS پشتیبانی می‌کنند که باعث می‌شود رمزگذاری عملاً الزامی باشد. پل هنینگ کمپ توسعه دهنده ای که در فری بی اس دی و ورنیش فعالیت می‌نماید، ادعا می‌کند که استاندارد طی یک زمان‌بندی غیرواقع گرایانه و کوتاه آماده شده که نتیجه آن حذف کلیه مفاهیم جدید در HTTP/2 به جز آن‌ها که در پروتکل SPDY آمده‌اند بوده و در نتیجه سایر فرصت‌ها برای بهینه‌سازی از دست رفته‌اند. | ## بخش 3: پروتکل انتقال ابرمتن نگارش ۲ | هنینگ کمپ از خود پروتکل نیز برای ناپایداری و داشتن پیچیدگی غیر ضروری و بیش از اندازه انتقاد می‌کند. او همچنین می‌گوید که این پروتکل، اصل لایه بندی پروتکلها را، به عنوان مثال با تکثیر کنترل جریان در لایه انتقال (TCP)، نقض می‌کند. رمزگذاری در ابتدا برخی از اعضای کارگروه سعی در تعریف یک نیازمندی جهت رمزگذاری در پروتکل نمودند. طرفداران رمزگذاری اعلام کرده‌اند که این سربار تولید شده توسط رمزگذاری در عمل قابل اغماض است. برای اعضای جامعه منبع باز، انتقاد از رویه رمزگذاری اجباری بر روی یک چارچوب صدور گواهی موجود، چیز جدید و منحصر به فردی نیست. یک کارمند سیسکو در سال ۲۰۱۳ اظهار داشت: که مدل گواهی دهی فعلی برای دستگاه‌های کوچک مانند روترها سازگار نیست، چرا که در مدل فعلی نه تنها نیاز به ثبت نام سالانه و عدم چشم پوشی از هزینه‌های ناچیز برای هر گواهی می‌باشد، بلکه باید این درآمدهای ناچیز طور مستمر در حساب درآمدهای سالانه شرکت تکرار شوند. کارگروه در نهایت بر سر اجباری بودن رمزگذاری به اجماع نرسیدند، اگر چه بیشتر پیاده‌سازی‌های سمت کلاینت به آن نیاز دارند که باعث می‌شود رمزگذاری عملاً مورد نیاز باشد. هم چنین پروتکل HTTP/2 در خصوص عدم پشتیبانی از رمزگذاری فرصت طلبانه با انتقاداتی مواجه شده‌است. رمزگذاری فرصت طلبانه یک معیار جهت مقاومت در برابر نظارت غیر محسوس است که شبیه به مکانیسم STARTTLS می‌باشد که از گذشته در پروتکل‌های اینترنت مانند SMTP موجود بوده‌است. منتقدان اعلام کرده‌اند که پیشنهاد HTTP/2 در تناقض با RFC7258 "نظارت غیرمحسوس یک حمله است " خود IETF می‌باشد، که آن نیز همچنین دارای یک وضعیت بهترین تجربه فعلی می‌باشد. RFC7258/BCP188 اجبار می‌کند که که نظارت غیرمحسوس به عنوان یک حمله در نظر گرفته شود. | ## جمع‌بندی | پروتکل‌های طراحی شده توسط IETF باید گامهایی را جهت محافظت در برابر نظارت غیرمحسوس (برای مثال از طریق استفاده از رمزگذاری فرصت طلبانه) بردارند.