Akış performansı yalnızca bir video oynatıcı sorunu değildir. Yazılım parçacıkları, model ağırlıkları, yedekler, ses kütüphaneleri ve büyük API dışa aktarımları tümü aynı temellere dayanır: baytları hızlı taşımak, tam yükü korumak, geribeslemeye saygı göstermek ve bir istemci bağlantısını kestiğinde temiz bir şekilde durmak.
Webship bu gereksinimleri bir ulaşım problemi olarak ele alırHTTP/1.1, HTTP/2, HTTP/3, doğrudan dosya teslimi, ters vekil sunucu ve WebTransport. Hızlı yol, yalnızca çerçevelemeyi, iptali, son ekleri, güvenlik denetimini ve sınırlı belleği koruduğunda kullanışlıdır.
Ölçülen 100 MB akış kapasitesi
TheWebship 1.3.1 Debian kapasite çalıştırması, sabit 100 MB cihaz ile ölçülen ortalama yük verisi aktarım hızını ölçtü. Kabul edilen her örnek, tam olarak 99.943.778 baytlık yanıt gövdesi ve sıfır istemci, protokol, vekil sunucu, büyük sayfa hatası gerektirdi veHTTP/3 paket kaybı hataları.
| Webship mod | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Doğrudan dosya teslimi | 4.194,8 MiB/s | 3.574,3 MiB/s | 2.096,9 MiB/s | | TLS sonlandırmalı ters proxy | 3.585,7 MiB/s | 3.355,0 MiB/s | 1.938,6 MiB/s | | TLS geçişli ters proxy | 2.783,2 MiB/s | 2.135,0 MiB/s | 1.748,5 MiB/s |
Kaydedilen karşılaştırmada,Webship ölçülen her protokol için en yüksek doğrudan ve TLS-sonlandırmalı medyanı üretti. Tam matris şunları içerir Nginx, Lighttpd, Caddy, HAProxy, Envoy, Pingora ve Bun [karşılaştırma sayfasında](/benchmarks).
Bu sayılar, referans sunucudaki kapasiteyi ölçer. Bunlar, rastgele bir internet yolu için bir söz değildir. Depolama gecikmesi, ağ bant genişliği, gidip gelme süresi, paket kaybı, TLS politikası, eşzamanlılık ve kaynak davranışı hâlâ gerçek teslimat hızını belirler.
Bir ikili, üç taşıma stratejisi
Büyük bir yanıt, küçük bir HTML belgesiyle aynı politikadan fayda görmez.Webship Sıradan istek yolunu muhafazakar tutar ve yalnızca kanıtlanmış toplu yanıtı teşvik eder.
HTTP/1.1: dosya etrafında daha az geçiş
Linux'ta,Webship yanıt başlığını ve dosya yükünü tek bir en iyi çabayla TCP mantar aralığı içinde tutar. Büyük bir TLS yanıtı toplu yola uygun hale geldiğinde, doğrudan dosya teslimi şuradan taşınabilirRustls kayıtlarını denetlenmiş tek yönlü çekirdek TLS'ye kaydedin ve yükü bir uygulama tamponu üzerinden kopyalamadan sendfile kullanın.
Bağlantı hâlâ kullanıcı alanı TLS'de başlar. Küçük yanıtlar orada kalır.Webship en az 1 MiB boyutunda bir yanıt gövdesi bağlantının toplu veri taşıdığını kanıtladıktan sonra yalnızca kTLS geçişini talep eder.
HTTP/2: akış kontrolünü bozmadan toplu işleme
HTTP/2 Çoklamalama, kontrolsüz tamponlamayı pahalı hale getirir.Webship akış ve bağlantı akış kontrolü sınırlarını korurken toplu yazmalar. Yüksek eşzamanlılığa sahip akış için, 128 KiB TLS yazma tamponu iki 64 KiB DATA çerçevesini tutabilir, bağlantı gönderim bütçesi ise açık ve sınırlı olarak kalır.
Zaten hazır olan bir yukarı akış gövde çerçevesi, Hyper framing, ekler, iptal, denetim veya geri basıncı atlamadan önceden alınabilir. Bu, protokol sözleşmesini bozmadan önlenebilir bir zamanlayıcı döngüsünü azaltır.
HTTP/3: kTLS yerine QUIC zamanlaması
HTTP/3 TCP kTLS yolunu asla kullanmaz.Webship taşımaya duyarlı QUIC hız kontrolü, sınırlı datagram paketlemesi, DPLPMTUD ve reaktör başına zamanlayıcı destekli mikro toplu işleme uygular. Büyük HTTP/3 yanıtlar ve kabul edilenWebTransport Oturumlar, normal trafik tarafından kullanılan CUBIC politikasını değiştirmeden BBR'yi seçebilir.
OdaklanmışHTTP/3 kararlılık yeterliliği yedi kabul edilmiş örnek kullanılarak yapıldı. TLS-sonlandırmalı akış, %2,12 varyasyon katsayısıyla 1.938,6 MiB/sn medyan değeri sağladı. TLS geçiş yönteminde %1,65 varyasyon katsayısıyla 1.748,5 MiB/sn elde edildi. Her iki seride de vücut bütünlüğü, istemci, protokol ve paket kaybı hatası sıfırdı.
Doğrudan teslimat mı yoksa ters vekil sunucu mu?
Kullanırken doğrudan teslimatı kullanınWebship Dağıtılmış dosya ağacına sahiptir. Kaynak atlamasını kaldırır ve en verimli statik dosya yolunu etkinleştirir.
Minimal bir çok protokollü site şöyle görünür:
listen = "0.0.0.0:443"
workers = 8
root = "/srv/media"
[[sites]]
domain = "media.example.com"
root = "/srv/media"
[sites.protocols]
h1 = true
h2 = true
h3 = true
[sites.tls]
cert = "/etc/webship/media-cert.pem"
key = "/etc/webship/media-key.pem"Ters-proksi TLS sonlandırmasını kullanırkenWebship yolu izlemeli, WAF veya API Shield kontrolleri uygulamalı, gövde sınırlamalarını zorlamalı, yönlendirme başlıkları eklemeli veya HTTP alanlarını gözlemlemeli:
[reverse_proxy]
enabled = true
tls_termination = true
[reverse_proxy.protocols]
h1 = true
h2 = true
h3 = true
[reverse_proxy.tls]
cert = "/etc/webship/proxy-cert.pem"
key = "/etc/webship/proxy-key.pem"
[[reverse_proxy.routes]]
domain = "media.example.com"
path_prefix = "/"
upstreams = ["10.0.0.20:8080"]Ayarla tls_termination = false kaynağın uygulama düz metnini ve aktif oturum anahtarlarını koruması gerektiğinde. Geçiş (pass-through) şifreli HTTP alanlarını inceleyemez. Bu nedenle TCP geçişi, ClientHello SNI'ye göre yönlendirir, ikenHTTP/3 geçiş, bir paylaşılan UDP kaynağı gerektirir.
Toplu akışı açıkça ayarla
Yüksek eşzamanlılık içinHTTP/2 TLS akışıWebship bu süreçle sınırlı ayarları belgeler:
[runtime.settings]
h2_tls_write_buffer_bytes = "131072"
proxy_h2_tls_max_send_buffer_bytes = "131072"
proxy_h2_tls_connection_send_buffer_bytes = "33554432"Yukarıdaki bağlantı bütçesi, 256 aktif akış için 128 KiB kredi sağlar. Bunu evrensel bir varsayılan olarak değil, bir kapasite kararı olarak değerlendirin. Artırmadan önce beklenen eşzamanlılık ile bellek, gecikme ve veri akışını ölçün.
Linux'ta, çekirdek TLS ve BBR modüllerini yükleyin ve izin verin Webship BBR seçmek için servis hesabı.Webship gerekli çekirdek yeteneği mevcut olmadığında bağlanmadan önce başarısız olur, bu nedenle bir dağıtım, bunu kullanmadan çalışırken optimize edilmiş yolu sessizce talep edemez. Diğer işletim sistemleri taşınabilirliği korurRustPlatformları için belgelenmiş ls ve tıkanıklık kontrol yolları.
WebTransport farklı bir akış şeklidir
WebTransport güvenli bir oturum üzerinde güvenilir akışları ve güvenilmez datagramları birleştirir. TCP kTLS kullanmaz.WebshipSınırlı tanılama uç noktası, kaynakları doğrular ve oturum, akış, kapsül, veri paketi, bayt ve boşta kalma süresi sınırlarını uygular.
1.3.1 kapasite çalışmasında, doğrudanWebTransport Güvenilir akımlar için 1.018,1 MiB/s ve datagramlar için 1.038,9 MiB/s hıza ulaşıldı. TLS geçiş modunda sırasıyla 548,6 MiB/s ve 629,7 MiB/s ulaşıldı. Her iki mod da beş örneğin tamamını, reddedilen örnek olmaksızın, kaybolan datagram olmaksızın ve sıfır müşteri ana hatası ile geçti.
Tercih etmekHTTP/3 yeni içinWebTransport müşteriler. The HTTP/2 Eski süresi dolmuş taslak ayarlarıyla uyumluluk için bir yol mevcut.
Üretim trafiği öncesinde neyi doğrulamalı
- Sadece küçük bir yapay yanıt değil, sunacağınız medya veya eserlerin tam boyutlarını test edin.
- Yanıt uzunluğunu ve içerik özünü istemcide doğrulayın.
- Egzersiz iptali, menzil talepleri, yavaş okuyucular ve origin yarı kapalı davranışı.
- Sürekli verimliliği CPU, bellek, soket hataları, yeniden iletimler ve kuyruk gecikmesi ile birlikte ölçün.
- Doğrudan, TLS sonlandırmalı ve geçişli modları ayrı ayrı doğrulayın; bunların farklı güvenlik ve yönlendirme sınırları vardır.
- Normal üretim trafiği için enstrümantasyonu kapalı tutun, ardından araştırma yaparken sınırlı tanılama özelliğini bilinçli olarak etkinleştirin.
- Çekirdek, konteyner veya systemd sandbox değişikliklerinden sonra Linux kTLS ve BBR ön kontrolünü yeniden kontrol edin.
Bütün yol iş birliği yaptığında akış hızlıdır.WebshipTasarımı, tek bir operasyonel modeli ve tek bir doğruluk standardını korurken, büyük veri optimizasyonlarını protokolüne özgü tutar.
Tamamını oku [Webship 1.3.1 belgelere](/docs/1.3.1) göz atın, [kıyaslama metodolojisi ve rakip matrisi](/benchmarks) inceleyin veya [İndirilenler](/downloads) bölümünden imzalı bir yapı indirin.