TCP Zero Window ผ่านพร็อกซี: ระบุฝ่ายรับ
ระบุว่าการควบคุมการไหลของ TCP อยู่ฝั่งไคลเอนต์หรือเซิร์ฟเวอร์ของพร็อกซีก่อนโทษ window scaling หรือขนาดบัฟเฟอร์สำหรับการดาวน์โหลดที่หยุดค้าง
แคปเจอร์แพ็กเก็ตแสดง TCP ZeroWindow ก่อนเปลี่ยนการตั้งค่าเคอร์เนล ให้ระบุว่าปลายทางใดประกาศค่าศูนย์
ปลายทางนั้นกำลังอธิบายความสามารถในการรับของตนบนการเชื่อมต่อ TCP นั้น ไม่ได้ประกาศว่าพร็อกซีทั้งหมดมีแบนด์วิดท์เท่าใด การตรวจสอบ zero-window ทำให้ผู้ส่งรู้ว่าความสามารถที่ประกาศไว้เปลี่ยนไปหรือไม่ การตรวจสอบเพียงอย่างเดียวไม่ได้ยืนยันว่าแพ็กเก็ตหายหรือพร็อกซีเสีย
browser <-- TCP A --> proxy <-- TCP B --> websiteนี่คือบทสนทนา TCP สองชุดแยกกัน สมมติว่าเบราว์เซอร์หยุดอ่านการตอบกลับขนาดใหญ่และประกาศศูนย์บน A พร็อกซีอาจหยุดดึงข้อมูลจาก B ในที่สุดเมื่อบัฟเฟอร์ของตัวเองเต็ม zero window ที่ปรากฏบน B ภายหลังอาจเป็นผลจากไคลเอนต์ที่ช้า ไม่ใช่ปัญหาเดิม
สถานการณ์ตรงกันข้ามอาจเกิดขึ้นระหว่างการอัปโหลด หากแอปพลิเคชันปลายทางหยุดบริโภคข้อมูล หน้าต่างของมันบน B อาจปิดลง ความกดดันอาจไหลย้อนกลับไปยังไคลเอนต์ผ่านบัฟเฟอร์ของพร็อกซี
จัดลำดับการสังเกต
- บันทึกปลายทั้งสองของการเชื่อมต่อและทิศทางของการถ่ายโอนข้อมูลที่ได้รับผลกระทบ
- ระบุว่าปลายใดประกาศหน้าต่างรับที่หดลงหรือเป็นศูนย์ก่อน
- ตรวจสอบว่าแอปพลิเคชันของปลายนั้นกำลังอ่าน หยุดชั่วคราวที่งานอื่น หรือถูกจำกัดด้วยทรัพยากร
- เปรียบเทียบเวลาบนการเชื่อมต่ออีกชุดของพร็อกซีก่อนกำหนดสาเหตุเดิม
ป้ายวิเคราะห์หน้าต่างของ Wireshark เป็นการตีความแคปเจอร์ที่เป็นประโยชน์ ไม่ใช่คำสั่งให้เพิ่มบัฟเฟอร์รับทุกตัว window scaling ก็ต้องตีความโดยดูการเจรจาของการเชื่อมต่อด้วย
การลองปลายทางอื่นจากรายการพร็อกซีแล้วเห็นการถ่ายโอนฟื้นตัวเป็นหลักฐานที่เป็นประโยชน์ว่าเส้นทางเปลี่ยนไป แต่เพียงอย่างเดียวไม่ได้พิสูจน์ว่าการทำงาน TCP ของระบบปฏิบัติการหนึ่งมีข้อบกพร่อง ให้คำอธิบายผูกกับโพรเซสที่รับข้อมูลและการเชื่อมต่อที่การรอเริ่มต้น