قالب Binary
در HTTP/1.1 پیام‌ها میان Client و سرور در قالب پیام‌های متنی ساده (plain text)، تبادل می‌شدند. این عمل، مشکلات امنیتی (هم‌چون Response Splitting Attack) را در پی داشت.
HTTP/2 با تعریف یک لایه‌ی جدید با نام Binary Framing، پیام‌های HTTP را پیش از ارسال، با حفظ Semantic اصلی HTTP، به قالب باینری تبدیل و سپس آن‌ها را ارسال می‌کند. تعریف این لایه‌ی جدید سبب می‌شود تا در مواقعی که یکی از دو طرف ارتباط از HTTP/2 پشتیبانی نمی‌کند، در ارتباط تداخلی ایجاد نشود.
قالب باینری، امکان فریم‌بندی پیام‌ها، کاهش سربار تجزیه و تحلیل آن‌ها، هم‌چنین کاهش خطاهایی که در هنگام تحلیل رخ می‌دهد و استفاده‌ی بهینه از منابع شبکه را فراهم می‌آورد.
Multiplexing
در HTTP/1.1 به‌ازای هر Request، یک ارتباط TCP مجزا برقرار می‌شد. در واقع ذات عملکردی HTTP/1.1، اطمینان از تحویل یک Response در هر ارتباط TCP بود. این ارتباط مجزا به‌ازای هر درخواست، افزون‌بر مصرف پهنای باند بالا، تاخیر در دریافت اطلاعات را نیز افزایش می‌داد.
در HTTP/2 می‌توان در قالب یک ارتباط TCP، چند درخواست را ارسال کرد. در واقع، قالب باینری HTTP/2 این امکان را فراهم می‌آورد که بتوان پیام HTTP را به فریم‌های کوچک‌تری تقسیم و آن‌ها را از طریق یک ارتباط TCP ارسال کرد. در سمت دیگر، این فریم‌ها سرهم می‌شود و پیام اصلی به‌دست می‌آید.
فشرده‌سازی Header
در HTTP/1.1 به‌ازای هر درخواست برای دریافت یکی از منابع مورد نیاز برای Load صفحه، یک HTTP header نیز ارسال می‌شد. از سوی دیگر، سرور نیز به همراه پاسخ ارسالی، یک HTTP Header ارسال می‌کرد. به این ترتیب، برای بارگذاری یک صفحه، میان Client و سرور چند Header تبادل می‌شد که همگی سرباری اضافی به‌شمار می‌آمدند.
HTTP/2 با بهره‌گیری از الگوریتمی با عنوان HPACK اقدام به فشرده‌سازی Headerها می‌کند. قالب باینری HTTP/2 این امکان را فراهم می‌آورد که بتوان Headerها را از داده‌ها جدا کرد و به این ترتیب، فریمی برای Header و فریمی برای Data داشت. HPACK، با فشرده‌سازی فریم‌های Header سبب کاهش حجم اطلاعات مورد تبادل میان Client و سرور می‌شود.
Server Push
با استفاده از این خاصیت، سرور می‌تواند منابع بعدی که Client قرار است Request را در قبال دریافت آن‌ها بفرستد، پیش‌بینی کند و پیش از ارسال درخواست برای دریافت آن‌ها از جانب Client، آن‌ها را برای Client بفرستد. برای نمونه، سرور پس از دریافت Request مربوط به فایل HTML، به‌جای انتظار برای دریافت Requestهای مربوط به فایل‌های CSS، JavaScript و… تمام این منابع را که اطمینان دارد Client برای دریافت آن‌ها درخواستی را ارسال خواهد کرد، برای آن می‌فرستد.
ارسال همه‌ی اطلاعات از جانب سرور پیش از دریافت Request در قبال آن‌ها، ممکن است سبب ارسال اطلاعاتی شود که مرورگر در طی ارتباطی که پیش از این با سرور داشته، آن‌ها را Cache می‌کند و نیازی به دریافت دوباره آن‌ها ندارد. برای حل این مشکل و حفظ منابع شبکه، سرور با ارسال فریمی با نام PUSH-PROMISE منابعی که قصد ارسال آن‌ها را دارد، به Client اطلاع می‌دهد. این فریم در واقع حاوی Header پیام‌هایی است که سرور قصد ارسال آن‌ها را دارد. اگر Client این منابع را در Cache خود بیابد، در پاسخ، فریم RST_STREAM را ارسال می‌کند و ارسال نشدن این منابع را به سرور اطلاع می‌دهد. ارسال فریم PUSH_PROMISE از جانب سرور، از ارسال درخواست‌های تکراری به سرور از جانب Client نیز جلوگیری می‌کند چرا که Client از طریق این فریم، از منابعی که سرور قصد ارسال آن‌ها را دارد، مطلع می‌شود.
Stream Prioritization
روشی که به‌کمک آن مرورگر می‌تواند ترتیب دریافت منابع مورد نیاز خود را مشخص کند. برای نمونه، مرورگر می‌تواند مشخص کند که ابتدا فایل HTML، سپس CSS، بعد JS و… را دریافت کند. این عمل سبب سرعت بخشیدن به Render فایل‌ها در مرورگر می‌شود.
Stream Prioritization (اولویت‌دهی به جریان‌ها) مکملی برای Multiplexing است. Multiplexing با فراهم آوردن امکان ارسال درخواست‌ها تنها از طریق یک ارتباط TCP، سبب حذف سربار TCP و Stream Prioritization با مشخص کردن اولویت پاسخ‌های دریافتی، سبب بهینه‌سازی زمان انتقال اطلاعات مابین سرور و مرورگر می‌شود.
برای نوشتن دیدگاه باید وارد بشوید.