Diferencia entre revisiones de «HTTP»

Contenido eliminado Contenido añadido
Sin resumen de edición
Etiqueta: editor de código 2017
Sin resumen de edición
Etiqueta: editor de código 2017
Línea 22:
##[[/Conexiones/Conexiones Persistentes|Conexiones Persistentes]]
##[[/Conexiones/Pipelined Connections|Pipelined Connections]]
 
== Peticiones ==
[[Métodos HTTP|Métodos HTTP]]
 
[[El método GET y la seguridad]]
 
[[Ejemplo GET]]
 
<p align= "Justify">
*Tanto GET como POST son métodos de envío de información de formularios válidos y utilizados. Cada uno de los métodos tiene sus ventajas y sus inconvenientes y no se puede decir que uno sea mejor que otro. Elegir entre un método y otro depende de la aplicación concreta a la que se aplicará, por ejemplo si solo deseamos obtener información de cualquier tipo el GET será nuestro mejor aliado, o bien sea para un inicio de sesión o un resgistro de credenciales el método POST se ajustará de una manera válida; y es algo que dentro de las empresas de desarrollos web suelen decidir los encargados del diseño de las aplicaciones. A nosotros en este apartado básico simplemente nos interesa conocer la existencia de ambos métodos y sus características.<br><br>
 
<p align= "Justify">
*GET lleva los datos de forma "visible" al cliente (navegador web). El medio de envío es la URL. Los datos los puede ver cualquiera.<br>
 
*Ejemplo:<br>
 
<form action="http://httpbin.org/image/webp" method ="get">
 
<p align= "Justify">
*Los datos son visibles por la URL, por ejemplo:
http://httpbin.org/image/webp<br><br>
 
 
[[Ejemplo POST]]
 
<p align= "Justify">
*POST consiste en datos "ocultos" (porque el cliente no los ve) enviados por un formulario cuyo método de envío es post. Es adecuado para formularios. Los datos no son visibles.
 
*Ejemplo:
<form action="http://httpbin.org/forms/post" method ="post">
 
<p align= "Justify">
*La ventaja de usar POST es que estos datos no son visibles al usuario de la web. En el caso de usar get, el propio usuario podría modificar la URL escribiendo diferentes parámetros a los reales en su navegador, dando lugar a que la información tratada no sea la prevista.<br><br>
 
<p align= "Justify">
*Fuentes:
.http://www.w3schools.com/tags/ref_httpmethods.asp -- GET Y POST (VS)<br><br>
 
===[[ HTTP Request Headers  (Encabezados de solicitud HTTP) ]]===
 
===[[ The Response (la respuesta) ]]===
 
=== Códigos de Estado===
El código de estado es un número definido por la especificación HTTP, indica que ha pasado con la petición que se hace al servidor. Cada código tiene un significado concreto, todos estos códigos caen en una de las cinco categorías, dichas categorías son:
{| class="wikitable"
|-
! Rango !! Categoria
|-
| 100–199 || Informativo
|-
| 200–299 || Exitoso
|-
| 300–399 || Redirección
|-
| 400–499 || Error de cliente
|-
| 500–599 || Error del servidor
|}
 
Los códigos de estado más comunes son los siguientes:
 
{| class="wikitable"
|-
! Código !! Razón !! Descripción
|-
| 200 || OK || Respuesta estándar para peticiones correctas.
|-
| 301 || Moved Permanently|| El recurso se ha movido a la URL especificada en el encabezado de ubicación y el cliente nunca tiene que comprobar esta URL de nuevo.
|-
| 302 || Moved Temporarily || El recurso se ha movido a la URL especificada en el encabezado de ubicación. En el futuro, el cliente todavía puede solicitar la URL porque es un movimiento temporal.
|-
| 304 || Not Modified || Indica que la petición a la URL no ha sido modificada desde que fue requerida por última vez.
|-
| 400 || Bad Request || La solicitud contiene sintaxis errónea y por lo tanto el servidor no la puede comprender.
|-
| 403 || Forbidden || La solicitud fue legal, pero el servidor rehúsa responderla dado que el cliente no tiene los privilegios para hacerla.
|-
| 404 || Not Found || Recurso no encontrado. Se utiliza cuando el servidor web no encuentra la página o recurso solicitado.
|-
| 500 || Internal Server Error || El servidor encuentra un error en la transmisión de la solicitud. Comúnmente sucede debido a errores de programación en una web solicitud.
|-
| 503 || Service Unavailable || El servidor no puede responder a la petición del navegador porque está congestionado o está realizando tareas de mantenimiento.
|}
 
Estos códigos de estado son una parte muy importante del mensaje que produce el HTTP ya que estos mensajes le dicen al cliente todo lo que sucede al enviar una solicitud al servidor (o en el caso de redirecciones, dónde ir después).
 
=== [[Encabezados de Respuesta]] ===
 
= Conexiones =
[[Redes y Sniffers]]
 
=== HTTP, TCP y la evolución de la Web ===
La web tiene sus inicios en el año 1990 donde su creador sir Tim Berners – lee lanzo el primer sistema de hipertexto, el que llamó enrique, el cual permitía acceder a varias personas a la misma información al mismo tiempo. Este proyecto tuvo gran impacto y poco a poco fue creciendo, y con él se fueron implementando nuevos estándares y protocolos como lo son http y el protocolo de transporte TCP.
En los primeros años de la web, solo se utilizaba un documento o una página donde se cargaba el contenido acerca de un tema, claro está que para esos días no se encontraban tantos usuarios conectados como la demanda que se presenta hoy, por lo cual se utilizaban conexiones simples con el servidor, donde se enviaba una solicitud, se recibía la respuesta, y se cerraba la conexión, además, en el pasado se solicitaba un documento, se leía durante cinco minutos y luego se hacia otra petición.
 
