Webship bloguna geri dön

Webship mühendisliği

Webship: Dünyadaki En RFC-Uyumlu Web Sunucusu

Webship, RFC gereksinimlerini HTTP/1.1, HTTP/2, HTTP/3, QUIC, TLS, önbellekleme, ters proxyleme, WebTransport, ACME ve yeni QUERY yöntemi genelinde açık davranışa dönüştürüyor. Tam 52-RFC standart haritasını keşfedin.

Web, kesin anlaşmalarla bir arada tutulur. Bir Content-Length alanı her adımda aynı anlama gelmelidir. Bir önbellek, doğrulama gerektiren bir yanıtı yeniden kullanmamalıdır. Hatalı bir HTTP/3 alan bölümü, doğru kapsamda başarısız olmalıdır. Güvenli bir yöntem, bir ters proxy'den geçtikten sonra da güvenli kalmalıdır.

Webship 1.3.1 bir kural etrafında inşa edilmiştir: hız, ancak byte’lar anlamlarını koruduğunda önemlidir.

İşte bu nedenle Webship’i dünyadaki en RFC-uyumlu genel amaçlı web sunucusu olarak tanımlıyoruz. Bu, her RFC’deki tüm isteğe bağlı özelliklerin mevcut olduğunu iddia etmek değil, görünür bir sınırı olan mühendislik iddiasıdır. Aşağıdaki harita, Webship’in aktif sunucu davranışını veya sahip olduğu protokol temellerini etkileyen 52 RFC’ye isim vermektedir. Mevcut standartlar önce gelir. Yerine geçen belgeler uyumluluk kökeni olarak tanımlanır. Taslak spesifikasyonlar RFC olarak yeniden adlandırılmaz.

Uyumluluk bir rozet değil, davranıştır

Webship, üretim sunucularının en sık belirsizleştiği yerlerde standartları uygular:

  • HTTP/1.1 çerçevelemesi, çelişkili uzunlukları, geçersiz transfer kodlamalarını, aşırı büyük istek hedeflerini, hatalı parçaları ve istek kaçırma biçimlerini reddeder.
  • HTTP/2 ve HTTP/3 yasaklanmış bağlantı alanlarını reddeder, sahte alanları doğrular, sıkıştırılmış alan bölümlerini sınırlar ve akış hatalarını bağlantı hatalarından ayrı tutar.
  • Statik dosyalar, HEAD semantiğini, doğrulayıcıları, ön koşul sırasını, bayt aralıklarını, yönlendirmeleri ve içerik türlerini korur.
  • Ters vekil, hop-by-hop alanlarını kaldırırken çerçevelemeyi, iptali, ekleri, yükseltmeleri, güvenli tekrar denemeleri ve yönlendirme kimliğini korur.
  • Önbellek, önbelleğe almayı bir anahtar-değer kısayolu olarak ele almak yerine, yaş, tazelik, yeniden doğrulama, Vary, geçersiz kılma ve bayat kullanım kurallarını hesaplar.
  • TLS, QUIC, ACME, erken veri ve WebTransport, sınırlı durum ve açık başarısızlık politikası kullanır.

Aynı kurallar hızlı yolda da geçerlidir. Webship, tek bir “doğru” yol ve farklı bir kıyaslama yolu tanımlamaz.

