GCP'de statik IP ve VPN hızı: üç değişken, tek test

Adres ayrıldıktan sonra aktarım hızlandı ve sonuç kendini yazdı. Ancak aynı değişiklik tüneli UDP'den TCP'ye geçirdi, testi başka bir akşama taşıdı ve muhtemelen başka bir bölgedeki VM'e indirdi. Harici bir adres ayırmak bir yaşam döngüsü sorununu çözer: yeniden başlatmalar arasında uç noktayı aynı tutar. Paketleri hızlandıracak hiçbir mekanizması yoktur, bu yüzden o deneydeki hız farkı diğer değişkenlere aittir ve önünüzdeki karar sırada hangisini test edeceğinizdir.

Ayrılmış bir adres gerçekte ne satın alır

Compute Engine, örnekle birlikte atanan ve bırakılan geçici adresleri, sizin ayırıp tuttuğunuz statik adreslerden ayırır. Bu fark saklama ve faturalandırmayla ilgilidir, paketin izlediği yolla değil. Kararlı bir uç nokta DNS kayıtları, uzaktan erişim profilleri, iş ortağı izin listeleri ve VM yeniden başlatıldığında değişmemesi gereken güvenlik duvarı kuralları için gerçekten yararlıdır.

Bunlar bir tane ayırmak için iyi nedenlerdir. Hiçbiri aktarım hızı nedeni değildir.

Katmanı, adresi ve taşımayı üç değişken olarak tutun

Google Cloud ayrıca Premium ve Standard Network Service Tiers katmanlarını satar ve ikisi de farklı özellik kullanılabilirliğiyle internete farklı yollar izler. Statik adresleme her ikisine de diktir, bu yüzden statik ve Premium'u bir VM hakkında ilgisiz gerçekler olarak görün, eşanlamlı olarak değil. Gerçek katmanı, bölgeyi ve devrede olan herhangi bir interconnect veya attachment'ı kaydedin, çünkü bunlar yolu adres etiketinin asla yapamayacağı biçimde tanımlar.

Üç değişken, üç ayrı deney, yoksa sonuç bir ölçüm değil hikâyedir.

Tek bir soruyu yanıtlayan bir test tasarlayın

Onaylanmış UDP ve TCP profillerini karşılaştırırken VM'i, adresi, istemci konumunu, hedefi ve iş yükünü sabit tutun. Hem her taşıma için bir sunucu dinleyicisi hem de eşleşen güvenlik duvarı kuralları gerekir; istemcide bir anahtar sözcüğü değiştirip dinleyiciyi değiştirmeden bırakmak yalnızca sabrınızı sınar. Tekrarlanabilir bir aktarım kullanın ve yönü, süreyi, tek ve paralel akışları ve birimleri kaydedin, çünkü MB/s ile Mb/s sekiz kat farklıdır.

VM'in CPU'sunu da izleyin, çünkü küçük bir örnek şifreleme veya softirq işinde ağdan çok önce doygunluğa ulaşır ve bu tavan tam olarak sağlayıcı sınırı gibi görünecektir.

VM'den ve istemciden gelen yeniden iletim ve kayıp sayaçları yol sorununu taşıma sorunundan ayırır, ilerleme çubuğu bunu yapamaz. iperf3 ile işleyen bir sıra taşıma başına yaklaşık on dakika sürer. Sunucuyu uzak tarafta başlatın, istemciyi her yönde otuz saniye çalıştırın ve her yönü üç kez yineleyin. Her serinin ilk çalıştırmasını atın, sonra gönderici ve alıcı hızlarını TCP çalıştırmalarının yazdırdığı yeniden iletim sayısıyla birlikte karşılaştırın.

UDP ile TCP mekanik olarak neden farklıdır

OpenVPN UDP üzerinde datagram taşır ve kayıpla baş etmeyi uygulamanın kendi taşımasına bırakır. TCP üzerinde tünelin güvenilir akışı zaten güvenilir bir uygulama akışının altında oturur, bu yüzden kaybolan tek bir segment arkasındaki her şeyi durdururken dış bağlantı kendi takvimine göre yeniden gönderir. Bu kuyruk başı davranışı TCP'yi TCP içinde tünellemenin bir özelliğidir, sağlayıcı politikası değildir. MTU ve MSS işleyişi de iki kip arasında farklıdır ve bu aynı yoldaki parçalanma davranışını değiştirir.

Bu yüzden daha hızlı bir TCP denemesi yalnızca o gün o yolda TCP'nin daha hızlı olduğunu kanıtlar, daha genel hiçbir şeyi değil.

Sonucu incelemeyi atlatacak biçimde yazın

Savunulabilir bir sonucun bir biçimi vardır: bu profil, bu makine boyutunda, bu ağ katmanında, bu ölçülen iş yükünü bu yönde bu koşullar altında sürdürdü. Bundan daha geniş her şey bir akşamın sağlayabileceğinden daha çok çalıştırma gerektirir. Daha yavaş durum açıklanamadan kalırsa, hiçbir sağlayıcı belgesinin tanımlamadığı bir sınırlama uydurmak yerine onu paket ve kaynak kanıtıyla birlikte bir gözlem olarak saklayın.

Adres kararlılığı ve aktarım hızı aynı dağıtım için ikisi de önemli olabilir ve yararlı karar her değişiklikte hangisini satın aldığınızdır.