Vissza a Webship bloghoz

Webship mérnöki munka

Webship: A világ legRFC-kompatibilisebb webszervere

A Webship az RFC követelményeket explicitté teszi a HTTP/1.1, HTTP/2, HTTP/3, QUIC, TLS, gyorsítótárazás, visszafelé proxyzás, WebTransport, ACME és az új QUERY módszer esetében. Fedezze fel a teljes 52-RFC szabványtérképet.

A web pontos megállapodásokra épül. A Content-Length mezőnek minden csomóponton ugyanazt kell jelentenie. A gyorsítótár nem használhat újra egy olyan választ, amely érvényesítést igényel. A hibás HTTP/3 mezőszakasznak a megfelelő hatókörben kell hibát jeleznie. Egy biztonságos módszernek biztonságosnak kell maradnia még akkor is, ha egy fordított proxy-n halad át.

A Webship 1.3.1 egy szabályra épül: a sebesség csak akkor számít, ha a bájtok megőrzik jelentésüket.

Ezért írjuk le a Webshipet a világ leginkább RFC-kompatibilis, általános célú webszervereként. Ez egy mérnöki állítás, amelynek látható határai vannak, és nem azt állítja, hogy minden opcionális funkció minden RFC-ben megtalálható. Az alábbi térkép azokat a 52 RFC-t nevezi meg, amelyek befolyásolják a Webship aktív szerver működését vagy a hozzá tartozó protokollalapokat. A jelenlegi szabványok szerepelnek először. A felváltott dokumentumokat kompatibilitási vonalként azonosítják. A tervezet specifikációkat nem címkézik át RFC-ként.

A kompatibilitás viselkedés, nem kitűző

A Webship szabványokat alkalmaz azokon a helyeken, ahol a termelőszerverek leggyakrabban félreérthetővé válnak:

  • A HTTP/1.1 keretezés elutasítja az ellentmondásos hosszúságokat, érvénytelen átvitelkódolásokat, túlméretezett kéréscélokat, hibás darabokat és a kérés-csempészés alakzatokat.
  • A HTTP/2 és a HTTP/3 elutasítja a tiltott kapcsolati mezőket, érvényesíti a pseudo-mezőket, korlátozza a tömörített mezőszakaszokat, és a stream hibákat elkülöníti a kapcsolati hibáktól.
  • A statikus fájlok megőrzik a HEAD szemantikát, az érvényesítőket, az előfeltétel sorrendjét, a bájttartományokat, az átirányításokat és a tartalomtípusokat.
  • A visszafelé irányuló proxy megőrzi a keretezést, a megszakítást, a mellékleteket, a frissítéseket, a biztonságos újrapróbálkozásokat és az továbbítási azonosítót, miközben eltávolítja a hop-by-hop mezőket.
  • A gyorsítótár az életkort, frissességet, újbóli ellenőrzést, Vary-t, érvénytelenítést és a régiségi használati szabályokat számítja ki, ahelyett, hogy a gyorsítást kulcs-érték rövidútként kezeli.
  • A TLS, QUIC, ACME, korai adatok és WebTransport korlátozott állapotot és explicite hibakezelési szabályt használnak.

Ugyanazok a szabályok érvényesek a gyors úton. A Webship nem határoz meg egy „helyes” utat és egy külön benchmark utat.

