Explorar o funcionamento interno e as estratégias de otimização de servidores web é fundamental para construir sistemas robustos e de alta performance. Este artigo aborda desde a configuração de threads até mecanismos complexos de concorrência e resiliência.

Configuração do Número de Threads

A otimização do número de threads em um servidor é crucial e depende da natureza das tarefas:

• Para operações intensivas em CPU, um número de threads igual ao número de núcleos da CPU mais um (N+1) é frequentemente recomendado. O thread adicional pode ser útil para lidar com interrupções e garantir que a CPU esteja sempre ocupada.
• Para operações intensivas em I/O, o número de threads pode ser significativamente maior. Uma heurística comum é Número de CPUs * (1 + Tempo de Espera da Thread / Tempo de CPU da Thread). Isso permite que, enquanto uma thread aguarda I/O, outras possam executar, maximizando a utilização da CPU.

Modelos de Concorrência: Multiprocesso vs. Multithread

A escolha entre um modelo multiprocesso e multithread impacta diretamente a arquitetura do servidor:

Modelo Multiprocesso

Neste modelo, cada requisição de cliente é atendida por um novo processo. Embora ofereça isolamento robusto (falhas em um processo geralmente não afetam outros), ele apresenta desafios:

• Sobrecarga de Criação e Destruição: A criação e o encerramento de processos são operações caras em termos de recursos.
• Processos Zumbis: Quando um processo filho termina, o kernel retém algumas de suas informações até que o processo pai as colete. Se o pai não fizer isso, o filho se torna um "processo zumbi", consumindo recursos e podendo esgotar os identificadores de processo disponíveis.

Modelo Multithread

Com threads, várias unidades de execução compartilham o mesmo espaço de endereço do processo. As vantagens incluem:

• Baixo Custo de Troca: A alternância entre threads é mais rápida e eficiente do que entre processos.
• Compartilhamento de Dados: Threads podem compartilhar dados facilmente, facilitando a comunicação.

No entanto, o compartilhamento de dados requer mecanismos de sincronização (como locks) para gerenciar o acesso a recursos compartilhados, como filas de tarefas, evitando condições de corrida e inconsistências.

Ordem de Bytes (Endianness)

Em comunicação de rede, a ordem de bytes é crucial. A ordem de bytes de rede (network byte order) é padronizada como Big-endian. Isso significa que, ao enviar dados pela rede, o byte mais significativo é transmitido primeiro. Os sistemas devem converter seus dados para essa ordem antes de enviar e de volta para sua ordem nativa ao receber, se necessário.

Nginx: Arquitetura e Funções Chave

O Nginx é um servidor web de alta performance conhecido por sua arquitetura assíncrona e não bloqueante.

Implementação de Assincronia e Não Bloqueio no Nginx

Nginx utiliza epoll no modo Edge-Triggered (ET), que é um mecanismo síncrono para notificação de eventos. No entanto, o Nginx alcança a assincronia de uma forma inteligente:

Quando uma aplicação realiza uma chamada read() e não há dados disponíveis, em vez de o thread principle ficar bloqueado esperando (comportamento síncrono e bloqueante), o Nginx registra um evento no epoll para o descritor de arquivo correspondente. Em seguida, ele prossegue para processar outras requisições. Somente quando os dados chegam e o evento é disparado pelo epoll é que o Nginx retoma a leitura, caracterizando um comportamento assíncrono.

Principais Funções do Nginx como Servidor Web

1. Proxy Reverso: Atua como um intermediário entre clientes e servidores de backend.
2. Servidor Web Estático: Serve arquivos estáticos (HTML, CSS, JS, imagens) diretamente, com alta eficiência.
3. Balanceador de Carga: Distribui o tráfego de requisições entre múltiplos servidores de backend.

Proxy Reverso: Mecanismo e Benefícios

Um proxy reverso recebe requisições de clientes e as encaminha para servidores internos. Se a requisição for para um arquivo estático, o Nginx pode servi-lo diretamente. Se for para um serviço de backend, ele retransmite a requisição. Os benefícios incluem:

• Balanceamento de Carga: Essencial para distribuir requisições entre múltiplos servidores de aplicação (integrado com configurações upstream).
• Segurança Aprimorada: Oculta a arquitetura interna do servidor, adicionando uma camada extra de proteção, pois os clientes não acessam diretamente os serviços de backend.
• Performance Otimizada: Sua arquitetura assíncrona permite lidar com um grande volume de requisições simultâneas de forma eficiente, repassando-as aos backends.
• Aproveitamento de Cache: Pode cachear respostas de backend, acelerando o retorno para requisições repetidas.

