Para realizar el despliegue de una aplicación Web necesitamos emplear diferentes tecnologías con las que trabajaremos a lo largo de curso. En este bloque vamos a hacer una introducción a ellas y mostraremos su relación.

Antes de comenzar vamos a echar un vistazo general a los fundamentos de la web. A la hora de deplegar una aplicación web debemos atender a una serie de conceptos: direcciones IP, puertos, certificados SSL, nombres de dominio, etc. Para situar gran parte de las tecnologías y servicios debemos conocer cómo funcionan estas aplicaciones.

Una aplicación web se basa en una arquitectura cliente-servidor que funciona en Internet. Un cliente hace una petición y un servidor le responde a través de una red de datos.

Internet es una red unida de muchas redes interconectadas. A la hora de interconectar redes nos encontramos con el problema de tener diferentes tipos de red, diferentes dispositivos de red, diferentes equipos, etc. Para simplificar el problema, las redes se divididen en un conjunto de capas, de modo que cada capa tiene unas funciones más o menos delimitadas. Así se reduce la complejidad del diseño y de las aplicaciones que se utilicen.

Flujo de datos entre dos hosts

Para estudiar la arquitectura de una red podemos dividirla en diferentes capas separando las funcionalidades implicadas entre unas y otras: los protocolos definidos en cada capa que hacen posible que los diferentes dispositivos se comuniquen entre si. Tenemos dos modelos principales que nos facilitan el estudio de la arquitectura de una red. El modelo OSI y el modelo TCP/IP.

Modelos OSI y TCP/IP

Internet funciona mediante el protocolo TCP/IP efectuando conexiones desde clientes hacia servidores. Cada host en Internet se identifica mediante una dirección IP y para conectar con las aplicación que deseamos dentro de ese host utilizamos los puertos que vienen definidos en los procolos de transporte:

Pila de protocolos TCP/IP

Además, cada vez que realizamos una conexión con un host remoto, nuestra petición se enviará en un paquete de datos a través de un sistema de redes intrerconectadas mediante enrutadores y otros dispositivos de red.

Encapsulación de datos a través de las diferentes capas

A la hora de configurar las herramientas necesarias para desplegar una aplicación en este curso, necesitamos conocer y trabajar con algunos protocolos:

• capa de aplicación: HTTP, HTTPS, TLS, FTP, DNS, SSH …
• capa de transporte: TCP y UDP
• capa de red: IP

Podemos estudiar la información transmitida por una red con un analizador de paquetes (p.e. Wireshark)

Podemos entender un nombre de dominio como el nombre con el que identificamos a un host dentro de Internet. Comohemos visto en el punto anterior, todos los hosts en internet se referencian mediante una dirección definida por el protocolo IP. (p.e. 217.43.134.76)

El Sistema de Nombres de Dominio es a Internet lo que la guía telefónica es a la red de teléfonos. Es un servicio al cual cada cliente web le puede preguntar por la dirección IP que está vinculada a un nombre de dominio.

Existen dos formas de resolver el nombre de dominio:

• Mediante fichero local: /etc/hosts/ en los sistemas Linux o C:Windows/System32/drivers/etc/hosts en los sistemas Windows.
• Mediante el uso de los Servidores DNS asignados a nuestra interfaz de red. Si utilizamos el protocolo DHCP se nos asignan automáticamente junto con nuestra IP y la máscara de red.

El proceso de resolución siempre es el mismo:

1. Se consulta el fichero hosts en busca del nombre de dominio
2. Si no está se realiza una petición al servidor DNS asignado

La desventaja de almacenar las parejas nombre-direccion IP en un fichero local es obvia: al ser un fichero estático en el momento en que la cantidad de nombres crece se hace más difícil mantenerla. Se puede plantear su uso para los nombres de dominio de una pequeña red local.

Es la dirección de un hosts escrita en lenguaje conocido: palabras.

Si introducimos en un navegador web la direccion: https://www.debian.com estamos indicando lo siguiente:

1. Los puntos separan dominios y subdominios, empezando de derecha a izquierda tendrás dominios de primer nivel (TLDs) y dominios de segundo (SLD), tercer, etc. Cada nivel de dominio es un subdominio del nivel superior:
   • org es el dominio de primer nivel (TLD)
   • debian es un subdominio, en este caso dominio de segundo nivel bajo org, que identifica al nombre de la organización o al nombre de la empresa.
   • www es un subdominio, en este caso dominio de tercer nivel bajo debian, que identifica al servidor web donde está colgada la página web, esto es, identifica el host exacto que aloja la página web.
