คอมพิวเตอร์เชื่อมต่อกับ PLC และไฟแสดงสถานะลิงก์ยังติดอยู่ แต่การอ่านพารามิเตอร์หยุดชะงักเป็นครั้งคราว ผ่านไปสักครู่ก็กลับมาทำงานต่อ โดยดูเหมือนข้อมูลไม่สูญหาย อุปกรณ์อาจไม่ได้ประมวลผลช้า แต่ TCP อาจกำลังเติมช่วงข้อมูลที่ขาดหาย TCP เป็นกลไกระดับขนส่งที่คอมพิวเตอร์ควบคุมดูแล เกตเวย์ และตัวควบคุมจำนวนมากใช้งาน โดยพยายามส่งมอบสตรีมไบต์ตามลำดับ คู่มือนี้ติดตามไบต์เหล่านั้นโดยไม่ใช้การพิสูจน์ทางคณิตศาสตร์ ว่าใครเก็บบันทึก ใครต้องรอ และเหตุใดการได้รับข้อมูลในที่สุดจึงยังส่งผลต่อรอบการผลิตได้
1. เครือข่ายขนส่งข้อมูล ส่วนปลายทางเป็นผู้ส่งซ้ำ
คอมพิวเตอร์ควบคุมดูแลส่งข้อมูลให้ส่วนการทำงาน TCP ของตน จากนั้นข้อมูลจึงผ่านอินเทอร์เฟซเครือข่ายและสวิตช์อุตสาหกรรมไปยัง PLC โดยปกติสวิตช์ส่งต่อเฟรม Ethernet โดยใช้ที่อยู่ Ethernet ไม่ได้ตอบรับทุกไบต์แทนการเชื่อมต่อ TCP นั้น ปลายทางการสื่อสารเป็นผู้เก็บบันทึกการส่ง ประมวลผลการตอบรับ และตัดสินใจว่าจะส่งซ้ำเมื่อใด หากเกตเวย์ยุติการเชื่อมต่อหนึ่งแล้วเริ่มอีกการเชื่อมต่อหนึ่ง ให้วิเคราะห์สองการเชื่อมต่อนั้นแยกกัน แทนที่จะมองเส้นทางทั้งหมดเป็นช่องทางเดียวที่ไม่แบ่งส่วน
ลองนึกถึง TCP ว่าเป็นต้นฉบับเอกสารต่อเนื่องที่มีหมายเลขกำกับตำแหน่ง กลไกระดับขนส่งอาจแบ่งเอกสารเป็นชุดข้อมูลขนาดต่างกัน แต่ท้ายที่สุดผู้รับควรได้รับเนื้อหาตามลำดับที่ถูกต้อง การเปรียบเทียบนี้อธิบายเฉพาะการกำหนดหมายเลขและการเติมช่องว่างเท่านั้น TCP ไม่เข้าใจเนื้อหาเอกสาร จึงบอกไม่ได้ว่าไบต์เหล่านั้นแทนอุณหภูมิ ไฟล์พารามิเตอร์ หรือคำสั่งเริ่มทำงาน แอปพลิเคชันต้องเป็นผู้ตัดสินว่าข้อมูลนั้นถูกต้องใช้ได้หรือไม่
2. หมายเลขลำดับและหมายเลขตอบรับนับไบต์ ไม่ได้นับชุดข้อมูล
ตัวอย่างง่าย ๆ คือการเชื่อมต่อที่สร้างขึ้นแล้วส่งเซกเมนต์ข้อมูลสามเซกเมนต์ ซึ่งประกอบด้วยไบต์ 1001–1100, 1101–1200 และ 1201–1300 ตัวเลขเหล่านี้ใช้เพื่อประกอบคำอธิบาย การเชื่อมต่อจริงไม่ได้มีหมายเลขลำดับเริ่มต้นตายตัว SEQ ระบุหมายเลขลำดับเริ่มต้นของข้อมูลในเซกเมนต์ ส่วน ACK ระบุไบต์ถัดไปที่ผู้รับคาดหวังในสตรีมต่อเนื่อง หลังจากเซกเมนต์แรกมาถึง การตอบรับอาจชี้ไปที่ 1101 เพื่อยืนยันเนื้อหาต่อเนื่องทั้งหมดก่อนหน้านั้น
หากเซกเมนต์ที่สองขาดหายแต่เซกเมนต์ที่สามมาถึง โดยทั่วไปผู้รับสามารถพักข้อมูลที่มาทีหลังไว้ในบัฟเฟอร์ ขณะที่การตอบรับแบบสะสมยังคงอยู่ที่ 1101 การเห็นไบต์ 1300 ต่างจากการมีไบต์ครบทั้งหมดระหว่างนั้น หมายเลขตอบรับจะเลื่อนไปข้างหน้าได้เมื่อเติมช่องว่างครบแล้ว ACK ไม่ใช่หมายเลขแพ็กเก็ต ดังนั้นการนับแถวในข้อมูลที่จับได้เพียงอย่างเดียวจึงไม่สามารถบอกปริมาณเนื้อหาของแอปพลิเคชันที่ขาดหายได้
3. การตอบรับซ้ำและตัวจับเวลาให้เบาะแสที่แตกต่างกัน
ผู้ส่งเก็บข้อมูลที่ยังไม่ได้รับการตอบรับไว้ หากข้อมูลที่มาทีหลังยังมาถึงอย่างต่อเนื่อง ผู้รับอาจรายงานหมายเลขตอบรับเดิมซ้ำ ๆ เพื่อบ่งชี้ว่ามีช่องว่างอยู่ข้างหน้า ในตัวอย่างการส่งซ้ำแบบรวดเร็วดั้งเดิม ACK ซ้ำสามครั้งจะกระตุ้นให้ส่งเซกเมนต์ที่ขาดหายอีกครั้ง การทำงานสมัยใหม่อาจใช้วิธีตรวจจับการสูญหายอื่นด้วย อุปกรณ์แต่ละชนิดไม่ได้ทำงานตรงตามแผนภาพเวลาแบบย่อเพียงแบบเดียวทั้งหมด
หากมีทราฟฟิกน้อย อาจมีข้อมูลที่มาทีหลังไม่มากพอให้เกิดการตอบรับซ้ำเหล่านั้น ในกรณีนี้ตัวจับเวลาการส่งซ้ำอาจเป็นกลไกสำหรับการกู้คืน RTO หรือระยะหมดเวลาการส่งซ้ำ คือช่วงเวลาที่รอการตอบรับ ปลายทางพิจารณาความหน่วงไปกลับและความแปรผันของความหน่วงนั้น แทนที่จะใช้ค่าคงที่เดียวกับทุกการเชื่อมต่อ หากตัวจับเวลาหมดลงโดยไม่ได้รับการตอบรับที่ต้องการ ปลายทางจะส่งข้อมูลซ้ำ โดยทั่วไปการไม่ได้รับข้อมูลตอบกลับซ้ำ ๆ จะทำให้ระยะรอนานขึ้น ค่ามิลลิวินาทีใด ๆ ในที่นี้ไม่ใช่คำรับรองเกี่ยวกับผลิตภัณฑ์ FCTEL
4. แม้กู้คืนข้อมูลได้แล้ว ก็ยังอาจเกิดการหยุดชะงักที่สังเกตเห็นได้
การส่งซ้ำต้องใช้เวลา ผู้รับอาจรอให้เติมช่องว่างครบก่อนส่งมอบไบต์ต่อเนื่องถัดไปให้แอปพลิเคชัน ข้อมูลที่มาถึงอินเทอร์เฟซเครือข่ายแล้วไม่ได้ทำให้หน้าจออัปเดตทันทีเสมอไป นี่คือผลที่อาจเกิดขึ้นอย่างหนึ่งจากกลไกระดับขนส่ง ไฟแสดงสถานะลิงก์ที่ติดอยู่ไม่ได้หมายความว่าแอปพลิเคชันจะอัปเดตตรงเวลาเสมอ และการหยุดชะงักหนึ่งครั้งก็ไม่ได้ระบุว่าพอร์ตสวิตช์ใดพอร์ตหนึ่งเป็นสาเหตุ
TCP ยังควบคุมปริมาณข้อมูลที่ส่งในแต่ละครั้งตามสภาพเครือข่ายด้วย การสูญหายอาจถูกตีความว่าเป็นสัญญาณความแออัด ทำให้ผู้ส่งลดการส่งข้อมูลลง สิ่งนี้เกิดขึ้นในโพรโทคอลที่ปลายทาง ไม่ได้หมายความว่าความเร็วพอร์ตที่เจรจาไว้ลดลงโดยอัตโนมัติ การเชื่อมต่ออาจส่งมอบข้อมูลที่ใช้งานได้ในปริมาณน้อยลงชั่วคราว ขณะที่ลิงก์ทางกายภาพยังรายงานความเร็วระดับ Gigabit การส่งมอบแบบเชื่อถือได้พยายามกู้คืนข้อมูลที่ขาดหาย แต่ไม่ได้รับประกันกำหนดเวลาควบคุมอุตสาหกรรมที่ตายตัว
5. การตอบรับ TCP ไม่ใช่การแจ้งว่างานเสร็จสิ้น
ACK ของ TCP ยืนยันไบต์ที่เกี่ยวข้อง ณ ตัวรับ TCP ฝั่งคู่สื่อสาร ไม่ได้พิสูจน์ว่าแอปพลิเคชัน PLC อนุมัติพารามิเตอร์ เขียนพารามิเตอร์ไปยังตำแหน่งปลายทาง หรือดำเนินการกับมอเตอร์เสร็จแล้ว โพรโทคอลแอปพลิเคชันมักมีการตอบกลับ รหัสข้อยกเว้น หรือสถานะเสร็จสิ้นของตนเอง ควรบันทึกการตอบรับระดับขนส่ง การตอบกลับของโพรโทคอล และผลลัพธ์ของอุปกรณ์แยกกัน แทนที่จะรวมเวลาของทั้งหมดเป็นข้อความแจ้งสำเร็จเพียงข้อความเดียว
เมื่อมีการส่งไบต์ที่ทับซ้อนกันซ้ำในการเชื่อมต่อเดียวกัน TCP ใช้หมายเลขลำดับเพื่อระบุข้อมูลซ้ำ และโดยปกติจะไม่ส่งมอบข้อมูลเหล่านั้นเป็นเนื้อหาใหม่ของสตรีม แอปพลิเคชันที่หมดเวลารอแล้วส่งคำสั่งอีกครั้งกำลังสร้างคำขอแอปพลิเคชันอีกคำขอหนึ่ง TCP ไม่สามารถตัดสินได้ว่าคำขอสองคำขอมีความหมายเดียวกัน หลังเชื่อมต่อใหม่ ให้ตรวจสอบตัวระบุคำขอ สถานะการดำเนินการ และกฎสำหรับคำขอซ้ำที่โพรโทคอลแอปพลิเคชันกำหนด การส่งคำสั่งดำเนินการซ้ำอย่างไม่สิ้นสุดไม่ใช่แนวทางที่เหมาะสมในการทำให้งานเสร็จสิ้น
6. แก้ไขปัญหาทั้งสองทิศทางและวิเคราะห์ร่วมกับจังหวะเวลาของแอปพลิเคชัน
บันทึกเวลาที่หยุดชะงัก ปลายทาง โพรโทคอล ปริมาณข้อมูล และการดำเนินการ จากนั้นตรวจสอบตัวนับข้อผิดพลาดและการทิ้งข้อมูลของพอร์ต บันทึกการเชื่อมต่อ และข้อมูลที่จับได้จากทั้งสองฝั่ง การส่งช่วงไบต์เดิมซ้ำเป็นเบาะแสที่มีประโยชน์ นอกจากนี้ให้ตรวจสอบว่า ACK เลื่อนไปข้างหน้าหรือไม่ ข้อมูลมาถึงผิดลำดับหรือไม่ และหน้าต่างรับที่ประกาศมีขนาดเล็กลงหรือเป็นศูนย์หรือไม่ หน้าต่างนี้บอกปริมาณข้อมูลที่บัฟเฟอร์รับสามารถรองรับได้ ซึ่งเป็นคนละเรื่องกับการเสียบสายเชื่อมต่ออยู่หรือไม่
เครื่องมือจับแพ็กเก็ตระบุการส่งซ้ำด้วยการตีความแพ็กเก็ตที่สังเกตได้ ไม่ได้วัดส่วนประกอบที่ขัดข้องโดยตรง พอร์ตมิเรอร์ที่รับภาระเกิน การสูญหายระหว่างจับข้อมูล หรือการเริ่มจับข้อมูลช้าเกินไปอาจทำให้วิเคราะห์คลาดเคลื่อน การถ่ายโอนภาระงานไปยังอินเทอร์เฟซเครือข่ายยังอาจเปลี่ยนลักษณะการแบ่งเซกเมนต์ที่เห็นในข้อมูลที่จับบนโฮสต์ด้วย เปรียบเทียบบันทึกทั้งสองฝั่งเพื่อแยกความแตกต่างระหว่างข้อมูลขาออกที่ขาดหาย การตอบรับขากลับที่ขาดหาย และแพ็กเก็ตที่เครื่องมือจับข้อมูลเพียงแค่ไม่สามารถสังเกตได้
หากข้อผิดพลาดการตรวจสอบเฟรมเพิ่มขึ้นในเวลาเดียวกัน ให้ตรวจสอบขั้วต่อ สายสัญญาณ การป้องกันสัญญาณรบกวน และสัญญาณรบกวน หากการทิ้งข้อมูลเพิ่มขึ้นพร้อมทราฟฟิกที่พุ่งสูงเป็นช่วง ๆ ให้ตรวจสอบทราฟฟิกที่แย่งใช้ทางออกและการบัฟเฟอร์ หากมีเพียงการถ่ายโอนข้อมูลขนาดใหญ่ผ่านเราเตอร์หรือทันเนลที่ล้มเหลว ให้ตรวจสอบข้อจำกัดด้านขนาดตามเส้นทางด้วย เปลี่ยนเงื่อนไขครั้งละหนึ่งอย่างและเก็บหลักฐานก่อนและหลังไว้ การเพิ่มระยะหมดเวลาของแอปพลิเคชันเพียงอย่างเดียวอาจซ่อนอาการโดยไม่ได้ขจัดความล่าช้าระดับขนส่ง
ทราฟฟิกขากลับมีความสำคัญ ข้อมูลอาจมาถึงแล้ว แต่การตอบรับสูญหายระหว่างทางกลับ หากไม่ได้รับการตอบรับนั้น ผู้ส่งอาจส่งซ้ำและผู้รับจะระบุได้ว่าเป็นไบต์ซ้ำ ดังนั้นการส่งซ้ำจึงไม่ได้พิสูจน์ว่าข้อมูลครั้งแรกไม่เคยถึงปลายทาง วาดเส้นทางขาไปและขากลับแยกกัน แล้วเปรียบเทียบบันทึกของผู้รับ มิฉะนั้น การเปลี่ยนสายข้างผู้ส่งอาจทำให้มองข้ามเส้นทางขากลับที่เป็นปัญหาจริง ทดสอบทั้งสองทิศทางแทนการใช้การถ่ายโอนทางเดียวเพียงครั้งเดียวเป็นตัวแทนของการเชื่อมต่อทั้งหมด
7. ตรวจสอบความถูกต้องของเนื้อหาและผลลัพธ์ที่ทันเวลาและใช้งานได้
เอกสารสวิตช์อุตสาหกรรมแบบจัดการได้ของ FCTEL เป็นจุดเริ่มต้นสำหรับตรวจสอบอินเทอร์เฟซและฟังก์ชันการจัดการ ตรวจสอบให้แน่ใจว่ารุ่น คู่มือ และเฟิร์มแวร์ที่ใช้งานจริงมีตัวนับและบันทึกใดให้ใช้บ้าง บทความนี้อธิบายพฤติกรรมทั่วไปของ TCP ไม่ได้อ้างว่าสวิตช์จัดการ TCP แทนปลายทาง หรือการทำงานของโพรโทคอลจากผู้ผลิตรายอื่นเป็นตัวแทนสมรรถนะของอุปกรณ์ FCTEL รุ่นใดรุ่นหนึ่ง
หลังการกู้คืน ให้ตรวจสอบเนื้อหาไฟล์หรือพารามิเตอร์ จากนั้นสังเกตการกระจายของเวลาตอบสนองและข้อยกเว้นระหว่างการทำงานต่อเนื่อง สำหรับคำขอดำเนินการ ให้ตรวจสอบสถานะเสร็จสิ้นและพฤติกรรมเมื่อได้รับคำสั่งซ้ำด้วย ใช้กำหนดเวลาของแอปพลิเคชันที่ตกลงไว้สำหรับสถานที่นั้น โดยแยกการหยุดชะงักเฉพาะครั้ง การเสื่อมลงอย่างต่อเนื่อง และการตัดการเชื่อมต่อจริงออกจากกัน จำไว้สามประเด็น: TCP เติมช่องว่างของไบต์ การเติมช่องว่างต้องใช้เวลา และต้องตรวจสอบการรับข้อมูลแยกจากการทำงานเสร็จสิ้น
รายงานการบำรุงรักษาควรระบุอาการและหลักฐาน ได้แก่ ช่วงไบต์ใดถูกส่งซ้ำในช่วงเวลาใด การตอบกลับของแอปพลิเคชันล่าช้าหรือไม่ และตัวนับของพอร์ตเปลี่ยนแปลงหรือไม่ การเขียนเพียงว่าปัญหาเครือข่ายยังไม่เพียงพอ บันทึกที่เจาะจงช่วยให้ทีมเครือข่าย อุปกรณ์ และซอฟต์แวร์วิเคราะห์เหตุการณ์เดียวกัน แทนที่แต่ละทีมจะยืนยันเพียงว่าอุปกรณ์ของตนปกติ หากนาฬิกาของเครื่องมือจับข้อมูลไม่ตรงกัน ให้ระบุความสัมพันธ์ของเวลาเหล่านั้นก่อนนำเหตุการณ์สองเหตุการณ์ที่ไม่เกี่ยวข้องกันมาเชื่อมโยงเป็นสาเหตุที่คาดเดา
เอกสารอ้างอิงทางเทคนิค: RFC 9293: ลำดับและการตอบรับของ TCP; RFC 6298: ตัวจับเวลาการส่งซ้ำ; RFC 5681: การส่งซ้ำแบบรวดเร็วดั้งเดิมและการควบคุมความแออัด; Wireshark: การวิเคราะห์ TCP; Wireshark: การถ่ายโอนภาระงานและการตีความข้อมูลที่จับได้. แหล่งข้อมูลที่เกี่ยวข้อง: บทความทางเทคนิค และ เอกสารสวิตช์ FCTELE FCM-G24FG4 แบบจัดการได้ พร้อมพอร์ต Gigabit Ethernet 24 พอร์ต + พอร์ตคอมโบ 4 พอร์ต. ภาพประกอบต้นฉบับที่สร้างโดยมี AI ช่วยแสดงหลักการทั่วไป ไม่ใช่ผลการวัดผลิตภัณฑ์
