Análisis de paquetes de Transporte

UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS

FACULTAD TECNOLOGICA
www.udistrital.edu.co

Análisis TCP y UDP

Brayan Damián Moyano Sánchez 20142373009
e-mail: bdmoyanos@correo.udistrital.edu.co

Resumen— Mediante el analizador de protocolos de red Wireshark, se analiza el contenido de paquetes capturados TCP y UDP, el
cual se da una explicación de sus funciones, como operan estos paquetes, sus diferencias, además se da una explicación desde la teoría
relacionada con estos protocolos que se constatará con la practica realizada.

Palabras Clave— TCP, UDP, Wireshark, Protocolo, Servicios en tiempo real, Organización de paquetes.
Abstract— Using the network protocol analyzer Wireshark, the content of captured TCP and UDP packets is analyzed, which gives an
explanation of its functions, how these packets operate, their differences, also gives an explanation from the theory related to these protocols
that will be verified with the practice carried out.
Keywords TCP, UDP, Wireshark, encapsulation, TCP/IP Protocol, Real-time services, Packet organization.

I. INTRODUCCIÓN
La necesidad de ofrecer servicios de red, implica ajustar, crear y diseñar protocolos que se ajusten a las
necesidades de transmisión de paquetes, tales como en tiempo real o aquellos que requieran todo el contenido digital y
recuperación de paquetes perdidos, un ejemplo de servicios en tiempo real son aquellos como el Streaming, como los
videos en línea o video llamadas, que requieren una tolerancia a fallas aceptable para garantizar su funcionamiento
continuo, en contraparte de este ejemplo se sabé que también se tiene aquella información de contenido digital que
debe estar completo tal como correos electrónico, archivos digitales, y descargas, etc. Es por esto se diseño y creo
protocolos como UDP (Protocolo de Datagramas de Usuario) y TCP (Protocolo de Control de Transmisión), que
sirven a estos propósitos.
Según lo explica CISCO[ CITATION CIS21 \l 3082 ] “La capa de transporte es responsable de establecer
sesión de comunicaciones temporal entre dos aplicaciones y de transmitir datos entre ellas. Para lograrlo TCP/IP
utiliza TCP y UDP”.
Entre las características de estos dos protocolos están:
TCP[ CITATION ccn21 \l 3082 ] : “Es un protocolo orientado a conexión que negocia y establece una conexión
permanente (o sesión) entre los dispositivos de origen y destino, antes de enviar cualquier Trafico. A través del
establecimiento de la sesión, los dispositivos negocian la cantidad de trafico que se puede reenviar en un momento
dado y los datos de comunicación entre los dos se pueden administrar de cerca”.
 Proporciona una entrega confiable que asegura que todos los datos lleguen al destino [ CITATION CIS21 \l
3082 ].
 Utiliza Acuse de recibo (ACK) y otros procesos para asegurar la entrega [ CITATION CIS21 \l 3082 ].
 Mayor demanda sobre la red (sobrecarga en la red) [ CITATION CIS21 \l 3082 ].
 Proporciona la entrega en el mismo orden[ CITATION ccn21 \l 3082 ]
 Control de flujo, lo que proporciona que disminuya la velocidad de carga si se requiere [ CITATION ccn21 \l
3082 ].

1
 Análisis de paquetes de Transporte
UDP[ CITATION ccn21 \l 3082 ]: “es un protocolo de transporte de mejor esfuerzo que ofrece la misma
segmentación y ensamblaje de datos como TCP, pero sin garantizar confiabilidad y control de flujo”.
 Proporciona solo las funciones básicas para la entrega; no proporciona confiabilidad [ CITATION CIS21 \l
3082 ].
 Menor sobrecarga[ CITATION CIS21 \l 3082 ].
 Los datos se reconstruyen en el orden en que se reciben [ CITATION ccn21 \l 3082 ].
 No hay establecimiento de sesión[ CITATION ccn21 \l 3082 ].
 No es un protocolo orientado a conexión[ CITATION Wik19 \l 3082 ].

II. ANALISIS TEORICO PRACTICO TCP

Un segmento TCP agrega 20 bytes (es decir 160 bits) de sobrecarga al encapsularlos datos de la capa de
aplicación. La imagen muestra los campos en un encapsulado TCP [ CITATION ccn21 \l 3082 ].

