PROYECTO FINAL FUNDAMENTOS DE REDES

INTEGRANTES
Daniel Alejandro Castillo González – 202214502
Maria Alejandra Angulo Mejía – 202121458
Cristian David González Mallorca - 202210991

Universidad de Los Andes

Bogotá- Colombia
2022-2
Tabla de contenido
RESUMEN...........................................................................................................................................2
1. Introducción y objetivos..............................................................................................................2
2. Prueba de conectividad host y servidor.....................................¡Error! Marcador no definido.
2.1. Configuración del servidor.................................................................................................3
2.2. Asignación de ip publica.....................................................................................................4
2.3. Escaneo de puertos del servidor..........................................................................................5
3. Resultados de transferencia de datos...........................................................................................6
3.1. FTP......................................................................................................................................7
3.1.1. Imagen............................................................................................................................7
3.1.2. Mp4...............................................................................................................................13
3.2. Sockets de flujo.................................................................................................................18
3.2.1. Imagen..........................................................................................................................18
3.2.2. Mp4...............................................................................................................................22
4. CONCLUSIONES.....................................................................................................................27
5. REFERENCIAS........................................................................................................................27
RESUMEN
En este trabajo se hace un estudio profundo del comportamiento protocolo TCP para
establecer cual protocolo es más fiable para enviar archivos, el protocolo FTP o el
protocolo SSH. Para esto se hace uso de una maquina virtual que permita interactuar entre
servidor y cliente desde un mismo computador, esto con el propósito de poder registrar el
comportamiento de los protocolos con ayuda de la herramienta Wireshark. Para probar la
eficiencia de cada protocolo se enviarán dos archivos, una foto y un video idénticos y se
estudiará cual es el comportamiento de estos envíos. Con los datos que se registran en
Wireshark para las 4 situaciones, se hará un análisis de tasa de transmisión, RTT,
Rendimiento y de jitter para estudiar cuanto se demoran los paquetes, cuanta información
se está transmitiendo en el tiempo y cual es latencia entre paquetes. Al hacer los estudios
respectivos se evidencia que el protocolo más fiable es el protocolo FTP debido a que
muestra mayor uniformidad en sus envíos lo que permite un envío más segura y fácil de
diagnosticar en caso de necesitar optimizarlo, no obstante, lo que se desea es velocidad el
protocolo más conveniente es el protocolo SSH.

1. Introducción y objetivos
El curso de fundamentos de redes ha tenido como propósito introducir diferentes conceptos
que permiten entender el funcionamiento de las redes. Dentro de estos conceptos se
incluyen las 5 capas que componen las redes, y los protocolos que se incluyen en cada una
de las capas para que haya un funcionamiento efectivo. Una de las tres capas es la capa de
transporte que es la capa que establece una comunicación adecuado entre distintos sistemas.
En esta capa coexisten dos protocolos principalmente, el protocolo UDP y el protocolo
TCP. Este proyecto tiene como objetivo estudiar el protocolo TCP respecto al envío de
archivos a través del análisis de protocolo FTP y a través de pockets de Python entre
máquinas para demonstrar una comprensión suficiente de los conceptos FTP y SSH. Para
este ejercicio se requería crear una máquina virtual Linux capaz de enviar y recibir paquetes
por FTP y SSH. La máquina actuaría como servidor, recibiría un archivo pesado en forma
de un video MP4 y un archivo ligero en forma de una imagen JPG.

Para hacer un análisis coherente y relevante al funcionamiento de redes es elemental poder

dar un referente teórico a todos los conceptos que serán explorados durante el proyecto
tanto para la conexión de la máquina virtual como del análisis del protocolo en cada una de
las situaciones.

Marco Teórico

Modos de la Máquina Virtual:

Las maquinas virtuales son una herramienta que permite conectar redes físicas y virtuales
con los adaptadores virtuales, que ofrecen la posibilidad que diferentes maquinas virtuales
en una misma máquina física estén conectadas a diferentes redes. Para configurar estas
maquinas virtuales se necesita entender los modos de redes [1]:
 - No conectado: Modo cuando hay una conexión de red faltante, utilizado sobre todo
para probar funcionamiento de máquina, como si se desconectara de manera física.
- NAT: Es el prestablecido por la VM, que permite que un sistema pueda acceder a
los hosts en la LAN (Local Area Network) con ayuda de la NAT (Network Address
Translation). Este modo permite la conexión al internet. La NAT establece una IP
de 10.0.2.15 en una red aislada detrás de un dispositivo virtual NAT.
- Adaptador puente: Utilizado para conectar el adaptador de una red virtual de una
VM a una red física a través de ese adaptador. Es la única comunicación para la red
virtual sin enrutamiento adicional. Es utilizado para generar acceso a una red local
física, en el caso de esta práctica se utiliza un cable Ethernet para generar el acceso
a una red física y poder hacer los análisis pertinentes.
- Red NAT: Utilizado para la configuración de un Router. Se puede utilizar para
comunicar múltiples VM entre si desde diferentes redes. Bajo esta configuración las
VM pueden acceder a otros clientes en la red y física y pueden acceder a otras redes
como el internet. La red NAT utiliza una interfaz física como una interfaz externa,
al igual que en el modo NAT. Este modo también permite establecer una IP publica
y mantenerla estática.

