요약

  • RFC 1055는 SLIP을 매우 작은 비표준 직렬 회선 프레이밍 관례로 기술합니다. END는 패킷을 닫고, ESC는 END 또는 ESC 데이터 바이트가 프레이밍으로 오인되지 않도록 막습니다.
  • 문서가 제안한 선행 END는 값싼 재동기화 동작입니다. 회선 잡음이 수신자 쪽에 남긴 바이트를 플러시하며, 연달아 오는 END는 제공된 수신기 코드가 무시하는 빈 패킷을 만듭니다.
  • 복구된 경계는 페이로드가 온전하거나 상위 계층 상태가 정렬되어 있다는 증거가 아닙니다. RFC 1144와 이후 PPP 프레이밍은 이 역할 분담을 드러내 보이도록 했으며, 경계 부호 하나로 접어버리지 않았습니다.

과장하지 않기로 한 프로토콜

SLIP의 역사적 매력은 풍부함이 아니었습니다. 절제였습니다. 1988년에 발표된RFC 1055는 Serial Line IP를 점대점 직렬 TCP/IP의 사실상(de facto) 관례라고 부르며, 이것이 인터넷 표준이 아니라고 정직하게 밝힙니다. 그 설명은 더 드러납니다. SLIP은 "단지 패킷 프레이밍 프로토콜"일 뿐이라는 것입니다. 직렬 회선에서 IP 패킷을 프레임으로 감싸는 문자열 규칙만 정의할 뿐, 그 이상은 아무것도 정의하지 않습니다.

마지막 구절은 사과문이 아니라 설계 경계입니다. RFC 1055는 SLIP이 주소 지정, 패킷 유형 식별, 오류 검출이나 복구, 압축 중 어느 것도 제공하지 않는다고 명시합니다. 두 피어는 IP 주소 정보를 다른 수단으로 알아야 합니다. 링크가 SLIP만으로 여러 네트워크 프로토콜을 유형 필드로 구분해 실어 보낼 수는 없습니다. 손상된 프레임에는 SLIP 수준의 무결성 증명서가 주어지지 않습니다. 코드를 쉽게 구현하게 만든 그 작음이, 다른 시스템에게 할 일을 남겨둔 것이기도 했습니다.

간결한 과거 포맷을 나중의 더 풍부한 포맷의 미완성 버전으로 읽고 싶은 유혹이 있습니다. 그것은 보통 잘못된 질문입니다. 더 나은 질문은 이렇습니다. 이 메커니즘이 지역적으로, 결정적으로, 그리고 세계의 나머지 부분에 대한 주장 없이 어떤 결정을 내릴 수 있었는가? SLIP의 경우 답은 좁았습니다. 끊김 없는 직렬 바이트 스트림을 읽는 수신자는 하나의 IP 데이터그램이 어디서 끝나는지 알아야 했습니다. 일반 데이터 안에서 두 개의 특수 바이트가 그 답을 사칭하지 못하도록 할 방법도 필요했습니다. 링크 권위에 관한 새로운 신화는 필요하지 않았습니다.

RFC 1055는 첫 번째 역할에END(8진수0300, 10진수 192)를, 두 번째 역할에ESC(8진수0333, 10진수 219)를 배정합니다. IP 패킷을 전송하는 동안 송신자는 END와 같은 데이터 바이트를 ESC와 8진수0334의 조합으로, ESC와 같은 데이터 바이트를 ESC와 8진수0335의 조합으로 바꿉니다. 마지막 데이터 바이트 뒤에는 END를 보냅니다. 수신자는 END를 만날 때까지 바이트를 읽고 그 두 치환을 되돌립니다. 이 문법은 의도적으로 지역적입니다. END는 해당 상태의 SLIP 수신자에게만 구조적 의미를 가지며, ESC는 같은 문법 안에서 두 개의 예약값에만 작용합니다.

이것은 일반적인 "이스케이핑"이 아닙니다. 책임의 작은 배분입니다. 송신자는 프레이밍 규칙과 충돌할 데이터 바이트를 보존하고, 수신자는 그것을 복원합니다. 어느 쪽도 IP 데이터그램이 의미상 바람직한지, 피어가 회선을 쓸 자격이 있는지, 이전 바이트가 손상되었는지는 알지 못합니다. 이 메커니즘은 구분자가 페이로드와 혼동되지 않도록 막을 뿐입니다. 그게 전부입니다.

구분할 것이 없는 데도 왜 구분자를 먼저 보내는가?

