Înapoi la blogul Webship

Inginerie Webship

Webship: Cel mai compatibil cu RFC dintre serverele web din lume

Webship transformă cerințele RFC în comportamente explicite pentru HTTP/1.1, HTTP/2, HTTP/3, QUIC, TLS, caching, proxy invers, WebTransport, ACME și noua metodă QUERY. Explorează harta completă a standardelor de 52 RFC.

Web-ul este ținut împreună prin acorduri exacte. Un câmp Content-Length trebuie să însemne același lucru la fiecare nod. Un cache nu trebuie să reutilizeze un răspuns care necesită validare. O secțiune de câmp HTTP/3 formatată incorect trebuie să eșueze la domeniul corect. O metodă sigură trebuie să rămână sigură după ce trece printr-un proxy invers.

Webship 1.3.1 este construit în jurul unei reguli: viteza contează doar atunci când biții își păstrează înțelesul.

De aceea descriem Webship ca fiind cel mai compatibil server web general cu RFC-urile din lume. Aceasta este o afirmație inginerească cu o limită vizibilă, nu o afirmație că fiecare funcție opțională din fiecare RFC există. Harta de mai jos menționează cele 52 de RFC-uri care afectează comportamentul activ al serverului Webship sau fundațiile protocolului său propriu. Standardele actuale apar primele. Documentele înlocuite sunt identificate ca linie de compatibilitate. Specificațiile în proiect nu sunt redenumite ca RFC-uri.

Compatibilitatea este comportament, nu un badge

Webship aplică standarde în locurile unde serverele de producție devin cel mai des ambigue:

  • Încadrarea HTTP/1.1 respinge lungimile conflictuale, codificările de transfer invalide, țintele cererii supradimensionate, bucățile de date incorect formate și formele de contrabandă a cererilor.
  • HTTP/2 și HTTP/3 resping câmpurile de conexiune interzise, validează pseudo-câmpurile, limitează secțiunile de câmp comprimat și păstrează erorile de flux separate de erorile de conexiune.
  • Fișierele statice păstrează semantica HEAD, validatoarele, ordinea condițiilor prealabile, intervalele de octeți, redirecționările și tipurile de conținut.
  • Proxy-ul invers păstrează încapsularea, anularea, antetele suplimentare, actualizările, reîncercările sigure și identificarea direcționării, în timp ce elimină câmpurile hop-by-hop.
  • Cache-ul calculează reguli privind vârsta, prospețimea, revalidarea, Vary, invalidarea și utilizarea expirată, în loc să trateze cache-ul ca un simplu shortcut cheie-valoare.
  • TLS, QUIC, ACME, date timpurii și WebTransport folosesc stare limitată și politică explicită de eșec.

Aceleași reguli se aplică pe calea rapidă. Webship nu definește o cale „corectă” și o cale de referință diferită.