TCP:
Cuando se habla de la efectividad del protocolo TCP es necesario tener claridad en los
siguientes conceptos:
RTT: (round-trip Time) es la duración en milisegundos que se tarda una solicitud de red en
ir de un punto de partida a un destino y regresar. Esta métrica permite determinar la
efectividad de la red local y diagnosticar la velocidad de las conexiones de red [2].
Throughput: El rendimiento hace referencia a cuantas unidades de información puede
procesar un sistema en un periodo de tiempo determinado. Esta medida esta relacionado
con la velocidad con la que se puede completar una carga de trabajo específica y el tiempo
de respuesta (cantidad de tiempo entre una solicitud y la recepción de la respuesta). [3]
Jitter: Variación del tiempo de retraso cuando una señal es transmitida y cuando es
recibida por otra red, que se mide por la variación en el ping. El jitter puede ser causado por
la congestión de red [4].

Objetivos específicos

- Capturar información de los protocolos FTP y sockets

- Analizar el RTT, Throughput y jitter instantáneo de cada uno de los protocolos.
- Calcular la tasa de transferencia de descarga de archivo
- Calcular manualmente el retardo de jitter
- Comparar la eficacia entre FTP y sockets respecto al comportamiento del TCP en
ambos envíos

1.1. Configuración del servidor

Como se mencionó anteriormente se requiere de establecer una maquina virtual para hacer el
envío de archivos y hacer los análisis correspondientes. Para crear la maquina virtual se
descargó como primera medida VirtualBox, después se descargó y se configuró dentro del
mismo VirtualBox un servidor Kali Linux. Este servidor al ser configurado permite
funcionar como la maquina virtual que será manipulada para generar los protocolos.

Figura 1. Maquina Virtual Kali Linux.

1.2. Asignación de IP publica

Al iniciar la maquina virtual, esta tendrá todos los valores que vienen establecidos desde
fábrica, no obstante, porque se desea hacer envíos entre diferentes redes para poder analizar
que sucede en estos momentos, se necesita establecer una IP pública para poder generar
envíos

Figura 2. IP preestablecida
Para establecer la IP pública se tiene en cuenta lo discutido en el marco teórico respecto a
los modos de conexión de la Máquina Virtual (VM). En este caso, las maneras más
efectivas de conectar una IP pública eran a través de una Red NAT o a partir del Adaptador
puente. La red NAT no fue posible de conectar ya que la versión gratuita de VirtualBox no
permite establecer IP públicas por este modo. Por lo tanto, se optó por utilizar el modo de
adaptador puente, asignando como salida el puerto Ethernet. A través de esta configuración,
la IP pública se asigna apenas se elige el modo de adaptador puente ya que toma prestada
una dirección IP de la red a la que está conectada el adaptador Ethernet. En esta ocasión se
le asignó a la maquina virtual la IP 192.168.0.18

Figura 3. Configuración IP Máquina Virtual

1.3. Escaneo de puertos del servidor

Ya con la IP pública establecida se necesita habilitar los puertos del servidor para hacer uso
de los protocolos a ser estudiados, el FTP y el SSH. En un aspecto general, se evidencia que
cada uno de los puertos se establece a partir de códigos sudo en la terminal. Este tipo de
códigos permite al programador actuar como administrador y activar todos los protocolos
de transmisión.
Para utilizar cualquiera de los dos protocolos, lo que se requiere es habilitar el protocolo
desde la terminal. Tomando como ejemplo el protocolo SSH.

Figura 4. Configuración protocolo SSH.

Ya con cada protocolo activado se hace una lectura de los puertos de cada protocolo. En
esta ocasión, por metodología se conservaron los puertos asignados originalmente a cada
protocolo, donde el puerto del protocolo SSH es el puerto 22. Este mismo proceso
mencionado anteriormente se hace tanto para el protocolo SSH y el protocolo FTP.

Figura 5. Escaneo de puertos SSH

En el caso del protocolo FTP, se requiere de ser conscientes de los comandos diferentes que
existen en la máquina por estar simulando un servidor Linux, por lo que este protocolo es
reportado como vsftpd en la terminal para poder interactuar con el protocolo como se
evidencia posteriormente. Tanto la figura 5 como la figura 6 demuestran como se debe ver
el código de los protocolos cuando este ya está corriendo correctamente.

Figura 6. Código en la terminal del protocolo FTP

2. Resultados de transferencia de datos

