Aplicaciones y arquitecturas web - teoria - p1-16

Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 16

Implantación, configuración y administración de

servidores web.
1.- Aplicaciones web.
La web es la parte más visible de Internet, pero no la única. Existen otros servicios, como el correo electrónico, grupos
de noticias, transferencia de archivos, terminal remoto.

En los orígenes del mundo web nos situábamos ante un entorno estático, con páginas en formato HTML que raramente
sufrían modificaciones o actualizaciones y en las que apenas había interacción con el usuario: páginas estáticas .

La Web 2.0 es la transición que se ha dado, a partir de finales de los 90 ( con Yahoo!, Amazon y e-bay como pioneros)
desde las aplicaciones tradicionales hacia aplicaciones que funcionan a través de la web y que abren nuevas
posibilidades Aplicaciones colaborativas, Redes sociales:publicación en comunidad de contenidos, comentarios, ….,
Compra electrónica, etc.
Está basada en páginas dinámicas: varían su contenido según las necesidades y aportaciones del usuario y según los
datos existentes en el servidor: la página que recibe el usuario se “crea” a propósito para él, no existía previamente
Involucra el uso de Bases de datos, perfiles de usuarios, etc
Hoy día a la web 2.0 también se la suele denominar web social. Dado que en ella los usuarios han dejado de ser usuarios
pasivos, meros receptores de contenidos, y han pasado a formar parte activa de la web, creando contenido y conocimiento
(blogs, wikis, redes sociales y otros servicios en la nube, como almacenamiento web o servicios de streaming). La web social
también se caracteriza por fomentar las relaciones sociales.

1.1 Aplicación web

◦ Aplicación distribuida proporcionada por un servidor web y utilizada por usuarios que se conectan
remotamente a través de un navegador web.
El usuario interactúa con un navegador (el cual proporciona la interfaz de usuario de la aplicación) que accede a
los servicios y recursos que ofrece un servidor web. Esos servicios y recursos son generados previamente por
un programa o aplicación que responde a las acciones del usuario y que realiza la mayor parte del
procesamiento, si no todo.
La aplicación web se sustenta en la consulta a una base de datos donde se almacena la información.
Más ejemplos: gestores de contenido (Joomla, wordpress), buscadores, una tienda electrónica, redes sociales,
comercio electrónico, servicios de correo web,....

1.2.- Tipos de aplicaciones web.

Algunas aplicaciones web emulan las funcionalidad de aplicaciones de escritorio. Otras, por
su naturaleza, deben ser remotas y “centralizadas”: redes sociales, plataformas educativas
Establecer una clasificación de los tipos de aplicaciones web es una tarea compleja debido a la
dificultad existente para poder establecer algún parámetro en función del cual establecer dicha
clasificación, junto con la innumerable cantidad de aplicaciones existentes en el actual entorno web
2.0.
Algunos ejemplos genéricos:
• Página web Dinámica. Existen muchos lenguajes de programación que son la base para la mayoría de páginas web
dinámicas. Los que destacamos aquí son los lenguajes PHP y ASP. Estos lenguajes permiten una perfecta
estructuración del contenido. Por una parte crearíamos la estructura de las páginas web y por otra, almacenaríamos el
contenido en determinados archivos. A partir de ahí, crearíamos el código de llamada, que insertaría el contenido en la
propia página web estructurada. Este es el principio básico que siguen los lenguajes de programación. A partir de aquí
se desarrollan aplicaciones para poder gestionar el contenido a través de un panel de control.
• Portal (término obsoleto). Es un sitio web que en su página principal permite el acceso a múltiples secciones que, por
lo general, son foros, chats, cuentas de correo, buscador, acceso registrado para obtener ciertas ventajas, las últimas
noticias de actualidad, ¿Podría servir la “página web” del centro como ejemplo?
• Tienda virtual o comercio electrónico. Sitio web que publica los productos de una tienda en Internet. Permite la
compra on-line a través de tarjeta de crédito, domiciliación bancaria o transferencia bancaria en general. Ofrece al
administrador un panel de gestión para poder subir los productos, actualizarlos, eliminarlos,
• Página web con "Gestor de Contenidos". Se trata de un sitio web cuyo contenido se actualiza a través de un panel de
gestión por parte del administrador del sitio. Este panel de gestión suele ser muy intuitivo y fácil de usar. En aquellas
páginas web que requieran una actualización constante, se suele incorporar este panel de gestión para que la web pueda
controlarse día a día por parte del cliente. Ejemplos: Moodle, WordPress, Joomla, Drupal. Los tres últimos son
altamente configurables y permiten crear múltiples sitios web con distintos objetivos (Buscar temas y plugins de
Joomla)
Reflexiona
Cuando adquirimos un equipo informático nuevo, existen una serie de aplicaciones imprescindibles que es necesario instalar
junto con los drivers de nuestro equipo para poder empezar a utilizarlo. Entre estas aplicaciones encontramos aplicaciones
ofimáticas, antivirus, aplicaciones de mensajería, compresores, visualizadores, reproductores multimedia, conversores….
Ejemplos concretos? Alguna que conozcas que no encuadre en estas categorías?
Examinar sitio de “desarrolloweb”, un programador que desarrolla aplicaciones pequeñas y medianas en php, algunas de ellas
gratuitas
¿En algún momento te has parado a pensar qué cantidad de aplicaciones web hay disponibles en Internet para sustituir a las que
tienes pensado instalar en el equipo?
Esto nos lleva a pensar en las ventajas e inconvenientes; indica razonadamente, 3 ventajas y 3? inconvenientes de las
aplicaciones Web
Siguen operando en la actualidad páginas y sitios web puramente estáticos? Busca algunos ejemplos
Ejemplos de servicios de despliegue de páginas estáticas:
• Netlify
• Surge
• GitHub Pages
• GitLab Pages
• Firebase
• Vercel
• Neocities

