วิธีอ่านการสูญหายของแพ็กเก็ตก่อนโทษสายเคเบิล

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

เปรียบเทียบสามการวัดแทนการเชื่อถือเพียงอย่างเดียว คือสิ่งที่โพรบเห็น สิ่งที่ตัวนับของอินเทอร์เฟซทำ และสิ่งที่แอปพลิเคชันรอจริง ๆ

เปอร์เซ็นต์ของ ping วัดอะไรจริง ๆ

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

เก็บผลของโพรบไว้เป็นเบาะแสเกี่ยวกับเส้นทาง จากนั้นให้ค้นหาจังหวะเวลาและขอบเขตที่ทำให้เกิดผลนั้น

เปรียบเทียบส่วนต่างของตัวนับ ไม่ใช่ยอดรวมตลอดอายุ

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

ip -s link show dev eth0
nstat -az TcpRetransSegs TcpExtTCPTimeouts
date -u +%Y-%m-%dT%H:%M:%SZ

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

ถ้าไดรเวอร์เปิดเผยตัวนับกายภาพอย่างละเอียด ให้อ่านผ่านเอกสารของอะแดปเตอร์นั้น การให้ความหมายเดียวกับทุกฟิลด์ที่ชื่อ “drop” ในผู้ผลิตสองรายคือทางที่ความแปลกประหลาดทางการบัญชีตามปกติกลายเป็นการวินิจฉัยฮาร์ดแวร์

เซกเมนต์ที่หายไปกลายเป็นการรอคอยยาวนานได้อย่างไร

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

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

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

เปลี่ยนขอบเขตเดียวโดยไม่ขยับขอบเขตอื่น

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

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