कुछ वेबसाइटों पर रैंडम टीसीपी आरएसटी, क्या चल रहा है?


34

लघु संस्करण: मेरे नेटवर्क पर एक विंडोज सर्वर 2012 मशीन कुछ वेबसाइटों से जुड़ते समय लगातार लेकिन रुक-रुक कर टीसीपी RSTs प्राप्त कर रही है। डनो वे कहाँ से आ रहे हैं। मेरे विश्लेषण और प्रश्नों के लिए वायरशार्क लॉग देखें।

दीर्घ संस्करण:

हम अपने छोटे से कार्यालय की सेवा के लिए अपने एक सर्वर पर कैशिंग वेब-प्रॉक्सी चलाते हैं। एक सहकर्मी ने बताया कि कुछ साइटों से जुड़ने पर बहुत सारे 'कनेक्शन रीसेट' या 'पेज प्रदर्शित नहीं किए जा सकते हैं' त्रुटियों, लेकिन यह ताज़ा आमतौर पर इसे ठीक करता है।

मैंने ब्राउज़र व्यवहार को सत्यापित किया, और फिर सर्वर पर अन-प्रॉक्सिड ब्राउज़र की कोशिश करके सीधे और अधिक। लेकिन परेशान साइटों के लिए पिंग और अनुरेखक कोई समस्या नहीं दिखाते हैं, मुद्दों को tcp कनेक्शन तक सीमित होना प्रतीत होता है।

मैंने तब प्रभावित स्थलों का परीक्षण करने के लिए एक स्क्रिप्ट बनायी थी, उन्हें सीधे HTTP HEAD अनुरोधों को CURL के माध्यम से भेजकर और जाँच कर कि वे कितनी बार सफल हुए। एक सामान्य परीक्षण इस तरह दिखता है: (यह असंसाधित है, सीधे खराब सर्वर पर चल रहा है)

C:\sdk\Apache24\htdocs>php rhTest.php
Sending HTTP HEAD requests to "http://www.washingtonpost.com/":
20:21:42: Length: 0     Response Code: NULL (0%)
20:22:02: Length: 0     Response Code: NULL (0%)
20:22:22: Length: 0     Response Code: NULL (0%)
20:22:42: Length: 0     Response Code: NULL (0%)
20:23:02: Length: 3173  Response Code: HTTP/1.1 302 Moved Temporarily (20%)
20:23:22: Length: 3174  Response Code: HTTP/1.1 302 Moved Temporarily (33.33%)
20:23:43: Length: 0     Response Code: NULL (28.57%)
20:24:03: Length: 3171  Response Code: HTTP/1.1 302 Moved Temporarily (37.5%)
20:24:23: Length: 3173  Response Code: HTTP/1.1 302 Moved Temporarily (44.44%)
20:24:43: Length: 3172  Response Code: HTTP/1.1 302 Moved Temporarily (50%)
20:25:03: Length: 0     Response Code: NULL (45.45%)

लंबी अवधि में, केवल 60% अनुरोध ही सफल होते हैं, बाकी कुछ भी नहीं मिलता है, कर्ल त्रुटि कोड के साथ: "cURL त्रुटि (56): सहकर्मी से डेटा प्राप्त करते समय विफलता" बुरा व्यवहार वेबसाइटों के लिए संगत है परीक्षण (कोई साइट कभी बेहतर नहीं हुई)) और यह काफी लगातार है, मैं अब एक सप्ताह के लिए समस्या निवारण कर रहा हूं, और सह-कार्यकर्ता रिपोर्ट करते हैं कि समस्या जाहिरा तौर पर महीनों से है।

मैंने अपने नेटवर्क पर अन्य मशीनों पर HEAD अनुरोध स्क्रिप्ट का परीक्षण किया: कोई समस्या नहीं, सभी कनेक्शन मेरी परीक्षण सूची के सभी साइटों से गुजरते हैं। तब मैंने अपने व्यक्तिगत डेस्कटॉप पर एक प्रॉक्सी स्थापित की, और जब मैं समस्याग्रस्त सर्वर से HEAD अनुरोधों को चलाता हूं, हालांकि, सभी कनेक्शन से गुजरते हैं। तो जो भी समस्या है, यह इस सर्वर के लिए बहुत विशिष्ट है।

अगला मैंने अलग करने की कोशिश की कि कौन सी वेबसाइटें कनेक्शन-रीसेट व्यवहार प्रदर्शित करती हैं:

  • हमारे इंट्रानेट साइटों में से कोई भी (192.168.xx) ड्रॉप कनेक्शन।
  • कोई आईपीवी 6 साइट नहीं जो मैंने ड्रॉप कनेक्शन का परीक्षण किया है। (हम दोहरे हैं)
  • केवल इंटरनेट ipv4 साइटों के एक छोटे से अल्पसंख्यक कनेक्शन ड्रॉप।
  • हर साइट जो क्लाउडफ्लेयर का उपयोग सीडीएन (जो मैंने परीक्षण किया है) के कनेक्शन से करती है। (लेकिन समस्या क्लाउडफ़ेयर साइटों के लिए अनन्य नहीं लगती है)

