OpenVPN sa TCP: hindi inaayos ng rto_min ang pagharang sa unahan ng pila

Ang isang interactive na shell sa ibabaw ng tunnel ay nagyeyelo nang ilang segundo habang tumatakbo ang pagkopya ng file, pagkatapos ay nagpapatuloy na parang walang nangyari. Ang download lang ang may problema, gayunpaman naghihintay din ang shell, at sabay silang bumangon sa parehong sandali. Ang pattern na iyon ay ang pirma ng isang maaasahang daloy na nagdadala ng maraming usapan, at nakakaligtas ito sa halos lahat ng tuning na unang sinusubukan ng mga tao.

Karapat-dapat basahin nang mabuti ang sintomas dahil tumuturo ito sa mekanismo at hindi sa setting: ang paghinto ay pinagsasaluhan, kaya pinagsasaluhan ang sanhi, at ang pinagsasaluhang bagay ay ang panlabas na koneksyon. Ang lahat ng iba sa log ay mukhang normal habang nangyayari ito.

Ang sintomas: sabay na humihinto ang lahat

Dalawang panloob na koneksyon na sabay na natigil ang palatandaan. Ang mabagal na download at mabagal na shell ay magkahiwalay na usapan sa TCP na may magkahiwalay na sequence number at magkahiwalay na kalagayan ng siksikan, kaya hindi dapat maapektuhan ng sira sa isa ang isa pa. Kapag sabay silang huminto sa parehong ritmo, may isang bagay sa itaas nila na nag-aayos ng kanilang byte.

Ang bagay na iyon ay ang transport ng tunnel. Sa mode na TCP, isinusulat ng OpenVPN ang mga naka-encapsulate na packet sa isang koneksyon sa TCP patungo sa peer, at ang kontrata ng TCP ay ang sunod-sunod na paghahatid ng isang daloy ng byte. Ang mga sumunod na byte ay hindi ibinibigay sa aplikasyon bago ang nawawala, kahit sa aling panloob na usapan sila nabibilang.

Pansinin ang hindi sinasabi ng sintomas. Hindi nito sinasabi na sira ang ruta, na overloaded ang server, o na mabagal ang encryption. Ang mga iyon ay gumagawa ng ibang hugis: pantay-pantay na mababang throughput, pag-timeout, o mga pagkabigo na umaapekto sa isang direksyon. Ang pinagsasaluhang paghinto na nagtatapos kapag naipadala muli ang nawawalang segment ay partikular na epekto ng pag-aayos ng pagkakasunod-sunod.

Isang panlabas na daloy ng byte, maraming panloob na usapan

Isipin ang tunnel na sabay na nagdadala ng download at shell. Nawala ang isang segment ng panlabas na koneksyon. Maaaring makarating ang mga sumunod na segment sa receiving host, at aakuin sila ng TCP stack doon, ngunit hindi nito maipapasa ang mga ito pataas hanggang mapuno ang puwang. Kaya wala nang mababasa ang OpenVPN para sa shell, kahit matagal nang dumating ang byte ng shell mismo.

Ito ang pagharang sa unahan ng pila sa loob ng isang koneksyon, at hindi nito kailangang magsaluhan ang dalawang aplikasyon ng panloob na koneksyon. Pinagsasaluhan nila ang panlabas, at sapat na iyon.

Pinapalala ito ng ikalawang antas na epekto. Ang panloob na nagpapadala na walang nakikitang acknowledgment ay maaaring magpadala muli ng data na sinusubukan na ng panlabas na layer na ihatid. Ang muling pagpapadala ay nagiging dagdag na trapik ng tunnel sa rutang katatapos lang patunayang maaari itong mawalan ng segment, kaya ang gawaing pagbangon ay nakikipag-agawan sa pagbangon na mahalaga.

Wala sa mga ito ang ginagarantiya ang pagbagsak. Sa malinis na ruta na may maiikling round trip at maluluwag na pila, maaaring ganap na magamit ang kaayusang ito nang maraming taon. Lumilitaw ang kabiguan kapag sabay na nangyayari ang pagkawala, pagkaantala at lalim ng pila, at dahil dito nagkukumpol ang mga ulat sa mga kongestionadong uplink at mobile link at hindi sa mahusay na kagamitang opisina.

Bakit hindi makatutulong ang mas mahabang panloob na timer

Ang pagtataas ng pinakamababang retransmission timeout sa isang ruta gamit ang rto_min ay nagpapaliban ng retransmission na batay sa timer para sa lokal na nalikhang trapik na TCP na gumagamit ng rutang iyon. Isa itong tunay na knob na may tunay na epekto, at hinaharap nito ang ikalawang antas na problema sa halip na ang una.

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

