OpenVPN over TCP: rto_min løser ikke blokkeringen ved starten av køen

Et interaktivt skall over tunnelen fryser i flere sekunder mens en filkopiering kjører, og fortsetter deretter som om ingenting hadde skjedd. Nedlastingen er det eneste med et problem, likevel venter skallet også, og begge kommer seg i samme øyeblikk. Det mønsteret er signaturen til én pålitelig strøm som bærer mange samtaler, og det overlever nesten enhver justering folk prøver først.

Symptomet er verdt å lese nøye fordi det peker på en mekanisme og ikke på en innstilling: pausen er delt, så årsaken er delt, og det delte objektet er den ytre forbindelsen. Alt annet i loggen ser normalt ut mens det skjer.

Symptomet: alt stanser på samme tid

To indre forbindelser som stopper sammen, er ledetråden. En treg nedlasting og et tregt skall er separate TCP-samtaler med separate sekvensnumre og separat overbelastningstilstand, så en feil i den ene bør ikke berøre den andre. Når de stopper i takt, er det noe over dem som ordner bytene deres.

Det noe er tunnelens transport. I TCP-modus skriver OpenVPN de innkapslede pakkene i én TCP-forbindelse til peeren, og TCPs kontrakt er levering i rekkefølge av én enkelt bytestrøm. Senere byter gis ikke til applikasjonen før de manglende, uansett hvilken indre samtale de hører til.

Legg merke til hva symptomet ikke sier. Det sier ikke at veien er brutt, at serveren er overbelastet, eller at chifferet er tregt. De gir andre former: jevnt lav gjennomstrømning, tidsavbrudd eller feil som rammer én retning. En delt pause som slutter når et tapt segment sendes på nytt, er nettopp en ordningseffekt.

Én ytre bytestrøm, mange indre samtaler

Se for deg tunnelen som bærer en nedlasting og et skall samtidig. Et segment av den ytre forbindelsen går tapt. De følgende segmentene kan nå den mottakende verten, og den mottakende TCP-stakken bekrefter dem, men den kan ikke levere dem oppover før hullet er fylt. OpenVPN har derfor ingenting å lese for skallet, selv om skallets egne byter kom for lenge siden.

Dette er blokkering ved starten av køen inne i én forbindelse, og det krever ikke at de to applikasjonene deler en indre forbindelse. De deler den ytre, og det er nok.

Andreordenseffekten gjør det verre. En indre avsender som ikke ser bekreftelser, kan sende på nytt data som det ytre laget allerede prøver å levere. Den nye sendingen blir ekstra tunneltrafikk på en vei som nettopp har bevist at den kan miste segmenter, så gjenopprettingsarbeidet konkurrerer med gjenopprettingen som betyr noe.

Ingenting av dette garanterer et sammenbrudd. På en ren vei med korte rundturer og romslige køer kan ordningen være helt brukbar i årevis. Feilen viser seg når tap, forsinkelse og kødybde faller sammen, og derfor klumper rapportene seg rundt overbelastede uplinker og mobile lenker i stedet for rundt godt utstyrte kontorer.

Hvorfor en lengre indre timer ikke kan hjelpe

Å heve den minste gjensendingstidsgrensen på en rute med rto_min utsetter timerbasert gjensending for lokalt generert TCP-trafikk som bruker ruten. Det er en ekte knapp med en ekte effekt, og den tar andreordensproblemet i stedet for det første.

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

Det den ikke kan, er å slippe ytre byter ut av rekkefølge, gjenopprette det manglende segmentet raskere eller få applikasjonsserveren i den andre enden til å bruke samme timer. Den mottakende stakken leverer fortsatt i rekkefølge, og avsenderen i den andre enden bruker fortsatt sine egne rundturmålinger.

Den slår heller ikke av alle andre mekanismer for tapsoppretting. Der ekte tap krever timerbasert gjenoppretting, får et større minimum applikasjonen til å vente lenger før den handler, som er det motsatte av hva en latensfølsom sesjon trenger.

Et fast gulv på tolv sekunder dukker opp i råd om emnet som om en TCP-tunnels eksistens forutsatte det. Gjensendingstimeren som er beskrevet i RFC 6298, utledes av målt rundtur med eksponentiell backoff, så et konstant gulv er et policyvalg for en bestemt vei og ikke et protokollkrav. Brukt bredt skjuler det symptomet samtidig som det endrer gjenopprettingen for hver flyt ruten dekker.

Hva tcp-nodelay gjør og ikke gjør

Tunnelvalget som slår av Nagle-lignende bufring på transportsocketen, har et snevert formål: det hindrer små skrivinger i å vente på mer data før sending. Det hjelper interaktiv trafikk å unngå en ekstra forsinkelse på en ellers frisk vei.

Det gjør ikke transporten uordnet, og det forkorter ikke gjenopprettingen etter et tapt segment. Et skall som stopper for en gjensendingstidsgrense, stopper fortsatt med valget slått på, fordi valget aldri rørte ordensregelen.

Det er lett å forveksle de to fordi begge beskrives som latensrettinger. Den ene fjerner en kunstig venting som bufringen innførte, den andre ville kreve å endre det transporten garanterer, og det gjør ingen socket-innstilling.

Slik sammenligner man transporter rettferdig

Hvis operatøren tillater det og begge tjenestene finnes, sammenlign en UDP-tjeneste og en TCP-tjeneste med samme arbeidsmengde over samme tilgangsvei til samme server. Å bytte land, leverandør eller servergenerasjon mellom de to testene fører inn en variabel som vil dominere resultatet.

Se etter den delte pausen i stedet for et gjennomstrømningstall. Flere indre applikasjoner som stopper sammen under ytre tap, er observasjonen som identifiserer blokkering ved starten av køen; ett lavere hastighetstall gjør det ikke.

Autoriserte opptak på tunnelgrensesnittet og på det fysiske grensesnittet skiller de to lagene rent, fordi indre og ytre gjensendinger hører til forskjellige forbindelser med forskjellige sekvensrom. Å se indre gjensendinger mens den ytre strømmen viser et hull, er det direkte beviset.

Å bytte til UDP fjerner den ekstra pålitelige strømmen og lar indre TCP gjøre sin egen gjenoppretting. Det lover ikke null tap eller lav latens, og en mettet uplink, overdimensjonerte køer eller et MTU-problem må fortsatt rettes. Trafikk utenfor tunnelen holdes aldri tilbake bak tunnelens sekvenshull, selv om den fortsatt kan lide når begge veiene deler en overbelastet lenke, og den delte flaskehalsen fortjener sin egen undersøkelse i stedet for å bli brettet inn i denne.