OpenVPN TCPలో: rto_min క్యూ మొదటి భాగం బ్లాకింగ్ను సరిచేయదు

టన్నెల్ మీద నడిచే ఇంటరాక్టివ్ షెల్ ఫైల్ కాపీ నడుస్తున్నప్పుడు కొన్ని సెకన్లు స్తంభించి, తర్వాత ఏమీ జరగనట్టుగా కొనసాగుతుంది. సమస్య డౌన్లోడ్కే ఉన్నా, షెల్ కూడా వేచి ఉంటుంది, రెండూ ఒకే క్షణంలో కోలుకుంటాయి. ఈ నమూనా చాలా సంభాషణలను మోసే ఒకే విశ్వసనీయ స్ట్రీమ్ సంతకం, మరియు ప్రజలు మొదట ప్రయత్నించే దాదాపు ప్రతి ట్యూనింగ్ మార్పును తట్టుకుంటుంది.

లక్షణాన్ని జాగ్రత్తగా చదవాలి ఎందుకంటే అది ఒక యంత్రాంగాన్ని సూచిస్తుంది, సెట్టింగ్ను కాదు: విరామం పంచుకోబడింది, కాబట్టి కారణం పంచుకోబడింది, పంచుకున్న వస్తువు బయటి కనెక్షన్. ఇది జరుగుతున్నప్పుడు లాగ్లో మిగతావన్నీ సాధారణంగా కనిపిస్తాయి.

లక్షణం: అన్నీ ఒకేసారి ఆగుతాయి

రెండు లోపలి కనెక్షన్లు కలిసి చిక్కుకోవడమే ఆధారం. నెమ్మదిగా డౌన్లోడ్ మరియు నెమ్మదిగా షెల్ వేర్వేరు సీక్వెన్స్ నంబర్లు, వేర్వేరు రద్దీ స్థితి కలిగిన వేర్వేరు TCP సంభాషణలు, కాబట్టి ఒకదానిలో లోపం మరొకదాన్ని తాకకూడదు. అవి ఒకే లయలో ఆగినప్పుడు, వాటి పైన ఏదో వాటి బైట్లను క్రమబద్ధం చేస్తోంది.

ఆ ఏదో టన్నెల్ రవాణా పొర. TCP మోడ్లో, OpenVPN చుట్టబడిన ప్యాకెట్లను పీర్కు ఒకే TCP కనెక్షన్లో రాస్తుంది, TCP ఒప్పందం ఒకే బైట్ స్ట్రీమ్ను క్రమంగా అందించడం. తర్వాతి బైట్లు తప్పిపోయిన వాటికి ముందు అప్లికేషన్కు ఇవ్వబడవు, అవి ఏ లోపలి సంభాషణకైనా చెందినా.

లక్షణం ఏమి చెప్పదో గమనించండి. మార్గం పాడైందని, సర్వర్ మితిమీరిన భారంలో ఉందని, లేదా ఎన్క్రిప్షన్ నెమ్మదిగా ఉందని అది చెప్పదు. అవి వేరే ఆకారాలను సృష్టిస్తాయి: సమానంగా తక్కువ నిర్గమనం, టైమౌట్లు, లేదా ఒక దిశను మాత్రమే ప్రభావితం చేసే వైఫల్యాలు. కోల్పోయిన సెగ్మెంట్ మళ్లీ పంపబడినప్పుడు ముగిసే పంచుకున్న విరామం సరిగ్గా క్రమం యొక్క ప్రభావం.

ఒక బయటి బైట్ స్ట్రీమ్, చాలా లోపలి సంభాషణలు

టన్నెల్ ఒకేసారి డౌన్లోడ్ మరియు షెల్ను మోస్తున్నట్టు ఊహించండి. బయటి కనెక్షన్ సెగ్మెంట్ ఒకటి పోతుంది. తర్వాతి సెగ్మెంట్లు స్వీకరించే హోస్ట్కు చేరవచ్చు, స్వీకరించే TCP స్టాక్ వాటిని ధృవీకరిస్తుంది, కానీ ఖాళీ నిండే వరకు వాటిని పైకి అందించలేదు. అందువల్ల OpenVPNకు షెల్ కోసం చదవడానికి ఏమీ లేదు, షెల్ యొక్క సొంత బైట్లు చాలా కాలం క్రితం చేరినా.

