要約

  • RFC 2013 は UDP 実装全体について、UDP 利用者へ渡したデータグラム、宛先ポートにアプリがなかったもの、その他の入力エラー、エンティティから送信したものという四つの読み取り専用 Counter32 を定義した。
  • udpTable の行を識別するのはローカル IPv4 アドレスとローカルポートだけである。遠隔相手、OS プロセス、再利用された socket のインスタンス、個々のデータグラムは含まれない。
  • RFC 4113 はローカル／リモートのアドレス種別・値・ポート、インスタンス、プロセス ID を加えた。endpoint の責任範囲は明確になったが、アプリ処理や応答到達まで証明するものではない。

四つの総数から一件の通信は復元できない

RFC 2013 の UDP グループは小さい。udpInDatagrams は UDP 利用者へ配達されたデータグラム、udpNoPorts は宛先ポートにアプリが存在しなかった受信、udpInErrors はそれ以外の理由で配達できなかった受信、udpOutDatagrams は当該エンティティから送られたデータグラムを数える。

それぞれは UDP 層における有用な分母である。しかし endpoint ごとの値ではない。リモートアドレス、プロセス、時刻、メッセージ ID、入力と出力の対応はない。同じ時間帯に入力と出力が増えても、一つがもう一つへの返信だったとは限らない。

同時代の RFC 1902 は Counter32 が 2^32−1 の後でゼロへ戻ること、規定された初期値を持たないこと、単独の値は一般に情報を持たないことを明記した。再初期化による不連続もある。差分を読むには二つの観測と連続性が必要であり、正しい差分でも対象はエンジン全体のままである。

待受表の住所欄はローカル側で終わる

udpTable は、ローカルアプリケーションが現在データグラムを受け付ける endpoint を列挙した。索引は udpLocalAddress と udpLocalPort。すべてのローカルインターフェースを対象とする待受は 0.0.0.0、ポートは 0 から 65535 で表された。

この行が裏付けるのは、採取時点で管理 agent がそのローカル IPv4 座標を listener として表現していたことだ。リモートのアドレスとポートはない。所有プロセスも、同じ組を共有する複数 socket を区別する値も、行ごとの受信数もない。

「受け付けている」は、特定データグラムの業務処理を意味しない。プログラムが buffer から読み、形式を検証し、権限を確認し、状態を変更したかは分からない。返信を作ったか、相手へ届いたか、利用者が目的を達成したかも分からない。窓口番号は対話記録ではない。

UDP 利用者への配達はアプリ完了より手前にある

udpInDatagrams の文言は単なる interface 到着より強い。「UDP 利用者へ配達」されたのであり、transport 層の実在する境界を示す。これを単なる packet 観測に薄めるべきではない。一方でアプリケーション成功へ膨らませてもならない。

Counter はプログラムがデータを読んだことを記録しない。udpNoPorts は数えたデータグラムに宛先アプリがなかったことを示すが、送信者を保存しない。udpInErrors はその他の不達理由を一つにまとめる。udpOutDatagrams はエンティティからの送信で止まり、遠隔 host やアプリでの受信を保証しない。

したがって一つの対話を主張するには、データグラムまたはイベント ID、endpoint 状態、process lifecycle、アプリの受領、遠隔観測を外部で結ぶ必要がある。

RFC 4113 は endpoint の同一性を作り直した

2005 年の RFC 4113 は RFC 2013 を置き換え、基本四カウンターを残しながら旧 udpTable を deprecated にした。理由は二つある。IPv4 のみであること、そして「connected」UDP endpoint を記述できないことだ。前者をこの記事の主題にはしない。後者こそ、ローカル座標だけでは相手との関係を表せないという問題である。

新しい udpEndpointTable は wildcard の listener と特定 remote を持つ endpoint の双方を表現できる。索引は local／remote の address type、address、port と udpEndpointInstance からなる。instance は SO_REUSEADDR や SO_REUSEPORT のように同じ tuple を使う複数 process を区別する。udpEndpointProcess は OS の process ID、なければ zero を示し、host-resource や application MIB と対応づけられる。

これは UDP を信頼できる session transport に変える仕組みではない。管理上の「どの endpoint、どの processか」を精密にした仕組みだ。PID は欠落・再利用し得る。remote が設定されていることは、その相手と特定データグラムを交換した証拠ではない。アプリの解析、応答、サービス結果は依然として行の外にある。

より細かな可視性は機密性も高める。RFC 4113 は、index から開いている port を知り得ると警告した。read-only の観測であっても、誰に見せるかは統制対象である。

観測した単位のまま結論を書く

RFC 2013 は完全な会話台帳を約束していない。問題は、全体カウンターを特定サービスへ帰属させ、ローカルポートを通信相手とみなし、「sent」を「delivered」へ、UDP 配達を業務完了へ置き換える後世の読み方にある。

堅い表現は範囲を保つ。連続性のある二時点でエンティティ全体のカウンターが増えた。ある時点で agent がローカル listener を示した。特定通信への帰属には packet/event の join、アプリ処理にはアプリの receipt、遠隔配達には遠隔観測、成功には service 層の定義と測定が要る。

ポートは座標、カウンターは分母、対話は帰属されたイベント列である。RFC 4113 は列の前半を豊かにしたが、結末を書き込んではいない。

情報源

証拠の限界

これらの資料は文書の系譜、object 定義、counter semantics、後継 schema を裏付ける。vendor 実装、普及率、現在の default、欠陥、実事故、SLA、測定トラフィック、完了した application outcome は裏付けない。