OpenVPN ar TCP: rto_min nenovērš bloķēšanu rindas galvā

Interaktīva čaula pāri tunelim iesalst uz vairākām sekundēm, kamēr notiek faila kopēšana, un pēc tam turpinās tā, it kā nekas nebūtu noticis. Problēma ir tikai lejupielādei, taču arī čaula gaida, un abas atgūstas tajā pašā mirklī. Šis modelis ir vienas uzticamas plūsmas, kas nes daudz sarunu, paraksts, un tas pārdzīvo gandrīz katru noregulējumu, ko cilvēki izmēģina pirmo.

Simptomu vērts lasīt uzmanīgi, jo tas norāda uz mehānismu, nevis iestatījumu: pauze ir kopīga, tāpēc cēlonis ir kopīgs, un kopīgais objekts ir ārējais savienojums. Viss pārējais žurnālā šajā laikā izskatās normāli.

Simptoms: viss apstājas vienlaikus

Divi iekšējie savienojumi, kas iestrēgst kopā, ir pavediens. Lēna lejupielāde un lēna čaula ir atsevišķas TCP sarunas ar atsevišķiem secības numuriem un atsevišķu pārslodzes stāvokli, tāpēc kļūme vienā nedrīkstētu skart otru. Kad tās apstājas vienā ritmā, kaut kas virs tām kārto to baitus.

Tas kaut kas ir tuneļa transporta slānis. TCP režīmā OpenVPN ieraksta iekapsulētās paketes vienā TCP savienojumā pret otru galu, un TCP līgums ir vienas baitu plūsmas piegāde pēc kārtas. Vēlākie baiti netiek nodoti lietotnei pirms trūkstošajiem, neatkarīgi no tā, kurai iekšējai sarunai tie pieder.

Pievērsiet uzmanību tam, ko simptoms nepasaka. Tas nepasaka, ka ceļš ir salauzts, ka serveris ir pārslogots vai ka šifrēšana ir lēna. Tie dod citas formas: vienmērīgi zemu caurlaidspēju, taimautus vai kļūmes, kas skar vienu virzienu. Kopīga pauze, kas beidzas, kad pazudušais segments tiek nosūtīts atkārtoti, ir tieši kārtības efekts.

Viena ārējā baitu plūsma, daudz iekšēju sarunu

Iedomājieties tuneli, kas vienlaikus nes lejupielādi un čaulu. Viens ārējā savienojuma segments pazūd. Nākamie segmenti var nonākt līdz uztverošajam resursdatoram, un uztverošais TCP steks tos apstiprinās, bet nevarēs nodot tālāk, kamēr plaisa nav aizpildīta. Tāpēc OpenVPN nav ko lasīt čaulai, lai gan pašas čaulas baiti ieradās sen.

Tas ir bloķēšana rindas galvā vienā savienojumā, un tai nav vajadzīgs, lai divas lietotnes dalītos iekšējā savienojumā. Tās dala ārējo, un ar to pietiek.

Otrās kārtas efekts to pasliktina. Iekšējais sūtītājs, kas neredz apstiprinājumus, var atkārtoti nosūtīt datus, ko ārējais slānis jau cenšas piegādāt. Šī atkārtotā nosūtīšana kļūst par papildu tuneļa trafiku ceļā, kas tikko pierādīja, ka var zaudēt segmentus, tāpēc atjaunošanas darbs konkurē ar svarīgo atjaunošanu.

Nekas no tā negarantē sabrukumu. Tīrā ceļā ar īsiem turp un atpakaļ laikiem un plašām rindām šis izkārtojums var būt pilnīgi lietojams gadiem. Kļūme parādās, kad zudumi, aizkave un rindas dziļums sakrīt, un tāpēc ziņojumi grupējas ap pārslogotām augšupielādes līnijām un mobilajām saitēm, nevis ap labi nodrošinātām birojiem.

Kāpēc garāks iekšējais taimeris nevar palīdzēt

Mazākā atkārtotās nosūtīšanas laika paaugstināšana maršrutā ar rto_min atliek uz taimeri balstītu atkārtotu nosūtīšanu lokāli radītam TCP trafikam, kas izmanto šo maršrutu. Tas ir īsts kloķis ar īstu efektu, un tas risina otrās kārtas problēmu, nevis pirmo.

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

