Web
A menudo se confunde la World Wide Web con Interneto las propias paginas web y estos en realidad son una de las aplicaciones que Internet ofrece; sin embargo la sociedad actual no se concibe sin estos
A la hora de afrontar un nuevo proyecto web, es importante tener una visión general del conjunto de elementos que interactúan (servidores, balanceadores, tipo de aplicación, cortafuegos, etc..).
A continuación vamos a ver una serie de conceptos, que te ayudarán a entender el funcionamiento general de distintas arquitecturas web y entender que es un servidor web.
World Wide web
La World Wide Web, habitualmente conocida como WWW o como Web, y que podríamos traducir como Red Mundial, es un entramado de documentos a escala planetaria escritos en un fotmato de texto denominado hipertexto. Cualquier usuario de la WWW puede crear su pagina web, ponerla a disposición de otros usuarios y establecer enlaces a cualquier parte de la Web.
El lenguaje basado en hipertexto más conocido es el lenguaje HTML (Hyper- Text Markup Language, Lenguaje de Marcas de Hipertexto) sirviéndose de un reducido conjunto de etiquetas estructurales y semánticas apropiadas para la realización de documentos relativamente simples y que luego se han hecho mas complejas para adaptar HTML a las nuevas posibilidades de la Web, como la posibilidad de usar elementos multimedia o la utilización de elementos dinámicos (animaciones Java, uso de Flash, controles ActiveX, etc.) que hacen las páginas web mucho más llamativas e interactivas para el usuario.
Direcciones URL
(Uniform Resources Locator)
Según la RFC1738, un Localizador Uniforme de Recursos (URL) no es más que una secuencia de caracteres, de acuerdo a un formato estándar, que se usa para nombrar recursos para su localización. Las URL no son pues más que las direcciones de los distintos recursos de Internet, es decir, de las distintas páginas web. A continuación tienes un esquema típico y ejemplos:
Protocolo HTTP
El Protocolo de Transferencia de Hipertexto (HyperText Transfer Protocol, HTTP) es un protocolo de nivel de aplicación para sistemas de información distribuidos que lleva siendo utilizado en la WWW desde 1990.
El protocolo HTTP permite el intercambio de información hipertextual (enlaces) en las páginas web. Se trata de un protocolo genérico orientado a objetos. Una de sus características principales es la independencia en la visualización y presentación de los datos, lo que permite que los sistemas se construyan independientemente del desarrollo de nuevos avances en la representación de los datos. Para visualizar los datos de la Web se precisa de un navegador instalado en la máquina del cliente. En el protocolo HTTP existen una serie de características tales como:
El protocolo HTTP está fundado en un modelo cliente/servidor.
Para la comunicación, se establece en una conexión TCP a través del puerto 80 (puerto por defecto).
La comunicación HTTP está basada en mensajes solicitud/respuesta en formato ASCII.
Por tanto, una sesión HTTP es una secuencia de transacciones solicitud/ respuesta. Un cliente HTTP inicia una petición, estableciéndose una conexión TCP a un puerto del host (habitualmente el 80). Un servidor HTTP espera el mensaje de petición del cliente en dicho puerto.
Para recibir la petición, el servidor devuelve una línea de estado, como "HTTP/1.1 200 OK" y un mensaje propio cuyo cuerpo es, por ejemplo, el recurso solicitado, un mensaje de error, o alguna otra información.
El mensaje de solicitud consiste en lo siguiente:
Línea de solicitud (por ejemplo, GET HTTP/1.1/images/logo.gif), la cual solicita un recurso llamado /images/logo.gif del servidor.
Cabeceras (por ejemplo, Accept-Language: en).
Una línea vacía.
Un cuerpo de mensaje opcional.
La línea de solicitud y la cabecera deben acabar con <CR> <LF> (es decir, un retorno de carro seguido de un fin de línea). La línea vacía debe consistir en solo <CR> <LF>.
En HTTP, se definen ocho de los denominados métodos, los cuales indican la acción que se desea que sea realizada sobre el recurso identificado. Los métodos definidos son los siguientes:
GET
Solicita una representación del recurso especificado. Mediante este método el cliente solicita, por ejemplo, una página HTML (index. html) o una imagen (foto.jpg).
HEAD
pide una respuesta idéntica a la que que correspondería a una petición GET, pero sin el cuerpo de respuesta (es decir, sin que nos devuelvan la página HTML o la imagen, por ejemplo). Es útil para recuperar la información escrita en cabeceras de respuesta, sin necesidad de llevar el contenido entero.
POST
envía datos para ser procesados (por ejemplo, un documento HTML) al recurso identificado Los datos se incluyen en el cuerpo de la petición. Esto puede causar la creación de un nuevo recurso y/o las actualizaciones de recursos existentes. POST puede usarse para enviar a un servidor web los datos de un formulario.
PUT
carga una representación del recurso especificado.
DELETE
suprime el recurso especificado.
TRACE
provoca que el servidor devuelva en la respuesta la petición recibida. Se suele usar para tareas de diagnóstico.
OPTIONS
devuelve los métodos HTTP que el servidor suministra para un URL especificado. Puede usarse para comprobar la funcionalidad de un servidor web solicitando " * " (all) en vez de un recurso específico.
CONNECT
convierte la conexión de solicitud en un túnel transparente TCP/IP, por lo general para facilitar la comunicación SSL cifrada (el denominado protocolo HTTPS, que veremos más adelante) a través de un proxy HTTP no encriptado.
Las peticiones y las repuestas llevarán unas cabeceras y, opcionalmente, un contenido (datos).
Primero se descarga la página, y luego cada gif u objeto que haya en ella.
Cada petición es independiente; si se usa HTTP/1.0 se hace en conexiones TCP distintas, si se usa HTTP/1.1 se puede hacer varias en una misma conexión.
En la cabecera se mostrará la siguiente información:
Host
User-agent
Server
Cache-control
Content-type
Content-Encoding
Expires: tiempo de expiración del recurso solicitado.
Location
Set-Cookie
Aquí tienes un ejemplo:
Más info sobre HTTP:
HTTP Status codes
Desde la introducción de HTTP/1.0, la primera línea de la respuesta HTTP se denomina línea de estado e incluye un código de estado numérico (por ejemplo, 404) y una frase explicativa textual (por ejemplo "No encontrado"). Estas son las estándar que pueden ser cambiadas en todo caso por el desarrollador web si así lo quisiera:
Protocolo HTTPS (seguro)
El Protocolo de Transferencia de Hipertexto Seguro (HyperText Transfer Protocol Secure, HTTPS) es una combinación del Protocolo HTTP con el protocolo SSL/TLS (Secure Sockets Layer, Protocolo de Capa de Conexión Segura; y Transport Layer Security, Seguridad de la Capa de Transporte) para proporcionar el cifrado y la identificación segura del servidor. Las conexiones HTTPS se usan, por ejemplo, para transacciones de pago en la WWW o para transacciones confidenciales en sistemas de información corporativos.
Conceptualmente, HTTPS es muy simple. Simplemente HTTP usa los servicios de SSL o TLS tal como se usa HTTP sobre TCP. El cliente HTTP también debe actuar como cliente SSL/TLS, iniciando una conexión al servidor sobre el puerto apropiado y enviando un ClientHello para el establecimiento de la conexión SSL/TLS. Una vez que el establecimiento SSL/TLS ha terminado, el cliente entonces puede iniciar la primera petición HTTP.
El primer dato que un servidor HTTP espera recibir del cliente es una petición de línea. Por otro lado, el primer dato que un servidor TLS/SSL espera recibir es el ClientHello. Por consiguiente, la práctica común es correr HTTP/ TLS sobre un puerto distinto para distinguir el protocolo que se usa. Cuando HTTPS funciona sobre una conexión TCP/IP, el puerto por defecto es 443. Esto no excluye que HTTPS pueda ir sobre otro protocolo de transporte, ya que TLS solo presupone que exista una conexión fiable.
El formato de los URL es el mismo pero cambiando el protocolo:
Antes de continuar, es necesario recordar algunos conceptos importantes en el intercambio de información seguro:
Claves: se utilizan para cifrar y descifrar mensajes, de manera que aumente la seguridad en la comunicación. Si se usa la misma clave para cifrar y descifrar mensajes, se habla de criptografía simétrica. El problema de este sistema es que emisor y receptor han de intercambiarse las claves, por lo que el sistema no es del todo seguro, para ello, surge la criptografía asimétrica, que es la que usan TTL y SSL, en la que existen dos claves diferentes: una clave pública, que puede entregarse a cualquier usuario; y una clave privada, que es guardada por el propietario, sin que nadie tenga acceso a ella. Cuando el emisor usa su clave pública para cifrar el mensaje, solo el receptor, que posee una clave privada asociada, puede descifrar el mensaje. Por otra parte, cuando el propietario utiliza su clave privada para cifrar el mensaje, cualquier usuario puede descifrarlo con su clave pública, de manera que se sabe quién es el remitente. Un ejemplo de utilización de este tipo de criptografía es la firma electrónica.
Certificados: el inconveniente que presenta el sistema anterior es que si alguien corrompe la clave pública, reemplazándola por la suya propia, podría descifrar los mensajes del emisor. Un certificado permite asociar una clave pública con una entidad para garantizar su validez. El certifi- cado es como una tarjeta de identificación de la clave, emitido por una entidad llamada Autoridad de certificación (CA, Certification Authority). La estructura de los certificados viene determinada por la norma X.509. Los certificados se utilizan principalmente en tres tipos de contextos: los certificados de cliente se almacenan en la estación de trabajo del usuario o se integran en un contenedor como una tarjeta inteligente, y permiten identificar a un usuario y asociarlo con ciertos privilegios; los certificados de servidor se instalan en un servidor web y permiten conectar un servicio con el dueño del servicio. En el caso de página web, permiten garantizar que la dirección URL de la página web y especialmente su do- minio pertenecen realmente a una empresa determinada. También permiten proteger las transacciones con usuarios gracias al protocolo SSL; los certificados VPN (Red privada virtual) se instalan en un equipo de red y permiten cifrar flujos de comunicación de extremo a extremo entre dos puntos (por ejemplo, dos ubicaciones de una empresa).
Autenticación: su objetivo es limitar el acceso a un servidor web únicamente a usuarios autorizados. Esto se suele realizar mediante la introducción de un nombre de usuario y contraseña. En sitios administrados mediante certificados, el administrador del sitio crea un certificado para cada usuario, el cual es guardado dentro de su navegador. Normalmente, el certificado contiene el nombre y la dirección de correo del usuario autorizado y se revisa automáticamente en cada conexión para verificar la identidad del usuario sin que tenga que ingresar su contraseña cada vez.
Arquitecturas web
Clásica (Cliente/Servidor)
Un cliente (Navegador, Webview) solicita un documento a un servidor . El servidor lo procesa y devuelve un documento al cliente. Implica varias características:
Recarga de página por cada petición.
Renderizado del documento en el servidor. El servidor entrega el documento con todo el marcado HTML. Es por esto por lo que las “arañas” de los motores de búsqueda, pueden indexar contenido.
Puede haber o no sesión.
Una aplicación web también se puede definir como una aplicación software codificada en un lenguaje soportado por un navegador (como, por ejemplo, HTML, JavaScript, Java, ASP.NET, etc.) y que reside en un navegador web común, constituyendo una aplicación ejecutable. Aplicaciones web típicas se utilizan para correo web, comercio y subastas online, gestores de contenidos (wikis) y muchas otras funciones. Para realizar una aplicación web, existen diversos conceptos (pulsa encima de ellos para saber más):
Permite a un cliente (navegador web) solicitar datos de un programa ejecutado en un servidor web.
, , ,
Generan páginas web de forma dinámica a partir de los parámetros de la petición que envíe el navegador web.
Creación de aplicaciones web interactivas.
Administración de contenidos en páginas web. Por ejemplo, Wordpress o Joomla
, ,
Sistema gestor de base de datos relacional
Servidor web de código abierto
Conjunto de servicios web de Windows
En cuanto a su estructura, las aplicaciones se dividen en partes lógicas denominadas capas, teniendo cada capa un papel diferente. Las aplicaciones clásicas constan únicamente de una capa, la cual reside sobre la máquina del cliente, aunque, a medida que aumenta la complejidad de la aplicación se tiene a un modelo de N capas. La estructura más común es la aplicación de tres niveles. En su forma más habitual, las tres capas se denominan:
Capa de presentación: consiste en un navegador web.
Capa de aplicación: suele constar de un motor que usa alguna tecnología dinámica de contenido web (como ASP, ASP.NET, CGI, ColdFusion, JSP/Java, PHP, Perl, Python, Rubi on Rails o Struts2).
Capa de almacén de datos: se trata de una base de datos.
El navegador web envía peticiones a la capa intermedia (capa de aplicación), la cual le presta servicios mediante la realización de peticiones, se actualiza con la base de datos y genera una interfaz de usuario.
Stacks web
Se llama Stack a un conjunto de tecnologías que se escogen como herramientas para implementar la solución de un proyecto. Generalmente se usan para dar una descripción de la arquitectura de un modo rápido.
Veamos algunos ejemplos:
La elección de una arquitectura u otra resultará de las condiciones del proyecto, los conocimientos de los programadores y el servicio concreto que se quiera dar. Las arquitecturas que diferenciamos a nivel cliente-servidor son:
RIA (Rich Internet Application)
Son aplicaciones de Escritorio ejecutadas en el contexto de un navegador.
El concepto básico para diferenciarlo de una arquitectura clásica es el uso AJAX para evitar recargas de página, y el aumento de protagonismo de Javascript y CSS para pasar de un documento de presentación a una interfaz más interactiva.
Las interfaces de usuario RIA normalmente se desarrollan utilizando HTML5 + JavaScript + CSS3, Flex (Flash), JavaFX, GWT, Dart o alguna otra herramienta RIA. Aunque se han impuesto las variaciones de HTML5 + JavaScript + CSS3 parecen ser las ganadoras (GWT y Dart se pueden compilar en JavaScript).
El hecho de mantener la lógica de la app separada de la GUI significa varias cosas:
Las GUI pueden volverse mucho más avanzadas con las tecnologías RIA.
El tiempo de CPU necesario para generar la GUI se elimina del servidor, liberando más ciclos de CPU para ejecutar la lógica de la aplicación.
El estado de la GUI se puede mantener en el navegador, "limpiando" así aún más el lado del servidor de las aplicaciones web RIA y ofreciendo algo más de seguridad.
Resulta más fácil desarrollar componentes de GUI reutilizables, que pueden reutilizarse sin importar qué lenguaje de programación del lado del servidor se utilice para la lógica de la aplicación.
Las tecnologías RIA normalmente se comunican con el servidor web mediante el intercambio de datos, no de código GUI (HTML, CSS y JavaScript). El intercambio de datos suele ser XML enviado a través de HTTP o JSON enviado a través de HTTP. Esto cambia el lado del servidor de ser "páginas" a "servicios" que realizan alguna parte de la lógica de la aplicación (crear usuario, iniciar sesión, almacenar tareas, etc.). Cuando el lado de su servidor queda completamente libre de generar GUI, la lógica de su aplicación se vuelve muy clara.
Dado que la GUI y la lógica de la aplicación en el servidor generalmente se comunican a través de HTTP + JSON o HTTP + XML, la GUI es 100% independiente del lenguaje de programación que se utiliza en el servidor. La interfaz de la lógica GUI con el servidor son solo llamadas HTTP.
Facilita el uso e implementación de las APIs y la integración con iOS o Android.
SPA (Single Page Application)
La idea fundamental por la que surgieron las SPA’s fue algo ya basado en las RIA’s, que es el concepto de evolucionar el estado de una aplicación en base sólo a los datos del servidor y no a la vista renderizada del servidor ( marcado + datos injectados).
Manejo del Histórico de navegación en el cliente mediante los ficheros de renderización iniciales.
Presenta un problema para el SEO, ya que ya no se renderizan todas las páginas en el servidor, sólo la primera y si el javascript no lo detecta el crawler, no funcionará.
Algunas tecnologias que usan SPA:
Frameworks de JavaScript para los navegadores web como AngularJS, Ember.js, Meteor.js, Vue.js, ExtJS y React han adoptado los principios de SPA.
AJAX
Websockets
Referencias:
Conceptos sobre servidores web
Escalabilidad
La escalabilidad hace referencia a la capacidad de un sistema de crecer.
Descripción
Escalado mediante el uso de recursos de hardware más potentes.
Escalado en base a más máquinas menos potentes se distribuyan la carga del trabajo a realizar.
Escalable
CPU’s con más cores o más potentes
Mayor cantidad de RAM o más rápida
Disco (SSD)
Mayor Ancho de Banda
Más servidores y máquinas o mejores componentes de red
Depende del caso, pero generalmente implica menor coste que un escalado vertical.
Desventajas
Mayor coste
Puede implicar parada o degradación de servicio
Pérdida de cierto control, si se delega en servicios a terceros, dependiendo del grado de flexibilidad que ofrezcan
Puede implicar degradación de servicio
Balanceo de Carga
Coordinación de las sesiones de usuario en caso de haberlas (Sticky Sessions) o algún mecanismo para que iniciada una transacción entre cliente y servidor que consta de varias peticiones, toda la transacción sea atómica (todas las peticiones vayan al mismo servidor).
Alta disponibilidad y Balanceo de carga
La alta disponibilidad consiste en garantizar que siempre haya al menos un mínimo de elementos de la arquitectura para poder procesar correctamente una “petición”. Aquí aparecen los conceptos de redundancia y evitar SPOF.
El balanceo de carga consiste en distribuir la carga de (tráfico, consultas a la base de datos…) entre distintos elementos de la arquitectura. El balanceo puede hacerse mediante hardware (más caro pero más fiable) o mediante software (más flexible pero exige un conocimiento mayor).
Rendimiento (Performance)
La mejora de rendimiento de una aplicación o servicio depende de muchos factores. NO hay soluciones universales.El rendimiento suele ir ligado a la velocidad, pero también es importante la percepción de la velocidad.
Puedes tener perfectamente configurado un backend y que tu aplicación parezca lenta. Los navegadores a veces te pueden jugar una mala pasada si no sabes cómo funciona un navegador.
Conceptos sobre Seguridad
Todo servicio expuesto en Internet puede ser vulnerable a ataques de distinta naturaleza. Si somos nosotros los que administramos el servicio, debemos preocuparnos de estar preparados ante ciertos ataques como:
DOS y DDOS: Denegación de servicio. Se produce por saturación de peticiones.
XSS y SQL Injection: Sucede cuando no se comprueban y "sanitizan" las entradas (vía formulario generalmente) en nuestra web.
Más info:
Hosting
Dentro de la elección de hosting tenemos muchas alternativas dependiendo de qué tipo de servicios necesitamos, con cuánto presupuesto contemos y otros servicios. Una clasificación a grosso modo podría ser la siguiente:
Tradicional
VPS ( Servidor Privado Virtual)
Plesk / Cpanel ( Nada recomendables, muy poco flexibles )
PAAS / IAAS
Azure (Microsoft)
AWS (Amazon)
DigitalOcean
OpenStack
PAAS
Heroku / Modulus
Homing
Web frameworks
Los web frameworks son un conjunto de abstracciones sobre operaciones comunes en la construcción de una aplicación web. Muchos frameworks se escriben en un determinado lenguaje de programación, ya que esto permite aprovechar el paradigma del lenguaje en sí. Por eso es importante también la elección del lenguaje de programación a la hora de decidir un framework ya que este nos permitirá afrontar de manera más cómoda y más natural una serie de problemas para los que el paradigma de programación está pensado.
Los webframeworks pretenden establecer un patrón de funcionamiento para resolver ciertas tareas que una aplicación web nos va requerir. Estas son algunas de ellas:
Enrutado
Templating
MVC
Scaffolding
Los webframeworks pueden ser generalistas, o bien específicos para resolver una determinada área como un CMS, una tienda, un portal , etc…
A continuación te muestro una lista con Web Frameworks con su lenguaje de programación asociado:
Symphony ( PHP )
RoR ( Ruby on Rails )
Django ( Python )
Spring (Java)
Express ( NodeJS )
Meteor ( NodeJS )
Última actualización
