OpenVPN përmes TCP: rto_min nuk e rregullon bllokimin në krye të radhës

Një shell interaktiv përmes tunelit ngrin për disa sekonda ndërsa ekzekutohet një kopjim skedari, dhe pastaj vazhdon sikur të mos kishte ndodhur asgjë. Shkarkimi është i vetmi me problem, megjithatë edhe shell-i pret, dhe të dyja rikuperohen në të njëjtin moment. Ky model është nënshkrimi i një rrjedhe të vetme të besueshme që mban shumë biseda, dhe i mbijeton pothuajse çdo ndryshimi akordimi që njerëzit provojnë së pari.

Simptoma meriton lexim të kujdesshëm sepse tregon një mekanizëm dhe jo një cilësim: pauza është e përbashkët, pra shkaku është i përbashkët, dhe objekti i përbashkët është lidhja e jashtme. Gjithçka tjetër në regjistër duket normale gjatë kësaj kohe.

Simptoma: gjithçka ndalon njëkohësisht

Dy lidhje të brendshme që ngecin bashkë janë të dhëna. Një shkarkim i ngadalshëm dhe një shell i ngadalshëm janë biseda TCP të ndara me numra sekuence të ndarë dhe gjendje kongjestioni të ndara, kështu që një defekt në njërën nuk duhet të prekë tjetrën. Kur ndalojnë në të njëjtin ritëm, diçka mbi to po rendit bajtët e tyre.

Ajo diçka është transporti i tunelit. Në modalitetin TCP, OpenVPN i shkruan paketat e inkapsuluara në një lidhje të vetme TCP drejt peer-it, dhe kontrata e TCP-së është dorëzimi sipas radhës i një rrjedhe të vetme bajtesh. Bajtët e mëvonshëm nuk i dorëzohen aplikacionit para atyre që mungojnë, pavarësisht se cilës bisedë të brendshme i përkasin.

Vini re se çfarë nuk thotë simptoma. Nuk thotë që rruga është e prishur, që serveri është i mbingarkuar ose që kriptimi është i ngadalshëm. Ato prodhojnë forma të ndryshme: xhiro uniformisht të ulët, skadime kohe ose dështime që prekin një drejtim. Një pauzë e përbashkët që përfundon kur një segment i humbur ritransmetohet është specifikisht një efekt renditjeje.

Një rrjedhë e jashtme bajtesh, shumë biseda të brendshme

Imagjinoni tunelin që mban njëkohësisht një shkarkim dhe një shell. Një segment i lidhjes së jashtme humbet. Segmentet pasardhëse mund të arrijnë në hostin pritës, dhe stiva TCP pritëse do t'i pranojë ato, por nuk mund t'i dorëzojë lart derisa hendeku të mbushet. Prandaj OpenVPN nuk ka asgjë për të lexuar për shell-in, edhe pse bajtët e vetë shell-it arritën shumë kohë më parë.

Ky është bllokim në krye të radhës brenda një lidhjeje, dhe nuk kërkon që dy aplikacionet të ndajnë një lidhje të brendshme. Ato ndajnë atë të jashtmen, dhe kjo mjafton.

Efekti i rendit të dytë e përkeqëson. Një dërgues i brendshëm që nuk sheh pranime mund të ritransmetojë të dhëna që shtresa e jashtme po përpiqet tashmë t'i dorëzojë. Ai ritransmetim bëhet trafik shtesë tuneli në një rrugë që sapo provoi se mund të humbasë segmente, kështu që puna e rikuperimit konkurron me rikuperimin që ka rëndësi.

Asgjë nga kjo nuk garanton një shembje. Në një rrugë të pastër me kohë të shkurtra vajtje-ardhjeje dhe radhë bujare, rregullimi mund të jetë plotësisht i përdorshëm për vite. Dështimi shfaqet kur humbja, vonesa dhe thellësia e radhës përputhen, dhe për këtë arsye raportet grumbullohen rreth lidhjeve lart të mbingarkuara dhe lidhjeve celulare, jo rreth zyrave të pajisura mirë.

Pse një kohëmatës i brendshëm më i gjatë nuk mund të ndihmojë

Ngritja e kohës minimale të ritransmetimit në një rrugë, me rto_min, shtyn ritransmetimin e bazuar në kohëmatës për trafikun TCP të prodhuar lokalisht që përdor atë rrugë. Është një çelës i vërtetë me efekt të vërtetë, dhe trajton problemin e rendit të dytë në vend të të parit.

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

