De volta ao blog Webship

Engenharia Webship

Webship: O Servidor Web Mais Compatível com RFC do Mundo

O Webship transforma os requisitos do RFC em comportamento explícito em HTTP/1.1, HTTP/2, HTTP/3, QUIC, TLS, cache, proxy reverso, WebTransport, ACME e o novo método QUERY. Explore o mapa completo de padrões de 52 RFCs.

A web é mantida unida por acordos exatos. Um campo Content-Length deve significar a mesma coisa a cada salto. Um cache não deve reutilizar uma resposta que requer validação. Uma seção de campo HTTP/3 malformada deve falhar no escopo correto. Um método seguro deve permanecer seguro depois de passar por um proxy reverso.

O Webship 1.3.1 é construído em torno de uma regra: a velocidade só conta quando os bytes mantêm seu significado.

É por isso que descrevemos o Webship como o servidor web de uso geral mais compatível com RFC do mundo. Esta é uma afirmativa de engenharia com um limite visível, não uma afirmação de que todos os recursos opcionais de todas as RFCs existem. O mapa abaixo nomeia as 52 RFCs que afetam o comportamento ativo do servidor Webship ou suas bases de protocolo próprias. Os padrões atuais vêm primeiro. Documentos substituídos são identificados como linhagem de compatibilidade. Especificações em rascunho não são reclassificadas como RFCs.

Compatibilidade é comportamento, não um distintivo

O Webship aplica padrões nos lugares onde os servidores de produção mais frequentemente se tornam ambíguos:

  • O encapsulamento HTTP/1.1 rejeita comprimentos conflitantes, codificações de transferência inválidas, alvos de requisição exageradamente grandes, pedaços malformados e formatos de contrabando de requisições.
  • HTTP/2 e HTTP/3 rejeitam campos de conexão proibidos, validam pseudo-campos, limitam seções de campos comprimidos e mantêm erros de fluxo separados de erros de conexão.
  • Arquivos estáticos preservam a semântica HEAD, validadores, ordem de pré-condição, intervalos de bytes, redirecionamentos e tipos de conteúdo.
  • O proxy reverso preserva a estrutura, cancelamento, trailers, atualizações, tentativas seguras e identidade de encaminhamento enquanto remove campos de salto a salto.
  • O cache calcula idade, frescor, revalidação, Vary, invalidação e regras de uso obsoleto, em vez de tratar o cache como um atalho de chave-valor.
  • TLS, QUIC, ACME, dados iniciais e WebTransport usam estado limitado e política de falha explícita.

As mesmas regras se aplicam no caminho rápido. O Webship não define um caminho “correto” e um caminho de referência diferente.

Semântica, estruturação, cache e proxy de HTTP

  • RFC 3986 — Identificador Uniforme de Recursos (URI): Sintaxe Genérica. O Webship normaliza referências relativas de Location e Content-Location, incluindo segmentos ponto, antes das decisões de invalidação de cache.
  • RFC 6455 — O Protocolo WebSocket. As atualizações de proxy reverso validam a chave WebSocket, o valor aceito, o subprotocolo, as extensões e a transição do túnel.
  • RFC 6585 — Códigos de Status HTTP Adicionais. Campos de solicitação excessivamente grandes utilizam a resposta 431 definida quando uma resposta HTTP ainda é possível.
  • RFC 6797 — HTTP Strict Transport Security. Strict-Transport-Security é emitido apenas sobre transporte seguro e nunca vaza de uma entrada de cache neutra ao transporte para HTTP em texto claro.
  • RFC 7235 — Autenticação HTTP/1.1. Os tokens do esquema de autenticação são analisados de forma insensível a maiúsculas e minúsculas, incluindo a superfície de controle MCP protegida. Sua semântica geral do HTTP agora está no RFC 9110.
  • RFC 7239 — Extensão HTTP Forwarded. Os operadores podem selecionar um campo Forwarded baseado em padrões, campos X-Forwarded legados, ambos ou nenhum; campos de identidade de entrada não confiáveis são removidos primeiro.
  • RFC 7540 — HTTP/2. Isso é mantido como linhagem de compatibilidade com HTTP/2; o contrato ativo do HTTP/2 é seu sucessor, RFC 9113.
  • RFC 7541 — HPACK: Compressão de Cabeçalhos para HTTP/2. A pilha HTTP/2 própria da Webship limita o estado do decodificador e as tabelas do codificador, enquanto preserva o formato de transmissão HPACK e a codificação Huffman.
  • RFC 7838 — Serviços Alternativos HTTP. Alt-Svc anuncia um endpoint HTTP/3 sem alterar a origem representada pelo URL.
  • RFC 8441 — Inicializando WebSockets com HTTP/2. O Webship suporta a base de negociação extended-CONNECT a jusante. Ele não finge que um upstream HTTP/1.1 implemente CONNECT estendido do HTTP/2; combinações de upstream não suportadas falham explicitamente.
  • RFC 8470 — Usando Dados Precoce no HTTP. Solicitações iniciais que o Webship não processará recebem 425 Too Early em vez de serem tratadas com suposições inseguras de repetição.
  • RFC 8941 — Valores de Campos Estruturados para HTTP. Valores de prioridade HTTP usam análise de dicionário de campo estruturado; campos opcionais malformados são ignorados por completo.
  • RFC 9110 — Semântica HTTP. Métodos, códigos de status, campos, validadores, pré-condições, redirecionamentos, metadados de conteúdo, HEAD, CONNECT, OPTIONS e a semântica de faixa compartilham um contrato atual entre as versões do protocolo.
  • RFC 9111 — Cache HTTP. O Webship implementa idade corrigida, frescor explícito, Vary, only-if-cached, must-revalidate, proxy-revalidate, uso seguro de stale e invalidação de URIs efetivas e relacionadas.
  • RFC 9112 — HTTP/1.1. As regras de linha de requisição, campo, comprimento do corpo, codificação de transferência, chunk, trailer, persistência e encerramento delimitado são aplicadas antes do despacho para a aplicação.
  • RFC 9113 — HTTP/2. Ordem do pseudo-campo, autoridade, campos de conexão proibidos, restrições de TE, ciclo de vida do fluxo, controle de fluxo, GOAWAY e escopo de erro são tratados pelo caminho H2 de propriedade da Webship.
  • RFC 9114 — HTTP/3. A Webship possui os caminhos de requisição, fluxo de controle, SETTINGS, fluxo crítico, cancelamento e erro de fluxo versus conexão utilizados por seu servidor HTTP/3.
  • RFC 9204 — QPACK: Compressão de Campos para HTTP/3. A capacidade da tabela dinâmica é limitada pelo limite anunciado, os fluxos de instrução permanecem analisáveis com capacidade zero e o estado inválido se torna o erro QPACK necessário.
  • RFC 9218 — Esquema de Priorização Extensível para HTTP. A urgência e a entrega incremental orientam o agendamento do HTTP/3 enquanto os parâmetros de prioridade desconhecidos permanecem extensíveis.
  • RFC 9220 — Inicializando WebSockets com HTTP/3. O Webship implementa a base HTTP/3 extended-CONNECT SETTINGS usada por protocolos modernos tunelados; isso não implica que todo protocolo CONNECT possível seja aceito.
  • RFC 9297 — Datagramas HTTP e o Protocolo Capsule. Sessões WebTransport usam decodificação de cápsula limitada e associação de Datagrama HTTP, com cápsulas desconhecidas tratadas como pontos de extensão em vez de falhas do analisador.
  • RFC 9421 — Assinaturas de Mensagens HTTP. A proveniência de resposta Ed25519 opcional pode abranger a identidade de lançamento e configuração do Webship sem substituir o TLS ou a autenticação do aplicativo.
  • RFC 10008 — O Método QUERY do HTTP. O Webship trata QUERY como seguro e idempotente, preserva seu corpo durante o proxy, inclui corpo e metadados de representação na identidade do cache, proíbe a frescura heurística, suporta comportamento condicional e de intervalo, e nunca invalida um cache apenas porque QUERY foi usado.

