TP 6 - Grupo Industriales 2 0

Vista previa del material en texto

REDES Y TELECOMUNICACIONES - INDUSTRIALES 4.0 
 
ACTIVIDADES 
 
1. Una forma de hacer control de flujo en la capa de transporte es pedir 
explícitamente, de extremo a extremo, que no se transmitan más segmentos. 
Otra es no aceptar datos de las capas inferiores, con la esperanza de que, al no 
poder librarse la capa de enlace de sus tramas, hará control de flujo a la estación 
anterior. Discute las desventajas de esta última estrategia. 
 
Una desventaja es que se le acopla toda la responsabilidad del control de flujo 
a una sola capa, a la capa de enlace de datos y sería probable que un emisor más 
rápido que un receptor lento provoque que el receptor descarte paquetes porque no 
puede atenderlos, lo cual ya no lo va a saber el emisor porque la subred confirma que 
los paquetes fueron recibidos. Otra desventaja es que por ejemplo cuando conexiones 
múltiples de transporte están multiplexadas (multiplexión descendente) en una única 
conexión de red (circuito virtual), el control de flujo se ejerce sólo en el agregado de 
todas las conexiones de transporte. 
 
2. Con un servicio de red fiable y que garantiza el orden, ¿son estrictamente 
necesarios los números de secuencia de los segmentos? ¿Qué capacidad, si 
hay alguna, se pierde sin ellos? 
 
A pesar de tratarse de una red fiable que garantiza el orden, es estrictamente 
necesario que el segmento tenga un número de secuencia. Si se pierde un segmento 
es decir un paquete durante la trasmisión, éste paquete es retransmitido y no 
necesariamente respetando el orden de los segmentos, por lo tanto, sin un número de 
secuencia el receptor no sabrá cómo ordenar los segmentos que recibe de la 
retransmisión. 
 
3. De ejemplos de aplicaciones para las que es conveniente el uso de un servicio 
como el que proporciona UDP. 
 
La simplicidad de UDP hace que sea ideal para aplicaciones que requieren 
pocos retardos (por ejemplo, aplicaciones en tiempo real como pueden ser 
aplicaciones de voz y video). UDP también es ideal para aquellos dispositivos que no 
pueden implementar un sistema tan complejo como el TCP. 
Otro uso interesante del UDP es en aplicaciones que trabajan en modo 
multicast o broadcast (enviar información a un grupo de usuarios o a todos los 
usuarios de la red). En este caso, se envía información a muchos receptores sin 
esperar una respuesta de todos, de manera que es ideal disponer de un protocolo de 
transporte simple y sencillo no orientado a la conexión como el UDP. 
En general: 
● UDP se usa cuando se buscan transmisiones con una cantidad de información 
baja en los paquetes y altas velocidades de transferencia, aunque se puedan 
perder algunos paquetes. 
FACULTAD DE INGENIERIA – UNJu JTP: Ing. Consuelo Gómez 
REDES Y TELECOMUNICACIONES - INDUSTRIALES 4.0 
4. ¿Por qué es necesario UDP? ¿Por qué no puede un programa de usuario 
acceder directamente a IP? 
 
Porque UDP sirve como multiplexor/demultiplexor para enviar y recibir 
datagramas, usando los puertos para dirigir los datagramas. UDP permite además 
mediante el uso de puertos dirigir los datagramas a proceso concretos y no a todo el 
sistema, siendo UDP una capa extremadamente delgada que permite menos 
"overhead". 
Un programa de usuario no puede acceder directamente a IP porque si el 
programa necesita enviar datos, debe antes pasar por varios protocolos para que 
permitan dejar la información en un formato entendible para la red. 
5. (Ejercicio basado en 6.16 de Tan 03) Uno de los mayores problemas a los que 
se enfrenta la capa de transporte es la recuperación ante caídas. El problema 
surge porque, aunque suponemos que la escritura de los datos recibidos y el 
envío de la aceptación son sucesos indivisibles, en una maquina no pueden 
hacerse a la vez. Por ejemplo, podrían pasarse los datos a la capa superior 
(escritura) primero, y después emitir el asentimiento, pero si la caída ocurre 
entre medias hay inconsistencias. Si dos máquinas tienen abierta una conexión 
de transporte, y una de ellas cae, pueden darse seis situaciones, que resultan de 
combinar el orden de los tres eventos: la caída (C), la escritura de los datos (E), y 
el envío del asentimiento (A). Observa que algunas son la misma, como C(EA) o 
C(AE), porque después de la caída realmente no pasa nada, como indican los 
paréntesis. Todos los asentimientos que hubiesen sido transmitidos ya llegaran 
al otro extremo, con lo que un segmento pendiente de confirmar. 
Puede que haya sido escrito pero no confirmado, en cuyo caso no debería 
retransmitirse, o que no haya sido ni siquiera escrita, por lo que sí debería 
retransmitirse. Las estrategias que podría tomar el lado transmisor tras la 
recuperación son (1) retransmitir siempre; (2) no retransmitir nunca; (3) 
retransmitir solo si se tiene un segmento pendiente de confirmar; (c) retransmitir 
solo si no se tiene un segmento pendiente de confirmar. Complete la tabla 
siguiente indicando BIEN si el protocolo funciona bien, DUPLICADO si el 
receptor pasa duplicados a la capa de transporte, y PERDIDA si el receptor 
pierde algún segmento. 
 
 Primero ACK, luego escribe Primero escribe, luego ACK 
 AC(E) AEC C(AE) C(EA) EAC EC(A) 
