ICMP vs. TCP vs. UDP: diferencias explicadas para desarrolladores

En resumen

ICMP, TCP y UDP viajan todos dentro de paquetes IP, pero hacen preguntas distintas. El eco ICMP (ping) pregunta «¿responde algo en esta dirección?» y no necesita ningún puerto. TCP pregunta «¿hay un programa escuchando en este puerto?» y recibe un sí claro, un no claro o silencio. UDP no pregunta nada por sí mismo: solo se entera de algo si el programa del otro lado decide responder. Un puerto cerrado responde de forma distinta en cada uno, y esa diferencia es casi todo lo que una comprobación de red puede y no puede decirle.

Una dirección, tres formas de llamar a la puerta

Todo paquete que circula por internet es un paquete IP. IP sabe llevar un paquete de una dirección a otra y nada más. Un byte de la cabecera IP indica qué lleva dentro, y la IANA mantiene la lista: ICMP es el protocolo 1, TCP el 6 y UDP el 17. Los tres son hermanos: las mismas direcciones, los mismos routers y una promesa distinta sobre lo que pasa cuando el paquete llega.

ICMP: la red hablando de sí misma

ICMP no es un protocolo de transporte. El RFC 792 lo dice sin rodeos: ICMP «es en realidad parte integral de IP, y todo módulo IP debe implementarlo». Existe para que los routers y los hosts puedan informar sobre la entrega: este destino es inalcanzable, aquel paquete se quedó sin saltos. Los mensajes ICMP tienen un tipo y un código, pero no puertos, porque por encima de ICMP no hay nada esperándolos. Los consume la propia pila IP.

El único mensaje ICMP que todo el mundo ha tecleado alguna vez es el eco. ping envía una solicitud de eco (tipo 8, o 128 en ICMPv6) y el kernel del host remoto devuelve una respuesta de eco (tipo 0, o 129). No hacía falta que hubiera ningún programa en marcha. El RFC 1122, el estándar de requisitos para hosts, lo convierte en norma: «Todo host DEBE implementar una función de servidor de eco ICMP que reciba las solicitudes de eco y envíe las respuestas de eco correspondientes».

$ ping -c 1 uptimepage.dev
PING uptimepage.dev (204.168.246.94): 56 data bytes
64 bytes from 204.168.246.94: icmp_seq=0 ttl=50 time=96.069 ms

Una respuesta demuestra dos cosas: que la dirección pertenece a una máquina encendida y que los paquetes pueden ir y volver. Además, le da gratis el tiempo de ida y vuelta.

Eso es todo lo que demuestra un ping. No dice nada sobre si hay en marcha un servidor web, una base de datos o cualquier otra cosa, y un host puede responder a cada ping mientras todos sus servicios están caídos.

Hay dos cosas de ICMP que sorprenden a la gente. La primera es que no recibir respuesta no significa que el host esté caído. Los firewalls descartan ICMP continuamente. En AWS, un grupo de seguridad recién creado lo bloquea, y la documentación lo dice: «Para hacer ping a su instancia, debe añadir una de las siguientes reglas ICMP de entrada». Antes de confiar en el ping para un host, confirme que ese host responde a un ping.

La segunda es que enviar ICMP requiere privilegios. Un socket raw necesita CAP_NET_RAW. Linux tiene una alternativa sin privilegios, el socket de datagramas ICMP, pero la documentación del kernel dice que el valor predeterminado de ping_group_range es «1 0», «es decir, que nadie (ni siquiera root) puede crear sockets de ping». Docker abre ese rango en cada contenedor que tiene su propio espacio de nombres de red, y por eso ping funciona ahí sin que nadie tenga que pensar en ello; un contenedor con --network host, en cambio, hereda la configuración del host. Descubrí los límites de esto tras perder bastante tiempo: el mismo binario de sondeo que hacía ping sin problemas en Docker no podía ni abrir un socket ICMP en una microVM de Firecracker, hasta que le di CAP_NET_RAW.

TCP: una promesa antes del primer byte

