요약

  • RFC 2013은 UDP 구현 전체를 위한 네 개의 읽기 전용 Counter32 값을 정의했습니다: UDP 사용자에게 전달된 데이터그램, 목적지 포트에 애플리케이션이 존재하지 않는 데이터그램, 기타 입력 전달 오류, 그리고 해당 주체가 송신한 데이터그램입니다.
  • 이 문서의udpTable은 로컬 IPv4 주소와 로컬 포트만으로 현재 리스너를 기술했습니다. 한 행은 수신 좌표를 보여줄 뿐, 원격 피어, 운영체제 프로세스, 재사용 가능한 소켓 인스턴스 또는 개별 데이터그램을 식별하지 않았습니다.
  • RFC 4113은 이후 로컬 및 원격 주소 유형, 주소와 포트, 인스턴스 구분자, 프로세스 식별자를 추가했습니다. 이로써 엔드포인트 신원은 더 명시적이 되었지만, 애플리케이션 처리, 응답 전달 또는 서비스 결과를 입증하지는 못했습니다.

네 개의 총계는 네 개의 이력이 아니었다

RFC 2013의 간결함은 주목할 만합니다. 리스너 테이블이 시작되기 전까지 이 문서의 UDP 그룹은 단 네 개의 스칼라 카운터만 담고 있었습니다.udpInDatagrams는 UDP 사용자에게 전달된 데이터그램을 셌습니다.udpNoPorts는 목적지 포트에 애플리케이션이 존재하지 않아 수신된 데이터그램을 셌습니다.udpInErrors는 다른 이유로 전달될 수 없었던 수신 데이터그램을 셌습니다.udpOutDatagrams는 관리 대상 주체가 송신한 데이터그램을 셌습니다.

각 정의는 유용한 분모를 제공합니다. 이들을 함께 두면 UDP 사용자 경계에 도달한 트래픽과 빈 포트 또는 다른 입력 실패에 부딪힌 트래픽을 구분할 수 있고, 송신 활동을 동일한 주체 전체 패널에 배치할 수 있습니다. 그러나 이것은 데이터그램의 장부가 아닙니다. 카운터에는 행 키가 없고, 로컬 또는 원격 엔드포인트도, 타임스탬프도, 프로세스도, 메시지 식별자도 없으며, 하나의 입력과 하나의 출력 사이의 관계도 없습니다.

Counter32 유형은 이 경계를 더 선명하게 만듭니다. RFC 1902는 2^32−1까지 증가하다가 되감기는 값을 명세했습니다. 또한 카운터에는 정의된 초기값이 없고, 단일 값은 일반적으로 정보 내용을 갖지 않는다는 점을 경고했습니다. 재초기화는 불연속을 만들 수 있습니다. 따라서 유용한 관측에는 최소한 두 번의 읽기와 연속성 맥락이 필요합니다. 그 경우에도 델타는 명시된 총계가 해당 구간 동안 변했다는 사실만 말합니다. 그 증분을 특정 리스너, 피어, 프로세스 또는 애플리케이션 결과에 귀속시키지는 않습니다.

테이블은 상대방 필드가 없는 주소록이었다

udpTable은 총계에서 현재의 로컬 구조로 이동했습니다. 이 테이블에는 로컬 애플리케이션이 데이터그램을 수신 대기 중인 엔드포인트가 담겼습니다. 각 행은udpLocalAddress와udpLocalPort로 인덱싱되었습니다. 임의의 로컬 인터페이스에 바인딩된 리스너는0.0.0.0으로 표시되었고, 포트 범위는 0에서 65535까지였습니다.

이 정도면 구체적인 질문은 가능합니다. 에이전트가 샘플링된 시점에 어떤 로컬 IPv4 좌표가 리스너로 표현되고 있었는가. 그러나 대화를 재구성하기에는 부족합니다. 인덱스에는 원격 주소와 원격 포트가 없습니다. 프로세스 식별자도 없습니다. 동일한 튜플을 공유하는 여러 소켓을 구분할 수 없습니다. 행별 패킷 카운터도 이벤트 시각도 제공하지 않습니다.

“리스너”라는 단어는 관측자가 애플리케이션 서사를 추론하도록 유혹할 수 있습니다. 행이 말하는 것은 해당 좌표에서 로컬 애플리케이션이 현재 데이터그램을 수신 대기 중이라는 사실입니다. 어떤 애플리케이션 인스턴스가 그 좌표를 소유하는지, 어떤 원격 시스템이 특정 데이터그램을 보냈는지, 프로세스가 바이트를 읽었는지, 파싱이 성공했는지, 요청이 승인되었는지, 응답이 생성되었는지, 사용자가 서비스를 받았는지는 말하지 않습니다. 문이 열려 있다고 손님 명부가 함께 제공되는 것은 아닙니다.

“UDP 사용자에게 전달됨”은 실제 경계에서 멈췄다

가장 쉽게 과대해석되는 카운터는udpInDatagrams입니다. 그 표현은 “인터페이스에 도착했다”보다 강합니다. 데이터그램이 UDP 사용자에게 전달된 것입니다. 이는 구현의 UDP 계층에 대한 의미 있는 증거이며, 단순한 패킷 존재로 약화되어서는 안 됩니다. 그러나 애플리케이션 효과의 증명으로 확대되어서도 안 됩니다.

