Zpět na Webship blog

Webship inženýrství

Webship: Nejvíce RFC-kompatibilní webový server na světě

Webship převádí požadavky RFC na explicitní chování napříč HTTP/1.1, HTTP/2, HTTP/3, QUIC, TLS, cachováním, reverzním proxy, WebTransport, ACME a novou metodou QUERY. Prozkoumejte kompletní mapu standardů 52 RFC.

Web je držen pohromadě přesnými dohodami. Pole Content-Length musí znamenat totéž na každém mezikroku. Cache nesmí znovu použít odpověď, která vyžaduje ověření. Nesprávně formátovaná sekce polí HTTP/3 musí selhat ve správném rozsahu. Bezpečná metoda musí zůstat bezpečná poté, co projde reverzní proxy.

Webship 1.3.1 je postaven na jednom pravidle: rychlost má význam jen tehdy, když bajty zachovávají svůj smysl.

To je důvod, proč popisujeme Webship jako nejvíce RFC-kompatibilní webový server obecného použití na světě. Toto je inženýrské tvrzení s viditelnou hranicí, nikoli tvrzení, že každá volitelná funkce ve všech RFC existuje. Níže uvedená mapa uvádí 52 RFC, které ovlivňují aktivní chování serveru Webship nebo jeho vlastněné protokolové základy. Nejprve jsou uvedeny aktuální standardy. Nahrazené dokumenty jsou identifikovány jako kompatibilní posloupnost. Návrhové specifikace nejsou přejmenovávány na RFC.

Kompatibilita je chování, ne odznak

Webship uplatňuje standardy na místech, kde se produkční servery nejčastěji stávají nejednoznačnými:

  • Rámování HTTP/1.1 odmítá konfliktní délky, neplatné přenosové kódování, nadměrně velké cíle požadavků, nesprávně formátované bloky a tvary požadavků umožňující pašování požadavků.
  • HTTP/2 a HTTP/3 odmítají zakázaná pole spojení, ověřují pseudo-pole, omezují části komprimovaných polí a udržují chyby toku oddělené od chyb spojení.
  • Statické soubory zachovávají sémantiku HEAD, validátory, pořadí předpokladů, rozsahy bajtů, přesměrování a typy obsahu.
  • Reverzní proxy zachovává rámcování, rušení, závěry, upgrady, bezpečné opakování a přeposílání identity při odstraňování polí typu hop-by-hop.
  • Cache vypočítává pravidla pro věk, čerstvost, znovuověření, Vary, neplatnost a použití zastaralých dat, místo aby zacházela s cache jako s klíč-hodnota zkratkou.
  • TLS, QUIC, ACME, raná data a WebTransport používají omezený stav a explicitní politiku selhání.

Stejná pravidla platí i na rychlé cestě. Webship nedefinuje jednu „správnou“ cestu a jinou referenční cestu.

