SO_REUSEPORT_LB é uma opção de socket útil para distribuir conexões entre múltiplos processos que escutam na mesma porta. Em ambientes compatíveis, ela combina reutilização de porta com balanceamento de carga no kernel, permitindo que vários workers aceitem conexões sem depender de um proxy intermediário. Neste guia, você verá como detectar suporte, configurar sockets com segurança, testar o comportamento e entender limites de portabilidade.
O que é SO_REUSEPORT_LB
A constante é exposta pelo módulo socket quando o sistema operacional e a versão do Python oferecem suporte. Ela é relacionada a SO_REUSEPORT, mas não deve ser tratada como sinônimo universal. A ideia central é que diversos sockets vinculados ao mesmo endereço e porta possam receber tráfego com distribuição feita pelo sistema. Isso pode reduzir contenção em servidores multiprocessos e simplificar arquiteturas de alto desempenho.
O suporte depende da plataforma. Portanto, o primeiro passo é verificar a presença da constante:
import socket
if hasattr(socket, "SO_REUSEPORT_LB"):
print("suportado")
else:
print("indisponível")Nunca assuma que o recurso existe apenas porque o código roda em uma versão recente do Python. A disponibilidade final também depende do sistema operacional.
Exemplo básico
O fluxo típico consiste em criar o socket, definir a opção antes de bind(), associar o endereço e iniciar a escuta.
import socket
HOST = "127.0.0.1"
PORT = 9000
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT_LB, 1)
sock.bind((HOST, PORT))
sock.listen()
print(f"Escutando em {HOST}:{PORT}")A ordem importa. Opções relacionadas ao vínculo de porta normalmente precisam ser configuradas antes de bind(). Alterá-las depois pode não produzir efeito ou gerar erro.
Quando usar
Esse recurso faz sentido em servidores multiprocessos nos quais cada processo possui seu próprio loop de aceitação. Exemplos incluem servidores HTTP personalizados, gateways internos, coletores de métricas, serviços de baixa latência e aplicações que desejam aproveitar múltiplos núcleos sem compartilhar um único descritor entre todos os workers.
Ele também pode ajudar em reinicializações graduais, desde que o comportamento da plataforma esteja bem compreendido. Ainda assim, não substitui uma estratégia completa de deploy, health checks, drenagem de conexões e observabilidade.
Diferença para SO_REUSEADDR
SO_REUSEADDR costuma ser usado para permitir a reutilização rápida de um endereço após reinicializações, especialmente quando conexões anteriores ainda estão em estados como TIME_WAIT. Já SO_REUSEPORT_LB se concentra na coexistência de múltiplos listeners e no balanceamento entre eles.
As semânticas variam por sistema. Em alguns ambientes, SO_REUSEPORT e SO_REUSEADDR têm comportamentos parcialmente sobrepostos. Por isso, teste no sistema real em vez de copiar combinações de opções sem validação.
Criando múltiplos workers
Um padrão comum é iniciar vários processos com o mesmo código de servidor. Cada worker cria seu próprio socket, configura a opção e faz bind no mesmo endereço.
from multiprocessing import Process
import socket
HOST = "127.0.0.1"
PORT = 9000
def worker(numero):
with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as servidor:
servidor.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT_LB, 1)
servidor.bind((HOST, PORT))
servidor.listen()
while True:
conexao, endereco = servidor.accept()
with conexao:
conexao.sendall(f"worker {numero}\n".encode())
if __name__ == "__main__":
processos = [Process(target=worker, args=(i,)) for i in range(4)]
for processo in processos:
processo.start()
for processo in processos:
processo.join()Esse exemplo é didático. Em produção, inclua timeouts, sinais de encerramento, limites de conexões, tratamento de erros e logs estruturados.
Balanceamento não significa igualdade perfeita
O kernel distribui conexões conforme regras próprias. Isso não garante exatamente 25% para cada worker em um grupo de quatro processos. Padrões de tráfego, afinidade, hash, duração das conexões e comportamento da pilha de rede podem gerar diferenças.
Meça a distribuição com métricas por processo. Conte conexões aceitas, duração, bytes processados, erros e latência. O objetivo deve ser equilíbrio operacional suficiente, não uma igualdade matemática rígida.
Testando corretamente
Um teste útil deve iniciar múltiplos workers e abrir muitas conexões independentes. Uma única conexão persistente não demonstra balanceamento, pois permanece associada ao worker que a aceitou.
import socket
from collections import Counter
resultados = Counter()
for _ in range(200):
with socket.create_connection(("127.0.0.1", 9000), timeout=2) as cliente:
resposta = cliente.recv(100).decode().strip()
resultados[resposta] += 1
print(resultados)Execute o teste em ambiente isolado e repita várias vezes. Para cargas HTTP com keep-alive, avalie tanto conexões curtas quanto conexões persistentes.
Portabilidade
O principal cuidado é a portabilidade. Código que usa a constante diretamente pode falhar na importação ou na execução em plataformas sem suporte. Prefira detecção explícita e uma estratégia alternativa.
opcao = getattr(socket, "SO_REUSEPORT_LB", None)
if opcao is None:
raise RuntimeError("SO_REUSEPORT_LB não é suportado neste sistema")Outra opção é usar um listener único com compartilhamento de descritor, um servidor ASGI/WSGI consolidado, um proxy reverso ou um balanceador externo.
Segurança
Reutilizar portas afeta a superfície de exposição do serviço. Todos os processos participantes devem executar sob identidades e permissões controladas. Não permita que processos não confiáveis ingressem no mesmo grupo de listeners. Use endereços específicos em vez de 0.0.0.0 quando o serviço não precisa ficar público.
Também aplique TLS quando necessário, valide entradas, limite tamanhos de requisição e trate exaustão de recursos. A opção de socket melhora distribuição, mas não oferece autenticação, criptografia ou isolamento.
Encerramento gracioso
Em deploys, um worker deve parar de aceitar novas conexões, concluir as ativas e fechar o socket. Como os demais listeners continuam disponíveis, o serviço pode permanecer responsivo. Entretanto, conexões persistentes continuam ligadas ao processo original até serem encerradas.
Implemente sinais como SIGTERM, deadlines de desligamento e métricas de conexões ativas. Evite finalizar todos os workers simultaneamente sem coordenação.
Integração com selectors e asyncio
O socket configurado pode ser usado com selectors ou integrado a loops assíncronos. Em asyncio, muitas APIs de alto nível já gerenciam sockets, então verifique se é possível passar um socket pré-configurado.
Para aprofundar a base, veja asyncio no Python, HTTPSServer no Python, os.timerfd_create no Python e concurrent.interpreters no Python.
Boas práticas
Detecte suporte em tempo de execução, configure a opção antes de bind, registre qual worker aceitou cada conexão, use timeouts, trate sinais, teste com carga real e documente a plataforma mínima. Mantenha um fallback claro e evite depender de comportamento não documentado.
Monitore também limites de arquivos abertos, backlog, erros de aceitação e uso de CPU. Muitos workers não garantem melhor desempenho; eles podem aumentar trocas de contexto e consumo de memória.
Erros comuns
Os erros mais comuns são usar a opção após bind(), confundir com SO_REUSEADDR, supor suporte universal, iniciar workers demais, testar apenas uma conexão e ignorar encerramento gracioso. Outro erro é considerar o recurso um substituto para balanceadores, políticas de segurança ou observabilidade.
Documentação e referências
Consulte a documentação oficial do módulo socket e a documentação de setsockopt do sistema para confirmar disponibilidade e semântica. Sempre compare essas referências com a versão exata do sistema em produção.
Conclusão
SO_REUSEPORT_LB pode simplificar servidores multiprocessos e distribuir novas conexões entre listeners independentes. O ganho real aparece quando o recurso é combinado com métricas, testes, fallback e encerramento gracioso. Use-o como uma otimização de arquitetura de rede, não como uma solução automática para escalabilidade.
