Tillbaka till Webship bloggen

Webship teknik

Webship: Den mest RFC-kompatibla webbservern i världen

Webship omvandlar RFC-krav till tydligt beteende över HTTP/1.1, HTTP/2, HTTP/3, QUIC, TLS, caching, reverse proxying, WebTransport, ACME och den nya QUERY-metoden. Utforska den kompletta kartan över 52 RFC-standarder.

Webben hålls ihop av exakta överenskommelser. Ett Content-Length-fält måste betyda samma sak vid varje steg. En cache får inte återanvända ett svar som kräver validering. En felaktigt formaterad HTTP/3-fältssektion måste misslyckas på korrekt nivå. En säker metod måste förbli säker efter att den passerar genom en omvänd proxy.

Webship 1.3.1 är byggt kring en regel: hastighet räknas bara när byte behåller sitt betydelse.

Det är därför vi beskriver Webship som den mest RFC-kompatibla allmänna webbservern i världen. Detta är ett ingenjörspåstående med en tydlig gräns, inte ett påstående om att varje valfri funktion i varje RFC finns. Kartan nedan namnger de 52 RFC:er som påverkar Webships aktiva serverbeteende eller dess egna protokollgrunder. Nuvarande standarder kommer först. Ersatta dokument identifieras som kompatibilitetslinje. Utkastsspecifikationer får inte ometiketteras som RFC:er.

Kompatibilitet är beteende, inte en märkesbricka

Webship tillämpar standarder på de platser där produktionsservrar oftast blir tvetydiga:

  • HTTP/1.1-ramverk avvisar motstridiga längder, ogiltiga överföringskodningar, överdimensionerade begäransmål, felaktigt formade chunkar och former av request-smuggling.
  • HTTP/2 och HTTP/3 avvisar förbjudna anslutningsfält, validerar pseudo-fält, begränsar komprimerade fältsektioner och håller strömfel åtskilda från anslutningsfel.
  • Statiska filer bevarar HEAD-semantik, validatorer, förhandsvillkorsordning, byteintervall, omdirigeringar och innehållstyper.
  • Reverse proxy bevarar inramning, avbokning, släp, uppgraderingar, säkra omförsök och vidarebefordring av identitet samtidigt som man tar bort hopp-för-hopp-fält.
  • Cachen beräknar ålder, färskhet, omvalidering, Vary, ogiltigförklaring och regler för användning av föråldrad data snarare än att behandla caching som en nyckel-värde-genväg.
  • TLS, QUIC, ACME, tidiga data och WebTransport använder begränsat tillstånd och uttrycklig felpolicy.

Samma regler gäller på den snabba vägen. Webship definierar inte en "korrekt" väg och en annan referensväg.

