Resumen

  • En TCP y UDP, RFC 863 ordenaba tirar los datos recibidos en el puerto 9 y no producir respuesta de aplicación. En TCP era el usuario llamante quien terminaba la conexión.
  • Un ACK de TCP puede respaldar una afirmación sobre la responsabilidad del TCP remoto, no certificar que la aplicación Discard ejecutó una lectura o completó una contabilidad.
  • El silencio UDP es compatible con procesamiento correcto, pérdida, filtrado o servicio ausente. Solo una observación independiente permite convertirlo en una medición de entrega.

El experimento termina, la inferencia apenas empieza

Discard parece un blanco ideal para medir envío. El receptor no tiene que reflejar datos ni construir una respuesta. El cliente puede ofrecer un flujo conocido y concentrarse en la ida. Cuando acaba de enviar, la pantalla permanece vacía.

Esa pantalla no contiene un código cero. Contiene ninguna respuesta. La diferencia importa porque el protocolo hizo que éxito y varios fallos fueran indistinguibles en el canal de retorno. Un instrumento que pinte verde debe explicar qué otra señal utilizó.

RFC 863 describió el servicio como herramienta de depuración y medición. Su contrato no era “el silencio confirma la llegada”, sino “si el servicio recibe datos, los desecha y no responde”. La regla describe al servidor; no concede al cliente conocimiento remoto sobre todo paquete del que nunca volvió noticia.

TCP ofrece historia, no un recibo Discard

El servidor TCP escuchaba en el puerto 9. Una vez establecida la conexión, descartaba todo lo recibido y seguía sin responder hasta que el usuario llamante terminara la conexión. No existía cierre de éxito iniciado por el servidor.

Ese reparto evita confundir espera con fallo. Si el cliente ha decidido cuánto enviar, también debe decidir cuándo cerrar. Mantener la sesión abierta en silencio puede ser conducta correcta. El contrato no promete que el servidor marque el final del lote.

TCP sí deja señales de transporte. El establecimiento muestra que un extremo TCP remoto aceptó la conexión en ese momento. Los ACK, retransmisiones, RST y temporizadores permiten reconstruir si el flujo avanzó. Pero la autoridad de cada señal termina en su capa.

RFC 9293 dice que el TCP receptor reconoce los datos cuando asume la responsabilidad de entregarlos a su usuario. Es una promesa del extremo TCP, no del proceso Discard. No demuestra que un read concreto terminara, que un contador de aplicación aumentara ni que el operador autorizara la prueba.

El retorno de la API local puede ser todavía más estrecho. RFC 9293 contempla interfaces donde SEND devuelve confirmación local antes de que el extremo remoto haya reconocido el segmento. Un write exitoso puede probar solo que la pila local aceptó el búfer. La evolución posterior de la conexión decide si hay evidencia más fuerte.

Para afirmar que la aplicación remota consumió una cantidad exacta hace falta otro testigo: métrica del proceso, captura controlada junto al receptor o canal auxiliar. Ese dato no completa una respuesta implícita de RFC 863; añade deliberadamente una autoridad que el protocolo no tenía.

Cinco causas caben en el mismo silencio UDP

En UDP, el servidor escuchaba datagramas en el mismo puerto. Al llegar uno, lo eliminaba sin responder. No había sesión, identificador, recibo ni estado compartido.

RFC 768 no garantiza entrega ni protección contra duplicados. Un datagrama enviado puede alcanzar Discard, perderse, ser filtrado o llegar a un host sin servicio. También puede provocar un ICMP que la aplicación nunca vea. Desde el único punto emisor, todos esos caminos pueden acabar en ausencia de respuesta.

RFC 8085 advierte que los intermediarios filtran ICMP y que una aplicación UDP no debe depender de su entrega para operar correctamente y con seguridad. Un error validado puede descartar algunas hipótesis; la falta de error no confirma la restante.

La medición recupera valor cuando controla un segundo punto. Un contador del receptor permite comparar llegadas con envíos. Una captura intermedia dice hasta dónde avanzó el datagrama. Una ventana temporal define cuándo se cierra el recuento. Sin esos elementos, la cifra “cero respuestas” no es una cifra de entrega.

Quitar el retorno también quita capacidad de diagnóstico

La familia de servicios pequeños permite ver la elección. Echo devuelve los mismos octetos. Character Generator produce otros. Discard no devuelve ninguno. Eliminar la respuesta reduce trabajo y tráfico de vuelta; al mismo tiempo elimina el material que el cliente podría comparar.

Por ello esta historia no repite el bucle Echo/Chargen. Aquellos servicios UDP podían encadenar respuestas cuando una fuente era falsificada. Discard no genera una respuesta de aplicación que alimente el siguiente paso. Las fuentes tampoco cuantifican abuso, carga o despliegue actuales, y el artículo no inventa una tasa.

El límite operativo es distinto: un sumidero silencioso aún consume ancho de banda, colas y proceso. La pregunta es quién autorizó la carga, qué capacidad está delimitada y qué evidencia queda para atribuir el uso. “No amplifica con una respuesta” no significa “no cuesta”.

La asignación del puerto no observa el extremo

IANA mantiene discard en el puerto 9 de TCP y UDP. También registra SCTP y DCCP con referencias separadas. RFC 863 regula directamente las dos primeras variantes. El registro hace reconocible el nombre, no pone en marcha un demonio.

RFC 6335 ubica el número entre los puertos de sistema y diferencia estados asignados, libres y reservados. Asignado significa que la autoridad del registro vinculó número y convención. No prueba que una dirección escuche, que su proceso sea Discard, que cumpla la norma ni que terceros tengan permiso para cargarlo.

En UDP, por tanto, el registro no convierte silencio en presencia. En TCP, una conexión aporta evidencia de un extremo, pero el puerto por sí solo no autentica el software. La prueba debe conservar identidad operativa y conducta observada.

Una matriz de afirmaciones, no una luz verde

Antes de ejecutar, conviene escribir la frase que se desea sostener. La aceptación de un búfer local necesita evidencia de API local. La responsabilidad del TCP remoto necesita ACK y estado de conexión. El consumo por la aplicación requiere métrica remota. La entrega UDP exige denominador de envío y observación de llegada.

El informe debe conservar transporte, direcciones, tiempos, bytes, retransmisiones, errores, iniciador del cierre y lugar de captura. Si una respuesta inesperada aparece, se guarda: indica que el extremo no se comportó como RFC 863, no que el número de puerto haya certificado otra identidad.

El pequeño protocolo deja una regla grande. Cuando la aplicación está diseñada para callar, todo veredicto más fuerte debe mostrar quién habló en su lugar.

Fuentes y límites

El comportamiento se define en RFC 863, y la categoría elective histórica en RFC 880. La frontera de TCP se toma de RFC 9293. Las garantías ausentes de UDP proceden de RFC 768, y las precauciones sobre entrega e ICMP de RFC 8085.

La gobernanza del número se apoya en RFC 6335 y el registro de IANA. Ninguna fuente mide uso, rendimiento, exposición o abuso actuales, ni identifica una implementación viva.