ఇది ఒక కనెక్షన్ లోపల క్యూ మొదటి భాగం బ్లాకింగ్, మరియు రెండు అప్లికేషన్లు లోపలి కనెక్షన్ను పంచుకోవాలని అడగదు. అవి బయటి కనెక్షన్ను పంచుకుంటాయి, అదే సరిపోతుంది.

రెండవ స్థాయి ప్రభావం దాన్ని మరింత దిగజార్చుతుంది. ధృవీకరణలు కనిపించని లోపలి పంపేవాడు, బయటి పొర ఇప్పటికే అందించడానికి ప్రయత్నిస్తున్న డేటాను మళ్లీ పంపవచ్చు. ఆ పునఃప్రసారం సెగ్మెంట్లను కోల్పోగలదని ఇప్పుడే నిరూపించిన మార్గంలో అదనపు టన్నెల్ ట్రాఫిక్గా మారుతుంది, కాబట్టి కోలుకోవడం పని ముఖ్యమైన కోలుకోవడంతో పోటీపడుతుంది.

ఇవేవీ కుప్పకూలడానికి హామీ ఇవ్వవు. చిన్న రౌండ్ ట్రిప్లు, విశాలమైన క్యూలు ఉన్న శుభ్రమైన మార్గంలో ఈ ఏర్పాటు సంవత్సరాల తరబడి పూర్తిగా ఉపయోగపడవచ్చు. నష్టం, ఆలస్యం, క్యూ లోతు కలిసి వచ్చినప్పుడు వైఫల్యం కనిపిస్తుంది, అందుకే నివేదికలు బాగా సన్నద్ధమైన కార్యాలయాల చుట్టూ కాక, రద్దీగా ఉన్న అప్లింక్లు, మొబైల్ లింక్ల చుట్టూ గుమిగూడుతాయి.

పొడవైన లోపలి టైమర్ ఎందుకు సహాయపడలేదు

ఒక మార్గంలో rto_min తో కనీస పునఃప్రసార సమయ పరిమితిని పెంచడం, ఆ మార్గాన్ని ఉపయోగించే స్థానికంగా ఉత్పన్నమయ్యే TCP ట్రాఫిక్కు టైమర్ ఆధారిత పునఃప్రసారాన్ని ఆలస్యం చేస్తుంది. ఇది నిజమైన ప్రభావం ఉన్న నిజమైన నాబ్, మరియు మొదటి స్థాయి సమస్యకు బదులు రెండవ స్థాయి సమస్యను పరిష్కరిస్తుంది.

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

అది చేయలేనిది: బయటి బైట్లను క్రమం వెలుపల విడుదల చేయడం, తప్పిపోయిన సెగ్మెంట్ను వేగంగా కోలుకోవడం, లేదా దూర అప్లికేషన్ సర్వర్ను అదే టైమర్ను స్వీకరించేలా చేయడం. స్వీకరించే స్టాక్ ఇప్పటికీ క్రమంగా అందిస్తుంది, దూర చివరి పంపేవాడు ఇప్పటికీ తన సొంత రౌండ్ ట్రిప్ కొలతలను ఉపయోగిస్తాడు.

ఇది మిగతా నష్ట పునరుద్ధరణ యంత్రాంగాలను కూడా ఆఫ్ చేయదు. నిజమైన నష్టానికి టైమర్ ఆధారిత పునరుద్ధరణ అవసరమయ్యే చోట, పెద్ద కనీసం అప్లికేషన్ను చర్య తీసుకునే ముందు ఎక్కువసేపు వేచి ఉండేలా చేస్తుంది, ఇది ఆలస్యానికి సున్నితమైన సెషన్కు అవసరమైన దానికి విరుద్ధం.

పన్నెండు సెకన్ల స్థిర అడుగు ఈ అంశంపై సలహాలలో TCP టన్నెల్ ఉనికే దాన్ని తప్పనిసరి చేసినట్టు కనిపిస్తుంది. RFC 6298లో వివరించిన పునఃప్రసార టైమర్ కొలిచిన రౌండ్ ట్రిప్ సమయం నుండి ఘాతాంక వెనక్కి తగ్గుదలతో ఉత్పన్నమవుతుంది, కాబట్టి స్థిర అడుగు ఒక నిర్దిష్ట మార్గానికి విధాన ఎంపిక, ప్రోటోకాల్ అవసరం కాదు. విస్తృతంగా వర్తింపజేస్తే అది లక్షణాన్ని దాచి, ఆ మార్గం కవర్ చేసే ప్రతి ప్రవాహానికి పునరుద్ధరణను మారుస్తుంది.