HTTP-semantik, inramning, cachning och proxyanvändning

  • RFC 3986 — Uniform Resource Identifier (URI): Generisk syntax. Webship normaliserar relativa Location- och Content-Location-referenser, inklusive punktsegment, före beslut om cache-ogiltigförklaring.
  • RFC 6455 — WebSocket-protokollet. Reverse-proxy-uppgraderingar validerar WebSocket-nyckeln, acceptvärdet, delprotokoll, tillägg och tunnelövergång.
  • RFC 6585 — Ytterligare HTTP-statuskoder. Överdimensionerade begäranfält använder det definierade 431-svaret där ett HTTP-svar fortfarande är möjligt.
  • RFC 6797 — HTTP Strict Transport Security. Strict-Transport-Security sänds endast över säker överföring och läcker aldrig från en transportneutral cachepost till klartext-HTTP.
  • RFC 7235 — HTTP/1.1-autentisering. Autentiseringsscheman tokens tolkas utan att beakta stora eller små bokstäver, inklusive den skyddade MCP-styrpanelen. Dess allmänna HTTP-semantik finns nu i RFC 9110.
  • RFC 7239 — Forwarded HTTP Extension. Operatörer kan välja ett standardbaserat Forwarded-fält, äldre X-Forwarded-fält, båda eller inga; opålitliga inkommande identitetsfält tas bort först.
  • RFC 7540 — HTTP/2. Detta bevaras som HTTP/2-kompatibilitetslinje; det aktiva HTTP/2-kontraktet är dess efterföljare, RFC 9113.
  • RFC 7541 — HPACK: Headerkomprimering för HTTP/2. Webships egna HTTP/2-stack begränsar avkodarens tillstånd och kodarbord medan HPACKs trådbaserade format och Huffmankodning bevaras.
  • RFC 7838 — HTTP Alternativa Tjänster. Alt-Svc annonserar en HTTP/3-endpoint utan att ändra det ursprung som representeras av URL:en.
  • RFC 8441 — Bootstrapping WebSockets med HTTP/2. Webship stöder den nedströms förlängda-CONNECT-förhandlingsgrunden. Den påstår inte att en HTTP/1.1-uppström implementerar HTTP/2 förlängd CONNECT; icke-stödda uppströmskombinationer misslyckas uttryckligen.
  • RFC 8470 — Använda tidiga data i HTTP. Tidiga förfrågningar som Webship inte kommer att bearbeta får 425 Too Early istället för att hanteras med osäkra upprepningsantaganden.
  • RFC 8941 — Strukturerade fältvärden för HTTP. HTTP-prioritetsvärden använder parsing av strukturerade fältdictionary; felaktigt formaterade valfria fält ignoreras helt.
  • RFC 9110 — HTTP Semantik. Metoder, statuskoder, fält, validatorer, förutsättningar, omdirigeringar, innehållsmetadata, HEAD, CONNECT, OPTIONS och intervallets semantik delar ett gemensamt aktuellt kontrakt över protokollversioner.
  • RFC 9111 — HTTP Caching. Webship implementerar korrigerad ålder, explicit färskhet, Vary, only-if-cached, must-revalidate, proxy-revalidate, säker användning av föråldrad data och ogiltigförklaring av effektiva och relaterade URI:er.
  • RFC 9112 — HTTP/1.1. Regler för begäran-rad, fält, kroppslängd, överföringskodning, block, trailer, persistens och stängningsavgränsning tillämpas innan applikationsdistribuering.
  • RFC 9113 — HTTP/2. Pseudo-fältordning, auktoritet, förbjudna anslutningsfält, TE-begränsningar, ströms livscykel, flödeskontroll, GOAWAY och felscope hanteras av Webships ägda H2-väg.
  • RFC 9114 — HTTP/3. Webship äger begäran, styrström, SETTINGS, kritiskström, avbokning och ström-mot-anslutningsfelsvägar som används av dess HTTP/3-server.
  • RFC 9204 — QPACK: Fältkomprimering för HTTP/3. Den dynamiska tabellens kapacitet är begränsad av den annonserade gränsen, instruktionsströmmar förblir parsbara vid nollkapacitet, och ogiltigt tillstånd blir det obligatoriska QPACK-felet.
  • RFC 9218 — Extenderbart prioriteringsschema för HTTP. Brådskande och inkrementell leverans styr HTTP/3-schemaläggning medan okända prioritetsparametrar förblir utbyggbara.
  • RFC 9220 — Bootstrapping WebSockets med HTTP/3. Webship implementerar HTTP/3 extended-CONNECT SETTINGS-grunden som används av moderna tunnlade protokoll; det innebär inte att varje möjligt CONNECT-protokoll accepteras.
  • RFC 9297 — HTTP-datagram och kapselprotokoll. WebTransport-sessioner använder begränsad kapselavkodning och HTTP-datagramkoppling, där okända kapslar hanteras som utvidgningspunkter istället för parserfel.
  • RFC 9421 — HTTP-meddelandesignaturer. Valfri Ed25519-svarsproveniens kan täcka Webship-version och konfigurationsidentitet utan att ersätta TLS eller applikationsautentisering.
  • RFC 10008 — HTTP QUERY-metoden. Webship behandlar QUERY som säker och idempotent, bevarar dess kropp vid proxyning, inkluderar kropp och representationsmetadata i cache-identitet, förbjuder heuristisk färskhet, stöder villkorlig och intervallbaserad funktionalitet, och ogiltigförklarar aldrig en cache enbart för att QUERY användes.

