Scribd Logo
Cargar

¡Te damos la bienvenida a Scribd!

  • 47 vistas

    Redes Practica1

    Cargado por

    Jhonny Palaguachi

    Copyright:

    © All Rights Reserved
    Descargue como PDF, TXT o lea en línea desde Scribd

    Redes Practica1

    Cargado por

    Jhonny Palaguachi
    47 vistas10 páginas

    Título original

    REDES-PRACTICA1

    Derechos de autor

    © © All Rights Reserved

    Formatos disponibles

    PDF, TXT o lea en línea desde Scribd

    ¿Le pareció útil este documento?

    ¿Este contenido es inapropiado?

    Copyright:

    © All Rights Reserved
    Descargue como PDF, TXT o lea en línea desde Scribd
    Descargar como pdf o txt
    47 vistas10 páginas

    Redes Practica1

    Cargado por

    Jhonny Palaguachi

    Copyright:

    © All Rights Reserved
    Descargue como PDF, TXT o lea en línea desde Scribd
    Descargar como pdf o txt
    de 10

    Práctica 1: IMPLEMENTACIÓN DE UN SERVIDOR

    WEB Y ANÁLISIS DEL PROTOCOLO HTTP


    UTILIZANDO WIRESHARK

    Tema: DISEÑO DE FUENTES DE ALIMENTACIÓN DE


    CORRIENTE CONTINUA:
    REGULADORES DE VOLTAJE INTEGRADOS

    Johnny palaguachi
    1 Universidad de Cuenca, Cuenca, Ecuador

    [email protected]

    Resumen. En esta práctica se realizó la instalación de un servidor apa-


    che2 en Ubuntu versión 20.04, se realizó una edición del archivo in-
    dex.hmtl para dar una apariencia y funciones personalizadas a nuestra
    página como una animación, un formulario, y la opción de subir archivos
    al servidor. Una vez que la instalación este correctamente realizada ac-
    cedemos a la página web del servidor por medio del navegador. Con la
    ayuda del programa Wireshark analizamos el protocolo HTTP y sus men-
    sajes mediante capturas de paquetes de interacción entre un cliente y un
    servidor web, en los mensajes de captura del wireshark logramos ver el
    protocolo por el cual interactuaban el cliente y el servidor, se capturo las
    peticiones del cliente tales como GET, PUT, HEAD, etc. Así como las
    respuestas que envía al servidor.

    Keywords: http, Apache2, Linux, cookies, telnet

    1 Marco Teórico

    HTTP (Hypertext Transfer Protocol) protocolo que permite la transferencia de datos a


    través de la web. Este protocolo se implementa desde 1991, y ha ido evolucionando
    hasta llegar a la versión más ampliamente conocida la 1.1. Al inicio de la historia el
    protocolo HTTP solo permitía realizar peticiones sin especificar el verbo, es decir solo
    se podían hacer peticiones GET con el pasar del tiempo se mejoraron las cosas y se
    agregó el soporte a algunos verbos como GET, POST y HEAD, se implementó los
    códigos de estado HTTP entre otras muchas mejoras. Lo que tienen en común todas
    2

    estas versiones es que tanto las respuestas como las peticiones se realizan a través de
    texto plano.

    HTTP 2

    HTTP/2 es un protocolo binario que conserva la misma semántica que el protocolo


    HTTP1.X busca resolver los defectos que tiene la comunicación a través TCP. Está
    basado en algunas de las ideas del protocolo SPDY, el cual actualmente se considera
    obsoleto pues se ha apostado completamente por el protocolo HTTP/2.
    Ventajas

    Multiplexed streams

    Provee los recursos en partes más pequeñas, pasando todos ellos a través de una misma
    conexión. Es decir, enviamos muchas peticiones y respuestas diferentes a través de una
    misma conexión, esto elimina congestiones causadas por muchas conexiones cuando
    se trata de descargar al mismo tiempo texto, fuentes e imágenes desde el servidor a su
    navegador.

    Server push

    Envía recursos a la cache del navegador sin que este los solicite reutilizando la conexión
    con el cliente, enviándole recursos que probablemente vaya a necesitar. Envía los ar-
    chivos de CSS, imágenes o fuentes antes de que el navegador haya interpretado el con-
    tenido HTML y los solicite, así cuando el navegador los necesita estos recursos están
    disponibles.

    Compresión de headers

    Cada solicitud enviada tiene una pequeña pieza de información adicional que son los
    encabezados HTTP o HEADERS, que describen cómo se comporta un navegador o un
    servidor.
    Todas las cabeceras se empaquetan en un solo bloque comprimido para ser enviados
    como una unidad. Una vez finalizada la transmisión, se decodifica el bloque de cabe-
    ceras del otro lado.

    Formato binario en lugar de texto

    Los protocolos binarios son más eficientes para interpretar, más compactos al ser trans-
    portados, son mucho menos propenso a errores comparados con los protocolos basados
    en texto, se definen hasta 4 formas de interpretar un mensaje, mientras tanto en HTTP/2
    solo existe una.
    La desventaja quizás es que el protocolo HTTP/2 no se usa a través de telnet, pero ya
    existen algunas herramientas que lo soportan.
    3

    HTTP 3
    HTTP/3 es el nombre oficial de la próxima versión de protocolo de comunicaciones
    que permite las transferencias en la web. Esta nueva versión tiene un cambio muy im-
    portante, pues será la que deje de utilizar por primera vez el protocolo TCP que hasta
    ahora se ha venido utilizando en el HTTP, y lo sustituirá un nuevo protocolo llamado
    QUIC, e inicialmente desarrollado por Jim Roskind en Google.

    El sustituto para este protocolo en HTTP/3 será QUIC, siglas que significan Quick UDP
    Internet Connections. En castellano, significa Conexiones UDP Rápidas en Internet.
    Está basado en otro viejo protocolo de los años 80 llamado UDP, y que a diferencia del
    TCP no requiere del intercambio continuo de información entre el emisor y el receptor
    del paquete de información. El protocolo de transferencia ya no se encarga de la inte-
    gridad de los datos, ese peso recaerá de cada aplicación que lo use.

    Vamos, que con UDP los paquetes se envían al receptor sin más, y el emisor no espera
    a que el receptor le diga si han llegado o no: los sigue enviando pase lo que pase, lo que
    hace que no haya garantías de que el receptor está recibiendo todos los paquetes. El
    protocolo se usa con frecuencia en emisiones en broadcasts e incluso en juego online,
    y Google ya ha integrado soporte en Chrome.

    2 Desarrollo de la Práctica.

    Instalación de Apache2 en Ubuntu 20.04

    Para instalar el servidor apache tenemos que actualizar el índice de paquetes locales
    mediante el siguiente comando.

    sudo apt update

    Después instalamos el paquete apache2

    -sudo apt install apache2

    Ilustración 1 instalación apache2 en terminal Ubuntu

    Ajustar el firewall
    4

    Es necesario modificar los ajustes de firewall para permitir el acceso externo a los puer-
    tos web predeterminados. Suponiendo que siguió las instrucciones de los requisitos
    previos, debería tener un firewall UFW configurado para que restrinja el acceso a su
    servidor.

    Para enumerar los perfiles de aplicación ufw utilizamos el comando:

    -sudo ufw app list

    Ilustración 2 perfiles de aplicación ufw

    Solo deberemos permitir el tráfico en el puerto 80:

    -sudo ufw allow 'Apache'

    Ilustración 3 permitir tráfico en el puerto 80.

    Para comprobar su funcionamiento se accedió a la página de destino predeterminada


    de Apache para confirmar que el software funcione correctamente mediante su direc-
    ción IP, para conocer la dirección IP se puede usar los siguientes comandos.
    -hostname –I
    5

    Para personalizar la página web del servidor se accedió a la siguiente dirección disco-
    local/var/ww/html y se modificó el archivo index.html

    La personalización que se hizo al archivo html fue agregarle un fondo, una animación,
    una función para subir archivos al sistema el código del archivo index.html se encuentra
    en ANEXOS.

    Ilustración 4 Pagina Web del servidor personalizada

    Interacción con el servidor y captura de mensajes mediante wireshark

    El navegador ingresa por medio de la dirección IP y usa el método GET para el


    archivo html. Al interceptar el mensaje podemos ver el código html completo del ar-
    chivo index.html cuyo título “Servidor Dumie”.
    6

    Ilustración 5 mensaje capturado de petición Get de parte del navegador.

    Al llenar el formulario y enviar al servidor pudimos interceptar el mensaje con los


    datos que llenamos en el formulario como el nombre y el correo electrónico, el men-
    saje del servidor es un Error 404 no Found, Debido a que no existe en el servidor
    una instrucción para responder ante el formulario.
    7

    Ilustración 6 Petición GET con los Datos del formulario y Error 404 No Found.

    Mediante la función de subir archivo de la página web que hemos personalizado


    subimos una imagen con el nombre “IMAGEN REDES” y al interceptar el mensaje
    logramos ver el método POST.

    Ilustración 7 Función de la página Web para subir archivo


    8

    Ilustración 8 Mensaje interceptado con el método POST

    También se hizo una conexión con el servidor mediante Telnet para esto se utilizo
    mediante el cmd de un equipo con Windows 10 los siguientes comandos.

    -telnet 192.168.0.106

    Una vez realizada la conexión se usó el método HEAD.

    -HEAD / HTTP/1.0

    Capturando con wireshark podemos ver la petición y respuesta del servidor.


    9

    El método PUT se usó mediante telnet con el siguiente comando y una respuesta de
    error 408 que se refiere que el servidor no respondió en el tiempo máximo de espera.

    3 Conclusiones

    - Un filtro en wireshark es importante es el de las peticiones realizadas. Estas


    peticiones las podemos conocer aplicando el filtro "http". De este modo, po-
    dremos conocer todos los GET y POST que hayan sido realizados durante la
    captura.

    - Cuando se inició la captura de datos del wireshark sin usar ningún tipo de filtro
    se pudo observar que en su mayoria los paquetes capturados eran del protocolo
    TCP

    - Analizando los paquetes de tipo Get se observa lo siguiente:o Request Met-


    hod: GET que nos dice que el método que se solicita es el GET o Request
    URI: / URI son las siglas en inglés de Uniform Resource Identifier (en español
    10

    identificador uniforme de recursos), que sirvepara identificar recursos en In-


    ternet.
    - Al analizar los paquetes de tipo Response y se observa lo siguiente: La versión
    de http que está solicitando es la 1.1 , Status code : 200 que significa que la
    solicitud ha tenido éxito, también existen errores como el 404 no Found en el
    metodo POST o la 408 Time request en el metodo PUT.

    Referencias

    - 1. Wireshark - Wikipedia, la enciclopedia libre. https://es.wikipe-


    dia.org/wiki/Wireshark.Accessed 2 Apr 2018

    - Form enctype. http://www.w3.org/TR/html4/interact/forms.html#h-


    17.13.4.2. Accessed 2 Apr 2018

    - (2018) Servidor HTTP Apache. https://www.domilo.co/estadisticas-del-inter-


    netcolombiano.Accessed 2 Apr 2018.

    También podría gustarte