OpenVPN per TCP: rto_min ne riparas la blokadon ĉe la kapo de la atendovico

Interaga ŝelo super la tunelo frostas dum pluraj sekundoj dum dosierkopio funkcias, poste daŭrigas kvazaŭ nenio okazus. Nur la elŝuto havas problemon, tamen ankaŭ la ŝelo atendas, kaj ambaŭ resaniĝas en la sama momento. Tiu modelo estas la subskribo de unu fidinda fluo, kiu portas multajn konversaciojn, kaj ĝi travivas preskaŭ ĉiun agordon, kiun homoj unue provas.

Indas legi la simpton atente, ĉar ĝi montras mekanismon, ne agordon: la paŭzo estas komuna, do la kaŭzo estas komuna, kaj la komuna objekto estas la ekstera konekto. Ĉio alia en la protokolo aspektas normale dum tio okazas.

La simptomo: ĉio haltas samtempe

Du internaj konektoj, kiuj blokiĝas kune, estas la indiko. Malrapida elŝuto kaj malrapida ŝelo estas apartaj TCP-konversacioj kun apartaj sinsekvaj numeroj kaj aparta kongesta stato, do eraro en unu ne devus tuŝi la alian. Kiam ili haltas samritme, io super ili ordigas iliajn bajtojn.

Tiu io estas la transporta tavolo de la tunelo. En TCP-reĝimo OpenVPN skribas la enkapsulitajn pakojn en unu TCP-konekton al la samtavolano, kaj la kontrakto de TCP estas la laŭorda livero de unu bajtfluo. Postaj bajtoj ne estas transdonitaj al la aplikaĵo antaŭ la mankantaj, al kiu ajn interna konversacio ili apartenas.

Rimarku, kion la simptomo ne diras. Ĝi ne diras, ke la vojo estas rompita, ke la servilo estas troloĝata aŭ ke la ĉifrado estas malrapida. Tiuj donas aliajn formojn: egale malaltan trapon, templimojn aŭ paneojn, kiuj efikas al unu direkto. Komuna paŭzo, kiu finiĝas kiam perdita segmento estas resendita, estas specife ordiga efiko.

Unu ekstera bajtfluo, multaj internaj konversacioj

Imagu la tunelon portanta samtempe elŝuton kaj ŝelon. Unu segmento de la ekstera konekto perdiĝas. La sekvaj segmentoj povas atingi la ricevan gastiganton, kaj la riceva TCP-stako konfirmos ilin, sed ĝi ne povas transdoni ilin supren ĝis la breĉo pleniĝos. Tial OpenVPN havas nenion por legi por la ŝelo, kvankam la bajtoj de la ŝelo mem alvenis longe antaŭe.

Ĉi tio estas blokado ĉe la kapo de la atendovico ene de unu konekto, kaj ĝi ne postulas, ke la du aplikaĵoj kunhavu internan konekton. Ili kunhavas la eksteran, kaj tio sufiĉas.

La efiko de la dua ordo plimalbonigas ĝin. Interna sendanto, kiu vidas neniujn konfirmojn, povas resendi datumojn, kiujn la ekstera tavolo jam provas liveri. Tiu resendo fariĝas plia tunela trafiko sur vojo, kiu ĵus pruvis, ke ĝi povas perdi segmentojn, do la riparlaboro konkurencas kun la riparo, kiu gravas.

Nenio el tio garantias kolapson. Sur pura vojo kun mallongaj vojaĝoj tien kaj reen kaj larĝaj atendovicoj tiu aranĝo povas esti tute uzebla dum jaroj. La paneo aperas, kiam perdo, prokrasto kaj profundo de la atendovico koincidas, kaj tial la raportoj amasiĝas ĉirkaŭ troŝarĝitaj suprenligoj kaj movaj ligoj kaj ne ĉirkaŭ bone ekipitaj oficejoj.

Kial pli longa interna tempigilo ne povas helpi