HTTP szemantika, keretezés, gyorsítótárazás és proxyzás

  • RFC 3986 — Egységes erőforrás-azonosító (URI): Általános szintaxis. A Webship normalizálja a relatív Location és Content-Location hivatkozásokat, beleértve a pontszegmenseket is, a gyorsítótár érvénytelenítési döntései előtt.
  • RFC 6455 — A WebSocket protokoll. A reverse-proxy frissítések érvényesítik a WebSocket kulcsot, az elfogadott értéket, az alprotokollt, a bővítményeket és az alagút átmenetet.
  • RFC 6585 — További HTTP státuszkódok. A túlméretezett kérésmezők a 431-es válaszkódot használják, ha még lehetséges HTTP-választ adni.
  • RFC 6797 — HTTP Strict Transport Security. A Strict-Transport-Security csak biztonságos átvitel esetén kerül kibocsátásra, és soha nem szivárog át egy átvitel-semleges gyorsítótár-bejegyzésből a tiszta HTTP-re.
  • RFC 7235 — HTTP/1.1 hitelesítés. A hitelesítési séma tokenjeit kis- és nagybetűtől függetlenül értelmezik, beleértve a védett MCP vezérlőfelületet is. Általános HTTP szemantikája most az RFC 9110-ban található.
  • RFC 7239 — Továbbított HTTP kiterjesztés. Az üzemeltetők választhatnak egy szabványos alapú Forwarded mezőt, régi X-Forwarded mezőket, mindkettőt vagy egyiket sem; a nem megbízható bejövő azonosító mezőket először eltávolítják.
  • RFC 7540 — HTTP/2. Ezt az HTTP/2 kompatibilitási leszármazásaként tartják meg; az aktív HTTP/2 szerződés a következője, az RFC 9113.
  • RFC 7541 — HPACK: HTTP/2 fejléc tömörítés. A Webship saját HTTP/2 verem a dekóder állapotát és az enkóder táblákat korlátozza, miközben megőrzi az HPACK vezetékformátumot és a Huffman kódolást.
  • RFC 7838 — HTTP alternatív szolgáltatások. Az Alt-Svc egy HTTP/3 végpontot hirdet anélkül, hogy megváltoztatná a URL által képviselt eredetet.
  • RFC 8441 — WebSocket-ek inicializálása HTTP/2-vel. A Webship támogatja a lefelé irányuló extended-CONNECT tárgyalási alapot. Nem állítja azt, hogy egy HTTP/1.1-es upstream HTTP/2 extended CONNECT-et valósít meg; a nem támogatott upstream kombinációk kifejezetten hibát jeleznek.
  • RFC 8470 — Korai adatok használata a HTTP-ben. Azok a korai kérések, amelyeket a Webship nem dolgoz fel, 425 Too Early választ kapnak ahelyett, hogy nem biztonságos újrajátszási feltételezésekkel kezelnék őket.
  • RFC 8941 — Struktúrált mezőértékek a HTTP-hez. A HTTP prioritásértékek struktúrált mező-szótár elemzést használnak; a hibás opcionális mezőket egészében figyelmen kívül hagyják.
  • RFC 9110 — HTTP szemantika. A metódusok, állapotkódok, mezők, ellenőrzők, előfeltételek, átirányítások, tartalom metaadatok, HEAD, CONNECT, OPTIONS és tartomány szemantikák egy közös aktuális megállapodást osztanak meg a protokoll verziói között.
  • RFC 9111 — HTTP gyorsítótárazás. A Webship megvalósítja a korrigált életkort, az explicit frissességet, a Vary-t, az only-if-cached-et, a must-revalidate-et, a proxy-revalidate-et, a biztonságos elavult használatot, valamint az érvényes és kapcsolódó URI-k érvénytelenítését.
  • RFC 9112 — HTTP/1.1. A kérés-sor, mező, törzs-hossz, átvitel-kódolás, darab, záró rész, tartósság és lezárással határolt szabályok érvényesítve vannak az alkalmazás továbbítása előtt.
  • RFC 9113 — HTTP/2. A pseudo-mezők sorrendje, a hitelesség, a tiltott kapcsolati mezők, a TE-korlátozások, a stream életciklusa, a forgalomszabályozás, a GOAWAY és a hibakör a Webship tulajdonában lévő H2 útvonal által van kezelve.
  • RFC 9114 — HTTP/3. A Webship birtokolja a HTTP/3 szervere által használt kérés-, vezérlőfolyam-, BEÁLLÍTÁSOK-, kritikusfolyam-, törlés- és folyamon belüli kapcsolat hibákat.
  • RFC 9204 — QPACK: Mezőtömörítés HTTP/3-hoz. A dinamikus tábla kapacitása a hirdetett korláttal van megszorítva, az utasításáramok nulla kapacitásnál is értelmezhetők maradnak, és a érvénytelen állapot a szükséges QPACK hibává válik.
  • RFC 9218 — Kiterjeszthető prioritási séma a HTTP számára. A sürgősség és a fokozatos kézbesítés útmutatást ad a HTTP/3 ütemezéséhez, miközben az ismeretlen prioritási paraméterek továbbra is kiterjeszthetők maradnak.
  • RFC 9220 — WebSocketok indítása HTTP/3-mal. A Webship megvalósítja a modern alagútprotokollok által használt HTTP/3 kibővített-CONNECT SETTINGS alapot; ez nem jelenti azt, hogy minden lehetséges CONNECT protokoll elfogadott.
  • RFC 9297 — HTTP Datagramok és a Capsule protokoll. A WebTransport munkamenetek korlátos kapszula dekódolást és HTTP Datagram összekapcsolást használnak, az ismeretlen kapszulák kiterjesztési pontként kezelve ahelyett, hogy elemzési hibát okoznának.
  • RFC 9421 — HTTP üzenet aláírások. Az opcionális Ed25519 válaszeredetiség lefedheti a Webship kiadását és a konfiguráció azonosságát anélkül, hogy helyettesítené a TLS-t vagy az alkalmazás-hitelesítést.
  • RFC 10008 — A HTTP QUERY metódus. A Webship a QUERY-t biztonságosnak és idempotensnek tekinti, megőrzi a törzsét a proxyzáson keresztül, a törzs- és reprezentációs metaadatokat a cache identitásába foglalja, tiltja a heurisztikus frissességet, támogatja a feltételes és tartományviselkedést, és soha nem érvénytelenít egy cache-t pusztán azért, mert QUERY-t használtak.

