Professional Documents
Culture Documents
Un servidor web o servidor HTTP es un programa informtico que procesa una aplicacin del lado del servidor realizando conexiones bidireccionales y/o unidireccionales y sncronas o asncronas con el cliente generando o cediendo una respuesta en cualquier lenguaje o Aplicacin del lado del cliente. El cdigo recibido por el cliente suele ser compilado y ejecutado por un navegador. Para la transmisin de todos estos datos suele utilizarse algn protocolo. Generalmente se utiliza el protocolo HTTP para estas comunicaciones, perteneciente a la capa de aplicacin del modelo OSI. El trmino tambin se emplea para referirse al ordenador que ejecuta el programa.
Arquitectura
Peticin GET
Un servidor web opera mediante el protocolo HTTP, de la capa de aplicacin del Modelo OSI. Al protocolo HTTP se le asigna habitualmente el puerto TCP 80. Las peticiones al servidor suelen realizarse mediante HTTP utilizando el mtodo de peticin GET en el que el recurso se solicita a travs de la url al servidor web. GET /index.html HTTP/1.1 HOST: www.host.com En la barra de URL de un navegador cualquiera la peticin anterior sera anloga a la siguiente direccin Web: www.host.com/index.html
Nombre
Descripcin
Es una porcin de contenido Web, texto, imagen y otros elementos, que enlaza con una direccin Web. Al pulsar un hipervnculo el navegador genera una peticin GET automtica a la direccin URL de dicho link.
Formulario web
Al realizar el envo satisfactorio de los datos de un formulario, el navegador Web genera una peticin GET o POST (comnmente POST) automtica a la par que enva los datos al servidor.
Barra de
direcciones
puede accederse manualmente a cualquier direccin URL, de modo que el navegador generar una peticin GET automtica a dicha URL cada vez que el usuario lo desee.
Cualquier aplicacin Javascript tiene acceso al estado del navegador, cmo puede modificar los datos que describen tal estado, de forma pasiva (sin medio de la intervencin del usuario) o de forma activa (mediante alguna accin del usuario).
Al pulsar en el enlace, el navegador crea automticamente la peticin GET y las cabeceras de la peticin en base a los metatags (cabeceras definidas), los cookies y cabeceras automticas del navegador, para luego enviarlas junto a la peticin al Servidor.
Peticin POST
Es el segundo tipo de peticin HTTP ms utilizado. Los datos a enviar al servidor se incluyen en el cuerpo de la misma peticin con las cabeceras HTTP asignadas correspondientemente respecto al tipo de peticin. Generalmente se asocia con los formularios web en el que los datos suelen ser cifrados para enviarlos de manera segura al servidor. Por motivos de convencin se incluye en la peticin la cabecera application/x-www-formurlencoded que indica el formato o codificacin de los datos a enviar; esta es variable>valor en el formato: variable=valor separada cada par variable->valor por &. Esta cabecera, en los formularios HTML se enva automticamente, pero en otras tecnologas web tal como AJAX, si se desea hacer correctamente una peticin POST debe ser especificado o instanciado el objeto: setRequestHeader("Content-type:application/x-www-formurlencode");ajax.send(data); Si se utilizase el mtodo GET los datos deberan de ser aadidos a la URL, lo que los expondra a ser vistos de forma directa.
Muestra
Petition type
Referer
http-url-referer
index.php
ContentLength
contentlenght-int 63
Origin
http-url-origin
User-Agent
useragent-string
ContentType
content-typestring mimetypes-
application/x-www-form-urlencoded
Accept
application/xml,application/xhtml+xml ...
AcceptLanguage
es-ES,es;q=0.8
AcceptCharset
ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie
PHPSESSID=gm0ugf96iojuldio8i51u92716
AcceptEncoding
gzip,deflate,sdch
Content
&data=4&lang=es+es
Petition type: Especifica el tipo de peticin HTTP. (Esta cabecera no tiene nombre, se enva tal cual) Referer: Especifica la url desde la cual se hizo la peticin POST. Content-Length: Especifica la longitud en bytes de los datos enviados en el cuerpo de la peticin. Origin: Especifica la url principal del sitio. User-Agent:Especifica el identificador del navegador Web desde el cual se hizo la peticin. Content-Type: Especifica el formato o MIME de los datos enviados en el cuerpo de la peticin. Accept: Especifica el MIME que se espera en la respuesta. Accept-Language: Especifica el cdigo del lenguaje esperado en la respuesta. Accept-Charset: Especifica la codificacin que se espera en la respuesta. Cookie: Especifica un identificador de sesin en la peticin derivado de un cookie. Accept-Encoding: Especifica el tipo de codificacin (generalmente compresin) que se espera de la respuesta. (No todos los navegadores envan esta cabecera)
Date
date-string
Server
server-string
Expires
expire-date-string
Cache-Control
Pragma
pragma-string
no-cache
Content-Length
Content-length-int
297
Content-Type
Content-type-string
text/html
Keep-Alive
Keep-alive-string
timeout=5, max=98
Connection
Connection-string
Keep-Alive
X-Powered-By
X-powered-by-string PHP/5.3.5
<form enctype="multipart/form-data">...</form>
<form enctype="text/plain">...</form>
<form enctype="application/x-www-form-urlencoded">...</form> O cualquier otro valor MIME. El multipart/form-data se utiliza para enviar grandes cadenas binarias que suponen cualquier otro tipo de documento que no sea texto plano, como imgenes, vdeos o ejecutables. Para varios valores, separar por comas. El application/x-www-form-urlencoded codifica de forma automtica los valores de todos los elementos del formulario del modo variable=valor, separados por &. El atributo name de un input suele ser el nombre de la variable y su value el valor. Los espacios se reemplazan por + y los caracteres no alfanumricos por $HH donde HH representa el nmero hexadecimal del carcter ASCII.
id=valor+de+la+variable&tama%A4o=4
tamao: 4
Funcionamiento
Servidor
El Servidor web se ejecuta en un ordenador mantenindose a la espera de peticiones por parte de un cliente (un navegador web) y que responde a estas peticiones adecuadamente, mediante una pgina web que se exhibir en el navegador o mostrando el respectivo mensaje si se detect algn error. A modo de ejemplo, al teclear www.google.com en nuestro navegador, ste realiza una peticin HTTP al servidor de dicha direccin. El servidor responde al cliente enviando el cdigo HTML de la pgina; el cliente, una vez recibido el cdigo, lo interpreta y lo exhibe en pantalla. Como vemos con este ejemplo, el cliente es el encargado de interpretar el cdigo HTML, es decir, de mostrar las fuentes, los colores y la disposicin de los textos y objetos de la pgina; el servidor tan slo se limita a transferir el cdigo de la pgina sin llevar a cabo ninguna interpretacin de la misma. Adems de la transferencia de cdigo HTML, los Servidores web pueden entregar aplicaciones web. stas son porciones de cdigo que se ejecutan cuando se realizan ciertas peticiones o respuestas HTTP. Hay que distinguir entre: Aplicaciones en el lado del cliente: el cliente web es el encargado de ejecutarlas en la mquina del usuario. Son las aplicaciones tipo Java "applets" o Javascript: el servidor proporciona el cdigo de las aplicaciones al cliente y ste, mediante el navegador, las ejecuta. Es necesario, por tanto, que el cliente disponga de un navegador con capacidad para ejecutar aplicaciones (tambin llamadas scripts). Comnmente, los navegadores permiten ejecutar aplicaciones escritas en lenguaje javascript y java, aunque pueden aadirse ms lenguajes mediante el uso de plugins. Aplicaciones en el lado del servidor: el servidor web ejecuta la aplicacin; sta, una vez ejecutada, genera cierto cdigo HTML; el servidor toma este cdigo recin creado y lo enva al cliente por medio del protocolo HTTP.
Las aplicaciones de servidor muchas veces suelen ser la mejor opcin para realizar aplicaciones web. La razn es que, al ejecutarse sta en el servidor y no en la mquina del cliente, ste no necesita ninguna capacidad aadida, como s ocurre en el caso de querer ejecutar aplicaciones javascript o java. As pues, cualquier cliente dotado de un navegador web bsico puede utilizar este tipo de aplicaciones. El hecho de que HTTP y HTML estn ntimamente ligados no debe dar lugar a confundir ambos trminos. HTML es un lenguaje de marcas y HTTP es un "protocolo".
PHP
ASP.Net
1998
4.0
El 75% de las aplicaciones del lado del servidor estn escritas en PHP, seguido de ASP y las dems opciones usadas de forma alternativa y muy casual. En 2009 Node.js fue creado por Ryan Dahl, abriendo pblicamente la oportunidad de usar javascript del lado del servidor. Evento que revoluciona la web, y da inicio a una nueva era del desarrollo en internet. Node.js, dado a sus usuarios, programadores web de todo el mundo, est creciendo como la mejor opcin para desarrollo de aplicaciones del lado del servidor, desplazando lenguajes tradicionales en esta tarea. Node.js trabaja sobre el rpido motor V8 que usa Google Chrome para la interpretacin de javascript.
Componentes
Para la operacin prctica del sistema DNS se utilizan tres componentes principales: Los Clientes fase 1: Un programa cliente DNS que se ejecuta en la computadora del usuario y que genera peticiones DNS de resolucin de nombres a un servidor DNS (Por ejemplo: Qu direccin IP corresponde a nombre de dominio?); Los Servidores DNS: Que contestan las peticiones de los clientes. Los servidores recursivos tienen la capacidad de reenviar la peticin a otro servidor si no disponen de la direccin solicitada. Y las Zonas de autoridad, porciones del espacio de nombres raros de dominio que almacenan los datos. Cada zona de autoridad abarca al menos un dominio y posiblemente sus subdominios, si estos ltimos no son delegados a otras zonas de autoridad
En cualquier caso, los servidores DNS que reciben la peticin, buscan en primer lugar si disponen de la respuesta en la memoria cach. Si es as, sirven la respuesta; en caso contrario, iniciaran la bsqueda de manera recursiva. Una vez encontrada la respuesta, el servidor DNS guardar el resultado en su memoria cach para futuros usos y devuelve el resultado.
Jerarqua DNS
El espacio de nombres de dominio tiene una estructura arborescente. Las hojas y los nodos del rbol se utilizan como etiquetas de los medios. Un nombre de dominio completo de un objeto consiste en la concatenacin de todas las etiquetas de un camino. Las etiquetas son cadenas alfanumricas (con '-' como nico smbolo permitido), deben contar con al menos un carcter y un mximo de 63 caracteres de longitud, y deber comenzar con una letra (y no con '-') (ver la RFC 1035, seccin "2.3.1. Preferencia nombre de la sintaxis "). Las etiquetas individuales estn separadas por puntos. Un nombre de dominio termina con un punto (aunque este ltimo punto generalmente se omite, ya que es puramente formal). Un FQDN correcto (tambin llamado Fully Qualified Domain Name), es por ejemplo este: www.example.com. (Incluyendo el punto al final) Un nombre de dominio debe incluir todos los puntos y tiene una longitud mxima de 255 caracteres.
Un nombre de dominio se escribe siempre de derecha a izquierda. El punto en el extremo derecho de un nombre de dominio separa la etiqueta de la raz de la jerarqua (en ingls, root). Este primer nivel es tambin conocido como dominio de nivel superior (TLD - Top Level Domain). Los objetos de un dominio DNS (por ejemplo, el nombre del equipo) se registran en un archivo de zona, ubicado en uno o ms servidores de nombres.
Resolucin iterativa
Las resoluciones iterativas consisten en la respuesta completa que el servidor de nombres pueda dar. El servidor de nombres consulta sus datos locales (incluyendo su cach) buscando los datos solicitados. El servidor encargado de hacer la resolucin realiza iterativamente preguntas a los diferentes DNS de la jerarqua asociada al nombre que se desea resolver, hasta descender en ella hasta la mquina que contiene la zona autoritativa para el nombre que se desea resolver.
Resolucin recursiva
En las resoluciones recursivas, el servidor no tiene la informacin en sus datos locales, por lo que busca y se pone en contacto con un servidor DNS raz, y en caso de ser necesario repite el mismo proceso bsico (consultar a un servidor remoto y seguir a la siguiente referencia) hasta que obtiene la mejor respuesta a la pregunta. Cuando existe ms de un servidor autoritario para una zona, Bind utiliza el menor valor en la mtrica RTT (round-trip time) para seleccionar el servidor. El RTT es una medida para determinar cunto tarda un servidor en responder una consulta. El proceso de resolucin normal se da de la siguiente manera: 1. El servidor A recibe una consulta recursiva desde el cliente DNS. 2. El servidor A enva una consulta recursiva a B. 3. El servidor B refiere a A otro servidor de nombres, incluyendo a C. 4. El servidor A enva una consulta recursiva a C. 5. El servidor C refiere a A otro servidor de nombres, incluyendo a D. 6. El servidor A enva una consulta recursiva a D. 7. El servidor D responde. 8. El servidor A regresa la respuesta al resolver.
Servicio.Protocolo.Dominio-completo IN SRV Prioridad.Peso.Puerto.Equipo-Completo SPF = Sender Policy Framework - Ayuda a combatir el Spam. En este registro se especifica cual o cuales hosts estn autorizados a enviar correo desde el dominio dado. El servidor que recibe, consulta el SPF para comparar la IP desde la cual le llega con los datos de este registro. ANY = Toda la informacin de todos los tipos que exista.