Semantica HTTP, structurare, caching și proxy

  • RFC 3986 — Identificator Uniform de Resurse (URI): Sintaxă Generică. Webship normalizează referințele relative Location și Content-Location, inclusiv segmentele punct, înainte de deciziile privind invalidarea cache-ului.
  • RFC 6455 — Protocolul WebSocket. Upgrade-urile reverse-proxy validează cheia WebSocket, valoarea acceptată, subprotocolul, extensiile și trecerea tunelului.
  • RFC 6585 — Coduri de stare HTTP suplimentare. Câmpurile de cerere supradimensionate folosesc răspunsul definit 431 atunci când un răspuns HTTP este încă posibil.
  • RFC 6797 — HTTP Strict Transport Security. Strict-Transport-Security este emis doar printr-un transport sigur și nu se scurge niciodată dintr-o intrare de cache neutră față de transport pe HTTP clar.
  • RFC 7235 — Autentificarea HTTP/1.1. Tokenurile schemelor de autentificare sunt analizate fără a ține cont de majuscule, inclusiv suprafața de control protejată MCP. Semantica generală HTTP trăiește acum în RFC 9110.
  • RFC 7239 — Extensie HTTP Forwarded. Operatorii pot selecta un câmp Forwarded bazat pe standarde, câmpuri X-Forwarded vechi, ambele sau niciunul; câmpurile de identitate inbound neîncredere sunt eliminate mai întâi.
  • RFC 7540 — HTTP/2. Acesta este păstrat ca linie de compatibilitate HTTP/2; contractul activ HTTP/2 este succesorul său, RFC 9113.
  • RFC 7541 — HPACK: Compresia antetelor pentru HTTP/2. Stiva HTTP/2 deținută de Webship leagă starea decodorului și tabelele codificatorului, păstrând în același timp formatul de transmisie HPACK și codarea Huffman.
  • RFC 7838 — Servicii Alternative HTTP. Alt-Svc promovează un punct final HTTP/3 fără a schimba originea reprezentată de URL.
  • RFC 8441 — Inițializarea WebSockets cu HTTP/2. Webship suportă baza de negociere extended-CONNECT pentru downstream. Nu pretinde că un upstream HTTP/1.1 implementează HTTP/2 extended CONNECT; combinațiile de upstream neacceptate eșuează în mod explicit.
  • RFC 8470 — Utilizarea Datelor Timpurii în HTTP. Solicitarile timpurii pe care Webship nu le va procesa primesc 425 Prea Timpuriu în loc să fie tratate cu presupuneri nesigure de redare.
  • RFC 8941 — Valori de câmp structurate pentru HTTP. Valorile de prioritate HTTP folosesc analizarea dicționarului câmpurilor structurate; câmpurile opționale incorect formate sunt ignorate în întregime.
  • RFC 9110 — Semantica HTTP. Metodele, codurile de stare, câmpurile, validatoarele, condițiile prealabile, redirecționările, metadatele conținutului, HEAD, CONNECT, OPTIONS și semantica intervalelor împărtășesc un singur contract curent între versiunile protocolului.
  • RFC 9111 — Cache-ul HTTP. Webship implementează vârsta corectată, valabilitatea explicită, Vary, only-if-cached, must-revalidate, proxy-revalidate, utilizarea sigură a stale și invalidarea URI-urilor efective și asociate.
  • RFC 9112 — HTTP/1.1. Regulile privind linia de cerere, câmpul, lungimea corpului, codarea transferului, segmentul, antetul final, persistența și delimitarea prin închidere sunt aplicate înainte de trimiterea către aplicație.
  • RFC 9113 — HTTP/2. Ordinea pseudo-câmpurilor, autoritatea, câmpurile de conexiune interzise, restricțiile TE, ciclul de viață al fluxului, controlul fluxului, GOAWAY și domeniul de eroare sunt gestionate de calea H2 deținută de Webship.
  • RFC 9114 — HTTP/3. Webship deține căile de eroare pentru request, control-stream, SETTINGS, critical-stream, anulare și stream-versus-connection utilizate de serverul său HTTP/3.
  • RFC 9204 — QPACK: Compresia câmpurilor pentru HTTP/3. Capacitatea tabelei dinamice este limitată de limita declarată, fluxurile de instrucțiuni rămân analizabile la capacitate zero, iar starea nevalidă devine eroarea QPACK necesară.
  • RFC 9218 — Schema de prioritizare extensibilă pentru HTTP. Urgența și livrarea incrementală ghidează planificarea HTTP/3 în timp ce parametrii de prioritate necunoscuți rămân extensibili.
  • RFC 9220 — Inițializarea WebSockets cu HTTP/3. Webship implementează baza SETTINGS extins-CONNECT HTTP/3 utilizată de protocoalele tunelate moderne; aceasta nu implică faptul că orice protocol CONNECT posibil este acceptat.
  • RFC 9297 — Datagramelor HTTP și Protocolul Capsulei. Sesiunile WebTransport utilizează decodarea capsulelor limitate și asocierea Datagramelor HTTP, capsulele necunoscute fiind tratate ca puncte de extensie în loc de eșecuri ale parserului.
  • RFC 9421 — Semnături de Mesaje HTTP. Proveniența opțională a răspunsului Ed25519 poate acoperi identitatea release-ului și a configurației Webship fără a înlocui TLS sau autentificarea aplicației.
  • RFC 10008 — Metoda QUERY HTTP. Webship tratează QUERY ca fiind sigură și idempotentă, păstrează corpul acesteia prin proxy, include corpul și metadatele reprezentării în identitatea cache-ului, interzice prospețimea euristică, suportă comportamentul condițional și de interval și niciodată nu invalidează un cache doar pentru că a fost folosit QUERY.

