iRule-Ereignisreihenfolge
Wählen Sie den Profil-Stack eines BIG-IP-Virtual-Servers — Client-SSL, HTTP, Server-SSL, Pool — und sehen Sie die Reihenfolge, in der die gängigen iRule-Ereignisse auslösen, von CLIENT_ACCEPTED bis CLIENT_CLOSED, als Zeitachse und Liste. Alles im Browser.
NetzwerkProfil-Stack des Virtual Servers
Im Browser berechnet. Es wird nichts gesendet.
Ein Modell des dokumentierten F5-Verhaltens für einen Standard-Virtual-Server. Es kontaktiert nie ein BIG-IP.
Ereignisablauf
Ereignisse in Reihenfolge
CLIENT_ACCEPTEDClient-SeiteA client connection is established. On a Standard virtual server this is when the TCP three-way handshake completes; on FastL4 it fires on the initial SYN.
CLIENTSSL_CLIENTHELLOClient-SeiteThe client's TLS ClientHello has been received, before the handshake is processed. Useful for SNI-based decisions.
CLIENTSSL_HANDSHAKEClient-SeiteThe client-side TLS handshake has completed successfully.
HTTP_REQUESTClient-SeiteThe system has fully parsed the complete client HTTP request headers.
LB_SELECTEDglobalThe system has selected a pool member for the connection.
SERVER_CONNECTEDServer-SeiteThe server-side connection to the selected pool member has been established.
SERVERSSL_HANDSHAKEServer-SeiteThe server-side TLS handshake has completed successfully.
HTTP_REQUEST_SENDServer-SeiteImmediately before the HTTP request is sent to the server-side TCP stack. Runs in the server-side context.
HTTP_RESPONSEClient-SeiteThe system has parsed all of the response status and header lines from the server response.
SERVER_CLOSEDServer-SeiteThe server-side connection has been closed.
CLIENT_CLOSEDClient-SeiteThe client-side connection has been closed.
Bedingte Ereignisse
Diese lösen nur unter bestimmten Bedingungen aus: ein TCP::collect oder HTTP::collect, ein Fehler bei der Lastverteilung oder eine 100-Continue-Antwort.
HTTP_REQUEST_DATA↪ HTTP_REQUESTAfter an HTTP::collect has gathered the specified amount of request payload.
LB_FAILED↪ LB_SELECTEDInstead of LB_SELECTED, when the system fails to select a pool or member, or the selected resource is unreachable.
HTTP_RESPONSE_CONTINUE↪ HTTP_RESPONSEBefore HTTP_RESPONSE, whenever the server sends a 100 Continue interim response.
HTTP_RESPONSE_DATA↪ HTTP_RESPONSEAfter an HTTP::collect has gathered the specified amount of response payload.
- Within a single event, multiple iRules run by priority (default 500, lowest number first); the priority command overrides that. This ordering is across events, not within one.
- Availability also depends on provisioning: module events (APM ACCESS_*, ASM/Advanced WAF, bot defense) only fire when that module is provisioned. And CLIENT_DATA, SERVER_DATA, HTTP_REQUEST_DATA, and HTTP_RESPONSE_DATA need an explicit TCP::collect or HTTP::collect first.