Balanceamento de Carga

Quando há múltiplos servidores, o balanceador de carga distribui as requisições com base em regras predefinidas. Geralmente, ele é configurado em conjunto com um proxy reverso.

Tipos de Soluções de Balanceamento de Carga:

1. Baseado em DNS: Distribui o tráfego em nível geográfico ou entre data centers.
2. Baseado em Hardware: Soluções de alto desempenho para grandes clusters de servidores.
3. Baseado em Software: Soluções como Nginx (camada de aplicação), HAProxy, ou balanceadores em nível de SO.

Estratégias Comuns de Balanceamento de Carga:

• Round Robin: Distribui as requisições sequencialmente para cada servidor.
• Round Robin Ponderado (Weighted Round Robin): Similar ao Round Robin, mas servidores com maior peso reecebem mais requisições.
• Hashing: Baseia-se em um hash de algum atributo da requisição (ex: IP do cliente) para rotear para o mesmo servidor, útil para persistência de sessão.
• Menor Número de Conexões (Least Connections): Roteia para o servidor com o menor número de conexões ativas, uma estratégia dinâmica.
• Resposta Mais Rápida (Fastest Response): Direciona o tráfego para o servidor que demonstrou o tempo de resposta mais rápido recentemente.

Otimizações para HTTP

Para melhorar a performance e a segurança em HTTP, podemos aplicar várias técnicas:

1. Cache de Conteúdo: Armazenar recursos frequentemente acessados para evitar novas requisições ao servidor de origem.
2. Compressão de Dados: Utilizar algoritmos como Gzip ou Brotli para reduzir o tamanho dos dados transferidos.
3. Criptografia SSL/TLS: Garantir a segurança e integridade dos dados em trânsito.
4. Reuso de Conexões TCP (Keep-Alive): Manter a conexão TCP aberta após uma requisição para reutilizá-la em requisições subsequentes, economizando o custo de estabelecimento de novas conexões.

Ferramentas de Teste de Estresse para Servidores

Ferramentas como o WebBench permitem avaliar o desempenho de um servidor, medindo métricas como requisições por segundo (QPS) e volume de dados transferidos. O princípio básico do WebBench envolve a criação de múltiplos processos filhos, cada um simulando acesso ao servidor e reportando os resultados ao processo pai para agregação de estatísticas. Em ambientes de máquina virtual, a concorrência e o QPS podem ser limitados, geralmente não atingindo milhões de requisições por segundo.

Servidores Web Comuns Multithread/Multiprocesso

Exemplos notáveis incluem:

1. Apache: Tradicionalmente mais multiprocesso (embora também suporte multithread com módulos como o prefork ou worker).
2. Nginx: Principalmente multiprocesso com um modelo de eventos (single-threaded event loop por worker process).
3. Tomcat: Servidor de aplicações Java que utiliza um modelo multithread.

Múltiplos Listeners no Mesmo Porto

Sim, é possível que múltiplos threads/processos escutem no mesmo porto:

1. Uma conexão TCP/UDP é identificada de forma única por uma quíntupla: (IP de Origem, Porta de Origem, Protocolo, IP de Destino, Porta de Destino). Diferentes protocolos (TCP e UDP) podem coexistir no mesmo número de porta.
2. Usando a opção de socket SO_REUSEPORT, múltiplos sockets podem ser ligados ao mesmo endereço IP e porta. Isso permite que vários processos/threads aceitem conexões no mesmo porto, o que pode mitigar o "problema do rebanho barulhento" (thundering herd problem) onde todos os processos/threads são despertados quando uma nova conexão chega, mas apenas um a aceita.

Limites de Conexões em um Host

O número máximo de conexões que um servidor pode manter é limitado por vários fatores:

1. Restrição de Número de Portas: As portas TCP/UDP são números de 16 bits, variando de 1 a 65535. No Linux, a faixa de portas efêmeras (ip_local_port_range) é limitada. Se um cliente sempre se conecta ao mesmo IP e porta de destino, o número de portas de origem disponíveis será o principle gargalo.

2. Descritores de Arquivo (File Descriptors - FD): No Linux, cada socket aberto consome um descritor de arquivo. Existem três níveis de limitação:

   • Sistema: /proc/sys/fs/file-max define o número máximo de FDs em todo o sistema.
   • Usuário: /etc/security/limits.conf define o limite por usuário.
   • Processo: /proc/sys/fs/nr_open define o limite por processo.

   O limite efetivo será o menor desses valores.

