CENTRO UNIVERSITARIO DE CIENCIAS EXACTAS E INGENIERÍAS

DEPARTAMENTO DE CIENCIAS COMPUTACIONALES

Administración de Redes

Semana 2. Reporte de Actividad número 2.

Wireshark y arquitectura de protocolos.

Prof: Ing. Luis Ignacio Sánchez Salazar

Alumno: Alejandro Canales González

Carrera: Ingeniería en Computación

Materia: i5907 Administración de Redes

NRC: 42241

Sección: D04

Calendario: 2023A
 ACTIVIDAD 2
"Wireshark y arquitectura de protocolos”.

Esta semana vimos en la clase del día 1 cómo usar –a grandes rasgos–
Wireshark. El día 2 nos tocó ver una exposición de la arquitectura de protocolos.

Objetivo:
Descargar e instalar Wireshark de su página oficial: https://www.wireshark.org y hacer
una captura no mayor a 60 segundos, durante la cual debemos interactuar con
alguna pagina web. Al terminar la captura, tratar de familiarizarse con las
herramientas que tiene el programa.

Por último, comentar qué me llamó mas la atención o qué descubrí con la
herramienta.

Materiales, herramientas y equipos utilizados:

● Una computadora.
● Navegador web Google Chrome.
● Wireshark.

1.- Wireshark:

Primero, iniciamos la aplicación.

 En la captura de arriba podemos ver la pantalla de bienvenida del programa
Wireshark. De las opciones para captura que reconocí, puedo mencionar el eth0,
que es mi tarjeta de red (Ethernet), aunque esa nomenclatura no se usa más en
Linux, puesto que el paquete de red ifconfig ha sido depreciado por el nuevo
iproute2, donde ahora se le llama a la tarjeta de red como enpXsX, donde las “x”
representan un número, según qué tarjeta de red sea y en qué socket se ejecute.

Por otro lado, el loopback se trata de mi computadora local.

En la captura de pantalla de arriba podemos apreciar que al abrir la página

web de Netflix se confirma que usa el protocolo UDP. Recordemos que UDP –
contrario a TCP-- no se cerciora de que todos los paquetes lleguen a su destino y
por lo tanto no hace reenvíos de paquetes. Esto, que de entrada resulta
contraintuitivo, es bastante útil cuando el arribo de los datos en tiempo real resulta
crítico. En el caso de las transmisiones en vivo, este suele ser el caso, como el los
videos de streaming que hace la plataforma Netflix. Sin embargo, hay que
considerar que la mayoría del contenido de Netflix es pregrabado y cuando faltan
partes de un video (tramas) este no se las salta para continuar con la linealidad
temporal, sino se queda esperando (con el típico símbolo oscilatorio de espera en
internet) hasta recibir lo que sigue del video.
 De manera que no logro entender por qué el uo de UDP y no TCP en su
lugar.

El protocolo UDP, recordemos, es de la capa de transporte del modelo OSI.

La comunicación se realizó por medio de IPv6, tanto en la fuente, mi PC,

como el destino.

Ahora vemos –en la captura de arriba-- cómo la comunicación cambió a

protocolo IPv4, y se ve claramente la puerta de enlace o gateway de mi PC y el
destino, con el cual se está comunicando por medio del protocolo ICMP, cuyo
encargo es verificar que los mensajes estén siendo enviados y recibidos.
Desgraciadamente, no pudo alcanzar su destino y por ende no le fue posible
verificar la correcta entrega de los paquetes.

En la siguiente captura de abajo vemos que han ocurrido algunos envíos de

paquetes bastante interesantes.

Primero, nos hallamos el paquete 19 que fue enviado a través del protocolo
TCP e inmediatamente después, en el paquete de la línea 20, se cambia al
protocolo ARP, en este caso para hacer multidifusión y encontrar un equipo. En
esa misma línea, notamos que se pregunta por una dirección IP, la 192.168.1.3.
 En lo subsecuente vemos en su mayoría paquetes UDP, pues seguimos con
la ventana abierta de Netflix.

Cerca del segundo 60, mi computadora comenzó a comunicarse con el

enrutador (también conocido como encaminador o router (ya sea pronunciado con
acento británico: [rúter], o con acento americano: [ráuter])), solicitando mediante
DNS algunos requerimientos que desconozco.
2.- Arquitectura de protocolos.

