429 Too Many Requests: Hız Sınırları, Retry-After ve Yanlış Alarmlar

Bir 429 ne anlama gelir ve beraberinde ne gelir

429, RFC 6585'te hız sınırlaması için durum olarak tanımlanır: istemci belirli bir zaman diliminde çok fazla istek göndermiştir. Spesifikasyon kasıtlı olarak iki şeyi açık bırakır: sunucunun istemciyi nasıl tanımladığı, ve isteklerin nasıl sayıldığı. Hız sınırlarının hizmetler arasında bu kadar farklılık göstermesinin nedeni budur.

Pratikte, sunucular IP adresi başına, API anahtarı başına, oturum başına, hesap başına, veya bunların bir kombinasyonu başına sayar, ve sabit pencereler, kayan pencereler veya token kovaları kullanırlar. Bu yüzden aynı sitedeki aynı iki istek hızı bir uç noktada sorunsuz olabilirken diğerinde engellenebilir.

Yanıt, ihtiyacınız olan sinyalleri taşır:

• Retry-After standart olandır. RFC 9110, ya bir saniye sayısına ya da bir HTTP tarihine izin verir, ve iyi davranan bir istemci yeniden denemeden önce o kadar bekler.
• Hız sınırı başlıkları, RateLimit-Limit, RateLimit-Remaining ve RateLimit-Reset gibi, veya daha eski X-RateLimit- varyantları, bütçeyi ve ne zaman sıfırlandığını ortaya çıkarır. Bunlar RFC 9110'un bir parçası değil kurallardır, bu yüzden tam adlar için API dokümantasyonunu kontrol edin.
• Gövde, sınırı insan tarafından okunabilir terimlerle açıklamalıdır. Birçok API, hangi kotanın aşıldığını adlandırır, ki bu çok fazla tahmin etmekten kurtarır.

Bir 429 varsayılan olarak önbelleğe alınabilir değildir, bu yüzden aracılar pencere sıfırlandıktan sonra onu sunmaya devam etmemelidir.

Hız sınırı mı yoksa gerçek bir kesinti mi?

Bunlar sürekli karıştırılır, çünkü ikisi de başarısız istekler olarak görünür. Ayırt edici testler hızlıdır:

• Kodun kendisi. Bir hız sınırı 429 yanıtı verir. Aşırı yüklenmiş veya bakım modundaki bir sunucu 503 yanıtı verir. İkisi de Retry-After taşıyabilir, ki insanların onları karıştırmasının nedeni budur, ama farklı anlamlara gelirler: 429 "sen özellikle çok fazla gönderiyorsun" der, 503 "hizmet bir bütün olarak şu anda iş kabul edemiyor" der. O taraf için 503 rehberine bakın.
• Yanıt süresi. Hız sınırları hızlı reddeder, genellikle milisaniyeler içinde, çünkü karar herhangi bir gerçek iş gerçekleşmeden önce verilir. Aşırı yüklenme yavaş yanıt verir veya zaman aşımına uğrar.
• Kim etkileniyor. Bir hız sınırı tek bir istemci kimliğini vurur. Farklı bir IP adresinden veya farklı bir API anahtarıyla test edin: kısıtlanmış istemci hâlâ başarısız olurken bu başarılı olursa, bu bir kesinti değil bir sınırdır.
• Zaman içindeki örüntü. Hız sınırlaması periyodiktir ve kendi kendine temizlenir. Başarısızlıklar kümelenir, sonra pencere tam olarak sıfırlandığında durur, sonra geri döner. Bir kesinti bir programa göre kibarca devam etmez.
• Kendi hacminizle korelasyon. Başarısızlıklar bir kontrol sıklığını yükselttiğinizde, paralel işçiler eklediğinizde veya bir toplu iş başlattığınızda başladıysa, neden bağlantının sizin tarafınızdadır.

İzlemenin kendi üzerinde neden bir 429 tetikleyebileceği

İzleme, küçük bir adres kümesinden aynı URL'ye tekrarlanan bir istektir, ki bu hız sınırlayıcılarının yakalamak için tasarlandığı şekle yakındır. Çok kısa bir kontrol aralığı bunu kötüleştirir, çünkü her dakika kontrolleri çarpı birçok izlenen URL, IP başına bir bütçeye karşı hızla toplanır. Birçok konumdan aynı anda bir kontrol çalıştırmak da aynı şeyi yapar: kaynak, düzenli bir akış yerine bir patlama görür, ve patlama sınırları önce tetiklenir.

URL seçimi de önemlidir. Arama sayfaları, API uç noktaları ve yazan herhangi bir şey genellikle statik bir ana sayfadan daha sıkı sınırlandırılır. Ve izleme ve uygulama tek bir API anahtarını paylaşırsa, ikisi tek bir kota için yarışır. Sonuç, site tamamen sağlıklıyken siteyi başarısız olarak bildiren bir monitör, ve işini doğru yapan bir hız sınırlayıcıdır.

Bir 429 nasıl düzeltilir

1. Bir şey değiştirmeden önce yanıt başlıklarını okuyun:

   curl -sS -o /dev/null -D - https://example.com/api/items

   Retry-After ve herhangi bir hız sınırı başlığı, aralıkları tahmin etmekten daha iyi gerçek bütçeyi söyler.
2. Retry-After'a saygı gösterin. Hemen yeniden denemek, birçok uygulamada engeli uzatır. Belirtilen süre kadar bekleyin.
3. Eşzamanlı istemcilerin senkronize olup bir gürültülü sürüde yeniden denememesi için istemci kodunda rastgelelikle üstel olarak geri çekilin.
4. İstek hızını düşürün. İzleme için, kontrol edilen bir uç noktayı daha uzun bir aralığa taşıyın, veya birçok konumun aynı saniyede tetiklenmemesi için kontrolleri kademelendirin.
5. Ucuz, temsili bir URL'yi izleyin. Hafif bir sağlık uç noktası veya ana sayfa, gerçek trafik için ihtiyaç duyduğunuz kotayı harcamadan sitenin çalıştığını söyler.
6. İzleme istemcisini sınırlayıcıda muaf tutun. Kontrol noktası adreslerini izin listesine ekleyin, veya izlemeye kendi bütçesi olan kendi API anahtarını verin, böylece üretim trafiğiyle asla yarışmaz.
7. Sınırlayıcının sahibiyseniz, sınırın doğru olduğunu kontrol edin. Bütçenin gerçek kullanımla eşleşip eşleşmediğini, hesap başına olması gerekirken IP başına olup olmadığını, ve paylaşılan proxy'lerin veya kurumsal NAT'ın birçok kullanıcıyı bir adresin arkasına koyup koymadığını sorun.

429'ları onlara neden olmadan izlemek

Hız sınırları genellikle önce en yoğun istemciler için görünür, ki bu ödeme yapan müşterilerin ve entegrasyonların ekibinizdeki herkesten önce onlara çarptığı anlamına gelir. Beklenen durum kodunu onaylayan zamanlanmış bir HTTP kontrolü, dağınık "API kararsız" raporları yerine bir 429'u ayrı, zaman damgalı bir olay olarak gösterir, ve zamanlama size sınırın periyodik mi yoksa kalıcı mı olduğunu söyler. Aralığı kasıtlı olarak ayarlayın: sorunları hızlıca fark edecek kadar sık, kontrolün asla sınırı tetikleyen şey olmayacağı kadar yumuşak. 401 ve 403 dahil daha geniş reddetme ailesi, 4xx genel bakışında ele alınır.