Ang hindi nito kayang gawin ay ilabas ang panlabas na byte nang wala sa ayos, mabawi ang nawawalang segment nang mas mabilis, o pilitin ang remote na application server na gamitin ang parehong timer. Ang receiving stack ay naghahatid pa rin nang sunod-sunod, at ang nagpapadala sa dulong bahagi ay gumagamit pa rin ng sarili nitong pagsukat ng round trip.

Hindi rin nito pinapatay ang lahat ng iba pang mekanismo ng pagbangon mula sa pagkawala. Kung saan ang tunay na pagkawala ay nangangailangan ng pagbangon na batay sa timer, ang mas malaking minimum ay nagpapahintay nang mas matagal sa aplikasyon bago ito kumilos, na kabaligtaran ng kailangan ng sesyon na sensitibo sa latency.

Ang nakapirming sahig na labindalawang segundo ay lumilitaw sa payo tungkol sa paksang ito na parang kailangan ito ng pagkakaroon ng tunnel na TCP. Ang retransmission timer na inilarawan sa RFC 6298 ay hinango sa sinusukat na round trip na may exponential backoff, kaya ang palagiang sahig ay pagpiling patakaran para sa isang partikular na ruta at hindi requirement ng protocol. Kapag inilapat nang malawakan, itinatago nito ang sintomas habang binabago ang pagbangon para sa bawat daloy na saklaw ng rutang iyon.

Ano ang ginagawa at hindi ginagawa ng tcp-nodelay

Ang opsyon ng tunnel na nagpapasok sa Nagle-style buffering sa transport socket ay may makitid na layunin: pinipigilan nito ang maliliit na write na maghintay ng mas maraming data bago ipadala. Nakatutulong iyon sa interactive na trapik na maiwasan ang karagdagang pagkaantala sa rutang kung hindi ay malusog.

Hindi nito ginagawang walang ayos ang transport, at hindi nito pinaiikli ang pagbangon pagkatapos ng nawawalang segment. Ang shell na humihinto dahil sa retransmission timeout ay patuloy na hihinto kahit nakabukas ang opsyong iyon, dahil hindi kailanman hinawakan ng opsyon ang tuntunin ng pagkakasunod-sunod.

Madaling pagkamalangin ang dalawa dahil pareho silang inilarawan bilang pag-aayos ng latency. Ang isa ay nag-aalis ng artipisyal na paghihintay na dinala ng buffering, ang isa ay mangangailangan ng pagbabago sa ipinagagarantiya ng transport, at wala sa mga opsyon ng socket ang gumagawa niyon.

Paano ihambing nang patas ang mga transport

Kung pinapayagan ng operator at umiiral ang dalawang serbisyo, ihambing ang isang serbisyong UDP at isang serbisyong TCP na may dalang parehong workload sa parehong daan ng pag-access patungo sa parehong server. Ang pagpapalit ng bansa, provider o henerasyon ng server sa pagitan ng dalawang pagsubok ay nagpasok ng variable na mangingibabaw sa resulta.

Panoorin ang pinagsasaluhang paghinto at hindi ang bilang ng throughput. Ilang panloob na aplikasyon na sabay na natigil habang may panlabas na pagkawala ang obserbasyong tumutukoy sa pagharang sa unahan ng pila; ang isang mas mababang bilang sa speed test ay hindi gumagawa niyon.

Ang awtorisadong pagkuha sa tunnel interface at sa physical interface ay malinaw na naghihiwalay sa dalawang layer, dahil ang panloob at panlabas na retransmission ay nabibilang sa magkaibang koneksyon na may magkaibang sequence space. Ang makita ang panloob na retransmission habang may puwang sa panlabas na daloy ang direktang ebidensya.

Ang paglipat sa UDP ay nag-aalis ng dagdag na maaasahang daloy at hinahayaang gawin ng panloob na TCP ang sarili nitong pagbangon. Hindi ito nangangako ng walang pagkawala o mababang latency, at ang puspos na uplink, sobrang laking pila o problema sa MTU ay kailangan pa ring ayusin. Ang trapik sa labas ng tunnel ay hindi kailanman hinahawakan sa likod ng puwang ng sequence ng tunnel, kahit na maaari pa rin itong magdusa kapag pinagsasaluhan ng dalawang ruta ang isang kongestionadong link, at ang pinagsasaluhang bottleneck na iyon ay karapat-dapat sa sariling pagsisiyasat sa halip na itiklop dito.