html Thoát byte nối tiếp và đóng khung SLIP - FCTELE
                                   +8618758069661 [email protected]
Tìm kiếm sản phẩm Hướng dẫn: dấu cách = VÀ, | = HOẶC, ! = KHÔNG

Nếu dữ liệu nối tiếp chứa dấu kết thúc thì sao? Giải thích cơ chế thoát byte

Bạn có câu hỏi? Hãy gọi cho chúng tôi ngay hôm nay!

+8618758069661

Hoặc để lại lời nhắn cho chúng tôi

Lời nhắn trực tuyến

Nếu dữ liệu nối tiếp chứa dấu kết thúc thì sao? Giải thích cơ chế thoát byte

Lượt xem: 14 +9Bài gốc của FCTELETác giả: Đội ngũ kỹ thuật FCTELE

THOÁT BYTE NỐI TIẾP

Làm thế nào một ký hiệu phân cách cũng có thể là dữ liệu?

Bộ thu nối tiếp nhận các ký tự, trong khi ứng dụng phải xác định các thông điệp. SLIP thực hiện thoát C0 và DB trong phần tải bằng các chuỗi hai byte để END không được thoát có thể phân cách gói tin. Bộ thu đảo ngược ánh xạ này đồng thời duy trì trạng thái qua các lần đọc. Những giá trị cụ thể này thuộc về SLIP và không tự động cung cấp khả năng kiểm tra lỗi hay bảo mật.

01

Ký tự và gói tin

A character boundary alone does not identify an application message.UARTMessage

Chỉ riêng ranh giới ký tự không xác định được một thông điệp ứng dụng.

02

Thoát dữ liệu đặc biệt

SLIP represents special payload bytes with two-byte sequences.C0DB DCDBDB DD

SLIP biểu diễn các byte đặc biệt trong phần tải bằng các chuỗi hai byte.

03

Ghi nhớ trạng thái

A parser must retain its escape state even when a read ends after DB.normal + DC → DCafter DB + DC → C0

Bộ phân tích phải giữ trạng thái thoát ngay cả khi một lần đọc kết thúc sau DB.

01 Xác định

Xác định các điểm cuối và phạm vi.

02 Kiểm tra

Xác nhận giao thức và các thiết lập thực tế.

03 Xác minh

Thử nghiệm bằng dữ liệu vô hại được phép sử dụng.

Danh sách kiểm tra lựa chọn và xác minh — mở rộng

Xác nhận giao thức và lớp thu thập dữ liệu; thử các byte thông thường và đặc biệt; kiểm tra các lần đọc bị chia tách, ký hiệu lặp và cách xử lý lỗi trong môi trường được phép.

Đường truyền nối tiếp cung cấp một luồng byte. Làm thế nào chương trình nhận biết được thông điệp kết thúc ở đâu? Một cách là dành riêng một ký hiệu đánh dấu. Nhưng một phép đo hoặc tệp có thể chứa cùng giá trị byte đó, và việc gửi nguyên trạng có thể khiến nó bị hiểu nhầm là dấu kết thúc. Thoát byte giải quyết sự nhập nhằng này. Để hiểu cơ chế này, cần phân biệt việc nhận ký tự, ranh giới gói tin và ý nghĩa ở cấp ứng dụng thay vì chỉ xem xét tốc độ baud.

Thiết bị nối tiếp và máy chủ minh họa ranh giới ký tự UART và thông điệp
Hình 1: Minh họa tổng quát có sự hỗ trợ của AI, không phải giao thức của một sản phẩm cụ thể.

Các ký tự chính xác không tự động tạo thành một gói tin

Một giao diện nối tiếp bất đồng bộ thông dụng sử dụng bit bắt đầu, các bit dữ liệu và các bit dừng để xác định một ký tự. Khi các ký tự đến chương trình, chúng tạo thành một chuỗi byte. Bộ thu không tự động biết một giá trị đo nhiệt độ bắt đầu và kết thúc ở đâu. Ranh giới ký tự và ranh giới thông điệp hoàn chỉnh là hai vấn đề riêng biệt.