A partir de la maquina virtual ya configurada se hace un envío de archivos a través de los
dos protocolos como se demuestra a continuación.
2.1. FTP

El protocolo FTP (File transfer protocol) es el protocolo de red utilizado para transmitir
archivos entre dispositivos a través de una red. Este protocolo es el que permite enviar o
recibir archivos a través del internet. En esta ocasión, se requiere analizar el
comportamiento del protocolo TCP, que funciona en simultaneo con el protocolo FTP, al
hacer un análisis de la tasa de transferencia del archivo, del RTT, del rendimiento y del
jitter que se tiene al enviar dos archivos de pesos diferentes, una imagen de 646 KB y un
video de 44 MB.

2.1.1. Imagen

Figura 7. Captura de imagen 650k.jpg filtrada por protocolo FTP

Figura 8. Representación gráfica de captura de imagen 650k.jpg filtrada por protocolo FTP

Con esta información se puede hacer el resto de los cálculos respectivos

Tasa de transferencia

La tasa de transferencia hace referencia a la velocidad en la que viajan los datos. Dentro de
la literatura esta es denominada por la letra “s” y puede ser calculada al dividir el tamaño
del paquete en bits en el tiempo que se demora en enviar el archivo.

Tamaño del archivo: 646 KB → 0.646 MB

No obstante, la tasa de transferencia se mide en Mbps por lo tanto el tamaño del archivo a
procesar es 5.168 Mb. El tiempo para calcular la tasa de transferencia es el último dato de
tiempo otorgado por la figura 7 donde se evidencia que el tiempo es 22.056 segundos.

Tamaño del archivo

s=
Tiempo de transmisión
5.168
s=
22.056
s=0.234 Mbps
Por lo tanto, este archivo tiene una tasa de transferencia de 0.234 Mbps

Fragmentos teóricos y prácticos

Se determina que los fragmentos se obtienen como

Tamaño archivo
Fragmentos=
Velocidad descarga
5.168 Mb
Fragmentos=
105 Mbps
Fragmentos=0.0492

Asumiendo esta velocidad de velocidad de internet usado fue de 100 megabytes por
segundo y teniendo en cuenta los tamaños se divide para saber la cantidad de paquetes que
serían necesarios, si la velocidad de descarga fuera menor a algunos de los paquetes se
derivaría en más de uno lo cual no es en este caso pero concuerda con la toma de datos de
Wireshark sharck donde no parece haberse dividido en diferentes paquetes. Este valor se
respeta de igual manera para el protocolo SSH

RTT

El RTT como se estableció en la introducción es el tiempo en el que el paquete se demora

en llegar al destino y volver. Para obtener este resultado se toman los datos que produce
Wireshark, y se exporta un archivo CSV para luego este procesarlo en Excel. Dentro de
Excel se comparan el valor delta (la diferencia de tiempo entre envíos) y el tiempo general
de la conversación para poder generar la figura 9 que muestra la variación del RTT
alrededor del tiempo.

RTT respecto al tiempo

12

10
RTT (m/s) +/- 0,001

0
0 5 10 15 20 25

Tiempo (s) +/- 0,001

Figura 9. Gráfica RTT protocolo FTP imagen 650k.jpg

La gráfica demuestra un comportamiento esperado de los RTT en medida que se ve una

fluctuación constante en la gráfica. Esto se debe a que el RTT corresponde a cuanto se
demora de ir a hacer todo el recorrido completo. Hay datos en 0 ya que también se incluyen
los paquetes que se encuentran en el origen antes de ser enviados, por lo tanto se ve esa
llegada a 0, un pico, que corresponde a un paquete enviado y que regresa su ACK, y luego
vuelve a 0. Se evidencia que entre el segundo 15 y el 20 hay un aumento en el RTT que
implica demora en la red que se puede atribuir al momento en que la mayoría del archivo se
transportó, por lo que esto causaría congestión en la red aumentando el valor de la RTT. Se
evidencia que cuando se terminan de mandar los paquetes la gráfica se queda en el 0
absoluto, mostrando que ya no tiene que hacer ningún recorrido.

No obstante, también es importante tener en consideración el iRTT (intial Round Trip

Time). Este valor es el RTT de los primeros dos paquetes y que se mantiene constante
durante toda la conversación TCP y permite hacer cálculos en el rendimiento.
Este iRTT puede ser observado en Wireshark.
Figura 10. Información TCP de la conversación FTP de la imagen 650k.jpg

En este caso se evidencia que el iRTT es 0.003164 segundos después de hacer los filtros
respectivos.

Rendimiento

El rendimiento, conocido en inglés como el Throughput es cuantas unidades de

información puede procesar un sistema en un periodo de tiempo determinado Se toma
ventana y iRTT para procesar datos

Rendimiento a través del tiempo

168.000
Rendimiento (Mbps) +/- 0,001

167.000

166.000

165.000

164.000

163.000

162.000

161.000

