OpenVPN oer TCP: rto_min reparearret de blokkade oan de kop fan de rige net

In ynteraktive shell oer de tunnel fretstet in pear sekonden wylst in bestânskopy rint, en giet dan fierder as wie der neat bard. Allinnich de download hat in probleem, dochs wachtet de shell ek, en beide herstelle har op itselde momint. Dat patroan is de hantekening fan ien betroubere stream dy't in protte petearen draacht, en it oerlibbet hast elke oanpassing dy't minsken earst besykje.

It symptoom is it foarsichtich lêzen wurdich, om't it op in meganisme wiist en net op in ynstelling: de pauze is dield, dus is de oarsaak dield, en it dielde objekt is de bûtenste ferbining. Al it oare yn it logboek sjocht der normaal út wylst it bart.

It symptoom: alles pauzelet tagelyk

Twa ynterne ferbiningen dy't tegearre fêst rinne binne de oanwizing. In stadige download en in stadige shell binne aparte TCP-petearen mei aparte folchoardernûmers en aparte oerlêsttastân, dus in flater yn ien soe de oare net reitsje moatte. As se yn deselde pas pauzelet, is der wat boppe har dat har bytes oardert.

Dat wat is de transportlaach fan de tunnel. Yn TCP-modus skriuwt OpenVPN de ynpakte pakketten yn ien TCP-ferbining nei de peer, en it kontrakt fan TCP is levering yn folchoarder fan ien bytestream. Lettere bytes wurde net earder oan de applikaasje jûn as de missende, hokker ynterne petear se ek hearre.

Tink derom wat it symptoom net seit. It seit net dat it paad stikken is, dat de tsjinner tefolle belêste is of dat de fersifering stadich is. Dy jouwe oare foarmen: gelyk lege trochset, tiidferrinnen of flaters dy't ien rjochting reitsje. In dielde pauze dy't einiget as ien ferlern segmint opnij ferstjoerd wurdt, is krekt in oarderings-effekt.

Ien bûtenste bytestream, in protte ynterne petearen

Stel jo de tunnel foar dy't tagelyk in download en in shell draacht. Ien segmint fan 'e bûtenste ferbining rekket ferlern. De folgjende segminten kinne by de ûntfangende host komme, en de ûntfangende TCP-stapel sil se befestigje, mar kin se net omheech leverje oant de kleau fol is. Dêrom hat OpenVPN neat te lêzen foar de shell, ek al binne de bytes fan 'e shell sels lang lyn kommen.

Dit is blokkade oan de kop fan 'e rige binnen ien ferbining, en it easket net dat de twa applikaasjes in ynterne ferbining diele. Se diele de bûtenste, en dat is genôch.

It effekt fan 'e twadde oarder makket it slimmer. In ynterne ferstjoerder dy't gjin befestigingen sjocht, kin gegevens opnij ferstjoere dy't de bûtenste laach al besiket te leverjen. Dy opnij ferstjoering wurdt ekstra tunnelferkear op in paad dat krekt bewiisd hat dat it segminten ferlieze kin, dus it werk fan it herstel konkurrearret mei it herstel dat fan belang is.

Neat hjirfan garandearret in ynstoarting. Op in skjin paad mei koarte hinne-en-wer tiden en romme rijen kin de opstelling jierrenlang prima te brûken wêze. De flater docht him foar as ferlies, fertraging en rigedjipte tegearre komme, en dêrom klustere de rapporten om oerbelêste opgeande ferbiningen en mobile keppelings hinne en net om goed tariste kantoaren.

Wêrom't in langere ynterne timer net helpe kin

It ferheegjen fan 'e minimale opnij-ferstjoertiid op in rûte mei rto_min fertraget timer-basearre opnij ferstjoeren foar lokaal oanmakke TCP-ferkear dat dy rûte brûkt. It is in echte knop mei in echt effekt, en hy pakket it twadde-oardersprobleem oan ynstee fan it earste.

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