RFC 1055에서 가장 기억에 남는 부분은 통상적인 뒤따르는 END가 아닙니다. Phil Karn이 제안한 수정은 패킷을 END로 끝내는 동시에 END로 시작하는 것이었습니다. 문서는 실용적인 이유를 듭니다. 선행 END는 회선 잡음으로 인해 수신자 쪽에 쌓였을 수 있는 잘못된 바이트를 플러시한다는 것입니다.

처음에는 중복으로 보일 수 있습니다. 이전 프레임이 END로 끝나고 다음 프레임이 END로 시작한다면, 정상적인 수신자는 구분자를 연달아 두 개 보게 됩니다. RFC 1055는 이 비용을 감수합니다. 정상적인 경우 인접한 값들은 길이 0 또는 잘못된 IP 패킷을 만들고, 문서는 IP 구현이 그것을 폐기할 것이라고 적으며, 샘플 수신기는 데이터를 수집하지 않은 상태에서 END를 무시하는 더 간단한 경로를 택합니다. 그러나 잡음이 있는 경우 첫 번째 새 END가 불필요한 축적을 종료시킵니다. 잡음이 만든 바이트들은 다음 데이터그램이 고려되기 전에 폐기됩니다.

그 한 바이트가 뜻하는 것은 "다음 패킷이 참이다"도 "이전 바이트들이 거짓이다"도 아닙니다. 그 뜻은 이렇습니다. 현재 완성되지 않은 수집이 다음 데이터그램으로 주장되는 것의 시작이 되어서는 안 된다는 것입니다. 그것은 파서 경계를 다시 세웁니다. 비용은 깨끗한 경우에 버리기로 의도된 빈 프레임 하나이고, 이득은 잡음 조각이 다음 프레임의 해석을 오염시킬 기회를 잃는다는 것입니다.

이 구분이 중요한 이유는 직렬 스트림이 수신자에게 메시지를 건네주지 않기 때문입니다. 시간순으로 옥텟을 건네줄 뿐입니다. 교란 이후 수신자는 버퍼에 바이트를 갖고 있으면서도 그것들을 다음 IP 데이터그램에 붙일 믿을 만한 근거를 갖지 못할 수 있습니다. 선행 END는 단순하고 관찰 가능한 재설정 지점을 줍니다. 매체를 신뢰할 수 있는 기록 저장소로 바꾸지는 못합니다. 재설정 이전에 도착한 바이트들의 관할권만 제한할 뿐입니다.

RFC 1055의 샘플 코드는 이 한계를 구체적으로 보여줍니다. 데이터 뒤에 END가 도착했을 때만 패킷을 반환합니다. 선행 END 제안이 만드는 중복 END를 소비합니다. ESC 뒤에 두 개의 기대되는 이스케이프값 중 하나가 오면 수신자는 END 또는 ESC를 복원하고, 다른 값이 오면 그 코드는 그것을 프로토콜 위반으로 간주하고 바이트를 저장합니다. 이것은 넓은 검증이 아닙니다. 두 개의 제어 문자를 인식하면서 페이로드 투명성을 지키려는 작은 디코더일 뿐입니다.

경계와 무결성, 그리고 상태는 서로 다른 사실이다

SLIP의 결여는 페이로드가 스스로 과거에 의존할 때 가장 선명해집니다.RFC 1144, 즉 저속 직렬 링크를 위한 Jacobson의 TCP/IP 헤더 압축은 계층을 흐리지 않기 때문에 여기서 유용합니다. 그 블록 다이어그램에서 IP 패킷은 압축기를 거쳐 프레이머로 향합니다. 압축기는 직렬 링크 상의 연결에 대한 헤더 상태를 유지하며, 압축된 패킷은 이전 헤더에 대한 변화를 기술할 수 있습니다.

따라서 프레이밍 질문은 상태 질문이 아닙니다. 수신자는 END를 찾아 프레임에서 바이트열을 올바르게 추출하면서도 그 열이 손상되지 않았다는 증거를 갖지 못할 수 있습니다. 프레임이 온전히 수신되었음에도, 압축 해제기의 이전 상태가 송신자가 가정한 상태와 더 이상 일치하지 않을 수 있습니다. RFC 1144의 오류 논의는 오류 검출이 프레이밍 수준에 속하며, 압축 해제기가 잘못된 패킷을 폐기하고 상태 오류를 전파하지 않기 위한 오류 표시가 필요하다고 말합니다. 초기 SLIP END는 그 표시를 제공하지 않습니다. 제공하도록 설계되지도 않았습니다.

