Performans ve Verimlilik: HTTP/3 ile Çalışmak

HTTP/3 ufukta, HTTP/2'nin hemen ardından geliyor - ki bu muhtemelen kendisi hala çok genç. HTTP/1.1'den HTTP/2'ye geçişin 16 yıl sürdüğü göz önüne alındığında, HTTP/3 ile gerçekten ilgilenmesi gereken biri var mı?

Kısa cevap: Evet, bu önemli ve onu hızlandırmalısınız. Tıpkı HTTP/2'nin ASCII'den ikiliye geçerek HTTP/1.1'den önemli değişiklikler yapması gibi. HTTP/3, bu sefer temel taşımayı TCP'den UDP'ye değiştirerek önemli değişiklikler yapar.

HTTP/3, resmi spesifikasyonun bir taslak olduğu tasarım aşamasında olmasına rağmen, halihazırda dağıtılıyor ve bugün ağınızda çalışan bir sürümünü bulma ihtimaliniz yüksek.

Ancak HTTP/3'ün nasıl çalıştığıyla ilgili bazı yeni ikilemler var. Ayrıca, ne faydası var? Ve ağ mühendisleri, sistem yöneticileri ve geliştiricilerin bilmesi gerekenler nelerdir?

Ana Konu: Performans ve Verimlilik

Site ve uygulama geliştiricileri, genellikle yarattıklarının gerçekten kullanılması amacıyla oluşturur. Bazen kitle tabanı sınırlıdır, ancak çoğu zaman fikir mümkün olduğunca çok kullanıcı elde etmektir. Doğal olarak, bir web sitesi ne kadar popüler olursa, o kadar fazla gelir elde edebilir.

Web sitesi yükleme süresindeki 100 milisaniyelik bir gecikme, dönüşüm oranlarına yüzde 7 zarar verebilir.

Akamai Online Perakende Performans Raporu: Milisaniye Kritiktir (2017)

Başka bir deyişle, günde 40.000 ABD doları satış yapan bir e-ticaret sitesi, böyle bir gecikme nedeniyle yılda bir milyon dolar kaybedecektir.

Bir sitenin performansının, bir sitenin daha popüler hale gelmesi için kesinlikle kritik olduğu da bir sır değil. Çevrimiçi alışveriş araştırmaları, artan hemen çıkma oranları ile daha uzun yükleme süreleri arasında ve alışveriş deneyimi sırasında müşteri sadakati ile web sitesi performansı arasında bağlantılar bulmaya devam ediyor.

Araştırma ayrıca şunu buldu:

• Tüketicilerin %47'si bir web sayfasının 2 saniye veya daha kısa sürede yüklenmesini bekliyor.
• İnsanların %40'ı yüklenmesi 3 saniyeden uzun süren bir web sitesini terk ediyor.

Ve bu, on yıldan fazla bir süre önce çevrimiçi alışveriş yapanların sabrının durumuydu. Bu nedenle performans kritiktir ve HTTP/2 ve HTTP/3 her ikisi de daha iyi web sitesi performansı anlamına gelir.

HTTP/2? …Bu da ne?

HTTP/2 protokolünü iyi anlamak, HTTP/3'ü anlamak için çok önemlidir. Her şeyden önce, HTTP/2'ye neden ihtiyaç duyuldu?

HTTP/2, web'deki en büyük performans sorununun gecikme olduğunu bildiren bir çalışmanın sonucu olarak SPDY adlı bir Google projesi olarak başladı. Yazar, "daha fazla bant genişliğinin (çok fazla) önemli olmadığı" sonucuna varmıştır:

Sıhhi tesisat ve internet arasında bir benzetme yaparsak, internetin bant genişliğini su borusunun çapı gibi düşünebiliriz. Daha büyük bir boru daha büyük bir su hacmi taşır ve bu nedenle iki nokta arasında daha fazla su iletebilirsiniz.