HTTP anlambilimi, çerçeveleme, önbellekleme ve vekillik

  • RFC 3986 — Tekdüze Kaynak Tanımlayıcı (URI): Genel Sözdizimi. Webship, önbellek geçersiz kılma kararlarından önce, nokta segmentleri de dahil olmak üzere göreli Location ve Content-Location başvurularını normalize eder.
  • RFC 6455 — WebSocket Protokolü. Reverse-proxy yükseltmeleri WebSocket anahtarını, kabul değerini, alt protokolü, uzantıları ve tünel geçişini doğrular.
  • RFC 6585 — Ek HTTP Durum Kodları. Aşırı büyük istek alanları, bir HTTP yanıtı hala mümkün olduğunda tanımlanmış 431 yanıtını kullanır.
  • RFC 6797 — HTTP Sıkı Taşıma Güvenliği. Strict-Transport-Security yalnızca güvenli taşıma üzerinden yayınlanır ve asla taşıma tarafsız önbellek kaydından açık metin HTTP'ye sızmaz.
  • RFC 7235 — HTTP/1.1 Kimlik Doğrulama. Kimlik doğrulama şeması belirteçleri büyük/küçük harf duyarsız olarak ayrıştırılır, korunan MCP kontrol yüzeyi dahil. Genel HTTP semantiği artık RFC 9110'da bulunmaktadır.
  • RFC 7239 — İletilen HTTP Uzantısı. Operatörler, standart tabanlı bir Forwarded alanı, eski X-Forwarded alanlarını, her ikisini veya hiçbirini seçebilir; güvenilmeyen gelen kimlik alanları önce kaldırılır.
  • RFC 7540 — HTTP/2. Bu, HTTP/2 uyumluluk soy geçmişi olarak korunmaktadır; aktif HTTP/2 sözleşmesi onun halefi olan RFC 9113'tür.
  • RFC 7541 — HPACK: HTTP/2 için Başlık Sıkıştırma. Webship’e ait HTTP/2 yığını, HPACK kablo formatını ve Huffman kodlamasını korurken çözücü durumunu ve kodlayıcı tablolarını sınırlar.
  • RFC 7838 — HTTP Alternatif Servisleri. Alt-Svc, URL tarafından temsil edilen kaynağı değiştirmeden bir HTTP/3 uç noktasını duyurur.
  • RFC 8441 — HTTP/2 ile WebSocket Başlatma. Webship, downstream genişletilmiş-CONNECT müzakere temelini destekler. Bir HTTP/1.1 upstream’in HTTP/2 genişletilmiş CONNECT uyguladığını iddia etmez; desteklenmeyen upstream kombinasyonları açıkça başarısız olur.
  • RFC 8470 — HTTP’de Erken Veriyi Kullanma. Webship tarafından işlenmeyecek erken istekler, güvensiz tekrar oynatma varsayımlarıyla ele alınmak yerine 425 Too Early yanıtı alır.
  • RFC 8941 — HTTP için Yapılandırılmış Alan Değerleri. HTTP öncelik değerleri yapılandırılmış alan sözlüğü ayrıştırmasını kullanır; hatalı isteğe bağlı alanlar tamamen görmezden gelinir.
  • RFC 9110 — HTTP Semantiği. Yöntemler, durum kodları, alanlar, doğrulayıcılar, önkoşullar, yönlendirmeler, içerik metadata’sı, HEAD, CONNECT, OPTIONS ve aralık semantiği, protokol sürümleri arasında tek bir mevcut sözleşmeyi paylaşır.
  • RFC 9111 — HTTP Önbellekleme. Webship, düzeltilmiş yaşı, açık tazeliği, Vary başlığını, sadece-önbellekten, tekrar doğrula (must-revalidate), vekil-tekrar doğrula (proxy-revalidate), güvenli eski kullanım ve geçerli ve ilişkili URI'lerin geçersiz kılınmasını uygular.
  • RFC 9112 — HTTP/1.1. İstek satırı, alan, gövde uzunluğu, aktarım kodlaması, parça, ek, kalıcılık ve kapatma ile sınırlı kurallar, uygulama gönderiminden önce uygulanır.
  • RFC 9113 — HTTP/2. Pseudo-alan sırası, yetki, yasaklı bağlantı alanları, TE kısıtlamaları, akış yaşam döngüsü, akış kontrolü, GOAWAY ve hata kapsamı, Webship’in sahip olduğu H2 yolu tarafından yönetilir.
  • RFC 9114 — HTTP/3. Webship, HTTP/3 sunucusu tarafından kullanılan istek, kontrol akışı, AYARLAR, kritik akış, iptal ve akışa karşı bağlantı hata yollarının sahibidir.
  • RFC 9204 — QPACK: HTTP/3 için Alan Sıkıştırma. Dinamik tablo kapasitesi ilan edilen sınırlama ile sınırlandırılmıştır, talimat akışları sıfır kapasitede bile çözümlenebilir durumda kalır ve geçersiz durum gerekli QPACK hatası haline gelir.
  • RFC 9218 — HTTP için Genişletilebilir Önceliklendirme Şeması. Aciliyet ve kademeli teslim rehberi, bilinmeyen öncelik parametreleri genişletilebilir kalırken HTTP/3 planlamasını yönlendirir.
  • RFC 9220 — HTTP/3 ile WebSocket Başlatma. Webship, modern tünellenmiş protokoller tarafından kullanılan HTTP/3 genişletilmiş-CONNECT SETTINGS temelini uygular; bu, her olası CONNECT protokolünün kabul edildiği anlamına gelmez.
  • RFC 9297 — HTTP Datagramları ve Kapsül Protokolü. WebTransport oturumları, sınırlı kapsül çözümlemesi ve HTTP Datagram ilişkisi kullanır; bilinmeyen kapsüller, ayrıştırıcı hataları yerine genişletme noktaları olarak işlenir.
  • RFC 9421 — HTTP Mesaj İmzaları. İsteğe bağlı Ed25519 yanıt kökeni, TLS veya uygulama kimlik doğrulamasının yerine geçmeden Webship sürümü ve yapılandırma kimliğini kapsayabilir.
  • RFC 10008 — HTTP QUERY Yöntemi. Webship, QUERY'yi güvenli ve tekrarlanabilir olarak değerlendirir, proxy üzerinden iletilirken gövdesini korur, önbellek kimliğinde gövde ve temsil meta verilerini içerir, sezgisel tazeliğe izin vermez, koşullu ve aralık davranışını destekler ve yalnızca QUERY kullanıldığı için önbelleği geçersiz kılmaz.

