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