Sıcak HTTPS ile sıcak VPN: aynı istek yolunu karşılaştırın

HTTPS'in her API isteği için yeni bir TCP bağlantısı ve yeni bir TLS el sıkışması açtığını, bu yüzden bir saat açık kalan bir tünelin daha ucuz göründüğünü okumuş olabilirsiniz. Bunun ilk yarısı genellikle yanlıştır. Desteklenen bir istemci, birçok alışveriş için kurulmuş bir bağlantıyı yeniden kullanır ve her çağrıda yeni bir istemci kuran bir ölçüm, korumayı değil yaşam döngüsünü ölçer. Bu sayfanın geri kalanı bunun yerine neyin ölçülmesi gerektiğini anlatır.

Yeniden kullanım gerçekte neyi gerektirir

Kalıcılık HTTP modelinin bir parçasıdır, bir hile değildir: tek bir bağlantı birden çok istek-yanıt alışverişi taşır. Bağlantı, taraflardan biri onu kapattığında, sunucu boşta veya aşırı yüklü bir bağlantıyı devre dışı bıraktığında ya da bir başlık veya protokol kuralı bağlantının yeniden kullanılamayacağını söylediğinde sona erer. HTTPS bu konuşmayı her alışveriş için yeni bir el sıkışma istemeden TLS'in içine yerleştirir. Bu yüzden ikinci istek, arada bir şey bağlantıyı sonlandırmadıysa ilk isteğin el sıkışmasını tekrarlamaz.

Yeniden kullanımın uygulamaların kolayca bozduğu bir koşulu da vardır. Bir bağlantıyı yeniden kullanmayı planlayan istemci yanıtın tamamını okumalıdır ve yarıda bırakılan bir yanıt, bağlantı havuzunun kimse fark etmeden kaybolmasının olağan yoludur.

Kitaplığın desteklediği istemciyi ve bağlantı havuzunun yaşam döngüsünü denetleyin, havuzlamanın açık veya kapalı olduğunu varsaymayın. Görüşülen HTTP sürümünü de kaydedin, çünkü HTTP/2 ve HTTP/3 bağlantı yeniden kullanımını HTTP/1.1'den farklı ele alır. Görüşülen sürümü ölçümün bir parçası olarak görün, dipnot olarak değil.

Karşılaştırma neden yaşam döngüsünü ölçer

Her işlem için yeni bir istemci oluşturmak ve onu bir saattir bağlı olan bir tünelle karşılaştırmak, bağlantı kurulumunu kararlı durumla karşılaştırır. Bu meşru bir ölçümdür ve HTTPS ile VPN karşılaştırması değildir. Aynı istemci yapılandırmasıyla iki koşu, davranışı bir koşudan daha iyi tanımlar, özellikle ilk koşu bir çözümleyiciyi veya bağlantı önbelleğini ısıttığında.

API işlemini, sunucuyu, hesabı ve verileri sabit tutun, yoksa karşılaştırma birden fazla değişken taşır. Zamanlayıcıyı nereye koyacağınıza önceden karar verin, çünkü kurulum, TLS görüşmesi, uygulama yürütmesi ve yanıt teslimi toplama farklı katkıda bulunur. Tek bir ilk istek zamanlayıcısı kurulumu tanımlar ve gerçekte sürdürdüğünüz kararlı trafik hakkında hiçbir şey söylemez. Zamanlayıcının sınırlarını sayıların yanına yazın.

Soğuk kurulumu sıcak isteklerden ayırın

İlk isteği kendisinden sonra gelenlerden ayrı ölçün. Ardından hizmetin gerçekte gördüğünü ekleyin: boşta dönemler, patlamalar, eşzamanlılık, yanıt boyutu ve yeniden bağlantılar.

Sertifika doğrulamasını ve HTTPS'i her iki yolda açık bırakın, çünkü bunları kaldırmak daha hızlı bir tasarımı değil farklı bir güvenlik tasarımını ölçer. Tünel rotayı veya ağ geçidinin konumunu değiştiriyorsa, her zaman değişikliğini şifrelemeye atfetmek yerine bu farkı ayrı bildirin, çünkü yol, kayıp ve kuyruk küçük bir isteğe egemen olabilir. Sonuç çıkarmadan önce her yolu aynı rota üzerinde iki kez çalıştırın. Görüşülen protokolü ve zamanlayıcının sınırlarını iki koşuyla birlikte kaydedin.

Kapanan bağlantıya hazırlanın

Kalıcı, kalıcı olduğu anlamına gelmez. Bir sunucu, bir vekil veya bir ağ değişikliği boşta bir dönemde bağlantıyı kapatabilir ve istemci kitaplığının desteklediği davranışla toparlanmalıdır. Bu toparlanmanın bir durum makinesi vardır: istek sunucuda tamamlanmış olabilir ya da sunucu onu okumadan önce başarısız olmuş olabilir ve kapalı bir soket çağırana hangisinin olduğunu söylemez. Bu konumdaki idempotent olmayan bir işlem basitçe yeniden oynatılamaz, çünkü yeniden oynatma bilinmeyen bir sonucu yinelenen bir yazmaya dönüştürür. Burada sıcak bir tünel ile sıcak bir bağlantı aynı davranır, çünkü ikisi de iş uçuşta olduğu anda başarısız olabilir.

Soketi yeniden açan bir döngü yerine hizmetin belgelenmiş yeniden deneme veya idempotentlik mekanizmasını kullanın. Toparlanmayı açıkça test edin: boşta bir bağlantıyı kapatın ve istemcinin sonra ne yaptığını izleyin. Soketi yeniden açmak, durumu değiştiren bir çağrının tekrarlanmasını güvenli kılmaz.

Önce sınırı seçin, sonra ayarlayın

Ağ sınırını, herhangi bir şeyi optimize etmeden önce erişim ve güven gereksinimlerinden seçin. Bir VPN kendi eşleri arasındaki segmenti korur, oysa uygulama uç noktaları ve tünel dışındaki her açık metin segmenti hâlâ önemlidir. Ardından bağlantının yaşam döngüsünü bu sınırın içinde ayarlayın. Daha ucuz tünel sonucu yalnızca her isteğin el sıkışmayı tekrarladığı inancından çıkar ve burada sınanan tam olarak bu inançtır.

RFC 9112'nin kalıcılık bölümü, yeniden kullanımın gerçekte ne vaat ettiğine, bağlantıyı sona erdiren koşullar dahil, referanstır. Bunları yok sayan bir ölçüme güvenmeden önce bir kez okuyun.