3. Memória: Cada conexão e seu respectivo descritor de arquivo requerem buffers de memória. Um número excessivo de conexões pode levar a esgotamento de memória.

4. CPU: O processamento das requisições e a manutenção das conexões consomem ciclos de CPU. A utilização da CPU é um indicador chave de gargalo.

Problemas de Cross-Origin (CORS)

CORS refere-se à política de segurança implementada pelos navegadores, conhecida como Política de Mesma Origem (Same-Origin Policy). Esta política impede que scripts em uma página web façam requisições HTTP para um domínio, protocolo ou porta diferente daquele de onde a página foi servida. Uma "mesma origem" significa que o protocolo, host e porta são idênticos. As soluções geralmente envolvem:

• Configuração no Backend: O servidor de backend pode enviar cabeçalhos HTTP Access-Control-Allow-Origin para indicar quais origens têm permissão para acessar seus recursos.
• Configuração no Frontend: Proxies ou configurações específicas no cliente podem ser usadas para contornar a restrição em ambientes de desenvolvimento.

Suporte a Conexões Persistentes (Long Connections)

O protocolo HTTP/1.1 suporta conexões persistentes por padrão, utilizando o cabeçalho Connection: keep-alive. No nível TCP, conexões persistentes são mantidas através de mecanismos de "keep-alive", onde o sistema operacional periodicamente envia pacotes de sonda para o cliente para verificar se a conexão ainda está ativa, mesmo na ausência de troca de dados.

Estratégias para Lidar com Alto Volume de Tráfego e Concorrência

Otimizar um servidor para alta concorrência envolve abordagens tanto no lado do cliente quanto no lado do servidor:

Otimizações no Lado do Cliente (HTTP)

1. Redução de Requisições: Utilizar servidores proxy ou CDNs para cachear recursos estáticos e reduzir a carga no servidor de origem.
2. Caching: Implementar mecanismos de cache no navegador e em proxies para evitar requisições desnecessárias.

Otimizações no Lado do Servidor

1. Aumento de Recursos: Prover mais largura de banda, servidores mais potentes (CPU, RAM).
2. Clusterização e Cache: Utilizar clusters de servidores web com balanceadores de carga e camadas de cache (ex: Redis) para distribuir e acelerar as requisições.
3. Otimização de Banco de Dados: Otimizar consultas SQL, usar índices, ou empregar soluções de busca e análise como Elasticsearch (EES) para acesso rápido a dados.
4. Otimização de Código: Refatorar a lógica de negócios e otimizar o uso de threads.

Segurança de Threads no Epoll

O epoll é thread-safe e utiliza locks para proteger suas estruturas de dados internas. Especificamente:

• Um spinlock (ep->lock) é usado para proteger a fila de prontos (ready list), que é manipulada principalmente por epoll_wait(). Spinlocks são eficientes para bloqueios de curta duração, pois evitam a troca de contexto, mantendo o CPU ocupado.
• Um mutex (ep->mtx) é usado para proteger a árvore rubro-negra (red-black tree), onde os descritores de arquivo são registrados e gerenciados por epoll_ctl(). Mutexes são adequados para bloqueios de maior duração, permitindo que o thread se torne inativo em vez de consumir CPU em espera.

Estrutura Conceitual do eventpoll

struct eventpoll_ctx {
    // Lock para operações rápidas na fila de eventos prontos
    spinlock_t ready_list_lock; 
    // Lock para operações na árvore de descritores de arquivo
    mutex_t fd_tree_lock;      
    // Fila de eventos que estão prontos para processamento
    struct list_head ready_events_queue; 
    // Árvore para armazenar e gerenciar os descritores de arquivo monitorados
    struct rb_root monitored_fds_tree;   
    // ... outros campos ...
};

Operação epoll_ctl() (Adição, Modificação, Remoção de FDs)

A função epoll_ctl(), que gerencia a adição, modificação ou remoção de descritores de arquivo na estrutura epoll, garante a thread-safety utilizando um mutex. Isso é apropriado porque as operações na árvore rubro-negra podem ser mais complexas e demoradas, e um mutex permite que o thread bloqueado durma, liberando a CPU para outras tarefas.

