요약

  • Sagan의 고정(pinned) 트레이스루트 파서에서 최종 제공 홉이 오류가 아닌 RTT를 가졌지만 패킷 발신자가 목적지 주소와 일치하지 않는 경우에도is_success가 참이 될 수 있습니다. 라이브러리는destination_ip_responded를 별도의 검사로 제공하며, 이 구분은 숨겨져 있지 않습니다.
  • 역방향 스캔이 이전 응답 홉을 찾을 수 있기 때문에 마지막 홉이 무응답이더라도last_median_rtt에 값이 남아 있을 수 있습니다. 이 값이 자동으로 대상까지의 지연 측정값은 아닙니다.
  • 기존 업스트림 테스트 21개와 합성 케이스 5개가 네트워크 호출 없이 선택된 정확한 클래스 대상으로 로컬에서 통과했습니다. 이는 파싱 동작을 확립한 것이며, 실제 배포된 장애, 소비자 오용 또는 애플리케이션 가용성 결과에 대한 판단이 아닙니다.

어떤 트레이스가 라우터의 응답으로 끝났다고 가정해 봅시다. 왕복 시간은 10밀리초입니다. 그러나 그 주소는 목적지가 아닙니다. Sagan의 결과 객체를 검사하는 프로그램은 그럼에도is_success가 참으로 설정된 것을 발견할 수 있습니다.

이것은 고객 인시던트에 대한 설명이 아니라 작은 합성 검사의 결과입니다. 이것이 드러내는 것은 매우 정밀한 판독 문제입니다. 이 파서에서 '성공' 조건은 목적지로부터의 응답 조건과 동일하지 않습니다. 후자의 답을 원하는 사용자는 읽어야 할 다른 속성이 있습니다.

Sagan은 RIPE NCC의 RIPE Atlas 측정 결과 파싱 라이브러리입니다. 그 명시된 목적은 실용적이고 소박합니다. 변화하는 형식과 그 곤란한 케이스를 처리하여 사용자가 동일한 JSON 해석을 반복하지 않고 Python 객체로 작업할 수 있게 하는 것입니다. 여기서 고려하는 소스는 2026-06-03에 커밋된45d01f754896ad648e5b306c4209153bab774af9커밋입니다. 이는 소스 경계이며, 설치된 사본의 목록이나 모든 사용자가 현재 내려받는 패키지에 대한 주장이 아닙니다.프로젝트 목적.

최종 홉에서의 세 가지 질문

관련 함수들은 제공된 결과 목록의 최종 홉에 대해 서로 다른 세 가지 질문을 던집니다.

set_destination_ip_responded는 발신지가 결과의 목적지 주소와 일치하는 패킷을 찾습니다.set_last_hop_responded는 참으로 평가되는 RTT를 가진 패킷을 찾습니다.set_is_success는 오류로 표시되지 않은 패킷에서 참으로 평가되는 RTT를 찾습니다. 마지막 함수는 목적지 주소 비교를 추가하지 않습니다.Traceroute 선택자.

이러한 구분은 친숙한 함수 이름보다 더 중요합니다. 대상으로부터의 정상적인 응답은 세 개의 술어를 모두 충족할 수 있습니다. 다른 주소로부터의 비오류 응답은 목적지 술어는 충족하지 않으면서 마지막 홉 및 성공 술어는 충족할 수 있습니다. 코드가 목적지를 옮긴 것은 아닙니다. 코드는 제공된 최종 홉의 또 다른 측면을 분류한 것입니다.

반대로, 목적지 주소에서 온 패킷이 오류로 표시될 수도 있습니다. 10밀리초 응답과 파서의p오류 코드를 사용한 합성 케이스에서, 목적지 응답 플래그와 마지막 홉 응답 플래그는 참이었지만is_success는 거짓이었습니다. 보고된 최종 홉 오류는 “Port unreachable”이었습니다. 기본 파서는 오류 상태를 패킷의 주소 및 수치적 시간 값과 별도로 기록합니다. 따라서 주소 응답과 비오류 분류는 어느 방향으로든 갈라질 수 있습니다.오류 처리.

