อะไรทำให้เกิดการบันทึก ACK ซ้ำกัน

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

เหล่านี้จะแสดงในภาพหน้าจอต่อไปนี้ .26 เป็นลูกค้าและ. 252 เป็นเซิร์ฟเวอร์

อะไรทำให้บันทึก ACK ซ้ำกัน

พื้นหลังเพิ่มเติมถ้ามันช่วย:

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

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

เราพยายามเปลี่ยนการตั้งค่าTcpMaxDupAcksบนเซิร์ฟเวอร์ แต่ค่าที่เราต้องการจริงๆคือ 5 และช่วงที่ถูกต้องคือ 1-3 เท่านั้น

เซิร์ฟเวอร์คือ Windows Server 2003 ลูกค้าคือองค์กรทั้งหมดที่จัดการ Windows XP ลูกค้าทั้งหมดรวมถึงคนทำงานสองคนได้ติดตั้งระบบป้องกันไวรัสของ Symantec

นี่เป็นเว็บไซต์ลูกค้าเพียงแห่งเดียวจากหลายร้อยที่แสดงปัญหานี้

pathping แสดง RTMS 56ms และการสูญเสียแพ็กเก็ต 0/100 ที่สม่ำเสมอแม้จากเครื่องที่มีปัญหา

ขอบคุณ

แซม

หมายเหตุ: ฉันสมมติว่าการจับภาพนี้เกิดขึ้นในเครื่องไคลเอ็นต์

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

การจัดส่งที่เชื่อถือได้จะดำเนินการผ่านการใช้หมายเลขลำดับ ทุกแพ็กเก็ตในแต่ละสตรีมจะได้รับหมายเลขลำดับ 32 บิต (โปรดจำไว้ว่า TCP เป็นสตรีมข้อมูลที่เป็นอิสระสองรายการคือ A-> B และ B-> A) ถ้า A ส่ง ACK ไป B ค่าในฟิลด์ ACK คือหมายเลขลำดับถัดไปที่ A คาดว่าจะเห็นจาก B

จากด้านบนปรากฏว่าอย่างน้อยหนึ่งเซ็กเมนต์ TCP ที่ส่งจากเซิร์ฟเวอร์ไปยังไคลเอนต์นั้นหายไป สาม ACKs ที่ซ้ำกันในลำดับที่มีความพยายามโดยลูกค้าที่จะเรียกการส่งอีกครั้งอย่างรวดเร็ว เมื่อผู้ส่ง TCP ได้รับการตอบรับซ้ำกัน 3 ครั้งสำหรับข้อมูลชิ้นเดียวกัน (เช่น 4 ACK สำหรับส่วนเดียวกันซึ่งไม่ใช่ชิ้นส่วนของข้อมูลที่ส่งล่าสุด) ก็สามารถสันนิษฐานได้ว่ากลุ่มทันทีหลังจากส่วนที่ ACKed หายไป ในเครือข่ายและส่งผลให้ส่งใหม่ทันที

ในกรณีนี้การส่งซ้ำจะผ่านและถูกระบุโดย Wireshark ว่าไม่เรียบร้อย

ตามที่กล่าวไว้โดยjoeqwertyการสูญเสียแพ็กเก็ตมักเกิดจากความแออัด มันอาจเป็นผลมาจาก CRC หรือข้อผิดพลาดอื่น ๆ บนลิงก์เนื่องจากการ์ดอินเตอร์เฟสไม่ดี, สายเคเบิลหลวม ฯลฯ ฉันจะดูสถิติของทุกลิงก์ตามเส้นทางเพื่อดูว่ามีการใช้งานสูงและ / หรือ พบข้อผิดพลาดจำนวนมาก

หากคุณไม่เห็นผู้สมัครที่เห็นได้ชัดใด ๆ ให้ดำเนินการจับแพ็คเก็ตพร้อมกันในหลาย ๆ จุดตามเส้นทางเพื่อลองแยกแยะจุดที่เกิดการสูญเสีย

การเชื่อมต่อ WAN ชนิดใดที่ใช้งานอยู่ที่นี่ มันเป็นสายเฉพาะหรือไม่? ลิงค์ MPLS VPN? IPsec VPN ผ่านอินเทอร์เน็ตสาธารณะ? อื่น ๆ อีก?

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