int my_epoll_ctl(int ep_instance_fd, int operation, int target_fd, struct epoll_event* event_data) {
    // Obtém o contexto interno do epoll_instance_fd
    struct eventpoll_ctx* ep_ctx = get_epoll_context(ep_instance_fd);

    // Adquire o mutex para proteger a árvore de descritores de arquivo
    mutex_lock(&ep_ctx->fd_tree_lock); 

    int result;
    switch (operation) {
        case EPOLL_CTL_ADD:
            // Lógica para adicionar target_fd à monitored_fds_tree
            result = add_fd_to_tree(ep_ctx->monitored_fds_tree, target_fd, event_data);
            break;
        case EPOLL_CTL_DEL:
            // Lógica para remover target_fd da monitored_fds_tree
            result = remove_fd_from_tree(ep_ctx->monitored_fds_tree, target_fd);
            break;
        case EPOLL_CTL_MOD:
            // Lógica para modificar o evento associado a target_fd na monitored_fds_tree
            result = modify_fd_in_tree(ep_ctx->monitored_fds_tree, target_fd, event_data);
            break;
        default:
            result = -EINVAL; // Argumento inválido
    }

    // Libera o mutex
    mutex_unlock(&ep_ctx->fd_tree_lock); 
    return result;
}

Operação epoll_wait() (Espera por Eventos Prontos)

A função epoll_wait(), que espera por eventos em descritores de arquivo e os retorna quando prontos, protege a fila de prontos com um spinlock. Spinlocks são ideais aqui, pois a operação de adicionar ou remover um item da fila de prontos é geralmente muito rápida, e evitar a troca de contexto que um mutex implicaria, melhora a performance.

int my_epoll_wait(int ep_instance_fd, struct epoll_event* events, int max_events, int timeout) {
    struct eventpoll_ctx* ep_ctx = get_epoll_context(ep_instance_fd);
    int events_count = 0;

    while (events_count == 0 && timeout != 0) {
        // Adquire o spinlock para proteger a fila de eventos prontos
        spin_lock_irqsave(&ep_ctx->ready_list_lock); 

        // Se a fila de prontos não está vazia, move eventos para o array de saída
        while (!list_empty(&ep_ctx->ready_events_queue) && events_count < max_events) {
            struct epoll_event_item* item = list_pop_front(&ep_ctx->ready_events_queue);
            events[events_count++] = item->event;
            release_event_item(item);
        }

        // Libera o spinlock
        spin_unlock_irqrestore(&ep_ctx->ready_list_lock); 

        if (events_count == 0) {
            // Se não há eventos, o thread pode dormir até ser notificado ou o timeout expirar
            wait_for_events(ep_ctx, timeout); 
        }
    }
    return events_count;
}

Desempacotamento de Requisições HTTP

Uma requisição HTTP consiste em Linha de Requisição, Cabeçalhos, Linha Vazia e Corpo da Requisição. O campo Content-Length nos cabeçalhos indica o tamanho do corpo da requisição. Se o corpo for muito grande, ele pode ser enviado em múltiplos pacotes TCP. O servidor utiliza o Content-Length para determinar o fim da mensagem HTTP, realizando o "desempacotamento" ou "desagregação" dos pacotes recebidos para reconstruir a requisição completa. Sem esse controle, pode ocorrer o problema de "nalepak" (packet agglutination) ou "pacote pegajoso", onde múltiplos segmentos de requisições diferentes são recebidos em um único buffer.

Função pthread_detach()

Threads podem estar em um de dois estados: "joinable" ou "detached" (unjoinable). Se uma thread é "joinable", seus recursos (pilha, descritor de thread) não são liberados automaticamente após sua terminação, exigindo uma chamada a pthread_join() pelo thread pai para coletá-los. Se pthread_detach() é chamado, a thread se torna "detached", e seus recursos são liberados imediatamente pelo sistema operacional após sua terminação, sem a necessidade de um pthread_join(). Isso é útil para threads que não precisam ter seu status de saída coletado pelo pai.

Estratégias de Rejeição de Thread Pool

Um pool de threads pode rejeitar a execução de tarefas em duas situações principais:

1. Quando o pool de threads é encerrado (via shutdown()).
2. Quando o número de threads ativas atinge o máximo configurado e a fila de tarefas está cheia.

As quatro estratégias de rejeição mais comuns são:

1. AbortPolicy (Política de Aborto): Lança uma exceção RejectedExecutionException, notificando o chamador sobre a falha.
2. DiscardPolicy (Política de Descarte): Silenciosamente descarta a tarefa, sem execução ou notificação.
3. DiscardOldestPolicy (Política de Descarte da Mais Antiga): Descarta a tarefa mais antiga na fila de espera para dar lugar à nova tarefa.
4. CallerRunsPolicy (Política de Execução pelo Chamador): O thread que tentou submeter a tarefa executa a tarefa ele mesmo, bloqueando-o até a conclusão.

