AWS Der Mainframe Modernization Service (Managed Runtime Environment Experience) steht Neukunden nicht mehr zur Verfügung. Funktionen, die dem AWS Mainframe Modernization Service (Managed Runtime Environment-Erfahrung) ähneln, finden Sie unter AWS Mainframe Modernization Service (Self-Managed Experience). Bestandskunden können den Service weiterhin wie gewohnt nutzen. Weitere Informationen finden Sie unter Änderung der Verfügbarkeit von [AWS Mainframe Modernization](https://docs.aws.amazon.com/m2/latest/userguide/mainframe-modernization-availability-change.html). Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Ratenbegrenzung für AWS Transform for Mainframe Runtime konfigurieren AWS Transform for Mainframe Runtime umfasst eine integrierte Funktion zur Ratenbegrenzung, um die Gapwalk-Anwendung vor übermäßigen Anfragen und potenziellem Missbrauch zu schützen. Das System zur Ratenbegrenzung verwendet den Token-Bucket-Algorithmus, um sowohl Burst-Kapazität als auch dauerhafte Ratenbegrenzung bereitzustellen. **Topics** + [Überblick über die Ratenbegrenzung](#ba-runtime-rate-limiting-overview) + [Konfigurationseigenschaften](#ba-runtime-rate-limiting-config) + [Ratenbegrenzung aktivieren](#ba-runtime-rate-limiting-enable) + [Identifizierung des Kunden](#ba-runtime-rate-limiting-client-id) + [Header zur Ratenbegrenzung](#ba-runtime-rate-limiting-headers) + [Speicherverwaltung](#ba-runtime-rate-limiting-memory) ## Überblick über die Ratenbegrenzung Das Ratenbegrenzungssystem bietet die folgenden Funktionen: **Token-Bucket-Algorithmus** + Ermöglicht Burst-Traffic bis zur konfigurierten Burst-Kapazität + Füllt Token mit einer konstanten Geschwindigkeit auf, die auf Anfragen pro Minute basiert + Sorgt für eine reibungslose Ratenbegrenzung, ohne legitime Verkehrsspitzen zu blockieren **Identifizierung des Kunden** + Identifiziert Clients anhand der IP-Adresse mit Proxy-Unterstützung + Unterstützungen X-Forwarded-For und X-Real-IP Header + Behandelt Loadbalancer- und Reverse-Proxy-Szenarien **Automatische Arbeitsspeicher-Verwaltung** + Bereinigt automatisch abgelaufene Ratenlimit-Buckets + Konfigurierbare Säuberungsintervalle und Ablaufzeiten + Beugt Speicherlecks bei Anwendungen mit langer Laufzeit vor **HTTP-Integration** + Gibt HTTP 429 (Too Many Requests) zurück, wenn die Grenzwerte überschritten werden + Schließt Standard-Header für die Ratenbegrenzung in Antworten ein + Stellt Informationen zum erneuten Versuch für Kunden bereit ## Konfigurationseigenschaften Konfigurieren Sie die Ratenbegrenzung in Ihrer Datei: `application-main.yaml` ``` gapwalk: ratelimiting: enabled: true # Enable/disable rate limiting requestsPerMinute: 1000 # Sustained rate limit per minute burstCapacity: 1500 # Maximum burst requests allowed includeHeaders: true # Include X-RateLimit-* headers cleanupIntervalMinutes: 5 # Cleanup interval for expired buckets bucketExpiryHours: 1 # Hours after which unused buckets expire errorMessage: "Too many requests. Try again later." # Custom error message whitelistIps: "" # Comma-separated IPs to bypass limiting perEndpointLimiting: false # Apply limits per endpoint (not implemented) ``` ### Beschreibungen der Immobilien **aktiviert** Hauptschalter zum Aktivieren oder Deaktivieren der Funktion zur Ratenbegrenzung. Standard: `false` **requestsPerMinute** Anzahl der Anfragen, die pro Minute für eine dauerhafte Ratenbegrenzung zulässig sind. Dies entspricht der Token-Nachfüllrate. Standard: `1000` **Burst-Kapazität** Maximale Anzahl von Anfragen, die in einem Burst zulässig sind, bevor die Ratenbegrenzung gilt. Sollte höher sein`requestsPerMinute`, als um Traffic-Spitzen zuzulassen. Standard: `1500` **Header einbeziehen** Ob Header für Standardratenbegrenzungen (`X-RateLimit-Limit`,`X-RateLimit-Remaining`,`X-RateLimit-Reset`) in HTTP-Antworten aufgenommen werden sollen. Standard: `true` **cleanupIntervalMinutes** Intervall in Minuten zwischen der automatischen Bereinigung abgelaufener Ratenlimit-Buckets. Hilft, Speicherlecks zu verhindern. Standard: `5` **bucketExpiryHours** Zeit in Stunden, nach deren Ablauf ungenutzte Ratenlimit-Buckets als abgelaufen gelten und für eine Bereinigung in Frage kommen. Standard: `1` **errorMessage** Benutzerdefinierte Fehlermeldung, die in der JSON-Antwort zurückgegeben wird, wenn das Ratenlimit überschritten wird. Standard: `"Too many requests. Try again later."` **Tipps auf die weiße Liste** Durch Kommas getrennte Liste von IP-Adressen, die die Ratenbegrenzung vollständig umgehen. Nützlich für Integritätsprüfungen oder vertrauenswürdige Systeme. Standard: `empty` **perEndpointLimiting** Gibt an, ob separate Ratenlimits pro Endpunkt statt nur pro Client angewendet werden sollen. Derzeit nicht implementiert. Standard: `false` ## Ratenbegrenzung aktivieren So aktivieren Sie die Ratenbegrenzung mit den Standardeinstellungen: ``` gapwalk: ratelimiting: enabled: true ``` ## Identifizierung des Kunden Das Ratenbegrenzungssystem identifiziert Kunden anhand der folgenden Prioritätsreihenfolge: 1. **X-Forwarded-For Header** (erste IP, wenn durch Kommas getrennt) 1. **X-Real-IP Kopfzeile** 1. **Remote-Adresse** aus der HTTP-Anfrage Auf diese Weise wird eine korrekte Identifizierung des Clients gewährleistet, wenn sich die Anwendung hinter folgenden Umständen befindet: + Load Balancers + Reverse-Proxys + CDNs + API-Gateways ### Beispiel für eine Kundenidentifikation ``` # Direct connection Client IP: 192.168.1.100 # Behind load balancer with X-Forwarded-For X-Forwarded-For: 203.0.113.45, 192.168.1.100 Client IP: 203.0.113.45 (first IP used) # Behind reverse proxy with X-Real-IP X-Real-IP: 203.0.113.45 Client IP: 203.0.113.45 ``` ## Header zur Ratenbegrenzung Wenn `includeHeaders` aktiviert, werden die folgenden Header zu HTTP-Antworten hinzugefügt: **X- RateLimit -Limit** Die Obergrenze des Ratenlimits für den Kunden (Anfragen pro Minute) **X- RateLimit -Verbleibend** Die Anzahl der Anfragen, die im aktuellen Ratenlimitfenster noch übrig sind **X- RateLimit -Zurücksetzen** Der Zeitpunkt, zu dem das Ratenbegrenzungsfenster zurückgesetzt wird (Unix-Zeitstempel) ### Beispiel für Antwortheader ``` X-RateLimit-Limit: 1000 X-RateLimit-Remaining: 847 X-RateLimit-Reset: 1640995200 ``` ### Das Ratenlimit hat die Antwort überschritten Wenn das Ratenlimit überschritten wird, gibt das System Folgendes zurück: **HTTP-Status** 429 Zu viele Anfragen **Content-Type** application/json **Retry-After** Anzahl der Sekunden, die gewartet werden müssen, bevor es erneut versucht wird ``` { "error": "Rate limit exceeded", "message": "Too many requests. Try again later.", "retryAfter": 60, "timestamp": 1640995140000 } ``` ## Speicherverwaltung Das System zur Geschwindigkeitsbegrenzung verwaltet den Arbeitsspeicher automatisch, um Datenlecks bei Anwendungen mit langer Laufzeit zu verhindern: **Automatische Säuberung** + Läuft alle Minuten `cleanupIntervalMinutes` + Entfernt Eimer, die stundenlang unbenutzt waren `bucketExpiryHours` + Protokolliert die Säuberungsaktivitäten zur Überwachung **Speicher-Effizienz** + Verwendet aus Gründen der Thread-Sicherheit parallele Datenstrukturen + Lazy-Bucket-Erstellung (nur bei Bedarf) + Effiziente Token-Bucket-Implementierung ### Überwachung der Säuberungsaktivitäten Suchen Sie in den Protokollen nach Säuberungsmeldungen: ``` INFO RateLimitingService - Cleaned up 15 expired rate limiting buckets ```