Ko tas nevar: atbrīvot ārējos baitus ārpus kārtas, atjaunot trūkstošo segmentu ātrāk vai likt attālajam lietotnes serverim pieņemt to pašu taimeri. Uztverošais steks joprojām piegādā pēc kārtas, un sūtītājs tālajā galā joprojām izmanto savus turp un atpakaļ mērījumus.

Tas arī neizslēdz visus citus zudumu atjaunošanas mehānismus. Kur īstens zudums prasa uz taimeri balstītu atjaunošanu, lielāks minimums liek lietotnei gaidīt ilgāk pirms darbības, kas ir pretēji tam, kas vajadzīgs aizkavei jutīgai sesijai.

Fiksēta divpadsmit sekunžu apakšējā robeža parādās šīs tēmas padomos tā, it kā TCP tuneļa esamība to paredzētu. RFC 6298 aprakstītais atkārtotās nosūtīšanas taimeris tiek atvasināts no izmērītā turp un atpakaļ laika ar eksponenciālu atkāpšanos, tāpēc pastāvīga apakšējā robeža ir konkrēta maršruta politikas izvēle, nevis protokola prasība. Piemērota plaši, tā slēpj simptomu un vienlaikus maina atjaunošanu katram plūsmam, ko šis maršruts aptver.

Ko tcp-nodelay dara un ko nedara

Tuneļa opcija, kas izslēdz Nagle stila buferēšanu transporta ligzdā, ir ar šauru mērķi: tā neļauj maziem ierakstiem gaidīt vairāk datu pirms nosūtīšanas. Tas palīdz interaktīvajam trafikam izvairīties no papildu aizkaves citādi veselā ceļā.

Tā nepadara transportu nekārtīgu un nesaīsina atjaunošanu pēc pazuduša segmenta. Čaula, kas apstājas atkārtotās nosūtīšanas taimauta dēļ, apstāsies arī ar ieslēgtu opciju, jo opcija nekad nav aizskārusi kārtības noteikumu.

Abus sajaukt ir viegli, jo abi tiek aprakstīti kā aizkaves labojumi. Viens novērš buferēšanas ieviesto mākslīgo gaidīšanu, otrs prasītu mainīt to, ko transports garantē, un to neveic neviena ligzdas opcija.

Kā godīgi salīdzināt transportus

Ja operators atļauj un abi pakalpojumi pastāv, salīdziniet UDP pakalpojumu un TCP pakalpojumu, kas nes vienu un to pašu darba slodzi pa to pašu piekļuves ceļu uz to pašu serveri. Valsts, pakalpojumu sniedzēja vai servera paaudzes maiņa starp diviem testiem ievieš mainīgo, kas dominēs rezultātā.

Vērojiet kopīgo pauzi, nevis caurlaidspējas skaitli. Vairāku iekšējo lietotņu iestrēgšana kopā ārēja zuduma laikā ir novērojums, kas atpazīst bloķēšanu rindas galvā; viens zemāks ātruma testa skaitlis to nepadara.

Atļautie uztveršanas faili tuneļa saskarnē un fiziskajā saskarnē tīri atdala abus slāņus, jo iekšējās un ārējās atkārtotās nosūtīšanas pieder dažādiem savienojumiem ar dažādām secības telpām. Redzēt iekšējās atkārtotās nosūtīšanas, kamēr ārējā plūsma rāda plaisu, ir tiešs pierādījums.

Pāreja uz UDP noņem papildu uzticamo plūsmu un ļauj iekšējam TCP veikt savu atjaunošanu. Tas nesola nulles zudumus vai zemu aizkavi, un piesātināta augšupielādes līnija, pārāk lielas rindas vai MTU problēma joprojām būs jālabo. Trafiks ārpus tuneļa nekad netiek aizturēts aiz tuneļa secības plaisas, lai gan tas joprojām var ciest, kad abi ceļi dala vienu pārslogotu līniju, un šī kopīgā sašaurinājuma vieta ir pelnījusi savu izmeklēšanu, nevis iesaiņošanu šajā.