آشنایی با برخی چالش‌های مهاجرت به HTTP/2

آشنایی با برخی چالش‌های مهاجرت به HTTP/2

پروتکل 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 متمایز می‌کند و وقتی از آن برای پیاده‌سازی یک وب‌سایت استفاده می‌کنید، بایستی مراقب چه چیزهایی باشید؟ در ادامه 5 مورد از چیزهایی که بایستی در طی مسیر استفاده از 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، این هدر به ازای هر یک از درخواست‌ها، مجدد فرستاده می‌شود. کاهش میزان پهنای باند مورد استفاده هدرها به‌معنی وجود پهنای باند بیشتر برای محتویات واقعی یک صفحهٔ وب است. اما به‌جز نسخه‌های اخیر NGINX، کمتر وب‌سروری را ‌می‌توان یافت که به‌سادگی از قابلیت HPACK پشتیبانی کند.

همان‌طور که وب‌سایت 99designs کشف کرد، سایر سرورها، لودبالانسرها و سی‌دی‌انها نیز مشکلاتی در استفاده از 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 در وب سایت‌ها خوشش نمی‌آید؟ مراجعه نمایید.)

برخی مطالعات موردی نشان می‌دهد که بالا آوردن تمام یک سایت روی HTTPS همیشه کار راحتی نیست و حتی پس از انجام این کار، کماکان بایستی از عملکرد صحیح آن مطمئن شویم.

بهینه‌سازی‌ HTTPS مثل اطمینان از این‌که Certificate Chainها بهینه هستند، OCSP فعال است و HSTS فراخوانی شده، می‌تواند عملکرد HTTP را بهبود بخشد (سرویس Qualys SSL Labs ابزار مناسبی برای تست این‌گونه مسائل است.)

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

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

منبع