QUIC szállítás és torlódásvezérlés

TLS, tanúsítványok és automatikus tanúsítványkezelés

WebTransport: pontos arról, hogy mi van szabványosítva

A WebTransport HTTP/3 felett nem számít a 53. RFC-nek. A Webship 1.3.1-es verziójától kezdve a vezetékes leképezése a draft-ietf-webtrans-http3-16 marad. A Webship az említett draftot az alább felsorolt, szabványosított HTTP/3, kiterjesztett CONNECT, QUIC DATAGRAM, HTTP Datagram és Capsule rétegek tetejére valósítja meg. Emellett megvalósítja a tárgyalás tárgyát képező RESET_STREAM_AT kiterjesztést is, amely szükséges ahhoz, hogy a WebTransport stream visszaállításakor megmaradjon a megbízható, munkamenetet azonosító prefix.

Ez a megkülönböztetés számít. A szabványokkal való kompatibilitás nem javul attól, hogy egy tervezetet RFC-nek nevezünk. Javul azáltal, hogy a tervezetet kifejezetten nyomon követjük, elkülönítjük a szokásos HTTP-útvonalaktól, minden kiterjesztést megállapodunk, minden munkamenet-erőforrást korlátozunk, és teszteljük a megszakítási és hibajelenségeket.

Miért fontos ez a szélesség a gyártásban

Egy szabványhibát ritkán tapasztalunk izoláltan. A helytelen HSTS-kezelés átlépheti a gyorsítótár határát. Egy hibás QPACK utasítás megszakíthat független kéréseket. Egy veszélyes korai adat feltételezés újrajátszhat egy műveletet. Egy QUERY gyorsítótár kulcs, amely kihagyja a kérés törzsét, egy másik lekérdezés eredményét adhatja vissza. Egy proxy, amely eltávolítja a trailer-eket vagy hibásan kezeli a megszakítást, csendben megváltoztathat egy alkalmazás protokollt.

A Webship architektúrája ezeket összekapcsolt kérdéskörökként kezeli. A parser korlátai, a biztonsági ellenőrzés, a gyorsítótárazás, a visszafordító proxyzás, a szállítási állapot és az instrumentáció explicit szerződéseket osztanak meg. Az eredmény egy olyan szerver, amely képes váltani a HTTP/1.1, HTTP/2, HTTP/3, statikus kiszolgálás, visszafordító proxyzás, streaming és WebTransport között anélkül, hogy minden üzemmódnak külön meghatározást kellene adnia a helyességről.

Ellenőrizze az állítást

Ne fogadj el egy felsőfokot bizalom alapján. Olvasd el a [Webship 1.3.1 dokumentációját](/docs/1.3.1), vizsgáld meg a konfigurációt és a protokollhatárokat, és reprodukáld a közzétett viselkedést. Ezután [töltsd le a Webshipet](/downloads), és teszteld azokat a szélsőséges eseteket, amelyek számítanak a rendszered számára.

Webship mérnöki munka

Streaming Webship-val: Magas átbocsátóképesség anélkül, hogy feladnánk a helyességet

Ismerje meg, hogyan szolgálja ki és közvetíti a Webship a nagy médiafájlokat HTTP/1.1, HTTP/2 és HTTP/3 felé adaptív kTLS, BBR ütemezés, korlátozott pufferelés és nulla hibás integritási kapuk használatával.

Cikk olvasása

A web szervered egy infrastruktúra-költség döntés

Webship ötvözi a nagy áteresztőképességű Rust szállítást, a modern protokollokat, a beépített védelmet, a helyi megfigyelhetőséget és az AI-hoz natív működést egyetlen futtatókörnyezetben – hiteles utat kínálva az infrastruktúra csapatok számára kevesebb szerverhez és kevesebb élkomponenshez.

Cikk olvasása

Webship 1.3.1: Magasabb HTTP/2 és Visszafordító proxy kapacitás

Webship 1.3.1 34,19%-kal növeli a közvetlen h2c kapacitást, 26,67%-kal a közvetlen HTTP/2 TLS-t, és 15,10%-kal a reverse-proxy H1-et az 1.2.0-hoz képest, miközben erősíti a transzport stabilitását és helyességét.

Cikk olvasása