OpenVPN gegnum TCP: rto_min lagar ekki stíflun fremst í biðröð

Gagnvirkt skel yfir göngunum frýs í nokkrar sekúndur meðan afritun skráar stendur yfir og heldur síðan áfram eins og ekkert hafi gerst. Niðurhalið er eina vandamálið, en skelið bíður líka, og bæði jafna sig á sama augnabliki. Þetta mynstur er undirskrift einnar áreiðanlegrar straums sem ber margar samræður, og það lifir af nánast hverja stillingu sem fólk prófar fyrst.

Einkennin eru þess virði að lesa vel því þau benda á verkun og ekki stillingu: hléið er sameiginlegt, svo orsökin er sameiginleg, og sameiginlegi hluturinn er ytri tengingin. Allt annað í annálnum lítur eðlilega út á meðan.

Einkennin: allt stöðvast á sama tíma

Tvær innri tengingar sem stíflast saman eru vísbendingin. Hægt niðurhal og hægt skel eru aðskildar TCP samræður með aðskildum raðnúmerum og aðskildu stíflustigi, svo bilun í annarri ætti ekki að snerta hina. Þegar þau stöðvast í takt raðar eitthvað yfir þeim bætunum þeirra.

Það eitthvað er flutningslag göngunnar. Í TCP ham skrifar OpenVPN umbúðuðu pakkana í eina TCP tengingu til jafningjans, og samningur TCP er afhending eins bætastreymis í röð. Seinni bætur eru ekki afhentar forritinu fyrir þær sem vantar, hvaða innri samræðu sem þær tilheyra.

Takið eftir því sem einkennin segja ekki. Þau segja ekki að leiðin sé brotin, að þjónninn sé ofhlaðinn eða að dulkóðunin sé hæg. Þau gefa aðra lögun: jafnt lágt afköst, tímamörk eða bilanir sem snerta eina átt. Sameiginlegt hlé sem endar þegar týndu sýnishorni er endursent er einmitt raðverkun.

Einn ytri bætastreymur, margar innri samræður

Ímyndið ykkur göngin bera niðurhal og skel á sama tíma. Eitt sýnishorn ytri tengingarinnar tapast. Næstu sýnishorn geta náð til móttökuhýsisins og TCP staflinn þar staðfestir þau, en getur ekki afhent þau upp fyrr en bilið er fyllt. Því hefur OpenVPN ekkert að lesa fyrir skelið, þótt bætur skelsins sjálfs hafi komið fyrir löngu.

Þetta er stíflun fremst í biðröð innan einnar tengingar, og hún krefst ekki að forritin tvö deili innri tengingu. Þau deila þeirri ytri, og það nægir.

Áhrif af annarri gráðu gera það verra. Innri sendandi sem sér engar staðfestingar getur endursent gögn sem ytra lagið er þegar að reyna að afhenda. Sú endursending verður aukinn gangatrafik á leið sem rétt hefur sannað að hún getur tapað sýnishornum, svo batavinnan keppir við batann sem skiptir máli.

Ekkert af þessu tryggir hrun. Á hreinni leið með stuttum ferðum og rúmgóðum biðröðum getur þessi uppsetning verið fullkomlega nothæf í mörg ár. Bilunin kemur fram þegar tap, seinkun og dýpt biðraðar falla saman, og þess vegna hópast skýrslurnar um þrengdar uppstreymisleiðir og farsímaleiðir en ekki um vel búin skrifstofur.

Hvers vegna lengri innri tímastilli getur ekki hjálpað

Hækkun lágmarks endursendingartíma á leið með rto_min seinkar tímastilldri endursendingu fyrir staðbundið myndað TCP umferð sem notar þá leið. Það er raunverulegur hnappur með raunveruleg áhrif, og hann tekur á vandamáli annarrar gráðu í stað hins fyrsta.

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

Það sem hann getur ekki er að sleppa ytri bætum úr röð, endurheimta týnda sýnishornið hraðar eða fá fjartengda forritsbjóninn til að taka sama tímastilla. Móttökustaflinn afhendir áfram í röð, og sendandinn í hinum endanum notar áfram sínar eigin ferðamælingar.

Hann slökkvir heldur ekki á öllum öðrum bataverkum vegna taps. Þar sem raunverulegt tap krefst tímastilldrar endurheimtar lætur stærra lágmark forritið bíða lengur áður en það bregst við, sem er andstæðan við það sem seinkunarnæm seta þarf.

Föst tólf sekúndna gólf birtast í ráðleggingum um þetta efni eins og tilvist TCP ganga gefi þau í skyn. Endursendingartímastillinn sem lýst er í RFC 6298 er leiddur af mældum ferðatíma með veldisvísis afturhvarfi, svo stöðugt gólf er stefnuval fyrir tiltekna leið en ekki krafa samskiptareglna. Notað vítt felur það einkennin en breytir samt bata fyrir hvert flæði sem leiðin nær yfir.

Hvað tcp-nodelay gerir og gerir ekki

Valkosturinn sem slekkur á Nagle-stíls biðminni á flutningssokki hefur þröngan tilgang: hann kemur í veg fyrir að litlar skrifanir bíði meiri gagna fyrir sendingu. Það hjálpar gagnvirkri umferð að forðast auka seinkun á annars heilbrigðri leið.

Hann gerir flutninginn ekki óraðaðan og styttir ekki batann eftir týnt sýnishorn. Skel sem stöðvast vegna endursendingartímamarka stöðvast áfram með valkostinn kveiktan, því valkosturinn snerti aldrei raðregluna.

Auðvelt er að rugla saman þessu tvennu því bæði eru lýst sem seinkunarlagfæringum. Annað fjarlægir gervilega bið sem biðminnið innleiddi, hitt þyrfti að breyta því sem flutningurinn tryggir, og það gerir enginn sokki valkostur.

Hvernig bera á saman flutningum á sanngjarnan hátt

Ef stjórnandinn leyfir og báðar þjónustur eru til, berið saman UDP þjónustu og TCP þjónustu sem bera sama vinnuálag á sömu aðgangsleið til sama þjóns. Að skipta um land, veitanda eða kynslóð þjóns milli tveggja prófana setur inn breytu sem mun ráða niðurstöðunni.

Fylgist með sameiginlega hléinu frekar en afkastatölu. Nokkur innri forrit sem stíflast saman meðan ytra tap stendur yfir er sú athugun sem greinir stíflun fremst í biðröð; ein lægri hraðaprófstala gerir það ekki.

Heimilaðar tökuur á gönguviðmóti og á eðlisfræðilegu viðmóti aðskilja lögin tvö skýrt, því innri og ytri endursendingar tilheyra ólíkum tengingum með ólíkum raðrúmum. Að sjá innri endursendingar meðan ytri straumurinn sýnir bil er bein sönnun.

Að skipta yfir í UDP fjarlægir auka áreiðanlegu strauminn og lætur innra TCP sjá um sinn eigin bata. Það lofar ekki núlltapi eða lágri seinkun, og mettuð uppstreymisleið, of stórar biðraðir eða MTU vandamál þurfa enn að lagast. Umferð fyrir utan göngin er aldrei haldið aftur af raðbili ganganna, þótt hún geti enn þjáðst þegar báðar leiðir deila einni þrengdri tengingu, og sá sameiginlegi flöskuháls á skilið eigin rannsókn frekar en að vera brotinn inn í þessa.