తక్కువ VPN థ్రూపుట్ ఎంట్రోపీ సమస్యా? సాధారణంగా కాదు

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

ఒకేలా కనిపించే రెండు లక్షణాలు

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

స్టార్టప్, ప్రామాణీకరణ, కీ పునర్ చర్చలు మరియు బదిలీ చుట్టూ టైమ్స్ట్యాంప్లు పెట్టండి. టన్నెల్ ఉపయోగించగలిగే ముందు దీర్ఘ జాప్యం తక్కువ స్థిర వేగం కాదు, రెండింటినీ ఒక సంఖ్యలో సగటు చేయడం సాక్ష్యాన్ని నాశనం చేస్తుంది.

systemd-analyze blame | head -10
journalctl -u [email protected] -o short-precise | head -40
cat /proc/sys/kernel/random/entropy_avail

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

యాదృచ్ఛిక సంఖ్యల కోసం వేచి ఉండటం నిజంగా ఎలా ఉంటుంది

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

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

strace -f -e trace=getrandom -p $(pidof openvpn) 2>&1 | head -20
dmesg | grep -i 'random\|crng'

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

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

నిరంతర నెమ్మదితనం నిజంగా ఎలా ఉంటుంది

ఎల్లప్పుడూ నెమ్మదిగా బదిలీ చేసే టన్నెల్ డేటా మార్గం ద్వారా పరిమితమవుతుంది. ఒక సంతృప్త థ్రెడ్, బాహ్య ప్యాకెట్ నష్టం, పునఃప్రసారాలు లేదా నిండిన సాకెట్ క్యూలు ప్రతి ఒక్కటి ఆ నమూనాను ఉత్పత్తి చేస్తాయి, ప్రతి దానికి దాని స్వంత పరిష్కారం ఉంది. మొత్తం CPU శాతం ఒక బిజీ థ్రెడ్ను దాచుతుంది, ఇదే అత్యంత సాధారణ తప్పు పఠనం. మొత్తం లోడ్ను చూసే ముందు థ్రెడ్ వారీగా సమయాన్ని చూడండి.

పోల్చదగిన ఆధారరేఖతో రెండు దిశల్లో కొలవండి, అప్లికేషన్ స్వంత నివేదికకు బదులుగా ఇంటర్ఫేస్ కౌంటర్లను గమనించండి.

ss -tin dst 203.0.113.10
nstat -az | grep -i 'drop\|retrans'
ethtool -S eth0 | grep -i 'drop\|error'

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

మీరు కొలిచిన అడ్డంకికి సరిదిద్దుకోవడం ఎంచుకోండి

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

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

అదే కొలత అదే పరిస్థితుల్లో మెరుగుపడినప్పుడు మాత్రమే మార్పును అంగీకరించండి. పెద్ద కౌంటర్ ఫలితం కాదు; చిన్న కొలిచిన నిరీక్షణ లేదా గుర్తించిన కారణంతో వేగవంతమైన బదిలీ ఫలితం.