시리얼 바이트 이스케이프
구분자가 어떻게 데이터도 될 수 있을까요?
시리얼 수신기는 문자를 수신하지만, 애플리케이션은 메시지를 식별해야 합니다. SLIP은 페이로드의 C0와 DB를 2바이트 시퀀스로 이스케이프하여 이스케이프되지 않은 END가 패킷을 구분하도록 합니다. 수신기는 읽기 작업 사이에도 상태를 유지하면서 이 매핑을 역으로 적용합니다. 이러한 특정 값은 SLIP에 해당하며, 그 자체로 오류 검사나 보안을 제공하지는 않습니다.
문자와 패킷의 차이
문자 경계만으로는 애플리케이션 메시지를 식별할 수 없습니다.
특수 데이터 이스케이프
SLIP은 특수 페이로드 바이트를 2바이트 시퀀스로 표현합니다.
상태 유지
읽기 작업이 DB 직후에 끝나더라도 파서는 이스케이프 상태를 유지해야 합니다.
종단점과 보호 범위를 파악합니다.
실제 프로토콜과 설정을 확인합니다.
승인된 무해한 데이터로 시험합니다.
선정 및 검증 체크리스트 — 펼치기
프로토콜과 캡처 계층을 확인하고, 일반 바이트와 특수 바이트를 테스트하며, 허가된 환경에서 분할 읽기, 중복 마커 및 오류 처리를 검증하세요.
시리얼 회선은 바이트 스트림을 전달합니다. 수신 프로그램은 메시지가 어디서 끝나는지 어떻게 알 수 있을까요? 한 가지 방법은 특정 마커를 예약하는 것입니다. 하지만 측정값이나 파일에도 같은 바이트 값이 포함될 수 있으며, 이를 그대로 전송하면 끝으로 오인될 수 있습니다. 바이트 이스케이프는 이러한 모호함을 해결합니다. 이를 이해하려면 전송 속도만 볼 것이 아니라 문자 수신, 패킷 경계, 애플리케이션에서의 의미를 구분해야 합니다.
올바른 문자가 자동으로 패킷을 구성하지는 않습니다
일반적인 비동기 시리얼 인터페이스는 시작 비트, 데이터 비트, 정지 비트를 사용하여 문자를 식별합니다. 문자가 프로그램에 도달하면 바이트 시퀀스를 형성합니다. 수신기는 온도 측정값이 어디서 시작하고 끝나는지 자동으로 알지 못합니다. 문자 경계와 완전한 메시지의 경계는 서로 별개의 문제입니다.
애플리케이션 프로토콜은 고정 길이, 길이 필드, 타이밍 또는 특수 마커를 사용하여 메시지를 구분할 수 있습니다. 각 방식에는 조건과 장단점이 있습니다. 이 글에서는 간단한 시리얼 프레이밍 예인 SLIP을 사용하여 마커와 이스케이프를 설명합니다. 모든 시리얼 프로토콜이 SLIP을 사용한다거나 기존 프로토콜을 함부로 변경해도 된다는 뜻은 아닙니다.
Feichang의 FCT-1100-F1S1 단일 포트 3-in-1 시리얼 디바이스 서버는 실제 시리얼-네트워크 연결의 맥락을 제공합니다. 인터페이스나 네트워크를 통해 전달되는 바이트에 새로운 업무적 의미가 자동으로 부여되지는 않습니다. 이 글은 해당 제품의 내부 프레이밍 프로토콜을 추정하지 않습니다. 실제 기능은 문서와 설정을 확인하세요.
하나의 마커가 두 가지 역할을 할 수 있는 이유
양쪽 단말이 특정 바이트를 끝 표시로 사용하기로 합의했다고 가정해 보겠습니다. 파서는 이 바이트를 받으면 그 앞까지 버퍼에 저장된 데이터를 전달합니다. 문장의 끝을 나타내는 문장 부호와 비슷한 개념입니다. 그러나 바이너리 콘텐츠에는 어떤 바이트 값이든 포함될 수 있으므로, 어떤 값을 선택하더라도 페이로드에 그 값이 없다고 자동으로 보장되지는 않습니다.
측정 기록에는 종료 마커와 같은 값이 포함될 수 있습니다. 파서는 해당 값을 데이터로 처리해야 할까요, 아니면 경계로 처리해야 할까요? 값만으로는 두 역할을 구분할 수 없습니다. 송신기와 수신기에는 전송 시 특수 값을 표현하는 방식을 바꾸는 공통 규칙이 필요합니다.
단순히 특정 값을 금지하면 원본 데이터가 표현할 수 있는 범위가 제한되고, 측정값이 아무런 알림 없이 변경될 수 있습니다. 구리선을 광섬유로 바꿔도 이러한 모호함은 사라지지 않습니다. 광 변환은 전송 매체를 바꿀 뿐, 애플리케이션 프로토콜의 해석을 바꾸지는 않습니다. 링크 품질과 인코딩 규칙은 별도로 확인해야 합니다.
이스케이프는 데이터가 아니라 표현 방식을 바꿉니다
이스케이프는 다음 바이트를 합의된 규칙에 따라 해석하라는 신호로 볼 수 있습니다. 송신기는 페이로드를 검사하여 보호 대상 바이트 값을 특수 시퀀스로 대체합니다. 수신기는 이 매핑을 역으로 적용하여 동일한 원본 콘텐츠를 복원해야 합니다.
RFC 1055에 설명된 SLIP 예에서 16진수 값 C0는 END이고 DB는 ESC입니다. 페이로드 안의 C0는 DB DC로, 페이로드 안의 DB는 DB DD로 변환됩니다. 이스케이프되지 않은 C0는 실제 종료 경계를 나타냅니다. 이 특정 값들은 이 예에 해당하며, 모든 시리얼 프로토콜에 적용되는 것은 아닙니다.
DB도 이스케이프하는 이유는 무엇일까요? DB는 다음 바이트를 특별하게 해석하도록 하기 때문입니다. 원본의 DB를 구분 없이 전송하면 그다음의 일반 값이 이스케이프 접미 바이트로 오인될 수 있습니다. 구분자와 이스케이프 시작 바이트를 모두 보호하면 새로운 모호함이 생기는 것을 방지할 수 있습니다.
송신기에서 수신기까지 짧은 예를 따라가 보기
원본 페이로드가 11 C0 22 DB 33라고 가정해 보겠습니다. 두 특수 값은 프레이밍된 스트림에 일반 콘텐츠로 직접 넣을 수 없습니다. 인코딩 결과는 11 DB DC 22 DB DD 33가 됩니다. 실제 END 마커가 이 결과의 경계를 구분하므로 수신기는 제어 역할과 복원된 데이터를 구별할 수 있습니다.
이 그림에서는 패킷 앞뒤에 모두 C0를 배치합니다. RFC 1055에서는 누적된 잡음을 비우는 방법으로 시작 부분에 END를 보내는 방식을 설명합니다. 연속된 마커로 인해 발생하는 길이가 0인 결과를 정상적인 IP 패킷으로 전달해서는 안 됩니다. 다른 프로토콜이 반드시 양 끝에 동일한 마커를 사용하는 것은 아닙니다.
디코딩 후에는 페이로드의 C0와 DB가 다시 일반 데이터가 됩니다. 구분자 자체는 전달되는 콘텐츠에 포함되지 않습니다. 인코딩으로 인해 전송되는 바이트 수가 늘어날 수 있습니다. 시리얼 서버의 카운터, 캡처 결과, 애플리케이션 데이터 길이는 서로 다른 계층에서 측정하면 차이가 날 수 있으며, 이것만으로 데이터 손실이 입증되지는 않습니다.
수신기는 현재 상태를 기억해야 합니다
파서는 각 바이트를 항상 독립적으로 판단할 수 있는 것은 아닙니다. 적어도 일반 읽기 상태와 이스케이프 시작 바이트 뒤에서 접미 바이트를 기다리는 상태를 구분해야 합니다. 일반 상태에서 END는 패킷 경계를 나타내고, DB는 원본 데이터로 즉시 출력되는 대신 접미 바이트를 기다리는 상태로 전환시킵니다.
대기 상태에서 수신기는 합의된 매핑을 적용한 뒤 일반 상태로 돌아갑니다. 두 바이트의 관계는 파서 상태에 의해 유지되므로 두 바이트가 동일한 소프트웨어 읽기 작업에서 도착할 필요는 없습니다. 한 읽기 작업이 DB로 끝나고 다음 읽기 작업이 DC로 시작한다면, 수신기는 상태를 유지하여 변환을 완료해야 합니다.
실제 구현에는 잘못된 접미 바이트, 버퍼 한도, 빈 패킷, 중단 상황에 대한 규칙도 필요합니다. 이 글은 하나의 보편적인 오류 처리 전략을 강제하지 않습니다. 소프트웨어가 네트워크 읽기 작업마다 파싱 상태를 초기화하거나 각 읽기 결과를 하나의 메시지로 가정하면, 전송 계층이 모든 바이트를 전달했더라도 프레이밍이 실패할 수 있습니다.
경계는 오류 검사나 보안 보장이 아닙니다
이스케이프는 표현상의 모호함을 해결합니다. 오류 검출, 재전송, 인증 또는 암호화를 자동으로 추가하지는 않습니다. 스트림을 패킷으로 나누었다고 해서 각 패킷이 올바르거나 송신자를 신뢰할 수 있다는 것이 입증되지는 않습니다. SLIP 자체가 제공하는 서비스는 제한적이며, 이를 범용 산업 제어 보안 프로토콜로 간주해서는 안 됩니다.
프로토콜마다 검사와 이스케이프를 적용하는 단계도 다를 수 있습니다. PPP의 HDLC 유사 프레이밍에는 자체적인 플래그, 투명성 및 프레임 검사 규칙이 있으며, 이러한 세부 사항은 SLIP과 동일하지 않습니다. 마커 값, 이스케이프 접미 바이트 또는 검사 단계를 혼용하면 양쪽 모두 바이트를 수신하면서도 어느 쪽도 패킷을 받아들이지 못할 수 있습니다.
원본 애플리케이션 데이터, 인코딩, 물리 계층 또는 네트워크 전송, 디코딩, 애플리케이션 검증이 각각 어디에 위치하는지 정리하세요. 오류를 조사할 때는 예상 콘텐츠를 비교하기 전에 관찰 계층을 식별하세요. 인코딩된 트래픽과 디코딩된 애플리케이션 필드를 바이트 단위로 직접 비교하면 실제로는 없는 오류가 있는 것처럼 보일 수 있습니다.
반복 가능한 소규모 샘플로 합의된 규칙 확인하기
장치와 프로토콜 문서부터 확인하세요. 버전, 인터페이스 설정, 패킷화 방식 및 캡처 지점을 기록하세요. 일반 데이터, 종료 값이 포함된 데이터, 이스케이프 값이 포함된 데이터, 연속된 특수 값을 테스트하세요. 인코딩된 형태와 디코딩된 형태를 모두 확인하세요. 이는 설명을 위한 방법이며, 특정 제품을 측정했다는 주장이 아닙니다.
그런 다음 구현에서 처리해야 하는 경우에 대해 분할 읽기, 병합된 읽기 및 연결 중단을 테스트하세요. 허가된 환경에서 무해한 데이터를 사용하고, 예제 바이트를 실제 운영 명령으로 사용하지 마세요. 양쪽 단말이 서로 다른 프로토콜을 사용한다면 전송 속도를 반복해서 변경하기 전에 어느 쪽에서 변환을 수행하는지 확인하세요.
계층을 기억하세요. UART는 문자를 식별하고, 프레이밍 규칙은 메시지를 식별하며, 이스케이프는 특수 페이로드 값이 제어 마커로 오인되는 것을 방지합니다. 이를 구분하면 포트가 바이트를 수신하면서도 애플리케이션이 완전한 메시지를 재구성하지 못하는 이유를 이해할 수 있습니다.
주요 참고 자료
RFC 1055: SLIP, 1988년 6월, 인터넷 표준이 아님; RFC 1662: HDLC 유사 프레이밍의 PPP, 1994년 7월. 제품 관련 맥락: FCT-1100-F1S1 직렬 장치 서버; 이는 해당 제품이 SLIP을 사용한다는 주장이 아닙니다.
다음 중국어 기술 문서에서 번역: 중국어 원문 읽기.
자주 묻는 실무 질문
시리얼 문자를 수신하면 패킷이 자동으로 식별되나요?
아니요. UART 문자 수신과 애플리케이션 프레이밍은 별개이며, 양쪽 단말에 동일한 프레이밍 규칙이 필요합니다.
SLIP은 페이로드의 C0와 DB를 어떻게 이스케이프하나요?
페이로드의 C0는 DB DC로, 페이로드의 DB는 DB DD로 변환됩니다. 이스케이프되지 않은 END는 경계를 나타냅니다. 다른 프로토콜은 다른 규칙을 사용할 수 있습니다.
바이트 이스케이프가 무결성 검사나 암호화를 대체하나요?
아니요. 제어 마커와 페이로드 값 사이의 모호함을 제거할 뿐, 오류 검출, 재전송, 인증 또는 암호화를 자동으로 제공하지는 않습니다.
범위 및 추가 읽을거리
일반적인 SLIP 프레이밍 예이며, 특정 제품이나 측정 데이터에 관한 주장이 아닙니다.