Aynı zamanda borunuz ne kadar büyük olursa olsun, boru boşsa ve bir noktadan diğerine su almak istiyorsanız, suyun borudan geçmesi zaman alır. İnternet dilinde suyun borunun bir ucundan diğer ucuna gidip tekrar geri gelmesi için geçen süreye gidiş-dönüş süresi veya RTT denir.

Mike Belshe

Çalışmada amaç, sayfa yükleme süresini azaltmaktı. 1 Mbps'den 2 Mbps'ye çıkmak sayfa yükleme süresini yarıya indirdiği için bant genişliğini artırmanın başlangıçta yardımcı olduğunu gösterdi. Bununla birlikte, faydalar çok hızlı bir şekilde düzleşir.

Buna karşılık, gecikmeyi azaltmanın sürekli bir faydası vardır ve en iyi sonuçları elde eder.

HTTP HOL: Hat Başı Engelleme Sorunu

HTTP/1 protokolündeki gecikmenin ana nedeni, hat başı engelleme sorunudur. Web sayfaları (neredeyse her zaman) birden çok kaynak gerektirir: CSS, JavaScript, yazı tipleri, resimler, AJAX/XMR, vb. Bu, web tarayıcısının sunucuya birden çok istekte bulunması gerektiği anlamına gelir. Ancak, sayfanın kullanışlı hale gelmesi için kaynakların tümü gerekli değildir.

HTTP/1.0 ile tarayıcının bir sonraki isteği başlatmadan önce yanıtı tam olarak almak da dahil olmak üzere bir isteği tam olarak tamamlaması gerekiyordu. Her şey sırayla yapılmalıydı. Her istek, istek satırını, dolayısıyla adı engeller.

HOL engelleme sorununu telafi etme girişiminde, web tarayıcıları tek bir sunucuya aynı anda birden çok bağlantı kurar. Ancak bu davranışı keyfi olarak sınırlamak zorunda kaldılar: Sunucular, iş istasyonları ve ağlar çok fazla bağlantıyla aşırı yüklenebilir.

HTTP/1.1, sorunu çözmeye yardımcı olmak için çeşitli iyileştirmeler yaptı. Bunlardan en önemlisi , web tarayıcılarının önceki isteklerin tamamlanmasını beklemeye gerek kalmadan yeni istekler başlatmasına izin veren boru hattıdır. Bu, düşük gecikmeli ortamlarda yükleme sürelerini önemli ölçüde iyileştirdi.

Ancak yine de tüm yanıtların yapıldıkları sırayla sırayla ulaşmasını gerektirir, bu nedenle hattın başı hala engellenir. Şaşırtıcı bir şekilde, birçok sunucu hala bu özellikten yararlanmıyor.

İlginç bir şekilde, HTTP/1.1, tarayıcıların her HTTP isteği için yeni bir TCP bağlantısı oluşturma ek yükünden kaçınmasına izin veren canlı tutma özelliğini de tanıttı. Bu, TCP'den türetilen bir performans sorununu çözmek için erken bir girişimdi. O kadar etkisizdi ki, çoğu performans uzmanı, sunucuyu çok fazla etkin olmayan bağlantıyla tıkadığı için gerçekten cesaretini kırıyor. Aşağıdaki TCP'ye ve bu sorunun HTTP/2 ile nasıl düzeltildiğine daha yakından bakacağız.

HTTP/2'nin HTTP HOL Engelleme Çözümü

HTTP/2, tek bir bağlantı üzerinden istek-yanıt çoğullamayı tanıttı. Bir tarayıcı herhangi bir zamanda yeni bir istek başlatmakla kalmaz, aynı zamanda yanıtlar herhangi bir sırayla alınabilir; uygulama düzeyinde engelleme tamamen ortadan kalkar.

Bunun doğrudan bir sonucu olarak, HTTP/2 konusunda bilgili web sunucularının verimliliği en üst düzeye çıkarabileceği anlamına gelir - daha sonra bu konuda daha fazlası.

