ل توسعه دهندگان Chrome اعلام کردند که قصد دارند پشتیبانی خود را متوقف کنند مکانیسم سرور را در پروتکل های HTTP / 2 و gQUIC فشار دهید ، و همچنین عدم اجرای آن برای پروتکل HTTP / 3 که در مرحله تأیید استاندارد است. فناوری Server Push از ابتدا در پروتکل HTTP / 1.1 ارائه نشده است.
دلیل از بین بردن میل به خلاص شدن از شر یک عارضه بزرگ در کد است، در زمینه کمبود تقاضا و فقط پیش نیازهای نظری برای اثربخشی بهینه سازی های مبتنی بر Push Server.
فناوری Server Push در استاندارد HTTP / 2 تعریف شده است و هدف آن بهینه سازی بارگذاری داده است.
علاوه بر مرورگرهای مبتنی بر موتور Chromium ، پشتیبانی از Server Push در حال حاضر در Firefox و Safari و در سمت سرور در nginx و Apache httpd پیاده سازی شده است.
با سرور فشار ، سرور می تواند منابعی را برای مشتری ارسال کند بدون اینکه منتظر درخواست صریح شما باشد. فرض بر این است که به این ترتیب سرور می تواند بارگذاری صفحه را سرعت ببخشد ، زیرا پرونده های CSS ، اسکریپت ها و تصاویر لازم برای ارائه صفحه در صورت درخواست مشتری از قبل به سمت خود منتقل می شوند.
مشتری یک صفحه خاص را متصل و درخواست می کند ، پس از آن سرور ، بر اساس پیکربندی یا محتوای سرآیند پیوند ارسال شده توسط مشتری ، انتقال منابع خاصی را از طریق اتصال HTTP / 2 که قبلاً ایجاد شده است آغاز می کند ، بدون اینکه منتظر درخواست این منابع از مشتری باشد. مشتری .
محتوای منتقل شده از طریق تماس فشاری در سمت سرویس گیرنده در یک حافظه پنهان ویژه مرتبط با اتصال HTTP / 2 فعلی ذخیره می شود.
هنگامی که مشتری در حال ارائه یک صفحه ، درخواست منابع مرتبط با آن (css ، js ، تصاویر و غیره) را می یابد ، قبل از ارسال واقعی هر درخواست بررسی حافظه پنهان انجام می شود. اگر منبع قبلاً توسط سرور منتقل شده باشد و در حافظه نهان باشد ، سرویس گیرنده بدون درخواست خارجی از سرور ، این منبع را از حافظه پنهان محلی بارگیری می کند.
HTTP / 3 یک پروتکل شبه RFC است که فشار سرور را نیز تعریف می کند.
Chrome در حال حاضر از مدیریت انتقال فشار از طریق HTTP / 2 و gQUIC پشتیبانی می کند و هدف از این کار حذف پشتیبانی از هر دو پروتکل است. Chrome از فشار دادن HTTP / 3 پشتیبانی نمی کند و افزودن پشتیبانی در نقشه راه نیست.
حفظ چنین حافظه پنهانی اجرای آن را بسیار دشوار می کند سرور از سمت سرویس گیرنده فشار می آورد ، اما در مقایسه با درخواست منبع پیشگیرانه از طریق برچسب "پیش بارگیری" منجر به شتابدهی بار قابل توجهی نمی شود و طبق برخی مطالعات ، حتی تأخیر را افزایش می دهد.
طبق آمار گوگل ، فناوری Server Push به درستی توزیع نشده است. به عنوان مثال ، در 28 روز گذشته ، 99,95٪ از اتصالات HTTP / 2 از Server Push استفاده نکرده اند. شاخص های مشابهی در طول مطالعه در ژوئن 2019 مشاهده شد ، یعنی رشد در استقرار Server Push وجود ندارد.
همچنین ، امسال فقط 40٪ از پیام های دریافت شده توسط Server Push توسط مرورگر استفاده شده است و دو سال پیش این رقم 63,51٪ بود (پیام های خام اشتباه بود ، با صفحه پردازش شده مطابقت نداشت یا قبلاً در حافظه پنهان بود) .
به جای Server Push ، بار را بهینه کنید از صفحه ، قصد دارد از برچسب استفاده کند ، بر اساس آن مرورگر می تواند منبعی را بدون انتظار برای استفاده از آن در صفحه درخواست کند.
از یک طرف ، پیش بارگیری ، در مقایسه با Server Push ، منجر به تبادل بسته غیر ضروری (RTT) می شود ، اما از طرف دیگر ، از ارسال منابعی که از قبل در حافظه پنهان مرورگر هستند ، جلوگیری می کند.
به طور کلی ، اختلاف زمان تأخیر هنگام استفاده از Server Push و پیش بارگیری قابل اغماض است. علاوه بر بهینه سازی بار منابع ، از مکانیسم Server Push می توان برای انتقال داده از سرور به سرویس گیرنده نیز استفاده کرد ، اما پروتکل WebTransport (بر اساس QUIC) برای این منظور مناسب تر است ، استاندارد سازی آن در مرحله پیش نویس است .
Fuente:https://groups.google.com
اولین کسی باشید که نظر