En esta segunda parte, maś que extenderme con una investigación donde
se copien y peguen términos técnicos, quiero hacer una disertación donde
podamos entender de una manera más amena pero enriquecedora qué son las
arquitecturas de protocolos y para qué nos sirven.

Para que las arquitecturas de protocolos sean utilizables, estas deben de

estar normalizadas. La Organización Internacional de Normalización o ISO
(International Standardization Organization, por sus siglas en inglés) es la
encargada de la creación del modelo OSI o ISO/OSI, el cual pretende ser una
ampliación o nuevo paradigma para lo que antes se venía haciendo con el modelo
TCP/IP, que es más simplificado.

¿Cuáles son las diferencias entre estos dos modelos? Básicamente, que el
modelo ISO/OSI cuenta con 7 capas, mientras que el modelo TCP/IP tiene solo 5.

Cabe aclarar antes de continuar que TCP/IP es el nombre del modelo y es

de esperarse que dentro de este se manejen los protocolos TCP e IP; sin embargo,
estos protocolos también están presentes dentro del modelo ISO/OSI. No significa,
pues, que el modelo ISO/OSI prescinda de dichos protocolos, simplemente no los
ha usado para intitular su modelo.

Así pues, el modelo TCP/IP tiene 5 capas, a saber:

• Red física
• Vínculo de datos
• Internet
• Transporte
• Aplicación

Mientras que el modelo ISO/OSI cuenta con 7 capas, las cuales son:
• Física
• Enlace de datos
• Red
• Transporte
• Presentación
• Sesión
• Aplicación

“Grosso modo”, las primeras cuatro capas son equivalentes, mientras que
las 3 últimas de ISO/OSI (OSI, en delante) están englobadas dentro de la capa
Aplicación del modelo TCP/IP.

A continuación se incluye una tabla de equivalencias y los respectivos

protocolos que se manejan en cada capa:
 ¿Quién ha ganado la batalla?
En la actualidad, el modelo TCP/IP lleva ventaja sobre el modelo OSI, esto,
no obstante, no significa que la idea de estandarización o normalización de OSI
sea mala ni mucho menos. De hecho, tiene algunos aspectos bastante ventajosos
a considerar:

1. Una mayor cantidad de capas consigue una mejor especificidad que ayuda
a especificaciones más precisas.
2. Todas las capas cuentan con controles que ayudan a verificar la integridad
y seguridad de los datos dentro de la propia capa, pero no fuera de esta. Por
ejemplo, un error en la capa Física no puede ser entendido por ningún
mecanismo de control de la siguiente capa, la de Enlace de datos, pero,
como se dijo, cada una tiene sus propios controles para detectar errores.
3. Las capas solo pueden comunicarse con la capa inmediatamente superior y
la inmediatamente inferior, pero no más allá. Esto mejora el ordenamiento y
la secuencialidad.
4. PDU o Unidad de Datos de Protocolo.

En la división de tareas, los bits (capa Física), las tramas (capa de Enlace de
datos), los paquetes (capa de Transporte), etcétera, cuentan con cabeceras. Estas
cabeceras tienen la función de ordenar y administrar los datos. Así, cuando una
trama es tratada dentro de la capa de Enlace de datos, a esta se le agrega una
cabecera (en este caso, la que incluye la dirección IP). La cabecera, una vez que
haya sido recibida por el destino, será leída por el PDU de dicha capa, el cual le
dará el tratamiento necesario para desempaquetarlo, unirlo o lo que sea menester,
para el adecuado recibimiento de los datos.

Las PDUs son las encargadas de gestionar esto y cada capa tiene una
asignada.

Conclusión personal:
Esta segunda semana resultó informativa. Aunque en un principio resulta
difícil entender todo el entramado y estructura de una arquitectura, poco a poco la
información va permeando en nuestras mentes, les damos significado y sentido y
nos resulta cada vez más claro cómo es que ocurre todo esto dentro del
fascinante mundo de internet.

Como se vio en Wireshark, el manejo de datos por internet es una marea

inmensa difícil de descifrar, pero por lo mismo fascinante y muy aleccionadora.

Comprender en buena medida y poder hacer una gestión adecuada de este

flujo inconmensurable de datos será la consecución más que satisfactoria de esta
materia.

Bibliografía y referencias:
https://www.wireshark.com
https://es.wikipedia.org/wiki/Unidad_de_datos_de_protocolo
https://docs.oracle.com/cd/E19957-01/820-2981/ipov-10