HTTP sémantika, rámování, ukládání do mezipaměti a proxy

  • RFC 3986 — Jednotný identifikátor zdrojů (URI): Obecná syntaxe. Webship normalizuje relativní odkazy Location a Content-Location, včetně segmentů s tečkami, před rozhodnutími o neplatnosti cache.
  • RFC 6455 — Protokol WebSocket. Upgrady na reverzní proxy ověřují klíč WebSocket, hodnotu 'accept', podprotokol, rozšíření a přechod tunelu.
  • RFC 6585 — Další kódy stavů HTTP. Překročení velikosti polí požadavku používá definovanou odpověď 431, pokud je stále možná HTTP odpověď.
  • RFC 6797 — HTTP Strict Transport Security. Strict-Transport-Security je odesílán pouze přes zabezpečený přenos a nikdy nezprostředkuje únik ze záznamu v mezipaměti nezávislé na přenosu na nešifrované HTTP.
  • RFC 7235 — HTTP/1.1 Autentizace. Toky autentizačního schématu jsou parsovány bez ohledu na velikost písmen, včetně chráněného řídicího povrchu MCP. Jeho obecná semantika HTTP nyní existuje v RFC 9110.
  • RFC 7239 — Rozšíření HTTP Forwarded. Provozovatelé mohou vybrat standardní pole Forwarded, starší pole X-Forwarded, obě, nebo žádné; nedůvěryhodná příchozí identifikační pole jsou nejprve odstraněna.
  • RFC 7540 — HTTP/2. Toto je zachováno jako kompatibilní linie HTTP/2; aktivní smlouva HTTP/2 je její nástupce, RFC 9113.
  • RFC 7541 — HPACK: Komprese hlaviček pro HTTP/2. HTTP/2 stack vlastněný Webship ohraničuje stav dekodéru a tabulky kodéru při zachování formátu drátového přenosu HPACK a Huffmanova kódování.
  • RFC 7838 — HTTP alternativní služby. Alt-Svc inzeruje koncový bod HTTP/3, aniž by měnil původ reprezentovaný URL.
  • RFC 8441 — Inicializace WebSockets přes HTTP/2. Webship podporuje downstream rozšířenou základnu vyjednávání CONNECT. Nepředstírá, že upstream HTTP/1.1 implementuje rozšířený CONNECT HTTP/2; nepodporované kombinace upstream selhávají explicitně.
  • RFC 8470 — Používání raných dat v HTTP. Rané požadavky, které Webship nebude zpracovávat, obdrží místo zpracování s nebezpečnými předpoklady opakování odpověď 425 Too Early.
  • RFC 8941 — Strukturované hodnoty polí pro HTTP. Prioritní hodnoty HTTP používají analýzu slovníku strukturovaného pole; nesprávně vytvořená volitelná pole jsou ignorována jako celek.
  • RFC 9110 — HTTP sémantika. Metody, stavové kódy, pole, validátory, předpoklady, přesměrování, metadata obsahu, HEAD, CONNECT, OPTIONS a sémantika rozsahu sdílejí jednu aktuální smlouvu napříč verzemi protokolu.
  • RFC 9111 — HTTP Caching. Webship implementuje opravený věk, explicitní čerstvost, Vary, only-if-cached, must-revalidate, proxy-revalidate, bezpečné použití zastaralých dat a neplatnění efektivních a souvisejících URI.
  • RFC 9112 — HTTP/1.1. Pravidla pro řádek požadavku, pole, délku těla, způsob přenosu, blok, závěs, trvanlivost a uzavření jsou uplatňována před odesláním do aplikace.
  • RFC 9113 — HTTP/2. Pseudo-pole order, autorita, zakázaná pole spojení, omezení TE, životní cyklus streamu, řízení toku, GOAWAY a rozsah chyb jsou zpracovávány H2 cestou vlastněnou Webshipem.
  • RFC 9114 — HTTP/3. Webship vlastní žádosti, řídicí proud, SETTINGS, kritický proud, zrušení a chyby proud-versus-připojení používané jeho serverem HTTP/3.
  • RFC 9204 — QPACK: Komprese polí pro HTTP/3. Kapacita dynamické tabulky je omezena deklarovaným limitem, toky instrukcí zůstávají parsovatelné při nulové kapacitě a neplatný stav se stává požadovanou chybou QPACK.
  • RFC 9218 — Rozšiřitelný schémat priorizace pro HTTP. Naléhavost a průběžné doručování řídí plánování HTTP/3, zatímco neznámé parametry priority zůstávají rozšiřitelné.
  • RFC 9220 — Inicializace WebSockets pomocí HTTP/3. Webship implementuje základy HTTP/3 extended-CONNECT SETTINGS používané moderními tunelovými protokoly; to neznamená, že je akceptován každý možný CONNECT protokol.
  • RFC 9297 — HTTP datagramy a kapsulový protokol. Relace WebTransport používají omezené dekódování kapslí a asociaci HTTP datagramů, přičemž neznámé kapsle jsou zpracovávány jako rozšiřující body místo selhání parseru.
  • RFC 9421 — HTTP podpisy zpráv. Volitelná původnost odpovědi Ed25519 může pokrývat identitu vydání a konfigurace Webship bez nahrazení TLS nebo autentizace aplikace.
  • RFC 10008 — Metoda HTTP QUERY. Webship považuje QUERY za bezpečnou a idempotentní, zachovává její tělo při proxyování, zahrnuje metadata těla a reprezentace do identity mezipaměti, zakazuje heuristickou čerstvost, podporuje podmíněné a rozsahové chování a nikdy neanuluje mezipaměť jen proto, že byla použita QUERY.

