คุณวินิจฉัยการสูญเสียแพ็คเก็ตได้อย่างไร

ฉันรู้ว่านี่เป็นอัตนัยและขึ้นอยู่กับตัวแปรหลายอย่าง แต่ฉันสงสัยว่าขั้นตอนใดที่คนส่วนใหญ่ต้องทำเมื่อพวกเขาต้องการวินิจฉัยการสูญหายของแพ็กเก็ตในระบบที่กำหนด

ฉันเป็นวิศวกรเครือข่ายดังนั้นฉันจะอธิบายเรื่องนี้จากมุมมองของฉัน

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

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

หากฉันไม่เห็นการสูญเสียสองขั้นตอนถัดไปมีแนวโน้มที่จะ "ส่ง Ping มากขึ้น" หรือ "ส่ง Ping มากขึ้น" หากนั่นไม่ได้เรียงลำดับให้บ่งชี้ว่าปัญหาคืออะไรก็ถึงเวลาเริ่มดูนโยบาย QoS และสถิติส่วนต่อประสานผ่านเส้นทางทั้งหมดระหว่างจุดสิ้นสุด

หากยังไม่พบอะไรเลยก็ถึงเวลาที่จะเริ่มตั้งคำถามกับข้อสันนิษฐานของคุณคุณกำลังประสบกับการสูญเสียแพ็กเก็ตหรือไม่ วิธีการตรวจสอบที่แน่นอนเพียงอย่างเดียวคือการจับภาพพร้อมกันที่ปลายทั้งสองโดยใช้ WireShark (หรือเทียบเท่า) บนโฮสต์หรือโดยการเชื่อมต่อเครื่องดมกลิ่น (อาจใช้ WireShark หรือคล้ายกัน) ผ่านก๊อกเครือข่าย จากนั้นความสนุกในการเปรียบเทียบการจับแพ็คเก็ตสองรายการ ...

บางครั้งสิ่งที่มีสาเหตุมาจาก "การสูญเสียแพ็กเก็ต" เป็นเพียงบางอย่างที่ฝั่งเซิร์ฟเวอร์ช้าลงอย่างเห็นได้ชัด (เช่นการย้ายฐานข้อมูลจาก "บน LAN เดียวกัน" ไปเป็น "20 มิลลิวินาที" และใช้แบบสอบถามที่ต้องใช้จำนวนมาก ไปมาระหว่าง front-end และฐานข้อมูล)

ethtool -S ethXจากมุมมองของระบบลินุกซ์ครั้งแรกที่ผมจะมองหาการสูญเสียตบนอินเตอร์เฟซเครือข่ายที่มี

ส่วนใหญ่แล้วการเพิ่มบัฟเฟอร์วงแหวนด้วยการethtool -G ethX rx VALUEแก้ปัญหานี้

บางครั้งการขัดจังหวะจะไม่สมดุลเนื่องจากระบบขาดบริการ irqbalance ดังนั้นให้ดูในchkconfig(EL) หรือupdate-rc(Debuntu) เพื่อดูว่าบริการนี้ทำงานอยู่หรือไม่ คุณสามารถบอกได้ว่าอินเทอร์รัปต์ไม่สมดุลเนื่องจาก/proc/interruptsจะแสดงเฉพาะ Core 0 ที่ให้บริการช่อง IRQ ทั้งหมด

ความล้มเหลวนี้คุณอาจจำเป็นต้องเพิ่มถ้าระบบจะผ่านมากกว่าหนึ่งกิกะบิตไม่กี่ของการจราจรและอาจnet.core.netdev_max_backlognet.core.netdev_budget

ethtool -Cหากไม่ได้ทำงานคุณสามารถปรับแต่งการขัดจังหวะหลอมรวมกับค่า

หากไม่มีแพ็กเก็ตดร็อปในอินเทอร์เฟซเครือข่ายให้ดูnetstat -sและดูว่ามีการลดลงในซ็อกเก็ตบัฟเฟอร์ข้อมูลเหล่านี้จะถูกรายงานด้วยสถิติเช่น " pruned from receive queue" และ " dropped from out-of-order queue"

คุณสามารถลองเพิ่มค่าเริ่มต้นและบัฟเฟอร์ซ็อกเก็ตสูงสุดสำหรับโปรโตคอลที่เหมาะสม (เช่น: net.ipv4.tcp_rmemสำหรับ TCP)

