పెద్ద డౌన్‌లోడ్‌లు మరియు VPN: అభ్యర్థన వద్దే మార్గాన్ని ఎంచుకోండి
ప్రతిస్పందన రాకముందే రౌటర్ దాని పరిమాణాన్ని కొలవలేదు. టాస్క్ ప్రకారం నిర్దేశానికి అప్లికేషన్‌లో నిర్ణయ బిందువు లేదా ఉన్న మార్గాన్ని నిలుపుకునే క్యూ విధానం అవసరం.
“పెద్ద డౌన్‌లోడ్‌లను VPN చుట్టూ పంపి, చిన్న ప్రతిస్పందనలను దానిపైనే ఉంచండి” అనేది రౌటింగ్ విధానంలా అనిపిస్తుంది, కానీ కాదు. రౌటర్ ఆ క్షణంలో అందుబాటులో ఉన్న సమాచారంతో నిర్ణయిస్తుంది: చిరునామాలు, పోర్టులు, ప్రోటోకాల్, firewall గుర్తులు, గుర్తించిన ప్రవాహం. ప్రతిస్పందన యొక్క తుది పరిమాణం ఆ సముదాయంలో లేదు, ఎందుకంటే అది ఇంకా రాలేదు, రౌటర్ బైట్లను కొలవగల సమయానికి అది వాటిని మోసుకెళ్తోంది. మీరు టాస్క్ ప్రకారం నిర్దేశించాలనుకుంటే, నిర్ణయం టాస్క్‌ను తెలిసిన బిందువుకు వెళ్లాలి, క్రింది తనిఖీ జాబితా మీ రూపకల్పనలో అలాంటి బిందువు ఉందో లేదో చూపిస్తుంది.
రౌటర్ ప్రతిస్పందనను ఎందుకు కొలవలేదు
ఒక ప్యాకెట్‌కు మార్గం అవసరమైన క్షణంలో, రౌటర్ ఒక ప్రవాహం యొక్క మొదటి కొన్ని ప్యాకెట్లను మాత్రమే చూసి ఉంటుంది. ఎవరు ఎవరితో మాట్లాడుతున్నారు, ఏ ప్రోటోకాల్‌లో, ఏ గుర్తుతో, ఇప్పటివరకు ఎన్ని బైట్లు గడిచాయో చెప్పగలదు. ఇప్పటివరకు గడిచిన బైట్లు గతాన్ని వివరిస్తాయి. ప్రతిస్పందన పరిమాణం ఇంకా సృష్టించబడని ప్రతిస్పందన లక్షణం, విభజించిన లేదా స్ట్రీమింగ్ ప్రతిస్పందనలలో అది ముందుగా ఎప్పటికీ తెలియకపోవచ్చు.
ప్రోటోకాల్ సొంత మెటాడేటా కూడా కనిపించే దానికంటే బలహీనం. HTTP శరీరానికి ముందు పొడవు ప్రకటించని ప్రతిస్పందనలను అనుమతిస్తుంది, ఒక వినియోగదారు చర్య ఏ ఒక్క హెడర్ విలువకూ సరిపోలని మొత్తం ఖర్చుతో అనేక అభ్యర్థనలను సృష్టించవచ్చు. హెడర్‌ను టాస్క్ పరిమాణంగా తీసుకోవడం రౌటింగ్ లోపానికి ముందు మోడలింగ్ లోపం.
తనిఖీ 1: మార్గాన్ని ఎంచుకోగల నిర్ణయ బిందువు ఉందా?
ఎంపిక చేసే భాగానికి పేరు పెట్టండి, తర్వాత ఎంపిక క్షణంలో అది ఏమి తెలుసుకుంటుందో చెప్పండి. పత్రబద్ధ హోస్ట్ సముదాయం నుండి తెచ్చే నవీకరణ బదిలీ ప్రారంభానికి ముందే తన ఉద్దేశాన్ని తెలుసుకుంటుంది. మెటాడేటాను చూసి తర్వాత అభ్యర్థనను తెరిచే డౌన్‌లోడ్ సేవ కనెక్షన్ ఏర్పడక ముందే టాస్క్‌ను తెలుసుకుంటుంది. సహకరించే proxy తనను రౌటర్‌గా చూపకుండా అభ్యర్థన స్థాయి విధానాన్ని వర్తింపజేయవచ్చు లేదా ప్రతిస్పందనను కాష్ చేయవచ్చు.
సమాధానం “గేట్‌వే” అయితే, తనిఖీ జాబితా ఇప్పటికే విఫలమైంది. గేట్‌వే తెలిసిన ప్రవాహాలను గమ్యస్థానం, గుర్తు లేదా క్లయింట్ విభాగం ప్రకారం వర్గీకరించి మొదటి ప్యాకెట్ నుండే నిర్దిష్ట మార్గంలో పంపగలదు, ఇది ఆమోదించిన నవీకరణకు తరచుగా సరిపోతుంది, తెలియని ప్రతిస్పందన పరిమాణానికి ఎప్పటికీ సరిపోదు.
తనిఖీ 2: మెటాడేటా నిజంగా మీకు ఏమి చెబుతుంది?
అప్లికేషన్ తెలిసిన నిర్దేశం అది చదివే క్షేత్రాలంత మంచిది. HTTP యొక్క అర్థశాస్త్రం లోని ప్రతిస్పందన-పొడవు నియమాలు ప్రారంభంలో పొడవు అందుబాటులో లేని సందర్భాలను అనుమతిస్తాయి, కంటెంట్ ఎన్‌కోడింగ్‌లు బదిలీ అయిన బైట్ గణనను ప్రాతినిధ్య పరిమాణం నుండి ఏమైనా భిన్నంగా చేస్తాయి. అందువల్ల హెడర్ పరిమితిని దాటినప్పుడు మార్గాన్ని మార్చే విధానం అస్థిరంగా ప్రవర్తిస్తుంది, ముఖ్యంగా పట్టుకోవాలని ఉద్దేశించిన పెద్ద బదిలీల్లోనే.
అప్లికేషన్ మెటాడేటా మద్దతు ఇవ్వగలిగేది టాస్క్ గురించిన నిర్ణయం: ఈ వర్క్‌ఫ్లో బల్క్ సింక్, ఇది ఇంటరాక్టివ్, ఇది తెలిసిన మూలం నుండి సాఫ్ట్‌వేర్ నవీకరణ. అది ఉద్దేశ భాషలో రాసిన విధానం, పరీక్షించడానికి తగినంత స్థిరం. “ఈ ప్రతిస్పందన నలభై మెగాబైట్ల కంటే పెద్దదిగా ఉంటుంది” అలాంటి విధానం కాదు.
తనిఖీ 3: ప్రవాహం ఇప్పటికే ఉందా?
ప్రవాహానికి రౌటింగ్ కనెక్షన్ గుర్తింపును మార్చకుండా మారవచ్చు, ఆ భేదాన్ని సరిగ్గా ఉంచుకోవడం విలువైనది. TCP కనెక్షన్ దాని చివరల చిరునామాలు మరియు పోర్టులతో గుర్తించబడుతుంది, రౌటింగ్ పట్టిక వాటి కింద మారితే ప్యాకెట్లు వేరే మార్గం తీసుకోవచ్చు. అదృశ్యంగా మారలేనిది నెట్‌వర్క్ చిరునామా అనువాద స్థితి: ట్రాఫిక్‌ను మరో నిష్క్రమణకు తరలించడం సాధారణంగా ప్రజా మూల ట్యూపుల్‌ను మారుస్తుంది, దూరపు చివర సరిపోలే స్థితి లేని మరో భాగస్వామిని చూస్తుంది.
conntrack -L -p tcp --dport 443 | head -5
ip route get 203.0.113.10
ss -tn state established dst 203.0.113.10కాబట్టి ఆచరణాత్మక నియమం, కనెక్షన్ మధ్యలో ఒక నిష్క్రమణ నుండి మరొకదానికి తరలడం కొత్త సంబంధం, వలస కాదు. రూపకల్పన అదే కనెక్షన్ కొనసాగాలని కోరితే, నిర్ణయం మొదటి SYN ముందే తీసుకోవాల్సి ఉండేది, తర్వాత జోడించిన ఏ ప్యాకెట్ నియమం దాన్ని శుభ్రంగా పునర్నిర్మించలేదు.
తనిఖీ 4: నిజమైన అవసరం ఆలస్యమా, నిష్క్రమణ కాదా?
“బల్క్ ట్రాఫిక్‌ను వేరే చోటికి పంపండి” అనే అనేక అభ్యర్థనలు నిజానికి పెద్ద బదిలీ ఇంటరాక్టివ్ పనిని నెమ్మదిగా అనిపించడం గురించిన ఫిర్యాదులు. అది షెడ్యూలింగ్ సమస్య, దానికి షెడ్యూలింగ్ సమాధానం ఉంది: ఉన్న మార్గంలో న్యాయమైన క్యూ లేదా మద్దతు ఉన్న బ్యాండ్‌విడ్త్ విధానం బల్క్ ప్రవాహం చాట్ సందేశాన్ని ఆకలితో ఉంచకుండా నిరోధిస్తుంది, రెండింటిలో దేన్నీ కదిలించకుండా.
tc qdisc replace dev eth0 root cake bandwidth 100mbitఇలా లక్షణాన్ని పరిష్కరించడం నిష్క్రమణ నిర్ణయాన్ని భద్రతా విధానం పెట్టిన చోటే ఉంచుతుంది, ఒక ఆదేశంతో తిరిగి మార్చవచ్చు. మొత్తం ట్రాఫిక్ తరగతికి నిష్క్రమణను మార్చడం ప్రామాణీకరణ, లాగింగ్ మరియు ప్రవేశ నియమాల పరిణామాలతో కూడిన విధాన మార్పు, కాబట్టి ఆలస్య ఫిర్యాదుకు అది మొదటి సాధనం కాకూడదు.
అవసరం నిజంగా వేరే ఇంటర్నెట్ నిష్క్రమణ అయితే, ఆ మాటల్లోనే చెప్పి మద్దతు ఉన్న సరిహద్దులో అమలు చేయండి: ఆమోదించిన వర్క్‌ఫ్లో నుండి కొత్త కనెక్షన్, లేదా ఎంచుకున్న నిష్క్రమణ ద్వారా తన అభ్యర్థనను తెరిచే అప్లికేషన్. తర్వాత ఏ టాస్క్‌లు ఏ నిష్క్రమణను ఉపయోగిస్తున్నాయో నమోదు చేయండి, తదుపరి వ్యక్తి దాన్ని రౌటింగ్ పట్టిక నుండి ఊహించకుండా.
మార్పు నమోదులో తనిఖీ జాబితాను ఉంచండి: నిర్ణయ బిందువు, దాన్ని నడిపే క్షేత్రం లేదా టాస్క్, ప్రవాహం ఇప్పటికే ఉందా, కొలిచిన లక్షణం ఆలస్యమా నిష్క్రమణా. నాలుగు ప్రశ్నలు, నాలుగింటికీ సమాధానమిచ్చే విధానం మీరు నిర్వహించగలిగేది, కాపాడాల్సినది కాదు.