O desempenho de streaming não é apenas uma preocupação de um reprodutor de vídeo. Artefatos de software, pesos de modelos, backups, bibliotecas de áudio e grandes exportações de APIs dependem todos dos mesmos fundamentos: mover bytes rapidamente, preservar a carga útil exata, respeitar a retropressã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 ficheiros, encaminhamento reverso e WebTransport. O caminho rápido é útil apenas quando preserva a estrutura, cancelamento, cabeçalhos finais, inspeção de segurança e memória limitada.
Capacidade de transmissão medida de 100 MB
A capacidade do Webship 1.3.1 Debian foi medida através da mediana do débito de carga útil com um dispositivo fixo de 100 MB. Cada amostra aceite exigiu exatamente um 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 directa de ficheiros | 4,194,8 MiB/s | 3,574,3 MiB/s | 2,096,9 MiB/s | | Proxy inverso 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 registada, Webship produziu a mediana directa e a terminada em TLS mais alta para cada protocolo medido. A matriz completa inclui Nginx, Lighttpd, Caddy, HAProxy, Envoy, Pingora e Bun na [página de benchmarks](/benchmarks).
Estes números medem a capacidade no host de referência. Não são uma promessa para um caminho de internet arbitrário. A latência de armazenamento, a largura de banda da rede, o tempo de ida e volta, a perda de pacotes, a política TLS, a concorrência e o comportamento da origem ainda determinam a velocidade real de entrega.
Um binário, três estratégias de transporte
Uma resposta grande não beneficia da mesma política que um pequeno documento HTML. Webship mantém o caminho de pedido ordinário conservador e promove apenas uma resposta em massa comprovada.
HTTP/1.1: menos transições em torno do ficheiro
No Linux, Webship mantém o cabeçalho da resposta e o conteúdo do ficheiro dentro de um único intervalo TCP cork de melhor esforço. Uma vez que uma grande resposta TLS se qualifique para o caminho de dados a granel, a entrega direta do ficheiro pode passar dos registos Rustls para TLS kernel unidirecional auditado e usar sendfile sem copiar o conteúdo através de um buffer de aplicação.
A ligação ainda começa no TLS em espaço de utilizador. Pequenas respostas permanecem lá. Webship solicita a transição para kTLS apenas depois de um corpo de resposta de pelo menos 1 MiB provar que a ligação está a transportar dados em massa.
HTTP/2: processamento em lote sem interromper o controlo de fluxo
HTTP/2 a multiplexação torna o buffering incontrolado caro. Webship agrupa escritas enquanto mantém os limites de controlo de fluxo do stream e da ligação. Para streaming de alta concorrência, um buffer de escrita TLS de 128 KiB pode conter dois quadros de DADOS de 64 KiB, enquanto o orçamento de envio da ligação permanece explícito e limitado.
Um quadro de corpo ascendente já pronto pode ser pré-carregado sem contornar a Hyper framing, os trailers, o cancelamento, a inspeção ou a contrapressão. Isso reduz uma ronda evitável do agendador, mantendo o contrato do protocolo intacto.
HTTP/3: Ritmo QUIC em vez de kTLS
HTTP/3 nunca usa o caminho TCP kTLS. Webship aplica o pacing QUIC consciente do transporte, a packetização de datagramas limitada, DPLPMTUD e micro-lotes acionados por temporizador por reator. Grandes respostas HTTP/3 e sessões WebTransport aceites podem selecionar BBR sem alterar a política CUBIC usada pelo tráfego normal.
A qualificação de estabilidade focada HTTP/3 utilizou sete amostras aceites. A transmissão em streaming terminada em TLS apresentou uma mediana de 1.938,6 MiB/s com um coeficiente de variação de 2,12%. A passagem direta de TLS apresentou 1.748,5 MiB/s com um coeficiente de variação de 1,65%. Ambas as séries não registaram erros de integridade do corpo, do cliente, do protocolo nem de perda de pacotes.
Entrega direta ou proxy reverso?
Use entrega direta quando Webship possuir a árvore de ficheiros implantada. Isso remove o salto de origem e permite o caminho de ficheiros estáticos mais eficiente.
Um site multi-protocolo minimalista parece assim:
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"Utilize terminação TLS no reverse-proxy quando Webship precisar de encaminhar por caminho, aplicar verificações 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 necessitar de reter o texto simples da aplicação e as chaves de sessão ativas. A passagem direta não pode inspecionar campos HTTP encriptados. A passagem direta TCP, portanto, encaminha pelo SNI do ClientHello, enquanto a passagem direta HTTP/3 requer uma origem UDP partilhada.
Ajustar explicitamente a transmissão em massa
Para streaming TLS de alta concorrência HTTP/2, Webship documenta estas definições ligadas 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 ligação acima fornece 128 KiB de crédito para 256 streams ativos. Considere-o como uma decisão de capacidade, não como um padrão universal. Meça a memória, a latência e a taxa de transferência com a sua concorrência esperada antes de a aumentar.
No Linux, carregue os módulos TLS e BBR do kernel e permita que a conta de serviço Webship selecione o BBR. O Webship falha antes de se ligar quando a sua capacidade de kernel necessária não está disponível, portanto uma implementação não pode reivindicar silenciosamente o caminho otimizado enquanto funciona sem ele. Outros sistemas operativos mantêm os caminhos portáteis Rustls e de controlo de congestionamento documentados para a sua plataforma.
WebTransport é uma forma de streaming diferente
WebTransport combina fluxos fiáveis e datagramas não fiáveis sobre uma sessão segura. Não utiliza TCP kTLS. O endpoint de diagnóstico limitado do Webship valida origens e aplica limites de sessão, fluxo, cápsula, datagrama, bytes e tempo de inatividade.
Na execução de capacidade 1.3.1, o WebTransport direto atingiu 1.018,1 MiB/s para fluxos fiáveis e 1.038,9 MiB/s para datagramas. O encaminhamento TLS atingiu 548,6 MiB/s e 629,7 MiB/s, respetivamente. Ambos os modos passaram todas as cinco amostras sem qualquer amostra rejeitada, sem datagramas perdidos e sem 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 irá fornecer, não apenas uma resposta sintética pequena.
- Verifique o comprimento da resposta e o resumo do conteúdo no cliente.
- Cancelamento de exercícios, pedidos de alcance, leitores lentos e comportamento de meia-fechadura de origem.
- Meça o débito sustentado juntamente com CPU, memória, erros de soquete, retransmissões e latência final.
- Valide os modos direto, terminado em TLS e passthrough separadamente; eles têm 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, no contentor ou na sandbox do systemd.
A transmissão em fluxo é rápida quando todo o percurso coopera. O design de Webship mantém as otimizações de dados em grande escala específicas do protocolo enquanto preserva um modelo operacional e uma referência de corretude.
Leia a documentação completa [Webship 1.3.1](/docs/1.3.1), consulte a [metodologia de benchmarking e a matriz de concorrentes](/benchmarks), ou descarregue uma versão assinada a partir de [Downloads](/downloads).