tcp-nodelay ఏమి చేస్తుంది, ఏమి చేయదు

రవాణా సాకెట్పై Nagle శైలి బఫరింగ్ను ఆఫ్ చేసే టన్నెల్ ఎంపికకు ఒక సన్నని ఉద్దేశం ఉంది: చిన్న రాతలు పంపే ముందు ఎక్కువ డేటా కోసం వేచి ఉండకుండా ఆపడం. ఇది ఇంటరాక్టివ్ ట్రాఫిక్ మిగిలిన విషయాల్లో ఆరోగ్యకరమైన మార్గంలో అదనపు ఆలస్యాన్ని నివారించడంలో సహాయపడుతుంది.

ఇది రవాణాను క్రమరహితంగా మార్చదు, మరియు తప్పిపోయిన సెగ్మెంట్ తర్వాత పునరుద్ధరణను కుదించదు. పునఃప్రసార సమయ పరిమితి కోసం ఆగే షెల్ ఆ ఎంపిక ఆన్లో ఉన్నా ఆగుతుంది, ఎందుకంటే ఎంపిక క్రమ నియమాన్ని ఎప్పుడూ తాకలేదు.

రెండింటినీ గందరగోళపరచడం సులభం ఎందుకంటే రెండూ ఆలస్య సవరణలుగా వివరించబడతాయి. ఒకటి బఫరింగ్ తెచ్చిన కృత్రిమ నిరీక్షణను తొలగిస్తుంది, మరొకటి రవాణా ఏమి హామీ ఇస్తుందో మార్చాల్సి ఉంటుంది, ఏ సాకెట్ ఎంపికా అది చేయదు.

రవాణా పొరలను న్యాయంగా ఎలా పోల్చాలి

నిర్వాహకుడు అనుమతించి, రెండు సేవలు ఉంటే, ఒకే పనిభారాన్ని మోసే UDP సేవను, TCP సేవను ఒకే సర్వర్కు ఒకే ప్రవేశ మార్గంలో పోల్చండి. రెండు పరీక్షల మధ్య దేశం, ప్రదాత లేదా సర్వర్ తరాన్ని మార్చడం ఫలితంపై ఆధిపత్యం చెలాయించే చరాన్ని ప్రవేశపెడుతుంది.

నిర్గమన సంఖ్యకు బదులు పంచుకున్న విరామాన్ని గమనించండి. బయటి నష్టం సమయంలో పలు లోపలి అప్లికేషన్లు కలిసి చిక్కుకోవడమే క్యూ మొదటి భాగం బ్లాకింగ్ను గుర్తించే పరిశీలన; స్పీడ్ టెస్ట్ యొక్క ఒక తక్కువ సంఖ్య అది చేయదు.

టన్నెల్ ఇంటర్ఫేస్పై, భౌతిక ఇంటర్ఫేస్పై అధీకృత క్యాప్చర్లు రెండు పొరలను స్పష్టంగా వేరు చేస్తాయి, ఎందుకంటే లోపలి, బయటి పునఃప్రసారాలు వేర్వేరు క్రమ ప్రదేశాలతో వేర్వేరు కనెక్షన్లకు చెందుతాయి. బయటి స్ట్రీమ్ ఖాళీ చూపుతుండగా లోపలి పునఃప్రసారాలను చూడటమే ప్రత్యక్ష సాక్ష్యం.

UDPకి మారడం అదనపు విశ్వసనీయ స్ట్రీమ్ను తొలగించి, లోపలి TCP తన పునరుద్ధరణను తానే చేసుకునేలా వదిలేస్తుంది. ఇది సున్నా నష్టం లేదా తక్కువ ఆలస్యానికి హామీ ఇవ్వదు, నిండిన అప్లింక్, మితిమీరిన క్యూలు లేదా MTU సమస్య ఇప్పటికీ సరిచేయాల్సి ఉంటుంది. టన్నెల్ వెలుపలి ట్రాఫిక్ టన్నెల్ క్రమ ఖాళీ వెనుక ఎప్పుడూ నిలిపివేయబడదు, రెండు మార్గాలు ఒకే రద్దీ లింక్ను పంచుకున్నప్పుడు అది ఇప్పటికీ బాధపడవచ్చు, ఆ పంచుకున్న అవరోధం ఇందులో మడవకుండా దాని సొంత దర్యాప్తుకు అర్హం.