Uyumsuzluk, açıkça ifade edilirse
İnsan web trafiğinin bir şekli vardır. Patlamalı, oturuma bağlı ve kendini sınırlayan bir yapıdadır: bir kişi bir sayfa açar, okur, tıklar ve sonunda durur. Tarayıcılar binlerce URL'ye paralel olarak dağılmaz ve 429 ile karşılaşan bir insan genellikle vazgeçer ya da bekler. Son yirmi yıldır kapasite planlaması bu varsayım üzerine kurulmuştur.
Agent trafiğinin şekli farklıdır. Paraleldir, kalıcıdır ve çoğaltılması ucuzdur. Tek bir orkestratör, her biri aynı istek desenini birçok kaynak adresi üzerinden yansıtan, başarısızlıkta yorulmadan yeniden deneyen ve bir retrieval planını işlerken oturumu saatlerce açık tutan alt-agent'lar üretebilir. Bir istek daha göndermenin maliyeti neredeyse sıfırdır, dolayısıyla doğal denge "kibarca oku ve git" değil — "bir şey pes edene kadar yeniden dene"dir.
Bu uyumsuzluk artık her iki tarafta da görünür durumda. Referans materyali yayımlayan siteler, okuyuculara hiç benzemeyen davranış sergileyen otomatik istemciler tarafından istila edildiklerini bildiriyor; diğer siteler ise agent erişimini açık şartlar ve teknik kontroller arkasına kapatmaya başladı. Literatür başarısızlık modunun her iki yarısını da gösteriyor: bir referans sitesini bunaltan agent'lar ve operatörlerin buna makine erişimini toptan kısıtlayarak yanıt vermesi. İki sonuç da istikrarlı bir tasarım değildir.
Kök neden hacim değildir. Kök neden, sitenin istemcinin ne yaptığı hakkında hiçbir fikri olmaması ve istemcinin bunu söyleme yükümlülüğünün bulunmamasıdır.
IP tabanlı hız sınırlaması neden yanlış istemciyi varsayar
Hız sınırlamalarının çoğu, tarayıcı gibi davranan bir istemci için yazılır. IP adresi veya API anahtarı üzerinden anahtarlama yapar, bir token bucket uygular ve Retry-After ile birlikte 429 döndürür. Bir tarayıcı için bu kapalı bir döngüdür: insan hatayı görür, sekme yüklenmeyi durdurur, bucket yeniden dolar.
Agent'lar bu döngünün her parçasını kırar.
- Yeniden denemeler backoff niyetini yok sayar. 429'u geçici bir hata olarak ele alan bir istemci kütüphanesi yeniden dener; çoğu zaman alt-agent'lar arasında çoğalan jitter'lı üstel backoff ile.
- Fan-out, IP anahtarlamayı etkisiz kılar. Adresler, bölgeler veya egress havuzları arasında yansıyan bir iş yükü, tek bir agresif istemci yerine birçok uslu istemci gibi görünür.
- Yansıtma, endpoint başına limitleri etkisiz kılar. Limit path başına ise agent işi path'ler arasına yayar. Anahtar başına ise agent anahtarlar arasına yayar. Limit, ancak bağlı olduğu kimlik kadar iyidir.
Daha kötüsü, IP tabanlı limitler yanlış tarafı cezalandırır. Paylaşılan bir NAT, bir kurumsal proxy veya bir CI runner, arkasındaki tek bir iş yükü kötü davrandığı için kısıtlanabilir. Limit gerçektir, ama hesap verebilirlik yoktur.
Bir kabul sözleşmesi neler içerir
Alternatif, agent isteklerini anonim HTTP olarak ele almayı bırakıp müzakere edilmiş bir iş yükü olarak ele almaya başlamaktır. Kabul sözleşmesi, ilk gerçek istek bir origin servisine ulaşmadan önce kurulan küçük ve açık bir anlaşmadır. Üç bölümü vardır.
Beyan edilen amaç ve kapsam, bir iş yükü kimliğine bağlı
Sözleşme, istemcinin ne yaptığını ve hangi kaynakları kapsadığını belirtir. Kritik olan, kopyalanabilen, paylaşılabilen veya sızdırılabilen statik bir API anahtarına değil, çalışan iş için doğrulanabilir bir kimlik bilgisi olan bir iş yükü kimliğine bağlı olmasıdır. Bir API anahtarı bir tenant'ı tanımlar; bir iş yükü kimliği bir görevi tanımlar. Bu ayrım önemlidir çünkü bütçeler, amaçlar ve iptaller görevlerin özellikleridir, organizasyonların değil.
Kapsam, serbest metin bir açıklama olarak değil, izin verilen işlemler ve kaynak önekleri kümesi olarak ifade edilmelidir. "/docs/ altındaki dokümantasyonu getir" uygulanabilirdir. "Araştırma asistanı" değildir.
Sitenin kendi terimleriyle bir eşzamanlılık ve istek bütçesi
Bütçe, istemcinin tercih ettiği birimlerle değil, sitenin kontrol ettiği birimlerle ifade edilmelidir. Bu şu anlama gelir:
- yalnızca saniyedeki istek sayısı değil, uçuştaki maksimum istek sayısı;
- sözleşmenin ömrü boyunca toplam istek hakkı, böylece uzun süreli bir iş sessizce sınırsız kapasite tüketemez;
- durum değiştiren işlemler için ayrı ve daha küçük bir hak.
Bütçeyi sitenin terimleriyle ifade etmek onu savunulabilir kılan şeydir. Bir istemci, kendi "tek mantıksal sorgu" anlayışının elli upstream çağrısına karşılık gelmesi gerektiğini savunamaz.
Çalışma sırasında işleyen sona erme ve iptal
Sözleşmeler varsayılan olarak sona erer. Daha da önemlisi, bir iş sürerken iptal edilebilirler ve iptal, bir sonraki düzenleme penceresinde değil, edge'de bir sonraki istekte etkili olur. Çoğu uygulamanın yanlış yaptığı kısım burasıdır: kabulü token düzenleme anında tek seferlik bir kapı olarak ele alırlar, bu da kötü davranan bir istemcinin token sona erene kadar erişimini koruduğu anlamına gelir.
Bir iptal tutamacı, sitenin geçersiz kılabileceği kısa bir tanımlayıcı ve bu geçersiz kılmayı her edge düğümüne yayan bir kontrol düzlemidir. İstemcinin iptali normal, yeniden denenemez bir sonuç olarak ele alması beklenir — backoff uygulanıp 
Sözleşmeyi edge'de sonlandırın
Kabul kararları, origin servislerinin önündeki gateway veya CDN katmanına aittir. Origin'ler müzakere edilmemiş trafiği asla görmemelidir; bir istek bir uygulama sunucusuna ulaştığında sözleşme zaten kontrol edilmiş, bütçe düşürülmüş ve karar kaydedilmiş olur. Bu, uygulamayı servisler arasında tekdüze tutar ve bir ekibin origin'inin korunup diğerininkinin korunmadığı yaygın başarısızlığı önler.
Edge ayrıca eşzamanlılık limitlerini uygulamak için yeterli görüş açısına sahip tek yerdir, çünkü bir iş yükü kimliği için hangi origin'i hedeflediklerinden bağımsız olarak tüm uçuştaki istekleri görür.
Kabul kararlarını yapılandırılmış olaylar olarak kaydedin
Her izin, ret, kısıtlama ve iptal; iş yükü kimliği, sözleşme tanımlayıcısı, işlem sınıfı ve gerekçeyi içeren yapılandırılmış bir olay yaymalıdır. Amaç tanılanabilirliktir: kötüye kullanım, açıklanamayan ve atfedilmesi bir saat süren bir trafik artışı olarak değil, adı konmuş bir sözleşmeyle bir politika ihlali olarak görünmelidir.
Bu aynı zamanda operasyonel konuşmayı değiştirir. "Trafik neden arttı?" diye sormak yerine soru "hangi sözleşme bütçesini aştı ve bu bekleniyor muydu?" haline gelir — bir sahibi ve bir cevabı olan bir soru.
Salt okunur retrieval'ı durum değiştiren çağrılardan ayırın
Okumalar ve yazmalar farklı risk profillerine sahiptir ve farklı haklara sahip olmalıdır. Bir retrieval sözleşmesi geniş, ucuz ve kolayca iptal edilebilir olabilir. Durumu değiştiren bir sözleşme daha güçlü bir hak, ayrı bir bütçe ve ideal olarak açık bir insan veya politika onay adımı gerektirir. Bunları birbirine karıştırmak, bir sayfayı özetlemesi gereken bir agent'ın, elindeki kimlik bilgisinin kapsamı fazla geniş olduğu için bir endpoint'e gönderi yapmasına yol açar.
Somut bir mekanizma: sözleşmeden kısa ömürlü, işlem kapsamlı token'lar düzenleyin ve edge'in, yöntemi ve path'i token'ın beyan edilen işlem sınıfının dışında kalan her isteği reddetmesini sağlayın — altta yatan iş yükü kimliği geçerli olsa bile.
Bunun çözmediği şeyler
Bir kabul sözleşmesi agent'ları güvenilir kılmaz. Onları hesap verebilir ve durdurulabilir kılar. Amacı hakkında yalan söyleyen bir istemci yine yalan söyleyecektir — beyan bir koordinasyon mekanizmasıdır, bir güvenlik sınırı değil.
İşte tam da bu yüzden iptal yolu beyandan daha önemlidir. Dürüst olmayan bir istemci ile origin arasında duran tek şey kendi bildirdiği bir amaç dizesiyse, sistem tiyatrodur. Site iş yükünü çalışma sırasında kesebiliyor, kararı adı konmuş bir sözleşmeye atfedebiliyor ve ihlali yapılandırılmış loglarda görebiliyorsa, o zaman beyan yük taşıyan bir varsayım değil, faydalı bir sinyal haline gelir.
Dürüst ödünleşim sürtünmedir. Bir sözleşme müzakere etmek bir kurulum adımı ekler, istemcilerin bir iş yükü kimliği taşımasını gerektirir ve siteleri iptal için bir kontrol düzlemi sürdürmeye zorlar. Bunu atlayan siteler, agent trafiğini web trafiğiymiş gibi emmeye devam edecek ve karşı taraftaki istemcinin yorulmadığını keşfetmeyi sürdürecektir.