MTU / MRU sorunu tam olarak nedir, neden kaynaklanır ve nasıl düzeltilir?

İçeren komutları gibi, neden genellikle makul olmayan birkaç aceleyle önerilen "sihirli tedavileri" ile "MTU / MRU sorun" olarak tanımlanır yavaş, tepkisiz internet bağlantılarını donma asılı durumlarda, (durum için genellikle geçersiz veya uygulanamaz) olarak iptablesveya ifconfig, ve diğer " MTU'yu TSS "büyülerine sıkıştırın.

Bilmek istediğim, MTU / MRU sorununun tam olarak ne olduğu, bağlantı hızını ve gecikmesini neden etkilediği ve sorunun nasıl çözüldüğünü (bilinen ve modern yöntemler), çünkü sorunun çözümüne bilgili bir şekilde yaklaşmak istediğimden, sihirli değil.

Bu biraz karmaşık bir Soru, bu yüzden temelden başlayacağım. Bunların hepsini zaten biliyorsan affet beni.

MTU, bilgisayar arayüzünün göndereceği en büyük veri paketi olan Maksimum İletim Birimi'dir. Ethernet için varsayılan değer 1500 bayttır. Ethernet çerçevelerinin genellikle 1522-1542'ye kadar olmasına izin verilir (ne saydığınıza bağlıdır) ve fazladan başlık bilgisi için 'ayrılmış' olur.

Çeşitli bağlantıların farklı yetenekleri olabilir. İnternette, 1500'den biraz daha küçük bir MTU'ya sahip bir bağlantıda çalışmak oldukça yaygındır. Bunun nedeni genellikle ekstra başlık bilgisi kullanan veya 'standart' Ethernet dışında bir ortam kullanmasıdır (İnternetin çoğu aslında çalışır ATM / SoNet bağlantıları). Normalde böyle bir bağlantıyla karşılaşan trafik basitçe birden fazla parçaya bölünür ve gönderilir.

Bu yaygın olduğu ve IP'nin icat edildiği zamanda ICMP protokolünün sorumluluğunun bir kısmı MTU'larla ilgili herhangi bir sorunu iletmekti. Herhangi bir nedenle bir paket kırılamaz ve iletilemezse, sorunu gönderen bilgisayara iletmek için ICMP kullanılır. Gönderen bilgisayar, bilgileri daha küçük parçalara ayırarak uygun eylemi gerçekleştirir ve herkes mutludur. Tüm bu süreç perde arkasında ele alınmaktadır. Bir de düzgün ağa o MTU ayarları ile muck asla gerekmez .

Bu son cümledeki niteleyici vurucu. Otomatik işlemin bozulmasının üç yaygın nedeni vardır:

1. Kırık Uygulama - Yazılım bir noktada açık olması gerektiği gibi çalışmıyor. İnsanların İnternet'in ilgili standardını takip etmeleri gerektiğini söyleyen hiçbir yasa yoktur ve genellikle ucuz olmak için standartları ihlal eden şirketler vardır.
2. Yönetici olarak devre dışı bırakılmış uygulama - İyi niyetleri olan insanlar yazılımı kırıyorlar çünkü gerçekte ne yaptıklarını bilmiyorlar. Ben sadece ICMP.0.0 paketleri için kullanıldığını düşündüğüm için insanların ICMP'yi engellediğini gördüm (yankı, çoğu kişi bunu pingyardımcı program tarafından biliyor ).
3. Bu 'normal' sürecin tamamen dışındaki diğer nedenler. Çoğunlukla bu, bağlantının o kadar kayıplı olduğu anlamına gelir, ancak daha kısa paketler bağlantıdan güvenilir bir şekilde (veya çok sayıda yeniden deneme olmadan) bunu yapar. Bazı erken DSL ve CableModemlerin böyle sorunları vardı. Ve ondan önce, çok düşük kaliteli telefon hatları ve agresif hat kodları kullanırken çevirmeli ağın yaygın olarak böyle sorunları vardı.

Peki, neden yaygın: Tembel teknisyenler / şirketler. Küçük bir MTU ile bağlantıyı engellemek, yukarıda özetlenen sorunlardan birini düzeltmekten neredeyse evrensel olarak 'daha kolaydır'. Yukarıda belirtildiği gibi, hiç kimse bu günlerde MTU ile uğraşmak zorunda kalmamalı (Jumbo çerçevelerini etkinleştirmeyi düşünebileceğim tek istisna, ancak burada tartıştığımız şey bu değil). Her durumda doğru tedavi, altta yatan problemi bulmak ve düzeltmektir; klasik tedavi hastalığı değil semptom.