이를 목적지 근거 제공의 숨겨진 실패로 제시하는 것은 공정하지 않습니다. Sagan은 이미 전용 목적지 플래그를 노출하고 있습니다. 유형 문서는 그 플래그를 마지막 홉 응답 플래그, 성공 플래그, 최종 홉 오류와 함께 나열합니다. 독자들은 더 정확한 답을 위한 구성 요소를 갖고 있습니다. 위험은 애플리케이션이 하나의 편리한 구성 요소를 유지하고 그 이름이 나머지를 대표하도록 조용히 허용할 때 시작됩니다. 이 조사에서 그런 방식을 쓰는 특정 애플리케이션은 확인되지 않았습니다.공개된 속성.

10밀리초라는 숫자에는 여러 출처가 있다

RTT 선택자는 두 번째 구분을 도입합니다. 홉은 보존된 패킷 RTT로부터 중앙값을 계산합니다. 그런 다음 결과 파서는 참으로 평가되는 홉 중앙값을 찾을 때까지 제공된 홉 목록을 역방향으로 훑으며, 그 값이last_median_rtt가 됩니다. 이 숫자를 찾는 데 목적지 주소와의 일치는 필요하지 않습니다.

두 번째 합성 트레이스에는 세 개의 홉이 있었습니다. 앞선 라우터가 5밀리초에 응답했고, 다음이 10밀리초에 응답했으며, 최종 홉에는 타임아웃 표시만 있었습니다. Sagan은 목적지 응답, 마지막 홉 응답, 성공 모두에 대해 거짓을 반환했습니다. 그럼에도last_median_rtt로 10밀리초를 반환했습니다.

이 네 가지 출력에 모순은 없습니다. 숫자는 선택된 응답 홉을 기술하고, 플래그는 제공된 최종 홉의 조건을 기술합니다. 모순은 어떤 보고서가 그 숫자를 “대상 지연 시간”이라고 부르거나, 지연 값의 존재 자체를 대상이 응답했다는 증거로 해석할 때만 발생합니다.

동일한 10밀리초 값은 정상적인 대상 응답, 비대상 라우터 응답, 대상 오류 응답이라는 세 합성 케이스 모두에서 나타났습니다. 동일한 크기가 관찰을 동등하게 만들지는 않았습니다. 그 중앙값을 취한다 해도 각각의 엔드포인트 의미가 수렴하지 않습니다. 숫자를 결합하기 전에 독자는 어떤 패킷과 어떤 조건이 그 계산의 대상이 되었는지 알아야 합니다.

역방향 스캔은 제공된 목록에 대한 규칙이지 실제 포워딩 경로의 독립적 재구성이 아닙니다. 이 검사는 통상적인 순서의 목록을 사용했습니다. 임의의 비정형, 재정렬 또는 비정상적인 결과가 항상 물리적으로 가장 먼 라우터를 식별한다는 것은 입증하지 않습니다. 값은 “마지막”이라는 단어에서 확신을 빌리기보다 자신의 선택 맥락을 유지해야 합니다.

빠른 판독이 모든 객체를 유지할 필요는 없다

Sagan은 모든 파싱된 홉이 필요 없는 사용자를 위해parse_all_hops=False를 제공합니다. 문서는 이 옵션이 결과의hops목록에 최종 Hop 객체만 남길 수 있다고 설명합니다. 불필요한 객체 생성을 피하는 합리적인 방법입니다.

세 홉 합성 트레이스에서 최소 파싱은 무응답 최종 홉인 세 번째 홉 인덱스를 유지했습니다. 파생된last_median_rtt는 그래도 10밀리초였으며, 이는 이전 응답 홉을 검사하면서 찾은 값이었습니다. 전체 원본 입력은raw_data에 그대로 남아 있었습니다. 이것은 측정 원본의 삭제가 아니라 원본 입력, 편의를 위해 유지된 객체, 파생 속성 사이의 구분입니다.

그 결과hops와 파생 숫자만 내보내는 소비자는 그 숫자를 제공한 파싱된 객체를 누락할 수 있습니다. 나중에 그 선택을 설명하려는 사람은 원본 입력을 유지하거나 선택된 홉 맥락을 명시적으로 기록해야 합니다. 이 선택은 실용적이지 신비로운 것이 아닙니다. 객체 생성을 줄이는 것이 수신자가 검사할 수 있는 내용의 문서화되지 않은 변경이 되어서는 안 됩니다.