QUIC-transport och överbelastningskontroll

TLS, certifikat och automatisk certifikathantering

WebTransport: exakt om vad som är standardiserat

WebTransport över HTTP/3 räknas inte som en femtionde tredje RFC. Från och med Webship 1.3.1 är dess trådkarta fortfarande draft-ietf-webtrans-http3-16. Webship implementerar det utkastet ovanpå det standardiserade HTTP/3, utökade CONNECT, QUIC DATAGRAM, HTTP Datagram och Capsule-lager som nämns ovan. Det implementerar också den förhandlade RESET_STREAM_AT-förlängningen som krävs för att bevara ett pålitligt sessionsidentifierande prefix när en WebTransport-ström återställs.

Den skillnaden är viktig. Kompatibilitet med standarder förbättras inte genom att kalla ett utkast för ett RFC. Den förbättras genom att spåra utkastet explicit, isolera det från vanliga HTTP-vägar, förhandla varje förlängning, begränsa varje sessionresurs och testa avboknings- och felbeteende.

Varför denna bredd är viktig i produktion

En standardbugg är sällan isolerad. Felaktig HSTS-hantering kan korsa en cachegräns. En felaktigt formaterad QPACK-instruktion kan avsluta orelaterade förfrågningar. Ett osäkert antagande om tidiga data kan upprepa en operation. En QUERY-cache-nyckel som utelämnar begärans kropp kan returnera resultatet av en annan fråga. En proxy som tar bort trailers eller hanterar avbokning felaktigt kan tyst ändra ett applikationsprotokoll.

Webships arkitektur behandlar dessa som sammanlänkade frågor. Parsergränser, säkerhetsinspektion, caching, omvänd proxy, transporttillstånd och instrumentering delar uttryckliga kontrakt. Resultatet är en server som kan växla mellan HTTP/1.1, HTTP/2, HTTP/3, statisk leverans, omvänd proxy, strömning och WebTransport utan att ge varje läge en annan definition av korrekthet.

Verifiera påståendet

Ta inte ett superlativ på förtroende. Läs [Webship 1.3.1-dokumentationen](/docs/1.3.1), granska konfigurationen och protokollgränserna, och reproducera det publicerade beteendet. Ladda sedan ner [Webship](/downloads) och testa de kantfall som är viktiga för ditt system.

Webship teknik

Streaming med Webship: Hög genomströmning utan att kompromissa med korrekthet

Lär dig hur Webship levererar och proxar stora mediefiler över HTTP/1.1, HTTP/2 och HTTP/3 med adaptiv kTLS, BBR-pacing, begränsade buffertar och nollfelsintegritetsgrindar.

Läs artikel

Din webbserver är ett infrastrukturkostnadsbeslut

Webship kombinerar höggenomströmningsleverans av Rust, moderna protokoll, inbyggt skydd, lokal observerbarhet och AI-native operationer i en körmiljö—vilket ger infrastrukturlag ett trovärdigt sätt till färre servrar och färre kantkomponenter.

Läs artikel

Webship 1.3.1: Högre HTTP/2 och omvänd proxykapacitet

Webship 1.3.1 ökar direkt h2c-kapacitet med 34,19 %, direkt HTTP/2 TLS med 26,67 % och reverse-proxy H1 med 15,10 % jämfört med 1.2.0, samtidigt som transportstabilitet och korrekthet förstärks.

Läs artikel