160.000
0 5 10 15 20 25
Tiempo (s) +/- 0,001

Figura 11. Gráfica Throughput (rendimiento) a través del tiempo protocolo FTP para imagen.

Para la realización de esta gráfica se toma la variable de rendimiento bajo la definición de

Tamaño de la ventana
Rendimiento=
RTT

El tamaño de la ventana se puede obtener de Wireshark donde se informa cual es el tamaño

de la ventana para cada uno de los envíos. No obstante para la RTT se tomó el valor de la
iRTT para mantener una estandarización que muestra cuantos datos se están transportando,
asumiendo que hay constancia en la manera en la que llegan y salen los paquetes. Si no
existe esta estandarización, la gráfica no permite evidenciar con claridad la variación del
rendimiento en el tiempo, debido a los datos que quedan registrados en el 0. Con esa
aclaración se evidencia que el rendimiento disminuye con el paso del tiempo. Aunque no es
una disminución significativa, se puede atribuir a que, con el paso del tiempo, hay más
paquetes que se envían, por lo que esto generará congestión en el flujo lo que disminuirá la
cantidad en la que se puede enviar información. Se ve entre el segundo 10 y 15 la mayor
constancia en el rendimiento que es coherente con los resultados de la figura 9 de la gráfica
RRT ya que es el punto donde más información se transfiere en un momento de tiempo. En
general se evidencia un comportamiento coherente del rendimiento en el transporte de la
imagen en un protocolo FTP.

Jitter

Jitter manual

El jitter hace referencia a la fluctuación de la latencia de paquetes que viajan por la red. Se
mide en milisegundos y tiende a pasar por la congestión en la red, interferencias y cambios
de la ruta. Esta puede ser calculada al tomar el tiempo que se demora en llegar un paquete a
su destino y restarlo al paquete anterior al suyo. Esto permite ver cuando se demoró entre
un envío y el otro. Tomando como referencia los primeros dos paquetes para explicar como
se obtuvo la columna del jitter se toma como referencia la columna “Time since previous
frame in this TCP stream”.

J 1=2.3705−0.01285
J 1=2.35765 ms
J 2=0.001105−2.3705
J=2.369695 ms

Estos datos se ven representados en la columna calculada creada en Excel para calcular el
jitter de cada uno de los momentos

Figura 12. Segmento de columna calculada Jitter protocolo FTP imagen

Al analizar como se calcula el jitter, se compara el tiempo con toda la columna calculada
creada respecto al jitter para analizar como se comporta esta a través del tiempo.
 Jitter a través del tiempo
12.000

10.000

Jitter (ms) +/- 0,001

8.000

6.000

4.000

2.000

0.000
0 5 10 15 20 25

Tiempo (s) +/- 0.001

Figura 13. Gráfica

Jitter a través del tiempo protocolo FTP para imagen.

Esta gráfica del jitter evidencia una constancia en la manera en la que se demora la
información. En primer lugar, se evidencia de una constancia, por lo que, aunque hay una
latencia en el envío de paquetes, se evidencia que es un proceso constante. En esta gráfica
lo que más resalta es el comportamiento del jitter del segundo 7 al 17 donde se ve un
incremento de la latencia de 6 ms comparados con el jitter constante de los segundos 2 al 7.
Esto es coherente con las figuras 9 y 11 donde se evidenció que es en este intervalo de
tiempo donde se hace el mayor envío de paquetes. Por este mayor envío de paquetes se
puede asumir que existe una mayor latencia porque hay mayor flujo lo que congestiona la
red y produce que los paquetes se demoren más en llegar del servidor al cliente. No
obstante, apenas se resuelve el flujo pesado, se ve como el jitter se establece. Sobre todo, se
evidencia un jitter que se comporta constante entre los intervalos, señalando que hay un
comportamiento muy uniforme entre paquetes.

2.1.2. Mp4

Cuando se analiza el comportamiento del envío del video a través de este protocolo se
toman los mismos parámetros explorados en la sección 2.1.1
Figura 14. Captura de imagen 45m.mp4 filtrada por protocolo FTP

Figura 15. Representación gráfica de captura de video 45m.mp4 filtrada por protocolo FTP

Con esta información se puede hacer el resto de los cálculos respectivos como se hace en la
sección 2.1.1

Tasa de transferencia

Se utiliza la misma metodología que se usó en el análisis de la imagen FTP donde se

contempla que el tamaño del video es de 44 MB por lo que cuando se dimensiona en Mb se
establece que el archivo tiene un tamaño de 352 Mb y la figura 14 establece que el tiempo
de transmisión fue de 23.215 segundos
 Tamaño del archivo
s=
Tiempo de transmisión

352
s=
23.215

s=15.162 Mbps

Por lo que se concluye que esta conversación tiene una tasa de transferencia de 15.162
Mbps. Esto es coherente respecto a la imagen ya que al ser un archivo 68.1 veces más
pesado y tardarse aproximadamente lo mismo en transmitir, es congruente que la tasa de
transferencia sea 64.79 veces mayor para el video.

