Voltar ao blog Webship

Engenharia Webship

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

O Webship transforma os requisitos das RFC em comportamento explícito através de HTTP/1.1, HTTP/2, HTTP/3, QUIC, TLS, caching, proxy reverso, WebTransport, ACME e o novo método QUERY. Explore o mapa completo das normas das 52 RFC.

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

O Webship 1.3.1 é construído em torno de uma regra: a velocidade só conta quando os bytes mantêm o 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 todas as funcionalidades opcionais em todos os RFC existem. O mapa abaixo indica os 52 RFCs que influenciam o comportamento activo do servidor do Webship ou as suas fundações 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 normas nos locais onde os servidores de produção mais frequentemente se tornam ambíguos:

  • A estrutura HTTP/1.1 rejeita comprimentos conflitantes, codificações de transferência inválidas, alvos de pedido excessivamente grandes, fragmentos malformados e formas de contrabando de pedidos.
  • HTTP/2 e HTTP/3 rejeitam campos de conexão proibidos, validam pseudo-campos, limitam secções de campos comprimidos e mantêm erros de fluxo separados dos erros de conexão.
  • Os ficheiros estáticos preservam a semântica HEAD, os validadores, a ordem das pré-condições, os intervalos de bytes, os redirecionamentos e os tipos de conteúdo.
  • O proxy inverso preserva a estrutura, cancelamento, trailers, atualizações, tentativas seguras e identidade de encaminhamento enquanto remove campos de salto a salto.
  • A cache calcula idade, frescor, revalidação, Vary, invalidação e regras de uso obsoleto, em vez de tratar o armazenamento em 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 aplicam-se no caminho rápido. O Webship não define um caminho “correto” e um caminho de referência diferente.

Semântica, enquadramento, 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 de decisões de invalidação de cache.
  • RFC 6455 — O Protocolo WebSocket. As atualizações de reverse-proxy validam a chave WebSocket, o valor aceito, o subprotocolo, as extensões e a transição do túnel.
  • RFC 6585 — Códigos de Estado HTTP Adicionais. Campos de pedido demasiado 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 controlo MCP protegida. A sua semântica geral do HTTP vive agora no RFC 9110.
  • RFC 7239 — Extensão HTTP Forwarded. Os operadores podem selecionar um campo Forwarded baseado em normas, campos X-Forwarded legados, ambos ou nenhum; os campos de identidade de entrada não confiáveis são removidos primeiro.
  • RFC 7540 — HTTP/2. Isto é mantido como linha de compatibilidade do HTTP/2; o contrato ativo do HTTP/2 é o seu sucessor, RFC 9113.
  • RFC 7541 — HPACK: Compressão de Cabeçalhos para HTTP/2. A pilha HTTP/2 da Webship limita o estado do descodificador 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 — Inicialização de WebSockets com HTTP/2. O Webship suporta a base de negociação extended-CONNECT a jusante. Não finge que um upstream HTTP/1.1 implemente o extended CONNECT do HTTP/2; combinações de upstream não suportadas falham de forma explícita.
  • RFC 8470 — Utilização de Dados Precoce em HTTP. Os pedidos iniciais que o Webship não processará recebem 425 Too Early em vez de serem tratados com pressupostos de repetição não seguros.
  • RFC 8941 — Valores de Campos Estruturados para HTTP. Os valores de prioridade HTTP utilizam a análise de dicionário de campos estruturados; os campos opcionais malformados são ignorados na totalidade.
  • RFC 9110 — Semântica HTTP. Métodos, códigos de estado, campos, validadores, pré-condições, redirecionamentos, metadados de conteúdo, HEAD, CONNECT, OPTIONS e a semântica de intervalos partilham um contrato atual numa versão única do protocolo.
  • RFC 9111 — Cacheamento HTTP. O Webship implementa idade corrigida, frescura explícita, Vary, only-if-cached, must-revalidate, proxy-revalidate, utilização segura de stale e invalidação de URIs eficazes e relacionadas.
  • RFC 9112 — HTTP/1.1. As regras de linha de pedido, campo, comprimento do corpo, codificação de transferência, fragmento, trailer, persistência e encerramento delimitado são aplicadas antes do envio para a aplicação.
  • RFC 9113 — HTTP/2. A ordem do pseudo-campo, autoridade, campos de ligação proibidos, restrições TE, ciclo de vida do fluxo, controlo de fluxo, GOAWAY e o âmbito do erro são geridos pelo caminho H2 pertencente ao Webship.
  • RFC 9114 — HTTP/3. A Webship detém os caminhos de request, control-stream, SETTINGS, critical-stream, cancelamento e stream-versus-connection utilizados pelo 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ções permanecem analisáveis com capacidade zero, e o estado inválido torna-se o erro QPACK necessário.
  • RFC 9218 — Esquema de Prioritizaçã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 — Inicialização de WebSockets com HTTP/3. O Webship implementa a base SETTINGS extended-CONNECT do HTTP/3 utilizada por protocolos encapsulados modernos; isso não implica que todos os protocolos CONNECT possíveis sejam aceites.
  • RFC 9297 — Datagramas HTTP e o Protocolo Capsule. As sessões WebTransport utilizam decodificação de cápsula limitada e associação de Datagramas 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 opcional de respostas Ed25519 pode abranger a identidade da versão e configuração do Webship sem substituir o TLS ou a autenticação da aplicação.
  • RFC 10008 — O Método QUERY do HTTP. O Webship trata QUERY como seguro e idempotente, preserva o seu corpo durante o encaminhamento através de proxy, inclui o corpo e os metadados da representação na identidade da cache, proíbe a frescura heurística, suporta comportamento condicional e de intervalo, e nunca invalida uma cache apenas porque o QUERY foi utilizado.

