Ein 4D-Webserver, der weiß, wann er „Nein“ sagen muss

Die Feinabstimmung der Auslastung Ihres 4D-Webservers ist jetzt ein Kinderspiel. Ab 4D 21 R5 ist Ihr Webserver nicht mehr der Gefahr einer unbeabsichtigten Überlastung ausgesetzt – sei es durch ein übermäßiges Datenvolumen, zu viele eingehende Anfragen oder eine explosionsartige Zunahme von Gast-Sitzungen.

Lesen Sie weiter und erfahren Sie alles, was Sie wissen müssen, um ein vollständig individuelles System zur Ratenbegrenzung für Ihren Web-App-Server aufzubauen.

In einem früheren Blogbeitrag zu 4D 21 R4 haben wir eine Möglichkeit vorgestellt , die Anzahl der Entitätssätze in einer REST-Sitzung zu begrenzen – das war der Auftakt zu einer viel umfassenderen Entwicklung. Heute erreicht diese Entwicklung einen wichtigen (wenn auch nicht endgültigen) Meilenstein.

Mit 4D 21 R5 lässt sich Ihr 4D Web Server dank Quoten präzise abstimmen, um den ein- und ausgehenden Datenverkehr unter Kontrolle zu halten.

Diese neue Funktion ändert nichts am Standardverhalten Ihres Webservers: Standardmäßig werden keine Quoten angewendet. Je nach Ihren Anforderungen können Sie aus einem umfassenden Angebot an Quoten wählen: Verwenden Sie nur eine oder alle – die Granularität liegt ganz bei Ihnen.

HDI_WebServer_RateLimitingQuotas

Erweiterung des klassischen Webschutzes um Anwendungsintelligenz

Diese Funktion ergänzt – anstatt sie zu ersetzen – Reverse-Proxys, WAFs, Firewalls … und andere Dienste. Diese Technologien schützen den Netzwerkperimeter und filtern böswilligen Datenverkehr, während 4D die Regulierung der Arbeitslast auf Anwendungsebene innerhalb des Webservers übernimmt.

Der Mehrwert liegt in der Berücksichtigung von 4D-Sitzungen und des Anwendungskontexts: Entwickler können globale und sitzungsbezogene Kontingente für Anfragen, Datenvolumina, Sitzungen und Entitätsmengen definieren. Dadurch lassen sich fehlerhafte oder übermäßige Nutzung, MCP-Datenverkehr und geschäftsspezifische Arbeitsabläufe direkt innerhalb der Anwendung steuern.

Quoten auf Server- und Sitzungsebene

Bevor wir ins Detail gehen: Für eine feinere Steuerung können die meisten Quoten auf zwei Ebenen festgelegt werden:

• Server-Ebene: drosselt die Aktivität des gesamten Servers
• Sitzungsebene: gilt individuell für jede neu erstellte Sitzung

Sie können sich entweder ausschließlich auf Quoten auf Serverebene, ausschließlich auf Quoten auf Sitzungsebene oder auf eine Kombination aus beiden verlassen.

Vorteil: Quoten auf Sitzungsebene stellen alle Nutzer gleich und verhindern, dass ein einzelner Nutzer die Ressourcen Ihres Webservers monopolisiert.

Was Quoten regeln können

Mit Quoten können Sie Folgendes begrenzen:

• Eingehender Datenverkehr: Anzahl der empfangenen Bytes, Anzahl der angenommenen Anfragen
• Ausgehender Datenverkehr: Anzahl der gesendeten Bytes
• Sitzungen: die maximale Anzahl aktiver Sitzungen
• Gästesitzungen: die maximale Anzahl von Sitzungen, die noch nicht über ` setPrivileges()` authentifiziert wurden.
• Entitätssätze: die standardmäßig zulässige maximale Anzahl von Entitätssätzen für jede neu erstellte REST-Sitzung

Das Kernprinzip: Sobald eine Quote überschritten wird, antwortet der Server mit einem HTTP-Status 429 – „Too Many Requests“.

Vorteil: Jeder Aspekt, der Ihren Webserver überlasten könnte, wird abgedeckt: nicht nur eingehende und ausgehende Bytes, sondern auch Anfragen. Sie können sowohl inaktive Gast-Sitzungen als auch die Anzahl gleichzeitiger Benutzersitzungen begrenzen.

Quoten drosseln die Auslastung Ihres Webservers auf elegante Weise und signalisieren den Benutzern, dass der Server nicht ausgefallen oder abgestürzt ist, sondern einfach seine Aufgabe erfüllt, indem er die Last reguliert, um zuverlässig verfügbar zu bleiben.

Hinter den Kulissen: zwei Arten von Quoten

Es gibt zwei Arten von Quoten:

• Quoten zur Ratenbegrenzung
• Quoten für gleichzeitige Verbindungen

Quoten zur Ratenbegrenzung

Diese umfassen:

• Anzahl der empfangenen Bytes
• Anzahl der akzeptierten Anfragen
• Anzahl der gesendeten Bytes

