Powrót do bloga Webship

Webship inżynieria

Webship: Najbardziej zgodny z RFC serwer internetowy na świecie

Webship przekształca wymagania RFC w wyraźne zachowania w całym HTTP/1.1, HTTP/2, HTTP/3, QUIC, TLS, buforowaniu, reverse proxy, WebTransport, ACME oraz nowej metodzie QUERY. Odkryj kompletną mapę standardów obejmującą 52 RFC.

Sieć opiera się na dokładnych porozumieniach. Pole Content-Length musi oznaczać to samo na każdym przeskoku. Pamięć podręczna nie może ponownie używać odpowiedzi, która wymaga walidacji. Błędnie sformatowana sekcja pola HTTP/3 musi zawieść w odpowiednim zakresie. Metoda bezpieczna musi pozostać bezpieczna po przejściu przez serwer proxy wstecznego.

Webship 1.3.1 opiera się na jednej zasadzie: szybkość ma znaczenie tylko wtedy, gdy bajty zachowują swoje znaczenie.

Dlatego opisujemy Webship jako najbardziej zgodny z RFC ogólnego przeznaczenia serwer internetowy na świecie. Jest to twierdzenie inżynierskie z wyraźnymi granicami, a nie stwierdzenie, że każda opcjonalna funkcja we wszystkich RFC istnieje. Poniższa mapa wskazuje 52 RFC, które mają wpływ na aktywne zachowanie serwera Webship lub jego własne podstawy protokołowe. Obecne standardy są wymienione jako pierwsze. Zastąpione dokumenty są oznaczone jako linia zgodności. Wstępne specyfikacje nie są ponownie oznaczane jako RFC.

Kompatybilność to zachowanie, nie odznaka

Webship stosuje standardy w miejscach, w których serwery produkcyjne najczęściej stają się niejednoznaczne:

  • Ramkowanie HTTP/1.1 odrzuca sprzeczne długości, nieprawidłowe kodowania transferu, nadmiernie duże cele żądań, niepoprawnie sformatowane fragmenty oraz kształty wstrzykiwania żądań.
  • HTTP/2 i HTTP/3 odrzucają zabronione pola połączenia, weryfikują pola pseudo, ograniczają skompresowane sekcje pól i utrzymują błędy strumienia oddzielnie od błędów połączenia.
  • Pliki statyczne zachowują semantykę HEAD, walidatory, kolejność warunków wstępnych, zakresy bajtów, przekierowania i typy treści.
  • Serwer proxy wsteczny zachowuje struktury ramki, anulowanie, nagłówki końcowe, aktualizacje, bezpieczne ponawianie prób oraz przekazywanie tożsamości, jednocześnie usuwając pola hop-by-hop.
  • Pamięć podręczna oblicza wiek, świeżość, ponowną walidację, nagłówek Vary, unieważnianie i reguły użycia przestarzałych danych, zamiast traktować cache'owanie jako skrót klucz-wartość.
  • TLS, QUIC, ACME, wczesne dane i WebTransport używają ograniczonego stanu i jawnej polityki awarii.

Te same zasady mają zastosowanie w trybie szybkiej ścieżki. Webship nie definiuje jednej „poprawnej” ścieżki i innej ścieżki odniesienia.