Fragmentos teóricos y prácticos

Se determina que los fragmentos se obtienen como
Tamaño archivo
Fragmentos=
Velocidad
352 Mb
Fragmentos=
105 Mbps
Fragmentos=3.35

Asumiendo esta velocidad de velocidad de internet usado fue de 105 megabits por segundo
según el diagnóstico y teniendo en cuenta los tamaños se divide para saber la cantidad de
paquetes que serían necesarios, si la velocidad de descarga fuera menor a algunos de los
paquetes se derivaría en más de uno lo cual no es en este caso, pero concuerda con la toma
de datos de Wireshark donde no parece haberse dividido en diferentes paquetes. Este valor
también se respeta para el SSH.

RTT

Se utiliza la misma lógica de la sección anterior para realizar los cálculos pertinentes para
realizar las gráficas y hacer el análisis de datos. Como sucede en toda la práctica se toma
los datos de Wireshark y a partir de una exportación a archivo CSV se pasa a Excel para
hacer el procesamiento de datos.
 RTT en términos del tiempo
12.000

10.000

8.000
RTT (ms) +/- 0,001

6.000

4.000

2.000

0.000
0 5 10 15 20 25

Tiempo (s) +/- 0,01

Figura 16. Gráfica RTT protocolo FTP imagen 650k.jpg

Se reconoce que la variación del RTT para el video tiene el mismo comportamiento de
picos que el RTT de video demostrado en la figura 9 ya que se evidencia un incremento en
el RTT cuando hay un recorrido completo del paquete. No obstante, diferente a lo que
sucede en la figura 9 que describe el RTT de la imagen, los RTT del video muestran una
menor variabilidad, donde en vez de mandar constantemente paquetes, se evidencia que
entre el segundo 5 y el 17 se produce el mayor RTT, señalando que hay una demora en que
el paquete llegue al cliente y la confirmación llegue al host. Esto puede ser debido a que
está mandando paquetes de mayor magnitud en un mismo periodo de tiempo. En el caso del
video se necesita de un envío de paquetes constantes para garantizar orden y simultaneidad
en el producto final. Se evidencia de un promedio mayor de RTT ya que son paquetes de
mayor magnitud que tienen que ser enviados, no obstante, muestra una homogeneidad con
el comportamiento de la Figura 9, mostrando precisión en el protocolo FTP.

De la misma manera que en la imagen, se hace un estudio de Wireshark para encontrar el

iRTT que permite facilitar los cálculos del rendimiento y establecer el estándar general.
Figura 17. Información TCP de la conversación FTP del video 45m.mp4

A partir de la figura 17 se evidencia que el iRTT para esta captura de datos es de 0.034938
segundos.

Rendimiento

Al igual que con la imagen se utiliza el iRTT en vez del RTT variable para ver un
comportamiento claro del rendimiento a través del tiempo.

Rendimiento a través del tiempo

16.500

16.400
Rendimiento (Mbps) +/- 0,001

16.300

16.200

16.100

16.000

15.900

15.800

15.700
0 5 10 15 20 25

Tiempo (s) +/- 0,001

Figura 18. Gráfica Throughput (rendimiento) a través del tiempo protocolo FTP para video.

Soportando lo que señala la Figura 16 que el protocolo FTP es un protocolo muy constante,
la figura 18 y la figura 11 muestran comportamientos muy similares entre sí, donde se ve
una disminución en el rendimiento según pasa el tiempo, así sea mínimo. Así mismo se ve
entre el intervalo 5 al 17 un rendimiento constante, que se puede atribuir a la gran cantidad
de paquetes que se moviliza en ese intervalo. Sin embargo, la evidencia más clara entre
ambas gráficas es el valor del rendimiento en sí. La imagen y el video se mandan en un
total de tiempo muy similar, sin embargo, su rendimiento es muy distinto. El video muestra
un rendimiento mucho menor al de la imagen. Esto podemos atribuirlo al tamaño de los
paquetes y la cantidad de información que tiene ser enviada al final.

Jitter
Al igual que en la sección 2.1.1 se calcula inicialmente el jitter manualmente para justificar
donde se producen los valores.

Jitter manual

Bajo el enunciado que el jitter individual se puede obtener del valor absoluto de la resta del
delta del paquete posterior y del paquete al que se le quiere obtener el jitter se ve la
obtención del jitter como
J 1=2.3405−0.1285
J 1=2.358
J 2=0.001105−2.3705
J 2=2.369

Este proceso se hace iterativamente para poder obtener la columna jitter que permite
generar la figura 20

Figura 19. Segmento de columna calculada Jitter protocolo FTP video

A partir de estos resultados se hace una gráfica donde se opone el jitter y el tiempo para ver
la variación que se produce en este envío.
 Jitter
12.000

