Hoy veremos de qué puede servirnos un sniffer de tráfico de red como wireshark/tshark o tcpdump para analizar algunos segmentos TCP particulares: los inicios de conexión TCP SYN.

Analizar los mensajes SYN y SYN-ACK en el establecimiento de una conexión (o handshake) es muy útil para estudiar la performance de la red, ya que podemos ver el RTT (Round Trip Time), el tiempo que demora un mensaje de ida y vuelta a un sitio remoto.

Y muchos dirán: ¿Por qué no usar un simple ping para eso?

Y hay una respuesta para eso, por supuesto 🙂

Los mensajes de ICMP, si bien sirven para medir tiempos, especialmente los de echo-request y echo-reply, utilizados por ping, muchas veces puede que:

• Sean bloqueados por firewalls por razones de seguridad.
• Puede que sean falsificados (spoofed) por un router/firewall.
• Puede que sean re-enrutados a otro nodo por no tratarse de tráfico propio del servicio que brinda un determinado servidor.
• Puede que sean tratados con menos prioridad por administradores de redes, ISP, etc., por lo que su medición de performance no será la misma que la del servicio en cuestión.

Y puede que me falte alguna… pero en general, más allá de que usemos o no ping para medir la performance, es importante saber y medir también la performance de los servicios utilizando la misma mensajería que usa el protocolo para brindar dicho servicio.

TCP SYN y el three-way-handshake de una conexión TCP/IP

Supongamos que deseamos medir el tiempo de respuesta de un servidor web. Al tratarse de un servicio HTTP/HTTPS, que corre sobre protocolo TCP, en TCP se producirá un handshake de inicio de conexión con tres mensajes:

1. Syn desde el cliente al servidor: el cliente intenta establecer una conexión.
2. Syn-ack desde el servidor al cliente: el servidor responde con un ack, confirmando que recibió el syn del cliente, y a su vez envía su propio syn.
3. Ack desde el cliente al servidor: el cliente confirma que recibió el syn del servidor, y queda establecida la conexión.

Veamos un ejemplo de estos tres mensajes en una captura de wireshark:

En esta captura puede verse un mensaje seleccionado: un segmento TCP SYN desde el cliente hacia el servidor (paquete 124), la respuesta, SYN-ACK, desde el servidor al cliente (paquete 125) y finalmente la respuesta ACK de confirmación del cliente (paquete 126).

Ahora, vamos a ir a menú View -> Time Display Format, y vamos a seleccionar la opción «Seconds Since Previous Displayed Packet«, como se ve en la siguiente captura:

Esta opción va a cambiar el formato de visión predeterminado de muestra de cada paquete, que es el tiempo desde que inició la captura, por los segundos desde el paquete mostrado con anterioridad.

Veamos qué cambió en nuestra captura:

He marcado en rojo los campos de interés. Ahora se ve que el primer paquete de la conexión, la solicitud de conexión enviada por el cliente, está en tiempo 0.000 segundos, mientras que la respuesta del servidor está en 0.185 segundos, es decir, 185 milisegundos.

Esto nos da una idea del tiempo que demora un mensaje real, de TCP, con protocolo HTTPS en este caso, contactando a un servicio puntual en un servidor remoto.

Y es más, en este caso particular se trata de un servidor que tengo montado en la nube, y al que le he desactivado el tráfico ICMP, por lo que un ping no obtiene respuesta.

Conclusiones

Algunas aplicaciones de medición de performance en redes utilizan esta métrica para medir el rendimiento de una red en términos reales, con tráfico real. Se denomina «TCP Connect» a esta medición de tiempo de RTT con un servidor TCP.

Dependiendo del caso, en wireshark también podemos aislar una conversación completa entre un cliente y servidor, basados en sockets (direcciones IP, puertos y protocolo de transporte) y medir los tiempos de delay entre los diferentes mensajes, para determinar dónde está el cuello de botella en una conexión de bajo rendimiento.

Espero les sea de utilidad! Este contenido será grabado para YouTube y, por supuesto, formará parte también del curso de Wireshark completo que estamos preparando 🙂

Hasta la próxima!