Estrategia 
1 
BIEN DUPLICADO BIEN BIEN DUPLICADO DUPLICADO 
Estrategia 
2 
PÉRDIDA BIEN PÉRDIDA PÉRDIDA BIEN BIEN 
Estrategia 
3 
PÉRDIDA BIEN BIEN BIEN BIEN DUPLICADO 
FACULTAD DE INGENIERIA – UNJu JTP: Ing. Consuelo Gómez 
REDES Y TELECOMUNICACIONES - INDUSTRIALES 4.0 
Estrategia 
4 
BIEN DUPLICADO PÉRDIDA PÉRDIDA DUPLICADO BIEN 
 
6. En su pc abra una página web www.hotmail.com y luego utilice el comando 
netstat analice el reporte. 
 
El comando ​netstat permite visualizar las conexiones establecidas por el equipo 
en un determinado momento. Vamos a observar la salida de éste comando cuando 
accedemos al sitio web de hotmail, donde es notorio que los guiones marcados en rojo 
son la cantidad de conexiones activas que tenemos en google chrome. 
Microsoft Windows [Versión 10.0.18362.900] 
(c) 2019 Microsoft Corporation. Todos los derechos reservados. 
 
C:\WINDOWS\system32>netstat 
 
Conexiones activas 
 
 Proto Dirección local Dirección remota Estado 
 TCP 127.0.0.1:49783 DESKTOP-R46Q1A6:49784 ESTABLISHED 
 TCP 127.0.0.1:49784 DESKTOP-R46Q1A6:49783 ESTABLISHED 
 TCP 127.0.0.1:49792 DESKTOP-R46Q1A6:49793 ESTABLISHED 
 TCP 127.0.0.1:49793 DESKTOP-R46Q1A6:49792 ESTABLISHED 
 TCP 192.168.0.108:49725 52.177.165.30:https ESTABLISHED 
 TCP 192.168.0.108:49766 162.125.5.13:https CLOSE_WAIT 
 TCP 192.168.0.108:49772 162.125.5.13:https CLOSE_WAIT 
 TCP 192.168.0.108:49773 162.125.5.13:https CLOSE_WAIT 
 TCP 192.168.0.108:49774 162.125.36.1:https CLOSE_WAIT 
 TCP 192.168.0.108:49778 ec2-34-236-45-120:https CLOSE_WAIT 
 TCP 192.168.0.108:49780 162.125.5.7:https CLOSE_WAIT 
 TCP 192.168.0.108:49787 162.125.5.7:https CLOSE_WAIT 
 TCP 192.168.0.108:49789 162.125.5.7:https CLOSE_WAIT 
 TCP 192.168.0.108:49790 162.125.5.7:https CLOSE_WAIT 
 TCP 192.168.0.108:49797 162.125.19.131:https ESTABLISHED 
 TCP 192.168.0.108:49842 52.179.224.121:https ESTABLISHED 
 TCP 192.168.0.108:49848172.217.192.188:5228 ESTABLISHED 
 TCP 192.168.0.108:49942 104.208.156.39:https ESTABLISHED 
 TCP 192.168.0.108:49970 13.107.42.11:https ESTABLISHED 
 TCP 192.168.0.108:50079 104.208.156.39:https ESTABLISHED 
 TCP 192.168.0.108:50201 104.208.156.39:https ESTABLISHED 
 TCP 192.168.0.108:50312 13.83.65.43:https TIME_WAIT 
 TCP 192.168.0.108:50330 13.83.65.43:https TIME_WAIT 
 TCP 192.168.0.108:50338 13.83.65.43:https TIME_WAIT 
 TCP 192.168.0.108:50347 13.83.65.43:https TIME_WAIT 
 TCP 192.168.0.108:50350 13.83.65.43:https TIME_WAIT 
 TCP 192.168.0.108:50365 a-0001:https TIME_WAIT 
 TCP 192.168.0.108:50367 13.107.18.11:https TIME_WAIT 
 TCP 192.168.0.108:50368 40.90.22.186:https TIME_WAIT 
 TCP 192.168.0.108:50369 40.90.22.186:https TIME_WAIT 
 TCP 192.168.0.108:50370 13.107.3.254:https ESTABLISHED 
 TCP 192.168.0.108:50371 13.107.255.82:https ESTABLISHED 
 TCP 192.168.0.108:50372 13.83.65.43:https TIME_WAIT 
 TCP 192.168.0.108:50373 13.107.18.254:https ESTABLISHED 
 TCP 192.168.0.108:50374 204.79.197.222:https TIME_WAIT 
 TCP 192.168.0.108:50375 52.114.77.34:https TIME_WAIT 
 TCP 192.168.0.108:50376 eze06s01-in-f19:https TIME_WAIT 
 TCP 192.168.0.108:50377 eze06s01-in-f19:https TIME_WAIT 
 TCP 192.168.0.108:50378 52.109.108.44:https TIME_WAIT 
 TCP 192.168.0.108:50380 191.232.236.80:https TIME_WAIT 
 TCP 192.168.0.108:50381 13.83.65.43:https TIME_WAIT 
FACULTAD DE INGENIERIA – UNJu JTP: Ing. Consuelo Gómez