Ilustración 1 Segmento TCP

En contraste con la ilustración 1, se aprecia puede apreciar la siguiente captura de Wireshark.

Ilustración 2 Captura TCP Wireshark

2
 Análisis de paquetes de Transporte
Puerto origen (Source Port): es un campo de 16 bits utilizado para identificar la aplicación de origen por el
numero de puerto[ CITATION ccn21 \l 3082 ].
Puerto Destino (Destination Port): al igual que el campo anterior también es un campo de 16 bits utilizado, para
identificar, la aplicación de destino por el numero de puerto [ CITATION ccn21 \l 3082 ].
Secuencias de Número (Sequence Number): un campo de 32 bits utilizado para fines de reensamblado de
datos[ CITATION ccn21 \l 3082 ].
Numero de acuse de recibo (Acknowlefgment number): Es un dato de 32 bits utilizado para indicar que los
datos se han recibido y que se espera el siguiente bite [ CITATION ccn21 \l 3082 ].
Longitud de encabezado (Header Leghth): Un campo de 4 bits conocido como “desplazamiento de datos” que
indica la longitud del encabezado del segmento TCP[ CITATION ccn21 \l 3082 ].
Bit de Control (Flag): es un campo de 6 bits utilizado que incluye códigos de bits o banderas, que indican el
propósito y la función del segmento TCP[ CITATION ccn21 \l 3082 ]. las Identificaciones pueden ser:
 URG: El campo de puntero urgente es válido[ CITATION IBM21 \l 3082 ].
 ACK: El campo de reconocimiento es válido[ CITATION IBM21 \l 3082 ].
 PSH: El segmento solicita un PUSH[ CITATION IBM21 \l 3082 ].
 RTS: Restablece la conexión[ CITATION IBM21 \l 3082 ].
 SYN: Sincroniza los números de secuencia[ CITATION IBM21 \l 3082 ].
 FIN: El remitente ha alcanzado el final de la corriente de bytes [ CITATION IBM21 \l 3082 ].
Tamaño de ventana (size window): Un campo de 16 bits utilizado para indicar el número de bytes que se pueden
aceptar a la vez[ CITATION ccn21 \l 3082 ].
Suma de Comprobación (Checksum): Un campo de 16 bits utilizado para la verificación de errores del
encabezado y los datos del segmento[ CITATION ccn21 \l 3082 ].
Urgente (Urgent Pointer): Un campo de 16 bits utilizado para indicar si los datos contenidos son urgentes es
puntero se utiliza para saber donde termina los datos urgentes [ CITATION ccn21 \l 3082 ].
THREE WAY HANDSHAKE
El proceso teórico que se explica en el Wiki de Wireshark es el siguiente [ CITATION Wik11 \l 3082 ];
“asumimos como cliente la computadora que realiza la solicitud al servidor de google. El proceso que utiliza el
servidor es crear un TCB1 y utiliza este mismo para aceptar la solicitud del host. Después de que TCB se crea, el
servidor cambia de estado a “ESCUCHA”.
“El host hace lo mismo, crea un TCB y usa este mismo para enviar la solicitud, estableciendo a "SYN=1" en el
encabezado de la solicitud e inicia un número de secuencia arbitrario, SEQ=x. SYN paccket (lo que significa SYN=1)
no puede tomar ningún contenido de datos, pero consumirá un número de secuencia. Después de la solicitud enviada,
el host entra en estado SYN-SENT[ CITATION Wik11 \l 3082 ]”.

Ilustración 3 Aceptación de conexión SYN

Después de recibir la solicitud del host:

1
TCB[ CITATION Wik11 \l 3082 ]: algo así como PCB, almacena alguna información significativa como, tabla TCP conexión, el puntero para el búfer de
envío y recepción, puntero de cola de retransmisión, el número de secuencia actual y número de confirmación y ext.

3
 Análisis de paquetes de Transporte
1. “Si el servidor acepta esta conexión, enviará una respuesta de confirmación. En la respuesta, tanto los bits
SYN como ACK deben ser '1', y el lado del servidor también inicia un número SEQ =y. El servidor enviará
su número de secuencia dentro del paquete que se utiliza para ser reconocido al paquete SYN del cliente.
Este paquete tampoco puede tomar ningún contenido de datos, pero consume un numero de secuencia. A
si que en este paquete SEQ=y , ACK=x+1. Y el servidor entra en un estado SYN-RCVD. [ CITATION
Wik11 \l 3082 ]”