2. http:// es el protocolo de hypertexto que permite la correcta visualización de la página web en el navegador. Es lo que el navegador autocomplementa en caso de no estipular uno propio en la barra de direcciones URL con en nombre de dominio.

Otro ejemplo: https://en.wikipedia.org

• org: TLD, dominio de nivel superior
• wikipedia: SLD, dominio de segundo nivel, o subdominio del TLD org
• en: dominio de tercer nivel, o subdominio de wikipedia
• en.wikipedia.org: nombre de dominio

Al nombre completo terminado en . se le conoce como FQDN (fully qualified domain name).

Entre los dominios de primer nivel o TLD (Top Level Domain) se encuentran: .com, .org, .net, .es, .edu, .gov, etc. Podemos consultar una lista aquí. Estos dominios se almacenan en la zona raíz del DNS.

Podríamos decir que los diferentes tipos de servidores DNS se clasifican en privados y públicos.

• Los privados son los servidores DNS que mantienen diferentes compañías, como los proveedores de internet (ISP).
• Los públicos son aquellos que de forma gratuita ponen algunas empresas. Por ejemplo, en Diciembre del 2009 Google puso a funcionar sus propios servidores públicos, contribuyendo a que internet sea más rápido. (p.e. 8.8.8.8 y 8.8.4.4).

Algunos de los servicios DNS públicos son Open DNS, gestionado actualmente por Cisco y Google Public DNS.

Por otro lado podemos encontrar 4 tipos de sercicios dentro del sistema:

• Solucionador DNS recursivo (Recursive Resolver): es el tipo de servidor que nos va a proveer de la respuesta deseada. Suele ser el servidor asignado a tu interfaz de red. Utiliza consultas a diferentes servidores hasta que encuentra al información. Si estuvieramos hablando de un biblioteca, sería el bibliotecario.

• Servidor DNS raíz: es el primer paso para traducir (solucionar) los nombres de servidor legibles en direcciones IP. Conoce las direcciones de los servidores de los servidores de nombres TLD. Se puede comparar a un índice en una biblioteca que apunta a diferentes estanterías de libros.

• Servidor DNS TLD: el servidor de dominio de nivel superior (TLD) es el encargado de conocer donde están los subdominios del TLD buscado. Se puede comparar con una estantería de libros en una biblioteca. Es el paso siguiente en la búsqueda de una dirección IP específica y aloja la última parte de un nombre de dominio (p.e. ejemplo.com, el servidor TLD es “com”).

• Servidor DNS autoritativo: se puede interpretar como un diccionario en una estantería de libros, en el que se puede consultar la definición de un nombre específico. El servidor de nombres autoritativo es la última parada en la consulta del servidor de nombres. Si cuenta con acceso al registro solicitado, devolverá la dirección IP del nombre del servidor solicitado al recursor de DNS (el bibliotecario) que hizo la solicitud inicial.

1. A través de tu navegador quieres consultar la página web oficial de Debian escribiendo en la barra de direcciones la URL https://www.debian.org/
2. El navegador busca la información de las DNS del dominio debian.org.
3. Se busca la dirección IP en la caché del sistema operativo (en caso de que se haya buscado recientemente). Si no se encuentra se lanza una petición a las direcciones IP de nuestros servidores DNS predeterminados. Son los que hemos configurado en nuestra interfaz de red.
4. Estos servidores son los solucionadores recursivos. Revisan sus cachés y si no conocen la respuesta lanzan una petición a los servidores DNS raiz que son los servidores mas altos en la jerarquía DNS.
5. Los servidores DNS raiz conocen la ubicación de los Servidores DNS TLD y redirigen al solucionador hacia el servidor encargado del TLD que que estamos buscando. (Servidores DNS para .com en nuestro caso).
6. Los servidores DNS TLD gestionan los dominios TLD, en nuestro caso el dominio .com del que debian.com forma parte. Estos servidores dirigen al solucionador hacia el servidor DNS autoritativo necesario ya que no conocen las direcciones IP. En nuestro caso hacia el servidor autoritatido que conoce debian.com.
7. En última instancia los servidores autoritativos son los que conocen toda la información referente al nombre de dominio completo, el cual se le indicará al solucionador que nos devolverá la IP requerida.

• Cabe destacar, que en el caso de consultas relativas a subdominios de tercer nivel, tales como 'www.debian.com o blog.debian.com, se añade un servidor autoritativo más a la cadena, encargado de conocer las direcciones IP de los subdominios.

