http - person - stateless traduccion
¿Por qué decir que HTTP es un protocolo sin estado? (6)
HTTP tiene cookies HTTP. Las cookies permiten al servidor rastrear el estado del usuario, el número de conexiones, la última conexión, etc.
HTTP tiene conexiones persistentes (Keep-Alive), varias solicitudes pueden enviarse en la misma conexión TCP.
Aunque se pueden enviar múltiples solicitudes a través de la misma conexión HTTP, el servidor no agrega ningún significado especial a su llegada sobre el mismo socket. Eso es únicamente una cuestión de rendimiento, con la intención de minimizar el tiempo / ancho de banda que de otra manera se gastaría en restablecer una conexión para cada solicitud.
En lo que respecta a HTTP, todas siguen siendo solicitudes separadas y deben contener suficiente información para cumplir con la solicitud. Esa es la esencia de la "apatridia". Las solicitudes no se asociarán entre sí en ausencia de alguna información compartida que el servidor conozca, que en la mayoría de los casos es una identificación de sesión en una cookie.
De la Wikipedia :
HTTP es un protocolo sin estado. Un protocolo sin estado no requiere que el servidor retenga información o estado sobre cada usuario durante la duración de múltiples solicitudes.
Pero algunas aplicaciones web pueden tener que rastrear el progreso del usuario de una página a otra, por ejemplo, cuando se requiere un servidor web para personalizar el contenido de una página web para un usuario. Las soluciones para estos casos incluyen:
- el uso de cookies HTTP.
- sesiones del servidor,
- variables ocultas (cuando la página actual contiene un formulario), y
- Reescritura de URL utilizando parámetros codificados por URI, por ejemplo, /index.php?session_id=some_unique_session_code.
Lo que hace que el protocolo sea sin estado es que no se requiere que el servidor rastree el estado sobre múltiples solicitudes, no es que no pueda hacerlo si así lo desea. Esto simplifica el contrato entre el cliente y el servidor, y en muchos casos (por ejemplo, al proporcionar datos estáticos a través de una CDN) minimiza la cantidad de datos que se deben transferir. Si los servidores tuvieran que mantener el estado de las visitas de los clientes, la estructura de emisión y respuesta a las solicitudes sería más compleja. Tal como es, la simplicidad del modelo es una de sus mejores características.
Debido a que un protocolo sin estado no requiere que el servidor retenga la información de sesión o el estado de cada socio de comunicaciones durante la duración de múltiples solicitudes.
HTTP es un protocolo sin estado, lo que significa que la conexión entre el navegador y el servidor se pierde una vez que finaliza la transacción.
HTTP no tiene conexión y este es un resultado directo de que HTTP es un protocolo sin estado. El servidor y el cliente son conscientes el uno del otro solo durante una solicitud actual. Después, ambos se olvidan el uno del otro. Debido a esta naturaleza del protocolo, ni el cliente ni el navegador pueden retener información entre diferentes solicitudes en las páginas web.
Si el protocolo HTTP se proporciona como protocolo de estado completo, la ventana del navegador usa una única conexión para comunicarse con el servidor web para solicitudes múltiples a la aplicación web. Esto da la oportunidad a la ventana del navegador de conectar las ventanas del navegador y los servidores web durante mucho tiempo y mantener en estado inactivo durante mucho tiempo. Esto puede crear la situación de alcanzar las conexiones máximas del servidor web a pesar de que la mayoría de las conexiones en los clientes están inactivas.
No es apátrida. HTTP (generalmente) está construido sobre TCP, que es con estado. Mantiene la información de conexión, como mínimo. Si se construyera en UDP, las cosas serían diferentes.
Decir que HTTP es sin estado es como decir que los programas de computadora no tienen electrón porque las computadoras que los alojan son los que usan los electrones. Eso es una tontería. De la misma manera, no puede separar completamente HTTP de TCP.
