เหตุใดเซิร์ฟเวอร์จึงไม่ส่งแพ็กเก็ต SYN / ACK เพื่อตอบกลับแพ็คเก็ต SYN

เมื่อเร็ว ๆ นี้เราได้ตระหนักถึงปัญหาการเชื่อมต่อ TCP ที่ จำกัด เฉพาะผู้ใช้ mac และ Linux ที่เรียกดูเว็บไซต์ของเรา

จากมุมมองของผู้ใช้มันนำเสนอตัวเองเป็นเวลาเชื่อมต่อนานมากไปยังเว็บไซต์ของเรา (> 11 วินาที)

เราจัดการเพื่อติดตามลายเซ็นทางเทคนิคของปัญหานี้ แต่ไม่สามารถระบุสาเหตุที่เกิดขึ้นหรือวิธีแก้ไขได้

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

และแน่นอนนักเตะที่มีปัญหา: มันไม่ต่อเนื่องและไม่เกิดขึ้นตลอดเวลา (แม้ว่ามันจะเกิดขึ้นระหว่าง 10-30% ของเวลา)

เราใช้ Fedora 12 Linux เป็นระบบปฏิบัติการและ Nginx เป็นเว็บเซิร์ฟเวอร์

ภาพหน้าจอของการวิเคราะห์ wireshark

ปรับปรุง:

การปิดการปรับสเกลของหน้าต่างบนไคลเอนต์ทำให้ไม่สามารถเกิดปัญหาได้ ตอนนี้ฉันแค่ต้องการการแก้ปัญหาด้านเซิร์ฟเวอร์ (เราไม่สามารถทำให้ลูกค้าทุกคนทำได้) :)

การปรับปรุงครั้งสุดท้าย:

วิธีแก้ไขคือปิดทั้งการปรับสเกลหน้าต่าง TCP และการ ประทับเวลา TCPบนเซิร์ฟเวอร์ของเราที่สาธารณชนสามารถเข้าถึงได้

เรามีปัญหาเดียวกันนี้แน่นอน เพียงปิดใช้งานการประทับเวลา TCP เพื่อแก้ไขปัญหา

sysctl -w net.ipv4.tcp_timestamps=0

/etc/sysctl.confเพื่อให้การเปลี่ยนแปลงนี้อย่างถาวรทำให้รายการใน

ระมัดระวังในการปิดการใช้งานตัวเลือก TCP Window Scale ตัวเลือกนี้มีความสำคัญสำหรับการให้บริการที่มีประสิทธิภาพสูงสุดผ่านทางอินเทอร์เน็ต คนที่มีการเชื่อมต่อ 10 เมกะบิต / วินาทีจะมีการถ่ายโอนที่ไม่ดีหากเวลาไปกลับ (โดยทั่วไปเหมือนกับ ping) มากกว่า 55 ms

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

ในกรณีของฉันคำสั่งต่อไปนี้แก้ไขปัญหาที่ขาดหายไป SYN / ACK ตอบกลับจากเซิร์ฟเวอร์ Linux:

sysctl -w net.ipv4.tcp_tw_recycle=0

ฉันคิดว่าถูกต้องมากกว่าการปิดใช้งานการประทับเวลา TCP เนื่องจากการประทับเวลา TCP มีประโยชน์สำหรับประสิทธิภาพสูง (PAWS การปรับขนาดหน้าต่าง ฯลฯ )

เอกสารเกี่ยวกับการ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.

เพิ่งสงสัย แต่ทำไมสำหรับแพ็กเก็ต SYN (เฟรม # 539; ที่ได้รับการยอมรับ) ฟิลด์ WS และ TSV หายไปในคอลัมน์ "ข้อมูล"

WS นั้นหน้าต่าง TCP ขูดหินปูนและ TSV คือการประทับเวลาราคา ทั้งคู่ถูกพบภายใต้ฟิลด์ tcp.options และ Wireshark ยังควรแสดงถ้ามี บางทีไคลเอนต์ TCP / IP สแต็คแพ็คเก็ต SYN ต่างกันในความพยายามครั้งที่ 8 และนั่นเป็นเหตุผลว่าทำไมมันจึงได้รับการตอบรับอย่างฉับพลัน?

คุณสามารถให้คุณค่าภายในเฟรม 539 แก่เราได้ไหม SYN / ACK มาสำหรับแพคเก็ต SYN ที่ไม่ได้เปิดใช้งาน WS อยู่เสมอหรือไม่

เราเพิ่งพบปัญหาเดียวกันนี้ (ใช้เวลาสักครู่เพื่อปักหมุดไปยังเซิร์ฟเวอร์ที่ไม่ได้ส่งสัญญาณซิงค์)

"ทางออกคือการปิดการปรับขนาดหน้าต่าง tcp และการประทับเวลา tcp บนเซิร์ฟเวอร์ของเราที่สาธารณะเข้าถึงได้"

เพื่อดำเนินการต่อในสิ่งที่ Ansis ได้ระบุไว้ฉันได้เห็นปัญหาเช่นนี้เมื่อไฟร์วอลล์ไม่รองรับ TCP Windows Scaling ไฟร์วอลล์ยี่ห้อ / รุ่นใดที่อยู่ระหว่างโฮสต์ทั้งสองนี้

SYN / ACK ที่ขาดหายไปอาจเกิดจากการ จำกัด การป้องกัน SYNFLOOD ของคุณในไฟร์วอลล์ต่ำเกินไป ขึ้นอยู่กับจำนวนการเชื่อมต่อกับผู้ใช้เซิร์ฟเวอร์ของคุณสร้างขึ้น การใช้ spdy จะลดจำนวนการเชื่อมต่อและสามารถช่วยในสถานการณ์ที่การnet.ipv4.tcp_timestampsปิดไม่ช่วยได้

นี่เป็นลักษณะการทำงานของซ็อกเก็ต TCP ที่รับฟังเมื่องานค้างเต็ม

Ngnix อนุญาตให้มีการตั้งค่าอาร์กิวเมนต์ค้างเพื่อรับฟังในการกำหนดค่า: http://wiki.nginx.org/HttpCoreModule#listen

คอยรับฟัง 80 คนงาน = จำนวน

ลองตั้งค่า num เป็นค่าที่มากกว่าค่าเริ่มต้นเช่น 1024

ฉันไม่รับประกันว่าการฟังคิวอย่างเต็มรูปแบบเป็นปัญหาของคุณจริง ๆ แต่นี่เป็นสิ่งแรกที่ควรตรวจสอบ

ฉันเพิ่งค้นพบว่าไคลเอนต์ Linux TCP เปลี่ยนแพ็กเก็ต SYN หลังจาก 3 พยายามและลบตัวเลือกการปรับขนาดหน้าต่าง ฉันเดาว่าผู้พัฒนาเคอร์เนลคิดว่านี่เป็นสาเหตุของความล้มเหลวในการเชื่อมต่ออินเทอร์เน็ต

มันอธิบายว่าทำไมไคลเอนต์เหล่านี้จัดการเชื่อมต่อหลังจาก 11 วินาที (TCP SYN แบบไร้หน้าต่างน้อยเกิดขึ้นหลังจาก 9 วินาทีในการทดสอบสั้น ๆ ของฉันด้วยการตั้งค่าเริ่มต้น)

ฉันมีปัญหาที่คล้ายกัน แต่ในกรณีของฉันมันเป็น TCP checksum ที่คำนวณอย่างผิดพลาด ลูกค้าอยู่ข้างหลังสัตวแพทย์และกำลังรัน ethtool -K veth0 rx off tx off ไม่ได้หลอกลวง