2.- Aspectos generales del funcionamiento web


Internet, tal y como la conocemos hoy día, utiliza para su funcionamiento la arquitectura de protocolos TCP/IP. Lo
importante de TCP/IP es que permite la comunicación de equipos que están en diferentes redes a través de una arquitectura
flexible.

Los estándares WWW (W3C) especifican muchos de los mecanismos necesarios para construir un ambiente de aplicación de
propósito general, por ejemplo:
• Modelo estándar de nombres: todos los servidores, así como el contenido de la WWW se denominan según un
Localizador Uniforme de Recursos (Uniform Resource Locator: URL).
• Lenguajes y tecnologías estándar: todos los navegadores soportan un conjunto de formatos y tecnologías estándar,
por ejemplo HTML (Lenguaje de marcas de hipertexto), ECMAScript (JavaScript), CSS, .
• Protocolos estándar, HTTP: éstos permiten que cualquier navegador pueda comunicarse con cualquier servidor web.
El más comúnmente usado en WWW es HTTP (Protocolo de Transferencia de HiperTexto), que opera sobre el
conjunto de protocolos TCP/IP (Protocolo de Control de Transmisión / Protocolo de Internet).
• Contenido: a todos los contenidos en la WWW se les especifica un
determinado tipo, permitiendo de esta forma que los browsers
(navegadores) los interpreten correctamente. MIME (Multipurpose
Internet Mail Extensions )

Esta infraestructura permite a los usuarios acceder a una gran cantidad de aplicaciones y servicios de terceros. También permite
a los desarrolladores crear aplicaciones y servicios para una gran comunidad de clientes.
El esquema de funcionamiento de los servicios web requiere de tres elementos fundamentales:
1. Proveedor del servicio web, que es quien lo diseña, desarrolla e implementa y lo pone disponible para su uso, ya sea
dentro de la misma organización o en público.
2. Consumidor del servicio, que es quien accede al componente para utilizar los servicios que éste presta.
3. Agente del servicio, que sirve como enlace entre proveedor y consumidor para efectos de publicación, búsqueda y
localización del servicio.

2.1.- Funcionamiento general.


Como supondrás, cuando accedemos a un sitio web a través de un navegador web, el navegador web inicia una o más
comunicaciones con un sistema remoto y se produce un intercambio de paquetes que permite mostrar la página web. Veamos el
proceso:
1. El navegador realiza una petición de un recurso al servidor web (imagen, HTML, .).
2. El servidor web recibe la petición y la procesa. Procesar la petición en el servidor web puede significar dos cosas
diferentes:
◦ Servir un recurso estático, es decir, el contenido de un archivo almacenado en el disco del servidor.
◦ Ejecutar una aplicación en el servidor que genere contenido dinámico.
3. El navegador web recibe el contenido del servidor y es el encargado de mostrarlo al usuario final, a través de un
proceso conocido como renderizado. En el proceso de renderizado el navegador web convierte los datos recibidos en
información que el usuario puede ver en la pantalla de su ordenador. ¿Cómo se llama el motor de renderizado de
Firefox? ¿”Dónde” podemos averiguarlo?
4. Si para representar la página web el navegador necesita más recursos (imágenes, archivos CSS, .), los volvería a pedir
al servidor, siguiendo el proceso anterior.

HTTP es el protocolo que permite al navegador realizar una petición y al servidor generar una respuesta, y es importante
entenderlo antes de configurar un servidor web, pero si ha triunfado la web y ha llegado hasta donde está hoy día, es también
gracias a otros mecanismos:
• El sistema DNS, que permite traducir un nombre de máquina en una dirección IP. El sistema DNS es una base de datos
distribuida que nos permite acceder a una máquina remota a través de un nombre (como www.gnu.org o
www.debian.org).
• El uso de URLs (Uniform Resource Locator). Una URL es una nomenclatura pensada para poder nombrar recursos en
la red de forma sencilla, por ejemplo: http://www.gnu.org).
• Por el ingenio de muchos desarrolladores y desarrolladoras web que con HTML, CSS y JavaScript, y tecnologías del
lado del servidor, consiguen hacer páginas webs increíbles.

URL: De todos estos conceptos, el que vamos a revisar ahora es el de URL. Para entender una URL lo mejor es analizar un
ejemplo de URL y desglosarla en partes:
http://es.wikipedia.org/wiki/Localizador_de_recursos_uniforme
En la URL anterior aparecen las siguientes partes:
• Esquema. El esquema es donde pone http: y representa el protocolo usado para acceder al recurso. Los esquemas más
usados son http:, https: (protocolo HTTPS) y ftp: (protocolo FTP), aunque hay otros esquemas como tel: (para hacer
referencia a un número de teléfono), mailto: (para hacer referencia a un correo electrónico), y bastantes más.
• Nombre de máquina o FQDN. En este caso es es.wikipedia.org y hace referencia a la máquina a la que estamos
accediendo.
• Ruta hasta el recurso. En este caso sería /wiki/Localizador_de_recursos_uniforme, y hace referencia al camino a
seguir para llegar al recuso.
Si alguna URL necesita usuario y contraseña (por ejemplo, si usamos el esquema ftp), entonces podemos escribirlo de la
siguiente forma:
• ftp://[email protected]/mirror/Apache/: donde anonymous sería el nombre de usuario.
• ftp://anonymous:contraseñ[email protected]/mirror/Apache/: donde anonymous:contraseña son la combinación del
usuario y su contraseña separados por dos puntos.
Y por último, como se verá más adelante, si un protocolo se usa en un puerto diferente al puerto por defecto o estándar,
podemos usar el siguiente formato de URL:
• http://www.ejemplodedominio.com:8080/mirecurso; donde 8080 es el puerto que se usaría en este caso para acceder al
servicio remoto.