Métodos de Transferência de Grandes Arquivos

1. Baseado em Sockets: Implementar a lógica de fragmentação no lado do cliente e remontagem no lado do servidor, pois os buffers de socket têm limites de tamanho (ex: 4KB). A complexidade de programação é alta.
2. Uso de Middleware/Brokers: Utilizar sistemas de mensagens ou brokers (como Kafka, RabbitMQ) que podem lidar com o transporte de grandes volumes de dados ou referências a arquivos.
3. Protocolo FTP: Para cenários onde é aplicável, o FTP (File Transfer Protocol) é uma solução simples e robusta para a transferência de arquivos.

Princípio do Despertar de Threads no Epoll

Ao registrar um evento via epoll_ctl(), o kernel associa uma função de callback a esse evento. Quando dados chegam em um socket (ou um evento de escrita está pronto), a placa de rede (NIC) gera uma interrupção de hardware. O kernel, em resposta a essa interrupção, executa a função de callback registrada. Essa função de callback é responsável por marcar o descritor de arquivo como "pronto" e mover o thread correspondente da fila de espera (bloqueado) para a fila de prontos (ativado), permitindo que ele seja escalonado para processar os dados.

Correspondência entre Conexão TCP e Socket

Uma conexão TCP é definida unicamente por sua quíntupla (IP de Origem, Porta de Origem, Protocolo, IP de Destino, Porta de Destino). Quando um servidor aceita uma nova conexão (via accept()), o kernel cria um novo socket e associa essa quíntupla a ele. Esse socket serve como um endpoint para a comunicação. Quando dados chegam através da rede e são identificados como parte de uma conexão existente, o kernel os copia para o buffer de recepção do socket correspondente.

Fechamento Elegante de Conexão TCP

O encerramento de uma conexão TCP pode ser "elegante" ou "forçado":

• Fechamento Elegante: Prioriza a entrega de todos os dados pendentes no buffer de envio. O processo que deseja fechar a conexão envia um pacote FIN somente após todos os dados terem sido transmitidos e seus ACKs recebidos. O socket é então removido da memória de forma ordenada, garantindo que nenhum dado seja perdido.
• Fechamento Forçado: Descarta imediatamente quaisquer dados pendentes no buffer de envio e envia um pacote RST (Reset). O RST indica uma terminação anormal da conexão e não requer um ACK de resposta, encerrando a conexão abruptamente e removendo o socket da memória.

Limitação de Taxa (Rate Limiting) em Cenários de Alta Concorrência

A limitação de taxa é uma técnica de serviço de degradação utilizada para controlar o número de requisições que um sistema pode processar em um determinado período. As estratégias são similares às de rejeição de pool de threads:

• Rejeição Direta: Novas requisições acima do limite são imediatamente recusadas.
• Atraso no Processamento: Requisições excedentes são colocadas em uma fila e processadas com atraso.
• Rejeição Aleatória: Uma porcentagem de requisições é aleatoriamente descartada ao atingir o limite.

Ideias de Otimização para Serviços de Alta Concorrência

1. Bancos de Dados Não Relacionais (NoSQL): Para workloads que exigem alta escalabilidade e flexibilidade, NoSQL pode oferecer melhor desempenho do que bancos de dados relacionais.

2. Múltiplas Camadas de Cache:

   • Cache Local (Nível 1): Cache na memória do próprio servidor de aplicação para acesso ultra-rápido.
   • Memcached (Nível 2): Cache distribuído em memória, multithreaded e eficiente para casos onde o Redis pode sofrer com "hot spots".
   • Redis (Nível 3): Cache em memória, persistente e versátil. No entanto, sendo single-threaded, pode apresentar problemas de "hot spot" se uma única chave for acessada massivamente.

   Problema de "Hot Spot" no Cache: Ocorre quando um único item (uma "chave quente") ou um conjunto limitado de itens recebe um volume desproporcional de requisições. Isso pode sobrecarregar um único nó de cache ou até mesmo um servidor Redis single-threaded, impactando a performance de todo o sistema e podendo causar "cache penetration" ou "cache breakdown".

   Soluções para Hot Spots:

   • Cache Multicamadas: Usar caches locais ou Memcached para absorver a carga de chaves quentes antes que atinjam o Redis.
   • Distribuição de Chaves Quentes: Replicar chaves quentes em múltiplos shards ou nós de cache, distribuindo a carga entre eles.
   • Fragmentação de Chaves: Criar várias chaves de cache para o mesmo dado quente (ex: key_1, key_2) e distribuir as requisições entre elas aleatoriamente.