Sie basieren auf einem Zeitfenstersystem, sowohl auf Minuten- als auch auf Stundenebene, sodass Sie die maximale Anzahl an Bytes (oder Anfragen) festlegen können, die Ihr Webserver und/oder dessen Sitzungen innerhalb eines Zeitfensters von einer Minute oder einer Stunde verarbeiten können.

Sobald ein Kontingent innerhalb eines Zeitfensters überschritten wird, gibt der Server einen HTTP-429-Fehler zurück, bis das nächste Zeitfenster beginnt.

Diese Quoten können sowohl auf serverseitiger als auch auf Sitzungsebene konfiguriert werden.

Vorteil: Durch die Kombination von Ein-Minuten- und Ein-Stunden-Fenstern erhalten Sie eine sehr fein abgestufte Kontrolle, die minutengenaue Spitzen ausgleicht und gleichzeitig eine stündliche Obergrenze durchsetzt.

Wenden Sie dieselbe Logik auf Sitzungsebene an, und Sie regulieren die Aktivität jedes Benutzers individuell und verhindern so, dass einer von ihnen Ihre gesamte Bandbreite beansprucht.

Quoten für gleichzeitige Verbindungen

Diese umfassen:

• Maximale Anzahl von Sitzungen
• Maximale Anzahl an Gast-Sitzungen
• Maximale Anzahl von Entitätssätzen, die standardmäßig für jede neu erstellte REST-Sitzung zulässig sind

Es handelt sich hierbei um absolute Zähler: Sobald eine Quote überschritten wird, gibt der Server einen HTTP-429-Fehler zurück , bis der Zähler wieder sinkt. Beispielsweise wenn eine Sitzung geschlossen wird und dadurch Platz für eine neue frei wird.

Vorteil: Dies ergänzt die Quoten zur Ratenbegrenzung in idealer Weise, da nicht nur der Datenverkehr, sondern auch die Anzahl der Nutzer reguliert wird.

Einrichten von Quoten

Das WEB Server Objekt stellt eine Eigenschaft „quotas “ bereit, ein Objekt, das genauer gesagt eine Instanz der 4D.QuotaManager Klasse.

Es gibt drei Möglichkeiten, Kontingente zu konfigurieren: Wählen Sie diejenige, die am besten zu Ihrer Architektur passt:

1. Aktualisieren Sie das „quotas “-Objekt im laufenden Betrieb, sobald der Webserver bereits läuft:

var $quotas : 4D.QuotaManager

$quotas:=WEB Server().quotas

$quotas.inBytesPerMin:=10000000

2. Übergeben Sie beim Starten des Webservers ein „quotas“-Objekt:

var $quotas:={}

$quotas.inBytesPerMin:=20000000

WEB Server().start({quotas: $quotas})

3- Verwenden Sie eine HTTPQuotas.json-Konfigurationsdatei, die beim Start automatisch eingelesen wird:

  {
    "inBytesPerMin": 10000
  }

Vorteil: absolute Flexibilität. Unabhängig davon, wie Ihre Bereitstellung aussieht, passt eine dieser Optionen.

Ein konkretes Beispiel

var $quotas:={}

// Maximum number of input bytes accepted in a one-minute time window on the web server
$quotas.inBytesPerMin:=20000000

// Maximum number of sent bytes in a one-minute time window in a session
$quotas.outBytesPerMinPerSession:=10000000

// Maximum number of allowed sessions on the web server
$quotas.nbSessions:=50

// Maximum number of not authenticated sessions on the web server
$quotas.nbGuestSessions:=10

// Maximum number of accepted requests in a one-minute time window on the web server
$quotas.nbRequestsPerMin:=500

// Maximum number of accepted requests in a one-hour time window on the web server
$quotas.nbRequestsPerHour:=20000

WEB Server().start({quotas: $quotas})

Hinweis:

„nbRequestPerHour“ entspricht nicht einfach „nbRequestPerMin“ × 60 (was 30.000 ergeben würde). Der Wert wurde bewusst niedriger festgelegt, nämlich auf 20.000. Auf diese Weise kann selbst eine Arbeitslast, die das Minutenkontingent über mehrere einzelne Minuten hinweg voll ausschöpft, dieses Tempo nicht fast eine Stunde lang aufrechterhalten, sodass Sie eine echte stündliche Obergrenze erhalten und nicht nur ein umformuliertes Minutenkontingent.

Während die Benutzer mit der Anwendung arbeiten, gibt der Server bei jeder Überschreitung der Quote einen HTTP-Status 429 – „Too Many Requests“ – zurück.

Gegebenenfalls teilt der Antwort-Header „Retry-After“ dem Client genau mit, wie viele Sekunden er warten muss, bevor er es erneut versuchen soll:

Probieren Sie es selbst mit dem detaillierten HDI aus, tauchen Sie tief in die vollständigen Details der Dokumentation ein und teilen Sie Ihre Erfahrungen gerne im Forum mit.

Vergessen Sie überlastete Server, die den Betrieb verlangsamen. Nutzen Sie noch heute die volle Leistungsfähigkeit Ihres Webservers.