एक SYN पैकेट के जवाब में एक सर्वर SYN / ACK पैकेट क्यों नहीं भेजेगा

Question

हाल ही में, हम एक टीसीपी कनेक्शन मुद्दे से अवगत हो गए हैं जो ज्यादातर मैक और लिनक्स उपयोगकर्ताओं तक सीमित है जो हमारी वेबसाइटों को ब्राउज़ करते हैं।

उपयोगकर्ता के दृष्टिकोण से, यह खुद को हमारी वेबसाइटों (> 11 सेकंड) के लिए वास्तव में लंबे कनेक्शन के समय के रूप में प्रस्तुत करता है।

हम इस समस्या के तकनीकी हस्ताक्षर को ट्रैक करने में कामयाब रहे हैं, लेकिन यह पता नहीं लगा सकते हैं कि ऐसा क्यों हो रहा है या इसे कैसे ठीक किया जाए।

असल में, क्या हो रहा है कि क्लाइंट की मशीन टीसीपी कनेक्शन स्थापित करने के लिए SYN पैकेट भेज रही है और वेब सर्वर इसे प्राप्त करता है, लेकिन SYN / ACK पैकेट के साथ प्रतिक्रिया नहीं करता है। क्लाइंट द्वारा कई SYN पैकेट भेजे जाने के बाद, सर्वर अंततः SYN / ACK पैकेट के साथ प्रतिक्रिया करता है और शेष कनेक्शन के लिए सब कुछ ठीक है।

और, ज़ाहिर है, समस्या के लिए किकर: यह आंतरायिक है और हर समय नहीं होता है (हालांकि यह समय के 10-30% के बीच होता है)

हम वेब सर्वर के रूप में Fedora 12 Linux को OS और Nginx के रूप में उपयोग कर रहे हैं।

वायरशार्क विश्लेषण का स्क्रीनशॉट

अपडेट करें:

क्लाइंट पर विंडो स्केलिंग को बंद करने से समस्या हो रही है। अब मुझे बस एक सर्वर साइड रिज़ॉल्यूशन की आवश्यकता है (हम सभी क्लाइंट ऐसा नहीं कर सकते) :)

अंतिम अद्यतन:

इसका समाधान था कि हमारे सर्वर पर टीसीपी विंडो स्केलिंग और टीसीपी टाइमस्टैम्प दोनों को बंद कर दिया जाए जो जनता के लिए सुलभ हो।

Comments

मुझे लगता है कि हमें इसके कुछ tcpdump होते हुए देखने की आवश्यकता होगी।

— coredump

क्या आपके पास रिवर्स डीएनएस के आधार पर कोई एसेल्स या नियम हैं? आपको क्लाइंट और सर्वर के बीच कनेक्शन को और अधिक देखने की आवश्यकता हो सकती है। शायद एक डीएनएस लुक आउट टाइमिंग कर रहा है?

— ज़ॉर्दाचे

@coredump: यहां वायरशर्क विश्लेषण का एक स्क्रीन शॉट दिखाया गया है जो इस मुद्दे को दिखाता है i.imgur.com/Bnzrm.png (यह पता नहीं लगा सकता है कि बस स्ट्रीम कैसे निर्यात करें ....)

— कोडमेकन

@Zoredache: नहीं, हमारे पास रिवर्स डीएनएस के आधार पर कोई भी ऐस या नियम नहीं है। यह एक वेबसर्वर का सामना करने वाली जनता है और हम सभी को इसे एक्सेस करने की अनुमति देते हैं

— कोडनेम

बस एक कूबड़ है, लेकिन क्या आप सर्वर पर किसी भी तरह के इनकमिंग कनेक्शन को सीमित कर रहे हैं? कहो, iptables के साथ?

— स्टीवन सोमवार

Answer 1

हमारी यह वही समस्या थी। बस टीसीपी टाइमस्टैम्प को अक्षम करने से समस्या हल हो गई।

sysctl -w net.ipv4.tcp_timestamps=0