Giao thức ứng dụng có thể sử dụng độ dài cố định, trường độ dài, thời gian hoặc các ký hiệu đặc biệt để phân cách thông điệp. Mỗi phương pháp đều có điều kiện áp dụng và sự đánh đổi. Bài viết này sử dụng SLIP, một ví dụ đơn giản về đóng khung nối tiếp, để giải thích ký hiệu đánh dấu và cơ chế thoát. Bài viết không hàm ý rằng mọi giao thức nối tiếp đều sử dụng SLIP hoặc có thể tùy tiện thay đổi một giao thức hiện có.

Máy chủ thiết bị nối tiếp ba trong một, một cổng FCT-1100-F1S1 của Feichang cung cấp bối cảnh thực tế về chuyển đổi nối tiếp sang mạng. Các byte được chuyển tiếp qua giao diện hoặc mạng không tự động có thêm ý nghĩa nghiệp vụ mới. Bài viết này không suy đoán giao thức đóng khung nội bộ của sản phẩm; hãy kiểm tra tài liệu và cấu hình để biết các khả năng thực tế của sản phẩm.

Vì sao một ký hiệu đánh dấu có thể có hai vai trò

Giả sử cả hai đầu thống nhất rằng một byte nhất định đánh dấu điểm kết thúc. Khi nhận được byte đó, bộ phân tích chuyển giao dữ liệu đã lưu trong bộ đệm trước đó. Ý tưởng này giống như dấu câu đánh dấu kết thúc một câu. Tuy nhiên, nội dung nhị phân có thể chứa bất kỳ giá trị byte nào; không có giá trị được chọn nào mặc nhiên không xuất hiện trong phần tải.

Một bản ghi đo lường có thể chứa giá trị trùng với ký hiệu kết thúc. Bộ phân tích nên coi lần xuất hiện đó là dữ liệu hay ranh giới? Chỉ riêng giá trị không thể giải đáp cả hai câu hỏi. Bên gửi và bên nhận cần có quy tắc chung để thay đổi cách biểu diễn các giá trị đặc biệt trên đường truyền.

Chỉ đơn giản cấm một giá trị sẽ hạn chế những gì dữ liệu gốc có thể biểu đạt và có thể âm thầm làm thay đổi các giá trị đo. Thay cáp đồng bằng cáp quang cũng không loại bỏ sự nhập nhằng này: chuyển đổi quang thay đổi môi trường truyền dẫn, chứ không thay đổi cách diễn giải của giao thức ứng dụng. Chất lượng liên kết và quy tắc mã hóa cần được kiểm tra riêng.

Thoát thay đổi cách biểu diễn, không thay đổi dữ liệu

Có thể hiểu cơ chế thoát là một tín hiệu để diễn giải byte tiếp theo theo quy tắc đã thống nhất. Bên gửi kiểm tra phần tải và thay các giá trị byte cần bảo vệ bằng những chuỗi đặc biệt. Bên nhận đảo ngược ánh xạ này và phải thu được nội dung gốc giống hệt.

Trong ví dụ SLIP được mô tả trong RFC 1055, giá trị thập lục phân C0 là END và DB là ESC. C0 trong phần tải trở thành DB DC; DB trong phần tải trở thành DB DD. C0 không được thoát tạo ra ranh giới kết thúc thực sự. Những giá trị cụ thể này thuộc về ví dụ này, không phải mọi giao thức nối tiếp.

Vì sao cũng phải thoát DB? Nó mở đầu cách diễn giải đặc biệt cho byte tiếp theo. Nếu một DB gốc được gửi mà không có cách phân biệt, giá trị thông thường tiếp theo có thể bị hiểu nhầm là hậu tố thoát. Bảo vệ cả ký hiệu phân cách và byte mở đầu chuỗi thoát giúp tránh tạo ra sự nhập nhằng mới.

SLIP mã hóa C0 trong phần tải thành DB DC và DB thành DB DD
Hình 2: Ví dụ minh họa có các ký hiệu END ở đầu và cuối; các giao thức khác có thể khác.