Semantyka HTTP, ramowanie, buforowanie i pośrednictwo

  • RFC 3986 — Jednolity identyfikator zasobów (URI): składnia ogólna. Webship normalizuje względne odwołania Location i Content-Location, w tym segmenty kropkowe, przed podejmowaniem decyzji o unieważnieniu pamięci podręcznej.
  • RFC 6455 — Protokół WebSocket. Odwrotne proxy aktualizuje weryfikację klucza WebSocket, wartości akceptacji, podprotokółu, rozszerzeń i przejścia tunelowego.
  • RFC 6585 — Dodatkowe kody statusu HTTP. Pola żądań o nadmiernym rozmiarze używają zdefiniowanej odpowiedzi 431, gdy odpowiedź HTTP jest nadal możliwa.
  • RFC 6797 — HTTP Strict Transport Security. Strict-Transport-Security jest wysyłany tylko przez bezpieczny transport i nigdy nie wycieka z neutralnego względem transportu wpisu pamięci podręcznej na nieszyfrowany HTTP.
  • RFC 7235 — Uwierzytelnianie HTTP/1.1. Tokeny schematów uwierzytelniania są analizowane bez rozróżniania wielkości liter, w tym chroniona powierzchnia sterowania MCP. Jego ogólne semantyki HTTP teraz znajdują się w RFC 9110.
  • RFC 7239 — Rozszerzenie HTTP Forwarded. Operatorzy mogą wybrać standardowe pole Forwarded, przestarzałe pola X-Forwarded, oba lub żadne; najpierw usuwane są niezweryfikowane pola tożsamości przychodzącej.
  • RFC 7540 — HTTP/2. Jest to zachowane jako linia kompatybilności z HTTP/2; aktywnym kontraktem HTTP/2 jest jego następca, RFC 9113.
  • RFC 7541 — HPACK: Kompresja nagłówków dla HTTP/2. Stos HTTP/2 należący do Webship ogranicza stan dekodera i tablice enkodera, zachowując jednocześnie format przewodowy HPACK i kodowanie Huffmana.
  • RFC 7838 — HTTP Usługi Alternatywne. Alt-Svc reklamuje punkt końcowy HTTP/3 bez zmiany źródła reprezentowanego przez URL.
  • RFC 8441 — Inicjalizacja WebSockets za pomocą HTTP/2. Webship obsługuje rozszerzoną podstawę negocjacji CONNECT w dół. Nie udaje, że HTTP/1.1 upstream implementuje rozszerzony CONNECT w HTTP/2; nieobsługiwane kombinacje upstream kończą się jawnie niepowodzeniem.
  • RFC 8470 — Wykorzystywanie wczesnych danych w HTTP. Wczesne żądania, które Webship nie będzie przetwarzać, otrzymują 425 Too Early zamiast być obsługiwane z niebezpiecznymi założeniami powtórzeń.
  • RFC 8941 — Strukturalne wartości pól dla HTTP. Wartości priorytetu HTTP używają analizowania słownika pola strukturalnego; nieprawidłowe pola opcjonalne są ignorowane w całości.
  • RFC 9110 — Semantyka HTTP. Metody, kody statusu, pola, walidatory, warunki wstępne, przekierowania, metadane treści, HEAD, CONNECT, OPTIONS i semantyka zakresu mają jeden aktualny kontrakt we wszystkich wersjach protokołu.
  • RFC 9111 — Pamięć podręczna HTTP. Webship wdraża skorygowany wiek, jawne określenie świeżości, Vary, only-if-cached, must-revalidate, proxy-revalidate, bezpieczne użycie przeterminowanych danych oraz unieważnianie skutecznych i powiązanych URI.
  • RFC 9112 — HTTP/1.1. Zasady dotyczące linii żądania, pól, długości ciała, kodowania transferu, fragmentów, nagłówków końcowych, utrzymywania połączenia i zamykania są egzekwowane przed wysłaniem do aplikacji.
  • RFC 9113 — HTTP/2. Pseudo-pola order, authority, zabronione pola połączenia, ograniczenia TE, cykl życia strumienia, kontrola przepływu, GOAWAY i zakres błędów są obsługiwane przez ścieżkę H2 należącą do Webship.
  • RFC 9114 — HTTP/3. Webship posiada ścieżki żądań, strumienia sterującego, SETTINGS, strumienia krytycznego, anulowania oraz błędów strumienia kontra połączenie używane przez jego serwer HTTP/3.
  • RFC 9204 — QPACK: Kompresja pól dla HTTP/3. Pojemność tabeli dynamicznej jest ograniczona przez ogłoszony limit, strumienie instrukcji pozostają parsowalne przy zerowej pojemności, a nieprawidłowy stan staje się wymaganym błędem QPACK.
  • RFC 9218 — Rozszerzalny schemat priorytetyzacji dla HTTP. Pilność i stopniowe dostarczanie sterują harmonogramowaniem HTTP/3, podczas gdy nieznane parametry priorytetu pozostają rozszerzalne.
  • RFC 9220 — Uruchamianie WebSockets za pomocą HTTP/3. Webship implementuje fundament ustawień HTTP/3 extended-CONNECT używany przez nowoczesne protokoły tunelowane; nie oznacza to, że każdy możliwy protokół CONNECT jest akceptowany.
  • RFC 9297 — Ramki HTTP i protokół Capsule. Sesje WebTransport używają ograniczonego dekodowania kapsułek i powiązania z ramkami HTTP, przy czym nieznane kapsułki są traktowane jako punkty rozszerzeń zamiast jako błędy parsera.
  • RFC 9421 — Podpisy wiadomości HTTP. Opcjonalne pochodzenie odpowiedzi Ed25519 może obejmować wersję i konfigurację Webship bez zastępowania TLS ani uwierzytelniania aplikacji.
  • RFC 10008 — Metoda HTTP QUERY. Webship traktuje QUERY jako bezpieczną i idempotentną, zachowuje jej ciało podczas proxy, uwzględnia ciało i metadane reprezentacji w tożsamości pamięci podręcznej, zabrania heurystycznej świeżości, obsługuje zachowanie warunkowe i zakresowe oraz nigdy nie unieważnia pamięci podręcznej tylko dlatego, że użyto QUERY.

