การเอสเคปไบต์อนุกรม
ตัวคั่นจะเป็นข้อมูลด้วยได้อย่างไร?
ตัวรับข้อมูลอนุกรมเห็นอักขระ ขณะที่แอปพลิเคชันต้องระบุข้อความ SLIP เอสเคป C0 และ DB ในเพย์โหลดด้วยลำดับสองไบต์ เพื่อให้ END ที่ไม่ผ่านการเอสเคปใช้คั่นแพ็กเก็ตได้ ตัวรับจะแปลงกลับตามกฎโดยคงสถานะไว้ข้ามการอ่าน ค่าเฉพาะเหล่านี้เป็นของ SLIP และไม่ได้ให้การตรวจสอบข้อผิดพลาดหรือความปลอดภัยโดยอัตโนมัติ
อักขระกับแพ็กเก็ต
ขอบเขตอักขระเพียงอย่างเดียวไม่ได้ระบุข้อความของแอปพลิเคชัน
เอสเคปข้อมูลพิเศษ
SLIP แทนไบต์พิเศษในเพย์โหลดด้วยลำดับสองไบต์
จดจำสถานะ
ตัวแยกวิเคราะห์ต้องคงสถานะเอสเคปไว้ แม้การอ่านจะสิ้นสุดหลัง DB
ระบุปลายทางและขอบเขตการป้องกัน
ยืนยันโปรโตคอลและการตั้งค่าที่ใช้จริง
ทดสอบด้วยข้อมูลที่ไม่ก่ออันตรายและได้รับอนุญาต
รายการตรวจสอบสำหรับการเลือกและการตรวจยืนยัน — ขยาย
ยืนยันโปรโตคอลและชั้นที่บันทึกข้อมูล ทดสอบไบต์ทั่วไปและไบต์พิเศษ ตรวจสอบการอ่านที่ถูกแบ่ง เครื่องหมายซ้ำ และการจัดการข้อผิดพลาดในสภาพแวดล้อมที่ได้รับอนุญาต
สายอนุกรมส่งข้อมูลเป็นสตรีมไบต์ โปรแกรมฝั่งรับจะรู้ได้อย่างไรว่าข้อความสิ้นสุดตรงไหน? วิธีหนึ่งคือสงวนเครื่องหมายไว้ แต่ค่าที่วัดหรือไฟล์อาจมีค่าไบต์เดียวกัน และหากส่งโดยไม่เปลี่ยนแปลงก็อาจถูกเข้าใจผิดว่าเป็นจุดสิ้นสุด การเอสเคปไบต์ช่วยแก้ความกำกวมนี้ เพื่อให้เข้าใจ ควรแยกการรับอักขระ ขอบเขตแพ็กเก็ต และความหมายระดับแอปพลิเคชันออกจากกัน แทนที่จะพิจารณาเพียงอัตราบอด
อักขระที่ถูกต้องไม่ได้ประกอบเป็นแพ็กเก็ตโดยอัตโนมัติ
อินเทอร์เฟซอนุกรมแบบอะซิงโครนัสทั่วไปใช้บิตเริ่มต้น บิตข้อมูล และบิตหยุดเพื่อระบุอักขระ เมื่ออักขระมาถึงโปรแกรม อักขระเหล่านั้นจะเป็นลำดับไบต์ ตัวรับไม่ได้รู้โดยอัตโนมัติว่าค่าอุณหภูมิเริ่มต้นและสิ้นสุดตรงไหน ขอบเขตอักขระและขอบเขตข้อความที่สมบูรณ์เป็นปัญหาคนละส่วน
โปรโตคอลระดับแอปพลิเคชันอาจใช้ความยาวคงที่ ฟิลด์ความยาว จังหวะเวลา หรือเครื่องหมายพิเศษเพื่อคั่นข้อความ แต่ละวิธีมีเงื่อนไขและข้อแลกเปลี่ยน บทความนี้ใช้ SLIP ซึ่งเป็นตัวอย่างการจัดเฟรมอนุกรมอย่างง่าย เพื่ออธิบายเครื่องหมายและการเอสเคป ไม่ได้หมายความว่าโปรโตคอลอนุกรมทุกชนิดใช้ SLIP หรือควรเปลี่ยนโปรโตคอลที่มีอยู่โดยไม่พิจารณาอย่างรอบคอบ
เซิร์ฟเวอร์อุปกรณ์อนุกรมแบบสามในหนึ่งพอร์ตเดียวรุ่น FCT-1100-F1S1 ของ Feichang เป็นบริบทการใช้งานจริงของการเชื่อมต่ออนุกรมกับเครือข่าย ไบต์ที่ส่งต่อผ่านอินเทอร์เฟซหรือเครือข่ายไม่ได้มีความหมายทางธุรกิจใหม่โดยอัตโนมัติ บทความนี้ไม่ได้อนุมานโปรโตคอลการจัดเฟรมภายในของผลิตภัณฑ์ โปรดตรวจสอบเอกสารและการกำหนดค่าเพื่อทราบความสามารถที่แท้จริง
เหตุใดเครื่องหมายเดียวจึงมีได้สองบทบาท
สมมติว่าปลายทางทั้งสองตกลงกันว่าไบต์ค่าหนึ่งใช้ระบุจุดสิ้นสุด เมื่อได้รับไบต์นั้น ตัวแยกวิเคราะห์จะส่งมอบข้อมูลก่อนหน้าที่เก็บไว้ในบัฟเฟอร์ แนวคิดนี้คล้ายเครื่องหมายวรรคตอนที่ระบุจุดจบของประโยค อย่างไรก็ตาม เนื้อหาไบนารีสามารถมีค่าไบต์ใดก็ได้ ไม่มีค่าใดที่เลือกแล้วจะรับประกันได้โดยอัตโนมัติว่าไม่ปรากฏในเพย์โหลด
ระเบียนค่าที่วัดอาจมีค่าเดียวกับเครื่องหมายสิ้นสุด ตัวแยกวิเคราะห์ควรถือว่าค่าที่ปรากฏนั้นเป็นข้อมูลหรือเป็นขอบเขต? ค่าเพียงอย่างเดียวไม่อาจบอกได้ว่าควรตีความแบบใด ผู้ส่งและผู้รับจึงต้องมีกฎร่วมกันที่เปลี่ยนวิธีแทนค่าพิเศษระหว่างการส่ง
การห้ามใช้ค่าหนึ่งโดยตรงจะจำกัดสิ่งที่ข้อมูลต้นฉบับสามารถสื่อได้ และอาจเปลี่ยนค่าที่วัดโดยไม่มีการแจ้งเตือน การเปลี่ยนสายทองแดงเป็นใยแก้วนำแสงก็ไม่ได้ขจัดความกำกวมนี้เช่นกัน การแปลงเป็นสัญญาณแสงเปลี่ยนสื่อส่งสัญญาณ ไม่ใช่การตีความของโปรโตคอลระดับแอปพลิเคชัน ต้องตรวจสอบคุณภาพลิงก์และกฎการเข้ารหัสแยกกัน
การเอสเคปเปลี่ยนรูปแบบการแทนค่า ไม่ใช่ตัวข้อมูล
การเอสเคปอาจมองได้ว่าเป็นสัญญาณให้ตีความไบต์ถัดไปตามกฎที่ตกลงกัน ผู้ส่งตรวจสอบเพย์โหลดและแทนค่าไบต์ที่ต้องป้องกันด้วยลำดับพิเศษ ผู้รับจะแปลงกลับตามกฎและควรได้เนื้อหาต้นฉบับเดิม
ในตัวอย่าง SLIP ที่อธิบายใน RFC 1055 ค่าเลขฐานสิบหก C0 คือ END และ DB คือ ESC โดย C0 ภายในเพย์โหลดจะเปลี่ยนเป็น DB DC ส่วน DB ภายในเพย์โหลดจะเปลี่ยนเป็น DB DD ขณะที่ C0 ที่ไม่ผ่านการเอสเคปใช้ระบุขอบเขตสิ้นสุดจริง ค่าเฉพาะเหล่านี้เป็นของตัวอย่างนี้ ไม่ใช่ของโปรโตคอลอนุกรมทุกชนิด
เหตุใดจึงต้องเอสเคป DB ด้วย? เพราะมันทำให้ไบต์ถัดไปถูกตีความเป็นพิเศษ หากส่ง DB ต้นฉบับโดยไม่แยกให้ชัดเจน ค่าทั่วไปที่ตามมาอาจถูกเข้าใจผิดว่าเป็นไบต์ต่อท้ายเอสเคป การป้องกันทั้งตัวคั่นและไบต์นำเอสเคปช่วยหลีกเลี่ยงการสร้างความกำกวมใหม่
ติดตามตัวอย่างสั้น ๆ จากผู้ส่งไปยังผู้รับ
สมมติให้เพย์โหลดต้นฉบับเป็น 11 C0 22 DB 33 ค่าพิเศษทั้งสองไม่สามารถใส่ลงในสตรีมที่จัดเฟรมแล้วโดยตรงในฐานะเนื้อหาทั่วไปได้ เมื่อเข้ารหัสจะได้ 11 DB DC 22 DB DD 33 จากนั้นใช้เครื่องหมาย END จริงคั่นผลลัพธ์ เพื่อให้ตัวรับแยกบทบาทควบคุมออกจากข้อมูลที่แปลงกลับได้
ภาพประกอบนี้วาง C0 ไว้ทั้งก่อนและหลังแพ็กเก็ต RFC 1055 กล่าวถึงการส่ง END ที่จุดเริ่มต้นเพื่อกำจัดสัญญาณรบกวนที่สะสมอยู่ ผลลัพธ์ที่มีความยาวเป็นศูนย์จากเครื่องหมายที่ต่อเนื่องกันไม่ควรถูกส่งมอบเป็นแพ็กเก็ต IP ปกติ โปรโตคอลอื่นไม่จำเป็นต้องใช้เครื่องหมายเดียวกันที่ปลายทั้งสอง
หลังถอดรหัส C0 และ DB ในเพย์โหลดจะกลับเป็นข้อมูลทั่วไปอีกครั้ง ตัวคั่นเองไม่ใช่ส่วนหนึ่งของเนื้อหาที่ส่งมอบ การเข้ารหัสอาจเพิ่มจำนวนไบต์ที่ส่งบนสาย ค่าตัวนับของเซิร์ฟเวอร์อนุกรม ข้อมูลที่บันทึก และความยาวข้อมูลของแอปพลิเคชันอาจต่างกันเมื่อวัดคนละชั้น โดยไม่ได้พิสูจน์ว่าข้อมูลสูญหาย
ตัวรับต้องจดจำสถานะปัจจุบัน
ตัวแยกวิเคราะห์ไม่สามารถตัดสินแต่ละไบต์แยกจากกันได้เสมอไป อย่างน้อยต้องแยกการอ่านตามปกติออกจากการรอไบต์ต่อท้ายหลังไบต์นำเอสเคป ในสถานะปกติ END ระบุขอบเขตแพ็กเก็ต ส่วน DB จะเปลี่ยนสถานะเป็นรอไบต์ต่อท้าย แทนที่จะส่ง DB ออกเป็นข้อมูลต้นฉบับทันที
ในสถานะรอ ตัวรับจะแปลงค่าตามกฎที่ตกลงกันและกลับสู่สถานะปกติ ความสัมพันธ์ระหว่างสองไบต์คงอยู่ด้วยสถานะของตัวแยกวิเคราะห์ ไบต์ทั้งสองไม่จำเป็นต้องมาถึงในการอ่านครั้งเดียวกันของซอฟต์แวร์ หากการอ่านครั้งหนึ่งสิ้นสุดด้วย DB และครั้งถัดไปเริ่มด้วย DC ตัวรับต้องคงสถานะไว้และแปลงค่าให้เสร็จสมบูรณ์
การนำไปใช้งานจริงยังต้องมีกฎสำหรับไบต์ต่อท้ายที่ไม่ถูกต้อง ขีดจำกัดบัฟเฟอร์ แพ็กเก็ตว่าง และการหยุดชะงัก บทความนี้ไม่ได้กำหนดกลยุทธ์จัดการข้อผิดพลาดแบบเดียวสำหรับทุกกรณี หากซอฟต์แวร์ล้างสถานะการแยกวิเคราะห์ทุกครั้งที่อ่านจากเครือข่าย หรือถือว่าการอ่านแต่ละครั้งคือหนึ่งข้อความ การจัดเฟรมอาจล้มเหลวแม้ระบบขนส่งจะส่งไบต์มาครบทั้งหมด
ขอบเขตไม่ใช่การตรวจสอบข้อผิดพลาดหรือการรับประกันความปลอดภัย
การเอสเคปแก้ความกำกวมของการแทนค่า แต่ไม่ได้เพิ่มการตรวจจับข้อผิดพลาด การส่งซ้ำ การยืนยันตัวตน หรือการเข้ารหัสโดยอัตโนมัติ การแบ่งสตรีมเป็นแพ็กเก็ตไม่ได้พิสูจน์ว่าแต่ละแพ็กเก็ตถูกต้องหรือผู้ส่งเชื่อถือได้ ตัว SLIP เองให้บริการอย่างจำกัด และไม่ควรถือเป็นโปรโตคอลความปลอดภัยทั่วไปสำหรับระบบควบคุมอุตสาหกรรม
โปรโตคอลต่างชนิดอาจใช้การตรวจสอบและการเอสเคปในขั้นตอนที่ต่างกันด้วย การจัดเฟรมแบบคล้าย HDLC ของ PPP มีกฎแฟล็ก การคงข้อมูลโดยไม่ให้ปะปนกับเครื่องหมายควบคุม และการตรวจสอบเฟรมของตนเอง รายละเอียดเหล่านี้ไม่เหมือน SLIP การผสมค่าเครื่องหมาย ไบต์ต่อท้ายเอสเคป หรือขั้นตอนตรวจสอบเข้าด้วยกันอาจทำให้ทั้งสองฝั่งได้รับไบต์ แต่ไม่มีฝั่งใดยอมรับแพ็กเก็ต
ระบุตำแหน่งของข้อมูลแอปพลิเคชันต้นฉบับ การเข้ารหัส การขนส่งทางกายภาพหรือเครือข่าย การถอดรหัส และการตรวจสอบความถูกต้องของแอปพลิเคชัน เมื่อสืบหาข้อผิดพลาด ให้ระบุชั้นที่สังเกตก่อนเปรียบเทียบเนื้อหาที่คาดหวัง การเปรียบเทียบทราฟฟิกที่เข้ารหัสกับฟิลด์แอปพลิเคชันที่ถอดรหัสแล้วโดยตรงแบบไบต์ต่อไบต์ อาจทำให้ดูเหมือนมีข้อผิดพลาดทั้งที่ไม่มี
ตรวจสอบกฎที่ตกลงกันด้วยตัวอย่างขนาดเล็กที่ทดสอบซ้ำได้
เริ่มจากเอกสารอุปกรณ์และโปรโตคอล บันทึกเวอร์ชัน การตั้งค่าอินเทอร์เฟซ การแบ่งข้อมูลเป็นแพ็กเก็ต และจุดบันทึกข้อมูล ทดสอบข้อมูลทั่วไป ข้อมูลที่มีค่าสิ้นสุด ข้อมูลที่มีค่าเอสเคป และค่าพิเศษที่ต่อเนื่องกัน ตรวจสอบทั้งรูปแบบที่เข้ารหัสและถอดรหัสแล้ว วิธีเหล่านี้เป็นเพียงตัวอย่าง ไม่ใช่คำกล่าวอ้างว่าได้ตรวจวัดผลิตภัณฑ์ใดโดยเฉพาะ
จากนั้นทดสอบการอ่านที่ถูกแบ่ง การอ่านที่รวมข้อมูลเข้าด้วยกัน และการเชื่อมต่อที่ขาดช่วง ในกรณีที่การใช้งานต้องรองรับ ใช้ข้อมูลที่ไม่ก่ออันตรายในสภาพแวดล้อมที่ได้รับอนุญาต อย่านำไบต์ตัวอย่างไปใช้เป็นคำสั่งกับระบบผลิตจริง หากปลายทางใช้โปรโตคอลต่างกัน ให้ระบุว่าใครเป็นผู้แปลงโปรโตคอลก่อนเปลี่ยนอัตราบอดซ้ำ ๆ
จดจำการแบ่งชั้นไว้: UART ระบุอักขระ กฎการจัดเฟรมระบุข้อความ และการเอสเคปป้องกันไม่ให้ค่าพิเศษในเพย์โหลดถูกเข้าใจผิดว่าเป็นเครื่องหมายควบคุม การแยกสิ่งเหล่านี้ออกจากกันอธิบายได้ว่าเหตุใดพอร์ตจึงรับไบต์ได้ แต่แอปพลิเคชันยังไม่สามารถประกอบข้อความที่สมบูรณ์กลับคืนได้
เอกสารอ้างอิงหลัก
RFC 1055: SLIP, มิถุนายน 1988, ไม่ใช่มาตรฐานอินเทอร์เน็ต; RFC 1662: PPP ในการจัดเฟรมแบบคล้าย HDLC, กรกฎาคม 1994 บริบทผลิตภัณฑ์: เซิร์ฟเวอร์อุปกรณ์อนุกรม FCT-1100-F1S1; ข้อความนี้ไม่ได้กล่าวอ้างว่าผลิตภัณฑ์ใช้ SLIP
แปลจากบทความทางเทคนิคภาษาจีน: อ่านบทความต้นฉบับภาษาจีน.
คำถามที่พบบ่อยในการใช้งานจริง
การรับอักขระอนุกรมทำให้ระบุแพ็กเก็ตได้โดยอัตโนมัติหรือไม่?
ไม่ การรับอักขระของ UART และการจัดเฟรมของแอปพลิเคชันเป็นคนละส่วน ปลายทางทั้งสองต้องใช้กฎการจัดเฟรมเดียวกัน
SLIP เอสเคป C0 และ DB ในเพย์โหลดอย่างไร?
C0 ในเพย์โหลดจะเปลี่ยนเป็น DB DC และ DB ในเพย์โหลดจะเปลี่ยนเป็น DB DD ส่วน END ที่ไม่ผ่านการเอสเคประบุขอบเขต โปรโตคอลอื่นอาจใช้กฎต่างกัน
การเอสเคปไบต์ใช้แทนการตรวจสอบความครบถ้วนถูกต้องหรือการเข้ารหัสได้หรือไม่?
ไม่ การเอสเคปขจัดความกำกวมระหว่างเครื่องหมายควบคุมกับค่าในเพย์โหลด แต่ไม่ได้ให้การตรวจจับข้อผิดพลาด การส่งซ้ำ การยืนยันตัวตน หรือการเข้ารหัสโดยอัตโนมัติ
ขอบเขตและข้อมูลอ่านเพิ่มเติม
ตัวอย่างการจัดเฟรม SLIP แบบทั่วไป ไม่ใช่คำกล่าวอ้างเกี่ยวกับผลิตภัณฑ์เฉพาะหรือข้อมูลที่ตรวจวัด
การปิดการเชื่อมต่อครึ่งทิศทางของ TCP และการตอบกลับทางอนุกรม · ยูนิตโหลดของ RS485 และขีดความสามารถในการขับโหลดของไดรเวอร์
