요약

  • 초기의 견고성 원칙은 불완전한 명세를 다루는 문제였다. 신중하게 작성된 형식을 하나 보내되, 의도된 의미가 명확하다면 기술적 결함은 수용하라는 것이었다.
  • 영구적인 관용은 결함이 있는 발신자로부터의 피드백을 차단했다. 일단 작동해버린 편차는 배포된 동작이 되었고, 이후의 구현체들은 그 버그를 복제하거나 상호운용성을 포기해야 했다.
  • 현대의 복구 방식은 회복탄력성은 유지하되, 추측에 의한 의도 해석을 명시적인 오류 조치, 적극적인 유지보수, TLS GREASE와 같은 확장 테스트로 대체한다.

모호성은 출발 조건이었다

이 규칙은 자랑이 아니라 고백 곁에서 처음 등장했다. RFC 760은 명시적인 프로토콜조차 서로 다른 해석을 받을 수 있다고 말했다. 그 실용적 해답은 비대칭적이었다. 잘 구성된 데이터그램을 보내되, 의미가 명확하다면 기술적 오류를 거부하지 말라는 것이었다.

젊은 네트워크에게는 합리적인 역할 분담이었다. 명세와 코드가 함께 발전했고, 구현체들은 서로 다른 작업장에서 나왔으며, 완벽한 문서를 기다리는 동안 유용한 상호운용이 지연될 수 있었다. 대화를 계속 유지할 수 있는 곳은 종종 수신자뿐이었다.

RFC 793은 이 타협을 TCP의 "견고성 원칙(Robustness Principle)"으로 압축했다. 보수적인 행동, 관대한 수용. 이 문장은 원래의 맥락보다 훨씬 멀리 퍼졌다. 불확실성을 넘기 위한 임시 방법이 시대를 초월한 도덕 법칙처럼 들리기 시작한 것이다.

RFC 1122에는 무조건적 관용 이상의 것이 담겨 있었다

호스트 요구사항 문서는 이 원칙을 모든 계층에 적용했지만, 그 예시들은 여러 작업을 구분하고 있었다. 소프트웨어는 드물고 악의적인 입력에서도 생존해야 한다. 열거형은 네 개의 값을 문서화한 뒤에도 다섯 번째 값을 위한 여지를 남겨야 한다. 발신자는 결함이 있는 상대가 오처리할 수 있는 모호하지만 합법적인 동작을 피해야 한다. 오류는 기록되어야 한다.

이러한 의무가 모두 "발신자의 의도를 추측하라"는 뜻은 아니다. 생존은 로컬 시스템을 보호한다. 확장 규칙은 미래의 코드 포인트를 보호한다. 보수적인 출력은 피해를 제한한다. 로깅은 증거를 보존한다. 의미론적 창작은 다른 문제다. 두 관대한 수신자가 동일한 기형 입력에서 서로 다른 의미를 추론할 수 있고, 그 상태가 실제로 중요해질 때까지 양쪽 모두 성공한 것처럼 보일 수 있다.

RFC 1958은 이후 엄격한 발신과 관대한 수신을 아키텍처 원칙으로 재진술했다. 이 격언은 이기종 소프트웨어가 만나도록 도왔다. 동시에 수신자를 다른 쪽의 모호성에 대한 조용한 소유자로 만들기도 했다.

관용된 버그는 고객을 얻었다

수신자가 편차를 조용히 수용하면 발신자는 변경할 이유를 받지 못한다. 다음 릴리스에서도 같은 형식이 나온다. 배포된 트래픽을 거부하는 것은 자신의 실패처럼 보이기 때문에, 다른 수신자들도 같은 예외를 추가한다. 그 예외는 테스트, 문서, 운영에 들어선다.

결국 정확성은 작성된 문법이 아니라 설치된 개체군을 기준으로 측정된다. 새 구현체가 시장에 들어오려면 기형적인 동작을 재현해야 한다. 버그는 더 이상 한 제품 안에 국한되지 않는다. 그것은 모든 피어에 분산된 호환성 의무가 된다.