QUIC taşıma ve tıkanıklık kontrolü

TLS, sertifikalar ve otomatik sertifika yönetimi

WebTransport: standartlaştırılan şey hakkında kesin

HTTP/3 üzerinden WebTransport, elli üçüncü RFC olarak sayılmamaktadır. Webship 1.3.1 itibarıyla, onun iletim eşlemesi hala draft-ietf-webtrans-http3-16 olarak kalmaktadır. Webship, bu taslağı standartlaştırılmış HTTP/3, genişletilmiş CONNECT, QUIC DATAGRAM, HTTP Datagram ve yukarıda adı geçen Capsule katmanlarının üzerine uygular. Ayrıca, bir WebTransport akışı sıfırlandığında güvenilir bir oturum tanımlayıcı ön eki korumak için gerekli olan müzakere edilmiş RESET_STREAM_AT uzantısını da uygular.

Bu ayrım önemlidir. Bir taslağı RFC olarak adlandırmak, standart uyumluluğunu artırmaz. Bunu artıran, taslağı açıkça takip etmek, onu sıradan HTTP yollarından izole etmek, her uzantıyı müzakere etmek, her oturum kaynağını sınırlandırmak ve iptal ve başarısızlık davranışını test etmektir.

Üretimde bu kapsam neden önemlidir

Bir standart hatası nadiren izole olur. Yanlış HSTS işleme bir önbellek sınırını aşabilir. Hatalı bir QPACK talimatı ilgisiz istekleri sonlandırabilir. Güvensiz bir erken veri varsayımı bir işlemi tekrar oynatabilir. İstek gövdesini atlayan bir QUERY önbellek anahtarı farklı bir sorgunun sonucunu döndürebilir. Ekleri kaldıran veya iptali yanlış yöneten bir proxy, bir uygulama protokolünü sessizce değiştirebilir.

Webship’in mimarisi bunları bağlantılı konular olarak ele alır. Ayrıştırıcı sınırları, güvenlik denetimi, önbelleğe alma, ters proxyleme, taşıma durumu ve ölçümlemeler açık sözleşmeleri paylaşır. Sonuç, her mod için doğruluk tanımını farklı tanımlamadan HTTP/1.1, HTTP/2, HTTP/3, statik teslimat, ters proxyleme, akış ve WebTransport arasında geçiş yapabilen tek bir sunucudur.

İddiayı doğrula

Bir üstlük ifadesini güvenerek kabul etmeyin. [Webship 1.3.1 dokümantasyonunu](/docs/1.3.1) okuyun, yapılandırmayı ve protokol sınırlarını inceleyin ve yayımlanmış davranışı yeniden üretin. Sonra [Webship'i indirin](/downloads) ve sisteminiz için önemli olan uç durumları test edin.

Webship mühendisliği

Webship ile Akış: Doğruluğu Feda Etmeden Yüksek Verim

Uyarlanabilir kTLS, BBR hız kontrolü, sınırlı tamponlar ve sıfır-hata bütünlük kapıları kullanarak Webship'in büyük medya dosyalarını HTTP/1.1, HTTP/2 ve HTTP/3 üzerinden nasıl sunduğunu ve vekil olarak çalıştırdığını öğrenin.

Makaleyi oku

Web Sunucunuz Bir Altyapı Maliyeti Kararıdır

Webship, yüksek verimli Rust teslimatı, modern protokoller, yerleşik koruma, yerel gözlemlenebilirlik ve yapay zekâya uygun operasyonları tek bir çalışma zamanında birleştirerek, altyapı ekiplerine daha az sunucu ve daha az uç bileşen ile güvenilir bir yol sunar.

Makaleyi oku

Webship 1.3.1: Daha Yüksek HTTP/2 ve Ters Vekil Sunucu Kapasitesi

Webship 1.3.1, 1.2.0'a kıyasla doğrudan h2c kapasitesini %34,19, doğrudan HTTP/2 TLS'i %26,67 ve ters-proxy H1'i %15,10 artırırken, aynı zamanda iletim kararlılığını ve doğruluğunu güçlendirir.

Makaleyi oku