MTU bir bağlantıyı nasıl etkiler? Verilerin küçük parçalara ayrılması, her parçanın, özellikle son derece güvenilir olmayan bağlantılarda hedefe ulaşma şansının daha yüksek olacağı anlamına gelir. Bununla birlikte, daha küçük parçalar olarak, iletilen veriler başına daha fazla yük vardır. Bu, etkin bağlantı hızının azaldığı anlamına gelir; MTU gerçekten küçükse. Gecikme etkilenebilir, ancak üstbilginin ekstra işlenmesi ve ek yükü ve parçalanma / yeniden montaj işlemi nedeniyle küçük olmasını bekleyebilirim.

Güncelleme: - --clamp-mss-to-pmtu
Şahsen MTU ile hiç uğraşmadım; Biraz mükemmeliyetçi olduğumu itiraf ediyorum ve böyle çirkin hack'lerle karşılaştığımda her zaman sorunun kökenini buluyorum ve düzeltebiliyorum. Bu amaçla iptablesseçenek --clamp-mss-to-pmtubana tanıdık gelmiyor. Görünüşe göre bu hack'i kullanmak son derece yaygındır ve çoğu durumda muhtemelen çok haksızdır. Yukarıdaki sorunlardan birini telafi etmek hala bir hack. Ben iptables (8) için Linux manpage alıntı:

Bu hedef, 'ICMP Parçalanma Gerekli' veya 'ICMPv6 Paket Çok Büyük' ​​paketlerini engelleyen cezai braindead ISP'lerin veya sunucuların üstesinden gelmek için kullanılır.

Mankenin nispeten sert dili, RFC'leri takip etmeyen ISP'ler ve Ağlar tarafından ne kadar hor görüldüğüne dair bir gösterge olmalıdır (ve denemek veya telafi etmek için çaba göstermez).

VPN'lerde UDP kullanımından bahsetmişken, bu, VPN'nin ek yükünü en aza indirmek ve mevcut uç noktaların oturum bilgilerini yönetmesine izin vermek için en yaygın olanıydı. VPN'in oturumun nasıl ele alınması gerektiğini bilmesinin bir yolu yoktur, böylece görev en iyi bilen uygulamalara bırakılır.

Birçok modern VPN tünel protokolü, GRE ve L2TP gibi daha düşük seviyelerde (daha az ek yük ile) oluşturulmuştur; veya SSTP veya SSH gibi daha yüksek seviyelerde (genellikle kısıtlayıcı güvenlik duvarları veya diğer nedenlerle uyumluluk nedeniyle) tünellenir. Bunlar yavaş yavaş UDP'nin yerini bir ulaşım mekanizması olarak alacaktır.

Güncelleme 2: - MTU / ICMP Sorunlarını Teşhis Etmek
Bir MTU / ICMP sorununuz olduğunu ve emin olmak istediğinizi düşünüyorsunuz. Bu işlem için iki temel adım vardır. Yönergeler bir Linux veya BSD kutusu içindir, ancak hemen hemen her işletim sistemine uyarlanabilir.

1. Bir ICMP Ping hedefi seçin (ör. Google.com, Yahoo.com, Facebook.com vb.). Aşağıdaki komut ile ping deneyin: ping -c 2 -s 1472 -D google.com.
   • Bu başarılı olmalı . Başarılı olmazsa, "paketin parçalanması gerekir" i döndürmelidir. Bunlardan herhangi biri doğruysa, durun, bağlantınız iyi çalışıyor.
   • Bu herhangi bir şey döndürmezse veya "zaman aşımı" mesajı verirse, bir sorununuz vardır.
2. Yalnızca kopuk bağlantılar için: çalıştırın traceroute -F google.com 1472. Bu size hangi şeridin kırıldığını söyleyecektir. Not: CPE'nin traceroute isteklerine yanıt vermemesi oldukça yaygındır, bu nedenle ilk atlama yanıt vermezse endişelenmeyin.
   • Yanıt veren son atlama hangisi olursa olsun, sizin için doğru çalışan son atlamadır.
   • Hiçbiri yanıt vermiyorsa, CPE veya DSL hattınız (hangisinin biraz zor olabileceğini anlamak, ancak modern ise neredeyse hiç CPE değildir). Not: Bağlantınız iyi çalışıyorsa, traceroute başarıyla tamamlanır.

Yan not: Bugünlerde hangi İSS PPTP kullanıyor ?! Bu eski ve işe yaramaz geçmişten gelen bir patlama. En azından PPPoE kullanıyor olmalılar; ancak modemi MAC ve Segment tarafından yetkilendirmek çok daha kolay olurdu (hem İSS hem de Müşteri için daha kolay).