OpenVPN TCP'de takılıyor: rto_min sıra başı blokajını çözmez

Tünel üzerinden çalışan etkileşimli bir kabuk, bir dosya kopyası sürerken birkaç saniye donuyor, sonra hiçbir şey olmamış gibi devam ediyor. Sorun yalnızca indirmede, ama kabuk da bekliyor ve ikisi aynı anda toparlanıyor. Bu örüntü, birçok konuşmayı taşıyan tek bir güvenilir akışın imzasıdır ve insanların ilk denediği neredeyse her ayar değişikliğine dayanır.

Belirtiyi dikkatle okumaya değer, çünkü bir ayara değil bir mekanizmaya işaret ediyor: duraklama ortaksa neden de ortaktır ve ortak olan nesne dış bağlantıdır. Bu olurken günlükteki her şey normal görünür.

Belirti: her şey aynı anda duruyor

İki iç bağlantının birlikte takılması ipucudur. Yavaş bir indirme ve yavaş bir kabuk, ayrı sıra numaralarına ve ayrı tıkanıklık durumuna sahip ayrı TCP konuşmalarıdır, bu yüzden birindeki arıza diğerine dokunmamalıdır. Aynı ritimde durakladıklarında, üstlerinde bir şey baytlarını sıralıyordur.

O şey tünelin taşıma katmanıdır. TCP modunda OpenVPN, kapsüllenmiş paketleri eşe giden tek bir TCP bağlantısına yazar ve TCP'nin sözleşmesi tek bir bayt akışının sırayla teslimidir. Sonraki baytlar, hangi iç konuşmaya ait olursa olsun, eksik olanlardan önce uygulamaya verilmez.

Belirtinin ne söylemediğine dikkat edin. Yolun bozuk olduğunu, sunucunun aşırı yüklendiğini ya da şifrenin yavaş olduğunu söylemez. Bunlar farklı biçimler üretir: tekdüze düşük verim, zaman aşımları veya tek yönü etkileyen arızalar. Kayıp bir segment yeniden iletildiğinde biten ortak bir duraklama, özellikle sıralama etkisidir.

Tek dış bayt akışı, birçok iç konuşma

Tünelin aynı anda bir indirme ve bir kabuk taşıdığını düşünün. Dış bağlantının bir segmenti kaybolur. Sonraki segmentler alıcı konağa varabilir ve alıcı TCP yığını bunları onaylar, ancak boşluk dolmadan yukarı teslim edemez. Bu yüzden OpenVPN'in kabuk için okuyacak bir şeyi yoktur, gerçi kabuğun kendi baytları çok önce gelmiştir.

Bu, tek bir bağlantı içinde sıra başı blokajıdır ve iki uygulamanın iç bağlantıyı paylaşmasını gerektirmez. Dış olanı paylaşırlar ve bu yeterlidir.

İkinci derece etki durumu kötüleştirir. Onay görmeyen bir iç gönderici, dış katmanın zaten teslim etmeye çalıştığı verileri yeniden iletebilir. Bu yeniden iletim, segment kaybedebildiğini az önce kanıtlamış bir yolda ek tünel trafiğine dönüşür, böylece kurtarma işi önemli olan kurtarmayla yarışır.

Bunların hiçbiri bir çöküşü garanti etmez. Kısa gidiş-dönüşlerin ve geniş kuyrukların olduğu temiz bir yolda bu düzen yıllarca tamamen kullanılabilir kalabilir. Arıza, kayıp, gecikme ve kuyruk derinliği bir araya geldiğinde ortaya çıkar, bu yüzden raporlar iyi donatılmış ofisler yerine tıkanık yukarı akışlarda ve mobil bağlantılarda kümelenir.

Daha uzun bir iç zamanlayıcı neden yardımcı olamaz

Bir rotada rto_min ile en düşük yeniden iletim zaman aşımını yükseltmek, o rotayı kullanan yerel olarak üretilen TCP trafiği için zamanlayıcı tabanlı yeniden iletimi erteler. Gerçek etkisi olan gerçek bir ayardır ve birinci değil ikinci derece sorunu ele alır.

