¿Por qué se dice que "HTTP es un protocolo sin estado"?

170

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) donde se pueden enviar varias solicitudes desde la misma conexión TCP.

http stateless

— Jose Nobile
fuente

3

Otra área en la que no veo "apatridia" es la Autorización, particularmente la Autorización por proxy. Parece que tiene estado durante la negociación. Para la autenticación NTLM, el cliente debe recordar el tipo de autenticación proxy y el servidor debe tener estado ya que hay una secuencia de los tipos de mensajes NTLM. Así que no estoy seguro de entender las respuestas.

— Lindsay Morsillo

1

¿Debo agregar ahora HTTP / 1.1? Porque creo que HTTP / 2 tiene estado.

— Jose Nobile

44

HTTP / 2 tiene estado. HTTP 1 no tiene estado. Las adiciones posteriores destinadas a HTTP 1, como las cookies, agregaron estado. Esas adiciones no están separadas de la especificación HTTP 1 "central". Es por eso que se dice que HTTP 1 es un protocolo sin estado, aunque en la práctica no lo es. HTTP / 2, por otro lado, fue diseñado con componentes con estado incorporados. No se requirieron adiciones para satisfacer el requisito de ser etiquetados como "con estado".

— Zamicol

También relacionado: stackoverflow.com/questions/11067500/… stackoverflow.com/questions/36178447/…

— Andrew

130

Aunque se pueden enviar múltiples solicitudes a través de la misma conexión HTTP, el servidor no otorga ningún significado especial a su llegada a través del mismo socket. Eso es solo una cuestión de rendimiento, con la intención de minimizar el tiempo / ancho de banda que de lo contrario se gastaría restablecer una conexión para cada solicitud.

En lo que respecta a HTTP, todas son solicitudes separadas y deben contener suficiente información por sí mismas para cumplir con la solicitud. Esa es la esencia de la "apatridia". Las solicitudes no se asociarán entre sí en ausencia de información compartida que el servidor conozca, que en la mayoría de los casos es una ID de sesión en una cookie.

— cHao
fuente

1

¿Qué sucede cuando el servidor recuerda una sesión (del lado del servidor) y personaliza la experiencia del usuario de acuerdo con ella?

— NurShomik

3

@NurShomik: consulte stackoverflow.com/a/3521393/319403 para obtener una explicación de cómo suelen funcionar las sesiones.

— cHao

12

@ Andrew: HTTP no está "construido en" TCP, y el estado de TCP no es HTTP. Los dos son protocolos completamente separados en diferentes capas en la pila. Podrías servir HTTP sobre canalizaciones con nombre si quisieras, o incluso enviando archivos, si tienes suficientes masoquistas para aceptar hacerlo, y funcionaría precisamente porque HTTP es independiente del protocolo de transporte. En ese nivel, todo son solo solicitudes y respuestas. Eso hace que HTTP no tenga estado, independientemente de qué estado pueda ser usado / mantenido / requerido por los protocolos de nivel inferior o superior.

— cHao

@ cHao De acuerdo, lo concederé. Si definimos la apatridia como "no necesariamente necesita tener un estado para operar" (vea la respuesta de dimo414 a continuación, enumerando las opciones para el estado dentro de HTTP citado de Wikipedia), y si vemos cada protocolo estrictamente por sí mismo y no basado en las capas debajo de él , entonces sí, puedo aceptar que HTTP no tiene estado.

— Andrew

101

De 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 lado 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 apátrida es que el servidor no está obligado a rastrear el estado en múltiples solicitudes, no es que no pueda hacerlo si lo desea. Esto simplifica el contrato entre el cliente y el servidor y, en muchos casos (por ejemplo, el suministro de datos estáticos a través de una CDN) minimiza la cantidad de datos que deben transferirse. Si se servidores necesarios para mantener el estado de las visitas de los clientes de la estructura de la emisión y responder a las solicitudes sería más complejo. Tal como están las cosas, la simplicidad del modelo es una de sus mejores características.

— dimo414
fuente

21

