آشنایی با برخی چالش‌های مرتبط با پروتکل HTTP/2

با وجود کاربرد نسبتاً ساده‌ٔ آن، کماکان مواردی وجود دارند که وقتی HTTP/2 را فعال می‌کنید، بایستی مراقب یکسری چالش‌ها باشد. پیش از این، در مقاله‌ای تحت عنوان HTTP/2 چیست و چه تفاوت‌هایی با HTTP/1 دارا است؟، به بیان خوبی‌های نسخه‌ٔ جدید پروتکل HTTP پرداختیم اما در این مقاله قصد داریم به برخی نقاط ضعف احتمالی HTTP/2 اشاره‌ای داشته باشیم.

HTTP/1.x در سال 1999 به‌ عنوان یک پروتکل استاندارد تحت وب درآمد. در این مدت، ما تجربه‌ٔ سال‌ها استفاده از آن‌ را داشته‌ایم، می‌دانیم که رفتار مرورگرها و سرورها با آن چگونه است و همچنین می‌دانیم چه‌طور باید رفتار آن را بهینه کنیم. در مقابل، HTTP/2 از عمر کوتاه‌تری برخوردار است و طی این مدت، استفاده‌های فراوانی از آن توسط مرورگرها، سرورها و سی‌دی‌ان‌ها به‌ عمل آمده است (CDN مخفف واژگان Content Delivery Network است که به یک شبکهٔ بزرگ از سرورهایی گفته می‌شود که در چندین نقطهٔ دنیا مستقرند. با استفاده از CDN، محتوا باتوجه به موقعیت جغرافیایی کاربر و اینکه وی از چه کشوری به اینترنت متصل است، از طریق نزدیک‌ترین سرور به وی ارائه می‌گردد.)

بنابراین چه چیزی HTTP/2 را از HTTP/1 متمایز می‌کند و وقتی از آن برای پیاده‌سازی یک وب‌سایت استفاده می‌کنید، بایستی مراقب چه چیزهایی باشید؟ در ادامه، پنج مورد از چیزهایی که بایستی در طی پروسهٔ استفاده از HTTP/2 مراقبت آن باشید را با شما به اشتراک خواهیم گذاشت (از این پس، به‌ منظور رعایت اختصار، به‌ جای  HTTP/2 از H2 و به‌ جای HTTP/1 از H1 استفاده خواهیم کرد.)

Network Waterfalls در عین شباهت، متمایزند
وقتی H2 را فعال کردید، یکی از اولین چیزهایی که باید انجام دهید این است که با استفاده از سرویس‌های آنلاین تست سرعت یا ابزار عیب‌یابی مرورگرتان، نگاهی به نمودارهای شبکه بیندازید. این همان جایی است که شما متوجه تفاوت‌های عمده‌ای مابین H1 و H2 خواهید شد. تعداد زیادی از نمودارهای Request/Response عریض‌تر خواهند بود و ریکوئست‌ها ممکن است زمان بیشتری برای دریافت پاسخ از سرور منتظر بمانند.

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

از طرف دیگر، H2 کار کاملاً متفاوتی انجام می‌دهد؛ در واقع، به‌ جای استفاده از چند کانکشن TCP، تنها از یک کانکشن (ارتباط) برای هر سرور استفاده می‌کند و می‌تواند چند درخواست را به‌ صورت هم‌زمان ارسال کند. در ادامه، پاسخ‌ها از طرف سرور ادغام می‌شوند و سرور مسئول بازگرداندن پاسخ‌ها براساس ارجحیت و وابستگی آن‌ها است. بنابراین ممکن است زمان پاسخ‌دهی در Waterfall به‌ دلیل لایه‌بندی شدن پاسخ‌ها توسط سرور برای منابع با ارجحیت یکسان یا صف‌بندی پاسخ‌هایی با ارجحیت پایین‌تر، بیشتر شود. موارد فوق ما را به دومین نکته‌ای می‌رساند که در استفاده از H2 باید به آن دقت کنیم که چیزی نیست جز عمر کوتاه H2.

HTTP/2 هنوز جوان است
پیاده‌سازی H2 در مرورگرها و سرورها مدت زمان مدیدی نیست که صورت گرفته است؛ فلذا عمر استفاده از H2 خیلی زیاد نیست. این پروتکل دارای تغییرات ناگهانی است که به‌ معنی عدم عملکرد بهینهٔ آن‌ است. برای مثال، تعدادی از مرورگرها کاملاً کار ارجحیت‌سازی را انجام نمی‌دهند و تعدادی از سرورها نیز در فشرده‌سازی هِدِرها عملکرد خوبی از خود نشان نمی‌دهند!

فشرده‌سازی هِدِر (از طریق HPACK) یکی از اجزای کلیدی H2 است. تعداد زیادی از درخواست‌ها و پاسخ‌های سورس یک صفحه شامل هِدِرهای تکراری است. به‌ عنوان مثال، هِدِر user-agent باید برای تمامی درخواست‌ها یکی باشد اما در H1، این هِدِر به ازای هر یک از درخواست‌ها، مجدد فرستاده می‌شود. کاهش میزان پهنای باند مورد استفادهٔ هِدِرها به‌ معنی وجود پهنای باند بیشتر برای محتویات واقعی یک صفحهٔ وب است. 