El Sistema de Nombres de Dominio al igual que otras tecnologías tiene su propio formato de mensajes. Este formato es definido mediante el protocolo DNS.

El paquete DNS viaja normalmente en el protocolo UDP de transporte, debido a que la información de DNS es bastante ligera y UDP es más rápido que TCP.

• Campo Preguntas: La sección de preguntas (questions) contiene un campo del nombre que se está solicitando.

• Campo Respuestas: En una respuesta desde un servidor DNS, la sección de respuestas contiene las entradas asociadas al nombre que se solicitó originalmente. Puede tener múltiples entradas, debido a que un nombre de dominion puede tener múltiples IPs asociadas.

Cuando queremos acceder a una página web desde el navegador indicando su nombre (www.google.com), se envía un paquete DNS que preguntará por la dirección IP correspondiente a ese nombre. El servidor DNS que tengamos asignado, nos responderá con la dirección IP, y acto seguido podremos conectarnos a esa dirección.

Campos de la cabecera del paquete DNS

La cabecera de un paquete DNS ocupa 12 bytes:

• Los primeros 16 bits corresponden al ID de la consulta
• Los siguientes 16 bits son parámetros del paquete
  • Campo QR: Es un Flag que indica consulta (0) o respuesta (1)
  • El resto de códigos y flags indican otros parámetros del paquete
• Total Questions: Un entero de 16 bits que indica el nº de entradas de la sección “preguntas”
• Total Answers: Un entero indicando el numero de respuestas en la sección “respuestas”
• Cantidad de respuestas en la sección “autoridad”
• Cantidad de respuestas en la sección “registros adicionales”

Las aplicaciones web siguen lo que se conoce como una arquitectura cliente-servidor. Siguiendo esta misma filosofía, existe la programación por capas, que consiste en una arquitectura en la que el principal objetivo es la separación de las diferentes capas lógicas de una aplicación (presentación, negocio y datos). Por ello, la arquitectura más conocida es la arquitectura de 3 capas, en la que la estructura de la aplicación se separa en tres niveles. Aunque no siempre las 3 capas están separadas físicamente, es conveniente que lo estén lógicamente. La separación física vendrá dada por la propia naturaleza de la aplicación (aplicación web) o bien por las propias necesidades en cuanto a rendimiento de la misma (uno o más equipos para dar soporte a la capa de negocio o datos).

• Capa de presentación Es la capa que ve el usuario. Presenta la aplicación al usuario, le permite interactuar con el mismo y le muestra la información que éste solicita. En definitiva es lo que se conoce como interfaz de usuario.

• Capa de negocio En esta capa se encuentra toda la lógica de la aplicación y será donde se realicen todos los procesos de tratamiento de la información obtenida en la capa de datos y cuyos resultados se muestran al usuario mediante la capa de presentación.

• Capa de datos En esta capa residen los datos. En ella se encuentran los SGBD y reciben peticiones para acceder o escribir datos desde la capa de negocio.

En aplicaciones de tamaño medio es bastante habitual encontrar un modelo lógico basado en 3 capas pero físicamente distribuido solamente en 2. En estos casos lo habitual será que el usuario cargue la capa de presentación en su propio equipo (ya sea ejecutando la aplicación o cargando la web en su navegador) y que las capas de negocio y datos se encuentren en otro equipo remoto (el servidor). A medida que la aplicación se haga más exigente las capas de negocio y datos pueden separarse en diferentes equipos (normalmente físicamente más cerca) y según se exige un mayor rendimiento se pueden añadir equipos a cualquiera de estas dos capas.

Existen dos arquitecturas muy utilizadas conocidas por sus acrónimos:

LAMP:

• Linux: Sistema operativo.
• Apache: Servidor web.
• MySQL: Gestor de bases de datos.
• PHP: Lenguaje interpretado PHP, aunque a veces se sustituye por Perl o Python.

WISA:

• Windows: Sistema operativo.
• Internet Information Services: servidor web.
• SQL Server: gestor de bases de datos.
• ASP o ASP.NET como lenguaje para scripting del lado del servidor.

Un cliente es un programa (p.e. navegador Web) que se ejecuta en el ordenador, teléfono u otro dispositivo local del usuario, y se conecta a un servidor cuando lo necesita. Necesita acceso a información o funcionalidades que están disponibles en el cliente y no en el servidor: introducción o selección de datos, tareas que no requieren transmisión de datos, etc.

En el desarrollo web, el “lado del cliente” hace referencia a todo lo que en una aplicación web se muestra o tiene lugar en el cliente (dispositivo del usuario final). Esto incluye lo que ve el usuario, como texto, imágenes y el resto de la interfaz de usuario, junto con cualquier acción que una aplicación lleve a cabo en el navegador del usuario.