Altigo de la minimuma resenda templimo sur vojo per rto_min prokrastas la tempigilan resendon por loke generita TCP-trafiko, kiu uzas tiun vojon. Ĝi estas reala tenilo kun reala efiko, kaj ĝi traktas la problemon de la dua ordo anstataŭ la unua.

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

Kion ĝi ne povas: liberigi eksterajn bajtojn ekster ordo, pli rapide ripari la mankantan segmenton aŭ igi la distancan aplikaĵservilon alpreni la saman tempigilon. La riceva stako daŭre liveras laŭorde, kaj la sendanto ĉe la malproksima fino daŭre uzas siajn proprajn mezurojn de la vojaĝo tien kaj reen.

Ĝi ankaŭ ne malŝaltas ĉiujn aliajn mekanismojn de perdo-riparo. Kie reala perdo postulas tempigilan riparon, pli granda minimumo igas la aplikaĵon atendi pli longe antaŭ ol agi, kio estas la malo de tio, kion bezonas latenc-sentema sesio.

Fiksa planko de dek du sekundoj aperas en konsiloj pri ĉi tiu temo kvazaŭ la ekzisto de TCP-tunelo ĝin implicus. La resenda tempigilo priskribita en RFC 6298 estas derivita el mezurita vojaĝtempo kun eksponenta retroiro, do konstanta planko estas politika elekto por specifa vojo kaj ne postulo de la protokolo. Aplikita vaste, ĝi kaŝas la simptonon dum ĝi ŝanĝas la riparon por ĉiu fluo, kiun tiu vojo kovras.

Kion faras kaj kion ne faras tcp-nodelay

La tunela opcio, kiu malŝaltas Nagle-stilan bufradon sur la transporta poŝo, havas mallarĝan celon: ĝi malhelpas etajn skribojn atendi pli da datumoj antaŭ sendo. Tio helpas interagan trafikon eviti plian prokraston sur alie sana vojo.

Ĝi ne faras la transporton senorda kaj ne mallongigas la riparon post perdita segmento. Ŝelo, kiu haltas pro resenda templimo, haltos ankaŭ kun tiu opcio ŝaltita, ĉar la opcio neniam tuŝis la ordigan regulon.

Facilas konfuzi la du, ĉar ambaŭ estas priskribitaj kiel latencaj riparoj. Unu forigas artefaritan atendo, kiun enkondukis bufrado, la alia postulus ŝanĝi tion, kion garantias la transporto, kaj tion faras neniu poŝa opcio.

Kiel justa kompari transportojn

Se la operatoro permesas kaj ambaŭ servoj ekzistas, komparu UDP-servon kaj TCP-servon portantajn la saman laborŝarĝon laŭ la sama alirvojo al la sama servilo. Ŝanĝo de lando, provizanto aŭ generacio de servilo inter la du testoj enkondukas variablon, kiu dominos la rezulton.

Rigardu la komunan paŭzon, ne trapokvanton. Pluraj internaj aplikaĵoj blokiĝantaj kune dum ekstera perdo estas la observo, kiu identigas la blokadon ĉe la kapo de la atendovico; unu pli malalta rapidtesta nombro ne faras tion.

Permesitaj kaptaĵoj sur la tunela interfaco kaj sur la fizika interfaco klare apartigas la du tavolojn, ĉar internaj kaj eksteraj resendoj apartenas al malsamaj konektoj kun malsamaj sinsekvaj spacoj. Vidi internajn resendojn dum la ekstera fluo montras breĉon estas la rekta pruvo.

Transiro al UDP forigas la plian fidindan fluon kaj lasas al la interna TCP fari sian propran riparon. Ĝi ne promesas nulan perdon aŭ malaltan latencion, kaj saturita suprenligo, tro grandaj atendovicoj aŭ MTU-problemo ankoraŭ devos esti riparitaj. Trafiko ekster la tunelo neniam estas tenata malantaŭ la sinsekva breĉo de la tunelo, kvankam ĝi povas ankoraŭ suferi, kiam ambaŭ vojoj kunhavas unu troŝarĝitan ligon, kaj tiu komuna botelkolo meritas sian propran esploron anstataŭ esti faldita en ĉi tion.