Ajo që nuk mund të bëjë është të lëshojë bajtë të jashtëm jashtë radhe, të rikuperojë segmentin që mungon më shpejt ose ta bëjë serverin e aplikacionit në distancë të miratojë të njëjtin kohëmatës. Stiva pritëse dorëzon përsëri sipas radhës, dhe dërguesi në skajin e largët përdor përsëri matjet e veta të vajtjes-ardhjes.

Nuk çaktivizon as të gjithë mekanizmat e tjerë të rikuperimit të humbjeve. Aty ku humbja e vërtetë kërkon rikuperim të bazuar në kohëmatës, një minimum më i madh e bën aplikacionin të presë më gjatë para se të veprojë, që është e kundërta e asaj që i nevojitet një sesioni të ndjeshëm ndaj vonesës.

Një dysheme fikse prej dymbëdhjetë sekondash shfaqet në këshillat për këtë temë, sikur ekzistenca e një tuneli TCP ta nënkuptonte atë. Kohëmatësi i ritransmetimit i përshkruar në RFC 6298 rrjedh nga koha e matur e vajtjes-ardhjes me tërheqje eksponenciale, kështu që një dysheme konstante është një zgjedhje politike për një rrugë të caktuar dhe jo një kërkesë e protokollit. E zbatuar gjerësisht, fsheh simptomën duke ndryshuar rikuperimin për çdo rrjedhë që mbulon ajo rrugë.

Çfarë bën dhe çfarë nuk bën tcp-nodelay

Opcioni i tunelit që çaktivizon buferimin e stilit Nagle në socketin e transportit ka një qëllim të ngushtë: ndalon shkrimet e vogla të presin më shumë të dhëna përpara transmetimit. Kjo i ndihmon trafikut interaktiv të shmangë një vonesë shtesë në një rrugë përndryshe të shëndetshme.

Nuk e kthen transportin në një pa rend, dhe nuk e shkurton rikuperimin pas një segmenti të humbur. Një shell që ndalon për një skadim kohe ritransmetimi do të ndalet përsëri me atë opsion të aktivizuar, sepse opcioni nuk e preku kurrë rregullin e renditjes.

Të ngatërrosh të dyja është e lehtë sepse të dyja përshkruhen si rregullime vonese. Njëra heq një pritje artificiale të futur nga buferimi, tjetra do të kërkonte ndryshimin e asaj që garanton transporti, dhe këtë nuk e bën asnjë opsion socketi.

Si të krahasojmë transportet me drejtësi

Nëse operatori e lejon dhe të dy shërbimet ekzistojnë, krahasoni një shërbim UDP dhe një shërbim TCP që mbajnë të njëjtën ngarkesë në të njëjtën rrugë aksesi drejt të njëjtit server. Ndryshimi i vendit, ofruesit ose gjeneratës së serverit mes dy testeve fut një variabël që do të dominojë rezultatin.

Shikoni pauzën e përbashkët dhe jo një shifër xhiroje. Disa aplikacione të brendshme që ngecin bashkë gjatë humbjes së jashtme është vëzhgimi që identifikon bllokimin në krye të radhës; një shifër e vetme më e ulët e testit të shpejtësisë nuk e bën këtë.

Kapjet e autorizuara në ndërfaqen e tunelit dhe në ndërfaqen fizike i ndajnë pastër të dy shtresat, sepse ritransmetimet e brendshme dhe të jashtme u përkasin lidhjeve të ndryshme me hapësira sekuence të ndryshme. Të shohësh ritransmetime të brendshme ndërsa rrjedha e jashtme tregon një hendek është prova e drejtpërdrejtë.

Kalimi në UDP heq rrjedhën shtesë të besueshme dhe e lë TCP-në e brendshme të bëjë rikuperimin e vet. Nuk premton humbje zero ose vonesë të ulët, dhe një lidhje lart e ngopur, radhë të mëdha ose një problem MTU do të kenë ende nevojë për rregullim. Trafiku jashtë tunelit nuk mbahet kurrë pas hendekut të sekuencës së tunelit, edhe pse mund të vuajë ende kur të dyja rrugët ndajnë një lidhje të mbingarkuar, dhe ai pengesë e përbashkët meriton hetimin e vet në vend që të paloset në këtë.