2.2.- El protocolo HTTP.


El protocolo permite realizar la transferencia de información entre un cliente web y un servidor web en Internet, dando lugar a
lo que hoy día se conoce como World Wide Web. Este protocolo ha pasado por varias versiones, desde la inicial 0.9 hasta la
actual 2.0 (comunicación en binario, más eficiente) . La versión más extendida actualmente es la versión 1.1 , pero la versión
2.0 se irá imponiendo poco a poco de forma natural. Está previsto el desarrollo de HTTP 3 sobre UDP

Veamos cuales son las características principales de la versión :


• Es un protocolo del nivel de aplicación, por lo que está destinado a que aplicaciones en sistemas diferentes se
comuniquen entre sí.
• Es un protocolo sin estado, no hay consciencia de las peticiones anteriores, simplemente se hace una petición de un
recurso y se obtiene el recurso.
• Las comunicaciones entre cliente y servidor web se hacen en formato texto plano: "legible" por un ser humano.
• No existe el concepto de sesión y no es necesario autenticarse para realizar la petición de un recurso.
Como puedes ver el protocolo es muy simple, por lo que cuando desarrollamos una aplicación web es necesario que cosas como
la autenticación sea implementada por la aplicación web, dado que el protocolo no provee de mecanismos para ello.

Veamos el funcionamiento de HTTP con mayor detalle: Cuando un cliente web (un navegador por ejemplo) accede a un
recurso, se sigue el siguiente procedimiento:
1. Un usuario accede a una URL, seleccionando un enlace de un documento HTML o introduciéndola directamente en el
campo correspondiente del cliente Web.
2. El cliente Web descodifica la URL, separando sus diferentes partes: el protocolo de acceso, la dirección DNS o IP del
servidor, el posible puerto opcional (el valor por defecto es 80) y el objeto requerido del servidor.
http://direccion[:puerto][path]
Ejemplo: http://www.miweb.com/documento.html

3. Se abre una conexión TCP/IP con el servidor, llamando al puerto TCP correspondiente. En ese momento, se realiza la
petición HTTP. Para ello, se envía el comando necesario (GET, POST, HEAD,...), la dirección del objeto requerido (el
contenido de la URL que sigue a la dirección del servidor), la versión del protocolo HTTP empleada y un conjunto
variable de información, que incluye datos sobre las capacidades del navegador (browser), datos opcionales para el
servidor, etc.
4. El servidor devuelve la respuesta al cliente. Consiste en un código de estado y el tipo de dato MIME de la información
de retorno, seguido de la propia información.
5. Se cierra la conexión TCP. Este proceso se repite en cada acceso al servidor HTTP. Por ejemplo, si se recoge un
documento HTML en cuyo interior están insertadas 2 imágenes y 1 vídeo, el proceso anterior se repite cuatro veces,
una para el documento HTML y tres más para los recursos (las dos imágenes y el vídeo).

Para entender mejor este proceso, veamos un ejemplo de comunicación entre un cliente web y navegador web. Supongamos
que en un navegador web ponemos la URL siguiente: http://www.rediris.es/rediris/. En este caso nuestro navegador se pondrá
en contacto con el sistema www.rediris.es y enviará una petición usando el método GET que tendrá el siguiente aspecto:
GET /rediris/ HTTP/1.1
Host: www.rediris.es
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://www.rediris.es/
Cookie: language=en
Connection: keep-alive
La petición anterior comienza indicando el método (GET), el recurso (/rediris/) y la versión del protocolo (). A continuación, el
navegador incluye varias cabeceras de petición (User-Agent, Accept, Cookie, .) que le permitirán al servidor web, y a una
potencial aplicación web que procese la petición , generar una respuesta más completa. El servidor responderá con una
respuesta que tendrá el siguiente aspecto:
HTTP/1.1 200 OK
Date: Thu, 11 May 2017 21:33:53 GMT
Server: Apache/2.2.3 (Red Hat)
Content-Location: index.html.en
Vary: negotiate,accept-language
TCN: choice
Last-Modified: Thu, 04 May 2017 10:03:20 GMT
Etag: "616903-22f3-54eafe1e9ea00"
Accept-Ranges: bytes
Content-Length: 8947
Set-Cookie: language=en; path=/; domain=rediris.es
Cache-Control: no-cache
Connection: close
Content-Type: text/html; charset=UTF-8
Content-Language: en
Lo anterior es solamente la cabecera de respuesta, que comienza por la versión del protocolo (), seguido de un código de
respuesta (200) y un texto que dependiendo del caso puede variar (en el caso del código 200 suele ser u OK o Document
follows). Después de esa primera parte, se incluyen varias cabeceras de respuesta (Date, Set-Cookie, Server, ...) con
información que el cliente web debe tener en cuenta. ¿Y dónde va la información? Justo después de terminar las cabeceras, el
servidor incluirá una línea vacía y, a continuación, el documento o recurso.

