TCP RST แบบสุ่มในบางเว็บไซต์เกิดอะไรขึ้น


34

เวอร์ชั่นย่อ: เครื่อง Windows Server 2012 หนึ่งเครื่องบนเครือข่ายของฉันกำลังได้รับการขัดจังหวะ แต่ TCP RSTs เป็นระยะ ๆ เมื่อเชื่อมต่อกับเว็บไซต์บางแห่ง Dunno พวกเขามาจากไหน ตรวจสอบบันทึก wireshark สำหรับการวิเคราะห์และคำถามของฉัน

รุ่นยาว:

เราใช้เว็บแคชพร็อกซีบนเซิร์ฟเวอร์ของเราเพื่อให้บริการสำนักงานขนาดเล็กของเรา เพื่อนร่วมงานรายงานว่าได้รับข้อผิดพลาด 'รีเซ็ตการเชื่อมต่อ' หรือ 'ไม่สามารถแสดงหน้า' ได้จำนวนมากเมื่อเชื่อมต่อกับบางไซต์ แต่การรีเฟรชมักจะแก้ไขได้

ฉันตรวจสอบพฤติกรรมของเบราว์เซอร์แล้วลองอีกครั้งโดยตรงโดยใช้เบราว์เซอร์ที่ไม่ได้ใช้พร็อกซีบนเซิร์ฟเวอร์ แต่การ ping & traceroutes ไปยังไซต์ที่มีปัญหาจะไม่แสดงปัญหาใด ๆ ปัญหาดูเหมือนว่าจะ จำกัด เฉพาะการเชื่อมต่อ 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 ของ: "ข้อผิดพลาด cURL (56): ความล้มเหลวเมื่อรับข้อมูลจากเพียร์" พฤติกรรมที่ไม่เหมาะสมสอดคล้องกับเว็บไซต์ การทดสอบ (ไม่มีไซต์ใดที่ 'ดีขึ้นกว่านี้') และค่อนข้างจะขัดขืนฉันได้รับการแก้ไขปัญหาเป็นเวลาหนึ่งสัปดาห์แล้วและเพื่อนร่วมงานรายงานว่าปัญหาอยู่ที่นั่นมาหลายเดือนแล้ว

ฉันทดสอบสคริปต์คำขอ HEAD ในเครื่องอื่น ๆ ในเครือข่ายของเรา: ไม่มีปัญหาการเชื่อมต่อทั้งหมดผ่านไปยังไซต์ทั้งหมดในรายการทดสอบของฉัน จากนั้นฉันจะตั้งค่าพร็อกซีบนเดสก์ท็อปส่วนบุคคลของฉันและเมื่อฉันเรียกใช้การร้องขอ HEAD จากเซิร์ฟเวอร์ที่มีปัญหาถึงแม้ว่าการเชื่อมต่อทั้งหมดจะผ่านไป ดังนั้นสิ่งที่เป็นปัญหาคือมันเฉพาะเจาะจงกับเซิร์ฟเวอร์นี้

ต่อไปฉันพยายามแยกเว็บไซต์ที่แสดงพฤติกรรมการเชื่อมต่อรีเซ็ต:

  • ไม่มีไซต์อินทราเน็ตของเรา (192.168.xx) การเชื่อมต่อที่ปล่อย
  • ไม่มีไซต์ ipv6 ฉันได้ทดสอบการเชื่อมต่อที่ลดลง (เราเป็น dual-stack)
  • เฉพาะเว็บไซต์อินเทอร์เน็ต ipv4 เพียงเล็กน้อยเท่านั้นที่ปล่อยการเชื่อมต่อ
  • ทุกไซต์ที่ใช้ cloudflare เป็น CDN (ที่ฉันได้ทดสอบ) จะลดการเชื่อมต่อ (แต่ปัญหาดูเหมือนจะไม่เป็นเอกสิทธิ์ของเว็บไซต์ cloudflare)

