Laborda Sebastian

Ejercicios
1. ¿Qué puerto usa el servidor UDP?, ¿y el servidor TCP?
Servidor TCP: Puerto 7000 (establecido en el script para realizar la conexión)

Cliente TCP: Puerto 52262 (random)

Servidor UDP: Puerto 7000 (establecido en el script para realizar la conexión)

Cliente UDP: Puerto 60382 (random)

 2. En la computadora que está ejecutando el servidor UDP o TCP: Identifique con
netstat que efectivamente se está escuchando en el puerto que se definió en el
script (ver filmina 44 del teórico). Recomendamos usar: $ netstat -plunt, para
una mejor visualización del comando.

3. ¿Por qué el script client_udp.py no da error si ponemos una dirección de

destino fuera de la VPN, o una IP que no existe?, ¿Por qué el script
client_tcp.py si da error en la misma condición?
El cliente UDP no da error si ponemos una direccion destino fuera de la VPN o una
IP que no existe ya que UDP al no estar orientado en conexion, solo se preocupa por enviar
los paquetes, sin antes verificar que la direccion realmente existe. Por otro lado, TCP, antes
de enviar los datos, el cliente debe establecer una conexión con el servidor usando un
proceso llamado handshake de tres pasos (SYN, SYN-ACK, ACK). Si el servidor no está
disponible (por ejemplo, porque la IP es incorrecta o fuera de la VPN), la conexión no puede
establecerse.
El cliente envía los mensajes pero nunca hay respuesta por parte del servidor, en UDP:
 4. ¿Por qué, cuando usamos tc qdisc y “perdemos paquetes”, en TCP el servidor
recibe todos los mensajes?, ¿qué comportamiento arroja UDP si forzamos la pérdida
de paquetes con tc qdisc?
- tc qdisq show (Para ver la configuración actual de tc)
- sudo tc qdisc add dev lo root netem loss 30% (Configurar la pérdida de paquetes con
tc)

Prueba con TCP

Se aprecia que cuando se envía con TCP llegan todos los mensajes.
Cuando usamos tc qdisc para simular la pérdida de paquetes, el protocolo TCP sigue
asegurando que los mensajes lleguen al servidor debido a sus mecanismos de
confiabilidad. Estos mecanismos aseguran que, incluso si se pierden paquetes en la red,
TCP puede recuperarlos y entregarlos correctamente al servidor. Por eso, aunque simules
la pérdida de paquetes con tc qdisc, el servidor TCP sigue recibiendo todos los mensajes.

Prueba UDP
Se aprecia que cuando se envía con UDP no llegan todos los mensajes.
- sudo tc qdisc del dev lo root (eliminar la configuracion)
5.¿Por qué en UDP, en cada mensaje recibido en el servidor, se vuelve a decir: “Se Rx
xx bytes del cliente xx”?

El mensaje "Se Rx xx bytes del cliente xx" en cada recepción en un servidor UDP
proporciona una manera sencilla y efectiva de rastrear la actividad de red, identificar a los
clientes, verificar la cantidad de datos recibidos y garantizar que se gestionen
adecuadamente los datagramas en este protocolo sin conexión.

6. Usando Wireshark: ¿Por qué hay ACKs en TCP y no en UDP?

El ACK se usa gracias al handshake de tres vías, que es una manera que tiene TCP
para controlar el inicio y el fin de la comunicación.

Podemos ver mensajes de respuesta ya que TCP envia un mensaje del tipo ACK
para confirmar la llegada de ellos y el tamaño de ventana disponible.
En la transmisión UDP no existen mensajes ACK ya que no es un protocolo
orientado a asegurar la conexión, solo envía datos utilizando el máximo ancho de banda
disponible y no reconoce si los datos se enviaron y llegaron correctamente o no.
7. En lugar de Wireshark, use la herramienta tcpdump, que es un sniffer de línea de
comandos (se ejecuta en la consola, sin entorno gráfico). Usando tcpdump compare
en líneas generales los escenarios UDP vs TCP y los mensajes que se generan en
cada caso. Compare desde el enfoque del cliente (el alumno que ejecuta
client_udp.py y client_tcp.py) y desde el enfoque servidor (el alumno que ejecuta
server_udp.py y server_tcp.py).Se utilizó el software multipass.
Cliente UDP:

Servidor UDP:

Cliente TCP:

Servidor TCP:

Concluimos que desde el cliente y servidor la visualización es la misma.

8. Identifique paquetes en Wireshark. ¿Puede leer en Wireshark el mensaje?, ¿por
qué?
En la sección “Data” es posible visualizar el contenido del mensaje, pero en formato
hexadecimal. Además, en la parte inferior del software aparece el mensaje traducido a
texto, correspondiente al mensaje enviado.

Para realizar una verificación analizamos el mensaje n°2 del protocolo UDP desde el lado
del servidor:

Traduciendo a texto el mensaje hexadecimal perteneciente al sector “Data”:

Verificando lo visualizado con anterioridad desde el software.

9. ¿Cómo es la comunicación a nivel capa de enlace?, ¿Qué direcciones MACs

intervienen?, ¿por qué?
Se utiliza protocolo Ethernet en nivel de capa de enlace.
Analizando un mensaje TCP desde el cliente al servidor:

La MAC origen es la MAC de la pc cliente, y la MAC destino es la de la pc servidor.

MAC origen:

MAC destino:
Las MAC involucradas son las de las PC cliente y servidor ya que ambas se
encuentran en la red local, y no debe intervenir la MAC del router.

10. Modificando los scripts convenientemente: ¿Qué pasa si el mensaje que

mandamos es más largo?, ¿Cómo se refleja en Wireshark?
TCP

Al enviar un mensaje más largo, el mismo protocolo se encarga de segmentar el mensaje