El lado del cliente también se conoce como frontend, aunque estos dos términos no son lo mismo. El lado del cliente hace referencia únicamente al lugar en el que se ejecutan los procesos, mientras que el frontend hace referencia a los tipos de procesos que se ejecutan en el lado del cliente.

Un servidor es una aplicaicón informática (p.e. servidor Web) que se ejecuta habitualmente en un ordenador remoto (ordenador servidor), accesible desde un ordenador o dispositivo movil local de un usuario. Hay operaciones que se deben ejecutar en el servidor ya que requieren acceso a información o funcionalidades que no están disponibles en el cliente, o porque la ejecución de esas tareas serían lentas o inseguras en el cliente. Por ejemplo: representación de páginas web dinámicas, la interacción con las bases de datos, la autenticación de identidades, etc.

Al igual que “frontend” y “lado del cliente”, backend también es un término para los procesos que tienen lugar en el servidor, aunque backend solo hace referencia a los tipos de procesos y lado del servidor hace referencia a la ubicación en la que se ejecutan los procesos.

El Protocolo de transferencia de archivos (en inglés File Transfer Protocol o FTP) es un protocolo de red para la transferencia de archivos entre sistemas conectados a una red TCP (Transmission Control Protocol), basado en la arquitectura cliente-servidor.

Un servidor FTP es un programa que ofrece acceso a ficheros y permite enviarlos ante la solicitud de un cliente FTP.

Algunos ejemplos de aplicaciones:

• vsFTPd: Servidor FTP para linux ligero y seguro, siendo el servidor por defecto en varias distribuciones, licencia GPL.
• pureFTPd: Servidor seguro para linux, con licencia BSD.
• proFTPd: Servidor muy configurable para linux, licencia GPL.
• Filezilla Server: Servidor multiplataforma con interfaz gráfica, licencia GPL.

Un servidor Web es una aplicación informática que acepta peticiones a través del protocolo HTTP, o su variante segura HTTPS. Esta comunicación se inicia desde una aplicación cliente (un navegador web) el cual solicita acceso a una página web u otros recursos usando HTTP, y el servidor le responde con dicha información.

Algunos ejemplos de aplicaciones:

• Internet Information Services: Servidor web de Microsoft, propietario.
• Apache Web Server: Servidor Web multiplataforma de código abierto, licencia Apache 2.0.
• Nginx: Servidor web de código abierto, licencia BSD, el más usado junto a Apache.
• OpenLiteSpeed: Versión de código abierto del servidor LiteSpeed.

Un servidor de bases de datos, al igual que el resto de servidores, es una aplicación informátia que ofrece acceso a bases de datos a otros programas u ordenadores basandose en un modelo cliente-servidor. Los SGBD normalmente ofrecen funciones de servidor, incluso siendo la única forma de acceso para algunos tipos de SGBD, como es el caso de MySQL.

Ejemplos de aplicaciones:

• MySql: el servidor de bases de datos más usado, mantenido por Oracle.
• MariaDB: fork del proyecto MySQL, cuando fue adquirido por Oracle. Licencia GPL.
• PostgreSQL: SGBD objeto-relacional, código abierto.
• SQLServer: SGBD de Microsoft, propietario.
• MongoDB: SGBD NoSQL, orientado a documentos, código abierto.

Un servidores de aplicaciones es un tipo de servidor que se encarga de ejecutar ciertas aplicaciones más complejas que las que puede ejecutar un servidor web. Normalmente se apoyan en los servidores web, pero se encarga principalmente de la capa de negocio y del acceso a las bases de datos.

Ejemplos de aplicaciones:

• Apache Tomcat: Servidor de servlets de java, y JSP, código abierto.
• GlassFissh: Servidor de Java, mantenido por Eclipse Software Foundation, código abierto.

Los contenedores proporcionan una manera estándar de ejecutar código. Automatizan el despliegue de aplicaciones dentro de contenedores de software. Docker es un sistema operativo para contenedores. De manera similar a cómo una máquina virtual virtualiza (elimina la necesidad de administrar directamente) el hardware del servidor, los contenedores virtualizan el sistema operativo de un servidor.

Incluyen todo lo necesario para que el software se ejecute, incluidas bibliotecas, herramientas de sistema, código y tiempo de ejecución.

Ejemplos de aplicaciones:

• Docker
• Kubernetes

© 2024 Fernando Valdeón