أبرز الميزات
كانت المؤسسة سابقًا مجرد صف لا يمكن أن يضم سوى شخص واحد فقط. الآن أصبحت صفحة تديرها بنفسك: ادعُ زميلًا، وامنحه دورًا، واسمح له بإنشاء مفاتيح تدفع الشركة تكلفتها. كما توقف Proxy Finder عن الرد برسالة "out of tries" وبدأ يحدد العائق الذي واجهه بدقة، بينما قضى Browser الأسبوع في التأكد من أنه يقدم نفس البيانات المتسقة للصفحة في كل مرة.
ما الجديد
مؤسسات يمكنك إدارتها فعليًا
كانت إضافة زميل تعني سابقًا مراسلتنا عبر البريد الإلكتروني، لذلك كانت الفرق تشتري اشتراكين منفصلين.
تمتلك مؤسستك الآن صفحتها الخاصة في Dashboard، مع ثلاثة أدوار محددة. يتحمل المالك (Owner) الاشتراك الذي تُحسب عليه فواتير المفاتيح، لذلك يوجد مالك واحد فقط وتُنقل الملكية عبر التحويل. يتولى المسؤولون (Admins) إدارة الاستخدام والفوترة والأعضاء. ويستخدم الأعضاء (Members) الخدمة مباشرة. تُرسل الدعوات عبر البريد الإلكتروني وتعمل حتى مع من لم يسجل حسابه بعد.
يمكن لأي شخص في المؤسسة إنشاء مفاتيح تابعة لها ونقل مفتاح شخصي إليها، حتى لا يضطر المطور لاستخدام مفتاح شخصي يتحمل تكلفته لعمل يخص الشركة. يُحسب الاستخدام على مفتاح المؤسسة ضمن خطة المالك، ويوضح كل تأكيد الخطة التي تدفع التكلفة. يمكن لأي عضو إعادة تسمية المفتاح، بينما تقتصر إعادة الإنشاء والتعطيل والحذف على المالكين والمسؤولين، لأن هذه الإجراءات توقف فورًا عمل كل زميل يستخدمه.
يعمل فلتر Owner واحد عبر كل من Overview وDetailed Metrics وRecent Activity وقائمة المفاتيح الخاصة بك. بينما تظل أقسام Usage & Limits وBilling شخصية، إذ لا يحق للعضو الاطلاع على حصة المالك.
Proxy Finder يتوقف عن التخمين
كانت رسالة "Download maxTry limit reached" تظهر بنفس الشكل سواء كانت كل نقاط الخروج (exits) محظورة، أو معطلة تمامًا، أو أننا جلبنا الصفحة الحقيقية وتجاهلتها القواعد الخاصة بك. تتطلب هذه الحالات الثلاث حلولًا مختلفة تمامًا.
تحمل المهمة الفاشلة الآن attemptReport: عدد نقاط الخروج التي لم تستجب أبدًا، وعدد النقاط التي رفضها نظام حماية معروف مع تحديد مزودي هذه الأنظمة، وعدد الحالات التي رفضها validate.status الخاص بك، وعدد الحالات التي أرجعت كود HTTP 200 دون وجود أي نظام حماية وفشلت فقط أمام validate.data الخاص بك. وتأتي معها جملة ملخصة واضحة.
لكن هذا الإحصاء الأخير هو الأهم. فقاعدة المحتوى التي لا يمكن مطابقتها تبدو تمامًا كالحظر من جميع الجوانب التي اعتدنا قياسها، ولن تنجح أي إعادة محاولة في إصلاحها. (مزيد من التفاصيل حول كيفية تحديد قواعد validate لحالة النجاح.)
لذا فإن النصف الآخر يتعلق بملف التعريف (profile). كان Proxy Finder يقوم بتدوير نقاط الخروج دون تغيير بصمة العميل، لذا فإن الموقع الذي يرفض ملف تعريف متصفح معين كان يرفضه عند كل نقطة خروج في المجموعة. الآن، يؤدي الرفض إلى تغيير ملف التعريف أثناء إعادة المحاولة المجدولة أصلًا، وبالتالي لا يتغير عدد الطلبات والكريديت لكل مهمة. إذا قمت بتثبيت profile يدويًا، فلن يتغير أي شيء. تذكر أنه مع أصعب الأهداف، تظل نقطة الخروج التي تصل إليها أكثر أهمية من ملف التعريف الذي ترسله.
Browser ينهي تعارض البيانات
كان طلب User-Agent من Browser أسوأ من عدم طلبه. كانت هناك ثلاث طبقات، لكل منها تصورها الخاص عن هوية صاحب الـ request، مما جعل الـ request الواحد ينتحل نظام Windows وMac وإصدارا لا يعمل في الـ fleet في آن واحد. أصبح الآن قيمة واحدة، تُحدد مرة واحدة، وتُمرر في كل مكان: عند التشغيل، وفي الصفحة، وفي الـ workers التي تبدأها الصفحة.
تُشتق الـ Client hints من تلك السلسلة، لذا يتطابق معها كل من sec-ch-ua، والمنصة وnavigator.platform. تُرجع الـ response السلسلة التي أرسلناها بالفعل، وهو أمر مهم لأن ملفات تعريف الارتباط clearance مرتبطة بنقطة الـ exit والـ User-Agent معا. كما أصبح استعلام الـ renderer يُرجع النتيجة نفسها في المستند وفي worker، وهي واحدة من الإشارات الضعيفة الإضافية التي تتراكم.
وصلت ثلاث تحسينات أخرى معها:
- تتبع الساعة نقطة الـ exit. يعمل Browser في المنطقة الزمنية للبلد الذي توجد فيه نقطة الـ exit الخاصة بك، لذا تعرض الصفحة التي تُصيّر التوقيتات المحلية ما يراه الزائر من هناك. وعندما يكون البلد غير معروف، تُترك الساعة دون تغيير.
- يبقى WebRTC على نفس المسار كأي شيء آخر. يغطي إعداد الـ proxy ما يرسله المتصفح عبر TCP. لا يقع WebRTC ضمن ذلك المسار، لذا فإن الصفحة التي تطلب منه ICE candidates تتلقى إجابة منفصلة. يقوم Browser بإيقاف ذلك عندما يتضمن الـ request نقطة exit.
- تستهلك عناوين الـ URL التي تحتوي على Anchors التكلفة الفعلية المفترضة. كان عنوان الـ URL الذي ينتهي بـ
#reviewsيستنفد المهلة المحددة دائما. لقد عاد الآن إلى السرعة الطبيعية.
مسارات أقل تكلفة، وDashboard بحسابات دقيقة
يحقن Imperva نصه البرمجي في الصفحات السليمة، وليس فقط في صفحات الرفض، ولم يتمكن Auto من التمييز بينهما، مما أدى إلى تصعيد الصفحات السليمة إلى متصفح دون داع. في أحد مواقع تأجير السيارات، كلف ذلك 75 رصيدا و27.5 ثانية عبر ست محاولات؛ وأصبح الآن محاولة واحدة، و10 أرصدة، ونحو ست ثوان ونصف. تمنحك بعض المواقع session داخل الرفض الذي تجيب به على request بدون session، وتقوم المحركات الأربعة الآن بإعادة إرساله مباشرة قبل التصعيد.
كانت بطاقة الأرصدة في Overview تعرض كل ما تم إنفاقه وتصنفه على أنه مفوتر. في ظل نموذج الدفع مقابل النجاح يختلف هذان الرقمان، والفرق بينهما يمثل تكلفة فعلية، لذا يظهر كلاهما على البطاقة: المفوتر كالرقم الأساسي، والمنفق تحته، لكل منتج وفي المجموع. تُقسم بطاقة Requests بالطريقة نفسها. كما أصبحت عناصر التحكم في الفترة والتفاصيل منفصلة أيضا، من 30 دقيقة إلى عام بالإضافة إلى نطاق مخصص، مستغنية عن الزر الذي كان يحمل النص "1D" ويفتح ثلاثين يوما.
في Playground، يقدم زر carry الآن الـ profile من الـ response الأخيرة، بحيث يعيد الـ request الذي أُرسل تحت profile لم تدخله تشغيل الإصدار الذي نجح. تتوفر جميع المعاملات في مرجع API.
تفاصيل تقنية
يحتفظ Proxy Finder بسجل أطول لكل مضيف: 32 منفذ خروج بدلا من اثني عشر. في اختبار A/B مباشر، كان الأداء متماثلا على الأهداف السهلة وأفضل على الأهداف الصعبة، حيث انخفض متوسط الوقت للوصول إلى الصفحة من 5.5 ثوان إلى 3.8 ثوان دون أي تغيير في زمن الاستجابة على مستوى الأسطول بالكامل. سلك هدف واحد مسارا عكسيا ولا نعرف السبب بعد، لذا خصصنا له قياسات مستقلة.
المهمة التي ستفشل، ستفشل في كل الأحوال. الفارق الحقيقي هو ما إذا كنت ستغلق التذكرة في دقيقة واحدة أو تقضي فترة ما بعد الظهيرة في قياس الشيء الخطأ.