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


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

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

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

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

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

हम वेब सर्वर के रूप में ओएस और Nginx के रूप में फेडोरा 12 लिनक्स का उपयोग कर रहे हैं।

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

Screenshot of wireshark analysis

अद्यतन करें:

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

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

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


37
2018-02-15 22:54


मूल


मुझे लगता है कि हमें कुछ टीसीपीडम्प होने की आवश्यकता होगी। - coredump
क्या आपके पास रिवर्स डीएनएस के आधार पर कोई एसीएल या नियम है? आपको क्लाइंट और सर्वर के बीच कनेक्शन को और अधिक देखने की आवश्यकता हो सकती है। शायद एक DNS लुकअप समय समाप्त हो रहा है? - Zoredache
@coredump: यहां वायरसहार्क विश्लेषण का एक स्क्रीन शॉट है जो इस मुद्दे को दिखाता है i.imgur.com/Bnzrm.png  (केवल स्ट्रीम को निर्यात करने का तरीका नहीं पता था ....) - codemonkey
@Zoredache: नहीं, हमारे पास रिवर्स डीएनएस के आधार पर कोई एसीएल या नियम नहीं है। यह एक सार्वजनिक सामना करने वाला वेबसर्वर है और हम सभी को इसका उपयोग करने की अनुमति देते हैं - codemonkey
बस एक झटका, लेकिन क्या आप किसी भी तरह की आने वाली कनेक्शन दर-सर्वर पर सीमित कर रहे हैं? Iptables के साथ कहो? - Steven Monday


जवाब:


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

sysctl -w net.ipv4.tcp_timestamps=0

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

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

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


11
2018-04-05 16:26



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


मेरे मामले में निम्न आदेश ने लिनक्स सर्वर से अनुपलब्ध SYN / ACK उत्तरों के साथ समस्या को हल किया:

sysctl -w net.ipv4.tcp_tw_recycle=0

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

पर प्रलेखन tcp_tw_recycle स्पष्ट रूप से बताता है कि इसे सक्षम करने की अनुशंसा नहीं की जाती है, क्योंकि कई एनएटी राउटर टाइमस्टैम्प को संरक्षित करते हैं और इस प्रकार पीएडब्ल्यूएस किक करता है, क्योंकि एक ही आईपी से टाइमस्टैम्प लगातार नहीं होते हैं।

   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.

9
2018-06-27 13:47



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


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

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

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


5
2018-02-16 00:29



@ एन्सिस: फ्रेम 539 विवरण के लिए यहां कुछ स्क्रीन शॉट्स हैं (इसे दो भागों में करना था): i.imgur.com/D84GC.png और i.imgur.com/4riq3.png - codemonkey
@codemonkey: आपका 8 वां SYN पैकेट पहले सात SYN पैकेट से अलग प्रतीत होता है। क्या सर्वर केवल एसईएन / एसीके के साथ ग्राहक के SYN पर प्रतिक्रिया करता है जब tcp.options फ़ील्ड आकार 8 बाइट्स का होता है (पहले सात SYN पैकेट्स में आकार 20 बाइट्स के tcp.options होते हैं।)? क्या आप क्लाइंट पक्ष पर टीसीपी विंडो स्केलिंग को अक्षम कर सकते हैं यह देखने के लिए कि समस्या गायब हो जाती है या नहीं? सर्वर पक्ष पर टीसीपी / आईपी स्टैक या गलत कॉन्फ़िगर किए गए फ़ायरवॉल के साथ किसी समस्या की तरह लगता है ... - Hans Solo
@ एन्सिस: हाँ, मैं इसे देख रहा हूं क्योंकि आपने इसे इंगित किया है और अन्य सभी SYN पैकेट 24 बाइट हैं। मैं क्लाइंट पर विंडो स्केलिंग को अक्षम करने का प्रयास करूंगा और सुबह के परिणामों के साथ वापस जांच करूँगा। - codemonkey
@ एन्सिस: क्लाइंट पर विंडोज स्केलिंग बंद करने से इस मुद्दे को होने से रोक दिया गया। धन्यवाद! हालांकि, अब मुझे यह समझने की ज़रूरत है कि सर्वर पक्ष पर इसे कैसे ठीक किया जाए (क्योंकि हम अपने सभी क्लाइंट विंडोज स्केलिंग को अक्षम नहीं कर सकते हैं) :) प्रश्न में सर्वर net.ipv4.tcp_windows_scaling = 1 है - codemonkey
@ कोडमकी: मैं मानता हूं कि सभी ग्राहकों पर डब्ल्यूएस को अक्षम करना समाधान नहीं है, लेकिन हमने कम से कम इस मुद्दे को डब्ल्यूएस / पैकेट आकार के मुद्दों पर ट्रैक किया है। कारण को और जानने के लिए हमें यह देखना चाहिए कि आपकी फ़ायरवॉल कैसे कॉन्फ़िगर की गई है। क्या आप विभिन्न टीसीपी बंदरगाहों के लिए डब्ल्यूएस के साथ टीसीपी कनेक्शन स्थापित कर सकते हैं? विभिन्न स्रोत आईपी से? - Hans Solo


हम बस एक ही समस्या में भाग गए (वास्तव में सिंक-एक नहीं भेज रहे सर्वर पर पिन करने के लिए काफी समय लगा)।

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


4
2018-03-18 06:14





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


2
2018-02-16 01:15



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


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

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


1
2017-08-28 03:20





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


1
2018-05-20 12:11





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

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

80 बैकलॉग = num सुनो

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

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


0
2018-02-16 00:04



पारितोषिक के लिए धन्यवाद। मुझे इसे आज़माना है। हमने ओएस स्तर पर बैकलॉग सेट किया है, लेकिन स्पष्ट रूप से Nginx कॉन्फ़िगरेशन में नहीं है। मैं परिणाम के साथ अद्यतन करूँगा। - codemonkey
इसने व्यवहार को बिल्कुल नहीं बदला। मान लीजिए, यह समस्या नहीं है? या एकमात्र समस्या ... - codemonkey
आवेदन स्तर बैकलॉग पैरामीटर नियंत्रण पूर्ण टीसीपी कनेक्शन के लिए कतार का आकार यानी 3-तरफा हैंडशेक समाप्त हुआ, यानी syn-ack प्राप्त हुआ - इसलिए यह ओपी स्थिति से मेल नहीं खाता - ygrek