Melhores Práticas de Rede
Regras para chamadas de saída confiáveis, transporte seguro e comportamento de rede operável em serviços Rust.
Como Usar Esta Lista
- Aplique a cada nova integração de dependência externa.
- Codifique a política de retentativas e tempo limite na fábrica de clientes compartilhada.
- Revise durante incidentes envolvendo interrupções de sistemas upstream.
A - Clientes HTTP
- Um
reqwest::Clientcompartilhado por processo. Reutilização do pool de conexões. - Defina tempos limite de conexão e totais em cada cliente. Sem esperas infinitas.
- Identifique o serviço com
User-Agent. A equipe de operações pode rastrear chamadores nos logs. - Mapeie erros upstream para erros de domínio. Não vaze corpos brutos para usuários finais.
- Faça streaming de downloads grandes. Evite carregar respostas de vários GB na RAM.
B - Retentativas e Resiliência
- Retente apenas operações idempotentes. POST precisa de
Idempotency-Key. - Backoff exponencial com jitter. Limite o atraso máximo e o número de tentativas.
- Respeite
Retry-Afterem 429. Respeite os limites de taxa upstream. - Circuit breaker para falhas sustentadas. Falhe rapidamente quando a dependência estiver inativa.
- Bulkhead para chamadas concorrentes por host. Evite que uma API lenta paralise todas as tarefas.
C - TLS e Segurança
- Use
rustlsem binários Rust. Evite distribuir OpenSSL, a menos que seja necessário. - Nunca desative a verificação de certificado em produção. Use raízes personalizadas apenas para CA corporativa.
- Rotacione certificados TLS antes do vencimento. Automatize com
cert-managerou LB. - mTLS para comunicação serviço-a-serviço quando a política exigir. Certificados de cliente de curta duração.
- Não registre cabeçalhos de
Authorizationou cookies.
D - Escolha do Protocolo
- REST/JSON para APIs públicas north-south. Amplo suporte de cliente.
- gRPC para RPC interno east-west. Contratos fortes e streaming.
- WebSocket apenas quando push do servidor ou bidirecional for necessário. Não para polling simples.
- TCP/UDP bruto apenas com framing documentado. Prefira HTTP, a menos que a latência exija o contrário.
E - Observabilidade
- Propague o contexto de rastreamento (
traceparent). Vincule spans de saída à solicitação de entrada. - Métrica: latência, taxa de erro, contagem de retentativas por dependência. Dashboard por upstream.
- Falhas de DNS alertam separadamente. Distinto de HTTP 5xx.
- Documente os SLAs upstream no runbook. Valores de tempo limite derivados do SLA.
- Teste de carga com injeção de falhas. Verifique se o backoff não amplifica as interrupções.
FAQs
reqwest ou hyper?
reqwest para HTTP de aplicação; hyper para stacks personalizadas.
Tempo limite padrão?
10-30s total, 3-5s de conexão - ajuste por dependência.
gRPC vs REST?
gRPC interno; REST externo, a menos que o gateway de API traduza.
IPv6?
Teste dual-stack em staging; "happy eyeballs" tratado pelo SO/runtime.
Proxy para toda a saída?
Ambientes corporativos - configure HTTP_PROXY no construtor do cliente.
HTTP/2 para upstream?
Habilitado por padrão; verifique se o servidor suporta antes de forçar.
Tempo limite ocioso de keep-alive?
Alinhe o tempo limite ocioso do pool de clientes com o tempo limite ocioso do LB para evitar sockets obsoletos.
Verificação de Webhook?
Assinatura HMAC + tolerância de timestamp na entrada, não na saída.
Testes de Caos?
toxiproxy ou injeção de falhas de malha em staging.
Maior erro único?
Sem tempos limite em HTTP de saída bloqueando workers do Tokio sob lentidão upstream.
Relacionados
- Clientes HTTP (reqwest) - Configuração do cliente
- Retentativas, Tempos Limite e Backoff - Políticas
- TLS com rustls - Criptografia
- Melhores Práticas de Backends Web - Lado do servidor
- Melhores Práticas de APIs e Segurança - Linha de base de autenticação
Versões das Ferramentas: Esta página foi escrita para Rust 1.97.0 (edição 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4 e Polars 0.46+.