มุมนี้ไม่ได้พัฒนาเป็นอะไรที่มีประโยชน์จริง ๆ ดังนั้นต่อไปฉันติดตั้ง wireshark เพื่อดูว่าเกิดอะไรขึ้นเมื่อคำขอล้มเหลว คำขอ 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
  • คำขอ HTTP HEAD ถูกส่ง
  • มีแพ็กเก็ต RST ซึ่งทำเครื่องหมายว่ามาจากเว็บเซิร์ฟเวอร์ IP ที่ฆ่าการเชื่อมต่อ
  • เว็บเซิร์ฟเวอร์ส่ง ACK
  • เว็บเซิร์ฟเวอร์ (พยายาม) เพื่อตอบสนองต่อคำขอ HEAD ด้วยข้อมูล HTTP ที่ถูกต้อง (การตอบกลับ 951 ไบต์มีส่วนหัว HTTP ที่ถูกต้อง)
  • เว็บเซิร์ฟเวอร์ retransmits (หลายครั้งในช่วงหลายวินาที) การตอบสนอง HTTP ที่ถูกต้อง แต่มันไม่สามารถประสบความสำเร็จได้เนื่องจากการเชื่อมต่อเป็น RST

ดังนั้นหากเว็บเซิร์ฟเวอร์ได้ส่ง RST ที่ถูกต้องทำไมมันพยายามที่จะกรอกคำขอ? และถ้าเว็บเซิร์ฟเวอร์ไม่ได้สร้าง RST จะเกิดอะไรขึ้น

สิ่งที่ฉันลองซึ่งไม่มีผล:

  • ปิดการใช้งานการทำงานร่วมกันของ NIC
  • การเปลี่ยนอะแดปเตอร์เครือข่าย (การเปลี่ยน NIC เป็นที่ทราบกันว่าใช้งานได้)
  • การกำหนด IP แบบคงที่
  • ปิดใช้งาน ipv6
  • ปิดการใช้งานเฟรมจัมโบ้
  • เสียบเซิร์ฟเวอร์เข้ากับโมเด็มของเราโดยตรงหนึ่งคืนผ่านสวิตช์และเราเตอร์ของเรา
  • ปิดไฟร์วอลล์ windows
  • รีเซ็ตการตั้งค่า TCP ผ่าน netsh
  • ปิดการใช้งานจริงทุกบริการอื่น ๆ บนเซิร์ฟเวอร์ (ส่วนใหญ่เราใช้เป็นไฟล์เซิร์ฟเวอร์ แต่มี apache และ DB สองสามรายการ)
  • การกระแทกหัวบนโต๊ะ (ซ้ำ ๆ )

ฉันสงสัยว่ามีบางอย่างบนเซิร์ฟเวอร์กำลังสร้างแพ็กเก็ต RST แต่สำหรับชีวิตของฉันฉันไม่สามารถค้นหาได้ ฉันรู้สึกว่าถ้าฉันรู้: ทำไมมันเป็นแค่เซิร์ฟเวอร์นี้ หรือทำไมมีเพียงบางเว็บไซต์ มันช่วยได้มาก ในขณะที่ฉันยังสงสัยฉันมีแนวโน้มมากขึ้นที่จะนุกจากวงโคจรและเริ่มต้นใหม่

ความคิด / คำแนะนำ?

ขอบคุณ


พร็อกซีเซิร์ฟเวอร์แคชระบบปฏิบัติการใดที่ทำงานได้ และซอฟต์แวร์พร็อกซีเซิร์ฟเวอร์คืออะไร
Michael Hampton

1
เซิร์ฟเวอร์กำลังเรียกใช้ Windows Server 2012 พร็อกซี squid 3.3.3 ทำงานผ่าน cygwin; แต่สิ่งนี้เกิดขึ้นกับการเชื่อมต่อ TCP ทั้งหมดจากเครื่องไม่ใช่แค่การเชื่อมต่อของพร็อกซี สคริปต์ทดสอบ curl ยังไม่พร้อมใช้งาน
Morty

คำตอบ:


38

การจับแพ็คเก็ตของคุณมีบางสิ่งที่ผิดปกติ: บิต ECN ถูกตั้งค่าไว้ในแพ็คเก็ต SYN ขาออก

การแจ้งเตือนความแออัดอย่างชัดเจนเป็นส่วนขยายของโปรโตคอล IP ที่ช่วยให้โฮสต์สามารถตอบสนองต่อความแออัดของเครือข่ายได้เร็วขึ้น มันถูกนำมาใช้ครั้งแรกกับอินเทอร์เน็ตเมื่อ 15 ปีก่อน แต่มีปัญหาร้ายแรงที่ระบุไว้เมื่อมีการใช้งานครั้งแรก สิ่งที่ร้ายแรงที่สุดของพวกเขาก็คือไฟร์วอลล์จำนวนมากอาจปล่อยแพ็คเก็ตหรือส่งคืน RSTเมื่อได้รับแพ็คเก็ต SYN พร้อมชุดบิต ECN

