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)
42 \begin_inset LatexCommand \tableofcontents{}
55 El protocolo PPP es muy utilizado para establecer una comunicación entre
56 2 redes (routers), ya sea entre LANs o entre una LAN y WAN u otras redes
58 Incluso es útil para comunicar un sólo host a una red distante (donde no
59 sería viable tender un cable o utilizar un medio inalámbrico).
60 Al poder ser montado sobre líneas telefónicas conmutadas, este protocolo
61 fue (y es) muy utilizado para proveer acceso a internet.
68 \begin_inset Float figure
75 \begin_inset LatexCommand \label{cap:Diagrama-de-estados-ppp}
79 Diagrama de estados de una conexión PPP
92 Lo primero que debe hacer el protocolo es establecer una conexión física
93 entre las dos puntas de la comunicación, para esto debe discar el número
94 si se utiliza sobre una línea telefónica conmutada, para establecer el
96 Una vez establecido el canal, empieza a actuar el LCP (Link Control Protocol)
97 que negocia, enviando frames PPP, los parámetros de la conexión.
98 Una vez acordados estos parámetros, puede realizarse una etapa de autenticación
99 , para verificar la identidad de las puntas y así permitir o no que la comunicac
101 Finalmente, si todo resultó bien, se envía una serie de paquetes NCP (Network
102 Control Protocol) para configurar la capa de red (como la dirección IP,
103 si se quisiera utilizar el protocolo TCP/IP en dicha capa).
106 En este momento las dos puntas de la conexión están comunicadas y pueden
107 realizar todas sus tareas como si estuvieran conectadas en una LAN.
110 Un vez finalizado, se procede prácticamente de forma inversa a como se estableci
111 ó la conexión para liberarla.
112 Primero se libera la IP a través del procotocolo NCP, luego se libera el
113 enlace cerrando la conexión de la capa LCP y finalmente se cierra la conexión
114 física (se corta el módem), si fuera necesario.
117 Se puede ver un diagrama de estados de este proceso en la figura
118 \begin_inset LatexCommand \vref{cap:Diagrama-de-estados-ppp}
128 Entre las cosas que se pueden configurar (negociando a través del protocolo
129 LCP) está el tamaño de la cabecera del frame (ya que los campos
137 generalmente son fijos y pueden evitarse, el campo
141 puede ser de 1 o 2 bytes y el
145 de 2 o 4) y el máximo tamaño del
150 Estos parámetros se establecen con valores por omisión para poder ser negociado
151 s luego con el protocolo LCP.
154 El protocolo NCP es muy específico sobre qué protocolo de red se quiera
155 negociar, por lo que es muy difícil hablar en términos generales de él.
156 Para el caso más común, donde se configura una capa de red IP, se utiliza
157 el protocolo IPCP (IP Control Protocol) cuya tarea se limita prácticamente
158 a la asignación de la IP (aunque puede negociar compresión de cabeceras
160 Hay también extensiones, como la extensión para configurar servidores de
161 nombre (definido en la RFC 1877
162 \begin_inset Quotes eld
165 PPP Internet Protocol Control Protocol Extensions for Name Server Addresses
166 \begin_inset Quotes erd
172 Configuración de los routes sobre línea dedicada
173 \layout Subsubsection
178 Lo primero que hay que hacer si utilizamos un modem sobre una línea telefónica
179 conmutada, es establecer el canal de la capa física.
180 Esto significa que una de las puntas debe discar el número de la otra y
181 establecer el canal utilizando algún programa de comunicación que permita
190 , con el que podemos hacerlo utilizando la combinación de teclas
197 Con el canal establecido, ejecutamos en ambas puntas el comando:
200 pppd -detach <IP local>:<IP remota> /dev/ttyS<N> <baudios> &
207 es la IP que se usará en la punta donde se ejectuta el comando,
215 el número de puerto serie (empezando de 0, que equivaldría al puerto más
216 conocido como COM1) y
220 la velocidad en baudios del puerto serie.
221 Recordemos que estamos usando como NCP al protocolo IPCP, para establecer
225 Esta es una forma muy precaria y no autenticada de establecer la conexión
227 La forma correcta sería dejando que una de las puntas actúe como
235 Técnicamente no es un servidor, ya que no existe tal cosa en el protocolo
236 PPP (en el que ambas puntas son pares), pero suele utilizarse este término
237 para la punta que recibe las llamadas, las atiende y asigna IPs.
242 PPP, encargándose de atender a la llamada entrante automáticamente, autenticand
243 o y asignando la IP a la otra punta, pero esta configuración es bastante
244 más compleja y poco realizable en el laboratorio.
245 \layout Subsubsection
247 Sin modems (null modems)
250 En ambas puntas de la conexión via null modem hay que ejecutar el siguiente
254 pppd -detach crtscts lock <IP local>:<IP remota> /dev/ttyS<N> <baudios>
262 es la IP que se usará en la punta donde se ejectuta el comando,
270 el número de puerto serie (empezando de 0, que equivaldría al puerto más
271 conocido como COM1) y
275 la velocidad en baudios del puerto serie.
276 Recordemos que estamos usando como NCP al protocolo IPCP, para establecer
280 Esto no establece ninguna tabla de ruteo, por lo que hay que cargarlas a
281 mano en caso de ser un router o de querer especificar un
285 en alguna de las puntas.
286 También es probable que haya que configurar los parámetros del puerto serie
291 , de manera tal que ambas puntas tenga los mismos parámetros (como paridad,
299 \begin_inset Float figure
306 \begin_inset LatexCommand \label{cap:Diagrama-de-la-red}
314 \begin_inset Graphics
315 filename diagrama.eps
324 Las tablas de ruteo se adjuntan en el Anexo.
325 Puede verse un diagrama de la red con sus respectivos routers y sus interfaces
327 \begin_inset LatexCommand \vref{cap:Diagrama-de-la-red}
334 Tablas de ruteo (simulación)
338 \begin_inset Float figure
345 \begin_inset LatexCommand \label{cap:Diagrama-de-la-simulacion}
349 Diagrama de la simulación
353 \begin_inset Graphics
354 filename red_labo.eps
363 Las tablas de ruteo de la simulación se adjuntan en el Anexo.
364 Puede verse un diagrama de la red con sus respectivos routers y sus interfaces
366 \begin_inset LatexCommand \vref{cap:Diagrama-de-la-simulacion}
373 Análisis de la captura HTTP
376 Registro de un nuevo usuario
377 \layout Subsubsection
382 Requirió para cargar el
386 16 mensajes HTTP, 8 GET y 7 respuestas 200 (OK) y 1 404 (NOT FOUND), correspond
387 ientes a dichos mensajes.
388 Los 8 GET fueron para pedir los siguientes archivos:
420 (que devolvió NOT FOUND).
421 Para la página específica de registro de un usuario (el formulario) solo
422 requirió 2 mensajes HTTP (GET y su respuesta) ya que las imágenes ya las
423 tenía en el cache el navegador.
424 Una vez presionado el botón de ENVIAR se observan 4 mensajes más HTTP,
425 primero un POST para enviar los datos del formulario al servidor, luego
426 su correspondiente respuesta 200 (OK).
427 Finalmente se vuelve a cargar el
431 para lo que se utilizan 2 mensajes más (GET y su respuesta 200).
432 Nuevamente observamos que como las imágenes están en el cache, no se vuelven
434 \layout Subsubsection
439 Lo primero que se observa son 3 segmentos para establecer la conexión (SYN
440 y ACK), luego por cada mensaje HTTP se observa al menos 2 segmentos TCP,
441 el que lleva el mensaje HTTP y el ACK que confirma la recepción de dicho
443 Además, si el mensaje HTTP es mayor a algo menos de 1500 bytes (tamaño
444 del MTU de ethernet), se observa la fragmentación y por cada fragmento
445 se generan 2 nuevos segmentos TCP (nuevamente uno que lleva el fragmento
446 de mensaje HTTP y el ACK correspondiente).
447 Finalmente se observan 4 segmentos TCP para la desconexión (FIN y ACK).
450 Para obtener el index.php y sus imágenes se observa que se hace todo en la
451 misma conexión, pero al estar ociosa durante un tiempo el servidor http
452 pide la desconexión y cuando se va a cargar la siguiente página vuelve
453 a iniciar una nueva conexión.
456 En total se observaron 4 conexiones:
459 index.php+imagenes: 53 segmentos (incluyendo 3 segmentos de conexión y 4
463 index.php?NuevoUsuario: 27 segmentos (incluyendo 3 segmentos de conexión
467 index.php?GuardarUsuario+index.php: 97 segmentos (incluyendo 3 segmentos de
468 conexión y 4 de desconexión)
472 \layout Subsubsection
477 Al ser el protocolo IP el transporte de los segmentos TCP, se observa que
478 para cada segmento, hay un paquete IP que lo transporta (incluyendo los
479 segmentos de control, como SYN y ACK).
480 No hay otro tipo de paquete IP que no este asociado a un segmento TCP.
483 Cantidad de paquetes IP: 177
484 \layout Subsubsection
489 Al ser el protocolo ethernet el transporte de los paquetes IP, se observa
490 que para cada paquete, hay un frame ethernet que lo transporta.
491 En esta actividad no se aprecia otro tipo de frame ethernet que no este
492 asociado a un paquete IP.
495 Cantidad de frames ethernet: 177
498 Nueva pregunta de la FAQ
501 A partir de ahora sólo enumeraremos la cantidad de
505 y mencionaremos si hay alguna diferencia con la actividad anterior, ya
506 que la mecánica es muy similar.
507 \layout Subsubsection
512 12 mensajes en total:
515 GET /~luca/foro/index.php?module=faqs&accion=AgregarPregunta HTTP/1.1
518 HTTP/1.1 200 OK (text/html)
521 GET /favicon.ico HTTP/1.1
524 HTTP/1.1 404 Not Found (text/html)
527 POST /~luca/foro/index.php?module=faqs&accion=guardarpregunta HTTP/1.1
530 HTTP/1.1 200 OK (text/html)
533 GET /~luca/foro/index.php?module=faqs HTTP/1.1
536 HTTP/1.1 200 OK (text/html)
539 GET /~luca/foro/avatars/phpQe1MqS HTTP/1.1
542 HTTP/1.1 304 Not Modified
545 GET /favicon.ico HTTP/1.1
548 HTTP/1.1 404 Not Found (text/html)
549 \layout Subsubsection
556 index.php?module=faqs&accion=AgregarPregunta
558 se reutiliza una conexión previa así que no hay SYN y se utilizan 10 segmentos
559 TCP (incluyendo los 4 de la desconexión).
564 se reutilizó otra conexión diferente, por lo cual tampoco se presentan
565 los segmentos de conexión.
566 En ésta se utilizan 8 segmentos TCP (incluyendo la desconexión).
567 Finalmente el envío de los datos se realiza todo en una nueva conexión
568 que se compone de 88 segmentos TCP (incluyendo conexión y desconexión).
569 \layout Subsubsection
574 En total se utilizan 106 paquetes IP.
575 \layout Subsubsection
580 En total se utilizan 106 frames ethernet.
584 \layout Subsubsection
589 GET /~luca/foro/index.php?module=faqs&accion=NuevaRespuesta&idpreg=1 HTTP/1.1
592 HTTP/1.1 200 OK (text/html)
595 GET /favicon.ico HTTP/1.1
598 HTTP/1.1 404 Not Found (text/html)
601 POST /~luca/foro/index.php?module=faqs&accion=guardarrespuesta HTTP/1.1
604 HTTP/1.1 200 OK (text/html)
607 GET /~luca/foro/index.php?module=faqs&accion=Mostrarrespuestas&idpreg=1 HTTP/1.1
610 HTTP/1.1 200 OK (text/html)
613 GET /~luca/foro/avatars/phpQe1MqS HTTP/1.1
616 HTTP/1.1 304 Not Modified
619 GET /~luca/foro/avatars/phpGifOBK HTTP/1.1
622 HTTP/1.1 304 Not Modified
625 GET /favicon.ico HTTP/1.1
628 HTTP/1.1 404 Not Found (text/html)
631 Total: 14 mensajes HTTP
632 \layout Subsubsection
639 index.php?module=faqs&accion=NuevaRespuesta&idpreg=1
641 : 10 (reutiliza conexión, incluye desconexión)
648 : 7 (reutiliza conexión, incluye desconexión)
651 Resto: 31 (incluye conexión y desconexión)
652 \layout Subsubsection
657 Total: 48 paquetes IP.
658 \layout Subsubsection
663 Total: 48 frames ethernet.
666 Análisis de la captura FTP
672 La captura fue realizada transfiriendo un archivo binario de 1.9 Mb, llamado
673 db4o-4.5-mono.tar.gz.
674 Para la transferencia se han intercambiado 16 mensajes FTP 8 response y
678 Lo primero que se recibe es el response del server dando su identificacion
680 Luego un request del comando USER y la respuesta del servidor diciendo
681 que se necesita password para dicho usuario.
682 El siguiente comando es PASS con el que se envia el password y recibimos
683 la respuesta de que estamos loggeados.
686 El cliente envía un SYST para saber el tipo de sistema que hay del otro
687 lado, a lo que el server responde UNIX Type: L8.
688 Luego se cambia el tipo de modo de transferencia con TYPE y a continuación
689 se hace un PORT para establecer un canal de comunicación.
692 Como último comando se envía RETR para traer un archivo, luego recibimos
693 una respuesta de que se estableció un canal binario y por último un response
694 cuando se completo la transferencia.
697 También se registraron 1346 paquetes FTP-DATA intercambiados durante la
698 transferencia del archivo.
699 Once de dichos paquetes correspondieron a paquetes de control conteniendo
700 TCP Previous segment lost.
701 El resto corresponden a envío de 1448 bytes de datos transferidos.
707 Lo primero que se observa son 3 segmentos para establecer la conexión (SYN
708 y ACK) entre un puerto alto (35631) y el puerto FTP del server.
709 Luego 2 paquetes para la autenticación de usuario y a continuación está
710 la negociación del puerto y el comando RETR usando 34 segmentos.
713 Sigue a continuación la transferencia del archivo entre el puerto ftp-data
714 del servidor y el puerto local 32985.
717 La transferencia consume 1466 paquetes, de los cuales tenemos algunos de
719 Hay 112 ACK, 5 paquetes TCP ACKed lost segment y 3 de TCP Window Update.
722 La comunicación termina con 11 segmentos TCP.
728 En total se utilizan 1516 paquetes IP.
734 En total se utilizan 1516 frames ethernet.
737 Análisis de la captura Telnet
740 Se realizó la captura al inicio de una conexión mediante telnet al servidor
741 donde se encontraba el archivo RFC792 al cual se le modificaron 5 líneas
742 (una en cada hoja) se lo guardó y luego se desconecto del servidor cerrando
749 Se contaron en total 717 mensajes telnet, donde en su mayoría contenían
750 cada uno de ellos, un caracter correspondiente a una tecla presionada y
751 en algunas ocasiones líneas completas transmitidas por el servidor hacia
753 Tambíen se puede notar que los primeros mensajes pertenecen a la negociación
754 del protocolo e intercambio de parámetros.
760 Como en los protocolos anteriores se puede observar que se utilizan 3 segmentos
761 para establecer la conexión (SYN, ACK), y que todos los mensajes telnet
762 van montados en un segmento TCP.
763 Por lo tanto tendremos tantos segmentos TCP como mensajes de telnet haya
764 sumando además los segmentos TCP de control, en total 1005 segmentos fueron
772 Cada segmento TCP va acompañado por un paquete IP, en total 1005 paquetes
779 Analogamente al caso anterior, podemos observar 1005 frames ethernet.