OpenVPN TCP:ssä: rto_min ei korjaa jonon alkuun syntyvää estoa

Interaktiivinen kuori tunnelin yli jäätyy useiksi sekunneiksi tiedostokopion pyöriessä ja jatkaa sitten kuin mitään ei olisi tapahtunut. Vain latauksessa on ongelma, silti myös kuori odottaa, ja molemmat toipuvat samalla hetkellä. Tuo kuvio on yhden luotettavan virran allekirjoitus, kun se kuljettaa monta keskustelua, ja se kestää lähes jokaisen virityksen, jota ihmiset ensin kokeilevat.

Oiretta kannattaa lukea tarkasti, koska se osoittaa mekanismiin eikä asetukseen: tauko on jaettu, joten syy on jaettu, ja jaettu objekti on ulompi yhteys. Muu lokissa näyttää normaalilta sen aikana.

Oire: kaikki pysähtyy yhtä aikaa

Kaksi sisempää yhteyttä, jotka juuttuvat yhdessä, on vihje. Hidas lataus ja hidas kuori ovat erillisiä TCP-keskusteluja, joilla on erilliset sekvenssinumerot ja erillinen ruuhkatila, joten vika toisessa ei saisi koskea toiseen. Kun ne pysähtyvät tahdissa, jokin niiden yläpuolella järjestää niiden tavut.

Se jokin on tunnelin kuljetus. TCP-tilassa OpenVPN kirjoittaa kapseloidut paketit yhteen TCP-yhteyteen vertaiselle, ja TCP:n sopimus on yhden tavuvirran toimittaminen järjestyksessä. Myöhempiä tavuja ei anneta sovellukselle ennen puuttuvia, riippumatta siitä, mihin sisempään keskusteluun ne kuuluvat.

Huomaa, mitä oire ei kerro. Se ei kerro, että polku on rikki, että palvelin on ylikuormitettu tai että salaus on hidasta. Ne tuottavat erilaisia muotoja: tasaisen alhainen läpäisy, aikakatkaisut tai yhden suunnan viat. Jaettu tauko, joka päättyy kadonneen segmentin uudelleenlähetykseen, on nimenomaan järjestysefekti.

Yksi ulompi tavuvirta, monta sisempää keskustelua

Kuvittele, että tunneli kuljettaa latausta ja kuorta samaan aikaan. Ulomman yhteyden segmentti katoaa. Seuraavat segmentit voivat saapua vastaanottavaan koneeseen, ja vastaanottava TCP-pino kuittaa ne, mutta se ei voi toimittaa niitä ylöspäin ennen kuin aukko on täytetty. Siksi OpenVPN:llä ei ole kuorelle mitään luettavaa, vaikka kuoren omat tavut saapuivat kauan sitten.

Tämä on jonon alkuun syntyvä esto yhden yhteyden sisällä, eikä se vaadi, että kaksi sovellusta jakaa sisemmän yhteyden. Ne jakavat ulomman, ja se riittää.

Toisen kertaluvun vaikutus pahentaa sitä. Sisempi lähettäjä, joka ei näe kuittauksia, voi lähettää uudelleen dataa, jota ulompi kerros jo yrittää toimittaa. Siitä uudelleenlähetyksestä tulee lisää tunneliliikennettä polulla, joka juuri osoitti voivansa pudottaa segmenttejä, joten palautustyö kilpailee sen palautuksen kanssa, jolla on merkitystä.

Mikään tästä ei takaa romahdusta. Puhtaalla polulla, jolla on lyhyet edestakaiset ajat ja runsaat jonot, järjestely voi olla täysin käyttökelpoinen vuosia. Vika ilmenee, kun häviö, viive ja jonon syvyys osuvat yhteen, ja siksi raportit keskittyvät ruuhkautuneisiin ylälinkkeihin ja mobiiliyhteyksiin eivätkä hyvin varustettuihin toimistoihin.

Miksi pidempi sisempi ajastin ei voi auttaa

Pienimmän uudelleenlähetysaikakatkaisun nostaminen reitillä rto_min-asetuksella lykkää ajastinpohjaista uudelleenlähetystä paikallisesti syntyvälle TCP-liikenteelle, joka käyttää reittiä. Se on todellinen nuppi, jolla on todellinen vaikutus, ja se käsittelee toisen kertaluvun ongelmaa ensimmäisen sijaan.

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

