¿Cómo se vuelve sin estado HTTP?


26

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?


66
¿Cómo es que esto no es un duplicado 5 años después del lanzamiento de Super User?
Peter Mortensen

¿Porque la mayoría de los engañados están en StackOverflow? Solo estoy adivinando.
trysis

8
El hecho de que atraviese cables (entre otros) tampoco lo convierte en un protocolo eléctrico
Hagen von Eitzen el

Respuestas:


42

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.


1
El enrutamiento ocurre en el nivel tcp / ip.
Fiasco Labs

3
Esta imagen lo explica muy bien. vichargrave.com/wp-content/uploads/2013/01/…
JakeGould

2
Coincidentemente, el hecho de que HTTP ignore la capacidad de estado de la conexión subyacente (que casi siempre será TCP) es uno de los principales déficits de rendimiento que varios enfoques HTTP2 están tratando de solucionar.
skolima

2
@Fiasco: estrictamente hablando, el enrutamiento se produce a nivel de IP. El enrutamiento se basa en direcciones de Internet, no se utiliza información de la capa TCP en el enrutamiento básico.
RedGrittyBrick

1
@skolima: por otro lado, la apatridia es la razón por la cual HTTP es el protocolo más escalable y confiable en uso generalizado. HTTP siempre se ha diseñado explícitamente para la escalabilidad en lugar del rendimiento (sí, son algo diferente), por lo que si cree que necesita una latencia muy baja, está utilizando el protocolo incorrecto o está utilizando el protocolo incorrectamente. Si bien HTTP2 tiene la intención de mejorar el rendimiento, lo hace de una manera que se mantiene fiel a la apatridia. Cuando se usa para lo que está destinado, nunca había visto la apatridia como un cuello de botella de una aplicación HTTP bien diseñada.
Lie Ryan

10

"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.


can also easily be handled by different server and the client will never knowAunque técnicamente es cierto, esto es engañoso ya que muchas aplicaciones web usan sesiones fijas, lo que requiere un equilibrador de carga para enrutar las solicitudes futuras de la misma sesión de navegación al mismo servidor. Desde una perspectiva HTTP, las sesiones son irrelevantes, pero su última oración implica que la experiencia del usuario final no se verá afectada, lo que sería falso con las sesiones fijas.
Brandon

1
@ Brandon: ¡Tales aplicaciones crean un protocolo con estado sobre HTTP y este es su castigo por ello!
Jan Hudec

@Brandon: muchos servidores con equilibrio de carga, como gmail, no envían solicitudes al mismo servidor. En cambio, la sesión se almacena en una base de datos compartida a la que pueden acceder todos los servidores del clúster. Por lo tanto, el estado no lo maneja el servidor sino la base de datos.
slebetman

@Slebetman: Sí, lo que sea. HTTP en sí no tiene ese estado, por lo que para HTTP es simple. Si la aplicación agrega algún estado propio, es su lucha.
Jan Hudec

Bien, no dije todo. Dije algo. Personalmente prefiero evitar las sesiones adhesivas y, si es posible, evitar las sesiones por completo. Sin embargo, existe un software que no está a la altura del ideal de todos.
Brandon

2

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.


1

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.


1
El problema con el modelo OSI es que ahora es teórico (hubo intentos reales de implementarlo, pero fallaron en el mercado debido a su complejidad). En realidad, no hay capas entre TCP y HTTP. Además, la capa de presentación sería HTML, no HTTP.
MSalters

En el modelo TCP / IP, TCP no vive en la capa de red. Vive en la capa de transporte encima de IP, que está en la red más adelante. El primer hit de Google para el "modelo TCP" lo demuestra: technet.microsoft.com/en-us/library/cc786900(v=ws.10).aspx
Brandon

@MSalters: ¿TLS no es una capa?
Grawity

1
@MSalters: ¿Te das cuenta de que HTTPS es simplemente el nombre dado por HTTP que está siendo tunelizado por TLS? Como tal, TLS es una capa bajo HTTP y encima de TCP y TLS / SSL + HTTP combo se llama HTTPS.
slebetman

1
Además, hay otro nombre nuevo para el combo TLS / HTTP. Si el TLS que transporta el tráfico HTTP implementa multiplexación de socket / secuencia virtual se llama SPDY (pero la url en su navegador sigue siendo HTTPS).
slebetman
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.