로컬 검사이지 사용자 조사가 아니다

기존 업스트림 트레이스루트 테스트는 캡처된 정확한 base, 호환성 및 traceroute 소스를 로컬 모듈로 로드하여 실행했습니다. 21개 모두 통과했습니다. 이어서 다섯 개의 발명된 케이스가 비대상 최종 응답, 정상 대상 응답, 이전 RTT가 있는 말단 무응답, 대상 오류 응답, 그리고 최소 파싱 아래의 동일한 무응답 트레이스를 검증했습니다. 다섯 개 모두 선언된 기대를 충족했습니다. 네트워크 작업은 금지되었으며, 어떤 네트워크 작업도 발생하지 않았습니다.기존 회귀 테스트.

이것은 속성 이름에서 얻은 인상보다 강력하고 운영상의 발견보다는 좁습니다. 이것은 선택된 클래스와 예제를 검사합니다. 모든 릴리스 패키지, 모든 생산자 형식 또는 컨트롤러 수용 규칙과의 동등성을 증명하지 않습니다. 이러한 말단 상태가 얼마나 자주 발생하는지, 사용자가 라벨을 잘못 붙이는지, 특정 서비스가 실패했는지도 측정하지 않습니다. 업스트림 테스트는 여러 응답 구분에 이미 명시적인 주의가 기울어지고 있음을 보여줍니다. 이 근거가 라이브러리를 무성의하다고 부를 면허는 아닙니다.

주소와 패킷에는 각자의 역할이 필요하다

목적지 주소 일치조차 술어이지 증명서가 아닙니다. 파서는 결과 안에서 문자열을 비교합니다. 패킷 발신자를 인증하거나 애플리케이션 트랜잭션을 검사하지 않습니다.

일반적인 Atlas 결과 문서는 주소 역할을 평탄화하지 말라는 또 다른 일깨움을 줍니다. 측정 백엔드가 추가하는 최상위from을 프로브 기반src와 구분합니다. 이 필드들은 정당하게 서로 다를 수 있습니다. 트레이스루트 파서에서 중첩된 패킷의from은 그 패킷의 발신지로 사용됩니다. 최상위 주소, 중첩된 응답 주소, 목적지 주소는 서로 다른 질문에 답하며, 익숙한 철자가 그들을 호환 가능하게 만들지는 않습니다.공식 주소 구분 문서.

ICMP 역시 목적지 서비스 이상에 대해 이야기합니다. RFC 792는 TTL 만료와 연관된 Time Exceeded 메시지와 게이트웨이가 발신원에게 통지할 수 있는 상황을 기술합니다. 응답하는 포워딩 장치는 대상 애플리케이션에서 트랜잭션을 완료하지 않고도 운영자에게 가치 있는 정보를 줄 수 있습니다. 마찬가지로 침묵이 포워딩 경로가 고장임을 식별할 필요는 없습니다. 응답과 그 처리는 측정의 추가적인 부분입니다.ICMP 사양.

이 방법론적 경계는 이 라이브러리보다 오래되었습니다. RFC 2330은 단일 관찰, 관찰로 조립된 표본, 표본에서 파생된 통계를 구분합니다. Type-P 규약은 측정된 트래픽 유형을 명시합니다. 홉 RTT, 결과 수준 술어, 시간에 걸친 서비스 가용성 추정은 하나의 보고서에 나란히 표시될 수 있다고 해서 동일한 지표가 아닙니다.성능 지표 프레임워크.

Sagan의 기존 플래그는 유용한 출발점을 제공합니다. 숫자는 응답 홉 맥락과 함께 유지하고, 말단 술어는 그 옆에 두고, 더 큰 주장을 뒷받침하는 추가 엔드포인트 또는 애플리케이션 검사가 무엇인지 밝히십시오. 라이브러리는 근거를 더 읽기 쉽게 만듭니다. 그 선택된 근거가 답할 수 있는 것보다 더 많은 결정을 내리라고 요구해서는 안 됩니다.

출처