המסמך הזה רלוונטי לשיטות הבאות:
בקשות עדכון
כדי למנוע עומס יתר על השרת ולהפיק תועלת מהגנה אופטימלית, Update API (v4) קובע מרווחי זמן לבדיקת התדירות שבה לקוח יכול לשלוח בקשות לשרת הגלישה הבטוחה אל לבצע בדיקות של כתובות URL (fullHashes.find) או לעדכן את מסד הנתונים המקומי (threatListUpdates.fetch).
הבקשה הראשונית לנתונים חייבת להתרחש במרווח אקראי בין 0 ל-1 דקות לאחר הלקוח מתחיל לפעול או מתעורר. הבקשות הבאות יכולות להתרחש רק אחרי משך המתנה מינימלי או מגבלת הזמן של מצב ההשהיה לפני ניסיון חוזר שנמדד.
משך המתנה מינימלי
גם
fullHashes.find, וגם
תגובת threatListUpdates.fetch
יש שדה minimumWaitDuration שהלקוחות חייבים לציית לו.
אם השדה minimumWaitDuration לא מוגדר בתשובה, הלקוחות יכולים
לעדכן לפי הצורך ולשלוח כמה בקשות threatListUpdates או fullHashes לפי
שהם רוצים.
אם השדה minimumWaitDuration מוגדר בתשובה, הלקוחות לא יכולים
מעדכנים בתדירות גבוהה יותר ממשך זמן ההמתנה. לדוגמה, אם התשובה fullHashes
מכיל משך המתנה מינימלי של שעה אחת, אסור ללקוח לשלוח בקשות fullHashes
עד שהשעה הזו מסתיימת, גם אם המשתמש נכנס לכתובת URL שקידומת הגיבוב שלה תואמת
מסד נתונים. (לתשומת ליבכם: לקוחות יכולים לעדכן בתדירות נמוכה יותר ממשך ההמתנה המינימלי, אבל אפשרות זו
עלול להשפיע לרעה על ההגנה.)
מצב השהייה
השהיה אוטומטית לפני ניסיון חוזר (backoff) חלה על fullHashes.find, וגם תגובה של threatListUpdates.fetch.
לקוחות שמקבלים תגובת HTTP שנכשלה (כלומר, כל קוד מצב HTTP מלבד
200 OK) חייבים לעבור למצב של השהיה לפני ניסיון חוזר (backoff). במצב השהיה לפני ניסיון חוזר, הלקוחות צריכים להמתין את הזמן המחושב
משך הזמן לפני שהוא יוכל לשלוח בקשה נוספת לשרת.
לקוחות חייבים להשתמש בנוסחה הבאה כדי לחשב את משך הזמן של השהיה לפני ניסיון חוזר:
MIN((2N-1 * 15 minutes) * (RAND + 1), 24 hours)N מייצג את מספר הבקשות הרציפות שלא נכשלו (מתחיל ב-N=1 אחרי הבקשה הראשונה שנכשלה). RAND הוא מספר אקראי בין 0 ל-1 שצריך לבחור אחרי כל עדכון שנכשל.
לאחר שלקוח מקבל תגובת HTTP מוצלחת, הוא חייב לצאת ממצב השהיה לפני ניסיון חוזר (backoff) ולפעול לפי משך ההמתנה המינימלי שצוינו למעלה.