Transporte QUIC e controle de congestionamento

TLS, certificados e gerenciamento automático de certificados

WebTransport: preciso sobre o que está padronizado

WebTransport sobre HTTP/3 não é contado como o quinquagésimo terceiro RFC. A partir do Webship 1.3.1, seu mapeamento de protocolo permanece draft-ietf-webtrans-http3-16. O Webship implementa esse rascunho em cima do HTTP/3 padronizado, CONNECT estendido, QUIC DATAGRAM, Datagram HTTP e as camadas Capsule mencionadas acima. Ele também implementa a extensão negociada RESET_STREAM_AT necessária para preservar um prefixo de identificação de sessão confiável quando um stream do WebTransport é reiniciado.

Essa distinção importa. A compatibilidade com padrões não é melhorada ao chamar um rascunho de RFC. Ela é melhorada ao rastrear o rascunho explicitamente, isolando-o dos caminhos HTTP comuns, negociando cada extensão, delimitando cada recurso de sessão e testando o comportamento de cancelamento e falha.

Por que essa amplitude importa na produção

Um bug de padrão raramente é isolado. O tratamento incorreto de HSTS pode atravessar uma fronteira de cache. Uma instrução QPACK malformada pode encerrar solicitações não relacionadas. Uma suposição insegura de dados antecipados pode repetir uma operação. Uma chave de cache QUERY que omite o corpo da solicitação pode retornar o resultado de uma consulta diferente. Um proxy que remove trailers ou lida incorretamente com cancelamentos pode alterar silenciosamente um protocolo de aplicação.

A arquitetura do Webship trata esses como preocupações conectadas. Limites do parser, inspeção de segurança, cache, proxy reverso, estado de transporte e instrumentação compartilham contratos explícitos. O resultado é um servidor que pode transitar entre HTTP/1.1, HTTP/2, HTTP/3, entrega estática, proxy reverso, streaming e WebTransport sem dar a cada modo uma definição diferente de correção.

Verifique a reivindicação

Não aceite um superlativo sem questionar. Leia a [documentação do Webship 1.3.1](/docs/1.3.1), inspecione a configuração e os limites do protocolo, e reproduza o comportamento publicado. Em seguida, [baixe o Webship](/downloads) e teste os casos extremos que importam para o seu sistema.

Engenharia Webship

Streaming com Webship: Alta Taxa de Transferência Sem Comprometer a Correção

Aprenda como Webship serve e proxy arquivos de mídia grandes sobre HTTP/1.1, HTTP/2 e HTTP/3 usando kTLS adaptativo, pacing BBR, buffers limitados e portas de integridade sem erros.

Ler artigo

Seu Servidor Web É uma Decisão de Custo de Infraestrutura

Webship combina entrega de Rust de alta produtividade, protocolos modernos, proteção integrada, observabilidade local e operações nativas de IA em um único runtime—oferecendo às equipes de infraestrutura um caminho confiável para menos servidores e menos componentes de borda.

Ler artigo

Webship 1.3.1: Capacidade Superior de HTTP/2 e Proxy Reverso

Webship 1.3.1 aumenta a capacidade direta h2c em 34,19%, o TLS direto HTTP/2 em 26,67% e o H1 de proxy reverso em 15,10% em comparação com a versão 1.2.0, enquanto fortalece a estabilidade e a corretude do transporte.

Ler artigo