10.000
Jitter (ms) +/- 0.001

8.000

6.000

4.000

2.000

0.000
0 5 10 15 20 25

Tiempo (s) +/- 0.001

Figura 20. Gráfica Jitter a través del tiempo protocolo FTP para video

Al igual que con las figuras 18 y 16 esta gráfica del video permite ver un comportamiento
uniforme en el protocolo FTP, donde, aunque varía el tamaño del archivo los
comportamientos del TCP son muy constante. Al igual que en la figura 13 se ve un jitter
constante en los intervalos de tiempo que corresponde, que señala a que la latencia en los
envíos de paquetes es simultánea, casi que asegurando que los paquetes lleguen a un ritmo
coherente que no sature la red. Al igual que en la figura 13 se ve que del intervalo de
tiempo 7 al 17 se genera el mayor jitter. Esto se puede justificar en que es el periodo de
tiempo en donde más se envían paquetes y más información es transmitida exitosamente,
por lo que debe existir congestión en la red. No obstante, diferente a la figura 13, el jitter
después del segundo 17 no vuelve al jitter que se produce en el intervalo de tiempo 2-5
segundo, pero es un valor considerablemente más elevado. Esto puede ser justificado en el
tamaño de la información enviada, donde mientras en la foto después del segundo 17 la
mayoría de información ya había sido transferida, en el video después del segundo 17 sigue
existiendo mucha información a ser transmitida.

2.2. Sockets de flujo

En este caso generar sockets de flujo entre equipos no fue posible por los diferentes
impedimentos que se tuvieron con el uso del Python, sin embargo, se optó por utilizar el
protocolo SSH que también permite enviar archivos y con este protocolo hacer el mismo
proceso hecho en la sección 2.1

2.2.1. Imagen
Figura 21. Captura de imagen 650k.jpg filtrada por protocolo SSH

Figura 22. Representación gráfica de captura de imagen 650k.jpg filtrada por protocolo SSH

Tasa de Transferencia
Al ser el mismo archivo de prueba el tamaño del archivo es de 0.646 MB que equivale a
5.168 Mb para poder establecer la tasa de transferencia. Al leer la captura para este
protocolo se puede evidenciar que el tiempo que se tarda es de 13.440 s para transmitir todo
el archivo.

Tamaño del archivo

s=
Tiempo de transmisión
5.168
s=
13.440
s=0.384 Mbps

Por lo tanto, este archivo tiene una tasa de transferencia de 0.3845 Mbps que muestra ser
mucho más rápida que la tasa de transferencia que el protocolo FTP.

RTT

Al igual que con el protocolo FTP se tomaron los datos del Wireshark y se contrapusieron
los Delta y el tiempo total de transferencia de archivo.

RTT a través del tiempo SSH

0.04000
RTT (ms) +/- 0.00001

0.03500
0.03000
0.02500
0.02000
0.01500
0.01000
0.00500
0.00000
7.9 7.92 7.94 7.96 7.98 8 8.02 8.04 8.06 8.08 8.1 8.12

Tiempo (s) +/- 0.01

Figura 23. Gráfica RTT protocolo SSH imagen 650k.jpg

Es a partir de esta gráfica que se puede evidenciar mejor la diferencia entre protocolos. Si
se compara la figura 9 con la nueva figura 23 se evidencia que en la figura 23 el
comportamiento del RTT es mucho menos lineal y constante, con fluctuaciones que no
pueden ser representadas linealmente en su totalidad. Aunque se conserva la llegada al RTT
0 en los paquetes que han sido enviados, se señala una variabilidad, donde a partir de que se
envía el primer paquete hay RTT elevados, que no se repiten en la gráfica. Esto puede
deberse al modo en el que se mandan los paquetes de manera particular. Otra diferencia
significante es que mientras en el FTP el mayor flujo de paquetes es en el intervalo de la
mitad, aquí se evidencia el mayor flujo en el primer intervalo de tiempo.

Al igual que con los otros RTT se puede calcular el iRTT a partir de Wireshark para
facilitar el resto de los cálculos, donde al evaluar correctamente en la herramienta se
evidencia un iRTT de 0.00172739

Rendimiento

Rendimiento a través del tiempo SSH

Rendimiento (Mbps) +/- 0,001

200.000

150.000

100.000

50.000

0.000
7.9 7.92 7.94 7.96 7.98 8 8.02 8.04 8.06 8.08 8.1 8.12
Tiempo (s) +/- 0.001

Figura 24. Gráfica Throughput (rendimiento) a través del tiempo protocolo SSH para imagen