Wat er net kin, is bûtenste bytes út 'e folchoarder loslitte, it missende segmint flugger weromkrije of de fiere applikaasje-tsjinner deselde timer oannimme litte. De ûntfangende stapel leveret noch altyd yn folchoarder, en de ferstjoerder oan 'e oare ein brûkt noch altyd syn eigen hinne-en-wer mjittingen.

Hy skeakelet ek net alle oare meganismen foar ferliesherstel út. Dêr't wier ferlies timer-basearre herstel easket, lit in grutter minimum de applikaasje langer wachtsje foar't se hannelt, wat it tsjinoerstelde is fan wat in fertragingsgefoelige sesje nedich hat.

In fêste ûndergrins fan tolve sekonden ferskynt yn advizen oer dit ûnderwerp as soe it bestean fan in TCP-tunnel it ymplisearje. De opnij-ferstjoertimer dy't yn RFC 6298 beskreaun is wurdt ôflaat fan mjitten hinne-en-wer tiid mei eksponinsjele weromgong, dus in konstante ûndergrins is in beliedskeuze foar in beskaat paad en net in eask fan it protokoll. Breed tapast ferberget er it symptoom wylst er it herstel feroaret foar elke stream dy't de rûte beslacht.

Wat tcp-nodelay docht en net docht

De tunnelopsje dy't Nagle-styl buffering op 'e transportsocket útskeakelet, hat in smel doel: it hâldt lytse skriuwen tsjin om op mear gegevens te wachtsjen foar ferstjoering. Dat helpt ynteraktyf ferkear om in ekstra fertraging op in oars sûn paad te mijen.

Hy makket it transport net ûnoardere en ferkoartet it herstel nei in ferlern segmint net. In shell dy't pauzelet foar in opnij-ferstjoertiid sil mei dy opsje oan noch altyd pauzelje, om't de opsje de oarderingsregel nea oanrekke hat.

De twa trochinoar helje is maklik om't beide as fertragingsreparaasjes beskreaun wurde. De iene hellet in keunstmjittige wachttiid wei dy't troch buffering ynbrocht is, de oare soe feroarje moatte wat it transport garandearret, en dat docht gjin inkele socket-opsje.

Hoe't men transporten earlik ferliket

As de operator it tastiet en beide tsjinsten bestean, ferlykje dan in UDP-tsjinst en in TCP-tsjinst dy't deselde wurklêst drage oer itselde tagongspaad nei deselde tsjinner. It wikseljen fan lân, provider of tsjinnergeneraasje tusken de twa tests bringt in fariabele yn dy't it resultaat oerhearskje sil.

Sjoch nei de dielde pauze en net nei in trochsettsifer. Ferskate ynterne applikaasjes dy't tegearre fêst rinne by bûten ferlies is de waarnimming dy't blokkade oan 'e kop fan 'e rige identifisearret; ien legere snelheidstest-wearde docht dat net.

Fergunning-hâldende opnames op 'e tunnelinterface en op 'e fysike interface skiede de twa lagen skjin, om't ynterne en bûtenste opnij ferstjoeringen ta ferskate ferbiningen mei ferskate folchoarderromten hearre. Ynterne opnij ferstjoeringen sjen wylst de bûtenste stream in kleau toant, is it direkte bewiis.

Oerstappen op UDP hellet de ekstra betroubere stream wei en lit it ynterne TCP syn eigen herstel dwaan. It ûnthjit net nul ferlies of lege fertraging, en in sêde opgeande ferbining, te grutte rijen of in MTU-probleem moatte noch reparearre wurde. Ferkear bûten de tunnel wurdt nea efter de folchoarder-kleau fan 'e tunnel holden, al kin it noch lije as beide paden ien oerbelêste keppeling diele, en dy dielde knyppunt fertsjinnet syn eigen ûndersyk ynstee fan hjir yn te folden.