1 #LyX 1.3 created this file. For more info see http://www.lyx.org/
11 \paperpackage widemarginsa4
15 \use_numerical_citations 0
16 \paperorientation portrait
19 \paragraph_separation indent
21 \quotes_language english
29 Introducción a los Sistemas Distribuídos (74.43)
47 El protocolo PPP es muy utilizado para establecer una comunicación entre
48 2 redes (routers), ya sea entre LANs o entre una LAN y WAN u otras redes
50 Incluso es útil para comunicar un sólo host a una red distante (donde no
51 sería viable tender un cable o utilizar un medio inalámbrico).
52 Al poder ser montado sobre líneas telefónicas conmutadas, este protocolo
53 fue (y es) muy utilizado para proveer acceso a internet.
60 \begin_inset Float figure
67 \begin_inset LatexCommand \label{cap:Diagrama-de-estados-ppp}
71 Diagrama de estados de una conexión PPP
84 Lo primero que debe hacer el protocolo es establecer una conexión física
85 entre las dos puntas de la comunicación, para esto debe discar el número
86 si se utiliza sobre una línea telefónica conmutada, para establecer el
88 Una vez establecido el canal, empieza a actuar el LCP (Link Control Protocol)
89 que negocia, enviando frames PPP, los parámetros de la conexión.
90 Una vez acordados estos parámetros, puede realizarse una etapa de autenticación
91 , para verificar la identidad de las puntas y así permitir o no que la comunicac
93 Finalmente, si todo resultó bien, se envía una serie de paquetes NCP (Network
94 Control Protocol) para configurar la capa de red (como la dirección IP,
95 si se quisiera utilizar el protocolo TCP/IP en dicha capa).
98 En este momento las dos puntas de la conexión están comunicadas y pueden
99 realizar todas sus tareas como si estuvieran conectadas en una LAN.
102 Un vez finalizado, se procede prácticamente de forma inversa a como se estableci
103 ó la conexión para liberarla.
104 Primero se libera la IP a través del procotocolo NCP, luego se libera el
105 enlace cerrando la conexión de la capa LCP y finalmente se cierra la conexión
106 física (se corta el módem), si fuera necesario.
109 Se puede ver un diagrama de estados de este proceso en la figura
110 \begin_inset LatexCommand \vref{cap:Diagrama-de-estados-ppp}
120 Entre las cosas que se pueden configurar (negociando a través del protocolo
121 LCP) está el tamaño de la cabecera del frame (ya que los campos
129 generalmente son fijos y pueden evitarse, el campo
133 puede ser de 1 o 2 bytes y el
137 de 2 o 4) y el máximo tamaño del
142 Estos parámetros se establecen con valores por omisión para poder ser negociado
143 s luego con el protocolo LCP.
146 El protocolo NCP es muy específico sobre qué protocolo de red se quiera
147 negociar, por lo que es muy difícil hablar en términos generales de él.
148 Para el caso más común, donde se negocia para TCP/IP, lo más importante
149 es la asignación de la IP.
152 Configuración de los routes sobre línea dedicada
153 \layout Subsubsection
156 \layout Subsubsection
158 Sin modems (null modems)
164 Tablas de ruteo (simulación)
167 Análisis de la captura HTTP
170 Registro de un nuevo usuario
171 \layout Subsubsection
176 Requirió para cargar el
180 16 mensajes HTTP, 8 GET y 7 respuestas 200 (OK) y 1 404 (NOT FOUND), correspond
181 ientes a dichos mensajes.
182 Los 8 GET fueron para pedir los siguientes archivos:
214 (que devolvió NOT FOUND).
215 Para la página específica de registro de un usuario (el formulario) solo
216 requirió 2 mensajes HTTP (GET y su respuesta) ya que las imágenes ya las
217 tenía en el cache el navegador.
218 Una vez presionado el botón de ENVIAR se observan 4 mensajes más HTTP,
219 primero un POST para enviar los datos del formulario al servidor, luego
220 su correspondiente respuesta 200 (OK).
221 Finalmente se vuelve a cargar el
225 para lo que se utilizan 2 mensajes más (GET y su respuesta 200).
226 Nuevamente observamos que como las imágenes están en el cache, no se vuelven
228 \layout Subsubsection
233 Lo primero que se observa son 3 segmentos para establecer la conexión (SYN
234 y ACK), luego por cada mensaje HTTP se observa al menos 2 segmentos TCP,
235 el que lleva el mensaje HTTP y el ACK que confirma la recepción de dicho
237 Además, si el mensaje HTTP es mayor a algo menos de 1500 bytes (tamaño
238 del MTU de ethernet), se observa la fragmentación y por cada fragmento
239 se generan 2 nuevos segmentos TCP (nuevamente uno que lleva el fragmento
240 de mensaje HTTP y el ACK correspondiente).
241 Finalmente se observan 4 segmentos TCP para la desconexión (FIN y ACK).
244 Para obtener el index.php y sus imágenes se observa que se hace todo en la
245 misma conexión, pero al estar ociosa durante un tiempo el servidor http
246 pide la desconexión y cuando se va a cargar la siguiente página vuelve
247 a iniciar una nueva conexión.
250 En total se observaron 4 conexiones:
253 index.php+imagenes: 53 segmentos (incluyendo 3 segmentos de conexión y 4
257 index.php?NuevoUsuario: 27 segmentos (incluyendo 3 segmentos de conexión
261 index.php?GuardarUsuario+index.php: 97 segmentos (incluyendo 3 segmentos de
262 conexión y 4 de desconexión)
266 \layout Subsubsection
271 Al ser el protocolo IP el transporte de los segmentos TCP, se observa que
272 para cada segmento, hay un paquete IP que lo transporta (incluyendo los
273 segmentos de control, como SYN y ACK).
274 No hay otro tipo de paquete IP que no este asociado a un segmento TCP.
277 Cantidad de paquetes IP: 177
278 \layout Subsubsection
283 Al ser el protocolo ethernet el transporte de los paquetes IP, se observa
284 que para cada paquete, hay un frame ethernet que lo transporta.
285 En esta actividad no se aprecia otro tipo de frame ethernet que no este
286 asociado a un paquete IP.
289 Cantidad de frames ethernet: 177
292 Nueva pregunta de la FAQ
295 A partir de ahora sólo enumeraremos la cantidad de
299 y mencionaremos si hay alguna diferencia con la actividad anterior, ya
300 que la mecánica es muy similar.
301 \layout Subsubsection
306 12 mensajes en total:
309 GET /~luca/foro/index.php?module=faqs&accion=AgregarPregunta HTTP/1.1
312 HTTP/1.1 200 OK (text/html)
315 GET /favicon.ico HTTP/1.1
318 HTTP/1.1 404 Not Found (text/html)
321 POST /~luca/foro/index.php?module=faqs&accion=guardarpregunta HTTP/1.1
324 HTTP/1.1 200 OK (text/html)
327 GET /~luca/foro/index.php?module=faqs HTTP/1.1
330 HTTP/1.1 200 OK (text/html)
333 GET /~luca/foro/avatars/phpQe1MqS HTTP/1.1
336 HTTP/1.1 304 Not Modified
339 GET /favicon.ico HTTP/1.1
342 HTTP/1.1 404 Not Found (text/html)
343 \layout Subsubsection
350 index.php?module=faqs&accion=AgregarPregunta
352 se reutiliza una conexión previa así que no hay SYN y se utilizan 10 segmentos
353 TCP (incluyendo los 4 de la desconexión).
358 se reutilizó otra conexión diferente, por lo cual tampoco se presentan
359 los segmentos de conexión.
360 En ésta se utilizan 8 segmentos TCP (incluyendo la desconexión).
361 Finalmente el envío de los datos se realiza todo en una nueva conexión
362 que se compone de 88 segmentos TCP (incluyendo conexión y desconexión).
363 \layout Subsubsection
368 En total se utilizan 106 paquetes IP.
369 \layout Subsubsection
374 En total se utilizan 106 frames ethernet.
378 \layout Subsubsection
383 GET /~luca/foro/index.php?module=faqs&accion=NuevaRespuesta&idpreg=1 HTTP/1.1
386 HTTP/1.1 200 OK (text/html)
389 GET /favicon.ico HTTP/1.1
392 HTTP/1.1 404 Not Found (text/html)
395 POST /~luca/foro/index.php?module=faqs&accion=guardarrespuesta HTTP/1.1
398 HTTP/1.1 200 OK (text/html)
401 GET /~luca/foro/index.php?module=faqs&accion=Mostrarrespuestas&idpreg=1 HTTP/1.1
404 HTTP/1.1 200 OK (text/html)
407 GET /~luca/foro/avatars/phpQe1MqS HTTP/1.1
410 HTTP/1.1 304 Not Modified
413 GET /~luca/foro/avatars/phpGifOBK HTTP/1.1
416 HTTP/1.1 304 Not Modified
419 GET /favicon.ico HTTP/1.1
422 HTTP/1.1 404 Not Found (text/html)
425 Total: 14 mensajes HTTP
426 \layout Subsubsection
433 index.php?module=faqs&accion=NuevaRespuesta&idpreg=1
435 : 10 (reutiliza conexión, incluye desconexión)
442 : 7 (reutiliza conexión, incluye desconexión)
445 Resto: 31 (incluye conexión y desconexión)
446 \layout Subsubsection
451 Total: 48 paquetes IP.
452 \layout Subsubsection
457 Total: 48 frames ethernet.
460 Análisis de la captura FTP
466 La captura fue realizada transfiriendo un archivo binario de 1.9 Mb, llamado
467 db4o-4.5-mono.tar.gz.
468 Para la transferencia se han intercambiado 16 mensajes FTP 8 response y
472 Lo primero que se recibe es el response del server dando su identificacion
474 Luego un request del comando USER y la respuesta del servidor diciendo
475 que se necesita password para dicho usuario.
476 El siguiente comando es PASS con el que se envia el password y recibimos
477 la respuesta de que estamos loggeados.
480 El cliente envía un SYST para saber el tipo de sistema que hay del otro
481 lado, a lo que el server responde UNIX Type: L8.
482 Luego se cambia el tipo de modo de transferencia con TYPE y a continuación
483 se hace un PORT para establecer un canal de comunicación.
486 Como último comando se envía RETR para traer un archivo, luego recibimos
487 una respuesta de que se estableció un canal binario y por último un response
488 cuando se completo la transferencia.
491 También se registraron 1346 paquetes FTP-DATA intercambiados durante la
492 transferencia del archivo.
493 Once de dichos paquetes correspondieron a paquetes de control conteniendo
494 TCP Previous segment lost.
495 El resto corresponden a envío de 1448 bytes de datos transferidos.
501 Lo primero que se observa son 3 segmentos para establecer la conexión (SYN
502 y ACK) entre un puerto alto (35631) y el puerto FTP del server.
503 Luego 2 paquetes para la autenticación de usuario y a continuación está
504 la negociación del puerto y el comando RETR usando 34 segmentos.
507 Sigue a continuación la transferencia del archivo entre el puerto ftp-data
508 del servidor y el puerto local 32985.
511 La transferencia consume 1466 paquetes, de los cuales tenemos algunos de
513 Hay 112 ACK, 5 paquetes TCP ACKed lost segment y 3 de TCP Window Update.
516 La comunicación termina con 11 segmentos TCP.
522 En total se utilizan 1516 paquetes IP.
528 En total se utilizan 1516 frames ethernet.
531 Análisis de la captura Telnet
534 Cálculo de eficiencia sobre la red