TCP es una conexión. Antes de que cualquiera de los dos lados envíe un solo byte de datos, los dos extremos hacen el handshake en tres pasos: SYN, SYN-ACK, ACK. El RFC 9293, que en 2022 sustituyó a la especificación de 1981, lo llama «el procedimiento que se usa para establecer una conexión». Cuesta un viaje de ida y vuelta, y ese viaje paga todas las promesas que TCP hace después: los bytes llegan en orden, los segmentos perdidos se reenvían, el receptor no se satura (control de flujo) y la red tampoco (control de congestión). Para el programa parece un flujo continuo. Usted escribe bytes en un lado y lee los mismos bytes, en el mismo orden, en el otro.

Sobre TCP funcionan HTTP/1.1, HTTP/2, TLS, SSH, PostgreSQL, MySQL, SMTP y casi todo lo que usted despliega.

El handshake también sirve como sonda, porque un SYN recibe una de tres respuestas:

1. SYN-ACK. Hay un programa escuchando. La conexión se establece.
2. RST. No hay nada escuchando. El RFC 9293 dice que, si la conexión no existe, «se envía un reset en respuesta a cualquier segmento entrante, salvo otro reset». Su llamada a connect falla al instante con «connection refused».
3. Nada. Un firewall descartó el SYN, o el host ya no está. El kernel sigue reintentando. En Linux el valor predeterminado de tcp_syn_retries es 6, y la documentación del kernel sitúa el tiempo de espera final de un intento de conexión activo en 131 segundos.

Aquí están los tres casos desde mi portátil. El último tiene un límite de tres segundos; sin él, macOS espera 75 segundos.

$ nc -zv uptimepage.dev 443
Connection to uptimepage.dev port 443 [tcp/https] succeeded!

$ nc -zv 127.0.0.1 9
nc: connectx to 127.0.0.1 port 9 (tcp) failed: Connection refused

$ nc -zv -G 3 uptimepage.dev 8443
nc: connectx to uptimepage.dev port 8443 (tcp) failed: Operation timed out

La documentación de Nmap da a estos estados los nombres que usa todo el mundo: open, closed y filtered (abierto, cerrado y filtrado).

Lo que demuestra un handshake completado: que un proceso aceptó una conexión en ese puerto. No que esté sano. Una base de datos que acepta conexiones y luego rechaza todas las consultas sigue pasando la prueba. Por eso una comprobación TCP es para lo que no tiene superficie HTTP (SSH, SMTP, el puerto de una base de datos) y una comprobación HTTP, para lo que sí la tiene.

UDP: un mensaje, nada más

UDP es el transporte más pequeño que existe. El RFC 768 cabe en tres páginas. Añade a un paquete IP un puerto de origen, un puerto de destino, una longitud y una suma de comprobación, 8 bytes en total, y ahí se queda. El RFC dice: «El protocolo está orientado a transacciones, y no se garantizan ni la entrega ni la protección contra duplicados». No hay handshake, ni acuse de recibo, ni orden, ni retransmisión, y tampoco control de congestión. El RFC 8085 empieza diciendo que UDP «no tiene mecanismos de control de congestión inherentes» y luego dedica más de cincuenta páginas a explicar a quienes diseñan aplicaciones cómo añadir los suyos.

¿Por qué se usa? Por la latencia y el control. Una consulta DNS es un paquete de ida y otro de vuelta, sin handshake. El RFC 1035 limitó a 512 bytes una respuesta DNS por UDP. Más tarde, EDNS(0) (RFC 6891) permitió que un cliente anunciara un búfer mayor, así que hoy la mayoría de las respuestas caben en un datagrama; la que aun así no cabe llega truncada con el bit TC activado, y el cliente vuelve a preguntar por TCP (RFC 7766). NTP, casi todo el tráfico de los juegos y el video en tiempo real usan UDP porque un paquete que llega tarde vale menos que el siguiente, así que esperar una retransmisión no compensa. Y QUIC, el transporte que hay debajo de HTTP/3, está construido por completo sobre UDP. El RFC 9000 afirma que «los paquetes QUIC se transportan en datagramas UDP» y da como motivo «facilitar el despliegue en los sistemas y redes existentes». En la práctica, eso significa que QUIC hace su propio handshake, su recuperación de pérdidas y su control de congestión en la aplicación, y puede cambiarlos sin esperar a que todos los sistemas operativos actualicen su pila TCP.

