Büyük indirmeler ve VPN: yolu istek anında seçin
Bir yönlendirici, yanıt gelmeden boyutunu ölçemez. Göreve göre yönlendirme, uygulamada bir karar noktası ya da mevcut yolu koruyan bir kuyruk politikası gerektirir.
“Büyük indirmeleri VPN'in etrafından gönder, küçük yanıtları üzerinde tut” bir yönlendirme politikası gibi kulağa geliyor, ama değil. Yönlendirici o anda erişilebilen bilgiyle karar verir: adresler, portlar, protokol, firewall işaretleri, tanımlanmış bir akış. Yanıtın nihai boyutu bu kümede yoktur, çünkü henüz gelmemiştir ve yönlendirici baytları ölçebileceği zaman onları zaten taşımaktadır. Göreve göre yönlendirmek istiyorsanız, karar görevi bilen bir noktaya taşınmalıdır ve aşağıdaki kontrol listesi tasarımınızda böyle bir nokta olup olmadığını gösterir.
Bir yönlendirici yanıtı neden ölçemez
Bir paketin yola ihtiyaç duyduğu anda yönlendirici en fazla akışın ilk birkaç paketini görmüştür. Kim kiminle konuşuyor, hangi protokolle, hangi işaretle ve şu ana kadar kaç bayt geçti, söyleyebilir. Şimdiye kadarki baytlar geçmişi anlatır. Yanıtın boyutu henüz oluşturulmamış bir yanıtın özelliğidir ve parçalı ya da akış halindeki yanıtlarda asla önceden bilinmeyebilir.
Protokolün kendi üst verisi bile göründüğünden zayıftır. HTTP, uzunluğu gövdeden önce duyurulmayan yanıtlara izin verir ve tek bir kullanıcı eylemi, birleşik maliyeti hiçbir başlık değerine benzemeyen çok sayıda istek üretebilir. Bir başlığı görevin boyutu saymak, yönlendirme hatası olmadan önce modelleme hatasıdır.
Kontrol 1: yolu seçebilecek bir karar noktası var mı?
Seçimi yapacak bileşeni adlandırın, sonra seçim anında ne bildiğini adlandırın. Belgelenmiş bir ana bilgisayar kümesinden indiren güncelleyici amacını aktarım başlamadan önce bilir. Üst veriyi inceleyip sonra isteği açan indirme hizmeti görevi bağlantı oluşmadan önce bilir. İşbirliği yapan bir proxy, kendini yönlendirici olarak göstermeden istek düzeyinde politika uygulayabilir veya yanıtı önbelleğe alabilir.
Yanıt “ağ geçidi” ise kontrol listesi zaten başarısız olmuştur. Ağ geçidi bilinen akışları hedefe, işarete veya istemci bölümüne göre sınıflandırıp ilk paketten itibaren tanımlı bir yola gönderebilir; bu, onaylanmış bir güncelleyici için çoğu zaman yeterlidir ve bilinmeyen bir yanıt boyutu için asla yeterli değildir.
Kontrol 2: üst veri size gerçekte ne söylüyor?
Uygulama farkındalıklı yönlendirme, okuduğu alanlar kadar iyidir. HTTP'nin anlambilimi içindeki yanıt uzunluğu kuralları, uzunluğun başlangıçta mevcut olmadığı durumlara izin verir ve içerik kodlamaları aktarılan bayt sayısını temsil boyutundan zaten farklı kılar. Bu nedenle bir başlık eşiği aştığında yolu değiştiren politika tutarsız davranacak ve çoğunlukla tam da yakalaması gereken büyük aktarımlarda bu olacaktır.
Uygulama üst verisinin destekleyebileceği şey bir görev hakkındaki karardır: bu iş akışı toplu eşitleme, bu etkileşimli, bu bilinen bir kaynaktan yazılım güncellemesi. Bu, niyet dilinde yazılmış bir politikadır ve test edilebilecek kadar istikrarlıdır. “Bu yanıt kırk megabayttan büyük olacak” böyle bir politika değildir.
Kontrol 3: akış zaten var mı?
Yönlendirme bir akış için bağlantının kimliğini değiştirmeden değişebilir ve bu ayrımı doğru tutmakta yarar var. Bir TCP bağlantısı uçlarının adresleri ve portlarıyla tanımlanır ve yönlendirme tablosu altlarında değişirse paketler başka bir yol izleyebilir. Görünmez biçimde değişemeyecek olan şey ağ adresi çevirisi durumudur: trafiği başka bir çıkışa taşımak genellikle genel kaynak demetini değiştirir ve uzak uç, eşleşen durumu olmayan farklı bir eş görecektir.
conntrack -L -p tcp --dport 443 | head -5
ip route get 203.0.113.10
ss -tn state established dst 203.0.113.10
Dolayısıyla pratik kural, bağlantının ortasında bir çıkıştan diğerine geçişin göç değil yeni bir ilişki olduğudur. Tasarım aynı bağlantının sürmesini gerektiriyorsa karar ilk SYN'den önce verilmeliydi ve sonradan eklenen hiçbir paket kuralı bunu temiz biçimde yeniden kuramaz.
Kontrol 4: gerçek gereksinim çıkış değil, gecikme mi?
“Toplu trafiği başka yere gönder” isteklerinin çok büyük bir kısmı aslında büyük bir aktarımın etkileşimli işi yavaş hissettirmesinden şikâyettir. Bu bir zamanlama sorunudur ve zamanlama yanıtı vardır: mevcut yolda adil kuyruk veya desteklenen bant genişliği politikası, toplu akışın bir sohbet iletisini aç bırakmasını, ikisini de yerinden oynatmadan engeller.
tc qdisc replace dev eth0 root cake bandwidth 100mbit
Belirtiye bu şekilde yaklaşmak çıkış kararını güvenlik politikasının koyduğu yerde bırakır ve tek komutla geri alınabilir. Bütün bir trafik sınıfı için çıkışı değiştirmek, kimlik doğrulama, günlükleme ve erişim kuralları sonuçları olan bir politika değişikliğidir, bu yüzden gecikme şikâyetinde ilk başvurulacak araç olmamalıdır.
Gereksinim gerçekten başka bir internet çıkışıysa bunu o sözcüklerle söyleyin ve desteklenen bir sınırda uygulayın: onaylanmış bir iş akışından yeni bağlantı ya da kendi isteğini seçilmiş bir çıkıştan açan uygulama. Ardından hangi görevlerin hangi çıkışı kullandığını kaydedin, böylece sonraki kişi bunu bir yönlendirme tablosundan çıkarmak zorunda kalmasın.
Kontrol listesini değişiklik kaydında tutun: karar noktası, onu sürükleyen alan veya görev, akışın zaten var olup olmadığı ve ölçülen belirtinin gecikme mi çıkış mı olduğu. Dört soru ve dördüne de yanıt veren bir politika, savunmak yerine işletebileceğiniz bir politikadır.