Tp 3 - Redes de Computadoras

Transcripción

Departamento de Electrónica
Facultad de Ingeniería
Seminario de Redes
TRABAJO PRACTICO Nº 3
“UDP y TCP.”
Grupo: NMNK
Responsable a cargo:
Integrantes:
•
•
Guzmán Pegazzano, Ma. Azul
•
•
E-mail: [email protected]
Padrón: 77902
•
•
Padrón: 77799
Josa Scorza, Gonzalo
• Rodríguez Palacios, Agustina
•
•
Padrón: 77677
Seminario de Redes de Computadoras.
Trabajo Práctico Nº 3
Grupo NMNK
Maqueta.
Para el desarrollo de las pruebas se utilizará la siguiente maqueta. Dependiendo
del escenario en cuestión, se utilizará una parte de la maqueta en especial, la cual será
especificada en el escenario correspondiente, es decir, la siguiente es la maqueta más
general utilizándose ciertos sectores de la misma en cada caso.
FI.UBA
SERVER
PC
L14
ETH. A:192.168.1.0 / 24
.2
PC2
.3
PC3
.1
PC1
MDM
INTERNET
+
200.10.122.10
DNS
Server
Descripción de los equipos utilizados.
PC1: Windows XP. Ethereal.
PC2: Windows 98. Ethereal.
PC3: Linux Red Hat 7.2
PCL14: Linux.
2
Grupo NMNK
Escenario I. DHCP sobre UDP
Objetivo:
En este escenario se desea observar como se encapsulan los mensajes DHCP
sobre el protocolo UDP.
Desarrollo:
Dentro de la red Ethernet A se configura la PC 1 como servidor DHCP y a la
PC3 como cliente DHCP. Se sniffeará el tráfico en la LAN cuando el cliente DHCP
negocia el arrendamiento de una dirección IP al bootearse. En particular, se analizarán
los puertos utilizados por UDP.
Ejecución:
En esta trama se observa que el protocolo DHCP viaja sobre UDP, utilizando los
puertos 67 y 68. En particular, el puerto que utiliza el servidor es el 67, y el que utiliza
el cliente es el 68.
En el header UDP no se manifiesta cual es el protocolo que está encapsulando.
Conclusiones:
Vemos que DHCP utiliza el protocolo UDP para encapsularse, usando los
puertos reservados 67 y 68 tal como se manifestó anteriormente. Utiliza UDP y no
TCP porque los diálogos que se establecen no son punto a punto sino del tipo broadcast,
ya que en el proceso de arranque se desconoce la dirección IP del servidor DHCP a
contactar, necesaria para establecer una conexión TCP.
3
Grupo NMNK
Escenario II. Transacciones DHCP
Objetivo:
Se pretenden observar distintos mensajes DHCP que se intercambian en el
arrendamiento de una dirección IP.
Desarrollo:
Este escenario, se desarrolla con la misma configuración anterior (la PC 1 como
servidor DHCP y la PC3 como cliente DHCP), y se observarán los distintos mensajes
que se ven involucrados en el momento de arrendar una dirección IP.
Un host difunde un mensaje broadcast de nivel 2 (DHCP DISCOVER) a todos
los servidores DHCP de la red LAN (en este caso la PC1) con el fin de obtener una
dirección IP. El servidor responde a este pedido enviando un mensaje DHCP OFFER,
sugiriendo una posible IP. El cliente selecciona la dirección IP y negocia el
arrendamiento con el servidor enviándole un mensaje DHCP REQUEST avisando que
va a aceptar la dirección IP propuesta. Por último el servidor le confirma el
arrendamiento mediante un mensaje DHCP ACK.
Ejecución:
La secuencia de tramas obtenidas fue la siguiente:
4
Grupo NMNK
El primer paquete, correspondiente al DHCP DISCOVER, posee los siguientes campos:
Este es un mensaje del tipo Boot Request, lo cual se observa en el campo
Message Type. A su vez, también se puede ver que es un mensaje de broadcast como se
dijo anteriormente, lo cual se ve en la trama Ethernet. En el campo de opciones, se
destaca que el tipo de mensaje DHCP es el de DHCP Discover.
La trama correspondiente al paquete DHCP OFFER es:
5
Grupo NMNK
En esta trama se observan todos los parámetros que debe tener el cliente para
arrendar una dirección IP, tales como el tiempo de arrendamiento (opción 59), tiempo
de reasignación (opción 58), y el tiempo de expiración (opción 51). A su vez se envía
información adicional como las direcciones IP del gateway y del DNS server asociado a
la LAN.
Se observa que este mensaje también es un broadcast de nivel 2.
La trama correspondiente al paquete DHCP Request es:
6
Grupo NMNK
En este paquete se observa en el campo option 50, cual es la dirección IP elegida
que es la 192.168.0.52.
La trama correspondiente al paquete DHCP ACK es:
En este paquete, el servidor DHCP le confirma al host que puede comenzar a
utilizar esa dirección IP a partir de ese momento. Con esta trama termina la transacción.
7
Grupo NMNK
Conclusiones:
Como primer observación, notamos que el servidor envía mensajes ARP
intercalados antes de enviar el mensaje DHCP OFFER, y antes del mensaje DHCP
ACK. Suponemos que el servidor realiza consultas ARP con el fin de verificar que la IP
propuesta al cliente no esté siendo utilizada por ningún host dentro de la misma LAN.
Notamos también que el host, luego de haber recibido la confirmación de su
dirección IP, envía un mensaje ARP broadcast, consultando a la red para confirmar que
nadie la esté utilizando.
Todos los mensajes DHCP observados son del tipo broadcast. Creemos que es
así con el fin de que todos los hosts de la red sean informados acerca de la existencia de
una nueva dirección IP en la red.
8
Grupo NMNK
Escenario III: TFTP sobre UDP
Objetivo:
El objetivo de este escenario es ver como se encapsula TFTP en UDP.
Desarrollo:
Para lograr este escenario se realizó un TFTP desde la PC1 hacia la PC3 dado
que en este caso la PC3 actuaba como servidor TFTP (dado que el servidor TFTP que
teníamos corría sobre Windows 98).
TFTP se diseñó para aplicaciones que no necesiten interacciones complejas
entre cliente-servidor. TFTP no necesita un transporte de flujo confiable por lo que no
es necesario que viaje sobre TCP; razón por la cual se utiliza UDP.
Ejecución:
Se realizó la siguiente captura:
En esta captura se puede observar que TFTP utiliza el puerto 69 de UDP como
puerto destino y un puerto efímero como puerto origen (puerto 3222 en este caso).
La trama 107 es la primer trama de la aplicación TFTP, la cual indica el tipo de
mensaje que interviene (en este ejemplo se realiza un pedido de lectura).
Conclusiones:
TFTP utiliza como protocolo de transporte UDP ya que no necesita interacciones
complejas entre servidor-cliente ni un transporte de flujo confiable.
9
Grupo NMNK
Escenario IV: TFTP
Objetivo:
Se desean analizar los distintos mensajes de TFTP y el funcionamiento de esta
aplicación.
Desarrollo:
Para realizar este escenario realizamos diferentes transferencias TFTP con 2
tipos de mensajes: Read Request y Write Request. En estas transferencias también se
involucran los mensaje de datos, acknowledge y error.
Ejecución:
Para la operación de lectura se capturó la siguiente trama:
Este primer mensaje es generado por el cliente, quien utiliza un puerto efímero
(3222). El puerto contra el cual se establece la conexión en el servidor es el puerto 69 de
UDP.
En la operación de lectura el primer mensaje es del tipo “Read Request”, lo cual
se observa en el campo “opcode” con valor igual a 1. En el header de TFTP también se
muestra el archivo sobre el cual se desea realizar la operación (readme.txt).
10
Grupo NMNK
Los paquetes subsiguientes son del tipo de mensaje “datos” con sus
correspondientes “acknowledges”:
En la trama de datos, se observa que el opcode tiene valor 3 y que el tamaño de
los paquetes es 512 bytes (máximo tamaño de datos que permite UDP).
El último paquete de datos es el siguiente:
En éste se observa que la cantidad de datos es de 61 bytes. TFTP interpreta esto
como que éste es el último paquete de datos ya que todos los paquetes de datos poseen
un tamaño de 512 bytes con excepción del último. Cuando se recibe un paquete de
tamaño inferior, se infiere que la transferencia de datos ha terminado.
11
Grupo NMNK
En un mensaje del tipo acknowledge el campo de opcode posee un valor igual a
4.
Por cada paquete de datos recibido se manda un mensaje de acknowledge. Hasta
que éste no se recibe no se envía el siguiente mensaje de datos.
Es interesante observar dentro del paquete TFTP el campo “block” indica el
segmento al cual se refiere el acknowledge en cuestión. El campo block tanto en el
mensaje de datos como en el acknowledge indica la correspondencia que existe entre
estos. El campo block indica la posición relativa del segmento de datos dentro del
archivo total a transmitir.
Para la operación de escritura se capturó la siguiente trama:
En esta trama el tipo de mensaje es de “Write Request”. Esto se observa en el
campo opcode con valor igual a 2. A diferencia del mensaje “Read Request”, este
mensaje tiene un campo de “Destination File”, el cual indica el archivo que se desea
escribir (readme.txt).
12
Grupo NMNK
En una operación de escritura, las tramas de datos poseen el mismo formato que
en la operación de lectura.
Conclusiones:
TFTP establece la conexión con el puerto 69 de UDP. Una vez que se ha
establecido la conexión este puerto queda liberado y el servidor cambia a un puerto
efímero cualquiera, de manera de dejar disponible este puerto para otras conexiones
sucesivas TFTP. En este caso se observa que el puerto efímero que utiliza el destino es
el 1038.
Las tramas de datos poseen igual formato tanto para las operaciones de lectura y
escritura.
Para saber cuando finaliza la transferencia de datos, TFTP analiza el tamaño de
los paquetes de datos. Cuando recibe un paquete de tamaño menor al máximo aceptado
por UDP (512 bytes), determina que es el último paquete de datos, dando por finalizada
la transferencia.
13
Grupo NMNK
Escenario V: Establecimiento de la conexión en TCP.
Objetivo:
El objetivo de este escenario es ver cómo realiza TCP el establecimiento de una
conexión.
Desarrollo:
Dado que TCP es un protocolo orientado a la conexión, antes de el envío de
datos, debe establecerse una conexión.
En un segmento TCP existen los siguientes flags:
Flag
S
F
R
P
A
U
Abreviación
SYN
FIN
RESET
PUSH
ACK
URG
Observación
Sincroniza el número de secuencia
Quien lo envía deja de enviar datos.
Reseteo de la conexión
Empuja los datos hacia el proceso de recepción lo antes posible.
Acknowledge de segmentos recibidos.
Indica datos Urgentes.
Cuando el flag push se encuentra activado, esto es una notificación del emisor al
receptor para que éste pase todos los datos que tiene en la cola al proceso de recepción.
Los datos que se transfieren al proceso de recepción son todos aquellos que se
encuentren en la cola más los que llegan con el flag push activado.
En el inicio de la conexión, el primer paquete contiene el falg SYN activado,
especificándose el número de puerto del servidor al cual se quiere conectar junto con el
número de secuencia inicial del cliente. El servidor responde también con su bit de SYN
activado, el cual contiene su número de secuencia inicial. El servidor también realiza el
ACK del SYN del cliente enviándole el número de secuencia del cliente más uno
(ISNcliente + 1). El cliente debe a su vez, hacer un ACK del SYN del servidor
transmitiéndole el numero de secuencia del servidor más uno (ISNservidor + 1). Con este
último paquete finaliza el establecimiento de la conexión. Esta recibe el nombre de
“Threeway handshake”.
Quien envía el primer SYN realiza la “apertura activa” y el otro la “apertura
pasiva”.
El valor del ISN debe cambiar a lo largo del tiempo para que cada conexión
tenga un valor de ISN distinto.
En el establecimiento de la conexión también se negocia el máximo tamaño de
segmento permitido en bytes (MSS: Maximum Segment Size). El emisor no desea
recibir segmentos TCP mayores al valor indicado por este parámetro. Este valor se elige
con el fin de evitar la fragmentación en TCP. El tamaño del MSS es en general de 1460
bytes, ya que se tiene en cuenta una MTU de 1500 bytes, 20 bytes de encabezado de IP
y 20 bytes de encabezado TCP.
El campo window size indica el tamaño de la ventana de datos disponible que se
puede recibir. Tanto quien realiza la apertura activa, como quien realiza la apertura
pasiva envían tamaños máximos de ventana en el inicio de la conexión; ambos tamaños
son independientes entre sí. Los mismos pueden ir variando a lo largo de la conexión,
según sea la congestión existente en el enlace.
14
Grupo NMNK
Para poder observar lo arriba expuesto realizaremos una conexión TELNET
entre la PC1 y la PC2.
Ejecución:
Se capturaron las siguientes tramas:
•
•
•
•
En el segmento señalado se observan lo siguiente:
el bit de SYN activado, ya que éste es el primer segmento de una conexión TCP
establecida
el número de secuencia inicial (2123205155)
el tamaño de window size (16384)
el MSS (1460)
Se observa que en este caso, el número de puerto al cual se quiere conectar el cliente
es el 23; es decir Telnet, ya que la aplicación que utilizamos era ésta.
En el siguiente segmento el servidor inicia la conexión en el sentido opuesto,
observándose los siguientes bytes:
15
•
•
•
•
•
Grupo NMNK
el bit de SYN está activado
el número de secuencia inicial correspondiente a ese sentido de la
transmisión
el ACK del segmento SYN recibido
el window size del servidor
el mismo MSS
Se observa que el número de puerto destino en este paquete, corresponde al
mismo número de puerto de origen del paquete anterior.
Por último, vemos el tercer paquete involucrado en el establecimiento de la
conexión:
16
Grupo NMNK
Notamos que el ACK es igual al número de secuencia anterior, más uno, y que el
número de secuencia de este paquete es superior en uno, con respecto al número de
secuencia del primer paquete (2123205155 + 1 = 2123205156).
Se ve que en este paquete el tamaño de la ventana aumentó con respecto al
primer paquete (de 16384 pasó a 17520).
Conclusiones:
Se puede concluir que al establecerse una conexión TCP se utiliza un socket
pair, es decir; cada extremo de la conexión reserva un puerto para la conexión,
manteniéndolo durante el transcurso de la misma.
El hecho de que exista un número de secuencia para cada sentido de la conexión
se debe a que la misma es full-duplex.
El MSS se determina en los dos primeros paquetes intercambiados, por lo tanto,
este dato no aparece en el resto de la conexión.
El tamaño de la ventana aumenta en los paquetes sucesivos, debido a que TCP
no detectó congestión en el enlace y por lo tanto puede aumentarlo.
17
Grupo NMNK
Escenario VI: Finalización de la conexión en TCP.
Objetivo:
El objetivo de este escenario es ver cómo realiza TCP la finalización de una
conexión.
Desarrollo:
En la finalización de la conexión intervienen 4 paquetes debido a que la
conexión TCP es full-duplex y por lo tanto cada extremo debe finalizar su conexión.
Cualquiera de los extremos que no quiera enviar mas datos, enviará una
segmento con el flag FIN activado. El receptor realiza una acknowledge de éste
segmento dando por finalizada la conexión en es sentido. A partir de este momento la
conexión se vuelve half-duplex es decir, el extremo que cerró su conexión solo enviará
mensajes de acknowledge hacia el otro extremo. Cuando éste último desea finalizar por
completo la conexión, envía un FIN esperando recibir el ACK correspondiente. Quien
envía el primer FIN realiza lo que se llama “finalización activa” y quien responde
realiza la “finalización pasiva”.
Ejecución:
Durante la finalización de la conexión anterior se capturaron las siguientes
tramas:
En esta trama se puede observar que tanto el flag de ack y el flag de fin están
activados. Esto se debe a que para no generar tráfico de más se aprovecha el mensaje de
acknowledge de datos para enviar a su vez el anuncio de fin.
18
Grupo NMNK
El mensaje de acknowledge para la trama anterior es el siguiente:
En esta trama se observa que el bit de FIN no está activado; esto se debe a que
en este caso se esta finalizando la conexión en un solo sentido.
Conclusiones:
TCP permite enviar el flag de FIN junto con el acknowledge de un paquete de
datos con el fin de no generar tráfico extra en el enlace.
La conexión puede finalizarse en un solo sentido permitiendo al otro extremo
continuar con la suya. Por ello, el extremo que finaliza su transmisión de datos, no
libera el puerto que estaba utilizando para la misma. El socket-pair es liberado solo
cuando la conexión termina por completo, luego de transcurrido un tiempo de 2MSL
(tiempo de espera para liberar el socket-pair).
19
Grupo NMNK
Escenario VII: FTP sobre TCP.
Objetivo:
El objetivo de este escenario es observar como funciona FTP sobre TCP.
Desarrollo:
Se realizó una transacción FTP (get) desde la PC1 hacia la PC 2, donde está
instalado un servidor FTP.
Cuando el cliente en la PC1 establece la conexión con el servidor en la PC2, el
cliente utiliza un número de puerto aleatorio y se pone en contacto con el puerto 21 del
servidor. Este par de números de puertos son los que se utilizan para la conexión de
control. Para realizar la transferencia de datos se utiliza un par de puertos diferentes, en
particular el puerto 20 en el servidor y un puerto efímero en el cliente. El cliente utiliza
el canal de control para comunicarle al servidor el puerto efímero por el cual debe
establecer la conexión de datos. En caso de que el cliente no le comunique esto, el
servidor establece la conexión de datos con el mismo puerto con el cual tiene
establecida la conexión de control.
20
Grupo NMNK
Ejecución:
En estas primeras tramas se puede observar como se establece la conexión TCP
entre la PC1 y la PC2:
21
Grupo NMNK
En estas tramas se observa que la conexión se establece entre el puerto efímero
3017 del cliente y el puerto 21 (reservado para FTP) del servidor.
En la trama siguiente se puede observar cuando el cliente le envía al servidor el
puerto efímero con el cual debe establecer la conexión de datos:
22
Grupo NMNK
En la última línea del campo FTP, el cliente envía el puerto que debe utilizar el
servidor para transmitirle datos. Este puerto se coloca a continuación de la dirección IP
del cliente de la siguiente manera:
192.168.0.1.11.203
donde:
dirección IP del cliente: 192.168.0.1
puerto efímero a conectar (en base 256): 11.203
El valor del puerto es entonces (11.203)256 = 3019
A continuación se observa la trama en la cual se pide el archivo “setuplog.txt”:
Dentro de la trama de FTP se encuentra el campo de request arg, donde se
escribe el archivo que se desea obtener (setuplog.txt).
23
Grupo NMNK
En las siguientes tramas se observa el establecimiento de la conexión para el
tráfico de datos:
24
Grupo NMNK
En esta trama se puede observar que la conexión se estableció contra el puerto
3019 del cliente.
Con respecto a la finalización de la conexión:
Se observa que cuando la PC2 (ana.mshome.net) finaliza la transferencia de
datos, ésta realiza el cierre activo de la conexión enviando un FIN a la PC1
(hppav.mshome.net) junto con el acknowledge de los últimos datos recibidos.
25
Grupo NMNK
La trama anterior es el ACK al FIN enviado por la PC2.
La trama siguiente es la correspondiente a la finalización pasiva que realiza la
PC1. La misma envía una trama con el bit FIN activado hacia la PC2.
26
Grupo NMNK
Luego, la PC2 responde con un ACK correspondiente:
Las tramas anteriores representan la finalización de la conexión de datos.
Como la conexión de datos es independiente de la conexión de control, ésta
también necesita su finalización. En este caso es la PC1 quien realiza la finalización
activa de la conexión de control:
27
Grupo NMNK
La PC2 envía el ACK correspondiente:
La PC2 realiza la finalización pasiva de la conexión de control:
28
Grupo NMNK
En el momento de la finalización de la conexión de datos y de control, se libera
el socket-pair utilizado en la conexión.
Conclusiones:
Cuando se utiliza el protocolo FTP, se observa que en lugar de una sola
conexión TCP, se obtienen dos conexiones completamente independientes entre sí. La
primera conexión se realiza para los comandos de control y se establece entre el puerto
21 del servidor y un puerto efímero cualquiera del cliente. La segunda conexión se
establece entre el puerto 20 del servidor y otro puerto efímero del cliente, el cual es
comunicado al servidor a través de la primera conexión. En caso que el cliente no le
especifique otro puerto efímero, la conexión de datos se establece en el mismo puerto
que la primera; debiendo éste multiplexar la información que le llegue.
Pese a que cuando finaliza la transmisión de datos el puerto 20 del servidor y el
puerto efímero correspondiente quedan liberados; la conexión de control se mantiene en
caso de que se quiera realizar otra operación.
La conexión de control finaliza cuando se tipea el comando “bye”, indicando
que se desea terminar la aplicación.
29
Grupo NMNK
Escenario VIII: Conexiones de datos sucesivas en FTP.
Objetivo:
El objetivo de este escenario es observar como se establecen 2 conexiones de
datos sucesivas bajo la misma sesión de FTP; analizando si se utiliza el mismo puerto
efímero del cliente en ambas conexiones.
Desarrollo:
Para lograr el objetivo se inició una sesión FTP de la PC1 a la PC2 para obtener
dos archivos diferentes “blue.txt” y “bluedot.txt” que se encontraban en la PC2.
Ejecución:
A continuación se destacan las tramas que involucran el establecimiento de las
transmisiones de datos. En primer lugar se muestra la transferencia de datos del primer
archivo; luego la del segundo archivo, obtenidos de la PC2 mediante la operación “get”.
30
Grupo NMNK
Conclusiones:
A partir de el sniffeo de los paquetes podemos observar que al ejecutar dos
transacciones “get” en una misma sesión FTP; al finalizar una, y comenzar otra los
puertos asignados por el cliente para recibir los datos son diferentes.
31
Grupo NMNK
Escenario IX: Aplicación de TCP según el sistema operativo.
Objetivo:
Determinar las diferencias de la implementación de TCP sobre distintos sistemas
operativos.
Desarrollo:
Se realizó una sesión de TELNET entre la PC1 con sistema operativo Windows
XP y la PC3 con Linux y una conexión FTP entre la PC1 y la PC2 con Windows 98.
Una vez capturado el tráfico de ambas conexiones se analizarán las diferencias
en la implementación de TCP.
Ejecución:
Las tramas correspondientes a la conexión TELNET son las siguientes:
El primer segmento corresponde al enviado desde la PC1 con Windows XP
hacia la PC3 con Linux; mientras que el segundo es la respuesta al primero.
32
Grupo NMNK
Se realizó una nueva captura, pero en este caso se corrió la aplicación FTP desde
la PC1 a la PC2, y se analizaron los paquetes intercambiados en las dos direcciones:
Conclusiones:
Vemos que la única diferencia que existe al variar las plataformas en donde se
implementa TCP, es el tamaño de la ventana. Los demás parámetros no varían ya que
están dados por factores externos al sistema operativo en curso. Es el caso de el valor
del MSS, que está dado por la interfaz de capa 2 (Ethernet), o el caso de la asignación
de los puertos TCP utilizados, que sólo están dados en función de la aplicación que se
corre.
El mayor tamaño de ventana se observa en la PC1 en donde corre el sistema
operativo Windows XP. Luego sigue el tamaño de ventana de Windows 98, y por
último el de Linux.
33
Grupo NMNK
Escenario X: Congestionamiento del enlace.
Objetivo:
El objetivo de este escenario es observar el congestionamiento del enlace.
Desarrollo:
Se realizará una transacción FTP entre la PC2 y el servidor FTP
ftp.fi.debian.org. A la vez se realizarán transacciones FTP desde la PC1 con el servidor
remoto para cargar el enlace y se trazará la curva de congestión correspondiente.
En un principio se negociará un tamaño de ventana dado. Cuando se realicen las
nuevas conexiones FTP que comparten el enlace, se deberá negociar un nuevo tamaño
de ventana ya que todas compartirán el mismo ancho de banda, aumentando los tiempos
de tránsito de los paquetes en la red. Este aumento influye en la determinación del
tamaño de la ventana, ya que éste se calcula a partir de los tiempos.
Ejecución:
La operación realizada fue un “get” transfiriéndose un archivo desde el servidor
FTP.
Los paquetes en los cuales se observa el bit de CWR seteado son los siguientes:
34
Grupo NMNK
Estos paquetes corresponden a la inicialización de la conexión de datos.
Una vez capturado todo el tráfico de la transferencia de datos original se realizó
el gráfico que representa el intercambio de paquetes de dicha conexión en función del
tiempo.
time
35
Grupo NMNK
Conclusiones:
Las variaciones de pendientes en el gráfico representan los cambios en la tasa de
transferencia denotando que el enlace se encuentra congestionado. Al principio se
observa que la pendiente es máxima ya que en el enlace sólo está presente la
transferencia de datos original. A medida que comienzan a establecerse nuevas
conexiones, la pendiente va disminuyendo debido a que el enlace comienza a ser
compartido por todas las sesiones. Las variaciones de pendiente que aparecen en la
mitad de la curva corresponden a la finalización e inicio de las sesiones FTP utilizadas
para cargar el enlace.
36

Tp 3 - Redes de Computadoras

Transcripción

Documentos relacionados

Capítulo 6 - Seminario Menor de Pilas

redes para todo