$ dig @1.1.1.1 uptimepage.dev A +noall +answer +stats
; <<>> DiG 9.10.6 <<>> @1.1.1.1 uptimepage.dev A +noall +answer +stats
; (1 server found)
;; global options: +cmd
uptimepage.dev.		3600	IN	A	204.168.246.94
;; Query time: 125 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Wed Sep 02 11:40:44 EEST 2026
;; MSG SIZE  rcvd: 59

Un datagrama de ida, un datagrama de vuelta con una respuesta de 59 bytes (67 con la cabecera UDP), y ningún handshake antes. Por TCP, la misma consulta cuesta dos viajes de ida y vuelta, uno para el handshake y otro para la consulta, y por eso DNS usa UDP de forma predeterminada.

Ahora, el problema de sondear. Envíe un datagrama UDP a un puerto. ¿Qué vuelve?

Si no hay nada escuchando, la pila IP del host debería responder con un error ICMP. De nuevo el RFC 1122: «Si llega un datagrama dirigido a un puerto UDP para el que no hay ninguna llamada LISTEN pendiente, UDP DEBERÍA enviar un mensaje ICMP de puerto inalcanzable». Así que «cerrado» se puede detectar, y quien lo detecta es ICMP.

Si hay algo escuchando, recibe lo que ese programa decida enviar. Un servidor DNS envía una respuesta. Un receptor de syslog no envía nada, nunca. Así que el silencio significa abierto, o filtrado, o caído, y Nmap tiene un estado para esto, open|filtered. Su documentación lo explica: «Esto ocurre con los tipos de escaneo en los que los puertos abiertos no dan respuesta».

La consecuencia es que no existe una «comprobación de puerto UDP» genérica. Para comprobar un servicio UDP hay que hablar su protocolo: enviar una consulta DNS real y leer la respuesta, enviar una solicitud NTP real y comprobar la marca de tiempo. Por eso las herramientas de monitoreo tienen una comprobación DNS y una comprobación TCP, pero rara vez una comprobación UDP.

La misma puerta cerrada, tres respuestas

Lea la tabla por columnas. TCP es el único en el que «cerrado» y «filtrado» se distinguen por sí solos, UDP se apoya en ICMP para decir «cerrado», e ICMP no ve puertos en absoluto. El silencio es la respuesta ambigua en los tres, y por eso ninguna comprobación debería concluir «caído» a partir de un único sondeo sin respuesta enviado desde un solo lugar. Dos o tres fallos consecutivos, vistos desde más de una red, es el listón honesto. Escribí sobre ello en cómo evitar las falsas alertas de disponibilidad.

Qué significa esto para un monitor

Desarrollo Uptimepage, y sus tipos de comprobación responden a estas mismas preguntas, así que así es como la teoría se convierte en una configuración.

• Ping envía un eco ICMP con una carga útil de 32 bytes, el tamaño que usa ping en Windows (el ping de Unix envía 56, como muestra la transcripción de arriba), para que los dispositivos intermedios de la red vean tráfico de diagnóstico corriente. Prueba la primera dirección IPv4 y la primera IPv6 del host y reparte el tiempo de espera entre ellas. Si no hay respuesta en todo el plazo, cuenta como caída, porque un eco no tiene forma de rechazar. Úselo para routers, gateways y hosts que no exponen ningún servicio.
• TCP hace el handshake y cierra la conexión. Una conexión aceptada es «activo», una rechazada es «caído», y un tiempo de espera agotado se registra como error junto con lo que tardó. Un error cuenta como comprobación fallida para las alertas exactamente igual que una caída, así que un puerto bloqueado por un firewall también abre un incidente cuando se alcanza el umbral de confirmación. Úselo para bases de datos, brokers, SSH y correo, donde «un proceso aceptó la conexión» es lo máximo que se puede afirmar desde fuera.
• DNS envía una consulta real y comprueba el contenido de la respuesta, así que es la comprobación UDP para el único servicio UDP del que depende casi todo el mundo. Puede apuntar a un resolvedor concreto, algo importante cuando quiere la visión de ese servidor y no la de su caché.
• HTTP es un handshake TCP, luego TLS, luego una solicitud, y registra el tiempo de cada fase: DNS, conexión, TLS y tiempo hasta el primer byte. La fase de conexión es el handshake de este artículo, medido dentro de una comprobación más grande.

