# Explicador da ordem de eventos de iRules > Escolha o conjunto de perfis de um virtual server do BIG-IP — Client-SSL, HTTP, Server-SSL, pool — e veja a ordem em que os eventos de iRule comuns disparam, de CLIENT_ACCEPTED a CLIENT_CLOSED, como linha do tempo e lista. Tudo no seu navegador. - Tool: https://ronutz.com/pt-BR/tools/f5-irules-event-order - Family: Redes --- ## O que faz Escolha o conjunto de perfis de um virtual server Standard (full-proxy) do BIG-IP, se ele tem um perfil Client-SSL, um perfil HTTP, um perfil Server-SSL e um pool, e a ferramenta mostra a ordem em que os eventos comuns de iRule disparam, de `CLIENT_ACCEPTED` até `CLIENT_CLOSED`, como linha do tempo e como lista. É um modelo do comportamento documentado da F5, calculado no seu navegador; ela nunca se conecta a um equipamento. ## Por que a ordem depende do conjunto de perfis Uma iRule é orientada a eventos: seu código Tcl roda quando um evento nomeado dispara, e quais eventos disparam, e em que ordem, é decidido pela configuração do virtual server, não pelo script. Um virtual server full-proxy processa o lado do cliente e o lado do servidor como duas conexões separadas, então os eventos percorrem fases distintas: a conexão do cliente é aceita, o handshake TLS do lado do cliente é concluído, a requisição HTTP é analisada, um membro do pool é selecionado, a conexão do lado do servidor é aberta, o handshake TLS do lado do servidor é concluído, a requisição é enviada, a resposta retorna e, por fim, os dois lados são fechados. Mude o conjunto de perfis e o conjunto de eventos muda com ele. ## O que cada perfil acrescenta - **Nenhum perfil além de um pool** deixa os eventos em nível de conexão: `CLIENT_ACCEPTED` no início, os eventos de balanceamento quando um membro é escolhido, `SERVER_CONNECTED` no lado do servidor e os eventos `CLOSED` no fim. - **Um perfil Client-SSL** acrescenta os eventos de TLS do lado do cliente, como `CLIENTSSL_CLIENTHELLO` e `CLIENTSSL_HANDSHAKE`, antes de a requisição ser processada. - **Um perfil HTTP** acrescenta os eventos de requisição e resposta, `HTTP_REQUEST` no lado do cliente e `HTTP_REQUEST_SEND` e `HTTP_RESPONSE` no lado do servidor, para você agir sobre cabeçalhos e payload. - **Um perfil Server-SSL** acrescenta os eventos de TLS do lado do servidor para a conexão com o membro do pool. A ferramenta também posiciona os eventos condicionais, os caminhos de coleta de dados e o caminho de falha de balanceamento (`LB_FAILED`), onde eles pertencem na sequência. ## Uma nota sobre múltiplas iRules Quando duas iRules tratam o mesmo evento, a ordem entre elas não é a ordem em que estão listadas; é controlada pelo comando `priority` dentro de cada evento (F5 K12090273), com uma prioridade padrão aplicada quando nenhuma é definida. Esse é um eixo separado da ordem entre eventos que esta ferramenta apresenta. ## Como usar Alterne os perfis do seu virtual server e leia a sequência de eventos resultante como linha do tempo e como lista. Ela reflete o modelo de eventos documentado da F5 (a Master List of iRule Events e as referências por evento), então é um apoio de planejamento e aprendizado, não uma captura de um sistema ativo. ## Standards and references - [F5 Clouddocs — Master List of iRule Events](https://clouddocs.f5.com/api/irules/Events.html) - event names and triggers - [F5 Clouddocs — CLIENT_ACCEPTED](https://clouddocs.f5.com/api/irules/CLIENT_ACCEPTED.html) - connection-setup timing (Standard vs FastL4) - [F5 Clouddocs — HTTP_REQUEST_SEND](https://clouddocs.f5.com/api/irules/HTTP_REQUEST_SEND.html) - server-side send ordering - [F5 — K12090273: iRule priority command controls execution order](https://my.f5.com/manage/s/article/K12090273) - within-event priority - [F5 DevCentral codeshare — iRule Event Order (captured sequence)](https://community.f5.com/kb/codeshare/irule-event-order/290961) - empirical event ordering ## Related reading - [Eventos de Handshake SSL em iRules](https://ronutz.com/pt-BR/learn/irule-ssl-handshake-events.md): Os perfis Client-SSL e Server-SSL adicionam seus próprios eventos de iRule em torno do handshake TLS. CLIENTSSL_CLIENTHELLO dispara antes de o handshake concluir, o que torna possível a seleção de perfil e pool baseada em SNI; CLIENTSSL_HANDSHAKE dispara depois. O lado Server-SSL os espelha na conexão com o pool. - [FastL4 vs Standard: Quais Eventos de iRule Você Tem](https://ronutz.com/pt-BR/learn/irule-fastl4-vs-standard-events.md): Um virtual server Standard é um proxy TCP completo e expõe o conjunto rico de eventos de iRule L7 e SSL. Um virtual server FastL4 é um caminho rápido baseado em pacotes, otimizado para throughput, e deliberadamente abre mão da maioria desses eventos. Escolher o perfil é escolher quais eventos existem. - [Lado Cliente vs Lado Servidor em iRules](https://ronutz.com/pt-BR/learn/irule-clientside-vs-serverside.md): Um virtual server do BIG-IP é um proxy completo: ele mantém uma conexão separada com o cliente e com o membro do pool. Os eventos de iRule rodam em um contexto ou no outro, e comandos como IP::remote_addr retornam coisas diferentes dependendo do lado em que você está. Conhecer essa fronteira evita toda uma classe de bugs confusos. - [O Que Faz um Evento Disparar: Provisionamento e Perfis](https://ronutz.com/pt-BR/learn/irule-events-modules-and-profiles.md): Um evento de iRule só está disponível se duas coisas se alinharem: o módulo ao qual ele pertence está provisionado, e o perfil que o produz está anexado ao virtual server. Alguns eventos precisam de um terceiro ingrediente — um comando collect explícito. Especifique um evento cujos pré-requisitos faltam e não há erro; ele simplesmente nunca dispara. - [Ordem de Eventos de iRule: O Ciclo de Vida da Conexão](https://ronutz.com/pt-BR/learn/irule-event-order-explained.md): iRules são orientadas a eventos, e os eventos disparam em uma ordem fixa conforme o BIG-IP processa uma conexão: aceitar o cliente, concluir o handshake TLS do cliente, analisar a requisição, escolher um membro do pool, conectar a ele, concluir o handshake TLS do servidor, enviar a requisição, ler a resposta, encerrar. Conhecer essa ordem é a diferença entre uma iRule que funciona e uma que dá erro. - [Perfis de Protocolo: TCP Vivo, TCP Congelado e os Dois Caminhos Rápidos](https://ronutz.com/pt-BR/learn/bigip-l4-protocol-profiles.md): O menu de tcp esconde três decisões. O anúncio do 13.0 da F5 dividiu a família full-proxy em perfis vivos que ela atualiza continuamente (somente leitura, ajustados via filhos) e um trio legado congelado que ainda é distribuído. O FastL4 troca o proxy por um caminho de pacotes em hardware, e o FastHTTP é o caso HTTP estreito que precisa passar em todos os critérios da sua lista. - [Prioridade de iRule e Múltiplas Regras](https://ronutz.com/pt-BR/learn/irule-priority-and-event-order.md): A ordem de eventos governa quais eventos disparam e quando. O comando priority governa algo diferente: quando várias iRules (ou vários handlers) escutam o mesmo evento, qual roda primeiro. A prioridade padrão é 500, números menores rodam mais cedo, e acertar isso importa quando a saída de uma regra alimenta outra.