Fundamentos de Funcionamiento de Una Aplicación Web

Fundamentos de funcionamiento de una aplicacin web
http://www.devjoker.com/print/Articulos/518/Articulos.aspx
www.devjoker.com Fundamentos de funcionamiento de una aplicacin web

Arquitectura cliente-servidor y modelo de peticin - respuesta
Antes de poder entrar a ver como se programa una aplicacin con ASP.NET es necesario conocer algunos de los fundamentos de funcionamiento de una aplicacin web. Los primero que debemos saber es que las aplicaciones web se basan en una arquitectura cliente-servidor. Donde: El servidor es el ordenador encargado de proporcionar el contenido. Para ello necesitamos instalar un servidor web en dicha mquina. Existen multitud de servidores web (Apache, LigHTTPd, IIS) pero no todos son capaces de ejecutar aplicaciones ASP.NET. nicamente los servidores de Microsoft pueden desempear dicha tarea. En nuestro caso utilizaremos IIS Espress. El cliente, que es el encargado de solicitar la informacin al servidor y mostrarla al usuario. Es el navegador (Interner Explorer, Firefox, Chrome, etc ). Si estas viendo est pagina estas utilizando un navegador web. El funcionamiento de una aplicacin es simple, el cliente emite una peticin de un recurso que se encuentra en el servidor, y el servidor devuelve el recurso solicitado que es mostrado por el navegador.
La peticin del recurso en concreto se realiza a travs de una URL. Una URL no es mas que una cadena de texto, expresada en un formato determinado en la que indicamos el protocolo, el puerto, el servidor y el recurso que estamos solicitando. Por ejemplo: http://www.devjoker.com:80/default.aspx En nuestro caso el protocolo es HTTP, el servidor www.devjoker.com, el puerto el 80 y el recurso default.aspx. El puerto estndar para el protocolo HTTP es el 80, por lo que no se suele especificar. Dependiendo de la configuracin del servidor podramos omitir el recurso y asignar uno por defecto. De este modo la siguiente URL seria equivalente a esta otra: http://www.devjoker.com La peticin HTTP tendra la siguiente forma: GET http://www.devjoker.com/ HTTP/1.1 Accept: text/html, application/xhtml+xml, */* Accept-Language: es-ES User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0) Accept-Encoding: gzip, deflate Host: www.devjoker.com If-Modified-Since: Fri, 03 Aug 2012 10:57:59 GMT Connection: Keep-Alive Pragma: no-cache Cookie: ASP.NET_SessionId=nullimt1wzjmbtik5ferit4w; Aunque nosotros solo especifiquemos la URL, el navegador web aadir cierta informacin adicional a la peticin como el tipo de contenido que acepta como respuesta, el lenguaje, tipo de navegador Y la respuesta sera algo similar a esto (se acorta el contenido del documento HTML devuelto por razones de espacio): HTTP/1.1 200 OK Cache-Control: public Content-Type: text/html; charset=utf-8 Expires: Fri, 03 Aug 2012 10:58:48 GMT Last-Modified: Fri, 03 Aug 2012 10:58:38 GMT Vary: Accept-Encoding Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Fri, 03 Aug 2012 10:58:39 GMT Content-Length: 42013 <!DOCTYPE html > <html lang="es"> <head id="Head1"> <title>www.devjoker.com</title> </head> <body>  ....
1 de 6
15/10/2013 22:46
</body> </html> Tanto la peticin como la respuesta pueden tener dos secciones diferenciadas: Las cabeceras de HTTP (indicadas en cursiva y color gris en el ejemplo) y el cuerpo. Profundizaremos algo ms en estos conceptos en captulos posteriores de este tutorial. De momento diremos que en el caso de la peticin HTTP podemos enviar informacin adicional (normalmente los datos de un formulario web), y que en el caso de la respuesta HTTP recibiremos el contenido HTML, el lenguaje de marcado que utilizar el navegador para visualizar la pgina. Afortunadamente ASP.NET (y todos los framework de desarrollo web) encapsulan el manejo de la solicitud y la respuesta en objetos de fcil acceso.
Servidores DNS
Falta an por introducir un elemento importante. Los servidores en internet (en realidad cualquier ordenador dentro de una red) se identifica por una direccion IP. Sin embargo, en el ejemplo anterior, al proporcionar la URL, no nos hemos referido a una direccin IP, sino al nombre del servidor (mas concretamente al nombre de dominio). Entonces Como sabe el navegador que un determinado servidor www.devjoker.com se corresponde con una direccin IP concreta? La respuesta es simple: Los servidores DNS. Un servidor DNS es una especie de centralita de internet, de forma que cuando un navegador solicita una URL a un servidor desconocido, primero se consulta la centralita para obtener la direccin IP. Por motivos de rendimiento, una vez que se ha resuelto el nombre de dominio se almacena localmente para que no sea necesario volver a preguntar.
Podemos realizar consultas directamente al servidor DNS con la aplicacin nslookup: Microsoft Windows [Versin 6.1.7601] Copyright (c) 2009 Microsoft Corporation. Reservados todos los derechos. C:\Users\pedro_herrarte>nslookup Servidor predeterminado: google-public-dns-a.google.com Address: 8.8.8.8 > devjoker.com Servidor: google-public-dns-a.google.com Address: 8.8.8.8 Respuesta no autoritativa: Nombre: devjoker.com Address: 188.165.132.77 > 188.165.132.77 En el ejemplo anterior estamos utilizando los servidores DNS de Google (IP 8.8.8.8). Por ultimo, nos faltara conocer como es capaz el servidor DNS de obtener la IP correcta de nuestro servidor www.devjoker.com. Cuando registramos un dominio en internet, debemos configurar dicha informacin a travs del panel de control DNS (opcin que proveen TODOS los registradores de dominio TODOS? NO! MoviStar no te permite configurar los registros de DNS y te obliga a contratarlo como servicio aparte. Mi recomendacin es que NUNCA registris un dominio con MoviStar). De este modo, publicamos que nuestro nombre de dominio devjoker.com, se corresponde un servidor (o conjunto de servidores) con una direccin IP concreta. La siguiente imagen muestra la configuracin DNS de devjoker.com:
De un modo similar funciona el envo de correos electrnicos, con las salvedad de que el servidor DNS es consultado para registros de tipo MX Mail eXchange, es decir, que para que nuestro servidor sea capaz de enviar y recibir correos debemos haber configurado correctamente ambos servidores y haber configurado los servidores DNS adecuadamente.
2 de 6
15/10/2013 22:46
Protocolo HTTP
El protocolo de comunicaciones que se utiliza para solicitar y recibir pginas web es HTTP. HTTP es el acrnimo de HyperText Transfer Protocol, siendo el aspecto mas relevante que se trata de un protocolo de transmisin de texto. Solo texto. Es sumamente importante entender este aspecto, ya que condiciona como funciona la web. Si analizamos los elementos base en los que sostiene la web hoy en da, nos encontramos los siguientes elementos fundamentales: El lenguaje para la definicin de los elementos de una pgina y su contenido es texto HTML. Veremos una pequea introduccin a HTML en el siguiente capitulo. El lenguaje para la definicin del aspecto visual de la pgina es texto. CSS. Tambin veremos una introduccin a CSS en este tutorial. El lenguaje para la programacin del lado del cliente JavaScript, que se recibe en cuerpo de la respuesta como texto, y se compila e interpreta en el cliente. (Esto tiene interesantes matices, como la posibilidad de escribir cdigo dinmicamente en el servidor ) HTTP es un protocolo sin estado, es decir, HTTP no guarda ninguna informacin sobre conexiones anteriores. Esto significa que cuando enviamos varias solicitudes HTTP, la solicitud actual no conoce en los datos que han enviado y recibido las peticiones anteriores. Por ejemplo, si en una primera solicitud enviamos la informacin de un usuario, y luego visitamos una segunda pgina, esta segunda pgina no sabe que usuario utilizamos en la anterior. Este es un factor que condiciona completamente la forma de trabajar cuando desarrollamos aplicaciones web, ya que al no proporcionarnos esta informacin el protocolo vamos a tener que realizarlo a nivel de aplicacin. Adems las peticiones HTTP responden a una serie de verbos predefinidos, segn el verbo de la solicitud el servidor actuar de una forma u otra. Los verbos mas comunes son GET y POST, aunque existen mas. Veremos mas adelante que ASP.NET MVC permite especificar que un mtodo de un controlador responda nicamente a un conjunto de verbos concretos. Cuando veamos la parte dedicada a AJAX y jQuery veremos que existen mtodos $.get() y $.post() para realizar peticiones utilizando uno u otro verbo de forma simple desde JavaScript. Ha continuacin vamos a ver un par de ejemplos sobre GET y POST. GET Solicita un recurso especifico. Se utiliza sobre todo cuando solicitamos un recurso sin necesidad de enviar informacin adicional, aunque el verbo GET permite enviar datos adicionales como parte de la URL solicitada, su uso debe realizarse con cuidado, ya que es una informacin que un usuario malintencionado podra modificar para realizar un ataque. GET /images/logo.png HTTP/1.1 obtiene un recurso llamado logo.png POST Enva los datos incluyndolos en el cuerpo de la peticin. Es muy habitual para el envo de datos (a travs de formularios), en los que el usuario rellena cierta informacin y la enva al servidor. POST http://devjoker.com/login.aspx HTTP/1.1 Accept: text/html, application/xhtml+xml, */* Accept-Language: es-ES User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0) Content-Type: application/x-www-form-urlencoded Accept-Encoding: gzip, deflate Host: devjoker.com Content-Length: 650 Connection: Keep-Alive Pragma: no-cache UserName=nombreUsuario&Password=laclave El ejemplo anterior corresponde a la captura de una peticin HTTP de un formulario de identificacin de usuario a travs de POST. Podemos ver que la informacin se enva en el cuerpo de la peticin, y fcilmente podemos obtener el usuario y el password, siendo muy fciles de capturar (al menos desde el propio equipo que realiza las peticiones!). Es por este motivo, por el existe una versin cifrada de HTTP HTTPS , que se encarga de cifrar todas comunicaciones que se producen entre el navegador y el servidor. Es un aspecto que tendremos que tener en cuenta siempre que nuestras aplicaciones requieran del manejo de datos sensibles. Por ltimo, comentar que HTTP responde a cada peticin con un cdigo de estado predefinido que permite al navegador identificar que accin debe realizar. A continuacin vamos a ver algunos de los cdigos HTTP mas comunes.
Cdigos de estado HTTP.

