TCP handshake తర్వాత వేలాడే క్వెరీ రూటింగ్ సమస్య కాదు. మార్గ లోపాలు handshake విఫలమయ్యేలా చేస్తాయి, కాబట్టి ఏర్పడి తర్వాత నిశ్శబ్దమయ్యే సెషన్ మార్గం లోపలికి సూచిస్తుంది: తనిఖీ, MTU, లేక టన్నెల్ UDP ప్యాకెట్లు వచ్చే విధానం. మీ ముందున్న నిర్ణయం ఆ మార్గాన్ని సరిచేయడమా లేక టన్నెల్ను TCPకి మార్చడమా. మూడు షరతులు దాన్ని నిర్ణయిస్తాయి, వాటిలో ఏదీ డేటాబేస్ గురించి కాదు.

టన్నెల్ను నిందించే ముందు వేలాడటాన్ని వర్గీకరించండి

నాలుగు ఫలితాలు వినియోగదారుకు ఒకేలా కనిపిస్తాయి, ఇంజనీర్కు పూర్తిగా భిన్నమైన అర్థం ఇస్తాయి.

What the client seesWhat it rules out
Connection refusedNothing is listening on the address and port the client reached
Timeout before the handshakeA filter, a missing route, or the wrong address
Handshake completes, query hangsThe session exists, so look at inspection, MTU and packet order
Stalls that recover on retryOften reordering, or a state table entry expiring

చివరి రెండు వరుసలు మాత్రమే టన్నెల్పై సమయం వెచ్చించడాన్ని సమర్థిస్తాయి. VPN ద్వారా తిరస్కరించబడిన కనెక్షన్ సాధారణంగా డేటాబేస్ కేవలం loopbackలో వినడం, ఇది శ్రోత సమస్య, మరియు handshake ముందు సమయం ముగియడం ఫిల్టర్ లేక మార్గం. రెండూ ఎన్క్యాప్సులేషన్ మార్చడం వల్ల మెరుగుపడవు.

వర్గీకరణను మొదట టికెట్లో రాయండి. ఇది చౌకైన అడుగు మరియు శోధన స్థలంలో ఎక్కువ భాగాన్ని తొలగిస్తుంది.

UDP మరియు TCP మధ్య నిర్ణయించే మూడు షరతులు

ఎన్‌క్యాప్సులేట్ చేయబడిన IPsec ట్రాఫిక్ UDPపై ప్రయాణిస్తుంది, UDP మార్గానికి ఎవరికీ చెప్పకుండా పునర్వ్యవస్థీకరించడానికి మరియు వదిలేయడానికి స్వాతంత్ర్యం ఇస్తుంది. పునర్వ్యవస్థీకరణ ప్యాకెట్లను టన్నెల్ యొక్క పునరావృత నిరోధక విండో వెలుపలికి నెట్టినప్పుడు, అవి నిశ్శబ్దంగా తొలగించబడతాయి మరియు లోపలి TCP సెషన్ కేవలం వేచి ఉంటుంది. విజయవంతమైన handshake మరియు ఎప్పుడూ తిరిగి రాని క్వెరీ వెనుక ఉన్న యంత్రాంగం ఇదే.

మార్గాన్ని సరిచేయడం లేక TCPకి తిరిగి వెళ్లడం మూడు విషయాలపై ఆధారపడి ఉంటుంది. మొదటిది, మార్గంలో నిజమైన ప్యాకెట్ నష్టం ఉందా లేక పునర్వ్యవస్థీకరణ మాత్రమేనా? రెండవది, తనిఖీ ఎక్కడ జరుగుతుందో మార్చగలరా, లేక ఈ టన్నెల్ను పునర్వ్యవస్థీకరించే భాగం నుండి మినహాయించగలరా? మూడవది, పనిభారం వేలాడటం నమూనాకు సున్నితమా, ఉదాహరణకు ఒక లింక్‌ను పంచుకునే అనేక మల్టీప్లెక్స్ సెషన్లు?

మొదటి సమాధానం నష్టం అయితే, రెండవది కాదు అయితే,443లో TCP ఆచరణాత్మక ప్రత్యామ్నాయం. రెండవ సమాధానం అవును అయితే, మార్గాన్ని సరిచేసి UDP ఉంచండి.

అప్లికేషన్ లోపం కాదు, ఫైర్‌వాల్ రికార్డును చదవండి

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

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

ఏదైనా మార్చే ముందు రెండు చివరలను పోల్చండి, ప్యాకెట్ సంఖ్యలు కాదు రాక క్రమాన్ని పోల్చండి:

tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcap

443లో TCP వాస్తవంగా మీకు ఎంత ఖర్చు చేస్తుంది

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

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

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

నిర్ణయాన్ని పునఃసమీక్షించగలిగేలా ఉంచండి

మార్గ నిర్ధారణ త్వరగా పాతబడుతుంది. మధ్య పెట్టె మార్చబడుతుంది, బ్లేడ్ కాన్ఫిగరేషన్ మారుతుంది, లింక్ అప్‌గ్రేడ్ అవుతుంది, 443లో TCPకి కారణం మాయమవుతుంది కానీ కాన్ఫిగరేషన్ మిగిలి ఉంటుంది. మినహాయింపుపై సమీక్ష తేదీ పెట్టి, UDPకి తిరిగి వెళ్లడానికి అనుమతించే షరతును పేర్కొనండి.

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

సంబంధిత వ్యాసాలు