OpenVPN prek TCP: rto_min ne odpravi blokade na začetku čakalne vrste

Interaktivna lupina prek tunela zamrzne za nekaj sekund, medtem ko teče kopiranje datoteke, nato pa se nadaljuje, kot da se ni nič zgodilo. Težavo ima samo prenos, a tudi lupina čaka, in oba si opomoreta v istem trenutku. Ta vzorec je podpis enega samega zanesljivega toka, ki nosi veliko pogovorov, in preživi skoraj vsako nastavitveno spremembo, ki jo ljudje poskusijo najprej.

Simptom si zasluži natančno branje, ker kaže na mehanizem in ne na nastavitev: premor je skupen, torej je vzrok skupen, skupni objekt pa je zunanja povezava. Vse drugo v dnevniku je med tem videti normalno.

Simptom: vse se ustavi hkrati

Dve notranji povezavi, ki se zatakneta skupaj, sta namig. Počasen prenos in počasna lupina sta ločena TCP pogovora z ločenimi zaporednimi številkami in ločenim stanjem zastoja, zato se napaka v enem ne bi smela dotakniti drugega. Ko se ustavita v enakem ritmu, nekaj nad njima ureja njune bajte.

To nekaj je transport tunela. V načinu TCP OpenVPN zapiše zapakirane pakete v eno samo TCP povezavo do nasprotnega vozlišča, pogodba TCP pa je dostava po vrsti enega samega bajtnega toka. Poznejši bajti se aplikaciji ne predajo pred manjkajočimi, ne glede na to, kateremu notranjemu pogovoru pripadajo.

Bodite pozorni, česa simptom ne pove. Ne pove, da je pot pokvarjena, da je strežnik preobremenjen ali da je šifriranje počasno. Ti dajo drugačne oblike: enakomerno nizko prepustnost, časovne omejitve ali napake, ki prizadenejo eno smer. Skupni premor, ki se konča, ko se izgubljeni segment ponovno pošlje, je posebej učinek urejanja.

En zunanji bajtni tok, veliko notranjih pogovorov

Predstavljajte si tunel, ki hkrati nosi prenos in lupino. En segment zunanje povezave se izgubi. Naslednji segmenti lahko prispejo do prejemnega gostitelja in prejemni sklad TCP jih bo potrdil, ne more pa jih dostaviti navzgor, dokler vrzel ni zapolnjena. OpenVPN torej nima česa brati za lupino, čeprav so bajti same lupine prispeli že davno.

To je blokada na začetku čakalne vrste znotraj ene povezave in ne zahteva, da si dve aplikaciji delita notranjo povezavo. Delita si zunanjo, in to je dovolj.

Učinek drugega reda ga poslabša. Notranji pošiljatelj, ki ne vidi potrditev, lahko znova pošlje podatke, ki jih zunanji sloj že poskuša dostaviti. To ponovno pošiljanje postane dodatni tunelski promet na poti, ki je pravkar dokazala, da lahko izgublja segmente, zato obnovitveno delo tekmuje z obnovo, ki je pomembna.

Nič od tega ne zagotavlja zloma. Na čisti poti s kratkimi povratnimi časi in velikodušnimi čakalnimi vrstami je ureditev lahko vrsto let povsem uporabna. Napaka se pokaže, ko se izguba, zakasnitev in globina čakalne vrste poravnajo, zato se poročila kopičijo okoli preobremenjenih navzgornjih povezav in mobilnih povezav, ne pa okoli dobro opremljenih pisarn.

Zakaj daljši notranji časovnik ne more pomagati

Dvig najkrajšega čakalnega časa za ponovno pošiljanje na poti z rto_min odloži ponovno pošiljanje na podlagi časovnika za lokalno ustvarjen TCP promet, ki uporablja to pot. To je resničen gumb z resničnim učinkom in obravnava problem drugega reda namesto prvega.

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

Česar ne more: sprostiti zunanjih bajtov zunaj vrstnega reda, hitreje obnoviti manjkajoči segment ali pripraviti oddaljeni aplikacijski strežnik, da prevzame isti časovnik. Prejemni sklad še vedno dostavlja po vrsti, pošiljatelj na drugem koncu pa še vedno uporablja svoje lastne meritve povratnega časa.

Prav tako ne izklopi vseh drugih mehanizmov za obnovo po izgubi. Kjer resnična izguba zahteva obnovo na podlagi časovnika, večji minimum povzroči, da aplikacija čaka dlje, preden ukrepa, kar je nasprotje tega, kar potrebuje seja, občutljiva na zakasnitev.

Fiksna spodnja meja dvanajstih sekund se pojavlja v nasvetih o tej temi, kot da bi obstoj TCP tunela to impliciral. Časovnik ponovnega pošiljanja, opisan v RFC 6298, izhaja iz izmerjenega povratnega časa z eksponentnim umikom, zato je stalna spodnja meja izbira politike za določeno pot in ne zahteva protokola. Široko uporabljena skrije simptom, hkrati pa spremeni obnovo za vsak tok, ki ga pot pokriva.

Kaj tcp-nodelay počne in česa ne

Možnost tunela, ki izklopi medpomnjenje v slogu Nagle na transportnem vtiču, ima ozek namen: prepreči, da bi majhni zapisi čakali na več podatkov pred pošiljanjem. To pomaga interaktivnemu prometu, da se na sicer zdravi poti izogne dodatni zakasnitvi.

Transporta ne spremeni v neurejenega in ne skrajša obnove po izgubljenem segmentu. Lupina, ki se ustavi zaradi čakalnega časa ponovnega pošiljanja, se bo ustavila tudi z vklopljeno možnostjo, ker se možnost ni nikoli dotaknila pravila vrstnega reda.

Dve stvari je lahko zamenjati, ker sta obe opisani kot popravka zakasnitve. Ena odpravi umetno čakanje, ki ga je vneslo medpomnjenje, druga bi zahtevala spremembo tega, kar transport zagotavlja, in tega ne stori nobena vtična možnost.

Kako pošteno primerjati transporte

Če operater dovoli in obe storitvi obstajata, primerjajte storitev UDP in storitev TCP z enako obremenitvijo po isti dostopni poti do istega strežnika. Menjava države, ponudnika ali generacije strežnika med dvema testoma vnese spremenljivko, ki bo prevladala v rezultatu.

Opazujte skupni premor, ne števila prepustnosti. Več notranjih aplikacij, ki se med zunanjo izgubo zataknejo skupaj, je opazovanje, ki prepozna blokado na začetku čakalne vrste; ena sama nižja številka hitrostnega testa tega ne stori.

Dovoljeni zajemi na vmesniku tunela in na fizičnem vmesniku čisto ločijo oba sloja, ker notranja in zunanja ponovna pošiljanja pripadajo različnim povezavam z različnimi zaporednimi prostori. Videti notranja ponovna pošiljanja, medtem ko zunanji tok kaže vrzel, je neposreden dokaz.

Prehod na UDP odstrani dodatni zanesljivi tok in pusti notranjemu TCP, da opravi svojo obnovo. Ne obljublja ničelne izgube ali nizke zakasnitve, nasičena navzgornja povezava, predimenzionirane čakalne vrste ali težava z MTU pa bodo še vedno zahtevale popravek. Promet zunaj tunela ni nikoli zadržan za zaporedno vrzeljo tunela, čeprav lahko še vedno trpi, ko si obe poti delita eno preobremenjeno povezavo, in to skupno ozko grlo si zasluži lastno preiskavo, namesto da bi bilo zloženo v to.