de acuerdo al MTU de capa 2, evitando el trabajo de fragmentación en capa 3.
UDP:

En este caso, se realiza la fragmentación del mensaje por la capa 3. UDP no se encarga de
segmentar.
11 - Compare el largo de los mensajes TCP y UDP, donde la carga útil es la misma (el
mensaje crudo es del mismo largo). ¿Cuál es más largo?, ¿por qué?

Utilizando el mensaje “numero 0” comparamos los largos.

Tamaño del mensaje TCP 88 bytes

Tamaño del mensaje UDP 64 Bytes

Se aprecia que el mensaje más grande es TCP debido a que el tamaño de la cabecera de
UDP es de 8 bytes y el tamaño de la cabecera de TCP es de 32 bytes.
 Capturas de wireshark donde se aprecian las cabeceras TCP y UDP.

12. Realice un diagrama de estado de una visión simplificada de una sesión TCP
típica, con los datos que observa en Wireshark y basado en la filmina 27 del teórico.
Puede realizarlo en papel y lápiz y luego adjuntar una foto. Distinga los paquetes
[SYN], [PSH] y [ACK]. ¿Cada cuántos paquetes se manda un ACK de parte del
servidor? ¿Qué significa que sean PSH?, ¿Quién es responsable de este
comportamiento?

Ejercicios de complemento
13. ¿Cuánto tiempo mantiene el servidor TCP una conexión con un cliente, sin haber
tráfico de datos?
Teóricamente, según los visto en clase, el tiempo que el servidor TCP mantiene
conexión con su cliente debería ser de 2 minutos, pero igualmente es un parámetro que
depende del sistema operativo, como se muestra a continuación.
Revisando en la PC, tiempo de ‘keep alive’ es de 2 horas.
14. ¿Qué cambios (generales) encuentra entre los scripts servidor de TCP y UDP?

Dentro de los cambios generales entre los scripts podemos encontrar que:
UDP crea el tipo de socket SOCK_DGRAM, y TCP utiliza SOCK_STREAM. Esto es
por características propias de los protocolos, para poder utilizarlos.
UDP no posee conexión, mientras que TCP si tiene aceptación de conexiones.
UDP recibe los datos con recvfrom mientras que TCP utiliza recv pero recién
después de aceptar la conexión.

15. ¿Puede identificar el proceso asociado al servidor (TCP o UDP) en el sistema

operativo? ¿Qué PID le corresponde?

16. ¿Por qué hemos levantado el servidor en un puerto >1023?, ¿qué pasa si
queremos usar un puerto menor a 1023, cuando ejecutamos el script como usuario
(no como root)?
Los puertos menores a 1023 son los denominados “puertos bien conocidos” que ya
están asignados para determinados procesos, como por ej. puerto 22 para SSH o puerto 80
para Web, entre otros.
Debido a esto, al ejecutar el servidor en un puerto menor al 1023 obtenemos este
mensaje de error.

17. ¿Qué pasa cuando, en nuestra implementación en python, dos clientes quieren
conectarse simultáneamente?

Cuando dos clientes quieren conectarse al mismo tiempo al mismo servidor, lo que
ocurre es que se asignan dos puertos diferentes de destino, generandose de esta manera
tres sockets. Como se puede apreciar en la siguiente imagen.
Realizando la implementación en la misma PC, se observa que al cliente se le asignan
también dos puertos diferentes.
18. Produzca (usando tc qdisc) un escenario que fuerce a que se deban re-transmitir
paquetes TCP. Intente comparar este comportamiento con la secuencia mostrada en
el teórico (filminas 59-62) COASSOLO
- sudo tc qdisc add dev lo root netem loss 30%
- Ver el comportamiento
- sudo tc qdisc del dev lo root
En un funcionamiento normal luego de cada mensaje, hay un [ACK].

Luego del [PSH, ACK] hay un [ACK].

En cambio, si no llega un [ACK],

Hay una retransmisión hasta que llegue el [ACK] correspondiente.

20. Usando el campo Time, que ofrece Wireshark, ¿podría calcular el RTT (round trip
time)? Se condice con el RTT de un ping? Gallardo y Biscay
El RTT se calcula como la diferencia entre el tiempo en que se envía el paquete y el
tiempo en que se recibe la respuesta. El campo Time en Wireshark te muestra las marcas
de tiempo para cada paquete.
En TCP podríamos compararlo entre el mensaje SYN y el mensaje de respuesta
SYN-ACK, o entre cualquier mensaje enviado y su correspondiente ACK de respuesta.
Comparando entre el mensaje numero 1 y su correspondiente ACK:
 Mensaje del cliente:

Tiempo desde que se envió la primer trama en la comunicación TCP: 1.1941

segundos
Mensaje ACK de confirmación del servidor:

Tiempo desde que se envió la primer trama en la comunicación TCP: 1.3188

segundos
El RTT correspondiente a este mensaje es: 1.3188 [s] - 1.1941 [s] = 0.1247 [s]

En UDP no tenemos mensajes de respuesta, por lo que no podriamos calcular el

RTT. Para calcularlo, deberiamos modificar el script del servidor para que envie alguna
respuesta, o utilizar otro tipo de comando como ping.

21. El script UDP que tenemos de python, ¿hace comprobación de errores

(checksum)?

El script proporcionado por la cátedra no hace comprobación de errores, pero el

protocolo UDP cuenta con Checksum. El mismo se utiliza para verificar la integridad de los
datos en el proceso de transmisión. Aunque UDP es un protocolo no orientado a la
conexión (sin confirmación de entrega ni retransmisión de paquetes perdidos), el checksum
ofrece un nivel básico de protección contra errores introducidos durante la transmisión,
como errores en los bits debido a interferencias.