Cookies:
Una cookie es un pequeño texto introducido en el ordenador de un usuario por un cliente HTTP (navegador). Una
cookie contiene una o varias parejas nombre = valor, con información como las preferencias de un usuario,
contenidos de carros de la compra por Internet, identificadores de sesión, ... Las cookies se envían por medio de
una cabecera HTTP desde un servidor a un cliente y luego es devuelta por el cliente al servidor cuando éste se lo
solicita.
Algunos usos de las cookies son:
• Gestión de sesiones. Las cookies se usan para guardar datos relacionados con el usuario durante la
navegación, sobre todo cuando hay múltiples visitas. El servidor envía una cookie con un identificador de
sesión único. El cliente devolverá el identificador de sesión con cada petición posterior al servidor
(cesta de la compra).
• Las cookies también se emplean para indicar el permiso de los usuarios a conectarse a un sitio web. El
servidor envía primero una cookie con un identificador de sesión único. Los usuarios envían a continuación
sus credenciales y la aplicación web autentifica la sesión y permite el acceso de los usuarios a sus servicios.
• Personalización. Las cookies se utilizan para recordar la información sobre un usuario que ha visitado un
sitio web para poder mostrarle el contenido más relevante.
• Seguimiento. Las cookies pueden usarse para registrar los hábitos de navegación de los usuarios.

2.3.- Métodos y Códigos de estado HTTP.


Ahora que ya conocemos los fundamentos del
protocolo HTTP, vamos a profundizar un poco
más en él. Para empezar, veamos los principales
métodos usados para realizar una petición al
servidor web (HTTP 1.0).

• Método GET: se usa para obtener un recurso, y en general, no admite que el cliente web envíe datos al servidor. Si
queremos usar este método para enviar datos al servidor los datos deben formar parte del recurso solicitado, usando por
ejemplo una cadena de consulta (query string). Por ejemplo:
• Si ponemos la url http://www.estoesunejemplo.com/mipagina.php, se generaría una petición HTTP del estilo a
GET /mipagina.php HTTP/1.1.
• Si ponemos la url http://www.estoesunejemplo.com/mipagina.php?dato1=a&dato2=2, se generaría una
petición HTTP del estilo a GET /mipagina.php?dato1=a&dato2=2 HTTP/1.1. La diferencia con el anterior es
que se ha añadido una cadena de consulta que se procesará internamente por la aplicación web (en este caso
escrita en php) para generar el contenido de forma dinámica.

• Método POST: se usa para enviar datos al servidor, los datos no irán en el recurso solicitado (como es el caso del
query string), sino que se enviarán después de las cabeceras de petición (cabeceras, línea en blanco y a continuación los
datos). De esta forma, los datos enviados al servidor no se ven en la URL y quedan ocultos a los ojos del usuario. La
respuesta del servidor será también contenido que se podrá visualizar en el navegador (generalmente una página web).
• Método HEAD: permite obtener datos de un recurso sin que el servidor llegue a enviarlo al cliente. Se obtendría por
ejemplo la fecha de la última modificación de una imagen y su tamaño, lo cual es útil para mantener una caché en el
navegador con los contenidos descargados más habitualmente o más recientemente.
• HTTP 1.1 incorpora algunos métodos más (OPTIONS, DELETE, PUT, etc) . Método PUT: puede verse como el
comando inverso a GET. Nos permite escribir datos en el servidor o, lo que es lo mismo, poner un recurso en la URL
que se especifique. Si el recurso no existe, lo crea; en caso contrario, lo reemplaza. La diferencia con POST puede ser
algo confusa; mientras que POST está orientado a la creación de nuevos contenidos, PUT está más orientado a la
actualización de los mismos (aunque también podría crearlos).
• HTTP 2 no incluye métodos nuevos

Después de realizar una petición como las anteriores, sea el método que sea, el servidor generará una respuesta HTTP que
contendrá un código de estado de respuesta. El código de estado 200 OK ya se vio en el apartado anterior, pero existen otros
códigos importantes que debes conocer:
• 1XX: los códigos de estado en el rango de 100 son respuestas informativas.
• 100 Continue: significa que todo va bien por ahora y que el cliente debería seguir con la petición.
• 2XX: los códigos de estado en el rango de 200 son respuestas de éxito en la transferencia, por ejemplo:
• 200 OK: significa que la respuesta ha tenido éxito y generalmente implica que los datos van en la respuesta
(depende del método de la petición).
• 3XX: los códigos de estado en el rango de 300 son respuestas de redirección, el recurso ha cambiado de ubicación.
• 301 Moved Permanently: significa que un recurso se ha movido a otro sitio de forma permanente. El servidor
web incluye una cabecera llamada Location: con la nueva ubicación. El navegador realizará una petición a la
nueva ubicación de forma transparente al usuario.
• 302 Found: significa que un recurso se ha movido a otro sitio de forma temporal. El funcionamiento es similar
al 301.
• Otras respuestas relacionadas con la redirección y el cambio de ubicaciones son la 303 See Other, 307
Temporary Redirect y 308 Permanent Redirect. Tienen connotaciones ligeramente diferentes a los códigos
de estado 301 y 302, pero la idea es similar.
• 4XX: los códigos de estado en el rango de 400 son respuestas en las que se indica que hay un error en la petición del
cliente o que algo ha ido mal al procesarla. Veamos algunos ejemplos:
• 400 Bad Request: el servidor no entiende la petición quizás porque está mal formada.
• 401 Unauthorized: es necesario que el usuario se autentique para acceder al recurso y dicha autenticación a
fallado.
• 403 Forbidden: el acceso al contenido solicitado no está permitido.
• 404 Not Found: posiblemente el código de estado más conocido. El servidor responde con este código cuando
el recurso solicitado no existe o no puede ser encontrado.
• 5XX: los códigos de estado que están en el rango de 500 simbolizan que se ha recibido una petición correcta pero que
el servidor no ha podido completar la respuesta. Veamos algunos ejemplos:
• 500 Internal Server Error: generalmente significa que hay un error en la configuración del servidor y que no
se puede completar la respuesta.
• 502 Bad Gateway: suele indicar que el servidor al que se ha solicitado la petición actúa como una pasarela a
otro servidor, y el segundo servidor no ha respondido adecuadamente.
• 503 Service Unavailable: el servidor no está disponible en este momento.