İstek-yanıt çoğullama, HTTP/2'nin ana özelliği olmasına rağmen, diğer birçok önemli özelliği içerir. Okuyucular, hepsinin bir şekilde ilişkili olduğunu not edebilir.

HTTP/2 İkili Çerçeveleme

HTTP/2, HTTP protokol standardını verimsiz, insan tarafından okunabilen bir ASCII istek-yanıt modelinden verimli ikili çerçevelemeye geçirir . Artık sadece bir istek ve yanıt değil:

HTTP/2 ile tarayıcılar, her biri birden çok çerçeveden oluşan birden çok mesaj içeren çift yönlü akışlar üzerinden sunucularla konuşur.

HTTP/2 HPACK (Başlık Sıkıştırma)

HTTP/2'nin HPACK biçimini kullanan yeni başlık sıkıştırması , çoğu site için tonlarca bant genişliği tasarrufu sağlar. Bunun nedeni, bir bağlantı içinde gönderilen istekler için başlıkların çoğunun aynı olmasıdır.

Cloudflare, yalnızca HPACK sayesinde önemli bant genişliği tasarrufları bildiriyor:

• Giriş başlıkları için %76 sıkıştırma
• Toplam giriş trafiğinde %53 azalma
• Çıkış başlıkları için %69 sıkıştırma
• Toplam çıkış trafiğinde %1,4 ila %15 azalma

Tabii ki, daha az bant genişliği kullanmak genellikle daha hızlı bir web sitesi anlamına gelir.

HTTP/2 Akış Önceliklendirme ve Sunucu İletme

HTTP/2'nin çoğullamasının, sunucunun verimliliği en üst düzeye çıkarmasına gerçekten izin verdiği yer burasıdır. Çoğullama, daha yavaş kaynakların (örneğin, büyük resimler, veritabanı tarafından oluşturulan JSON, vb.) yerine daha hızlı kaynakların (örneğin, bellekte önbelleğe alınmış JavaScript) sunulmasına yardımcı olur. Ancak HTTP/2'nin akış önceliklendirmesi aracılığıyla ek bir performans artışına da olanak tanır.

Akış önceliklendirmesi, diğer kaynak yoğun isteklerin bitmesini beklemek zorunda kalmadan bir sayfanın neredeyse hazır yönlerinin eksiksiz olarak tamamlanmasını sağlamaya yardımcı olur. Bu, ağırlıklı bir bağımlılık ağacı aracılığıyla gerçekleştirilir. Bu ağaç, sunucuya en fazla sistem kaynağını hangi yanıtları hizmete ayırması gerektiğini bildirmek için kullanılır.