इस परिवर्तन को स्थायी बनाने के लिए, एक प्रविष्टि करें /etc/sysctl.conf।

टीसीपी विंडो स्केल विकल्प को अक्षम करने के बारे में बहुत सावधान रहें। यह विकल्प इंटरनेट पर अधिकतम प्रदर्शन प्रदान करने के लिए महत्वपूर्ण है । 10 मेगाबिट / सेकंड कनेक्शन वाले किसी व्यक्ति के पास एक सबॉप्टिमल ट्रांसफर होगा, यदि राउंड ट्रिप का समय (मूल रूप से पिंग के समान) 55 एमएस से अधिक है।

हमने वास्तव में इस समस्या पर ध्यान दिया जब एक ही NAT के पीछे कई उपकरण थे। मुझे संदेह है कि सर्वर उसी समय एंड्रॉइड डिवाइस और OSX मशीनों से टाइमस्टैम्प को देखकर भ्रमित हो गया होगा क्योंकि वे टाइमस्टैम्प क्षेत्रों में पूरी तरह से अलग-अलग मान रखते हैं।

Comments

यदि कोई व्यक्ति उसी खरगोश के छेद के माध्यम से यहाँ समाप्त होता है जो मैं अभी नीचे गया था: टीसीपी टाइमस्टैम्प या विंडो स्केलिंग को बंद करने से पहले, जो उच्च-ट्रैफ़िक लिंक पर गंभीर प्रदर्शन परिणाम हो सकता है, यह देखने के लिए जांचें कि क्या tcp_tw_recycle आपकी समस्या है: stackoverflow .com / प्रश्न / 8893888 /…

— नेफेट्स

Answer 2

मेरे मामले में निम्नलिखित कमांड ने लिनक्स सर्वर से लापता SYN / ACK उत्तरों के साथ समस्या तय की:

sysctl -w net.ipv4.tcp_tw_recycle=0

मुझे लगता है कि यह टीसीपी टाइमस्टैम्प को अक्षम करने से अधिक सही है, क्योंकि टीसीपी टाइमस्टैम्प उच्च प्रदर्शन (पीएडब्ल्यूएस, विंडो स्केलिंग, आदि) के लिए उपयोगी है ।

दस्तावेज़ में tcp_tw_recycleस्पष्ट रूप से कहा गया है कि इसे सक्षम करने की अनुशंसा नहीं की गई है, क्योंकि कई NAT राउटर टाइमस्टैम्प को संरक्षित करते हैं और इस प्रकार PAWS में किक करता है, क्योंकि समान IP से टाइमस्टैम्प संगत नहीं हैं।

   tcp_tw_recycle (Boolean; default: disabled; since Linux 2.4)
          Enable fast recycling of TIME_WAIT sockets.  Enabling this
          option is not recommended for devices communicating with the
          general Internet or using NAT (Network Address Translation).
          Since some NAT gateways pass through IP timestamp values, one
          IP can appear to have non-increasing timestamps.  See RFC 1323
          (PAWS), RFC 6191.

Comments

यहां पर अच्छा स्पष्टीकरण: vincent.bernat.im/en/blog/2014-tcp-time-wait-state-linux जब तक आप यकीन है कि आप नेट उपकरणों है कभी नहीं होगा रहे हैं सर्वर साइड पर net.ipv4.tcp_tw_recycle सक्षम नहीं करते मिश्रण में।

— Gnought

मेरे मामले में, net.ipv4.tcp_tw_recycleअसली कारण है। धन्यवाद।

— ब्लूएरो

हाल की गुठली में tcp_tw_recycle हटा दिया गया है। क्या एक और समाधान एक जैसा है? @nephtes का अर्थ है टाइमस्टैम्प को अक्षम करना प्रदर्शन को नुकसान पहुंचाता है।

— मप्पा