3. Uso de Multithreading: Otimizar o uso de threads para paralelizar o processamento e aproveitar os múltiplos núcleos da CPU.

4. Limitação de Taxa, Degradação e Circuit Breakers:

   • Limitação de Taxa (Rate Limiting): Restringir o número de requisições permitidas em um período.
   • Degradação de Serviço (Service Degradation): Desabilitar funcionalidades não essenciais para garantir a disponibilidade dos serviços críticos sob carga.
   • Circuit Breakers (Disjuntores): Interromper chamadas a serviços com falha ou lentos para evitar que um serviço falho derrube outros.

Otimização de Bloqueios em Pools de Threads de Alta Concorrência

A otimização de bloqueios visa reduzir o "domínio de conflito" – a porção do código que compete pelo mesmo lock. Uma estratégia eficaz é diminuir a granularidade dos locks. Em vez de um único lock para uma estrutura de dados grande, pode-se particionar os dados e usar um lock separado para cada partição. Por exemplo, em um pool de threads, em vez de uma única fila de mensagens protegida por um lock, pode-se usar múltiplas filas de mensagens, cada uma com seu próprio lock, distribuindo as requisições externas entre elas.

Tempo de Espera para Semáforos e Encerramento de Threads

Em pools de threads, se uma thread fica muito tempo esperando por uma tarefa (um sinal de um semáforo), ela pode ser encerrada para liberar recursos. Isso é controlado por um keepAliveTime: se um thread fica ocioso por mais tempo que o keepAliveTime, ele é encerrado (normalmente threads não-core). Alternativamente, funções como sem_timedwait() permitem que um thread espere por um semáforo com um tempo limite, executando uma lógica de encerramento se o tempo limite for excedido.

Concepção de Pools de Threads em WebServers

Um pool de threads bem projetado é essencial para a eficiência de um WebServer:

• Threads Core e Não-Core: O pool mantém um número mínimo de threads (core) sempre ativas. Se a carga aumenta, ele pode criar threads adicionais (não-core) até um limite máximo.
• KeepAliveTime: Define por quanto tempo threads não-core podem permanecer ociosas antes de serem terminadas, economizando recursos.
• Estratégias de Rejeição: Políticas para lidar com tarefas quando o pool está sobrecarregado (conforme discutido anteriormente).

O fluxo de trabalho típico é: uma nova tarefa primeiro tenta ser executada por um thread core disponível. Se todos os threads core estiverem ocupados, a tarefa é enfileirada em uma fila de bloqueio. Se a fila de bloqueio estiver cheia, o pool tenta criar threads não-core. Se o número máximo de threads (core + não-core) for atingido e a fila ainda estiver cheia, a estratégia de rejeição é aplicada.

Motivação para o Uso de Pools de Conexões

A criação e o encerramento de conexões de banco de dados (ou outras conexões de rede) são operações caras em termos de tempo e recursos. Para sistemas que fazem acesso frequente ao banco de dados, a criação e destruição repetida de conexões degrada significativamente o desempenho. Um pool de conexões pré-aloca e gerencia um conjunto de conexões ativas. Quando uma aplicação precisa de uma conexão, ela a obtém do pool; ao terminar, a retorna ao pool para reuso. Isso reduz a latência e o consumo de recursos, melhorando a velocidade de acesso aos dados.

Portas Não-Bloqueantes vs. Bloqueantes

Em operações de I/O, um socket pode operar em modo bloqueante ou não-bloqueante:

• Modo Bloqueante: Quando uma operação de I/O (ex: read(), accept()) é chamada em um socket bloqueante, o thread de execução fica suspenso até que a operação seja concluída (dados recebidos, conexão aceita). Isso pode levar a um baixo desempenho em servidores de alta concorrência, pois um único thread bloqueado pode paralisar o processamento de outras requisições.
• Modo Não-Bloqueante: Em um socket não-bloqueante, uma operação de I/O retorna imediatamente, mesmo que não haja dados disponíveis ou uma conexão para aceitar. Se a operação não puder ser concluída, ela retorna um erro (ex: EAGAIN ou EWOULDBLOCK). Isso permite que um único thread possa gerenciar múltiplas conexões eficientemente, verificando periodicamente o status das operações sem ficar bloqueado, ideal para arquiteturas baseadas em eventos como o Nginx e epoll.