การควบคุมการไหลด้านรับของ TCP
ทำไม TCP จึงหยุดชั่วคราวได้ทั้งที่ลิงก์ปกติ?
ระบบฝั่งรับจะเก็บข้อมูล TCP ไว้จนกว่าแอปพลิเคชันจะอ่าน หากไม่มีพื้นที่รับข้อมูลเหลือ ระบบสามารถประกาศหน้าต่างศูนย์ได้ ฝั่งส่งจะปฏิบัติตามขีดจำกัดนั้นและส่งโพรบเพื่อขอข้อมูลหน้าต่างปัจจุบัน การอ่านข้อมูลอาจทำให้หน้าต่างเปิดอีกครั้ง แต่การส่งโพรบเพียงอย่างเดียวไม่สามารถแก้ไขแอปพลิเคชันที่ติดค้างได้ สิ่งเหล่านี้เป็นแนวคิดทั่วไป ไม่ใช่ผลการวัดผลิตภัณฑ์หรือระยะเวลาการกู้คืนที่ตายตัว
บัฟเฟอร์
ข้อมูลอาจรออยู่ในบัฟเฟอร์ของระบบก่อนที่แอปพลิเคชันจะอ่าน
ข้อมูลป้อนกลับ
ฝั่งรับประกาศขีดจำกัดของตนกลับไปยังฝั่งส่ง
เปิดอีกครั้ง
การอ่านสามารถเพิ่มพื้นที่ว่างสำหรับรับข้อมูลได้ ส่วนโพรบช่วยให้ทราบสถานะหน้าต่างปัจจุบัน
บันทึกว่าปลายทางใดประกาศหน้าต่างศูนย์ และอยู่ในการเชื่อมต่อใด
เทียบการเปลี่ยนแปลงของหน้าต่างกับบันทึกการอ่านของแอปพลิเคชันและบันทึกทรัพยากรตามเวลา
เปรียบเทียบการอ่านอย่างต่อเนื่องกับการอ่านที่หน่วงเวลาในการทดสอบที่ได้รับอนุญาต
รายการตรวจสอบสำหรับการเลือกและการตรวจยืนยัน — ขยาย
| รายการตรวจสอบ | สิ่งที่ต้องยืนยัน | วิธีตรวจสอบ |
|---|---|---|
| การเชื่อมต่อ | ปลายทางและทิศทาง | บันทึกคู่ที่อยู่และพอร์ต |
| ฝั่งรับ | แอปพลิเคชันกำลังอ่านข้อมูล | เปรียบเทียบบันทึกของแอปพลิเคชันกับสถานะบัฟเฟอร์ |
| การคืนสู่การทำงานปกติ | หน้าต่างเปิดอีกครั้งจริง | เชื่อมโยงโพรบ การอัปเดต และข้อมูลที่กลับมาส่งอีกครั้ง |
อุปกรณ์ออนไลน์และไฟแสดงสถานะลิงก์ติดอยู่ แต่แอปพลิเคชันฝั่งส่งดูเหมือนหยุดชั่วคราว ข้อมูลที่จับได้อาจรายงานหน้าต่างศูนย์ ซึ่งไม่ได้หมายความว่าสายเคเบิลเสียหรือแบนด์วิดท์ของสวิตช์เป็นศูนย์เสมอไป ฝั่งรับ TCP อาจกำลังแจ้งคู่สื่อสารว่าขณะนี้ไม่มีพื้นที่รับข้อมูลชั่วคราว เพื่อทำความเข้าใจสาเหตุ ให้ตรวจสอบเส้นทางตั้งแต่ข้อมูลมาถึงเครือข่าย ผ่านการเก็บในบัฟเฟอร์ของระบบ จนถึงการอ่านของแอปพลิเคชัน
การมาถึงพอร์ตเครือข่ายไม่ใช่จุดสิ้นสุดของเส้นทาง
เกตเวย์อุตสาหกรรม เซิร์ฟเวอร์อุปกรณ์อนุกรม และคอมพิวเตอร์ควบคุมดูแลอาจแลกเปลี่ยนข้อมูลโดยใช้ TCP โดย TCP ให้บริการสตรีมไบต์ที่เรียงตามลำดับ ส่วนแอปพลิเคชันเป็นผู้กำหนดว่าไบต์เหล่านั้นแทนบันทึกอุณหภูมิ ข้อความสถานะ หรือคำสั่ง การที่ Ethernet ส่งเฟรมถึงปลายทางเป็นเพียงส่วนหนึ่งของเส้นทางเท่านั้น
หลังจากรับข้อมูล TCP ระบบจะตรวจสอบตามโพรโทคอล นำข้อมูลที่ยอมรับได้ไปไว้ในบัฟเฟอร์รับของการเชื่อมต่อ และรอให้แอปพลิเคชันอ่าน ลองนึกถึงห้องรับส่งพัสดุ: การส่งพัสดุถึงเคาน์เตอร์ไม่ได้หมายความว่าผู้รับเปิดและจัดการพัสดุแล้ว การเปรียบเทียบนี้แยกการจัดเก็บออกจากการนำไปใช้ ส่วนระบบจริงจะดูแลหมายเลขลำดับ ข้อมูลหน้าต่าง และสถานะหน่วยความจำ
หากแอปพลิเคชันกำลังรอการเขียนดิสก์ ประมวลผลข้อความก่อนหน้า หรือไม่ได้จัดสรรเวลาให้เธรดอ่านทำงาน ข้อมูลอาจสะสมได้ การ์ดเครือข่ายและสวิตช์ที่ทำงานปกติไม่สามารถอ่านไบต์เหล่านั้นแทนแอปพลิเคชันได้ การดูเฉพาะทราฟฟิกที่พอร์ตอาจทำให้มองข้ามการประมวลผลของซอฟต์แวร์ที่ปลายทาง
หน้าต่างรับข้อมูลประกาศความจุใด?
ส่วนหัว TCP มีฟิลด์หน้าต่างที่ประกาศช่วงข้อมูลซึ่งฝั่งรับยินดีรับในขณะนั้น โดยขึ้นอยู่กับการจัดการบัฟเฟอร์และนโยบายของระบบ ค่านี้ไม่จำเป็นต้องเท่ากับหน่วยความจำกายภาพที่ยังไม่ได้ใช้ของอุปกรณ์ และไม่ใช่พื้นที่ในคิวขาออกของสวิตช์ หน้าต่างศูนย์หมายความว่าขณะนี้ไม่มีหน้าต่างรับสำหรับข้อมูลใหม่ในทิศทางนั้น
สมมติว่าเกตเวย์ส่งบันทึกข้อมูลที่เก็บรวบรวมไปยังคอมพิวเตอร์ควบคุมดูแลอย่างต่อเนื่อง หากแอปพลิเคชันนั้นอ่านข้อมูลช้าลง ระบบสามารถลดหน้าต่างที่ประกาศและท้ายที่สุดประกาศหน้าต่างศูนย์ได้ ฝั่งส่งควรปฏิบัติตามขีดจำกัดแทนที่จะส่งข้อมูลใหม่โดยไม่จำกัด ทิศทางย้อนกลับของการเชื่อมต่อมีสถานะแยกเป็นอิสระ หน้าต่างศูนย์เพียงรายการเดียวไม่ได้ยืนยันว่าการแลกเปลี่ยนทั้งหมดในทั้งสองทิศทางหยุดลงแล้ว
เครื่องมือจับแพ็กเก็ตอาจแสดงค่าหน้าต่างดิบ หรือค่าที่คำนวณโดยนำตัวเลือกการปรับสเกลหน้าต่างมาพิจารณา การปรับสเกลหน้าต่างจะมีการเจรจาระหว่างการสร้างการเชื่อมต่อ และช่วยให้ใช้หน้าต่างรับข้อมูลที่ใหญ่ขึ้นได้ ตรวจสอบการจับมือและรูปแบบการแสดงผลก่อนตีความค่าที่ไม่เป็นศูนย์ การปรับสเกลค่าศูนย์ยังคงได้ศูนย์ การทำความเข้าใจการหยุดชั่วคราวนี้ไม่จำเป็นต้องคำนวณสูตร
ทำไมต้องแยกการตอบรับออกจากขนาดหน้าต่าง?
หมายเลขตอบรับของ TCP ระบุหมายเลขลำดับไบต์ถัดไปที่ฝั่งรับคาดว่าจะได้รับ ทำให้ฝั่งส่งติดตามข้อมูลต่อเนื่องที่ได้รับการตอบรับแล้วได้ ส่วนหน้าต่างระบุช่วงข้อมูลที่ฝั่งรับยินดีรับต่อไป อย่างหนึ่งบอกว่าได้รับข้อมูลก่อนหน้าไปถึงจุดใดแล้ว อีกอย่างเกี่ยวข้องกับการรับข้อมูลเพิ่มเติม ทั้งสองปรากฏร่วมกันแต่มีหน้าที่ต่างกัน
ระบบฝั่งรับสามารถตอบรับข้อมูลที่ยอมรับแล้วพร้อมกับประกาศหน้าต่างศูนย์ได้ ไบต์เหล่านั้นอาจยังอยู่ในบัฟเฟอร์โดยแอปพลิเคชันยังไม่ได้อ่าน การตอบรับของ TCP ยังไม่ได้ยืนยันว่าการประมวลผลทางธุรกิจสำเร็จแล้วเช่นกัน การยืนยันว่ารายการในฐานข้อมูลได้รับการบันทึกถาวรแล้วหรือคำสั่งได้รับการยอมรับแล้ว ต้องอาศัยการตอบกลับระดับแอปพลิเคชัน
ในทำนองเดียวกัน หมายเลขตอบรับที่ไม่เปลี่ยนแปลงไม่ได้พิสูจน์ทันทีว่าแพ็กเก็ตสูญหาย ให้พิจารณาทิศทาง การเปลี่ยนแปลงของหน้าต่าง เนื้อหาที่ส่ง และจังหวะเวลาร่วมกัน การส่งซ้ำ การตอบรับซ้ำ และหน้าต่างศูนย์อาจเกิดขึ้นในเหตุการณ์เดียวกันได้ แต่ป้ายสีของเครื่องมือจับแพ็กเก็ตไม่ใช่ข้อวินิจฉัยที่ยืนยันได้ด้วยตัวเอง
ทำไมจึงส่งโพรบหลังจากหน้าต่างเป็นศูนย์?
เมื่อแอปพลิเคชันฝั่งรับกลับมาอ่านข้อมูล ระบบอาจประกาศหน้าต่างที่พร้อมรับข้อมูล การอัปเดตนั้นอาจสูญหายระหว่างทาง หากฝั่งส่งรอเงียบ ๆ ตลอดไป ขณะที่ฝั่งรับเชื่อว่าตนส่งการอัปเดตไปแล้ว ทั้งสองฝ่ายอาจต่างรออีกฝ่าย TCP จึงกำหนดการส่งโพรบตรวจสอบหน้าต่างศูนย์เพื่อขอทราบสถานะหน้าต่างปัจจุบันของคู่สื่อสารอีกครั้ง
ฝั่งส่งกำหนดเวลาส่งโพรบตามข้อกำหนดของโพรโทคอลและการนำไปใช้งาน ส่วนฝั่งรับตอบรับพร้อมสถานะปัจจุบัน โพรบไม่ได้หมายความว่าการรับส่งข้อมูลของแอปพลิเคชันกลับมาทำงานแล้ว และไม่ได้พิสูจน์ว่าแอปพลิเคชันเริ่มอ่านข้อมูลแล้ว ขณะที่หน้าต่างที่ประกาศยังคงเป็นศูนย์ การส่งข้อมูลใหม่ตามปกติยังคงถูกจำกัด ช่วงเวลาระหว่างโพรบและการจัดการทรัพยากรขึ้นอยู่กับการนำไปใช้งาน ดังนั้นข้อมูลที่จับได้ครั้งเดียวจึงไม่สามารถยืนยันค่าพารามิเตอร์ด้านเวลาที่ใช้กับผลิตภัณฑ์ทุกชนิดได้
การส่งโพรบไม่สามารถแก้ไขแอปพลิเคชันที่ไม่อ่านข้อมูลเลยได้โดยอัตโนมัติ TCP กำหนดพฤติกรรมการรักษาการเชื่อมต่อและการส่งโพรบ ขณะที่นโยบายของระบบปฏิบัติการ ระยะหมดเวลาของแอปพลิเคชัน และขีดจำกัดทรัพยากรของอุปกรณ์ก็ส่งผลต่อผลลัพธ์ด้วย อย่าสัญญาว่าการเชื่อมต่อที่มีหน้าต่างศูนย์จะไม่มีวันปิด หรือจะกลับมาทำงานได้เสมอหลังจากเวลาที่กำหนดตายตัว
สิ่งนี้แตกต่างจากเฟรม Ethernet PAUSE อย่างไร?
หน้าต่างรับข้อมูลของ TCP เป็นข้อมูลป้อนกลับระดับชั้นขนส่งระหว่างปลายทางของการเชื่อมต่อ ส่วนเฟรม Ethernet PAUSE ขอให้หยุดส่งชั่วคราวบนลิงก์ที่เชื่อมต่อโดยตรง ความแออัดในคิวของสวิตช์และแอปพลิเคชันบนโฮสต์ที่อ่านข้อมูลช้าอาจทำให้ทราฟฟิกช้าลงได้ทั้งคู่ แต่ตำแหน่ง ผู้รับข้อมูลป้อนกลับ และฟิลด์ที่สังเกตได้แตกต่างกัน
สวิตช์ที่มีแบนด์วิดท์สูงกว่าไม่สามารถรับประกันการกลับมาทำงานของแอปพลิเคชันที่ไม่อ่านข้อมูลจากซ็อกเก็ตได้ ในทางกลับกัน หน้าต่างรับข้อมูลของโฮสต์ที่ปกติก็ไม่ได้พิสูจน์ว่าเส้นทางระหว่างกลางไม่มีความแออัด ให้ตรวจสอบข้อผิดพลาดและการทิ้งแพ็กเก็ตที่อินเทอร์เฟซ รวมถึงโหลดบนเส้นทาง แยกจากบัฟเฟอร์ของโฮสต์ โหลดของโพรเซส และบันทึกของแอปพลิเคชัน
สำหรับเซิร์ฟเวอร์อุปกรณ์อนุกรม ให้แยกพิจารณาความเร็วฝั่งอนุกรม การเชื่อมต่อ TCP และบัฟเฟอร์ภายใน การที่ไบต์จากฝั่งอนุกรมจะยังเข้ามาต่อเนื่องระหว่างที่เครือข่ายถูกจำกัดหรือไม่ และสิ่งที่จะเกิดขึ้นเมื่อบัฟเฟอร์เต็ม ขึ้นอยู่กับรุ่น เฟิร์มแวร์ และการตั้งค่าควบคุมการไหลที่ใช้จริง การรองรับ TCP เพียงอย่างเดียวไม่ได้ยืนยันว่าสามารถจัดการข้อมูลอนุกรมขาเข้าที่ไม่จำกัดโดยไม่สูญหายได้
รวบรวมหลักฐานที่อธิบายเหตุการณ์
เริ่มจากระบุการเชื่อมต่อและทิศทางที่ประกาศหน้าต่างศูนย์ โดยบันทึกที่อยู่ปลายทาง พอร์ต และเวอร์ชันของอุปกรณ์และแอปพลิเคชัน ตรวจสอบการจับมือและทราฟฟิกก่อนและหลังเหตุการณ์ เปรียบเทียบหน้าต่างรับข้อมูล หมายเลขตอบรับ โพรบ และการเปิดหน้าต่างอีกครั้งบนเส้นเวลาเดียวกัน เก็บข้อมูลที่จับได้ไว้ แทนที่จะเก็บเพียงภาพหน้าจอป้าย Zero Window
เทียบเส้นเวลานั้นกับบันทึกของแอปพลิเคชันฝั่งรับ แอปพลิเคชันกำลังอ่านข้อมูลอยู่หรือไม่? กำลังรอดิสก์ งานฐานข้อมูล หรือเธรดอื่นอยู่หรือไม่? ทรัพยากรระบบผิดปกติหรือไม่? หากฝั่งส่งยังคงสร้างข้อมูลต่อไป ให้ตรวจสอบคิวและระยะหมดเวลาทางธุรกิจของฝั่งส่งด้วย การย้ายข้อมูลค้างไปยังฝั่งส่งไม่ได้แก้ปัญหาการประมวลผลที่เป็นต้นเหตุ
ในสภาพแวดล้อมที่ได้รับอนุญาต การทดสอบแบบควบคุมด้วยข้อมูลปริมาณน้อยสามารถเปรียบเทียบการอ่านต่อเนื่องกับการหน่วงการอ่านชั่วคราว เพื่อดูว่าหน้าต่างที่ประกาศเปลี่ยนแปลงตามหรือไม่ อย่าหยุดกระบวนการผลิตที่สำคัญ หรือเพิ่มขนาดบัฟเฟอร์หรือปิดการหมดเวลาโดยไม่พิจารณา เพียงเพื่อให้ป้ายวินิจฉัยหายไป บัฟเฟอร์อาจช่วยเลื่อนเวลาที่เห็นข้อมูลค้างออกไป แต่ความสามารถในการประมวลผลอย่างต่อเนื่องที่ไม่เพียงพอยังคงต้องได้รับการแก้ไข
ระบุปัญหาแต่ละอย่างให้อยู่ในขั้นตอนที่ถูกต้อง
หน้าต่างศูนย์บ่งชี้โดยตรงที่สุดถึงขีดจำกัดการรับข้อมูลที่ฝั่งรับประกาศ ซึ่งช่วยชี้แนวทางตรวจสอบ แต่ไม่ได้พิสูจน์ว่าเหตุใดแอปพลิเคชันจึงช้าลง ให้เชื่อมโยงสี่ขั้นตอน ได้แก่ การมาถึงพอร์ตเครือข่าย การเก็บข้อมูล TCP ในบัฟเฟอร์ การอ่านของแอปพลิเคชัน และการประมวลผลทางธุรกิจ การแยกแยะนี้ช่วยตัดสินใจว่าควรตรวจสอบเส้นทางเครือข่าย ทรัพยากรระบบ หรือตรรกะของแอปพลิเคชัน
ข้อมูลสวิตช์อุตสาหกรรมแบบจัดการได้ที่ FCTELE เผยแพร่ครอบคลุมการเข้าถึงและการส่งต่อข้อมูล Ethernet อุตสาหกรรม โปรดตรวจสอบเอกสารผลิตภัณฑ์ที่เกี่ยวข้องเพื่อทราบอินเทอร์เฟซ ฟังก์ชันการจัดการ และความสามารถที่มีจริง คู่มือนี้ไม่ได้นำพฤติกรรมทั่วไปของ TCP มาอ้างว่าเป็นการออกแบบภายในของรุ่นใดรุ่นหนึ่ง และไม่ได้แต่งเติมความจุบัฟเฟอร์หรือระยะเวลาการกู้คืน การเลือกอุปกรณ์และงานแก้ไขจำเป็นต้องอาศัยรายละเอียดโพรโทคอลของปลายทาง เอกสารผลิตภัณฑ์ และการตรวจสอบยืนยันหน้างาน
เอกสารอ้างอิง
RFC 9293: การส่งโพรบตรวจสอบหน้าต่างศูนย์;Microsoft: หน้าต่างและการปรับสเกลของ TCP;อินเทอร์เฟซ TCP และการจัดการบัฟเฟอร์บน Linux;ข้อมูลสวิตช์อุตสาหกรรมแบบจัดการได้ของ FCTELE. ภาพประกอบทั่วไป ไม่ใช่ผลการวัดผลิตภัณฑ์
แปลจากบทความทางเทคนิคภาษาจีน: อ่านบทความต้นฉบับภาษาจีน.
คำถามที่พบบ่อย
หน้าต่างศูนย์หมายความว่าสายเคเบิลเสียหรือไม่?
ไม่ใช่ นี่คือขีดจำกัดการรับข้อมูลที่ปลายทาง TCP ประกาศ ให้ตรวจสอบการอ่านของแอปพลิเคชันและสถานะระบบควบคู่กับเส้นทางด้วย
การตอบรับของ TCP พิสูจน์ว่าการประมวลผลทางธุรกิจเสร็จสิ้นแล้วหรือไม่?
ไม่ใช่ ระบบอาจยอมรับไบต์ไว้แล้ว แต่แอปพลิเคชันยังไม่ได้นำไปใช้หรือประมวลผล
การส่งโพรบแก้ไขแอปพลิเคชันที่ติดค้างได้หรือไม่?
ไม่ได้ โพรบใช้ขอข้อมูลหน้าต่างปัจจุบัน ส่วนการอ่านที่ติดค้างอย่างต่อเนื่องต้องได้รับการตรวจสอบสาเหตุแยกต่างหาก
ขอบเขตและข้อมูลอ่านเพิ่มเติม
แนวคิดทั่วไปของ TCP ไม่ใช่วงจรของผลิตภัณฑ์รุ่นใดรุ่นหนึ่งหรือค่าระยะเวลาที่วัดได้
การควบคุมการไหลของ Ethernet และเฟรม PAUSE · การส่งต่อข้อมูลและการบำรุงรักษาสวิตช์