Bu, özellikle aşamalı web uygulamaları (PWA'lar) için önemlidir. Örneğin, bir sayfada dört JavaScript dosyası olduğunu varsayalım. İkisi sayfa işlevselliği, ikisi ise reklamlar içindir. En kötü durum senaryosu, işlevsel JS'nin yarısını ve reklam JS'sinin yarısını yüklemek ve ardından kalan JS'lerden herhangi birini yüklemeden önce büyük resimleri yüklemektir. Bu durumda, sayfadaki hiçbir şey başlangıçta çalışmaz, çünkü her şeyin en yavaş kaynağı beklemesi gerekir.

Akış önceliklendirmesi ile web tarayıcıları, reklam JavaScript dosyalarından herhangi birini göndermeden önce sunucuya her iki sayfa işlevi JS dosyasını da göndermesi talimatını verebilir. Bu şekilde, kullanıcıların sayfanın işlevselliğini kullanmadan önce reklamların tamamen yüklenmesini beklemeleri gerekmez. Genel yükleme süresi iyileşmemiş olsa da, algılanan performans önemli ölçüde arttı. Ne yazık ki, web tarayıcısındaki bu davranış, web geliştiricileri tarafından belirtilen bir şey olmaktan ziyade, çoğunlukla algoritmalar için bir konudur.

Aynı şekilde, HTTP/2'nin sunucu itme özelliği, sunucunun henüz yapmadığı istekler için tarayıcıya yanıt göndermesine olanak tanır! Sunucu, yakında talep edeceğini bildiği tarayıcı kaynaklarına önceden yükleyerek bant genişliğini verimli bir şekilde kullanarak iletimdeki boşluklardan yararlanabilir. Buradaki umudun bir kısmı, kaynakları şişiren ve yüklenmelerinin daha uzun sürmesine neden olan kaynak satır içi uygulama uygulamasını ortadan kaldırmaktır.

Ne yazık ki, bu özelliklerin her ikisi de gerçekten başarılı olmak için web geliştiricileri tarafından çok fazla dikkatli yapılandırmaya ihtiyaç duyar. Bunları basitçe etkinleştirmek yeterli değildir.

HTTP/2 açıkça birçok potansiyel avantaj sağlar - bazıları diğerlerinden daha ucuza yararlanmak için daha ucuzdur. Gerçek dünyada nasıl gidiyorlar?

HTTP ve HTTP/2 Kabulü

SPDY, 2009'da oluşturuldu. HTTP/2, 2015'te standartlaştırıldı. SPDY, kodun kararsız bir geliştirme dalının adı oldu ve HTTP/2'nin son versiyonu oldu. Sonuç, SPDY'nin modası geçmiş ve HTTP/2 genellikle herkesin izlediği standarttır.

Standardizasyondan sonra, HTTP/2'nin (veya “h2”) benimsenmesi hızla büyüyerek ilk 1000 web sitesinin yaklaşık %40'ına ulaştı. Bu, çoğunlukla müşterileri adına destek dağıtan büyük barındırma ve bulut sağlayıcıları tarafından yönlendirildi. Ne yazık ki, birkaç yıl sonra HTTP/2'nin benimsenmesi yavaşladı ve internetin çoğu hala HTTP/1'de.

HTTP/2 Açık Metin Modu için Tarayıcı Desteği Eksikliği

Şifrelemeyi standardın gerekli bir parçası haline getirmek için HTTP/2 için birçok çağrı yapıldı. Bunun yerine, standart hem şifreli (h2) hem de açık metin (h2c) modlarını tanımladı. Bu nedenle, HTTP/2, HTTP/1'in tamamen yerini alabilir.

Standarda rağmen, mevcut tüm web tarayıcıları yalnızca şifreli bağlantılar üzerinden HTTP/2'yi desteklemektedir ve kasıtlı olarak açık metin modunu uygulamamaktadır. Bunun yerine tarayıcılar, güvenli olmayan sunuculara erişmek için HTTP/1 geriye dönük uyumluluk moduna güvenir. Bu, web'i varsayılan olarak güvenli hale getirmeye yönelik ideolojik bir baskının doğrudan bir sonucudur.

Neden HTTP/3? Ve Nasıl Farklı?

HTTP/2 tarafından düzeltilen HTTP hat başı engelleme sorunuyla, protokol geliştiricileri dikkatlerini bir sonraki en büyük gecikme sürücüsüne çevirdiler: TCP hat başı engelleme sorunu.

İletim Kontrol Protokolü (TCP)

IP (internet protokolü) ağları, bilgisayarların birbirine paket göndermesi fikrine dayanır. Bir paket, yalnızca üstüne bazı adresleme bilgilerinin eklendiği verilerdir.

Ancak uygulamaların genellikle veri akışlarıyla ilgilenmesi gerekir. Bu yanılsamayı elde etmek için, iletim kontrol protokolü (TCP), uygulamalara içinden bir veri akışının akabileceği bir boru sunar. Çoğu boruda olduğu gibi, "ilk giren ilk çıkar" (FIFO) olarak da bilinen verilerin borudan girdiği sırayla çıkacağı garantisi vardır. Bu özellikler, TCP'yi çok kullanışlı ve çok yaygın olarak benimsenmiştir.

TCP'nin sağladığı veri teslim garantilerinin bir parçası olarak, çok çeşitli durumlarla başa çıkabilmesi gerekir. En karmaşık sorunlardan biri, bir ağ aşırı yüklendiğinde tüm verilerin durumu herkes için daha kötü hale getirmeden nasıl iletileceğidir. Bunun algoritmasına tıkanıklık kontrolü denir ve internet özelliklerinin sürekli gelişen bir parçasıdır. Yeterli tıkanıklık kontrolü olmadan, internet durma noktasına gelir.

86 yılının Ekim ayında, İnternet bir dizi "tıkanıklık çöküşü"nün ilkini yaşadı. Bu süre boyunca, LBL'den UC Berkeley'e (400 yarda ve üç IMP atlama noktasıyla ayrılmış siteler) veri çıkışı 32 Kbps'den 40 bps'ye düştü.

V. Jacobson (1988)

TCP'nin hat başı engelleme sorununun ortaya çıktığı yer burasıdır.

TCP HOL Engelleme Sorunu

TCP tıkanıklık kontrolü, paket kaybı algılandığında kullanılan paketler için geri alma ve yeniden iletim mekanizmalarını uygulayarak çalışır. Geri çekilme, ağı sakinleştirmeye yardımcı olmak için tasarlanmıştır. Yeniden iletim, verilerin sonunda teslim edilmesini sağlar.

Bu, TCP verilerinin hedefe düzensiz olarak ulaşabileceği anlamına gelir ve paketleri akışa yeniden birleştirmeden önce paketleri yeniden sıralamak alıcı tarafın sorumluluğundadır. Ne yazık ki bu, tek bir kayıp paketin, sunucu yeniden iletimini beklerken tüm TCP akışının duraklatılmasına neden olabileceği anlamına gelir. Bu nedenle, hattın başı bloke edilir.

Google'ın bir başka projesi de QUIC adlı bir protokol sunarak bu sorunu çözmeyi amaçlıyordu.

QUIC protokolü, TCP yerine UDP'nin üzerine inşa edilmiştir ve QUIC, HTTP/3'ün temelini oluşturmaktadır.

UDP Nedir?

Kullanıcı datagram protokolü (UDP), TCP'ye bir alternatiftir. Bir akış yanılsaması veya TCP'nin sunduğu garantilerin aynısını sağlamaz. Bunun yerine, verileri bir pakete yerleştirmenin, başka bir bilgisayara adreslemenin ve göndermenin kolay bir yolunu sağlar. Güvenilmez , düzensizdir ve herhangi bir tıkanıklık kontrolü ile birlikte gelmez .

Amacı hafif olmak ve iletişime izin vermek için gereken minimum özellikleri sağlamaktır. Bu şekilde uygulama kendi garantilerini uygulayabilir. Bu, gerçek zamanlı uygulamalarda genellikle çok kullanışlıdır. Örneğin, telefon görüşmelerinde, kullanıcılar genellikle verilerin %100'ünü nihai olarak almak yerine, verilerin %90'ını hemen almayı tercih ederler.

HTTP/3'ün TCP HOL Çözümü

TCP HOL engelleme sorununu çözmek, yalnızca UDP'ye geçmekten fazlasını gerektiriyordu, çünkü tüm verilerin teslim edilmesini garanti etmek ve ağ tıkanıklığının çökmesini önlemek hâlâ gerekli. QUIC protokolü, UDP tipi deneyim üzerinden optimize edilmiş bir HTTP sağlayarak tüm bunları yapmak için tasarlanmıştır.

QUIC, akış yönetimi, ikili çerçeveleme, vb.'nin kontrolünü ele geçirdiğinden, QUIC'in üzerinde çalışırken HTTP/2'nin yapması gereken pek bir şey kalmaz. Bu, QUIC + HTTP'nin bu yeni kombinasyonunun HTTP/3 olarak standartlaştırılmasına yönelik itici faktörün bir parçasıdır.

Not: Protokol yıllardır geliştirilmekte ve üretim ortamlarında dağıtılmakta olduğundan, QUIC'in birçok sürümü vardır. GQUIC adında Google'a özel bir sürüm bile var. Bu nedenle, eski QUIC protokolleri ile yeni HTTP/3 standardı arasında bir ayrım yapmak önemlidir.

Her Zaman Şifreli

HTTP/3, TLS'den büyük ölçüde ödünç alan ancak doğrudan kullanmayan şifreleme içerir. HTTP/3 için ana uygulama zorluklarından biri, yeni gerekli işlevselliği eklemek için değiştirilmesi gereken TLS/SSL kitaplıklarıdır.

Bu değişiklik, HTTP/3'ün neyi şifrelediği açısından HTTPS'den farklı olmasından kaynaklanmaktadır. Eski HTTPS protokolüyle, yalnızca verilerin kendisi TLS tarafından korunur ve birçok taşıma meta verisi görünür hale gelir. HTTP/3'te hem veriler hem de aktarım protokolü korunur. Bu bir güvenlik özelliği gibi gelebilir ve öyle. Ancak HTTP/2'de mevcut olan birçok ek yükü önlemek için bu şekilde yapılmıştır. Bu nedenle, taşıma protokolünün yanı sıra verileri şifrelemek, protokolü daha performanslı hale getirir.

HTTP/3'ün Ağ Altyapısı Üzerindeki Etkisi

HTTP/3 tartışmasız değildir. Ana endişeler ağ altyapısı ile ilgilidir.

İstemci tarafı HTTP/3

İstemci tarafında, UDP trafiğinin yüksek oranda hız sınırlaması ve/veya engellenmesi oldukça yaygındır. Bu kısıtlamaları HTTP/3'e uygulamak, protokolün amacını ortadan kaldırır.

İkincisi, HTTP'nin izlenmesi ve/veya engellenmesi oldukça yaygındır. HTTPS trafiğinde bile, ağlar, belirli ağlardan veya belirli bölgelerden belirli web sitelerine erişimi engellemek amacıyla bağlantıyı kesmeleri gerekip gerekmediğini belirlemek için protokolün açık metin aktarım öğelerini düzenli olarak izler. Bazı ülkelerde, bu, belirli hizmet sağlayıcılar için yasalarca bile zorunlu kılınmıştır. HTTP/3'teki zorunlu şifreleme bunu imkansız kılar.

Bu sadece hükümet düzeyinde filtreleme değil. Birçok üniversite, halk kütüphanesi, okul ve ilgili ailelere sahip evler aktif olarak ya belirli web sitelerine erişimi engellemeyi ya da en azından hangi sitelerin ziyaret edildiğinin bir kaydını tutmayı seçmektedir. HTTP/3'teki zorunlu şifreleme bunu imkansız kılar.

Şu anda sınırlı filtrelemenin mümkün olduğunu belirtmekte fayda var. Bunun nedeni, web sitesinin ana bilgisayar adını taşıyan ancak yol, sorgu parametreleri vb. olmayan sunucu adı göstergesi (SNI) alanının hala şifrelenmemiş olmasıdır. Ancak bu durum, yakın zamanda TLS standardına eklenen ESNI'nin (şifreli SNI) piyasaya sürülmesiyle değişecektir.

Sunucu tarafı HTTP/3

Sunucu tarafında, trafik beklemeyen tüm bağlantı noktalarını ve protokolleri engellemek en iyi uygulamadır; bu, sunucu yöneticilerinin artık mevcut TCP 443 kurallarına güvenmek yerine HTTP/3 için UDP 443'ü açması gerektiği anlamına gelir.

İkinci olarak, ağ altyapısı TCP oturumlarını yapışkan hale getirebilir, bu da yönlendirme öncelikleri değişse bile her zaman aynı sunucuya yönlendirilecekleri anlamına gelir. HTTP/3, oturumsuz olan UDP üzerinden çalıştığından, özellikle yapışkan yönlendirmeye yardımcı olmak için şifrelenmemiş bırakılan HTTP/3'e özgü bağlantı kimliklerini izlemek için ağ altyapısının güncellenmesi gerekir.

Üçüncüsü, kötüye kullanımı tespit etmek, yaygın güvenlik sorunlarını izlemek, kötü amaçlı yazılımların ve virüslerin yayılmasını tespit etmek ve önlemek vb. için HTTP'nin denetlenmesi oldukça yaygındır. Şifrelemesi nedeniyle HTTP/3 ile bu mümkün değildir. Yine de, cihazların HTTP/3 desteği uyguladığı varsayılarak, araya giren cihazın güvenlik anahtarlarının bir kopyasına sahip olduğu seçenekler hala mümkündür.

Son olarak, birçok yönetici, Let's Encrypt gibi hizmetlerin mevcut olmasıyla artık daha az sorun olsa da, daha fazla SSL sertifikasını yönetmek zorunda kalmaya itiraz ediyor.

Bu endişeleri gidermek için yaygın olarak kabul edilen, iyi bilinen çözümler bulunana kadar, birçok büyük ağın HTTP/3'ü basitçe engelleyeceğini düşünüyorum.

HTTP/3'ün Web Geliştirme Üzerindeki Etkisi

Bu cephede endişelenecek pek bir şey yok. HTTP/2'nin akış önceliklendirmesi ve sunucu gönderme özellikleri HTTP/3'te hala mevcuttur. Web geliştiricilerinin, site performanslarını gerçekten optimize etmek istiyorlarsa bu özelliklere aşina olmaları buna değer.

HTTP/3'ü Hemen Şimdi Kullanmak

Google Chrome veya açık kaynaklı Chromium tarayıcı kullanıcıları zaten HTTP/3'ü kullanmak üzere ayarlanmıştır. HTTP/3 sunucularının üretim kalitesi sürümleri hala biraz uzakta - bu yazı itibariyle spesifikasyon tam olarak kesinleşmedi. Ancak bu arada oynayacak çok sayıda araç var ve hem Google hem de Cloudflare, üretim ortamlarına destek vermeye başladı bile.

Bunu denemenin en basit yolu Docker'da Caddy kullanmaktır. Bunun için bir SSL sertifikası gereklidir, bu nedenle herkesin erişebileceği bir IP adresi işleri kolaylaştırır. Adımlar:

1. DNS kurulumu. İnternette yayında olan çalışan bir ana bilgisayar adı edinin, örneğin yourhostname.example.com IN A 192.0.2.1 .
2. Caddy dosyası oluşturma. Şu satırları içermelidir:

 yourhostname.example.com log stdout errors stdout ext .html .htm .md .txt browse gzip tls [email protected]

1. Çalışan Caddy: docker run -v Caddyfile:/etc/Caddyfile -p 80:80 -p 443:443 abiosoft/caddy --quic —veya Docker dışında, caddy --quic .
2. QUIC etkinken krom çalıştırma: chromium --enable-quic
3. (İsteğe bağlı) Bir Protokol Göstergesi uzantısı yükleme.
4. Bir dosya tarayıcısının görünür olması gereken QUIC etkin sunucuya gitme .

Geliştiriciler ayrıca aşağıdaki faydalı araçlarla sunucularını test edebilirler:

• Keycdn'nin HTTP/2 Testi
• LiteSpeed'in HTTP3Check'i
• Qualys'in SSL Sunucu Testi

Okuduğunuz için teşekkürler!