కనెక్షన్ ట్రాకింగ్ (“contrack”) అనేది Linux కెర్నల్ నెట్‌వర్కింగ్ స్టాక్ యొక్క ప్రధాన లక్షణం. ఇది కెర్నల్‌ను అన్ని లాజికల్ నెట్‌వర్క్ కనెక్షన్‌లు లేదా ఫ్లోలను ట్రాక్ చేయడానికి అనుమతిస్తుంది మరియు తద్వారా ప్రతి ప్రవాహాన్ని రూపొందించే అన్ని ప్యాకెట్లను గుర్తిస్తుంది, తద్వారా అవి వరుసగా కలిసి ప్రాసెస్ చేయబడతాయి.
Conntrack అనేది కొన్ని ప్రాథమిక సందర్భాలలో ఉపయోగించే ముఖ్యమైన కెర్నల్ ఫీచర్:
- NAT conntrack నుండి సమాచారంపై ఆధారపడుతుంది కాబట్టి ఇది ఒకే స్ట్రీమ్ నుండి అన్ని ప్యాకెట్లను సమానంగా పరిగణించగలదు. ఉదాహరణకు, ఒక పాడ్ Kubernetes సేవను యాక్సెస్ చేసినప్పుడు, kube-proxy లోడ్ బ్యాలెన్సర్ క్లస్టర్‌లోని నిర్దిష్ట పాడ్‌కు ట్రాఫిక్‌ని మళ్లించడానికి NATని ఉపయోగిస్తుంది. ఇచ్చిన కనెక్షన్ కోసం, IP సేవకు సంబంధించిన అన్ని ప్యాకెట్‌లు తప్పనిసరిగా అదే పాడ్‌కు పంపబడాలని మరియు బ్యాకెండ్ పాడ్ ద్వారా తిరిగి వచ్చిన ప్యాకెట్‌లు అభ్యర్థన వచ్చిన పాడ్‌కు తిరిగి NAT చేయబడాలని Conntrack రికార్డ్ చేస్తుంది.
- కాలికో వంటి స్టేట్‌ఫుల్ ఫైర్‌వాల్‌లు కనెక్ట్‌ట్రాక్ నుండి వైట్‌లిస్ట్ “స్పందన” ట్రాఫిక్ వరకు సమాచారంపై ఆధారపడతాయి. ప్రతిస్పందన ట్రాఫిక్‌ను స్పష్టంగా అనుమతించడానికి పాలసీని వ్రాయాల్సిన అవసరం లేకుండా "ఏదైనా రిమోట్ IP చిరునామాకు కనెక్ట్ చేయడానికి నా పాడ్‌ని అనుమతించు" అని చెప్పే నెట్‌వర్క్ విధానాన్ని వ్రాయడానికి ఇది మిమ్మల్ని అనుమతిస్తుంది. (ఇది లేకుండా, మీరు చాలా తక్కువ సురక్షితమైన "ఏదైనా IP నుండి నా పాడ్‌కి ప్యాకెట్లను అనుమతించు" నియమాన్ని జోడించాలి.)
అదనంగా, conntrack సాధారణంగా సిస్టమ్ పనితీరును మెరుగుపరుస్తుంది (CPU వినియోగం మరియు ప్యాకెట్ జాప్యాన్ని తగ్గించడం ద్వారా) స్ట్రీమ్‌లోని మొదటి ప్యాకెట్ మాత్రమే.
దానితో ఏమి చేయాలో నిర్ణయించడానికి మొత్తం నెట్‌వర్క్ స్టాక్‌ను తప్పనిసరిగా చూడాలి. పోస్ట్ చూడండి""ఇది ఎలా పని చేస్తుందో ఒక ఉదాహరణ చూడటానికి.
అయితే, contrack దాని పరిమితులను కలిగి ఉంది ...
కాబట్టి ఇదంతా ఎక్కడ తప్పు జరిగింది?
conntrack పట్టిక కాన్ఫిగర్ చేయదగిన గరిష్ట పరిమాణాన్ని కలిగి ఉంటుంది మరియు అది పూర్తి అయినట్లయితే, కనెక్షన్‌లు సాధారణంగా తిరస్కరించబడటం లేదా వదిలివేయబడటం ప్రారంభమవుతాయి. చాలా అప్లికేషన్‌ల ట్రాఫిక్‌ను నిర్వహించడానికి పట్టికలో తగినంత ఖాళీ స్థలం ఉంది మరియు ఇది ఎప్పటికీ సమస్యగా మారదు. అయితే, మీరు contrack పట్టికను ఉపయోగించడాన్ని పరిగణించాలనుకునే కొన్ని దృశ్యాలు ఉన్నాయి:
- మీ సర్వర్ చాలా పెద్ద సంఖ్యలో ఏకకాలంలో యాక్టివ్ కనెక్షన్‌లను నిర్వహిస్తుంటే చాలా స్పష్టమైన సందర్భం. ఉదాహరణకు, మీ conntrack పట్టిక 128k ఎంట్రీల కోసం కాన్ఫిగర్ చేయబడి ఉంటే, కానీ మీరు >128k ఏకకాల కనెక్షన్‌లను కలిగి ఉంటే, మీరు ఖచ్చితంగా సమస్యను ఎదుర్కొంటారు!
- కొంచెం తక్కువ స్పష్టమైన సందర్భం: మీ సర్వర్ సెకనుకు చాలా పెద్ద సంఖ్యలో కనెక్షన్‌లను ప్రాసెస్ చేస్తే. కనెక్షన్‌లు స్వల్పకాలికంగా ఉన్నప్పటికీ, అవి కొంత కాలం పాటు Linux ద్వారా పర్యవేక్షించబడుతూనే ఉంటాయి (డిఫాల్ట్‌గా 120లు). ఉదాహరణకు, మీ conntrack పట్టిక 128k ఎంట్రీల కోసం కాన్ఫిగర్ చేయబడి, మీరు సెకనుకు 1100 కనెక్షన్‌లను నిర్వహించడానికి ప్రయత్నిస్తున్నట్లయితే, కనెక్షన్‌లు చాలా తక్కువ కాలం ఉన్నప్పటికీ (128k/120s = 1092 కనెక్షన్‌లు/) అవి conntrack పట్టిక పరిమాణాన్ని మించిపోతాయి. లు).
ఈ వర్గాలలోకి వచ్చే అనేక సముచిత రకాల యాప్‌లు ఉన్నాయి. అదనంగా, మీరు చాలా మంది చెడ్డ నటులను కలిగి ఉన్నట్లయితే, మీ సర్వర్ యొక్క కాంటాక్ టేబుల్‌ను చాలా సగం-ఓపెన్ కనెక్షన్‌లతో నింపడం సేవా నిరాకరణ (DOS) దాడిలో భాగంగా ఉపయోగించబడుతుంది. రెండు సందర్భాల్లో, మీ సిస్టమ్‌లో కాంట్రాక్ పరిమిత అడ్డంకిగా మారవచ్చు. కొన్ని సందర్భాల్లో, conntrack పట్టిక పారామితులను సర్దుబాటు చేయడం మీ అవసరాలను తీర్చడానికి సరిపోతుంది - పరిమాణాన్ని పెంచడం లేదా conntrack గడువులను తగ్గించడం ద్వారా (కానీ మీరు తప్పు చేస్తే, మీరు చాలా ఇబ్బందుల్లో పడతారు). ఇతర సందర్భాల్లో దూకుడు ట్రాఫిక్ కోసం కాంట్‌ట్రాక్‌ను దాటవేయడం అవసరం.
నిజమైన ఉదాహరణ
ఒక నిర్దిష్ట ఉదాహరణను ఇద్దాం: మేము పనిచేసిన ఒక పెద్ద SaaS ప్రొవైడర్ హోస్ట్‌లలో (వర్చువల్ మెషీన్‌లు కాదు) అనేక మెమ్‌క్యాచ్డ్ సర్వర్‌లను కలిగి ఉంది, వీటిలో ప్రతి ఒక్కటి సెకనుకు 50K+ స్వల్పకాలిక కనెక్షన్‌లను ప్రాసెస్ చేస్తుంది.
వారు conntrack కాన్ఫిగరేషన్‌తో ప్రయోగాలు చేశారు, పట్టిక పరిమాణాలను పెంచారు మరియు ట్రాకింగ్ సమయాన్ని తగ్గించారు, కానీ కాన్ఫిగరేషన్ నమ్మదగనిది, RAM వినియోగం గణనీయంగా పెరిగింది, ఇది ఒక సమస్య (GBytes క్రమంలో!), మరియు కనెక్షన్‌లు చాలా తక్కువగా ఉన్నాయి కాబట్టి conntrack చేయలేదు. దాని సాధారణ పనితీరు ప్రయోజనాన్ని సృష్టించండి (తగ్గిన వినియోగం CPU లేదా ప్యాకెట్ జాప్యం).
వారు ప్రత్యామ్నాయంగా కాలికో వైపు మొగ్గు చూపారు. కాలికో నెట్‌వర్క్ విధానాలు కొన్ని రకాల ట్రాఫిక్‌ల కోసం (doNotTrack పాలసీ ఎంపికను ఉపయోగించి) conntrackని ఉపయోగించకుండా మిమ్మల్ని అనుమతిస్తాయి. ఇది వారికి అవసరమైన పనితీరు స్థాయిని అందించింది మరియు కాలికో అందించిన అదనపు భద్రతను అందించింది.
కాంట్రాక్‌ను దాటవేయడానికి మీరు ఏ పొడవులకు వెళ్లాలి?
- డో-నాట్-ట్రాక్ నెట్‌వర్క్ విధానాలు సాధారణంగా సుష్టంగా ఉండాలి. SaaS ప్రొవైడర్ విషయానికొస్తే: వారి అప్లికేషన్‌లు రక్షిత జోన్‌లో ఉన్నాయి మరియు అందువల్ల, నెట్‌వర్క్ విధానాన్ని ఉపయోగించి, వారు మెమ్‌క్యాచ్‌కు యాక్సెస్ అనుమతించబడిన ఇతర నిర్దిష్ట అప్లికేషన్‌ల నుండి ట్రాఫిక్‌ను వైట్‌లిస్ట్ చేయవచ్చు.
- డూ-నాట్-ట్రాక్ విధానం కనెక్షన్ యొక్క దిశను పరిగణనలోకి తీసుకోదు. అందువల్ల, మెమ్‌క్యాచ్ చేయబడిన సర్వర్ హ్యాక్ చేయబడితే, మీరు సరైన సోర్స్ పోర్ట్‌ను ఉపయోగిస్తున్నంత వరకు, మీరు మెమ్‌క్యాచ్ చేయబడిన క్లయింట్‌లలో దేనికైనా కనెక్ట్ చేయడానికి సిద్ధాంతపరంగా ప్రయత్నించవచ్చు. అయితే, మీరు మీ మెమ్‌క్యాచ్ చేయబడిన క్లయింట్‌ల కోసం నెట్‌వర్క్ విధానాన్ని సరిగ్గా నిర్వచించినట్లయితే, క్లయింట్ వైపు నుండి ఈ కనెక్షన్ ప్రయత్నాలు ఇప్పటికీ తిరస్కరించబడతాయి.
- సాధారణ విధానాలకు విరుద్ధంగా ప్రతి ప్యాకెట్‌కు డో-నాట్-ట్రాక్ విధానం వర్తించబడుతుంది, ఇది ఫ్లోలో మొదటి ప్యాకెట్‌కు మాత్రమే వర్తించబడుతుంది. ఇది ఒక్కో ప్యాకెట్‌కి CPU వినియోగాన్ని పెంచుతుంది ఎందుకంటే ప్రతి ప్యాకెట్‌కి తప్పనిసరిగా విధానం వర్తింపజేయాలి. కానీ స్వల్పకాలిక కనెక్షన్ల కోసం, కాంట్రాక్ ప్రాసెసింగ్ కోసం వనరుల వినియోగాన్ని తగ్గించడం ద్వారా ఈ వ్యయం సమతుల్యమవుతుంది. ఉదాహరణకు, SaaS ప్రొవైడర్ విషయంలో, ప్రతి కనెక్షన్‌కు ప్యాకెట్‌ల సంఖ్య చాలా తక్కువగా ఉంటుంది, కాబట్టి ప్రతి ప్యాకెట్‌కు విధానాలను వర్తింపజేసేటప్పుడు అదనపు CPU వినియోగం సమర్థించబడుతుంది.
పరీక్షను ప్రారంభిద్దాం
మేము మెమ్‌క్యాచ్డ్ సర్వర్ మరియు రిమోట్ నోడ్‌లలో రన్ అయ్యే బహుళ మెమ్‌క్యాచ్డ్ క్లయింట్ పాడ్‌లతో ఒకే పాడ్‌లో పరీక్షను అమలు చేసాము, తద్వారా మేము సెకనుకు చాలా పెద్ద సంఖ్యలో కనెక్షన్‌లను అమలు చేయగలము. memcached సర్వర్ పాడ్‌తో ఉన్న సర్వర్‌లో 8 కోర్‌లు మరియు 512k ఎంట్రీలు conntrack పట్టికలో ఉన్నాయి (హోస్ట్ కోసం ప్రామాణిక కాన్ఫిగర్ చేయబడిన టేబుల్ పరిమాణం).
మేము వీటి మధ్య పనితీరు వ్యత్యాసాన్ని కొలిచాము: నెట్‌వర్క్ విధానం లేదు; సాధారణ కాలికో విధానంతో; మరియు కాలికో డో-నాట్-ట్రాక్ విధానం.
మొదటి పరీక్ష కోసం, మేము కనెక్షన్ల సంఖ్యను సెకనుకు 4.000కి సెట్ చేసాము, కాబట్టి మేము CPU వినియోగంలో తేడాపై దృష్టి పెట్టవచ్చు. ఏ పాలసీ మరియు సాధారణ పాలసీల మధ్య గణనీయమైన తేడాలు లేవు, అయితే సుమారు 20% పెరిగిన CPU వినియోగాన్ని ట్రాక్ చేయవద్దు:
రెండవ పరీక్షలో, మేము మా క్లయింట్లు సృష్టించగలిగేన్ని కనెక్షన్‌లను ప్రారంభించాము మరియు మా మెమ్‌క్యాచ్డ్ సర్వర్ హ్యాండిల్ చేయగల సెకనుకు గరిష్ట సంఖ్యలో కనెక్షన్‌లను కొలిచాము. ఊహించినట్లుగానే, “నో పాలసీ” మరియు “రెగ్యులర్ పాలసీ” కేసులు రెండూ సెకనుకు 4,000 కనెక్షన్ల కంటే ఎక్కువ కనెక్షన్ల పరిమితిని చేరుకున్నాయి (512k / 120s = 4,369 కనెక్షన్‌లు/s). ట్రాక్ చేయని విధానంతో, మా క్లయింట్లు సెకనుకు 60,000 కనెక్షన్‌లను ఎటువంటి సమస్యలు లేకుండా పంపారు. మేము మరింత మంది క్లయింట్‌లను జోడించడం ద్వారా ఈ సంఖ్యను పెంచగలమని మేము ఖచ్చితంగా అనుకుంటున్నాము, అయితే ఈ కథనం యొక్క అంశాన్ని వివరించడానికి ఈ సంఖ్యలు ఇప్పటికే సరిపోతాయని మేము భావిస్తున్నాము!
తీర్మానం
Conntrack ఒక ముఖ్యమైన కెర్నల్ ఫీచర్. అతను తన పనిని పరిపూర్ణంగా చేస్తాడు. ఇది తరచుగా కీ సిస్టమ్ భాగాలచే ఉపయోగించబడుతుంది. అయినప్పటికీ, కొన్ని నిర్దిష్ట సందర్భాలలో, కాంట్రాక్ కారణంగా రద్దీ అది అందించే సాధారణ ప్రయోజనాల కంటే ఎక్కువగా ఉంటుంది. ఈ దృష్టాంతంలో, కాలికో నెట్‌వర్క్ విధానాలను నెట్‌వర్క్ భద్రతను పెంచుతున్నప్పుడు కాంట్రాక్ వినియోగాన్ని ఎంపికగా నిలిపివేయడానికి ఉపయోగించవచ్చు. అన్ని ఇతర ట్రాఫిక్ కోసం, contrack మీ స్నేహితుడిగా కొనసాగుతుంది!
మా బ్లాగ్‌లోని ఇతర కథనాలను కూడా చదవండి:
మూలం: www.habr.com