ip route show
ip route show cache 2>/dev/null | head
ss -tin dst 10.70.0.1

Yapamadığı şey, dış baytları sıra dışı serbest bırakmak, eksik segmenti daha hızlı kurtarmak veya uzak uygulama sunucusuna aynı zamanlayıcıyı benimsetmektir. Alıcı yığın yine sırayla teslim eder ve uzak uçtaki gönderici yine kendi gidiş-dönüş ölçümlerini kullanır.

Diğer tüm kayıp kurtarma mekanizmalarını da devre dışı bırakmaz. Gerçek kaybın zamanlayıcı tabanlı kurtarma gerektirdiği yerde daha büyük bir alt sınır, uygulamanın harekete geçmeden önce daha uzun beklemesine yol açar, bu da gecikmeye duyarlı bir oturumun ihtiyacının tam tersidir.

On iki saniyelik sabit bir taban, bu konudaki tavsiyelerde sanki bir TCP tünelinin varlığı bunu gerektiriyormuş gibi görünür. RFC 6298'de tanımlanan yeniden iletim zamanlayıcısı, üstel geri çekilmeyle ölçülen gidiş-dönüş süresinden türetilir, bu yüzden sabit bir taban belirli bir yol için politika seçimidir, protokol gereği değildir. Geniş uygulandığında, o rotanın kapsadığı her akışın kurtarmasını değiştirirken belirtiyi gizler.

tcp-nodelay ne yapar ve ne yapmaz

Taşıma soketinde Nagle tarzı tamponlamayı devre dışı bırakan tünel seçeneğinin dar bir amacı vardır: küçük yazmaların gönderimden önce daha fazla veri beklemesini durdurur. Bu, etkileşimli trafiğin aksi halde sağlıklı bir yolda ekstra gecikmeden kaçınmasına yardımcı olur.

Taşımayı sırasız hale getirmez ve kayıp bir segmentten sonra kurtarmayı kısaltmaz. Yeniden iletim zaman aşımı için duraklayan bir kabuk, sıralama kuralına hiç dokunmamış bu seçenek açıkken de duraklamaya devam eder.

İkisini karıştırmak kolaydır, çünkü ikisi de gecikme düzeltmesi olarak anlatılır. Biri tamponlamanın getirdiği yapay beklemeyi kaldırır, diğeri taşımanın neyi garanti ettiğini değiştirmeyi gerektirirdi ve bunu hiçbir soket seçeneği yapmaz.

Taşımalar nasıl adil biçimde karşılaştırılır

Operatör izin veriyorsa ve iki hizmet de varsa, aynı iş yükünü taşıyan bir UDP hizmetini ve bir TCP hizmetini aynı sunucuya giden aynı erişim yolu üzerinde karşılaştırın. İki test arasında ülkeyi, sağlayıcıyı veya sunucu neslini değiştirmek, sonuca hâkim olacak bir değişken sokar.

Bir verim sayısı yerine ortak duraklamayı izleyin. Dış kayıp sırasında birkaç iç uygulamanın birlikte takılması, sıra başı blokajını tanımlayan gözlemdir; tek bir düşük hız testi değeri bunu yapmaz.

Tünel arayüzünde ve fiziksel arayüzde alınan yetkili yakalamalar iki katmanı temiz biçimde ayırır, çünkü iç ve dış yeniden iletimler farklı sıra uzaylarına sahip farklı bağlantılara aittir. Dış akış bir boşluk gösterirken iç yeniden iletimleri görmek doğrudan kanıttır.

UDP'ye geçmek fazladan güvenilir akışı kaldırır ve iç TCP'nin kendi kurtarmasını yapmasına bırakır. Sıfır kayıp veya düşük gecikme vaat etmez; doymuş bir yukarı akış, aşırı büyük kuyruklar veya bir MTU sorunu yine de düzeltilmeyi gerektirir. Tünel dışındaki trafik asla tünelin sıra boşluğunun arkasında tutulmaz, ancak iki yol tek bir tıkanık bağlantıyı paylaştığında yine de zarar görebilir, bu ortak darboğaz da buraya katlanmak yerine kendi incelemesini hak eder.