El rendimiento en el SSH también muestra una gran diferencia respecto al protocolo FTP.
Mientras el protocolo FTP tenía un rendimiento que disminuya con el tiempo menos en los
puntos donde el paquete se mantenía estático el protocolo SSH muestra un rendimiento
constante a través del tiempo, pero no es tan consistente como el del FTP. El del FTP
muestra un piso constante, mientras que en el del SSH se evidencia un rendimiento alto,
que es muy variable respecto a los saltos que hace. Sin embargo, esto tiene sentido respecto
al protocolo ya que el SSH expone los paquetes a un ritmo constante para asegurar el envío
y que se haga seguro, por lo que se entiende el porque su rendimiento se mantiene en el
umbral alto.

Jitter
Jitter manual
El jitter se calcula de igual manera que en el caso del FTP donde se toma el delta de cada
una de las transmisiones y se calcula cuanto se demoran entre ellas. Para esto se establece
que
J 1=0.001136−0
J 1=0.001136
J 2=0.02366−0.001136
J 2=0.02252
Figura 25. Segmento de columna calculada Jitter protocolo SSH imagen

Al analizar como se calcula el jitter se toma esta columna y se ve como se comporta

respecto al tiempo.

Jitter
0.04000
Jitter (ms) +/- 0.00001

0.03500
0.03000
0.02500
0.02000
0.01500
0.01000
0.00500
0.00000
7.9 7.92 7.94 7.96 7.98 8 8.02 8.04 8.06 8.08 8.1 8.12

Tiempo (s) +/- 0.001

Figura 26. Gráfica Jitter a través del tiempo protocolo SSH para imagen.

Es al analizar la gráfica del Jitter del SSH con la del FTP es que se evidencia la mayor
diferencia entre protocolos. Mientras el protocolo de FTP era un jitter que se comportaba
constante en su mayoría, la latencia en un SSH es muy inconstante. Siendo coherente con
las figuras 23 y 24 el momento de mayor flujo es el primer intervalo. Esto se evidencia en
la gráfica del Jitter ya que es donde mas se demora en devolverse la información, donde
hay mas distancia entre los paquetes, lo que sugiere una red congestionada.

2.2.2. Mp4
El Mp4 cumple con los mismos requisitos del 2.2.1

Figura 27. Segmento de captura de video 45m.mp4 filtrada por protocolo SSH

Figura 28. Representación gráfica de captura de video 45m.mp4 filtrada por protocolo SSH
Tasa de Transferencia

Al ser el mismo archivo de prueba que en el FTP video se establece que el tamaño del
archivo es de 352 Mb, no obstante, el tiempo al analizarlo en Wireshark es de 0.02164. A
partir de esta información se obtiene que
Tamaño del archivo
s=
Tiempo de transmisión
352
s=
26.163
s=16266.17 Mbps

Por lo que se obtiene que la tasa de transferencia es de 16266.17 Mbps

RTT

RTT en el tiempo
0.18
0.16
0.14
RTT (ms) +/- 0.001

0.12
0.1
0.08
0.06
0.04
0.02
0
5 10 15 20 25 30 35

Tiempo (s) +/- 0.001

Figura 29. Gráfica RTT protocolo SSH 45m.mp4

Esta gráfica es la que mayor muestra diferencia con todas las mostradas anteriormente. Esto
se debe a que, en este protocolo, los archivos pesados causan una alta congestión en la red.
Diferente a todos los archivos de Wireshark que habían sido procesados donde habían de 45
a 60 líneas, el Wireshark que describía el comportamiento del SSH del video era de 2,196
líneas. Esto señala un alto flujo de paquetes y de material para cumplir el mismo cometido
que el FTP. En el caso del RTT esto se manifiesta mostrando que todos los paquetes tienen
un corto RTT, pero como son tantos se causa congestión como se evidencia gráficamente
en la figura 29.
Rendimiento

Rendimiento en el tiempo
60
Rendimiento (Mbps) +/- 0,001

50

40

30

20

10

0
5 10 15 20 25 30 35

Tiempo (s) +/- 0.001

Figura 30. Gráfica Throughput (rendimiento) a través del tiempo protocolo SSH para video

Siendo coherente con lo experimentado de manera empírica, el SSH demoró una cantidad
considerable de tiempo para subir el video. En la gráfica se puede evidenciar como el SSH
no es un protocolo efectivo para el transporte de video, ya que muestra solo un alto
rendimiento en el envío de los primeros paquetes, sin embargo, su rendimiento luego
reduce a no superar un umbral de 10 Mbps hasta que se envía el último paquete. Esto
evidencia un protocolo poco capaz de procesar alta información, que, aunque muestra
constancia, opuesto al comportamiento del rendimiento en el SSH de la imagen, es una
consistencia que no resulta productiva a la hora de mandar documentos.

Jitter
Jitter manual

Al igual que se ha calculado con los jitter de cada uno de los ejemplos dados hasta el
momento, se ejemplifica como se obtiene la columna para generar el análisis.
J 1=0.001118−0
J 1=0.001118
J 2=0.005664−0.001136
J 2=0.004545

Estos valores se ven evidenciados en

Figura 31. Segmento de columna calculada Jitter protocolo SSH video