หากแอปพลิเคชันตั้งค่าขนาดบัฟเฟอร์ซ็อกเก็ตของตัวเองแอปพลิเคชันอาจต้องการการเปลี่ยนแปลงการกำหนดค่า หากแอปพลิเคชันของคุณมีขนาดบัฟเฟอร์ซ็อกเก็ตที่เขียนโค้ดยากบ่นกับผู้ขายแอปพลิเคชันของคุณ

โดยส่วนตัวแล้วฉันไม่ชอบโพรโทคอลที่ถ่ายลงบน NICs (ตรวจสอบ, แบ่งเซ็กเมนต์, โหลดขนาดใหญ่ได้รับ offload) เนื่องจากดูเหมือนว่าจะทำให้เกิดปัญหามากกว่าที่มันคุ้มค่า การเล่นโดยใช้การตั้งค่าเหล่านี้ethtool -Kอาจคุ้มค่ากับการถ่ายภาพ

ดูตัวเลือกโมดูลสำหรับ NIC ของคุณ ( modinfo <drivername>) เนื่องจากคุณอาจจำเป็นต้องปรับเปลี่ยนคุณสมบัติบางอย่าง เพื่อยกตัวอย่างหนึ่งที่ฉันได้พบการใช้ Flow Director ของ Intel ในระบบที่จัดการสตรีม TCP ใหญ่ ๆ หนึ่งตัวอาจจะส่งผลเสียต่อประสิทธิภาพของสตรีมนั้นดังนั้นให้ปิด FDir

นอกเหนือจากที่คุณได้รับการปรับระบบนี้เฉพาะสำหรับปริมาณงานเฉพาะซึ่งฉันเดาว่าเกินขอบเขตของคำถามของคุณ

ฉันจะเริ่มต้นด้วยการใช้เครื่องมือจับภาพแพ็คเก็ตเช่น: wireshark (บน Windows) และ tcpdump (บนเทอร์มินัล Linux)

ฉันจะตรวจสอบการกำหนดค่าไฟร์วอลล์ (ไฟร์วอลล์โฮสต์รวมถึงไฟร์วอลล์เครือข่าย)

แยกแล้วกำจัด

ค้นหาเส้นทางย่อยที่เล็กที่สุดด้วยปัญหา ทำได้โดยการทดสอบชุดค่าผสมต่าง ๆ และ / หรือการกลั่นรายงานผู้ใช้ อย่าลืมแยกเวลาออกจากการแข่งขัน อาจเป็นเพียง packetloss ในทราฟฟิกทั้งหมดไปยังเครือข่ายที่เฉพาะเจาะจงหรืออาจเป็นเพียงไคลเอนต์ไร้สายกำลังประสบ พิจารณาประเภทการเข้าชมที่แตกต่างกัน (จำกัด อัตราการส่ง Ping) ค้นหาวิธีที่เชื่อถือได้และทำซ้ำได้ง่ายที่สุดในการทดสอบ

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

บางครั้งคุณสามารถใช้ทางลัดโดยดูที่การทิ้งแพ็กเก็ตหรือเดา (มันเป็น BitTorrent) นอกจากนี้บอกว่าศาสตราจารย์เซิร์ฟเวอร์ของคุณผิดพลาดก็ยอดเยี่ยม

การส่ง Ping อาจไม่แสดงการสูญเสียแพ็คเก็ตจนกว่าคุณจะส่งการส่ง Ping จำนวนมาก! ฉันมีแพ็กเก็ตข้อมูลสูญหายบนเครือข่ายของฉันซึ่งมองไม่เห็นจนกว่าฉันจะเพิ่มขนาดแพ็กเก็ต ping ของฉัน

สำหรับ windows:

ping -n 30 -l <largevalue> <target>

สำหรับlargevalueฉันใช้ 40960 (แพ็คเก็ต 40k)

สำหรับtargetฉันใช้ที่อยู่ IP สองสามอันแรกจากtracert google.com

(ซึ่งเป็นเราเตอร์และเคเบิลโมเด็มของฉัน) หนึ่งในอุปกรณ์ที่อยู่เหนือห่วงโซ่มีการสูญเสียแพ็กเก็ตแย่มาก (> 60%) สำหรับแพ็กเก็ตขนาดใหญ่ แต่ 0% สำหรับขนาดเล็ก ฉันแก้ไขโดยเริ่มต้นใหม่ แต่อาจเป็นสายเคเบิลหรือสิ่งที่อยู่ภายในที่จำเป็นต้องเปลี่ยน