Debido a que un protocolo sin estado no requiere que el servidor retenga información de la 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.

— Rahul Tripathi
fuente

2

Pero, HTTP puede guardar información en el servidor, utilizando cookies. HTTP con keep-alive no cierra la conexión en cada solicitud.

— Jose Nobile el

3

Echa un vistazo a este artículo: - ecst.csuchico.edu/~amk/foo/advjava/notes/servlets/Cookies.html

— Rahul Tripathi

18

Guardar información en el servidor no significa que la conexión esté activa constantemente.

— Sri Lanka el

1

@Srijan Bueno, no. ¿Entonces? Nadie decía lo contrario.

— Mark Amery

10

HTTP se llama como stateless protocolporque cada solicitud se ejecuta de forma independiente, sin ningún conocimiento de las solicitudes que se ejecutaron antes, lo que significa que una vez que finaliza la transacción, también se pierde la conexión entre el navegador y el servidor.

Lo que hace que el protocolo statelesssea que en su diseño original, HTTP es relativamente simple file transfer protocol:

hacer una solicitud para un archivo nombrado por una URL,
obtener el archivo en respuesta,
desconectar.

No se mantuvo ninguna relación entre una conexión y otra, incluso del mismo cliente. Esto simplifica el contrato entre el cliente y el servidor y, en muchos casos, minimiza la cantidad de datos que deben transferirse.

— revs Mobeen Sarwar
fuente

3

Si el protocolo HTTP se proporciona como protocolo de estado completo, la ventana del navegador utiliza una conexión única para comunicarse con el servidor web para múltiples solicitudes dadas a la aplicación web. Esto le da la oportunidad a la ventana del navegador de conectar las conexiones entre la ventana 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, aunque la mayoría de las conexiones en los clientes están inactivas.

— Rajasekhar reddy
fuente

1

HTTP ya tiene keep-alive, esto significa que el servidor no cierra la conexión y el cliente puede hacer muchas solicitudes en la misma conexión.

— Jose Nobile

3

HTTP no tiene conexión y este es un resultado directo de que HTTP es un protocolo sin estado. El servidor y el cliente solo se conocen entre sí durante una solicitud actual. Luego, 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.

— usuario3496740
fuente

1

¿Qué es apátrida?

Una vez que se realiza la solicitud y se devuelve la respuesta al cliente, la conexión se cortará o terminará. El servidor olvidará todo sobre el solicitante.

¿Por qué apátridas?

La web elige el protocolo sin estado. Fue una elección genial porque el objetivo original de la web era permitir que los documentos (páginas web) se sirvieran a un número extremadamente grande. de personas que utilizan hardware muy básico para el servidor.

Mantener una conexión de larga duración habría sido extremadamente intensivo en recursos.

Si se eligiera la web como protocolo con estado, la carga en el servidor se habría incrementado para mantener la conexión del visitante.

— chirag soni
fuente

1

HTTPes apátrida TCPtiene estado No existe el llamado HTTP connection, sino solo HTTP requesty HTTP response. No necesitamos mantener nada para hacer otro HTTP request. Un encabezado de conexión que es "mantener vivo" significa TCPque será reutilizado por las HTTPsolicitudes y respuestas posteriores , en lugar de desconectarse y restablecer la TCPconexión todo el tiempo.

— Xing
fuente

0

Creo que alguien eligió un nombre muy desafortunado para el concepto STATELESS y es por eso que se produce todo el malentendido. No se trata de almacenar ningún tipo de recursos, sino de la relación entre el cliente y el servidor.

Cliente: Mantengo todos los recursos a mi lado y le envío la "lista" de todos los elementos importantes que deben procesarse. Haz tu trabajo.

Servidor: Muy bien ... déjame asumir la responsabilidad de filtrar lo que es importante para darte la respuesta adecuada.

Lo que significa que el servidor es el "esclavo" del cliente y tiene que olvidarse de su "maestro" después de cada solicitud. En realidad, STATELESS se refiere solo al estado del servidor.

https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3

— JacobTheKnitter
fuente