Interaktiivne kest tunnelis külmub faili kopeerimise ajal mitmeks sekundiks ja jätkab siis, nagu poleks midagi juhtunud. Probleem on ainult allalaadimisel, kuid ka kest ootab, ja mõlemad toibuvad samal hetkel. See muster on ühe usaldusväärse voo, mis kannab palju vestlusi, allkiri, ja see peab vastu peaaegu igale häälestusele, mida inimesed esimesena proovivad.

Sümptomit tasub hoolikalt lugeda, sest see osutab mehhanismile, mitte seadele: paus on ühine, seega on ka põhjus ühine, ja ühine objekt on välimine ühendus. Kõik muu logis näeb selle ajal tavaline välja.

Sümptom: kõik peatub korraga

Kaks sisemist ühendust, mis jäävad koos kinni, on vihje. Aeglane allalaadimine ja aeglane kest on eraldi TCP vestlused eraldi järjekorranumbrite ja eraldi ummikuseisundiga, seega ei tohiks ühe rike teist puudutada. Kui need peatuvad samas rütmis, järjestab miski nende kohal nende baite.

See miski on tunneli transpordikiht. TCP režiimis kirjutab OpenVPN kapseldatud paketid ühte TCP ühendusse partneri poole, ja TCP leping on ühe baidivoo järjekorrapärane kohaletoimetamine. Hilisemad baidid ei jõua rakenduseni enne puuduvaid, olenemata sellest, millisesse sisemisse vestlusesse need kuuluvad.

Pange tähele, mida sümptom ei ütle. See ei ütle, et tee on katki, server on ülekoormatud või krüpteerimine on aeglane. Need annavad teistsuguse kuju: ühtlaselt madal läbilaskevõime, aegumised või tõrked, mis mõjutavad ühte suunda. Ühine paus, mis lõpeb kadunud segmendi kordussaatmisega, on täpselt järjestuse efekt.

Üks välimine baidivoog, palju sisemisi vestlusi

Kujutage ette tunnelit, mis kannab korraga allalaadimist ja kesta. Üks välimise ühenduse segment läheb kaotsi. Järgmised segmendid võivad jõuda vastuvõtvasse hosti ja vastuvõttev TCP pinu kinnitab need, kuid ei saa neid ülespoole edastada enne, kui tühik on täidetud. Seetõttu pole OpenVPN-il kesta jaoks midagi lugeda, kuigi kesta enda baidid jõudsid ammu.

See on blokeering järjekorra alguses ühes ühenduses ja see ei nõua, et kaks rakendust jagaksid sisemist ühendust. Nad jagavad välimist, ja sellest piisab.

Teise järgu efekt teeb selle hullemaks. Sisemine saatja, kes kinnitusi ei näe, võib saata uuesti andmeid, mida välimine kiht juba püüab kohale toimetada. See kordussaatmine muutub lisatunneliliikluseks teel, mis just tõestas, et võib segmente kaotada, seega taastetöö konkureerib olulise taastega.

Miski sellest ei taga kokkuvarisemist. Puhtal teel lühikeste edasi-tagasi aegade ja laiade järjekordadega võib see korraldus olla aastaid täiesti kasutatav. Rike ilmneb siis, kui kadu, viivitus ja järjekorra sügavus langevad kokku, ja seepärast kogunevad aruanded ülekoormatud ülesvoolu liinide ja mobiilsete ühenduste ümber, mitte hästi varustatud kontorite ümber.

Miks pikem sisemine taimer ei saa aidata

Minimaalse kordussaatmise ajalõpu tõstmine marsruudil valikuga rto_min lükkab edasi taimeripõhise kordussaatmise kohalikult tekitatud TCP liikluse jaoks, mis seda marsruuti kasutab. See on tõeline nupp tõelise mõjuga ja see tegeleb teise järgu, mitte esimese probleemiga.

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

Mida see ei saa: vabastada välimisi baite järjekorrast väljas, taastada puuduv segment kiiremini või panna kaugserveri rakendust sama taimerit kasutama. Vastuvõttev pinu toimetab endiselt järjekorras ja kaugema otsa saatja kasutab endiselt oma edasi-tagasi mõõtmisi.

See ei lülita välja ka kõiki muid kao taastamise mehhanisme. Kus tõeline kadu nõuab taimeripõhist taastet, paneb suurem miinimum rakenduse kauem ootama enne tegutsemist, mis on vastupidine sellele, mida vajab viivitusele tundlik seanss.

Fikseeritud kaheteistkümne sekundi alampiir esineb selle teema nõuannetes, nagu eeldaks TCP tunneli olemasolu seda. RFC 6298 kirjeldatud kordussaatmise taimer tuletatakse mõõdetud edasi-tagasi ajast eksponentsiaalse taganemisega, seega on püsiv alampiir konkreetse tee poliitikavalik, mitte protokolli nõue. Laialdaselt rakendatuna varjab see sümptomit ja muudab samal ajal taastet iga voo jaoks, mida see marsruut katab.

Mida tcp-nodelay teeb ja mida mitte

Tunneli valik, mis lülitab transpordi soketil välja Nagle'i stiilis puhverduse, on kitsa eesmärgiga: see takistab väikestel kirjutistel enne saatmist rohkem andmeid oodata. See aitab interaktiivsel liiklusel vältida lisaviivitust muidu tervel teel.

See ei muuda transporti korratuks ega lühenda taastet pärast kadunud segmenti. Kest, mis peatub kordussaatmise ajalõpu tõttu, peatub ka selle valiku sisselülitamisel, sest valik ei puudutanud kunagi järjestuse reeglit.

Neid kahte on lihtne segi ajada, sest mõlemat kirjeldatakse viivituse parandusena. Üks kõrvaldab puhverduse toodud kunstliku ootamise, teine nõuaks selle muutmist, mida transport garanteerib, ja seda ei tee ükski soketi valik.

Kuidas transporti õiglaselt võrrelda

Kui operaator lubab ja mõlemad teenused on olemas, võrrelge UDP teenust ja TCP teenust, mis kannavad sama töökoormust sama juurdepääsuteed mööda samasse serverisse. Riigi, teenusepakkuja või serveri põlvkonna vahetamine kahe testi vahel toob sisse muutuja, mis hakkab tulemust valitsema.

Jälgige ühist pausi, mitte läbilaskevõime numbrit. Mitme sisemise rakenduse koos kinnijäämine välimise kao ajal on vaatlus, mis tuvastab blokeeringu järjekorra alguses; üks madalam kiirustesti number seda ei tee.

Lubatud püüdmised tunneli liidesel ja füüsilisel liidesel eraldavad kaks kihti puhtalt, sest sisemised ja välimised kordussaatmised kuuluvad erinevatesse ühendustesse erinevate järjestusruumidega. Sisemiste kordussaatmiste nägemine, kui välimine voog näitab tühikut, on otsene tõend.

UDP-le üleminek eemaldab täiendava usaldusväärse voo ja jätab sisemisele TCP-le tema enda taaste. See ei tõota nullkadu ega madalat viivitust, ning küllastunud ülesvoolu liin, liiga suured järjekorrad või MTU probleem vajavad endiselt parandamist. Väljaspool tunnelit olev liiklus ei jää kunagi tunneli järjestustühiku taha, kuigi see võib endiselt kannatada, kui mõlemad teed jagavad ühte ülekoormatud liini, ja see ühine kitsaskoht väärib omaette uurimist, mitte siia kokkuvoldimist.

Seotud artiklid