यह कोण वास्तव में सहायक कुछ भी विकसित नहीं हो रहा था, इसलिए जब मैंने एक अनुरोध विफल हो रहा था, तो यह देखने के लिए कि मैंने क्या किया है, यह देखने के लिए मैंने वायरशार्क स्थापित किया। एक असफल HEAD अनुरोध इस तरह दिखता है: (यहां बड़ा स्क्रीनशॉट: http://imgur.com/TNfRUtX )

127 48.709776000    192.168.1.142   192.33.31.56    TCP 66  52667 > http [SYN, ECN, CWR] Seq=0 Win=8192 Len=0 MSS=8960 WS=256 SACK_PERM=1
128 48.728207000    192.33.31.56    192.168.1.142   TCP 66  http > 52667 [SYN, ACK, ECN] Seq=0 Ack=1 Win=42340 Len=0 MSS=1460 SACK_PERM=1 WS=128
129 48.728255000    192.168.1.142   192.33.31.56    TCP 54  52667 > http [ACK] Seq=1 Ack=1 Win=65536 Len=0
130 48.739371000    192.168.1.142   192.33.31.56    HTTP    234 HEAD / HTTP/1.1 
131 48.740917000    192.33.31.56    192.168.1.142   TCP 60  http > 52667 [RST] Seq=1 Win=0 Len=0
132 48.757766000    192.33.31.56    192.168.1.142   TCP 60  http > 52667 [ACK] Seq=1 Ack=181 Win=42240 Len=0
133 48.770314000    192.33.31.56    192.168.1.142   TCP 951 [TCP segment of a reassembled PDU]
134 48.807831000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
135 48.859592000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
138 49.400675000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
139 50.121655000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
141 51.564009000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
143 54.452561000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897

जिस तरह से मैं इसे पढ़ रहा हूं (सही होने पर मुझे गलत, यह वास्तव में मेरा क्षेत्र नहीं है) वह है:

  • हम वेबसर्वर के लिए एक tcp कनेक्शन खोलते हैं
  • वेबसर्वर ACK's
  • HTTP HEAD रिक्वेस्ट सेंड होती है
  • वेबसर्वर आईपी से चिह्नित एक आरएसटी पैकेट है, जो कनेक्शन को मारता है।
  • वेबसर्वर ACK भेजता है
  • वेबसर्वर (HTTP) मान्य HTTP डेटा के साथ HEAD अनुरोध का जवाब देने के लिए (951 बाइट उत्तर में सही HTTP हेडर शामिल हैं)
  • वेबसर्वर retransmits (कई सेकंड में कई बार) वैध HTTP प्रतिक्रिया, लेकिन यह सफल नहीं हो सकता क्योंकि कनेक्शन RST हो गया है

इसलिए यदि वेबसर्वर ने वैध आरएसटी भेजा है, तो वह अनुरोध को भरने की कोशिश क्यों करता है? और अगर वेबसर्वर ने RST उत्पन्न नहीं किया, तो बिल्ली ने क्या किया?

जिन चीजों की मैंने कोशिश की है उनका कोई प्रभाव नहीं पड़ा है:

  • एनआईसी टीमिंग को अक्षम करना
  • नेटवर्क एडॉप्टर को बदलना (एनआईसी को बदलने के लिए जाना जाता था)
  • एक स्थिर आईपी असाइन करना।
  • IPv6 अक्षम करना।
  • जंबो फ्रेम को अक्षम करना।
  • हमारे स्विच और राउटर को दरकिनार करते हुए, सर्वर एक रात में सीधे हमारे मॉडेम में पहुंच जाता है।
  • विंडोज़ फ़ायरवॉल को बंद करना।
  • Netsh के माध्यम से टीसीपी सेटिंग्स को रीसेट करना
  • सर्वर पर व्यावहारिक रूप से हर दूसरी सेवा को अक्षम करना। (हम ज्यादातर इसे एक फाइलर के रूप में उपयोग करते हैं, लेकिन अपाचे और एक जोड़े डीबी है)
  • डेस्क पर सिर पीटना (बार-बार)

मुझे संदेह है कि सर्वर पर कुछ आरएसटी पैकेट उत्पन्न कर रहा है, लेकिन मेरे जीवन के लिए मैं इसे नहीं पा सकता हूं। मुझे लगता है कि अगर मुझे पता था: यह सिर्फ यह सर्वर क्यों है? या केवल कुछ वेबसाइट ही क्यों? यह बहुत मदद करेगा। जबकि मैं अभी भी उत्सुक हूं, मैं कक्षा से शुरू करने और शुरू करने के लिए तेजी से इच्छुक हूं।

विचार / सुझाव?

-धन्यवाद


यह कैशिंग प्रॉक्सी सर्वर किस ऑपरेटिंग सिस्टम को चलाता है? और प्रॉक्सी सर्वर सॉफ्टवेयर क्या है?
माइकल हैम्पटन

1
सर्वर विंडोज सर्वर 2012 चला रहा है, प्रॉक्सी 3.3.3 स्क्वॉयड के माध्यम से चल रहा है; लेकिन यह मशीन से सभी टीसीपी कनेक्शन के लिए होता है, न कि केवल प्रॉक्सी के कनेक्शन से। कर्ल परीक्षण स्क्रिप्ट अप्रमाणित है।
मॉर्टी

जवाबों:


38

आपके पैकेट कैप्चर में कुछ असामान्य था: ECN बिट्स को आउटगोइंग SYN पैकेट में सेट किया गया था।

स्पष्ट भीड़ अधिसूचना आईपी ​​प्रोटोकॉल का एक विस्तार है जो मेजबानों को नेटवर्क भीड़ के लिए और अधिक तेज़ी से प्रतिक्रिया करने की अनुमति देता है। यह पहली बार 15 साल पहले इंटरनेट पर पेश किया गया था, लेकिन जब इसे पहली बार तैनात किया गया था, तब गंभीर मुद्दे थे । उनमें से सबसे गंभीर यह था कि ईसीएन बिट्स सेट के साथ एक SYN पैकेट प्राप्त करने पर कई फायरवॉल या तो पैकेट छोड़ देंगे या एक आरएसटी वापस कर देंगे ।

परिणामस्वरूप, अधिकांश ऑपरेटिंग सिस्टम डिफ़ॉल्ट रूप से ईसीएन को अक्षम कर देते हैं, कम से कम आउटगोइंग कनेक्शन के लिए। नतीजतन, मुझे संदेह है कि बहुत सारी साइटें (और फ़ायरवॉल विक्रेताओं!) ने कभी भी अपने फ़ायरवॉल को ठीक नहीं किया ।

विंडोज सर्वर 2012 तक जारी किया गया था। Microsoft ने ऑपरेटिंग सिस्टम संस्करण के साथ डिफ़ॉल्ट रूप से ECN को सक्षम किया

दुर्भाग्य से किसी ने भी हाल ही में स्मृति में ईसीएन के लिए इंटरनेट साइटों की प्रतिक्रियाओं का कोई महत्वपूर्ण परीक्षण नहीं किया है, इसलिए यह पता लगाना मुश्किल है कि क्या 2000 के दशक की शुरुआत में देखी गई समस्याएं अभी भी विलुप्त हैं, लेकिन मुझे दृढ़ता से संदेह है कि वे हैं और आपका ट्रैफ़िक कम से कम है कुछ समय, इस तरह के उपकरणों के माध्यम से गुजर रहा है।

मेरे डेस्कटॉप पर ECN को सक्षम करने के बाद और फिर Wireshark पर फायरिंग करने से कुछ ही सेकंड पहले मैंने एक होस्ट का उदाहरण पकड़ा, जिसमें से SYN और ECN सेट के साथ एक पैकेट पर RST मिला, हालांकि अधिकांश होस्ट ठीक काम करने लगते हैं। शायद मैं खुद ही इंटरनेट स्कैन करने जाऊँगा ...

यदि समस्या साफ़ होती है, तो आप अपने सर्वर पर ECN को अक्षम करने का प्रयास कर सकते हैं। यह आपको DCTCP का उपयोग करने में असमर्थ बना देगा, लेकिन एक छोटे से कार्यालय में यह बहुत कम संभावना है कि आप ऐसा कर रहे हैं या ऐसा करने की कोई आवश्यकता है।

netsh int tcp set global ecncapability=disabled

4
धन्यवाद! ECN को अक्षम करने के बाद मैं सबसे अधिक परेशानी वाली साइटों के कनेक्शन के लिए 100% सफलता दर देख रहा हूँ! हमें अपने प्रॉक्सी को वापस चालू करने से पहले सुबह और परीक्षण करना होगा, लेकिन मैं आगे बढ़ने जा रहा हूं और दोनों के जवाब के रूप में इसे चिन्हित करने जा रहा हूं और माइक्रोसॉफ्ट क्यूए के उपयोगकर्ताओं पर लगातार युद्ध में एक और मुंहतोड़ जीत।
मोर्टी

9
निष्पक्ष होने के लिए, मुझे नहीं लगता कि यह Microsoft की गलती है कि कुछ फ़ायरवॉल प्रवेश बेवकूफ हैं। ईसीएन बहुत अच्छा है, क्योंकि यह बहुत मदद करता है, और यह अच्छा होगा यदि हम सभी इसका उपयोग करना शुरू कर सकते हैं ... किसी दिन।
माइकल हैम्पटन

ओह, मुझे आश्चर्य है कि अगर यह उम्र के लिए Imgur और Wikia से मिल रहा है कि कितने टन का वर्णन करता है (दो अलग-अलग स्थानीय ISPs के साथ होता है, लेकिन कभी नहीं जब वीपीएन किसी अन्य देश के माध्यम से होता है, जो मुझे भ्रमित करता है)
grawity

मुझे संदेह है (लेकिन स्पष्ट रूप से साबित नहीं हो सकता है) कि इसके लिए जिम्मेदार कुछ मशीनें डिफ़ॉल्ट-मुक्त क्षेत्र में गुप्त हैं।
माइकल हैम्पटन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.