Theo dõi một ví dụ ngắn từ bên gửi đến bên nhận

Xét phần tải gốc 11 C0 22 DB 33. Không thể đưa trực tiếp hai giá trị đặc biệt vào luồng đã đóng khung như nội dung thông thường. Quá trình mã hóa tạo ra 11 DB DC 22 DB DD 33; các ký hiệu END thực sự phân cách kết quả để bộ thu có thể phân biệt vai trò điều khiển với dữ liệu được khôi phục.

Minh họa này đặt C0 cả trước và sau gói tin. RFC 1055 đề cập việc gửi END ở đầu như một cách loại bỏ nhiễu tích lũy; kết quả có độ dài bằng không từ các ký hiệu liên tiếp không được chuyển giao như một gói IP thông thường. Các giao thức khác không nhất thiết sử dụng ký hiệu giống nhau ở cả hai đầu.

Sau khi giải mã, C0 và DB trong phần tải lại trở thành dữ liệu thông thường. Bản thân các ký hiệu phân cách không thuộc nội dung được chuyển giao. Mã hóa có thể làm tăng số byte trên đường truyền. Bộ đếm của máy chủ nối tiếp, dữ liệu thu thập và độ dài ở cấp ứng dụng có thể khác nhau khi được đo tại các lớp khác nhau mà không chứng minh có mất dữ liệu.

Bộ thu phải ghi nhớ trạng thái hiện tại

Bộ phân tích không phải lúc nào cũng có thể xử lý từng byte một cách độc lập. Ít nhất, nó phải phân biệt trạng thái đọc bình thường với trạng thái chờ hậu tố sau byte mở đầu chuỗi thoát. Ở trạng thái bình thường, END đánh dấu ranh giới gói tin; DB chuyển trạng thái sang chờ hậu tố thay vì lập tức xuất DB như dữ liệu gốc.

Ở trạng thái chờ, bộ thu áp dụng ánh xạ đã thống nhất rồi trở lại trạng thái bình thường. Quan hệ giữa hai byte được duy trì bằng trạng thái của bộ phân tích; các byte không cần đến trong cùng một lần đọc của phần mềm. Nếu một lần đọc kết thúc bằng DB và lần tiếp theo bắt đầu bằng DC, bộ thu phải giữ trạng thái và hoàn tất chuyển đổi.

Một triển khai thực tế cũng cần các quy tắc cho hậu tố không hợp lệ, giới hạn bộ đệm, gói rỗng và tình huống gián đoạn. Bài viết này không áp đặt một chiến lược xử lý lỗi chung cho mọi trường hợp. Nếu phần mềm xóa trạng thái phân tích sau mỗi lần đọc từ mạng, hoặc cho rằng mỗi lần đọc là một thông điệp, quá trình đóng khung có thể thất bại dù cơ chế truyền tải đã chuyển giao đầy đủ mọi byte.

Byte DC tạo ra các kết quả khác nhau tùy theo trạng thái bộ thu
Hình 3: Ví dụ tổng quát về trạng thái bộ thu; trạng thái được duy trì qua các lần đọc.

Ranh giới không phải là phép kiểm tra lỗi hay bảo đảm bảo mật

Thoát giải quyết sự nhập nhằng trong cách biểu diễn. Nó không tự động bổ sung khả năng phát hiện lỗi, truyền lại, xác thực hoặc mã hóa. Chia một luồng thành các gói không chứng minh rằng mỗi gói đều chính xác hay bên gửi đáng tin cậy. Bản thân SLIP chỉ cung cấp các dịch vụ hạn chế và không nên được xem là giao thức bảo mật chung cho điều khiển công nghiệp.

Các giao thức khác nhau cũng có thể áp dụng kiểm tra và thoát ở những giai đoạn khác nhau. Cơ chế đóng khung kiểu HDLC của PPP có các quy tắc riêng về cờ, tính trong suốt dữ liệu và kiểm tra khung; những chi tiết đó không giống SLIP. Việc trộn lẫn các giá trị ký hiệu, hậu tố thoát hoặc các giai đoạn kiểm tra có thể khiến cả hai bên đều nhận được byte nhưng không bên nào chấp nhận một gói tin.

