UDP her zaman daha hızlı değildir: OpenVPN taşımasını seçmek

Her kılavuz UDP'nin OpenVPN için TCP'yi yendiğini söyler, oysa bu tavsiye bir varsayılandır, ölçüm değil. Taşıma, paketlerin nasıl teslim edildiğini ve yol onları düşürdüğünde ne olduğunu değiştirir, tünelin nasıl şifrelendiğini değil. Yakalama portalı veya yalnızca 443 portuna izin veren bir vekil sunucunun arkasında, daha yavaş seçenek bağlanan tek seçenektir. Aşağıdakiler protokolün ne yaptığını erişim ağınızın neye izin verdiğinden ayırır.

Taşıma gerçekte neyi değiştirir

TCP güvenilir, sıralı bir bayt akışı sunar ve kaybolan her şeyi yeniden gönderir, RFC 9293 belirttiği gibi. UDP datagramları ağa teslim eder ve OpenVPN bu soket üzerinde kendi güvenilirlik katmanını çalıştırır. TCP'yi TCP içinde kapsüllemek iki kurtarma döngüsünü üst üste yığar, bu yüzden kaybolan tek bir segment, dıştaki yeniden iletim gelene kadar iç akışı tutabilir. Bu etkileşim UDP lehine gerçek argümandır ve kendini aktarım hızı olarak değil gecikme olarak gösterir.

Etki kayıp ve gidiş-dönüş süresiyle büyür. Temiz bir yerel yolda iki taşıma da aynı hissedilir, bu yüzden laboratuvar testi şikayeti nadiren yeniden üretir. Tıkalı bir mobil bağlantıda fark, büyük bir aktarımın bir şey fark etmesinden çok önce etkileşimli oturumlarda görünür.

Bunların hiçbiri gizliliğe veya bütünlüğe dokunmaz. TLS el sıkışması ve veri kanalı şifresi iki taşıma için de aynıdır, bu yüzden geçiş zayıf bir şifre paketini kurtaramaz.

TCP yerini nerede kazanır

Erişim ağları TCP'yi seçmenin olağan nedenidir. Bir otel, havalimanı veya misafir ağı giden 443'e izin verip geri kalan her şeyi düşürebilir ve o porttaki TCP dinleyicisi çalışan tek profildir. Bu erişilebilirlik, performans değil, ve kendi başına yeterince iyi bir nedendir.

TCP, yol kararlı ama ara kutular düşmanca olduğunda da yardımcı olur. Bazı ağlar sıradan web trafiğine benzeyen TCP oturumlarına tahammül ederken uzun ömürlü UDP akışlarını sıfırlar. Bu benzerliğin başarılı olup olmaması belirli ağın özelliğidir ve hiçbir kılavuz bunu herkes için vaat edemez. Protokolü suçlamadan önce başarısız olan ağın içinde test edin.

Reddedilen bir oturum açma taşıma sorunu değildir. Bağlantıyı zorla geçirmek için sertifika doğrulamasını devre dışı bırakmak, sonucu çok daha kötü olan başka bir değişikliktir.

Hazır bir TCP profili tutmak pratik uzlaşmadır. Çoğu istemci ikisini de saklar ve ağ UDP yolunu reddettiğinde geçiş yapmanıza izin verir, bu da ihtiyaç duyana kadar hiçbir şeye mal olmaz. Yapmamanız gereken şey, farklı uç noktalara işaret eden iki profil sunmaktır, çünkü o zaman karşılaştırmanız sunucuları ölçer.

Gerçekte hangi dinleyiciye sahip olduğunuzu kontrol edin

Performansı karşılaştırmadan önce iki tarafın taşıma ve port konusunda anlaştığını doğrulayın. İstemci dosyasında proto udp değerini proto tcp olarak değiştirmek sunucu dinleyicisi oluşturmaz. Sunucu o protokol için yapılandırılmış olmalı ve profil ona uymalıdır.

grep -E '^(proto|port|remote)' /etc/openvpn/server.conf
ss -lunp | grep openvpn
ss -ltnp | grep openvpn

grep sunucuya ne kullanması söylendiğini yazdırır, iki soket listesi ise neye bağlı olduğunu gösterir. UDP dinleyicisi yalnızca ilk listede, TCP dinleyicisi yalnızca ikincisinde görünür, bu yüzden eksik satır hiç uygulanmamış bir profili bulmanın en hızlı yoludur. Portu da karşılaştırın, çünkü 1194'teki TCP profili çoğu erişim ağında 443'tekinden farklı davranır. Değişiklikten sonra hizmeti yeniden başlatın ve bağlamayı bildiren günlük satırını okuyun.

İstemci tarafındaki doğrulama ucuzdur: bağlantıyı --verb 4 ile çalıştırın ve günlükteki taşıma satırını okuyun. İstemci UDP diyorken sunucu TCP dinliyorsa el sıkışması hiç başlamaz ve hiçbir ayar yardımcı olmaz.

Taşıma etiketini değil, iş yükünü karşılaştırın

Adil bir karşılaştırma taşıma dışındaki her şeyi sabit tutar. Aynı cihaz, aynı erişim ağı, aynı hedef ana bilgisayar, aynı uygulama ve ideal olarak aynı sunucu. İki profil farklı ana bilgisayarlara işaret ediyorsa o ana bilgisayarları da ölçüyorsunuz.

Her çalıştırma için üç sonuç kaydedin: tünelin kurulup kurulmadığı, ayakta kalıp kalmadığı ve görevin tamamlanıp tamamlanmadığı. Büyük aktarımlar takılırken çalışan küçük istekler taşımaya değil, paket boyutuna ve MTU'ya işaret eder. Tekrarlanan yeniden bağlanmalar yola veya bir ara kutunun zaman aşımına işaret eder.

Gerçekte karşılaştığınız koşullarda çalışan profili saklayın, diğerini de kaydedin. Seçim kişiye değil ağa aittir, bu yüzden herhangi bir tek varsayılan yanıt bir yerde yanlıştır.