Al analizar cómo se calcula el jitter se toma esta columna y se ve cómo se comporta

respecto al tiempo.

Jitter
0.09
0.08
0.07
Jitter (ms) +/- 0.0001

0.06
0.05
0.04
0.03
0.02
0.01
0
5 10 15 20 25 30 35

Tiempo (s) +/- 0.001

Figura 32. Gráfica Jitter a través del tiempo protocolo SSH para video.

Finalmente, se evidencia la gráfica jitter, muy distinta a las gráficas constantes que se
habían evidenciado hasta el momento. Parecida a la figura 29 se ve una alta concentración
de paquetes, esto se debe a la manera en la que el protocolo reparte la información. A
diferencia de los demás escenarios, se evidencia en esta ocasión un jitter inconstante, que
revela que hay diferentes latencias para todos los paquetes, impredecible y poco
personalizable. Al mandar el video los paquetes llegaran a diferentes distancias una de la
otra, impidiendo uniformidad que puede ser una de las causas por las que el protocolo no es
efectivo para mandar videos.
A partir de todas esta información y el contraste se evidencia que aunque ambos protocolos
pueden mandar archivos, el protocolo SSH no es el protocolo más óptimo para mandar
videos.

3. CONCLUSIONES
A partir de todo el análisis hecho, y al hacer el estudio del comportamiento del TCP se
puede concluir que ambos protocolos tienen sus beneficios, todo es cuestión de que se
quiera priorizar. Tanto el FTP como el SSH pudieron mandar los archivos de manera
exitosa, no obstante, distribuyen sus recursos de manera diferente. El protocolo FTP es un
protocolo muy constante, donde sin importar el tamaño del archivo va a mostrar un
comportamiento de TCP coherente, donde los valores van a ser más sencillos de intervenir
en caso de ser necesario por esa constancia. Sin embargo, el protocolo SSH es más veloz
para mandar la información, pero con características TCP mucho menos constantes y que
varían con el tiempo de manera extrema, que hace que sea complicado intervenirlos. A
partir de este conocimiento se aclarece el porque el FTP es el protocolo para enviar
archivos pesados como fotos y videos, ya que tanta información puede causar congestión en
la red, y su constancia en el protocolo TCP hace que gestionar cualquier inconveniente sea
más sencillo. No obstante, para archivos que no requieren tanto peso, como puede ser el
texto, son usos ideales de SSH ya que no requieren de tanto monitoreo. Esta práctica
establece que los usos que se les otorga a los protocolos en la cotidianidad se deben al
comportamiento del protocolo TCP en cada uno de ellos.

4. REFERENCIAS
C. Mitchell, “What is File Transfer Protocol (FTP) and what is it used for?,” Investopedia,
21-Sep-2022. [Online]. Available: https://www.investopedia.com/terms/f/ftp-file-
transfer-protocol.asp. [Accessed: 11-Dec-2022].

CloudFlare, “What is round-trip time? | RTT definition | cloudflare,” What is round-trip

time? | RTT definition, 2021. [Online]. Available:
https://www.cloudflare.com/learning/cdn/glossary/round-trip-time-rtt/. [Accessed:
11-Dec-2022].

J. Anuskiewicz, “Measuring jitter accurately | lightwave,” Measuring jitter accurately,

2008. [Online]. Available:
https://www.lightwaveonline.com/home/article/16663492/measuring-jitter-
accurately. [Accessed: 12-Dec-2022].

M. Bose, “VirtualBox network settings: All you need to know,” Official NAKIVO Blog, 01-
Jul-2022. [Online]. Available: https://www.nakivo.com/blog/virtualbox-network-
setting-guide/#:~:text=VirtualBox%20has%20a%20built%2Din,default%20gateway
%20for%20a%20VM. [Accessed: 11-Dec-2022].
M. Wilson, “Network jitter - what is it and how to monitor it with software/tools [ free ],”
PC & Network Downloads - PCWDLD.com, 12-Jan-2022. [Online]. Available:
https://www.pcwdld.com/network-jitter. [Accessed: 11-Dec-2022].

Packt, “Mastering the Advanced Features of Wireshark,” Packt subscription, 2016.

[Online]. Available: https://subscription.packtpub.com/book/networking-and-
servers/9781783989522/3/ch03lvl2sec28/tcp-stream-graphs. [Accessed: 11-Dec-
2022].

PerfMatrix, “Throughput graph - how to read throughput graph in performance testing,”

PerfMatrix, 06-Sep-2019. [Online]. Available:
https://www.perfmatrix.com/throughput-graph/. [Accessed: 12-Dec-2022].

W. Deland-Han, “Description of windows TCP features - windows server,” Windows

Server | Microsoft Learn, 2022. [Online]. Available: https://learn.microsoft.com/en-
us/troubleshoot/windows-server/networking/description-tcp-features. [Accessed: 11-
Dec-2022].