UDP 사용자에게의 전달은 애플리케이션 코드가 버퍼를 소비했는지, 페이로드를 수용했는지, 요청된 작업을 수행했는지, 결과를 확정했는지를 기록하지 않습니다.udpNoPorts는 셈해진 데이터그램에 대해 목적지 포트에 애플리케이션이 존재하지 않았음을 알려 줄 뿐, 원격 송신자를 밝히거나 폐기된 데이터그램을 보존하지는 않습니다.udpInErrors는 의도적으로 그 밖의 모든 미전달 사유를 하나의 총계로 묶습니다.udpOutDatagrams는 주체 측 송신 수를 확립할 뿐, 원격 호스트, 원격 소켓, 애플리케이션 또는 고객 결과에의 도착을 의미하지 않습니다.

따라서 이 관리 항목들은 서로 다른 네 가지 UDP 계층 처분과 일련의 로컬 수신 대기 좌표를 기술합니다. 이를 요청-응답 서사로 결합하려면 MIB가 담고 있지 않은 증거가 필요합니다.

RFC 4113은 엔드포인트 신원을 명시적 설계 문제로 만들었다

2005년 RFC 4113이 RFC 2013을 대체하면서 네 개의 기본 카운터는 유지되었지만 테이블은 다시 그려졌습니다. 이 문서는udpTable을 폐기(deprecate)한 두 가지 독립적 이유를 제시했습니다. 테이블이 IPv4 전용이었고, “연결된(connected)” UDP 엔드포인트를 기술할 수 없었다는 점입니다. 첫 번째 문제는 주소 패밀리 가시성의 역사에 속합니다. 두 번째가 바로 이 글에서 다루는 신원의 공백을 드러냅니다.

후속 문서의udpEndpointTable은 와일드카드 리스너와 특정 원격 시스템으로 제한된 엔드포인트를 모두 표현할 수 있었습니다. 인덱스에는 로컬 주소 유형·주소·포트, 원격 주소 유형·주소·포트, 그리고udpEndpointInstance가 포함되었습니다. 인스턴스 값은 동일한 엔드포인트 튜플을 사용하는 여러 프로세스를, 소켓 재사용 사례를 포함하여 구분했습니다. 추가로udpEndpointProcess값은 운영체제 프로세스를 식별하거나, 없을 경우 0을 사용하며, 호스트 자원 MIB 또는 애플리케이션 MIB 행과의 상관을 기대할 수 있었습니다.

이것은 UDP를 신뢰성 있는 세션 프로토콜로 바꾼 것이 아니라, 더 나은 관리용 신원이었습니다. 테이블은 이제 “임의의 원격”과 명시된 원격을, 하나의 튜플 인스턴스와 다른 인스턴스를, 보고된 프로세스와 익명의 엔드포인트를 구분할 수 있었습니다. 운영자는 누가 로컬 표면을 소유하는지를 더 정밀하게 물을 수 있게 되었고, 읽을 수 있는 데이터는 더 민감해졌습니다. 실제로 RFC 4113은 엔드포인트 인덱스가 열린 포트를 노출할 수 있다고 경고했습니다.

그럼에도 추가된 필드들은 여전히 애플리케이션 트랜잭션 앞에서 멈춥니다. 프로세스 ID는 0일 수도, 재사용되었을 수도, 하나의 시스템 안에서만 의미를 가질 수도 있습니다. 연결된 엔드포인트는 운영상의 제약을 기록할 뿐, 특정 데이터그램의 도착을 증명하지 않습니다. 어떤 인덱스 값도 애플리케이션이 내용을 파싱했는지, 대응하는 응답을 보냈는지, 그 응답이 도착했는지, 서비스 결과가 올바른지를 보여주지 않습니다.

정직한 관리 기록은 이야기보다 얇다

RFC 2013은 자신이 모델링한다고 주장한 적이 없는 증거를 담지 못했다는 이유로 비난받아서는 안 됩니다. 그 미덕은 항목의 간결함에 있습니다. 오류는 관측자가 간결한 관리 기록을 완전한 서사로 취급하는 순간 시작됩니다.

방어 가능한 진술은 이렇습니다. 연속성이 호환되는 구간 동안 주체 전체의 no-port 카운터가 증가했고, 에이전트는 샘플링 시점들에서 특정 로컬 포트를 부재 또는 존재로 표현했다. 더 강한 인과 주장은 패킷 또는 이벤트 기록이 엔드포인트 상태와 결합될 때 필요합니다. 애플리케이션 주장에는 프로세스와 애플리케이션 로그가, 전달 주장에는 원격 측 증거가, 서비스 주장에는 서비스 계층에서 정의된 결과가 필요합니다.

역사적 교훈은 단순합니다. 포트는 좌표이고, 카운터는 분모이며, 대화는 귀속된 사건들의 사슬입니다. RFC 4113은 엔드포인트 사슬의 더 많은 부분을 가시화했습니다. 그러나 어느 MIB도 선언만으로 최종 결과를 나타나게 하지 않았습니다.

출처

근거의 한계

위 출처들은 문서 계보, 항목 정의, 카운터 의미론과 후속 스키마를 확립합니다. 그러나 벤더 구현, 배포 보급률, 현재의 기본값, 결함, 실제 사건, SLA, 측정된 트래픽 또는 완결된 애플리케이션 결과를 확립하지는 않습니다.