Con la evolución de los dispositivos de hardware y software, y el interés de la población mundial por interconectarse, las conexiones simples y paginas fueron creciendo hasta lo que hoy son. Es por esto que la web de hoy, requiere más de un documento simple para ser lo suficientemente eficaz para los usuarios, por lo cual se habla de combinaciones de imágenes, archivos CSS, archivos JavaScript, videos y contenidos interactivos; lo que implica más de una conexión simple, ya que, si los navegadores web de hoy abren solo una conexión a la vez, y esperan a que cada recurso se descargue completamente antes de iniciar la descarga siguiente, la web se sentiría muy lenta. Es por esto que el Internet está lleno de latencia y Las señales tienen que viajar largas distancias y serpentear a través de diferentes piezas de hardware.
 
La evolución de los documentos simples a complejos páginas ha requerido un poco de ingenio en el uso práctico de http
 
=== Conexiones paralelas ===
La mayoría de los navegadores web, no realizan sus conexiones en serie o una a una. En lugar de ellos, se abren varias conexiones paralelas a un servidor. Por ejemplo, cuando la descarga del código HTML de una página del navegador puede ver dos <img> en la página, por lo que el navegador abiertas dos conexiones paralelas para descargar las dos imágenes al mismo tiempo. El número de conexiones en paralelo depende del agente de usuario y la configuración del agente.
 
Durante muchos años el navegador más popular, fue Internet Explorer (IE) 6, y este navegador obedecía a las reglas mencionadas en las especificaciones HTTP 1.1, que establece:
 
“Un cliente de un solo usuario no debe mantener más de 2 conexiones con cualquier servidor o proxy”.
 
Por esta misma razón el criterio fue instaurado y durante su tiempo de popularidad y uso, solo serían 2 el número máximo de conexiones en paralelo de un navegador. Sin embargo, muchos sitios web, se daban a la tarea de realizar algunos trucos para aumentar el número de descargas paralelas. Por ejemplo, el límite de dos conexiones es per host, es decir, un navegador como Internet Explorer 6 fácilmente, hace dos conexiones en paralelo a www.google.com, y dos conexiones paralelas a imágenes.google.com. Mediante el hosting de imágenes en diferentes servidores, los sitios web podrían aumentar el número de descargas paralelas y hacer que sus páginas se carguen de manera más rápida (incluso si los registros DNS eran creado para señalar las cuatro peticiones al mismo servidor, debido a que el límite de dos conexión es por host nombre, no la dirección IP).
 
En la actualidad este concepto ha cambiado y ahora la mayoría de los sitios web utilizan habilidades heurísticas para decidir el número de conexiones paralelas a establecer. Por ejemplo, Internet Explorer 8 se abrirá hasta con seis conexiones simultáneas.
 
HTTP permite a los clientes abrir múltiples conexiones y realizar múltiples transacciones HTTP en paralelo.
 
Páginas compuestas de objetos incrustados pueden cargar más rápido si se aprovechan de los límites de tiempo y ancho de banda muerta de una única conexión. Los retrasos se pueden superponer, y si una única conexión no satura el
 
ancho de banda de Internet del cliente, el ancho de banda no utilizado pueden ser asignados a la carga de objetos adicionales.
 
La página HTML que encierra se carga por primera vez, y luego los tres restantes transacciones se procesan simultáneamente, cada uno con su propia conexión. Debido a que las imágenes se cargan en paralelo, los retardos en la conexión se solapan.
 
A pesar de que un navegador web soporto varias conexiones paralelas a la vez, la verdadera pregunta es saber ¿qué cantidad de conexiones son demasiadas? Esta pregunta corresponde a que las conexiones en paralelo obedecen a la ley de los rendimientos decrecientes, es decir, que demasiadas conexiones pueden saturar y congestionar la red y pueden perjudicar el rendimiento, sobre todo cuando los dispositivos móviles o redes no confiables son los involucrados.
 
Un servidor, solo puede aceptar un número finito de conexiones, así que si 100.000 navegadores crean simultáneamente 100 conexiones a un solo web 35 servidores, ocurrirán cosas malas. Aun así, el uso de más de una conexión por agente es mejor que descargar todo de una manera en serie.
 
Afortunadamente, las conexiones en paralelo no son la única optimización del rendimiento.
 
Un gran número de conexiones abiertas puede consumir una gran cantidad de memoria y causar problemas de rendimiento de su cuenta. Páginas web complejas pueden tener decenas o cientos de objetos incrustados. Los clientes pueden ser capaces de abrir cientos de conexiones, pero pocos servidores web van a querer hacer eso, porque a menudo están procesando las peticiones de muchos otros usuarios al mismo tiempo. Un centenar de usuarios simultáneos, cada abertura 100 conexiones, se ha puesto la carga de 10.000 conexiones en el
 
servidor. Esto puede causar desaceleración significativa del servidor. La misma situación se aplica a los proxies de alta carga.
 
En la práctica, los navegadores utilizan conexiones en paralelo, pero limitan el número total de conexiones en paralelo a un número pequeño (a menudo cuatro). Los servidores son libres para cerrar las conexiones excesivas de un cliente en particular.
 
 
=== Proxies ===
 
 
Un servidor proxy es un equipo que se encuentra entre un cliente y un servidor. es un servidor transparente para los usuarios finales.