หลังจากสร้างการเชื่อมต่อแล้วประสิทธิภาพของ TCP ที่ช้าอาจไม่ได้เกิดจากปัญหาเครือข่ายการขนส่ง บางครั้งมันมาเป็นผลมาจากเซิร์ฟเวอร์ CPU หรือข้อ จำกัด ของดิสก์ ... และบางครั้งเนื่องจากปัญหาบางอย่างบนเครื่องพีซีของลูกค้า ฉันได้ไล่ล่าหางของฉันเป็นเวลาหลายสัปดาห์ในการขุดหาร่องรอยของวัชพืช wireshark เพียงเพื่อยอมแพ้และค้นหาปัญหาที่ค่อนข้างรวดเร็วด้วยmtrหรือโดยการดูตัวชี้วัดโฮสต์อื่น ๆ เช่น CPU และดิสก์ I / O

งานแรกของคุณคือการพิสูจน์ว่าเป็นปัญหาเครือข่ายหรือปัญหาระดับโฮสต์ มุ่งเน้นไปที่การส่งปริมาณการใช้งานจริงผ่านเครือข่ายของคุณและพิสูจน์ว่าคุณกำลังเข้าคิว / การสูญเสีย / สั่งซื้อใหม่^{หมายเหตุ 1}มัน; ที่มักจะเป็นด้านล่างบรรทัดสำหรับปัญหาเครือข่ายที่มีศักยภาพเช่นนี้

ฉันจะทำการpingสุ่มตัวอย่างเป็นระยะเวลานาน (โดยทั่วไปจะเป็นชั่วโมงสำหรับฉัน) ระหว่างไคลเอนต์และเซิร์ฟเวอร์ในขณะที่ปัญหาปริมาณงานกำลังเกิดขึ้น คุณสามารถใช้ฟรีแวร์mtrหรือping plotterสำหรับสิ่งนี้ หากคุณสูญเสียแพ็คเก็ตอย่างต่อเนื่องในบาง hop และกระโดดหลังจากนั้นหลวมมากหรือมากกว่านั้นคุณมีผู้ต้องสงสัยเครือข่ายที่อาจเกิดขึ้น โปรดทราบว่าอุปกรณ์ที่ จำกัด อัตรา ICMP อาจทำให้ฮ็อพบางตัวปรากฏว่าพวกเขาทำแพ็กเก็ตที่หลวม ... นั่นเป็นเหตุผลที่คุณต้องการค้นหาแนวโน้มที่เริ่มต้นจากการฮ็อปและสิ่งต่อไปนี้

^{หมายเหตุ 1}หากคุณกำลังสั่งซื้อการรับส่งข้อมูลอีกครั้งนั่นจะปรากฏขึ้นอย่างรวดเร็วในฟิลด์ข้อมูลผู้เชี่ยวชาญที่ wireshark มีให้

โดยเห็นจำนวนมาก[ส่วนของ TCP ประกอบ PDU]โดยไม่ต้อง ACKs - ผมว่า ACKs เหล่านี้จะแสดงให้เห็นว่าน่าจะเป็น[TCP Dup ACK ... ]เนื่องจากการเลือกรับทราบ (aka SACK) พฤติกรรม

ตัวอย่าง:

• ลูกค้าส่งชิ้นส่วนข้อมูล (... , 0,1,2,3,4,5,6, ... )

• เซิร์ฟเวอร์ acked (0), จากนั้นได้รับ (2,4,3), (5), จากนั้น (6) และไม่เคยได้รับ (1)

ในสถานการณ์ข้างต้น - เซิร์ฟเวอร์สามารถเลือกช่วง ack (2-4) อย่างถูกต้องก่อนจากนั้นช่วง (2-5) จากนั้นช่วง (2-6) ในขณะที่สร้างแพ็กเก็ต "(AB) ช่วง ack" - เซิร์ฟเวอร์จะต้องระบุส่วนสุดท้ายที่รับ (0) ในส่วนหัว TCP Wireshark ทำเครื่องหมาย range-acks (SACKs) เป็น[TCP Dup ACK ... ]เนื่องจาก range-acks ทั้งหมดนั้นมีค่าชิ้นส่วนสุดท้ายที่เหมือนกันในส่วนหัว TCP (Ack = 872619 ในกรณีของคุณ)

ทำซ้ำ ACK ร่วมกับประสิทธิภาพของเครือข่ายช้าเสียงเหมือนปัญหาความแออัดของเครือข่ายสำหรับฉัน ดูที่ปริมาณและอัตราการรับส่งสัญญาณออกอากาศบนเครือข่าย ตรวจสอบให้แน่ใจว่าได้ดูการกระจายของเลเยอร์ทางกายภาพและเลเยอร์เครือข่ายรวมถึงมัลติคาสต์