¿Cómo se vuelve sin estado HTTP?

Se dice que HTTP no tiene estado. Es decir, no necesita almacenar información para la transmisión de datos.

Pero HTTP usa TCP, que está orientado al estado.

Si ese es el caso, ¿cómo se vuelve HTTP sin estado?

HTTP no se preocupa, y es independiente de, ninguno de los protocolos de nivel inferior utilizados para transportarse a sí mismo, aunque no tenga estado.

La tecnología de transporte puede ser TCP, o el antiguo SPX de Novell, o SCTP, o cualquier otra cosa que pueda imaginar, y HTTP seguirá funcionando igual. HTTP requiere un protocolo orientado a la transmisión o la conexión, y depende de que las URL se puedan resolver, pero no le importa cómo se logra.

Esta es una de las razones por las que existe el modelo en capas o la pila de red: la capa de aplicación no necesita preocuparse por las capas inferiores.

El hecho de que un protocolo de nivel inferior tenga estado no significa que nada encima de él se convierta automáticamente en estado o se requiera que lo sea.

HTTP en sí no tiene estado. Eso significa que las aplicaciones tienen que implementar otra capa sobre HTTP para establecer el estado. Esto normalmente se hace con cookies de sesión.

"HTTP no tiene estado" significa que cada transacción HTTP (par de solicitud-respuesta) puede procesarse independientemente de cualquier estado del par de solicitud-respuesta anterior.

Para transportar el par de solicitud-respuesta particular, necesita un protocolo que pueda transportar allí un bloque arbitrariamente grande y un bloque arbitrariamente grande, y para hacerlo sobre una capa con un tamaño de paquete limitado, el TCP debe tener estado.

Pero a través del límite de la transacción, no hay estado. El cliente puede desconectar la conexión y establecer una nueva para la próxima solicitud. De hecho, esa era la única opción en las primeras versiones y todavía funciona así si el cliente no incluye el Connection: keep-aliveencabezado.

La siguiente solicitud también puede ser manejada fácilmente por un servidor diferente y el cliente nunca lo sabrá, porque el servidor no necesita mantener ningún estado (a menos que la aplicación agregue su propio estado sobre HTTP, generalmente en forma de sesión; las consiguientes complicaciones en el equilibrio de carga es su castigo por construir un protocolo con estado en HTTP). Eso se aprovecha en los servidores ocupados de equilibrio de carga.

La naturaleza "sin estado" de HTTP significa que en esta capa, no se crea ni se utiliza información de estado.

Puede ver esto en algunos casos, por ejemplo en la autenticación HTTP, las credenciales se envían con cada solicitud, y las conexiones persistentes son realmente solo una optimización (es decir, si envío credenciales, el servidor las olvida después de la solicitud, incluso si se va La conexión abierta).

Por el contrario, los mecanismos de inicio de sesión basados ​​en cookies tienen estado, pero no forman parte de HTTP.

Tienes que entenderlo como un conjunto de muñecas rusas (o cajas si lo deseas), cada una de ellas con otra dentro, así es como funciona: TCP lleva HTTP "dentro" pero no le importa ni sus características.

Para obtener una imagen completa, recomiendo leer sobre el modelo OSI, ya que lo aclara.

TCP se encuentra algunas capas debajo de HTTP en el modelo OSI, de hecho, cada capa corresponde a un protocolo diferente.

En nuestro caso, HTTP se encuentra en las capas de presentación y aplicación y TCP en la capa de transporte. O si utiliza el modelo TCP / IP, tanto el protocolo TCP como el IP se encuentran en la capa de enlace de red y HTTP en las capas de aplicación y presentación.