Ilustración 4 Respuesta Servidor SYN=1 ACK=1

2. “Si el servidor rechaza la conexión, solo responde a un paquete RST para restablecer la conexión,
(teórico)2[ CITATION Wik11 \l 3082 ]”.
“Después de que el host reciba la respuesta del servidor, enviará también un paquete de confirmación con bits
ACK sets en '1' y SEQ=x+1, ACK=y+1”[ CITATION Wik11 \l 3082 ].

Ilustración 5 Conexión totalmente establecida entre cliente y servidor

SEQ y ACK
Una vez establecido la negociación entre cliente y servidor, se explica a continuación el proceso de Secuencia y
Acknowledgement.
Como se vio en Three Way Handshake, se realiza la explicación de las SEQ y ACK desde el principio, con el
mismo ejemplo.

Ilustración 6 Primera SEQ cliente.

2
Teórico, es decir en la practica no ocurrió

4
 Análisis de paquetes de Transporte
Dado que desde el principio esta, solicitando una conexión, la SEQ inicia en 0 y no tiene ACK, también se puede
observar que la solicitud al servidor se hacer al puerto 443 que se usa en la navegación HTTPS a google.com
Siguiente el orden de la captura, el Servidor responde con la misma SEQ y un ACK que espera recibir del cliente .
adicional a esto el cliente responde con un SEQ = 1 y ACK=1 que espera recibir en la siguiente secuencia, y que se
puede observar en la ilustración 7. Hasta este punto ha establecido la conexión como se explico en el punto anterior.

Ilustración 7 SEQ 2 y 3

Una vez establecida la conexión, el servidor enviara los datos con las SEQ y ACK que espera recibir una vez
termine de enviar estos datos como se muestra en la ilustración 8. En ella se puede apreciar que retoma la secuencia
anterior 1 uno y va incrementando su valor pero espera que el cliente ACK= 245

Ilustración 8 SEQ servidor

Ilustración 9 Respuesta y datos que envía el cliente.

En la ilustración 8 el ACK= 245 del servidor se responde con SEQ=245 que se puede apreciar en la fila 1 de la
ilustración 9 y, además, el cliente continúa generando otras secuencias que van incrementando y al igual que el punto
anterior el ACK se mantiene en 4833.

Ilustración 10 Cerrando sesión cliente servidor (FIN)

Finalmente, teneos la finalización FIN, ACK de la sesión entre el servidor y el cliente, en ella podemos ver que
esta sesión es finalizada por el cliente y el servidor realiza la misma operación.

III. ANALISIS TEORICO PRACTICO UDP

5
 Análisis de paquetes de Transporte

IV. BIBLIOGRAFÍA

[1] CISCO, «ie.tec.ac.cr,» [En línea]. Available: http://www.ie.tec.ac.cr/acotoc/CISCO/R&S

%20CCNA1/R&S_CCNA1_ITN_Chapter7_Capa%20de%20transporte.pdf. [Último
acceso: 24 Mayo 2021].
[2] ccnadesdecero, «ccnadesdecero.es,» [En línea]. Available:
https://ccnadesdecero.es/protocolo-tcp-y-udp-comparacion/. [Último acceso: 24 Mayo
2021].
[3] Wikipedia, «Wikipedia Protocolo no orientado a la conexión,» Wikipedia, 22 Octubre 2019.
[En línea]. Available: https://es.wikipedia.org/wiki/Protocolo_no_orientado_a_la_conexión.
[Último acceso: 24 Mayo 2021].
[4] IBM, «IBM.com,» IBM, [En línea]. Available: https://www.ibm.com/docs/es/aix/7.2?
topic=protocols-tcp-header-field-definitions. [Último acceso: 24 Mayo 2021].
[5] Wiki.Wireshark, «Wiki.Wireshark.Org,» Wireshark, 21 Junio 2011. [En línea]. Available:
https://wiki.wireshark.org/TCP_3_way_handshaking. [Último acceso: 24 Mayo 2021].