Cada respuesta HTTP identifica el resultado de la peticin a travs de un cdigo HTTP. Dependiendo de este cdigo de respuesta de HTTP el navegador realizar una accin u otra. Por ejemplo, mostrar la pantalla solicitada si el estado es 200 (OK) o mostrar la pantalla de error en caso de que reciba un error 500 (error de servidor). Los cdigos de error de HTTP con cdigos numricos, agrupados en familias por centenas. De forma que los errores 200 corresponden a peticiones correctas, los errores 300 redirecciones, los 400 errores en la peticin y los errores 500 errores de ejecucin del lado del servidor. De manera muy breve veremos los principales cdigos de respuesta de HTTP.
3 de 6
15/10/2013 22:46
200 OK Indica que el servidor a obtenido y enviado correctamente el recurso solicitado por la peticin. En este caso el cuerpo de la respuesta contendr el contenido en texto (HTML, CSS, Javascript, etc) del recurso solicitado, permitiendo al navegador mostrarlo en la pantalla. El siguiente ejemplo muestra una peticin GET al recurso http://devjoker.com : GET http://devjoker.com/ HTTP/1.1 Accept: text/html, application/xhtml+xml, */* Accept-Language: es-ES User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0) Accept-Encoding: gzip, deflate Host: devjoker.com If-Modified-Since: Sun, 19 Aug 2012 22:22:57 GMT Connection: Keep-Alive Y la respuesta obtenida: HTTP/1.1 200 OK Cache-Control: public, max-age=10 Content-Type: text/html; charset=utf-8 Content-Encoding: gzip Expires: Sat, 22 Sep 2012 22:37:05 GMT Last-Modified: Sat, 22 Sep 2012 22:36:55 GMT Vary: Accept-Encoding Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Sat, 22 Sep 2012 22:36:56 GMT Content-Length: 9357 <html> </html> La respuesta incluye el cdigo HTML de la pgina que permitir al navegador mostrar el contenido solicitado. Por razones de espacio se omite el contenido HTML en este ejemplo. 301 Redireccin permanentemente. sta es la opcin ms habitual en el caso de migraciones o cambios de dominio, indica al navegador que el recurso solicitado no ha cambiado de ubicacin y que debe solicitar una nueva URL. Adems le insta a modificar cualquier enlace que conserve almacenado o informacin asociada a dicha URL (como por ejemplo, el ndice de Google o Bing). Una redireccin 301 es interpretada por los motores de bsqueda de forma que implica que toda la informacin asociados a la pgina original se transmitan a la de destino, por lo que es el ms aconsejable para trasladar contenido. 302 Found. Indica que un recurso ha sido localizado pero que no ha sido devuelto como parte de la respuesta, indicando una nueva localizacin para el recurso. Est es la opcin que se utiliza cuando queremos efectuar la redireccin de un recurso a otro diferente. El cdigo 302 se suele usar para todos los traslados temporales, donde el servidor responde al navegador indicndole una nueva URL con el nuevo recurso. Es el navegador el que interpreta este cdigo y realiza una nueva peticin (esta vez al nuevo recurso). El siguiente ejemplo muestra una respuesta HTTP 302 en la que navegador redirecciona a un nuevo recurso (Location: /private/index.aspx) HTTP/1.1 302 Found Cache-Control: private, no-cache="Set-Cookie" Content-Type: text/html; charset=utf-8 Location: /private/index.aspx Tambin Es muy comn utilizar el cdigo 302 para controlar la navegacin dentro de un sitio web. 304 Not Modified. Bsicamente indica que el contenido no se ha modificado desde la ltima vez que se solicit. Lo mas normal es que nunca se provoque este estado a propsito, sino que dejemos al servidor decida cuando usarlo. La consecuencia directa en que cuando un navegador recibe est cdigo, la respuesta no contiene contenido alguno es el cuerpo el recurso se obtendr del los archivos temporales almacenados por el navegador en peticiones anteriores. Por ejemplo, si una pgina no se ha modificado, no se transmite de nuevo el contenido de la misma, simplemente se indica que no se ha modificado a travs del cdigo 304 y el navegador utiliza la ltima versin de la que dispone. HTTP/1.1 304 Not Modified Last-Modified: Mon, 06 Aug 2012 17:12:08 GMT Accept-Ranges: bytes
4 de 6
15/10/2013 22:46
ETag: "35ec559cf673cd1:0" Server: Microsoft-IIS/7.5 X-Powered-By: ASP.NET Date: Sat, 22 Sep 2012 22:36:58 GMT Podemos entender mejor este cdigo de estado si pensamos en una imagen que se muestra en una pgina web, la primera vez que visitamos la pgina el servidor nos entrega la imagen, pero en peticiones sucesivas se detecta que la imagen no se ha modificado y se utiliza la versin que se descargo la ultima vez. 400 Bad Request. Este cdigo indica que la solicitud no est correctamente formada. Normalmente se produce este error cuando la URL no es correcta. HTTP/1.1 400 Bad Request Otros errores de la familia 400 son: 401 No autorizado 402 Pago requerido 403 Prohibido 404 Not Found. Sin lugar a dudas el error mas comn. Indica que a pesar de que la peticin es correcta el recurso solicitado no existe en el servidor. Normalmente esto se produce debido a que la URL apunta a un recurso que no existe en el servidor, pero tambin es posible que el servidor este ocultando el recurso intencionadamente. HTTP/1.1 404 Not Found Content-Type: text/html Server: Microsoft-IIS/7.5 X-Powered-By: ASP.NET Date: Sat, 22 Sep 2012 22:51:04 GMT Content-Length: 1245 Tambin se puede producir un error 404 cuando el servidor no tiene configurado el tipo de recurso correctamente. 405 Method Not Allowed. Este cdigo indica que el verbo utilizado en la peticin no es vlido. Se incluye como parte de la respuesta los verbos admitidos por el recurso. HTTP/1.1 405 Method Not Allowed Allow: GET, HEAD, OPTIONS, TRACE Content-Type: text/html 500 Server Error La familia de errores 500 corresponden con errores de servidor. Se pueden deber a multitud de causas, ya que suelen corresponder con un error de nuestra aplicacin. Por ejemplo, si en nuestro programa cometemos un error de programacin e intentamos realizar una divisin por cero, el cliente recibir un error 500 como resultado de la respuesta. Tambin se produce un error 500 cuando el servidor no dispone de los recursos necesarios para atender la peticin. El siguiente ejemplo muestra un ejemplo de peticin a devjoker.com en el que hemos detenido intencionadamente la aplicacin. En este caso obtenemos un error con cdigo 503 que nos indica que la aplicacin no est disponible 503 Service Unavaileable. GET http://devjoker.com/ HTTP/1.1 Accept: text/html, application/xhtml+xml, */* Accept-Language: es-ES User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0) Accept-Encoding: gzip, deflate Host: devjoker.com Connection: Keep-Alive ----------------------------------------------------------------------------------------------------------------------------------HTTP/1.1 503 Service Unavailable Content-Type: text/html; charset=us-ascii Server: Microsoft-HTTPAPI/2.0 Date: Sat, 06 Oct 2012 15:41:03 GMT Connection: close Content-Length: 326
5 de 6
15/10/2013 22:46
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd"> <HTML><HEAD><TITLE>Service Unavailable</TITLE> <META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD> <BODY><h2>Service Unavailable</h2> <hr><p>HTTP Error 503. The service is unavailable.</p> </BODY></HTML> Los errores 500 definidos son: 501 No implementado, 502 Pasarela incorrecta, 503 Servicio no disponible, 504 Tiempo de espera de la pasarela agotado y 505 version not suported. 505 HTTP Version Not Supported. Este error se produce cuando la peticin solicita una versin de HTTP no soportada por el servidor. El siguiente ejemplo muestra una peticin HTTP 2.0, y el error devuelto indicando que el servidor no soporta esta versin de HTTP. GET http://www.devjoker.com/ HTTP/2.0 Host: www.devjoker.com ------------------------------------------------------------------HTTP/1.1 505 HTTP Version Not Supported Content-Type: text/html; charset=us-ascii Server: Microsoft-HTTPAPI/2.0 Un estudio mas detallado del HTTP escapa completamente del mbito de este tutorial donde solo pretendemos dar una breve introduccin para facilitar los conceptos de programacin con ASP.NET MVC que veremos en captulos posteriores.
Analizar el trafico HTTP.

Si queremos analizar el trfico HTTP directamente podemos hacerlo directamente utilizando las herramientas de desarrollo que incorporan casi todos los navegadores (pulsando F12), o bien a travs de herramientas especificas como Fiddler. La siguiente imagen muestra Fiddler utilizado para capturar el trfico.
6 de 6
15/10/2013 22:46

Fundamentos de Funcionamiento de Una Aplicación Web

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Fundamentos de Funcionamiento de Una Aplicación Web

Uploaded by

Copyright:

Available Formats

Fundamentos de funcionamiento de una aplicacin web

www.devjoker.com Fundamentos de funcionamiento de una aplicacin web

Fundamentos de funcionamiento de una aplicacin web

Fundamentos de funcionamiento de una aplicacin web

Cdigos de estado HTTP.

Fundamentos de funcionamiento de una aplicacin web

Fundamentos de funcionamiento de una aplicacin web

Fundamentos de funcionamiento de una aplicacin web

Analizar el trafico HTTP.

You might also like