Pěkná diskuse.
Co může způsobit, že jedním spojením nedokážu ucpat celou konektivitu je celá řada a bylo by to na román. :-(
Tabulka velikost okna proti RTT a clkové propustnost linky je celkem jasná, ale je třeba vzít v potaz spolehlivost linky. Platí to tak jen pro zcela bezeztrátovou linku. Pokud se sem tam se vám ztrtí paket a chci TCP okno hadně nad 64 KiB, tak musí být aktivován TCP scaling a ten se volí jen na otevření spojení v SYN paketech a pak se trvale používá stejný. Vedlejší efekt tohoto je, že nemůžete měnit velikost okna za chodu zcela plynule, ale pokud ten scaling přestřelíte, tak při drobné ztrátovosti linky docílíte toho, že ji nedokážete ucpat jedním spojením (protože minimální snížení okna je o moc velký krok dolů, než kolik by stačilo k vytížení linky).
U samby není jen problém v TCP okně v linuxu, ale i vlastní CIFS protokol vkládá další režii, takže na stejné trase a HW při porovnání FTPčko by mohlo dát lepší výsledky, hlavně FTP server obvykle používá nějakou formu systémového volání sendfile() (unixy) nebo TransmitFile() (Windows), která řeší odeslání souboru v rámci jádra OS bez účasti aplikační vrstvy a ušetří se tuna času přesouváním dat po paměti (u novější samby jde použít v konfiguraci use sendfile=yes a umí to znatelně urychlit některé typy přenosů, pokud mám klienty W2K a výše). Jen u linux kernelu řady 2.6 se měnil u TCP algoritmus pro manipalici s oknem a potvrzování nejméně 3x s ohledem na sítě LFN.
Co se týče vlivu L2 prvků na zpoždění delší linky, tak je obvkyle menší, než vliv té vzdálenosti (pokud se bavíme o WAN sítích po republice). Rychlost světla v optickém kabelu není žádný zázrak (v podstatě na rádiových dobrých trasách můžete udělat lepší RTT právě s využitém rychlejšího šíření signálu). K tomu pláči, že já mán přes data carriera odezvu mnohem větší než jiný, který tam ma třeba i X L2 prvků. Někdo od Plzně může mít štestí, že sedí na přímé lince jdoucí do Prahy do NIXu (pokud měřím proti němu) a někdo u Tábora může mít smůlu, že do Prahy mu to jde J. Hradec, Jihlava, Havl. Brod, Pardubice, Kolín, Praha. Tohle už pár km navíc je. Obvkyle toto půjde nějakou SDH tchnologií, takže vliv zpoždení vlastních prvků po trase bude minimální (respektive přechod z async ethernetu do sync linku bud emít větší režii, která se vyplatí na dlouhé trase, kde se sync prvkách umoří).
Jiná věc je šmejd L2 krabice. Teorie, kolik zpoždění vloží jeden switch dělající store-forward je hezká, realita bývá krutě jiná. Ale stále se bavíme o desítkách us na jeden prvek. Třeba zmíněné HPčka Procurve 2510G, ty celkem zpomalí předávání mezi porty, pokud je nějaký jiný port ve skupině v 100 Mbps režimu, asi málo vnitřních sběrnic a problém synchronizqíc mezi nima (a starší stovková řada je ještě tragičtější, pokud je velký počet VLAN). Jistě, mohu volat po switchích typu fast-forward, ale od dob, co jsou rychlé RAMky a je ji dost, tak se to u switchů nepoužívá. Respektive Cisco to zase vytáhlo na scénu a nabízí (tuším třeba Catalyst 4900), ale to řešení není určeno nna MAN/WAN sítě. Mířeno pro datacentra, kde provozují single image clustery a snaží se tím natlačit do aplikací, kde vládne InfiniBand sítě. To znamená, kde je požadavke nejen velká přenosová rychlost, ale zároveň i minimální dopravní zpoždění (tady Ethernet může závidět, ale také je to jiná cena).
Myšlenka MPLS není přínosná do L2 sítě ohledně odezvy. MPLS na L2 síti má smysl pro řešení přenosu různých protokolů a překonání bariéry 4000 VLAN. Jako urychlovač má smysl na routované síti, kdy MPLS urychluje průchod směrovači. Ta myšlenka s Cisco CEF nebyla asi úplně správná, to se opět týká až L3 beden (a defacto u cisca je aktivní CEF/dCEF podklad pod MPLS). Popkud mám plně routovanou síť, tak MPLS mí na odezvě něcí nahoní (a to i na wifi síti na Mikrotikách).
Ano rychlé spojení na L2 síti blížící se k hranici Etherneut spolehlivě zabije flow control na L2 vrstvě (802.3x), ale tuhle prasárnu snad nikdo nepoužívá, srážka TCP s tímto obvykle nedopadne dobře. Obecně srážka se switchovaným ethernetme, kde je daná síť zahlcována nad 80% kapacity se nechová úplně dobře, ale to platí při multiaccess přístupu, když jsou jen dva, tak ty efekty nejsou tak rychlé.
Jiné důvody, proč jedním spojením si neucpu celou síť: nejedna síť, kde mají třeba koupeno 300 Mpbs, poslední míle k nim je 1 Gpbs, krása, pohoda, ale předtím má carrier pár chytřejších L2+ beden staršího data, tak proč je nevyužít, tak dál to jde jako port channel přes 3x 100 Mbps kanály a má vyřízeno i osekání konektivity na koupenou hranici. A pak záleží dost na politice těch switchů, jak rozhazují pakety do toho trunku. Dost často to dělají tak, že pakety jednoho spojení jen jednou cestou (pro LACP je to tak i přímo ve specifikaci pro Ethernet) a v reálu to pro koncáka znamená, že jedno spojení nevytíží celou linku (ale u tohoto to platí na jedno spojení a jedno, zda TCP/UDP/cokoliv).
Co se toho řízení průtoku na stanovenou hranici týče, tak je víc technik než jen dropování paketů. Třeba přehazování pořadí paketů, také povede ke snížení rychlosti. Někdy to některé technologie proužívaly pro lepší vytěžování infroastruktuy, řazením různých paketu k sobě, což vede k přeházení pořadí také, ale snad už to časot nepotkáte (u O2 jsme třeba zaznamenal). Jiná možnost, která je v některých bedna implmenetována, tak pro TCP zdržují ACK pakety a také vás tím patřičně přibrzdí (tohle ale nepotkáte u data carriera).
Jinka hezká příčina a celkem zákeřná, proč nedokážu ucpat linku naplno jedním spojením (nebo i vícero, ale tam to není tak patrné) je srážka dvou řízení toků. Jedno u data carriera a druhé u vás. Obecně se to skládá z kroku měření nad nějakým časovým kvantem a pak se v dalším uplatní nějaká politika řízení (často ne hned v následujícíh, ale ob jedno). Tohle se děje u carriera a taktéž u Vás, pokud dopravní zpoždění mezí místem, kde to dělá nadřazená síť a kdy to děláte vy bude v nějakém násobku toho časového kroku řízení toků a pokud se rychlost přiblíží stropu, tak se může stát, že dojde k dvojitému podobnému "regulačnímu zásahu" na stejná data. Efekt je, že pokud linkou se snažíte protlačit jen jedno TCP spojení, tak to nedokáže vymačkat víc jak jednu 1/2, 1/4, .. teoretického maxima. Tohle ale dost závisí i na algoritmu, co daná TCP implemntace používá. Pokud ucpu linku vícero spojeníma, tak to tak vidět není (nebo smolně je nepochopitelně bržděno jedno spojení a ostatní jedou OK). Neprojevuje se to tam, kde probíhá aktivní řizení po celé trase na vícero prvkách za sebou a ne jen diskrétně na jednom místě (což defacto není řízení toků, ale jen vstupní kondiciování, či jak tomu říká teoreie). Také to nenastane, pokud u sebe řídíte toky tka, aby nedošlo k zahlcení celé kapacity (nedojde na působneí nadřazeného řízení limitu toku). O kolik je potřeba podstřelit závisí na kapacitě linky mezi body řízení u sebe a carrirera. Defacot jde o stjený případ srážky různých oken, tkao tunelování TCP v TCP, srážky TCP s L2 flow control, ....
A takto by šlo mastit možné případy dál a dál, na což není už vhodná ranní doba. :-(