QUIC transport a řízení zahlcení

TLS, certifikáty a automatická správa certifikátů

WebTransport: přesné ohledně toho, co je standardizováno

WebTransport přes HTTP/3 se nepočítá jako pětapadesátý třetí RFC. Od verze Webship 1.3.1 zůstává jeho přenosové mapování ve stavu draft-ietf-webtrans-http3-16. Webship implementuje tento návrh nad standardizovaným HTTP/3, rozšířeným CONNECT, QUIC DATAGRAM, HTTP Datagram a výše uvedenými vrstvami Capsule. Implementuje také dohodnuté rozšíření RESET_STREAM_AT potřebné k zachování spolehlivého prefixu identifikujícího relaci při resetování toku WebTransport.

Tento rozdíl má význam. Kompatibilita standardů se nezlepšuje tím, že se návrh nazve RFC. Zlepšuje se tím, že se návrh explicitně sleduje, izoluje od běžných HTTP cest, sjednává každé rozšíření, omezuje každý zdroj relace a testuje chování při zrušení a selhání.

Proč je tato šíře důležitá ve výrobě

Chyba ve standardu je zřídka izolovaná. Nesprávné zacházení s HSTS může překročit hranici cache. Špatně vytvořený příkaz QPACK může ukončit nesouvisející požadavky. Nezabezpečené předpokládání raných dat může zopakovat operaci. Klíč cache QUERY, který vynechává tělo požadavku, může vrátit výsledek jiné dotazu. Proxy, která odstraňuje závěsy nebo nesprávně zachází se zrušením, může tiše změnit aplikační protokol.

Architektura Webshipu považuje tyto záležitosti za propojené. Limity parseru, kontrola bezpečnosti, ukládání do mezipaměti, reverzní proxy, stav přenosu a instrumentace sdílejí explicitní smlouvy. Výsledkem je jeden server, který se může pohybovat mezi HTTP/1.1, HTTP/2, HTTP/3, statickým doručováním, reverzní proxy, streamováním a WebTransportem, aniž by každému režimu dával odlišnou definici správnosti.

Ověřte tvrzení

Nepřijímejte superlativ na důvěru. Přečtěte si [dokumentaci Webship 1.3.1](/docs/1.3.1), prozkoumejte konfiguraci a hranice protokolu a reprodukujte zveřejněné chování. Poté [stáhněte Webship](/downloads) a otestujte hraniční případy, které jsou důležité pro váš systém.

Webship inženýrství

Streamování s Webship: Vysoká propustnost bez kompromisů na správnosti

Naučte se, jak Webship poskytuje a zprostředkovává velké mediální soubory přes HTTP/1.1, HTTP/2 a HTTP/3 pomocí adaptivního kTLS, BBR řízení rychlosti, omezených bufferů a bran integrity bez chyb.

Přečíst článek

Váš webový server je rozhodnutí o nákladech na infrastrukturu

Webship kombinuje vysokopropustnou dodávku Rust, moderní protokoly, vestavěnou ochranu, lokální pozorovatelnost a nativní AI operace v jednom runtime—poskytující infrastrukturním týmům věrohodnou cestu k menšímu počtu serverů a okrajových komponent.

Přečíst článek

Webship 1.3.1: Vyšší HTTP/2 a kapacita reverzní proxy

Webship 1.3.1 zvyšuje přímou kapacitu h2c o 34,19 %, přímou kapacitu HTTP/2 TLS o 26,67 % a H1 reverzního proxy o 15,10 % ve srovnání s verzí 1.2.0, přičemž posiluje stabilitu a správnost přenosu.

Přečíst článek