O desempenho de streaming não é apenas uma preocupação de players de vídeo. Artefatos de software, pesos de modelos, backups, bibliotecas de áudio e grandes exportações de API dependem todos dos mesmos fundamentos: mover bytes rapidamente, preservar a carga útil exata, respeitar a contrapressão e parar de forma limpa quando um cliente se desconecta.
Webship trata esses requisitos como um único problema de transporte através de HTTP/1.1, HTTP/2, HTTP/3, entrega direta de arquivos, proxy reverso e WebTransport. O caminho rápido é útil apenas quando preserva o enquadramento, cancelamento, cabeçalhos finais, inspeção de segurança e memória limitada.
Capacidade de streaming medida em 100 MB
A capacidade do Webship 1.3.1 Debian foi medida pelo desempenho mediano do payload com um dispositivo fixo de 100 MB. Cada amostra aceita exigiu exatamente o corpo de resposta de 99.943.778 bytes e zero erros de cliente, protocolo, proxy, falha de página principal e HTTP/3 perda de pacotes.
| modo Webship | TLS HTTP/1.1 | TLS HTTP/2 | TLS HTTP/3 | | --- | ---: | ---: | ---: | | Entrega direta de arquivo | 4.194,8 MiB/s | 3.574,3 MiB/s | 2.096,9 MiB/s | | Proxy reverso com terminação TLS | 3.585,7 MiB/s | 3.355,0 MiB/s | 1.938,6 MiB/s | | Proxy reverso com passagem TLS | 2.783,2 MiB/s | 2.135,0 MiB/s | 1.748,5 MiB/s |
Na comparação registrada, Webship produziu a maior mediana direta e com TLS encerrado para cada protocolo medido. A matriz completa inclui Nginx, Lighttpd, Caddy, HAProxy, Envoy, Pingora e Bun na [página de benchmarks](/benchmarks).
Esses números medem a capacidade no host de referência. Eles não são uma promessa para um caminho arbitrário na internet. Latência de armazenamento, largura de banda da rede, tempo de ida e volta, perda de pacotes, política de TLS, concorrência e comportamento da origem ainda determinam a velocidade real de entrega.
Um binário, três estratégias de transporte
Uma resposta grande não se beneficia da mesma política que um pequeno documento HTML. Webship mantém o caminho de solicitação comum conservador e promove apenas uma resposta em massa comprovada.
HTTP/1.1: menos transições ao redor do arquivo
No Linux, Webship mantém o cabeçalho da resposta e o conteúdo do arquivo dentro de um único intervalo TCP cork de melhor esforço. Uma vez que uma grande resposta TLS se qualifique para o caminho em massa, a entrega direta de arquivos pode passar de registros Rustls para TLS de kernel unidirecional auditado e usar sendfile sem copiar o conteúdo pelo buffer da aplicação.
A conexão ainda começa no TLS em espaço do usuário. Pequenas respostas permanecem lá. Webship solicita a transição para kTLS apenas após o corpo da resposta de pelo menos 1 MiB provar que a conexão está transportando dados em massa.
HTTP/2: processamento em lote sem interromper o controle de fluxo
HTTP/2 multiplexação torna o buffer descontrolado caro. Webship agrupa gravações enquanto mantém os limites de fluxo de controle de stream e conexão. Para streaming de alta concorrência, um buffer de gravação TLS de 128 KiB pode conter dois frames DATA de 64 KiB, enquanto o orçamento de envio da conexão permanece explícito e limitado.
Um quadro de corpo upstream já pronto pode ser pré-buscado sem contornar o Hyper framing, trailers, cancelamento, inspeção ou pressão de retorno. Isso reduz uma rodada evitável do agendador enquanto mantém o contrato do protocolo intacto.
HTTP/3: Controle de ritmo QUIC em vez de kTLS
HTTP/3 nunca usa o caminho TCP kTLS. Webship aplica paceamento QUIC consciente do transporte, segmentação de datagramas limitada, DPLPMTUD e micro-lotes acionados por temporizador por reator. Grandes respostas HTTP/3 e sessões WebTransport aceitas podem selecionar BBR sem alterar a política CUBIC usada pelo tráfego comum.
A qualificação de estabilidade focada HTTP/3 utilizou sete amostras aceitas. A transmissão em streaming com TLS terminado entregou uma mediana de 1.938,6 MiB/s com 2,12% de coeficiente de variação. A transmissão TLS pass-through entregou 1.748,5 MiB/s com 1,65% de coeficiente de variação. Ambas as séries não apresentaram erros de integridade do corpo, cliente, protocolo ou perda de pacotes.
Entrega direta ou proxy reverso?
Use entrega direta quando Webship possuir a árvore de arquivos implantada. Isso remove o salto de origem e permite o caminho de arquivo estático mais eficiente.
Um site mínimo multi-protocolo se parece com isto:
listen = "0.0.0.0:443"
workers = 8
root = "/srv/media"
[[sites]]
domain = "media.example.com"
root = "/srv/media"
[sites.protocols]
h1 = true
h2 = true
h3 = true
[sites.tls]
cert = "/etc/webship/media-cert.pem"
key = "/etc/webship/media-key.pem"Use a terminação TLS de proxy reverso quando Webship precisar rotear por caminho, aplicar verificações de WAF ou API Shield, impor limites de corpo, adicionar cabeçalhos de encaminhamento ou observar campos HTTP:
[reverse_proxy]
enabled = true
tls_termination = true
[reverse_proxy.protocols]
h1 = true
h2 = true
h3 = true
[reverse_proxy.tls]
cert = "/etc/webship/proxy-cert.pem"
key = "/etc/webship/proxy-key.pem"
[[reverse_proxy.routes]]
domain = "media.example.com"
path_prefix = "/"
upstreams = ["10.0.0.20:8080"]Defina tls_termination = false quando a origem precisar reter o texto simples do aplicativo e as chaves de sessão ativas. O encaminhamento direto não pode inspecionar campos HTTP criptografados. O encaminhamento TCP, portanto, roteia pelo SNI do ClientHello, enquanto o encaminhamento HTTP/3 requer uma origem UDP compartilhada.
Ajustar streaming em massa explicitamente
Para streaming TLS de alta concorrência HTTP/2, Webship documenta essas configurações vinculadas ao processo:
[runtime.settings]
h2_tls_write_buffer_bytes = "131072"
proxy_h2_tls_max_send_buffer_bytes = "131072"
proxy_h2_tls_connection_send_buffer_bytes = "33554432"O orçamento de conexão acima fornece 128 KiB de crédito para 256 streams ativos. Trate isso como uma decisão de capacidade, não como um padrão universal. Meça memória, latência e taxa de transferência com sua concorrência esperada antes de aumentá-lo.
No Linux, carregue os módulos TLS e BBR do kernel e permita que a conta de serviço Webship selecione o BBR. Webship falha antes de vincular quando sua capacidade de kernel necessária não está disponível, então uma implantação não pode reivindicar silenciosamente o caminho otimizado enquanto está sendo executada sem ele. Outros sistemas operacionais mantêm os caminhos portáteis Rustls e de controle de congestionamento documentados para sua plataforma.
WebTransport é uma forma de streaming diferente
WebTransport combina fluxos confiáveis e datagramas não confiáveis sobre uma sessão segura. Ele não usa TCP kTLS. O endpoint de diagnóstico limitado do Webship valida origens e aplica limites de sessão, fluxo, cápsula, datagrama, byte e tempo ocioso.
Na execução de capacidade 1.3.1, o WebTransport direto alcançou 1.018,1 MiB/s para streams confiáveis e 1.038,9 MiB/s para datagramas. A passagem TLS alcançou 548,6 MiB/s e 629,7 MiB/s, respectivamente. Ambos os modos passaram em todas as cinco amostras com zero amostras rejeitadas, zero datagramas perdidos e zero falhas graves de cliente.
Prefira HTTP/3 para novos clientes WebTransport. O caminho HTTP/2 existe para compatibilidade com as configurações antigas de rascunho expirado.
O que verificar antes do tráfego de produção
- Teste os tamanhos exatos de mídia ou artefato que você irá fornecer, não apenas uma pequena resposta sintética.
- Verifique o comprimento da resposta e o resumo do conteúdo no cliente.
- Cancelamento de exercícios, solicitações de intervalo, leitores lentos e comportamento de origem semi-fechada.
- Meça a taxa de transferência sustentada juntamente com CPU, memória, erros de soquete, retransmissões e latência de cauda.
- Valide os modos direto, com TLS encerrado e passante separadamente; eles possuem diferentes limites de segurança e roteamento.
- Mantenha a instrumentação desligada para o tráfego normal de produção e, em seguida, ative diagnósticos limitados deliberadamente ao investigar.
- Verifique novamente o kTLS e o pré-voo do BBR no Linux após alterações no kernel, container ou sandbox do systemd.
O streaming é rápido quando todo o caminho coopera. O design do Webship mantém as otimizações de dados em massa específicas para cada protocolo, ao mesmo tempo em que preserva um modelo operacional e um padrão de corretude.
Leia a [documentação completa do Webship 1.3.1](/docs/1.3.1), verifique a [metodologia de benchmark e matriz de concorrentes](/benchmarks), ou baixe uma versão assinada em [Downloads](/downloads).