OpenVPN cez TCP: rto_min neodstráni blokovanie na začiatku frontu

Interaktívny shell cez tunel zamrzne na niekoľko sekúnd, kým beží kopírovanie súboru, a potom pokračuje, ako keby sa nič nestalo. Problém má len sťahovanie, no aj shell čaká, a oba sa zotavia v tom istom okamihu. Tento vzor je podpisom jediného spoľahlivého toku, ktorý nesie mnoho rozhovorov, a prežije takmer každé ladenie, ktoré ľudia skúsia ako prvé.

Príznak si zaslúži pozorné čítanie, pretože ukazuje na mechanizmus, nie na nastavenie: pauza je zdieľaná, takže príčina je zdieľaná, a zdieľaným objektom je vonkajšie spojenie. Všetko ostatné v logu počas toho vyzerá normálne.

Príznak: všetko sa zastaví naraz

Dve vnútorné spojenia, ktoré sa zaseknú spolu, sú stopou. Pomalé sťahovanie a pomalý shell sú oddelené TCP rozhovory s oddelenými sekvenčnými číslami a oddeleným stavom preťaženia, takže porucha v jednom by sa nemala dotknúť druhého. Keď sa zastavia v rovnakom rytme, niečo nad nimi usporadúva ich bajty.

Tým niečím je transport tunela. V režime TCP OpenVPN zapisuje zapuzdrené pakety do jedného TCP spojenia s peerom, a kontraktom TCP je doručovanie v poradí jediného bajtového toku. Neskoršie bajty sa aplikácii neodovzdajú pred chýbajúcimi, nech patria ktorémukoľvek vnútornému rozhovoru.

Všimnite si, čo príznak nehovorí. Nehovorí, že cesta je pokazená, že server je preťažený alebo že šifra je pomalá. Tie vytvárajú iné formy: rovnomerne nízku priepustnosť, časové limity alebo poruchy postihujúce jeden smer. Zdieľaná pauza, ktorá sa skončí, keď sa stratený segment odošle znova, je konkrétne efektom usporiadania.

Jeden vonkajší bajtový tok, mnoho vnútorných rozhovorov

Predstavte si tunel, ktorý nesie sťahovanie a shell súčasne. Jeden segment vonkajšieho spojenia sa stratí. Nasledujúce segmenty môžu doraziť do prijímajúceho hostiteľa a prijímajúci TCP zásobník ich potvrdí, ale nemôže ich odovzdať nahor, kým sa medzera nevyplní. OpenVPN preto nemá pre shell čo čítať, hoci bajty samotného shellu dorazili dávno predtým.

Toto je blokovanie na začiatku frontu v rámci jedného spojenia a nevyžaduje, aby dve aplikácie zdieľali vnútorné spojenie. Zdieľajú vonkajšie, a to stačí.

Efekt druhého rádu to zhoršuje. Vnútorný odosielateľ, ktorý nevidí potvrdenia, môže znova odoslať dáta, ktoré sa vonkajšia vrstva už snaží doručiť. Toto opätovné odoslanie sa stáva ďalšou tunelovou prevádzkou na ceste, ktorá práve dokázala, že dokáže stratiť segmenty, takže práca na obnove súťaží s obnovou, na ktorej záleží.

Nič z toho nezaručuje zrútenie. Na čistej ceste s krátkymi spiatočnými časmi a štedrými frontami môže byť usporiadanie roky úplne použiteľné. Porucha sa objaví, keď sa strata, oneskorenie a hĺbka frontu zídu spolu, a preto sa hlásenia zhlukujú okolo preťažených odosielacích liniek a mobilných spojení, nie okolo dobre vybavených kancelárií.

Prečo dlhší vnútorný časovač nemôže pomôcť

