OpenVPN preko TCP-a: rto_min ne rješava blokadu na čelu reda

Interaktivna ljuska preko tunela smrzne se na nekoliko sekundi dok traje kopiranje datoteke, a zatim nastavi kao da se ništa nije dogodilo. Problem ima samo preuzimanje, no i ljuska čeka, i oboje se oporave u istom trenutku. Taj je uzorak potpis jednog pouzdanog toka koji nosi mnoge razgovore i preživljava gotovo svako podešavanje koje ljudi prvo isprobaju.

Simptom vrijedi pažljivo pročitati jer upućuje na mehanizam, a ne na postavku: pauza je zajednička, pa je i uzrok zajednički, a zajednički objekt je vanjska veza. Sve ostalo u zapisniku izgleda normalno dok se to događa.

Simptom: sve se zaustavlja istodobno

Dvije unutarnje veze koje se zajedno zaglave su trag. Sporo preuzimanje i spora ljuska odvojeni su TCP razgovori s odvojenim rednim brojevima i odvojenim stanjem zagušenja, pa kvar u jednome ne bi trebao dotaknuti drugi. Kad zastanu u istom ritmu, nešto iznad njih poredava njihove bajtove.

To nešto je transport tunela. U TCP načinu OpenVPN zapisuje inkapsulirane pakete u jednu TCP vezu prema partneru, a ugovor TCP-a je isporuka po redu jednog toka bajtova. Kasniji bajtovi ne predaju se aplikaciji prije manjkavih, bez obzira kojem unutarnjem razgovoru pripadali.

Obratite pozornost na ono što simptom ne kaže. Ne kaže da je put pokvaren, da je poslužitelj preopterećen ili da je šifriranje sporo. Oni daju drukčije oblike: ravnomjerno nisku propusnost, isteke vremena ili kvarove koji pogađaju jedan smjer. Zajednička pauza koja završava kad se izgubljeni segment ponovno pošalje upravo je učinak poretka.

Jedan vanjski tok bajtova, mnogi unutarnji razgovori

Zamislite tunel koji istodobno nosi preuzimanje i ljusku. Jedan segment vanjske veze se izgubi. Sljedeći segmenti mogu stići do prijamnog računala i prijamni TCP stog će ih potvrditi, ali ih ne može predati više dok se praznina ne popuni. Zato OpenVPN nema što čitati za ljusku, iako su bajtovi same ljuske stigli davno.

To je blokada na čelu reda unutar jedne veze i ne zahtijeva da dvije aplikacije dijele unutarnju vezu. One dijele vanjsku, i to je dovoljno.

Učinak drugog reda to pogoršava. Unutarnji pošiljatelj koji ne vidi potvrde može ponovno poslati podatke koje vanjski sloj već pokušava isporučiti. To ponovno slanje postaje dodatni tunelski promet na putu koji je upravo dokazao da može gubiti segmente, pa se rad na oporavku natječe s oporavkom koji je važan.

Ništa od ovoga ne jamči slom. Na čistom putu s kratkim povratnim putovanjima i širokim redovima čekanja taj raspored može godinama biti posve upotrebljiv. Kvar se pojavljuje kad se gubitak, kašnjenje i dubina reda čekanja poklope, i zato se izvještaji skupljaju oko zagušenih uzlaznih veza i mobilnih linkova, a ne oko dobro opremljenih ureda.

Zašto dulji unutarnji mjerač ne može pomoći

Povećanje najkraćeg vremena ponovnog slanja na ruti s rto_min odgađa ponovno slanje na temelju mjerača za lokalno stvoreni TCP promet koji koristi tu rutu. To je pravi gumb s pravim učinkom i rješava problem drugog reda umjesto prvog.

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

Ono što ne može jest osloboditi vanjske bajtove izvan reda, oporaviti manjkavi segment brže ili natjerati udaljeni poslužitelj aplikacije da prihvati isti mjerač. Prijamni stog i dalje isporučuje po redu, a pošiljatelj na udaljenom kraju i dalje koristi svoja mjerenja povratnog puta.

Također ne isključuje sve ostale mehanizme oporavka od gubitka. Gdje pravi gubitak zahtijeva oporavak na temelju mjerača, veći minimum tjera aplikaciju da čeka dulje prije nego što djeluje, što je suprotno od onoga što treba sesija osjetljiva na kašnjenje.

Fiksna donja granica od dvanaest sekundi pojavljuje se u savjetima o ovoj temi kao da je postojanje TCP tunela podrazumijeva. Mjerač ponovnog slanja opisan u RFC 6298 izvodi se iz izmjerenog povratnog vremena s eksponencijalnim uzmicanjem, pa je stalna donja granica izbor politike za određeni put, a ne zahtjev protokola. Primijenjena široko, skriva simptom dok istodobno mijenja oporavak za svaki tok koji ta ruta pokriva.

Što tcp-nodelay čini i što ne čini

Opcija tunela koja isključuje međuspremanje u stilu Naglea na transportnom utičnici ima usku svrhu: sprječava male zapise da čekaju više podataka prije slanja. To pomaže interaktivnom prometu izbjeći dodatno kašnjenje na inače zdravom putu.

Ona ne čini transport neuređenim i ne skraćuje oporavak nakon izgubljenog segmenta. Ljuska koja zastane zbog isteka vremena ponovnog slanja zastat će i s uključenom opcijom, jer opcija nikada nije dotaknula pravilo poretka.

Lako je zamijeniti jedno s drugim jer se oboje opisuje kao popravci kašnjenja. Jedno uklanja umjetno čekanje koje uvodi međuspremanje, drugo bi zahtijevalo promjenu onoga što transport jamči, a to ne čini nijedna opcija utičnice.

Kako pošteno usporediti transporte

Ako operater to dopušta i obje usluge postoje, usporedite uslugu UDP i uslugu TCP s istim radnim opterećenjem istim putem pristupa prema istom poslužitelju. Promjena zemlje, pružatelja ili generacije poslužitelja između dvaju testova uvodi varijablu koja će dominirati rezultatom.

Pazite na zajedničku pauzu, a ne na broj propusnosti. Nekoliko unutarnjih aplikacija koje se zajedno zaglave tijekom vanjskog gubitka opažanje je koje prepoznaje blokadu na čelu reda; jedan niži broj brzinskog testa to ne čini.

Ovlaštena snimanja na sučelju tunela i na fizičkom sučelju čisto razdvajaju dva sloja, jer unutarnja i vanjska ponovna slanja pripadaju različitim vezama s različitim rednim prostorima. Vidjeti unutarnja ponovna slanja dok vanjski tok pokazuje prazninu izravan je dokaz.

Prelazak na UDP uklanja dodatni pouzdani tok i ostavlja unutarnjem TCP-u da obavi vlastiti oporavak. Ne obećava nula gubitaka ni nisko kašnjenje, a zasićena uzlazna veza, preveliki redovi čekanja ili problem s MTU-om i dalje će trebati popravak. Promet izvan tunela nikada se ne zadržava iza redne praznine tunela, iako još može trpjeti kad oba puta dijele jednu zagušenu vezu, i to zajedničko usko grlo zaslužuje vlastitu istragu umjesto da se savije u ovu.