Para saber más


Un simple navegador, como Firefox, o Chrome, es una herramienta muy potente para analizar las cabeceras que se envían y
reciben cuando se realiza una petición HTTP. Puedes ver como utilizar esta utilidad en Firefox (no hay que instalar nada, dado
que ya va incorporado), en el siguiente enlace: Como usar el monitor de red de Firefox.
Para empezar, puedes activarlo con la combinación de teclas Ctrl+Shift+I.
2.4.- Protocolo HTTP vs HTTPS.
El protocolo HTTPS (HTTP seguro) permite que la información viaje de forma segura entre el
cliente y el servidor, por la contra el protocolo HTTP envía la información en texto claro, esto
es, cualquiera que accediese a la información transferida entre el cliente y el servidor puede ver
el contenido exacto y textual de la información.
Para asegurar la información, el protocolo HTTPS requiere de certificados y siempre y cuando
sean validados la información será transferida cifrada. Pero cifrar la información requiere un
tiempo de computación, por lo que será perjudicado el rendimiento del servidor web. Así, ¿es
necesario que toda, absolutamente toda, la información sea transferida entre el cliente y servidor
de forma cifrada? A lo mejor solamente es necesario que sea cifrada la autenticación a dicha
información, por eso en algunas páginas web puede que el servidor esté configurado para que
en todo el dominio esté cifrada su información o simplemente el intento de acceso a la misma.
Un servidor web, como Apache, puede emitir certificados, pero puede que en algún
navegador sea interpretado como peligroso, esto suele ser debido a que los navegadores
poseen en su configuración una lista de Entidades Certificadoras que verifican, autentican y
dan validez a los certificados. ¿Tú, confiarías en un DNI que no fuese certificado por una
entidad de confianza como el Ministerio del Interior? Pues, lo mismo le pasa a los
navegadores, solamente confían en quien confían. Eso no quiere decir que no puedes crear
tus certificados en un servidor web, de hecho muchas empresas lo hacen, sobre todo para
sitios internos o externos en los que solamente puede acceder personal autorizado por la
propia empresa. Ahora si, si utilizas certificados mediante Apache en un sitio visible a través de Internet y accesible por
cualquier usuario, o bien eres una empresa o entidad en la que de por si confía el usuario o la imagen de la empresa o entidad
quedará muy mal parada, ya que lo más probable es que el usuario no aceptará la comunicación, por visionar en el navegador
un aviso de problema de seguridad.

El protocolo HTTPS utiliza cifrado sobre SSL/TLS que proporcionan autenticación y privacidad. Entonces, si necesitas que la
información viaje cifrada debes emplear el protocolo HTTPS, en caso contrario el protocolo HTTP. Hay que dejar claro que la
utilización del protocolo HTTPS no excluye ni impide el protocolo HTTP, los dos pueden convivir en un mismo dominio.
Bien, pero, ¿cómo funcionan? Más o menos hemos visto ya el funcionamiento pero vamos a revisarlo para entender la
diferencia con HTTPS. Cuando escribes una dirección URL en el navegador, por ejemplo http://www.debian.org/index.es.html,
antes de ver la página en el navegador existe todo un juego de protocolos que entran en acción, sin profundizar en todos ellos,
vamos ver el proceso que ocurre:
• Se traduce el dominio DNS por una dirección IP (en este caso www.debian.org se traduce a una dirección IP).
• Una vez obtenida la dirección IP se accede al sistema remoto que tiene dicha IP, concretamente al puerto 80, que es el
puerto TCP asignado por defecto al protocolo HTTP.
• El cliente web entonces realiza la petición HTTP, solicitando un recurso (en este caso podría ser GET /index.es.html
HTTP/1.1, por ejemplo).
• Si el servidor web aloja la página, ésta será transferida a tu navegador en la respuesta HTTP.
Sin embargo cuando escribes en el navegador una dirección URL con llamada al protocolo HTTPS, el procedimiento es similar
al anterior pero un poco más complejo:
• Se traduce el dominio DNS por una IP.
• Una vez que se obtiene la IP, se busca en el servidor web que aloja la página solicitada el puerto 443, puerto TCP
asignado por defecto al protocolo HTTPS.
• Pero ahora, antes de transferir la página a tu navegador se inicia una negociación SSL, en la que entre otras cosas el
servidor envía su certificado de seguridad al navegador (el navegador, aunque es poco habitual, también puede enviar
el suyo), y si el certificado está firmado por un Entidad Certificadora de confianza, el cliente web aceptará el
certificado y se usará un canal seguro de comunicación, donde toda la información irá cifrada.
• Una vez verificado el certificado servidor, se realiza el proceso de petición HTTP y respuesta HTTP pero de forma
cifrada.
Puedes hacer que un servidor web para una determinada página acepte los protocolos HTTP y HTTPS en puertos TCP
distintos del 80 y 443 respectivamente. Eso sí, cuando visites la página web, en la dirección URL debes especificar el puerto
TCP. Por ejemplo, si nuestro servidor atiende peticiones HTTP en el puerto 8080 deberíamos poner
http://www.tupagina.local:8080, de esta forma el cliente web enviará la petición de la página www.tupagina.local al puerto
8080. Del mismo modo si nuestro servidor atiende peticiones HTTPS en el puerto 4333, deberíamos escribir la url en el
navegador de la siguiente forma: https://www.tupagina.local:4333. Como ves, puedes cambiar los puertos por defecto, pero
ten en cuenta que cualquiera que quisiera acceder a esas páginas debería saber el puerto TCP de la solicitud. Entonces,
¿quiere decir que aunque no escribas el puerto TCP en las direcciones URL estas se interpretan en el puerto 80 y 443 para el
protocolo HTTP y HTTPS respectivamente? Pues si, así es. Es lo mismo escribir http://www.tupagina.local:80 que
http://www.tupagina.local y es lo mismo escribir https://www.tupagina.local:443 que https://www.tupagina.local.

