หน้าเว็บโหลดได้แต่อัปโหลดค้างบน VPN: สาเหตุใดชนะ
การค้างที่ขึ้นกับขนาดตรงกับความผิดพลาด MTU ของเส้นทาง และยังตรงกับ DNS ขีดจำกัดของแอป หรืออุโมงค์ที่ไม่เสถียร การสังเกตสี่อย่างตัดสินว่าอันใด
หน้าเว็บโหลดได้ VPN รายงานว่าเชื่อมต่อแล้ว และการอัปโหลดไฟล์ค้างที่จุดเดิมทุกครั้ง คำอธิบายสี่อย่างตรงกับคำบรรยายนี้: ปัญหาขนาดแพ็กเก็ต ปัญหาการแปลงชื่อ ปัญหาขีดจำกัดของแอป และอุโมงค์ที่รีเซ็ตซ้ำ ๆ แต่ละอย่างยืนยันหรือตัดออกได้ด้วยการสังเกตที่ต่างกัน ดังนั้นการตัดสินใจคือการเลือกการทดสอบที่ถูกต้อง ไม่ใช่การเดาสาเหตุ
ผู้ต้องสงสัยสี่รายกับรูปร่างเดียว
เริ่มจากรูปร่างของความล้มเหลว เพราะมันตัดรายการส่วนใหญ่ออกก่อนจะเปิดเครื่องมือใด ๆ การค้างที่เกิดที่ขนาดคงที่คือ ปัญหาขนาดจนกว่าจะพิสูจน์เป็นอย่างอื่น การค้างที่จุดสุ่มคือปัญหาการสูญหายหรือเสถียรภาพ ความล้มเหลวก่อนการเชื่อมต่อจะเปิดคือปัญหาชื่อ
ผู้ต้องสงสัยรายที่สี่คือแอป ขีดจำกัดการอัปโหลด เวลาหมดของคำขอ และเพดานขนาดเนื้อความที่พร็อกซีสร้างความล้มเหลวที่ดูเหมือนปัญหาเครือข่ายจากเบราว์เซอร์ และมักมาในรูปการปฏิเสธไม่ใช่การค้าง
จดรูปร่างที่สังเกตได้ก่อนทดสอบสิ่งใด "หยุดที่จำนวนไบต์ใกล้เคียงเดิม ทุกครั้ง ขณะอุโมงค์ทำงาน" เป็นจุดเริ่มต้นที่แข็งแรงกว่า "อัปโหลดใช้ไม่ได้" มาก
จากนั้นตรึงเส้นทางไว้ขณะทดสอบ การเปลี่ยนทางออก โปรโตคอล และเซิร์ฟเวอร์พร้อมกันให้ผลลัพธ์ที่คุณระบุไม่ได้ว่าเป็นของสิ่งใด หนึ่งตัวแปรต่อการรัน และจดไว้
แบ่งขนาดครึ่งหนึ่งก่อนแตะนโยบาย
ตัวแยกแยะที่ถูกที่สุดคือการทดสอบที่เปลี่ยนตัวเลขหนึ่งตัว ส่ง ping ที่ห้ามแบ่งส่วนขนาดเพิ่มขึ้นไปยังปลายทาง และอัปโหลดไฟล์ที่คุณควบคุมไปยังบริการเดียวกัน แล้วเปรียบเทียบว่าแต่ละอย่างหยุดที่ใด
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/uploadคำสั่งแรกบอกว่าแพ็กเก็ตขนาดเต็มผ่านเส้นทางได้เลยหรือไม่ ที่ MTU 1500 ไบต์ เพย์โหลด ICMP ที่ใหญ่ที่สุดซึ่งไม่ถูกแบ่งส่วนคือ 1472 ไบต์ และอุโมงค์กินงบประมาณนั้นมากกว่าเดิมก่อนแพ็กเก็ตภายในจะเริ่ม คำสั่งที่สองให้ขนาดและระยะเวลาของการถ่ายโอนระดับแอป และนั่นคือตัวเลขที่สำคัญจริง
| Candidate | Observation that confirms it | Observation that rules it out |
|---|---|---|
| Path MTU or blocked ICMP feedback | Stall at a consistent size; large do-not-fragment probes fail | Small and large transfers both complete |
| Name resolution | The connection never opens for that name | The connection opens and then stalls mid-transfer |
| Application or proxy limit | A clean rejection at a documented size | No log entry on the server at all |
| Tunnel instability | Reconnects or rekeying during the transfer | The tunnel uptime is unchanged across the failure |
อ่านทั้งคู่ด้วยกัน การทดสอบที่ล้มเหลวเหนือเกณฑ์และการอัปโหลดที่หยุดใกล้เกณฑ์เดียวกันคือเรื่องราวที่สอดคล้องกัน การทดสอบที่สำเร็จทั้งหมดขณะการอัปโหลดค้างที่จำนวนไบต์ที่เส้นทางลำเลียงได้ชัดเจนย่อมชี้ไปที่แอปหรือเซิร์ฟเวอร์ และการทำงานกับ MTU ไม่ว่ามากเพียงใดก็ไม่เปลี่ยนสิ่งนั้น ผลลัพธ์เชิงลบนั้นมีค่าเท่ากับผลลัพธ์เชิงบวก มันตัดกิ่งที่แพงที่สุดของการสอบสวนออก
จากนั้นตรวจสอบเสถียรภาพระหว่างการถ่ายโอน เพราะอุโมงค์ที่ต่ออายุคีย์กลางการอัปโหลดขนาดใหญ่สร้างความล้มเหลวที่ดูเหมือนขึ้นกับขนาดโดยไม่ได้เป็นเช่นนั้น การอ่านเวลาทำงานเป็นวิธีที่ถูกที่สุดในการยืนยัน
เลือกระหว่างการซ่อมกับการเลี่ยง
หากหลักฐานชี้ไปที่ขนาด มีคำตอบที่ซื่อสัตย์สองข้อและหนึ่งข้อที่ไม่ซื่อสัตย์ ข้อที่ซื่อสัตย์คือการคืนการค้นพบ MTU ของเส้นทางโดยอนุญาตผลตอบกลับ ICMP ที่จำเป็น หรือจำกัดขนาดเซกเมนต์ที่ประกาศเพื่อให้คู่ปลายส่งเซกเมนต์เล็กลง ข้อที่ไม่ซื่อสัตย์คือการลด MTU ของอินเทอร์เฟซเป็นค่าที่คัดลอกจากฟอรัมและไม่เคยตรวจสอบว่ามันเปลี่ยนอะไร
การเลือกขึ้นกับสิ่งที่คุณควบคุม บนเครือข่ายที่คุณดูแล การอนุญาตข้อความ ICMP เป็นการแก้ที่สะอาดกว่าเพราะกลไกยังทำงานกับทุกโปรโตคอล บนเส้นทางที่คุณไม่ได้ควบคุม การจำกัดเป็นทางเลือกที่ปฏิบัติได้ และควรใช้อย่างแคบไม่ใช่ทั้งเซิร์ฟเวอร์
หากหลักฐานชี้ไปที่แอป ให้ซ่อมแอปหรือการตั้งค่าพร็อกซี การตอบกลับ 413 และการเชื่อมต่อที่ค้างเป็นความล้มเหลวที่ต่างกัน และอย่างหลังมักเป็นการหมดเวลาในที่ใดที่หนึ่งของห่วงโซ่ที่มีพร็อกซีซึ่งมีขีดจำกัดของตัวเอง
ไม่ว่าทางใด ให้เก็บค่าเดิมไว้และทดสอบซ้ำหลังย้อนกลับ การเปลี่ยนแปลงที่บังเอิญตรงกับการถ่ายโอนที่สำเร็จไม่ใช่หลักฐานว่ามันเป็นสาเหตุ และความสามารถในการย้อนกลับคือสิ่งที่แยกการวินิจฉัยออกจากความบังเอิญ
บันทึกการตัดสินใจให้อยู่รอดถึงเหตุการณ์ครั้งถัดไป
ข้อเท็จจริงสี่ข้อพอ: รูปร่างความล้มเหลวที่สังเกตได้ ผลของการทดสอบ การเปลี่ยนแปลงที่คุณทำ และผลของการทดสอบซ้ำ ด้วยสิ่งเหล่านี้ คนถัดไปบอกได้ว่าปัญหาเดิมหรือใหม่ที่มีอาการเดียวกัน
บันทึกบริบทของเส้นทางด้วย เพราะข้อค้นพบเรื่อง MTU เฉพาะกับลิงก์หนึ่ง เครื่องแล็ปท็อปที่ทำงานที่บ้านแต่ล้มเหลวในโรงแรมมีสองเส้นทาง และการแก้ที่ใช้กับเส้นทางหนึ่งไม่บอกอะไรเกี่ยวกับอีกเส้นทาง
สุดท้าย จงต้านทานบทสรุปที่ว่า "VPN ทำให้การอัปโหลดพัง" อุโมงค์มีอยู่ทั้งในกรณีที่ทำงานและกรณีที่ล้มเหลว สิ่งที่เปลี่ยนคือขนาดแพ็กเก็ตที่เส้นทางต้องลำเลียง หรือจุดที่หยุดการถ่ายโอน การเรียกชื่อกลไกจริงคือสิ่งที่ทำให้บันทึกนี้มีประโยชน์