Transporte QUIC e controlo de congestionamento

TLS, certificados e gestão automática de certificados

WebTransport: preciso sobre o que está normalizado

O WebTransport sobre HTTP/3 não é contado como um cinquenta e terceiro RFC. A partir do Webship 1.3.1, a sua mapeamento de fio permanece como draft-ietf-webtrans-http3-16. O Webship implementa esse rascunho em cima do HTTP/3 padronizado, CONNECT estendido, QUIC DATAGRAM, HTTP Datagram e camadas de Capsule mencionadas acima. 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 fluxo WebTransport é reiniciado.

Essa distinção importa. A compatibilidade com os padrões não é melhorada ao chamar um rascunho de RFC. É melhorada ao rastrear o rascunho explicitamente, isolando-o dos caminhos HTTP ordinários, negociando cada extensão, limitando cada recurso de sessão e testando o comportamento em caso de cancelamento e falha.

Porque é que esta amplitude é importante na produção

Um bug de normas é raramente isolado. O tratamento incorreto de HSTS pode atravessar uma fronteira de cache. Uma instrução QPACK malformada pode terminar pedidos não relacionados. Uma suposição insegura sobre dados antecipados pode reproduzir uma operação. Uma chave de cache QUERY que omite o corpo do pedido pode retornar o resultado de uma consulta diferente. Um proxy que remove trailers ou lida mal com cancelamentos pode alterar silenciosamente um protocolo de aplicação.

A arquitetura da Webship trata estes como preocupações ligadas. Limites do parser, inspeção de segurança, caching, proxy reverso, estado de transporte e instrumentação partilham 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 corretude.

Verificar a reivindicação

Não aceite um superlativo sem confiança. Leia a [documentação do Webship 1.3.1](/docs/1.3.1), verifique a configuração e os limites do protocolo e reproduza o comportamento publicado. Depois [descarregue o Webship](/downloads) e teste os casos limite que são importantes para o seu sistema.

Engenharia Webship

Streaming com Webship: Alto Débito Sem Comprometer a Correção

Aprenda como Webship serve e proxy ficheiros multimédia grandes através de HTTP/1.1, HTTP/2 e HTTP/3 usando kTLS adaptativo, ritmo BBR, buffers limitados e portões de integridade sem erros.

Ler artigo

O Seu Servidor Web É Uma Decisão de Custo de Infraestrutura

Webship combina entrega de Rust de alto rendimento, protocolos modernos, proteção integrada, observabilidade local e operações nativas de IA numa única runtime—oferecendo às equipas de infraestrutura um caminho credível para menos servidores e menos componentes de edge.

Ler artigo

Webship 1.3.1: Capacidade Superior de HTTP/2 e de Reverse-Proxy

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, ao mesmo tempo que reforça a estabilidade e a correção do transporte.

Ler artigo