SSL/TLS; Secure Sockets Layer/Transport Layer Security. Protocolos criptográficos que proporcionan conexiones seguras por
una red, comúnmente Internet.
Dominio DNS: Nombre por el cual se reconoce a un grupo de dispositivos o equipos conectados a la red. Éstos pueden ser
nombres locales, no existentes en Internet, pero en general tienen por finalidad su uso en Internet. Por ejemplo, debian.org
Puerto: Número utilizado en las comunicaciones cliente/servidor en transmisiones TCP o UDP comprendido entre 1 y 65535
que indica por dónde tiene lugar la conexión con un servidor. Están estandarizados, esto es, un servidor suele estar activo
siempre por definición en un puerto determinado, pero éste puede variarse mediante configuración.
TCP: Es uno de los protocolos fundamentales en Internet. Garantiza que los datos serán entregados en su destino sin errores y
una vez recogidos, que se pondrán en el mismo orden en que se transmitieron.

3.- Arquitecturas web.


3.1.- Niveles y modelos de arquitectura.
Se puede establecer que la arquitectura de un sitio web comprende los sistemas de organización y estructuración de los
contenidos junto con los sistemas de recuperación de información y navegación que provea el sitio web, con el objetivo de
servir de ayuda a los usuarios a encontrar y manejar la información.
Desde un punto de vista lógico, se distinguen las siguientes capas, correspondientes a diferentes responsabilidades, que
deberían separarse lo mejor posible
1. Capa de presentación, es la encargada de la navegabilidad, validación de los datos de entrada, formateo de los datos
de salida, presentación de la web, ; se trata de la capa que se presenta al usuario.
2. Capa de lógica de negocio está compuesta por los módulos que implementan la lógica de la aplicación y
que se ejecutan en un servidor de aplicaciones. Es la parte más importante de la aplicación. Define los
procesos que involucran a la aplicación, es decir, es el conjunto de operaciones requeridas para proveer
el servicio.
3. Capa de acceso
a datos, es la
formada por
determinados
gestores de
datos que se
encargan de
almacenar,
estructurar y
recuperar los
datos solicitados
por la capa de
negocio.

Los modelos de arquitectura web implementan de diferentes formas, con unos u otros componentes software, cada una de las
capas anteriores;
• Modelo 1. En este caso las aplicaciones se diseñan en un
modelo web CGI, basadas en la ejecución de procesos
externos al servidor web, cuya salida por pantalla era el
HTML que el navegador recibía en respuesta a su petición.
Presentación, negocio y acceso a datos se confundían en un
mismo script perl. El estado se almacena en el cliente
• Modelo 1.5. Aplicado a la tecnología java se da con la
aparición de las JSP -y los servlets.
En este modelo, las responsabilidades de presentación
recaen en las páginas JSP, mientras que los beans
(servlets) incrustados en las mismas son los responsables del modelo de negocio y acceso a datos.

• Modelo 2. Como evolución del modelo anterior, con la


incorporación del patrón MVC (modelo -vista - controlador)
➢ Modelo: espacio de representación del problema y sus
datos, incluyendo su almacenamiento y acceso.
Negocio y acceso a datos
➢ Vista: que se refiere a la presentación de la
información. Presentación
➢ Controlador: el intermediario entre la vista y el
modelo, se encarga de controlar las interacciones del
usuario en la vista, pide los datos al modelo y los
devuelve de nuevo a la vista para que esta los muestre
al usuario. Es decir las llamadas a clases y métodos, y los datos recibidos de formularios. Se encarga de la
responsabilidad de Navegación

https://victorroblesweb.es/2013/11/18/tutorial-mvc-en-php-nativo/