Transport QUIC i kontrola zatorów

TLS, certyfikaty i automatyczne zarządzanie certyfikatami

WebTransport: precyzyjnie o tym, co jest standaryzowane

WebTransport przez HTTP/3 nie jest liczony jako pięćdziesiąty trzeci RFC. Od wersji Webship 1.3.1 jego mapowanie w warstwie transmisji pozostaje w wersji draft-ietf-webtrans-http3-16. Webship implementuje ten draft na bazie standaryzowanego HTTP/3, rozszerzonego CONNECT, QUIC DATAGRAM, HTTP Datagram oraz wymienionych powyżej warstw Capsule. Implementuje również negocjowane rozszerzenie RESET_STREAM_AT wymagane do zachowania niezawodnego prefiksu identyfikującego sesję, gdy strumień WebTransport jest resetowany.

To rozróżnienie ma znaczenie. Zgodność ze standardami nie poprawia się przez nazywanie projektu RFC. Poprawia się przez ścisłe śledzenie projektu, izolowanie go od zwykłych ścieżek HTTP, negocjowanie każdego rozszerzenia, ograniczanie każdego zasobu sesji i testowanie zachowania przy anulowaniu i awarii.

Dlaczego ta szerokość ma znaczenie w produkcji

Błąd standardu rzadko występuje izolowanie. Nieprawidłowe obsługiwanie HSTS może przekroczyć granicę pamięci podręcznej. Nieprawidłowa instrukcja QPACK może zakończyć niezwiązane żądania. Niebezpieczne założenie dotyczące wczesnych danych może powtórzyć operację. Klucz pamięci podręcznej QUERY, który pomija ciało żądania, może zwrócić wynik innego zapytania. Proxy, które usuwa trailerów lub nieprawidłowo obsługuje anulowanie, może cicho zmienić protokół aplikacji.

Architektura Webship traktuje te kwestie jako powiązane zagadnienia. Limity parsera, inspekcja bezpieczeństwa, caching, reverse proxy, stan transportu i instrumentacja dzielą wyraźne kontrakty. Efektem jest jeden serwer, który może przechodzić między HTTP/1.1, HTTP/2, HTTP/3, dostarczaniem statycznym, reverse proxy, streamowaniem i WebTransport bez nadawania każdemu trybowi innej definicji poprawności.

Zweryfikuj twierdzenie

Nie przyjmuj wzmocnionej formy na słowo. Przeczytaj [dokumentację Webship 1.3.1](/docs/1.3.1), sprawdź konfigurację i granice protokołu oraz odtwórz opublikowane zachowanie. Następnie [pobierz Webship](/downloads) i przetestuj przypadki graniczne, które mają znaczenie dla twojego systemu.

Webship inżynieria

Strumieniowanie z Webship: Wysoka przepustowość bez poświęcania poprawności

Dowiedz się, jak Webship obsługuje i pośredniczy w przesyłaniu dużych plików multimedialnych za pośrednictwem HTTP/1.1, HTTP/2 i HTTP/3 przy użyciu adaptacyjnego kTLS, sterowania prędkością BBR, ograniczonych buforów i bramek integralności bez błędów.

Czytaj artykuł

Twój serwer internetowy jest decyzją kosztów infrastruktury

Webship łączy wysokoprzepustową dostawę Rust, nowoczesne protokoły, wbudowaną ochronę, lokalną obserwowalność oraz operacje natywne dla sztucznej inteligencji w jednym środowisku uruchomieniowym — dając zespołom infrastruktury wiarygodną drogę do zmniejszenia liczby serwerów i komponentów brzegowych.

Czytaj artykuł

Webship 1.3.1: Wyższa HTTP/2 i pojemność Reverse-Proxy

Webship 1.3.1 zwiększa bezpośrednią wydajność h2c o 34,19%, bezpośrednie HTTP/2 TLS o 26,67% oraz H1 w trybie reverse-proxy o 15,10% w porównaniu do 1.2.0, jednocześnie wzmacniając stabilność i poprawność transportu.

Czytaj artykuł