चूँकि tcp_tw_recycle को हटा दिया गया है, इसलिए समस्या फिर से नहीं होनी चाहिए क्योंकि यह केवल tcp_tw_recycle के गैर-डिफ़ॉल्ट मान के साथ हुआ है।

— लव

Answer 3

बस सोच रहा था, लेकिन SYN पैकेट (फ्रेम # 539; जिसे स्वीकार किया गया था) के लिए, "जानकारी" कॉलम में WS और TSV फ़ील्ड गायब हैं?

WS, TCP विंडो स्केलिंग है और TSV टाइमस्टैम्प वैल्यू है । वे दोनों tcp.options फ़ील्ड के अंतर्गत पाए जाते हैं और अगर वे मौजूद हैं तो Wireshark को अभी भी उन्हें दिखाना चाहिए। हो सकता है कि क्लाइंट टीसीपी / आईपी स्टैक 8 वें प्रयास पर अलग-अलग SYN पैकेट पर नाराजगी जताए और यही वजह थी कि इसे अचानक स्वीकार कर लिया गया?

क्या आप हमें 539 आंतरिक मूल्य प्रदान कर सकते हैं? क्या SYN / ACK हमेशा SYN पैकेट के लिए आता है जिसमें WS सक्षम नहीं है?

Comments

@Ansis: यहाँ के लिए फ्रेम 539 विवरण कुछ स्क्रीन शॉट्स (दो भागों में यह करना ही था) है: i.imgur.com/D84GC.png और i.imgur.com/4riq3.png

— codemonkey

@ कोडिमेक: आपका 8 वां SYN पैकेट पहले सात SYN पैकेट से अलग प्रतीत होता है। क्या सर्वर SYN / ACK के साथ क्लाइंट के SYN पर केवल तभी प्रतिक्रिया करता है जब tcp.options फ़ील्ड का आकार 8 बाइट्स होता है (पहले सात SYN पैकेटों में संभवतः 20 बाइट्स के tcp.options होते हैं।)? क्या आप समस्या को गायब करने के लिए क्लाइंट की तरफ से टीसीपी विंडो स्केलिंग को अक्षम कर सकते हैं? सर्वर साइड पर टीसीपी / आईपी स्टैक के साथ एक समस्या की तरह लगता है या कहीं-कहीं फ़ायर फ़ायर किया गया है ...

— हंस सोलो

@ एनिस: हाँ, मैं देख रहा हूँ कि जब से आपने इसे इंगित किया है और अन्य सभी SYN पैकेट 24 बाइट हैं। मैं क्लाइंट पर विंडो स्केलिंग को अक्षम करने का प्रयास करूंगा और सुबह परिणामों के साथ वापस जांच करूंगा।

— कोडनेमिज

@ एनिस: क्लाइंट पर स्केलिंग करने वाली विंडो बंद करने से समस्या होने से रुक गई। धन्यवाद! हालांकि, अब मैं यह पता लगाने कैसे सर्वर साइड पर इसे ठीक करने (के बाद से हम अपने सभी ग्राहकों को निष्क्रिय खिड़कियों स्केलिंग नहीं कर सकते हैं) की जरूरत है :) प्रश्न में सर्वर है net.ipv4.tcp_windows_scaling = 1

— codemonkey

@ कोडिमेक: मैं मानता हूं कि सभी ग्राहकों पर WS को अक्षम करना एक समाधान नहीं है, लेकिन हमने कम से कम WS / पैकेट आकार के मुद्दों पर नज़र रखी है। कारण खोजने के लिए हमें यह देखना चाहिए कि आपका फ़ायरवॉल कैसे कॉन्फ़िगर किया गया है। क्या आप टीसीपी कनेक्शन को डब्ल्यूएसपी के साथ अलग-अलग टीसीपी पोर्ट में स्थापित कर सकते हैं? विभिन्न स्रोत IP से?

— हंस सोलो

Answer 4