Sitä se ei voi tehdä: vapauttaa ulompia tavuja järjestyksen ulkopuolelta, palauttaa puuttuvan segmentin nopeammin tai saada kauko-ohjelmapalvelimen omaksumaan sama ajastin. Vastaanottava pino toimittaa edelleen järjestyksessä, ja toisen pään lähettäjä käyttää edelleen omia edestakaisen ajan mittauksiaan.

Se ei myöskään poista käytöstä kaikkia muita häviönpalautusmekanismeja. Kun todellinen häviö vaatii ajastinpohjaista palautusta, suurempi minimi saa sovelluksen odottamaan kauemmin ennen toimintaa, mikä on vastakohta sille, mitä latenssille herkkä istunto tarvitsee.

Kiinteä kahdentoista sekunnin alaraja esiintyy aiheen ohjeissa ikään kuin TCP-tunnelin olemassaolo edellyttäisi sitä. RFC 6298:ssa kuvattu uudelleenlähetysajastin johdetaan mitatusta edestakaisesta ajasta eksponentiaalisella perääntymisellä, joten vakio alaraja on tietyn polun käytäntövalinta eikä protokollavaatimus. Laajasti sovellettuna se kätkee oireen ja muuttaa samalla palautusta jokaiselle virralle, jonka reitti kattaa.

Mitä tcp-nodelay tekee ja mitä ei

Tunneliasetuksella, joka poistaa Nagle-tyylisen puskuroinnin kuljetuspyntistä, on kapea tarkoitus: se estää pieniä kirjoituksia odottamasta lisää dataa ennen lähetystä. Se auttaa interaktiivista liikennettä välttämään ylimääräisen viiveen muuten terveellä polulla.

Se ei tee kuljetuksesta järjestämätöntä eikä lyhennä palautusta kadonneen segmentin jälkeen. Kuori, joka pysähtyy uudelleenlähetysaikakatkaisun ajaksi, pysähtyy edelleen, vaikka asetus on päällä, koska asetus ei koskaan koskenut järjestyssääntöä.

Kahden sekoittaminen on helppoa, koska molempia kuvataan latenssikorjauksina. Toinen poistaa puskuroinnin tuoman keinotekoisen odotuksen, toinen vaatisi sen muuttamista, mitä kuljetus takaa, eikä sitä tee mikään pistokeasetus.

Miten kuljetuksia verrataan reilusti

Jos operaattori sallii sen ja molemmat palvelut ovat olemassa, vertaa UDP-palvelua ja TCP-palvelua, jotka kuljettavat saman työkuorman samaa palvelinta kohti samalla liityntäpolulla. Maan, palveluntarjoajan tai palvelinsukupolven vaihtaminen testien välillä tuo mukanaan muuttujan, joka hallitsee tulosta.

Tarkkaile jaettua taukoa äläkä läpäisylukua. Useiden sisempien sovellusten juuttuminen yhteen ulomman häviön aikana on havainto, joka tunnistaa jonon alkuun syntyvän eston; yksi matalampi nopeustestiluku ei sitä tee.

Valtuutetut kaappaukset tunneliliitännässä ja fyysisessä liitännässä erottavat kaksi kerrosta puhtaasti, koska sisemmät ja ulommat uudelleenlähetykset kuuluvat eri yhteyksiin, joilla on eri sekvenssiavauudet. Sisempien uudelleenlähetysten näkeminen, kun ulompi virta näyttää aukon, on suora todiste.

UDP:hen siirtyminen poistaa ylimääräisen luotettavan virran ja jättää sisemmän TCP:n tekemään oman palautuksensa. Se ei lupaa nollahäviötä tai matalaa latenssia, ja kyllästynyt ylälinkki, ylisuuret jonot tai MTU-ongelma on silti korjattava. Tunnelin ulkopuolinen liikenne ei koskaan jää tunnelin sekvenssiaukon taakse, vaikka se voi silti kärsiä, kun molemmat polut jakavat yhden ruuhkautuneen linkin, ja tuo jaettu pullonkaula ansaitsee oman tutkintansa sen sijaan, että se taitettaisiin tähän.