• Modelo 2X. Aparece con el objetivo de dar respuesta a la necesidad, cada vez más habitual, de desarrollar aplicaciones
multicanal, es decir, aplicaciones web que pueden ser atacadas desde distintos tipos de clientes remotos. Así, una
aplicación web multicanal podrá ejecutarse desde una PDA, desde un terminal de telefonía móvil, o desde cualquier
navegador HTML estándar. El medio para lograr publicar la misma aplicación para distintos dispositivos es emplear
plantillas XSL para transformar los datos XML.
PERL Es un lenguaje de programación diseñado por Larrry Wall en 1987. Perl toma características del lenguaje C, del lenguaje
interpretado shell (), awk, sed, Lisp y, en un grado inferior, de muchos otros lenguajes de programación.
Java - Lenguaje de programación orientado a objetos, desarrollado por Sun Microsystems a principios de los años 90, aunque a
finales de 2006 liberó la mayor parte de sus tecnologías Java bajo la licencia GNU GPL.
Servlet - Son objetos que se ejecutan dentro del contexto de un contenedor de "servlets", por ejemplo Tomcat y amplían su
funcionalidad. La palabra servlet deriva de otra anterior, applet, que se refería a pequeños programas que se ejecutan en el
contexto de un navegador web. Por contraposición, un servlet es un programa que se ejecuta en un servidor. El uso más común
de los servlets es generar páginas web de forma dinámica a partir de los parámetros de la petición que envíe el navegador web.
BEAN: Abreviatura científica del botánico Willian Jackson Bean (18631947). Un bean es un componente software que tiene la
particularidad de ser reutilizable y así evitar la tediosa tarea de programar los distintos componentes uno a uno.
JavaBeans - Son un modelo de componentes creado por Sun Microsystems para la construcción de aplicaciones en Java; se
usan para encapsular varios objetos en un único objeto (bean), para hacer uso de un solo objeto en lugar de varios más simples.
La especificación de JavaBeans los define como "componentes de software reutilizables que se puedan manipular visualmente
en una herramienta de construcción".

3.2.- ¿Cuáles son las Tecnologías asociadas a las


aplicaciones web?
Las aplicaciones web emplean páginas dinámicas, éstas se ejecutan en un servidor web y se muestran en el
navegador de un equipo cliente que es el que ha realizado previamente la solicitud. Cuando una página
web llega al navegador, es posible que también incluya algún programa o fragmento de código que se deba
ejecutar. Ese código, normalmente en lenguaje JavaScript, lo ejecutará el propio navegador. Es por ello
que en este apartado nos centraremos en las tecnologías asociadas a las aplicaciones web que se ejecutarán
tanto del lado del servidor como del cliente, especificando lo que corresponda en cada uno de los casos.
• Tecnologías en el lado del servidor:
• Programas independientes del servidor que generan la respuesta
• CGI (Common Gateway Interface): la "Interface Común de Entrada" es uno de los estándares más antiguos
relacionado con las aplicaciones web. Está pensado para permitir que un cliente web pueda acceder a un
programa que se ejecuta en un servidor web, donde este generará contenido dinámico. Este estándar es
utilizado para acceder a información almacenada en bases de datos, para implementar motores de búsqueda,
gestionar datos de formularios, generar emails de forma automática, foros, comercio electrónico, juegos en
línea, . Las rutinas de CGI son habitualmente escritas en lenguajes interpretados como Perl o por lenguajes
compilados como C.
• servlets java
• Scripts de servidor
• Java; Enmarcadas en lo que se conoce como Java EE (Java Enterprise Edition) existen tecnologías orientadas
al desarrollo web; las más conocidas son JSP (JavaServer Pages), JSF (JavaServer Faces).
• ASP (Active Server Pages): las "Páginas Activas" se ejecutan del lado del servidor, de este modo se forman
los resultados que luego se mostrarán en el navegador de cada equipo cliente en virtud de la petición que se ha
realizado. Existen versiones de ASP para Unix y Linux, a pesar de que fue una tecnología desarrollada por
Microsoft para la creación dinámica de páginas web ofrecida junto a su servidor IIS. Hoy en día ASP ha
evolucionado hasta ASP.NET, y se ha convertido en un framework de desarrollo web libre.
• PHP (Hypertext Preprocessor): este lenguaje es, al igual que ASP, ejecutado en el lado del servidor. PHP es
similar a ASP y puede ser usado en circunstancias similares. Es muy eficiente, permitiendo el acceso a bases
de datos empleando servidores como MySQL y, por lo tanto, suele utilizarse para crear páginas dinámicas
complejas.

• JavaScript: dentro de la idea de "full stack development", en la que se persigue que un mismo desarrollador
o desarrolladora pueda implementar tanto la parte que se ejecuta en el servidor (back-end) como la página
que se visualiza en el cliente (front-end), han surgido cada vez más tecnologías que permiten desarrollar en
JavaScript aplicaciones web que se ejecutan en el servidor (la misma usada en el navegador web), como es el
caso de Express.js y Hapi.js (ambos funcionan sobre Node.js), y Meteor.js. Pero esta idea no es nueva, ya en
1995 el servidor web Netscape Enterprise Server ya contemplaba el uso de javascript en el servidor (server-
side javascript).

• Tecnologías en el lado del cliente:


• HTML (HiperText Markup Language): como es de suponer, ya sabrás que HTML es el lenguaje de marcas
que se utiliza maquetar el contenido de una página web. Hoy día va por la versión 5 (HTML5).
• CSS (Cascading Style Sheets): las "Hojas de Estilo en Cascada" se usan para formatear las páginas web; se
trata de separar el contenido de un documento de su presentación. Cualquier cambio en el estilo marcado para
un elemento en la CSS afectará a todas las páginas vinculadas a esa CSS.
• Java: es un lenguaje que también podemos encontrarlo en el lado del cliente, ejecutándose de forma incrustada
en un navegador web. A las aplicaciones Java que se pueden embeber en una página web se las conoce como
"applets".
• JavaScript: posiblemente el uso más extendido de este lenguaje es hacer las páginas web más interactivas. Es
un lenguaje que como ya se introdujo antes, puede interpretarse y ejecutarse en un navegador web. Es útil para
realizar tareas tales como mover imágenes por la pantalla, crear
menús de navegación interactivos, juegos, . En las páginas web
suele preferirse JavaScript porque es aceptado por muchos más
navegadores que (creado por Microsoft).
• VBScript (Visual Basic Scripting): fue la respuesta de Microsoft a
JavaScript. es un lenguaje que ha entrado en desuso, dado que solo
se podía usar casi exclusivamente en el navegador Microsoft
Internet Explorer. El código en puede, además, estar diseñado para
su ejecución en el lado del cliente o en el del servidor, la diferencia
es que un código que se ejecuta en el lado del servidor no es visible
en el lado del cliente. Éste recibe los resultados, pero no el código.

