要約

  • RFC 863のTCP版とUDP版は、9番ポートで受け取ったデータを捨て、アプリケーション応答を一切返さない。TCP接続を終えるのは呼び出し側だった。
  • TCPの接続状態や確認応答はUDPの単発送信より多くを語る。しかしローカル書き込み、遠隔TCPの責任、Discardプロセスの読み取り完了は同じ証拠ではない。
  • UDPで返事がない状態は、正常な破棄、損失、フィルタ、未稼働サービスのすべてと両立する。到着を論じるには受信側の独立観測が要る。

「無」が仕様になった瞬間

送信能力だけを調べたいとき、相手が同じ量を返せば復路の処理が混ざる。Discardは受信後の計算と返信を取り除き、一方向のデータ受け皿を提供した。1983年のRFCは、これをデバッグと計測に有用だと位置づけた。

ただし、応答を消すことは証拠も消すことだった。送信側に見える無応答は、相手が正しく捨てた場合だけに現れるのではない。途中で消えた場合にも、誰も待ち受けていない場合にも同じ画面になる。

仕様が述べるのは条件文である。サーバーが受け取れば、捨てて返さない。送信者が何も受け取らなかったならサーバーが受け取った、という逆向きの命題は書かれていない。

TCPでは呼び出し側が終端を決める

TCP Discardは9番ポートで接続を待った。接続後は届いたデータを捨て、応答を送らず、呼び出しユーザーが接続を終えるまで継続した。サーバー側の完了メッセージも、成功を示す自発的な切断もない。

この役割分担を知らずにサーバーのクローズを待てば、正常な静止を障害と誤認する。送信量と試験終了を決めるのはクライアントである。

TCPはそれでも有用な履歴を残す。接続成立は、遠隔TCPエンドポイントがその時点で接続タプルを受け入れた証拠になる。シーケンス、ACK、再送、RST、タイムアウトは、バイト列がどこまで運ばれたかを別々に示す。

RFC 9293は、受信側TCPが利用者へデータを届ける責任を引き受けると受領を確認すると述べる。このACKは遠隔TCPの責任に関するものだ。Discardプロセスの特定の読み取り、内部カウンター、運用者の同意まで認証しない。

送信側の成功表示はさらに手前かもしれない。同RFCは、遠隔TCPがまだセグメントを確認していなくても、ローカル実装がSENDに直ちに応答し得ることを説明する。writeの戻り値だけでは、ローカルキューを越えたことを証明できない場合がある。

遠隔アプリが正確な量を消費したことまで必要なら、受信側プロセスの計数、制御されたキャプチャ、別チャネルの完了通知を設計する。これは試験装置が追加した証拠であり、RFC 863の暗黙の受領証ではない。

UDPの沈黙には原因名が付いていない

UDP版はさらに簡単で、9番ポートに届いたデータグラムを捨て、何も返さない。接続状態も取引番号もなかった。

RFC 768はUDPについて、配送と重複保護を保証しない。RFC 863はその上に再送や応答を追加しなかった。したがって送信後の空白は、正常受信、経路損失、ポリシーフィルタ、リスナー不在、アプリに届かなかったICMPエラーのどれとも矛盾しない。

RFC 8085もICMPを確実な救済にはしない。中間装置がICMPを除去するため、UDPアプリは正しく安全に動くためにその配送へ依存すべきでない。検証済みのエラーが届けば情報になるが、届かないことは反対の事実を証明しない。

両端を管理できる試験なら、送信数と受信側キャプチャまたはプロセス計数を比較できる。観測位置と締切時刻を定めれば、限定した配送率も求められる。送信端だけなら「応答ゼロ」は応答の統計であって、到着の統計ではない。

応答を引くと、Echoとは別の問題になる

Echoは入力を返し、Character Generatorは新しいデータを返す。Discardはアプリケーションの復路を取り除く。このため、偽装された送信元を介してEchoとChargenの返信が次の要求になる循環は作らない。

一方、沈黙する受け皿も帯域、バッファ、接続状態、CPUを使う。閉じた資料には現在の悪用率や一律の増幅率がないので、そこを推測してはいけない。判断対象は負荷の許可、容量上限、観測可能性である。

応答がないことは費用がないことではない。比較材料がないぶん、誤った宛先や止まったプロセスに負荷を送り続けても、送信側ダッシュボードが進んで見える危険がある。

9番という名前と稼働中の実体

IANAはTCPとUDPの9番にdiscardを登録し、SCTPとDCCPにも別の参照を持つ行を置く。RFC 863が直接定義したのはTCPとUDPである。登録は共通名称を守るが、各アドレスでサービスを起動しない。

RFC 6335は9番をSystem Portsの範囲に置き、割当済み、未割当、予約という状態を区別する。割当済みは番号台帳の状態であり、特定ホストのリスナー、実装の適合、公開利用の許可を証明しない。

この差は無応答プロトコルで特に重要だ。UDPの沈黙をIANA記録で埋めることはできない。TCPで接続できても、ポート番号だけでプロセスを認証できない。番号管理と実行観測は別の権威である。

先に主張を選ぶ

ローカルカーネルがバッファを受けたこと、遠隔TCPがバイト範囲の責任を負ったこと、Discardプロセスが読み捨てたこと、UDPデータグラムが到着した割合は、それぞれ別の計器を必要とする。

報告にはトランスポート、接続タプル、時間、ローカル受入量、遠隔ACK量、再送、エラー、切断開始者、受信側カウンターを残すべきだ。一つの「成功」に圧縮すると、後から証明範囲を復元できない。

逆にアプリ応答が返れば、それはRFC 863 Discardの予想外の挙動である。原文と端点情報を保存し、9番だからという理由だけでサービス名を断定しない。

出典と限界

動作はRFC 863、electiveという歴史的位置はRFC 880による。TCPの境界はRFC 9293、UDPの非保証はRFC 768、現代のUDPとICMPの注意はRFC 8085に基づく。

番号管理はRFC 6335とIANAレジストリで確認した。これらは現在の配備、性能、トラフィック、悪用を測らず、特定の稼働実装も特定しない。