Zvýšenie minimálneho časového limitu opätovného odoslania na trase pomocou rto_min odkladá opätovné odoslanie na základe časovača pre lokálne generovanú TCP prevádzku, ktorá používa túto trasu. Je to skutočný gombík so skutočným účinkom a rieši problém druhého rádu namiesto prvého.

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

Čo nedokáže: uvoľniť vonkajšie bajty mimo poradia, obnoviť chýbajúci segment rýchlejšie alebo prinútiť vzdialený aplikačný server prijať ten istý časovač. Prijímajúci zásobník stále doručuje v poradí a odosielateľ na vzdialenom konci stále používa svoje vlastné merania spiatočného času.

Nevypína ani všetky ostatné mechanizmy obnovy po strate. Tam, kde skutočná strata vyžaduje obnovu na základe časovača, väčšie minimum prinúti aplikáciu čakať dlhšie, kým koná, čo je opak toho, čo potrebuje relácia citlivá na latenciu.

Pevný prah dvanástich sekúnd sa objavuje v radách k tejto téme, akoby existencia TCP tunela ho implikovala. Časovač opätovného odoslania opísaný v RFC 6298 sa odvodzuje z meraného spiatočného času s exponenciálnym ústupom, takže konštantný prah je voľba politiky pre konkrétnu cestu, nie požiadavka protokolu. Široko aplikovaný skrýva príznak a zároveň mení obnovu pre každý tok, ktorý trasa pokrýva.

Čo tcp-nodelay robí a čo nie

Tunelová možnosť, ktorá vypína Nagle-like bufferovanie na transportnom sockete, má úzky účel: zabraňuje malým zápisom čakať na ďalšie dáta pred odoslaním. To pomáha interaktívnej prevádzke vyhnúť sa dodatočnému oneskoreniu na inak zdravej ceste.

Nerobí transport neusporiadaným a neskracuje obnovu po stratenom segmente. Shell, ktorý sa zastaví kvôli časovému limitu opätovného odoslania, sa zastaví aj so zapnutou možnosťou, pretože možnosť sa nikdy nedotkla pravidla poradia.

Zameniť tieto dve je ľahké, pretože obe sa opisujú ako opravy latencie. Jedna odstraňuje umelé čakanie zavedené bufferovaním, druhá by vyžadovala zmeniť to, čo transport garantuje, a to nerobí žiadna možnosť socketu.

Ako porovnávať transporty spravodlivo

Ak to operátor dovolí a obidve služby existujú, porovnajte UDP službu a TCP službu nesúce rovnakú záťaž po tej istej prístupovej ceste k tomu istému serveru. Zmena krajiny, poskytovateľa alebo generácie servera medzi dvoma testami vnáša premennú, ktorá bude dominovať výsledku.

Sledujte zdieľanú pauzu, nie číslo priepustnosti. Niekoľko vnútorných aplikácií zaseknutých spolu počas vonkajšej straty je pozorovanie, ktoré identifikuje blokovanie na začiatku frontu; jedno nižšie číslo rýchlostného testu to nerobí.

Autorizované záznamy na rozhraní tunela a na fyzickom rozhraní čisto oddeľujú obe vrstvy, pretože vnútorné a vonkajšie opätovné odoslania patria rôznym spojeniam s rôznymi sekvenčnými priestormi. Vidieť vnútorné opätovné odoslania, kým vonkajší tok ukazuje medzeru, je priamym dôkazom.

Prechod na UDP odstraňuje extra spoľahlivý tok a necháva vnútornému TCP jeho vlastnú obnovu. Nesľubuje nulovú stratu ani nízku latenciu a nasýtená odosielacia linka, predimenzované fronty alebo problém s MTU budú stále potrebovať opravu. Prevádzka mimo tunela sa nikdy nezdržiava za sekvenčnou medzerou tunela, hoci stále môže trpieť, keď obe cesty zdieľajú jedno preťažené spojenie, a toto spoločné hrdlo si zaslúži vlastné vyšetrovanie namiesto toho, aby sa vkladalo do tohto.