Transportul QUIC și controlul congestiei

TLS, certificate și gestionarea automată a certificatelor

WebTransport: precis despre ceea ce este standardizat

WebTransport peste HTTP/3 nu este considerat ca fiind un RFC cu numărul cincizeci și trei. Începând cu Webship 1.3.1, mapa sa de transmisie rămâne draft-ietf-webtrans-http3-16. Webship implementează acel draft deasupra HTTP/3 standardizat, CONNECT extins, QUIC DATAGRAM, Datagram HTTP și straturile Capsule menționate mai sus. De asemenea, implementează extensia negociată RESET_STREAM_AT necesară pentru a păstra un prefix de identificare a sesiunii fiabil atunci când un flux WebTransport este resetat.

Acea distincție contează. Compatibilitatea standardelor nu se îmbunătățește prin numirea unui draft ca RFC. Se îmbunătățește prin urmărirea explicită a draftului, izolarea acestuia de căile HTTP obișnuite, negocierea fiecărei extensii, limitarea fiecărui resursă de sesiune și testarea comportamentului la anulare și eșec.

De ce contează această amploare în producție

Un bug de standard este rar izolat. Gestionarea incorectă a HSTS poate traversa o limită de cache. O instrucțiune QPACK incorectă poate termina cereri nelegate. O presupunere nesigură despre datele timpurii poate repeta o operațiune. O cheie de cache QUERY care omit corpul cererii poate returna rezultatul unei alte interogări. Un proxy care elimină trailerele sau gestionează greșit anularea poate schimba silențios un protocol de aplicație.

Arhitectura Webship tratează aceste aspecte ca preocupări interconectate. Limitele parser-ului, inspectarea securității, caching-ul, proxy-ul invers, starea transportului și instrumentarea împărtășesc contracte explicite. Rezultatul este un singur server care poate trece între HTTP/1.1, HTTP/2, HTTP/3, livrare statică, proxy invers, streaming și WebTransport fără a oferi fiecărui mod o definiție diferită a corectitudinii.

Verificați afirmația

Nu accepta un superlativ pe cuvânt. Citește [documentația Webship 1.3.1](/docs/1.3.1), inspectează configurația și limitele protocolului și reproduce comportamentul publicat. Apoi [descarcă Webship](/downloads) și testează cazurile-limită care contează pentru sistemul tău.

Inginerie Webship

Streaming cu Webship: Debit ridicat fără a sacrifica corectitudinea

Aflați cum Webship servește și preia fișiere media mari prin HTTP/1.1, HTTP/2 și HTTP/3 folosind kTLS adaptiv, reglarea BBR, buffer-uri limitate și porți de integritate fără erori.

Citește articolul

Serverul tău web este o decizie de cost pentru infrastructură

Webship combină livrarea Rust cu debit mare, protocoale moderne, protecție încorporată, observabilitate locală și operațiuni native AI într-un singur runtime—oferind echipelor de infrastructură un drum credibil către mai puține servere și mai puține componente la margine.

Citește articolul

Webship 1.3.1: Capacitate HTTP/2 mai mare și de Reverse-Proxy

Webship 1.3.1 mărește capacitatea directă h2c cu 34,19%, TLS direct HTTP/2 cu 26,67% și H1 prin reverse-proxy cu 15,10% comparativ cu 1.2.0, în timp ce consolidează stabilitatea și corectitudinea transportului.

Citește articolul