이것이 "관대하라"라는 말에 가려진 제어의 역전이다. 발신자는 기형 출력을 통제하지만, 수신자가 수리 비용을 부담한다. 사용자는 오늘의 연속성을 보고, 유지보수자는 내일의 선택권을 잃는다.

BGP는 추측을 이름 붙은 결과로 대체했다

BGP 오류 처리는 회복탄력성이 반드시 모호성을 의미하지는 않는다는 것을 보여준다. RFC 7606은 특정 기형 속성에 특정 조치를 할당한다. "Treat-as-withdraw"는 영향받은 경로를 제거하고, 속성 폐기는 의미론이 허용하는 경우에만 사용하며, 일부 실패는 여전히 세션 또는 주소군(address-family) 조치를 요구한다. 진단 기능은 문제가 된 UPDATE를 보존해야 한다.

이것은 경계가 있는 복구다. 수신자는 세션을 평온하게 유지하기 위해 경로의 의미를 발명하지 않는다. 피해를 봉쇄하고, 증거를 보존하고, 트레이드오프를 검토 가능하게 만든다. 연결성은 여전히 잃을 수 있지만, 그 손실에는 정의된 원인과 범위가 있다.

TLS는 미래를 시험하기 시작했다

표준에 쓰인 확장 지점은, 배포된 소프트웨어가 익숙한 값만 보게 되면 실제로는 사라질 수 있다. 관용 없는 코드는 눈에 띄지 않은 채 생존하고, 최초의 실제 확장은 호환성을 깨는 변경처럼 보이게 된다.

RFC 8701은 GREASE로 이에 답했다. TLS 클라이언트는 예약된, 알 수 없어 보이는 값을 보내고, 규격에 부합하는 서버는 계속 작동해야 한다. 미래는 구현체에 추상적으로 관대하라고 요구하는 것으로 보호되지 않는다. 미래 확장이 의존하는 정확한 동작을 지속적으로 시험하는 것으로 보호된다.

RFC 9170은 이 교훈을 일반화했다. 정의만으로는 확장 메커니즘을 보존할 수 없다. 반복적인 적극적 사용은 아직 수정 가능할 때 무관용을 노출한다. 사용되지 않는 유연성은 장식적인 약속으로 굳어버린다.

유지보수는 프로토콜의 일부가 되었다

RFC 9413은 결함이나 공격에 대한 회복탄력성을 버리지 않았다. 그것은 예기치 않거나 모호한 입력을 관용하는 것이 항상 최선이라는 생각에만 이의를 제기했다. 조용한 관용은 프로토콜 부패, 버그 대 버그 호환성, 그리고 기존 구현체는 바꿀 수 없고 새 구현체는 모든 숨겨진 예외를 알아낼 수 없는 생태계를 낳을 수 있다.

그 대안은 적극적 유지보수다. 불일치를 보고하고, 명세를 갱신하고, 일관된 처리를 배포하고, 안전할 때는 가시적인 오류를 사용하고, 임시 우회책을 문서화하며 제거 계획을 세우는 것이다. 때로는 엄격한 피드백이 한 구현체를 배제해야 한다. 그 선택에는 근거, 명세적 지지, 마이그레이션이 필요하다. 우발적인 배제는 시스템을 분열시킬 수 있기 때문이다.

이 문서는 정보성이며, 적용 범위 섹션은 소프트웨어가 갱신될 수 있다고 가정한다. 이 한계는 중요하다. 동결된 기기에는 범위가 한정된 우회책이 필요할 수 있다. 범위와 만료 조건이 우회책이 새로운 법이 되는 것을 막는다.

출처와 근거의 한계

이 일련의 과정은RFC 760,RFC 793,RFC 1122,RFC 1958,RFC 7606,RFC 8701,RFC 9170,RFC 9413에 문서화되어 있다. 이 문서들은 서면 지침과 선정된 메커니즘을 확립할 뿐, 모든 구현체의 균일한 동작을 확립하지는 않는다. 역사적 교훈은 어느 슬로건보다도 좁다. 감쌀 수 있는 피해는 관용하되, 그 비용을 낯선 이들이 물게 될 모호성은 감추지 말라는 것이다.