La Licencia Pública General de GNU, o más conocida por su nombre en inglés GNU General Public License es una licencia
creada por la " Free Software Fundation" y está orientada, principalmente, a proteger la libre distribución, modificación y uso
de software. Su propósito es declarar que el software cubierto por esta licencia es software libre y protegerlo de intentos de
apropiación que restrinjan esas libertades a los usuarios. El proyecto GNU ( GNU es un acrónimo recursivo para "GNU No es
Unix"). Comenzó en 1984 a desarrollar un sistema operativo completo con la principal propiedad de ser Software Libre.
es un sistema de gestión de bases de datos relacional desarrollado bajo licencia dual: Licencia pública general/Licencia
comercial por Oracle Corporation y está considerada como la base de datos de código abierto más popular del mundo, y una
de las más populares en general junto a Oracle y Microsoft SQL Server, todo para entornos de desarrollo web.
ASP.NET es la evolución de ASP, incluyendo cambios sustanciales, que funcionan sobre el framework .NET

3.3.- Plataformas web libres y propietarias.


Una plataforma web es el entorno de desarrollo de software empleado para diseñar y
ejecutar un sitio web. En términos generales, una plataforma web consta de cuatro
componentes básicos:
1. El sistema operativo,bajo el cual opera el equipo donde se hospedan las
páginas web y que representa la base misma del funcionamiento del
computador. En ocasiones limita la elección de otros componentes.
2. El servidor web es el software que maneja las peticiones desde equipos
remotos a través de la Internet. En el caso de páginas estáticas, el servidor web
simplemente provee el archivo solicitado, el cual se muestra en el navegador. En el caso de sitios dinámicos, el servidor
web se encarga de pasar las solicitudes a otros programas que puedan gestionarlas adecuadamente.
3. El gestor de bases de datos se encarga de almacenar sistemáticamente un conjunto de registros de datos relacionados
para ser usados posteriormente.
4. Un lenguaje de programación interpretado que controla las aplicaciones de software que corren en el sitio web.
Diferentes combinaciones de los cuatro componentes señalados, basadas en las distintas opciones de software disponibles en el
mercado, dan lugar a numerosas plataformas web, aunque, sin duda, hay dos que sobresalen del resto por su popularidad y
difusión: LAMP y WISA.
La plataforma LAMP trabaja enteramente con componentes de software libre y no está sujeta a restricciones propietarias. El
nombre LAMP surge de las iniciales de los componentes de software que la integran:
• 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.
La plataforma WISA está basada en tecnologías desarrolladas por la compañía Microsoft; se trata, por lo tanto, de software
propietario. La componen los siguientes elementos:
• Windows: sistema operativo.
• Internet Information Services (IIS): servidor web.
• SQL Server: gestor de bases de datos.
• ASP o ASP.NET: como lenguaje para scripting del lado del servidor.
Existen otras plataformas, como por ejemplo la configuración Windows-Apache-MySQL-PHP que se conoce como WAMP. Es
bastante común pero sólo como plataforma de desarrollo local.
De forma similar, un servidor Windows puede correr con IIS, y con MySQL y PHP. A esta configuración se la conoce como
plataforma WIMP.
Entre los servidores web más utilizados hoy en día, aparte de Apache e IIS tenemos también a Nginx, un servidor web software
libre que está demostrando un alto rendimiento, y que es capaz de atender una gran cantidad de peticiones simultaneas, y que
según las estadísticas tiene un mejor rendimiento que sus competidores al servir contenido estático. En su contra, es un servidor
cuya configuración es menos flexible que otros.
Nginx también puede integrarse con PHP, por lo que podemos encontrar plataformas tipo LNMP, resultado de integrar Linux
con Nginx, MySQL o MariaDB y PHP. Esta opción es también posible en Windows, dando lugar y plataformas WNMP
(Windows + Nginx + MySQL o MariaDB + PHP).
Existen muchas otras plataformas que trabajan con distintos sistemas operativos (Unix, , Solaris), servidores web (incluyendo
algunos que se han cobrado relativa popularidad como Lighttpd y LiteSpeed), bases de datos (MariaDB, PostgreSQL,
MongoDB) y otros lenguajes de programación.
MariaDB es un clon de MySQL que ha evolucionado por su cuenta y que es completamente software libre.
Sistema gestor de bases de datos relacionales completamente software libre.
Base de datos documental, considerada dentro de la categoría de bases de datos NoSQL.

Para saber más


XAMPP es una forma fácil de instalar y usar el servidor web Apache con un sistema gestor
de bases de datos (MariaDB), PHP y Perl (en versiones anteriores de XAMPP el motor de
bases de datos incluido era MySQL, pero en versiones recientes se ha sustituido por
MariaDB, el cual, es un proyecto derivado de MySQL).
XAMPP, basta con descargarlo, extraerlo y comenzar. En este momento hay cuatro versiones de XAMPP, para: Linux,
Windows, Mac OS X y Solaris.
XAMPP
Te proponemos los siguientes enlaces con interesantísimos vídeos sobre la instalación y uso de XAMPP en Windows.
Vídeo sobre XAMPP en Windows Resumen textual alternativo

4.- Escalabilidad.

También podría gustarte