بر اساس برخی مشاهدات، یکسری از سرورها، لودبالانسرها و سی‌دی‌ان‌ها نیز مشکلاتی در استفاده از H2 دارند. بنابراین ضروری به‌ نظر می‌رسد که با استفاده از ابزارهایی که برای این‌ کار در نظر گرفته شده‌اند، ابتدا به ساکن مطمئن شویم که سرور ما چه ویژگی‌هایی را ساپورت می‌کند و چه کمبودهایی دارد.

Server Push یک گلوله جادویی نیست!
H2 همچنین تکنیک‌هایی را ارائه می‌کند که به ما اجازه می‌دهد سرعت لودینگ صفحه‌ها را بالاتر ببریم که Server Push قابل‌توجه‌ترین آن‌ها است. پروتکل H1 بر اساس مدل اصطلاحاً Push کار می‌کند؛ بدین صورت که مرورگر ریکوئستی برای دریافت یک صفحه و همچنین منابعی که این صفحه احتیاج دارد را ارسال می‌کند؛ اما در اغلب موارد، سرور منابعی را که یک صفحه نیاز دارد از قبل می‌داند و چه نیازی به یک سفر رفت و برگشت بی‌مورد و تلف کردن زمان وجود دارد وقتی که سرور می‌تواند منابع مورد نیاز را مستقیماً ارسال کند؟

در حال حاضر Server Push یک ابزار کندکنندهٔ سرعت است؛ سرور راهی برای دانستن آنچه که قبلاً در کَش مرورگر وجود دارد نداشته، بنابراین ممکن است مقدار بسیار زیادی دادهٔ اضافه ارسال کند. همچنین ارسال منابع مد نظر از طریق سرور پوش باعث ایجاد رقابت برای پهنای باند بین منابع مختلف برای لود شدن یک صفحهٔ وب می‌شود. به همین دلایل، احتمالاً بهترین راه این است که چیزهای ضروری که باعث عدم لود صحیح صفحه می‌شوند را با استفاده از سرور پوش از سرور گرفته و به مرورگر اجازه بدهیم الباقی چیزها را خود ارجحیت‌بندی کند چرا که مرورگر به‌ خوبی کارش را بلد است.

تعدادی از بهینه‌سازی‌های HTTP/1.x هنوز وجود دارند
سؤالی که در اینجا پیش می‌آید این است که آیا استراتژی‌هایی مانند یکپارچه کردن فایل‌ها در یکدیگر (مثلاً فایل‌های CSS و JS) و تقسیم‌بندی محتویات بین چندین دامنه‌ برای بهبود زمان لود کردن هنوز مناسب هستند؟ در ابتدا، فکر می‌شد زمانی که سایت‌ها به H2 مهاجرت پیدا کردند، دیگر نیازی به این تکنیک‌ها نخواهد بود اما تعدادی از آن‌ها هنوز هم مفید هستند. به‌ عنوان مثال، ترکیب فایل‌های متنی مثل CSS یا JS با یکدیگر منجر به فشرده‌سازی بهتر می‌شود (حداقل با gzip) که در‌ نهایت حجم کم‌تری از دیتا باید توسط مرورگر دانلود شود.

وقتی که دولوپرها از H2 استفاده می‌کنند، Sharding مسئله‌ای است که بایستی در مورد آن دقت کنند. در ایجاد هر کانکشن TCP، یک سربار وجود دارد و H2 راهی برای ارجحیت‌بندی داده‌ها در بیش از یک کانکشن ندارد و این مسئله‌ای است که بایستی به‌ درستی هَندل شود (به‌ طور خلاصه، منظور از Sharding این است که منابع مختلف برای لود یک صفحهٔ وب را مابین دامنه‌های مختلف تقسیم‌بندی کرده تا سرعت لودینگ صفحات وب‌سایت بهبود یابد؛ واژهٔ‌ Shart به‌معنی «جزئی از یک کل» است.) 

عملکرد HTTPS اهمیت دارد
با وجود اینکه H2 اجباری در رابطه با استفاده از پروتکل امن HTTPS ندارد، اما اکثر مرورگرها تنها زمانی H2 را ساپورت می‌کنند که روی HTTPS ارائه شود و این در حالی است که در گذشته ممکن بود فقط بخشی از یک سایت با HTTPS ایمن شده باشد، اما الان مجبور هستیم برای اینکه از H2 استفاده کنیم، کل سایت را روی پروتکل HTTPS بالا بیاوریم (البته مهاجرت به HTTPS اصلاً چیز بدی نیست چرا که حریم خصوصی کاربران وب‌سایت به‌ مراتب بیشتر حفظ خواهد شد؛ برای درک بهتر این موضوع، توصیه می‌کنیم به مقالهٔ چرا گوگل از پروتکل HTTP در وب سایت‌ها خوشش نمی‌آید؟ مراجعه نمایید.)

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