Xác định vị trí của dữ liệu ứng dụng gốc, quá trình mã hóa, truyền tải vật lý hoặc qua mạng, giải mã và kiểm tra hợp lệ ở cấp ứng dụng. Khi điều tra lỗi, hãy xác định lớp quan sát trước khi so sánh nội dung mong đợi. So sánh trực tiếp từng byte của lưu lượng đã mã hóa với các trường ứng dụng đã giải mã có thể tạo ra một lỗi biểu kiến vốn không tồn tại.

Kiểm tra quy tắc đã thống nhất bằng các mẫu nhỏ có thể lặp lại

Bắt đầu với tài liệu thiết bị và giao thức. Ghi lại phiên bản, cài đặt giao diện, cách chia gói và các điểm thu thập dữ liệu. Thử dữ liệu thông thường, dữ liệu chứa giá trị kết thúc, dữ liệu chứa giá trị thoát và các giá trị đặc biệt liên tiếp. Kiểm tra cả dạng đã mã hóa và đã giải mã. Đây là các phương pháp minh họa, không phải tuyên bố rằng một sản phẩm cụ thể đã được đo kiểm.

Sau đó thử các lần đọc bị chia tách, các lần đọc gộp và kết nối bị gián đoạn ở những trường hợp mà triển khai cần xử lý. Sử dụng dữ liệu vô hại trong môi trường được phép, không dùng các byte ví dụ làm lệnh trên hệ thống sản xuất đang vận hành. Nếu các đầu cuối sử dụng giao thức khác nhau, hãy xác định bên nào thực hiện chuyển đổi trước khi liên tục thay đổi tốc độ baud.

Hãy nhớ các lớp: UART xác định ký tự, quy tắc đóng khung xác định thông điệp, còn cơ chế thoát ngăn các giá trị đặc biệt trong phần tải bị hiểu nhầm là ký hiệu điều khiển. Phân biệt các lớp này giúp giải thích vì sao một cổng có thể nhận được byte nhưng ứng dụng vẫn không thể tái tạo một thông điệp hoàn chỉnh.

Tài liệu tham khảo chính

RFC 1055: SLIP, tháng 6 năm 1988, không phải tiêu chuẩn Internet; RFC 1662: PPP với cơ chế đóng khung kiểu HDLC, tháng 7 năm 1994. Bối cảnh sản phẩm: máy chủ thiết bị nối tiếp FCT-1100-F1S1; điều này không khẳng định sản phẩm sử dụng SLIP.

Dịch từ bài viết kỹ thuật bằng tiếng Trung: Đọc bài viết gốc bằng tiếng Trung.

Các câu hỏi thực tế thường gặp

Việc nhận ký tự nối tiếp có tự động xác định được một gói tin không?

Không. Việc nhận ký tự UART và đóng khung ở cấp ứng dụng là hai việc riêng biệt; cả hai đầu cần có cùng quy tắc đóng khung.

SLIP thực hiện thoát C0 và DB trong phần tải như thế nào?

C0 trong phần tải trở thành DB DC và DB trong phần tải trở thành DB DD; END không được thoát biểu thị một ranh giới. Các giao thức khác có thể sử dụng quy tắc khác.

Thoát byte có thay thế việc kiểm tra tính toàn vẹn hoặc mã hóa không?

Không. Cơ chế này loại bỏ sự nhập nhằng giữa ký hiệu điều khiển và giá trị trong phần tải; nó không tự động cung cấp khả năng phát hiện lỗi, truyền lại, xác thực hoặc mã hóa.

Phạm vi và tài liệu đọc thêm

Ví dụ tổng quát về đóng khung SLIP, không phải tuyên bố về một sản phẩm cụ thể hay dữ liệu đo kiểm.

Đóng một chiều TCP và phản hồi nối tiếp · Tải đơn vị RS485 và ngân sách tải của bộ điều khiển đường truyền

Chia sẻ bài viết này