เป็นผลให้ระบบปฏิบัติการส่วนใหญ่ปิดใช้งาน ECN ตามค่าเริ่มต้นอย่างน้อยที่สุดสำหรับการเชื่อมต่อขาออก ด้วยเหตุนี้ฉันจึงสงสัยว่าไซต์จำนวนมาก (และผู้จำหน่ายไฟร์วอลล์!) ไม่เคยแก้ไขไฟร์วอลล์ของตนเลย

จนกว่า Windows Server 2012 จะวางจำหน่าย Microsoft เปิดใช้งาน ECN โดยค่าเริ่มต้นเริ่มต้นด้วยรุ่นระบบปฏิบัติการนี้

น่าเสียดายที่ไม่มีใครในหน่วยความจำเมื่อเร็ว ๆ นี้ทำการทดสอบที่สำคัญเกี่ยวกับการตอบสนองของเว็บไซต์อินเทอร์เน็ตต่อ ECN ดังนั้นจึงเป็นการยากที่จะประเมินว่าปัญหาที่เกิดขึ้นในช่วงต้นยุค 2000 ยังคงมีอยู่ แต่ฉันสงสัยอย่างยิ่งว่า บางเวลาผ่านอุปกรณ์ดังกล่าว

หลังจากเปิดใช้งาน ECN บนเดสก์ท็อปของฉันแล้วเปิดใช้งาน Wireshark เพียงไม่กี่วินาทีก่อนที่ฉันจะได้เห็นตัวอย่างของโฮสต์ที่ฉันได้รับ RST ไปยังแพ็กเก็ตที่มีชุด SYN และ ECN แม้ว่าโฮสต์ส่วนใหญ่จะทำงานได้ดี บางทีฉันจะไปสแกนอินเทอร์เน็ตด้วยตัวเอง ...

คุณสามารถลองปิดการใช้งาน ECN บนเซิร์ฟเวอร์ของคุณเพื่อดูว่าปัญหาล้างออกหรือไม่ สิ่งนี้จะทำให้คุณไม่สามารถใช้ DCTCP ได้ แต่ในสำนักงานขนาดเล็กเป็นไปไม่ได้อย่างมากที่คุณจะทำเช่นนั้นหรือมีความจำเป็นต้องทำเช่นนั้น

netsh int tcp set global ecncapability=disabled

4
ขอขอบคุณ! หลังจากปิดใช้งาน ECN ฉันเห็นอัตราความสำเร็จ 100% สำหรับการเชื่อมต่อไปยังไซต์ที่ลำบากที่สุด! ฉันจะต้องทดสอบมากขึ้นในตอนเช้าก่อนที่จะเปิดใช้งานพร็อกซีของเราอีกครั้ง แต่ฉันจะดำเนินการต่อและทำเครื่องหมายสิ่งนี้เป็นคำตอบทั้งคู่และเป็นชัยชนะที่ยอดเยี่ยมอีกครั้งใน Microsoft QA
Morty

9
เพื่อความเป็นธรรมฉันไม่คิดว่าเป็นความผิดของ Microsoft ที่ผู้ดูแลระบบไฟร์วอลล์บางคนเป็นคนโง่ ECN นั้นดีมากเพราะมันช่วยได้มากและมันจะดีถ้าเราทุกคนสามารถใช้มันได้ ... สักวัน
Michael Hampton

โอ้ฉันสงสัยว่านี้อธิบายตันรีเซ็ตฉันได้รับจาก Imgur และ Wikia สำหรับทุกวัย (ที่เกิดขึ้นกับสองผู้ให้บริการอินเทอร์เน็ตในท้องถิ่นที่แตกต่างกัน แต่ไม่เคยเมื่อ VPN'd ผ่านประเทศอื่นซึ่งสร้างความสับสนให้ฉัน)
grawity

ฉันสงสัยว่า (แต่ไม่สามารถพิสูจน์ได้อย่างชัดเจน) ว่าบางเครื่องที่รับผิดชอบเรื่องนี้ซ่อนอยู่ในเขตปลอดค่าเริ่มต้น
Michael Hampton
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.