हम बस उसी समस्या में भाग गए (वास्तव में इसे सिंक करने में सर्वर को पिन करने के लिए काफी समय लग गया है।

"समाधान जनता के लिए सुलभ हमारे सर्वर पर tcp विंडोज़ स्केलिंग और tcp टाइमस्टैम्प को बंद करना था।"

Answer 5

Ansis ने जो बताया है उसे आगे बढ़ाने के लिए, मैंने इस तरह के मुद्दों को देखा है जब फ़ायरवॉल टीसीपी विंडोज स्केलिंग का समर्थन नहीं करता है। इन दो मेजबानों के बीच क्या / मॉडल फ़ायरवॉल है?

Comments

फ़ायरवॉल iptables का उपयोग करके एक फेडोरा 13 बॉक्स है। net.ipv4.tcp_windows_scaling भी इस मशीन पर 1 पर सेट है

— codemonkey

Answer 6

लापता SYN / ACK फ़ायरवॉल पर आपके SYNFLOOD सुरक्षा की बहुत कम सीमा के कारण हो सकता है। यह आपके सर्वर उपयोगकर्ता के कितने कनेक्शन पर निर्भर करता है। स्पडी का उपयोग करने से कनेक्शन की संख्या कम हो जाती है और ऐसी स्थिति में मदद मिल सकती है जहां net.ipv4.tcp_timestampsबंद करने से मदद नहीं मिलती है।

Answer 7

यह सुनने वाले टीसीपी सॉकेट का व्यवहार है जब इसका बैकलॉग भरा होता है।

Ngnix बैकलॉग तर्क को कॉन्फ़िगरेशन में सेट करने के लिए सुनने की अनुमति देता है: http://wiki.nginx.org/HttpCoreModule#listen

80 बैकलॉग = सुने

डिफ़ॉल्ट से कुछ बड़ा करने के लिए संख्या सेट करने का प्रयास करें, जैसे 1024।

मैं इस बात की कोई गारंटी नहीं देता कि एक पूर्ण श्रवण कतार वास्तव में आपकी समस्या है, लेकिन यह जांचने के लिए एक अच्छी पहली बात है।

Comments

पारितोषिक के लिए धन्यवाद। मुझे इसे आज़माना है। हमने ओएस स्तर पर बैकलॉग सेट किया है, लेकिन स्पष्ट रूप से नगीनक्स कॉन्फ़िगरेशन में नहीं। मैं परिणाम के साथ अद्यतन करूँगा।

— कोडनेम

इसने व्यवहार को बिल्कुल नहीं बदला। लगता है, यह समस्या नहीं है? या एकमात्र समस्या ...

— कोडमेक

आवेदन स्तर बैकलॉग पैरामीटर पूर्ण टीसीपी कनेक्शन के लिए कतार के आकार को नियंत्रित करता है अर्थात 3-रास्ता हैंडशेक समाप्त, यानी सिंक-एकैक प्राप्त हुआ - इसलिए यह ओपी स्थिति से मेल नहीं खाता

— ygrek

Answer 8

मैंने अभी पता लगाया है कि लिनक्स टीसीपी क्लाइंट 3 कोशिशों के बाद अपने SYN पैकेट को बदलते हैं, और विंडो स्केलिंग विकल्प को हटाते हैं। मुझे लगता है कि कर्नेल डेवलपर्स को लगा कि यह इंटरनेट में कनेक्शन विफलता का एक सामान्य कारण है

यह बताता है कि ये क्लाइंट 11 सेकंड के बाद कनेक्ट करने का प्रबंधन क्यों करते हैं (विंडो-कम टीसीपी SYN 9 सेकंड के बाद मेरी संक्षिप्त परीक्षा में डिफ़ॉल्ट सेटिंग्स के साथ होता है)

Answer 9

मुझे एक समान समस्या थी, लेकिन मेरे मामले में यह टीसीपी चेकसम था जिसे गलत तरीके से गणना की गई थी। क्लाइंट एक वीथ के पीछे था और टीटी को बंद करने के लिए एथिकल-के वीटी 0 आरएक्स चला रहा था।