이것은 선행 END에 발명된 권한을 부여하지 않고 그것을 읽는 강력한 방식입니다. 경계는파싱을 어디에서 다시 시작해야 하는가?에 답합니다. 무결성은이 내용들이 온전한가?를 묻습니다. 상태 기반 디코딩은양쪽 끝이 호환되는 기억된 컨텍스트를 사용하는가?를 묻습니다. 쓸모 있는 시스템은 세 가지 중 하나에만 답을 가질 수 있습니다. 셋을 같은 사실로 취급하면, 편리한 구분자가 자신이 관찰할 수 없는 실패의 책임을 지게 됩니다.

RFC 1662와의 대조도 마찬가지로 절제되어 있습니다. 이후 PPP의 HDLC류 프레이밍은 시작 또는 끝을 나타낼 수 있는 플래그, 옥텟 스터핑, FCS, 무효 프레임 처리를 규정합니다. 또한 유휴 시간 이후에 열림 플래그를 저장해 두면 신뢰성과 지연을 맞바꾸게 될 수 있음을 경고합니다. 잡음이 다음 프레임에 덧붙을 수 있으므로, 송신자가 새 열림 플래그를 내보내지 않는 한 그렇습니다. SLIP의 선행 END와의 유사성은 유익한 정보이지 동일성 주장이 아닙니다. 두 문서 모두 표시가 구획과 재동기화를 함께할 수 있음을 인정하며, PPP는 그 작업을 더 넓고 명시적으로 규정된 링크 계약 안에 놓습니다.

SLIP을 사후적으로 결함 있는 PPP로 다시 쓰지 말아야 합니다. 그것은 자신의 한계를 자기 문서 안에서 명명한 얇은 관례였습니다. 선행 END가 가치 있는 이유는 정확히 그것이 인접한 모든 속성을 제공하는 척하지 않고도 작은 공통 규칙이 복구를 개선할 수 있음을 보여주기 때문입니다.

프레이밍 권위는 만료되어야 한다

Lu Heng의 Notes 64와 65는 이 역사를 위한 올바른 편집 규율을 제시합니다. 실행 중인 시스템이 지역적으로 검증할 수 있는 최소의 결정론적 기능을 식별하고, 그것을 상설 권위로 부풀리지 말라는 것입니다. SLIP에서 END는 직렬 프레이밍 문법 안에서만 권위를 가집니다. ESC는 보호된 바이트 형태 중 하나 앞에 올 때만 권위를 가집니다. END가 경계를 확립한 이후에는 그 뒤의 바이트들을 보증할 수 없습니다. 수신자가 바이트를 재구성한 이후에는 프레이밍 메커니즘이 별개의 압축기가 필요로 하는 상태를 보증할 수 없습니다.

그래서 선행 END는 단지 낡은 직렬 트릭 이상입니다. 회복 가능한 범위의 깔끔한 사례입니다. 송신자가 경계 이벤트를 추가하고, 수신자에게 정의된 응답이 있으며, 이벤트는 값싸고 검사 가능하며 의도적으로 제한되어 있습니다. 어떤 위원회나 디코더도 회선 문법이 말하는 것 이상을 그 이벤트에서 추론할 수 없습니다.

운영 검토 질문은 이에 상응하게 단순합니다. 스트림이 교란되었을 때, 재동기화 표시 이전에 어떤 바이트들이 있었는지, 그 뒤에 완전한 프레임이 관찰되었는지, 어떤 무결성 검사가(있다면) 프레임을 수용했는지, 그리고 상태 기반 계층이 있었다면 그것이 별도로 재설정되거나 재동기화되었는지를 기록하십시오. 단지 "재설정 이후 프레임 수신됨"이라고만 쓴 로그는 서로 다른 세 가지 주장을 검증 불가능한 한 문장으로 합친 것입니다.

출처와 증거의 한계

닫힌 출처 집합은RFC 1055,RFC 1144,RFC 1662입니다. 이 집합은 본문에 기술된 바이트 문법, 선행 END의 근거, SLIP의 명시된 결여, RFC 1144의 압축기/프레이머 및 오류-상태 구분, 이후의 PPP 비교를 뒷받침합니다. 그러나 이 집합은 SLIP의 보편적 배포, 어떤 현재 직렬 장치의 동작, 측정된 회선 잡음률, 보안 결과, 또는 모든 SLIP 링크가 헤더 압축을 사용했다는 사실을 입증하지 않습니다.