Elija la comprobación que hace la pregunta que a usted le importa, y recuerde lo que cada una no puede ver. Hay una versión más completa de esa decisión en la referencia de tipos de monitor, y una versión en forma de historia en el misterio del sitio web «caído».

Preguntas frecuentes

¿Es ICMP un protocolo de transporte como TCP y UDP?

No. ICMP es un protocolo de control que forma parte del propio IP, y el RFC 792 dice que todo módulo IP debe implementarlo. No tiene puertos ni transporta datos de aplicación. Sirve para informar sobre la entrega, como un destino inalcanzable o un paquete que se quedó sin saltos, y para el par de eco que usa ping.

¿Por qué ping funciona si mi sitio web está caído?

Porque ping solo demuestra que la pila IP del host responde y que los paquetes pueden ir y volver. La respuesta de eco la envía el kernel, así que no hace falta que esté en marcha ningún servidor web, base de datos ni otro programa. Un host puede responder a cada ping mientras todos sus servicios están caídos.

¿Por qué un puerto TCP cerrado falla al instante, pero uno bloqueado por un firewall se queda esperando?

Un puerto cerrado devuelve un reset de TCP, así que la conexión falla de inmediato con «connection refused». Un firewall que descarta el SYN no devuelve nada, y el kernel sigue reintentando. En Linux el valor predeterminado es de seis reintentos, y la documentación del kernel sitúa el tiempo de espera final en 131 segundos.

¿Puedo comprobar un puerto UDP igual que un puerto TCP?

No, porque un puerto UDP abierto no devuelve nada salvo que el programa que hay detrás decida responder. Un puerto cerrado sí se puede detectar, ya que el host debería contestar con un mensaje ICMP de puerto inalcanzable, pero un puerto abierto y uno filtrado se ven igual: silencio. Para comprobar un servicio UDP hay que hablar su protocolo, por ejemplo, enviar una consulta DNS real.

Si UDP no es fiable, ¿por qué lo usa HTTP/3?

UDP por sí mismo no garantiza la entrega, y QUIC añade su propia garantía por encima. QUIC viaja dentro de datagramas UDP y hace su propio handshake, sus retransmisiones y su control de congestión en la aplicación, lo que le permite evolucionar sin esperar a que todos los sistemas operativos actualicen su pila TCP.

Fuentes

• IETF, RFC 792: Internet Control Message Protocol, septiembre de 1981.
• IETF, RFC 4443: ICMPv6 for the Internet Protocol Version 6, marzo de 2006.
• IETF, RFC 768: User Datagram Protocol, agosto de 1980.
• IETF, RFC 9293: Transmission Control Protocol, agosto de 2022.
• IETF, RFC 1122: Requirements for Internet Hosts, Communication Layers, octubre de 1989. Secciones 3.2.2.6 y 4.1.3.1.
• IETF, RFC 8085: UDP Usage Guidelines, marzo de 2017.
• IETF, RFC 1035: Domain Names, Implementation and Specification, noviembre de 1987. Sección 4.2.1.
• IETF, RFC 6891: Extension Mechanisms for DNS (EDNS(0)), abril de 2013.
• IETF, RFC 7766: DNS Transport over TCP, Implementation Requirements, marzo de 2016.
• IETF, RFC 9000: QUIC, a UDP-Based Multiplexed and Secure Transport, mayo de 2021.
• IANA, Assigned Internet Protocol Numbers.
• Kernel de Linux, documentación de IP sysctl, tcp_syn_retries y ping_group_range.
• Nmap, Port scanning basics, los seis estados de puerto.
• Amazon Web Services, Security group rules for different use cases, reglas para ping/ICMP.