Estoy estudiando Java para web y menciona que http es apátrida. qué significa eso y cómo afecta la programaciónqué significa cuando dicen que http es stateless
También estaba estudiando el marco de resorte y allí menciona que algunos granos deben declararse como granos internos a medida que cambia su estado. ¿Qué significa eso?
HTTP - que es el protocolo de transporte real entre el servidor y el cliente - es "sin estado", ya que no recuerda nada entre invocaciones. CADA recurso al que se accede a través de HTTP es una solicitud única sin conexión entre ellos.Si carga una página web con un archivo HTML que contiene tres etiquetas <img> que llegan al mismo servidor, habrá cuatro conexiones TCP negociadas y abiertas, cuatro transferencias de datos, cuatro conexiones cerradas. Simplemente no hay Estado mantiene en el servidor en el protocolo de nivel que tendrá el servidor saber nada de ti ya que vienen.
(Bueno, eso es cierto para HTTP hasta 1,0, en todo caso. HTTP 1.1 agrega persistentes mecanismos de conexión de varios tipos debido a los inevitables problemas de rendimiento que engendra un protocolo verdaderamente sin estado. Vamos a pasar por alto esto por el momento porque realmente no hacen HTTP con estado, simplemente lo vuelven sucio: sin estado en lugar de pura- sin estado.)
Para ayudarlo a comprender la diferencia, imagine que un protocolo como Telnet o SSH no tiene estado. Si desea obtener una lista de directorios de un archivo remoto, deberá, como una operación atómica, conectarse, iniciar sesión, cambiar al directorio y emitir el comando ls. Cuando el comando ls termina de mostrar los contenidos del directorio, la conexión se cierra. Si luego desea mostrar el contenido de un archivo específico, deberá volver a conectarse, iniciar sesión, cambiar al directorio y ahora emitir el comando cat. Cuando finaliza el comando que muestra el archivo, la conexión se cierra nuevamente.
Cuando lo ves de esa manera, aunque el objetivo de Telnet/SSH, suena bastante estúpido, ¿no? Bueno, de alguna manera es y de alguna manera no lo es. Cuando un protocolo es sin estado, el servidor puede hacer optimizaciones bastante buenas y los datos se pueden distribuir fácilmente. Los servidores que usan protocolos sin estado pueden escalar de manera muy efectiva, así que mientras las transferencias de datos individuales pueden ser muy lentas (abrir y cerrar conexiones TCP NO es barato) un sistema general puede ser muy, muy eficiente y puede escalar a cualquier cantidad de usuarios.
Pero ...
Casi cualquier cosa que usted quiere hacer que no sea la visualización de páginas web estáticas implicará sesiones y estados. Cuando HTTP se utiliza para su propósito original (compartir información estática como documentos científicos), el protocolo sin estado tiene mucho sentido. Cuando empiezas a usarlo para cosas como aplicaciones web, tiendas en línea, etc., la apatridia comienza a ser una molestia porque se trata de actividades inherentemente con estado. Como resultado, las personas rápidamente descubrieron formas de unificar el estado sobre el protocolo sin estado. Estos mecanismos han incluido cosas como las cookies, como el estado de codificación en las URL y que el servidor active dinámicamente los datos, como las solicitudes de estado ocultas, como ... bueno, como un montón de cosas que incluyen las más modernas. cosas como Web Sockets.
Éstos son algunos enlaces se puede seguir para obtener una comprensión más profunda de los conceptos:
gracias por cosas útiles, pero supongamos que si http2.1 se convierte en stateful entonces cómo se visualiza el actual chnage de escenario con respecto a la página web. Quiero decir que quiero ver el diff de vez en cuando –
1.1, no 2.1. ;) Y como he dicho, HTTP 1.1 realmente no se vuelve con estado. Solo tiene algunos trucos de optimización que le permiten reutilizar conexiones, etc. Desde la perspectiva del navegador web, significa que sus sitios web se cargan más rápido porque solo tiene que negociar la conexión TCP una vez para esos archivos HTML + 3 imágenes (para usar mi ejemplo) en lugar de 4 veces. –
por qué no pueden hacerlo con estado. ¿Hay algún problema de programación o no se puede hacer –
HTTP se denomina protocolo sin estado porque cada comando se ejecuta independientemente, sin ningún conocimiento de los comandos que le precedieron.
Esta deficiencia de HTTP se está abordando en una serie de nuevas tecnologías, que incluyen cookies.
ActiveX, Java y Javascript no abordan el hecho de que http es apátrida, aprovechan las cookies, la reescritura de URL, etc. para mantener el estado – Luis
HTTP es sin estado: esto significa que al usar HTTP, el punto final no "recuerda" cosas (como quién es usted). No tiene estado. Esto está en contraste con una aplicación de escritorio: si tiene un formulario y va a un formulario diferente, entonces regrese, el estado se ha retenido (siempre y cuando no haya cerrado la aplicación).
Normalmente, para mantener el estado en la aplicación web, uno usa cookies.
puedes dar un ejemplo de protocolo que recuerde el estado para que pueda comparar –
@Name - [TCP] (http://en.wikipedia.org/wiki/Transmission_Control_Protocol) es un protocolo que conserva algún estado. – Oded
Aunque no se pretende por el uso de la red, la familia de protocolos XYZModem (XModem, YModem, y así sucesivamente) son stateful – alvaroc
Cuando se dice que algo es sin estado, generalmente significa que no se puede suponer que el servidor rastrea ningún estado entre interacciones.
De forma predeterminada, el protocolo HTTP supone un servidor verdaderamente sin estado. Cada solicitud se trata como una solicitud independiente.
En la práctica esto es fixed por algunos servidores (la mayoría de ellos) que utilizan una cookie de seguimiento en la solicitud para hacer coincidir algún estado en el servidor con un cliente específico. Esto funciona porque funcionan las cookies (se publican en el servidor en cada solicitud posterior una vez que se han establecido en el cliente).
Básicamente, un servidor que no es apátrida es un impedimento para escalar. Debe asegurarse de enrutar todas las solicitudes desde un navegador específico a la misma instancia o hacer la replicación de respaldo de los estados. Esto generalmente es un factor limitante al intentar escalar una aplicación.
Existen otras soluciones para realizar un seguimiento del estado (consulte la cookie de estado encriptada de Rails) pero básicamente, si desea crecer, necesita encontrar una forma de evitar el seguimiento del estado en el servidor :).
Un protocolo sin estado no requiere que el servidor retenga información o el estado de cada usuario durante la duración de varias solicitudes. Por ejemplo, cuando se requiere que un servidor web personalice el contenido de una página web para un usuario, la aplicación web puede tener que rastrear el progreso del usuario de una página a otra.
Una solución común es el uso de cookies HTTP. Otros métodos incluyen sesiones del lado del servidor, variables ocultas (cuando la página actual es un formulario) y reescritura de URL usando parámetros codificados por URI, por ejemplo, /index.php?session_id=some_unique_session_code.
Danos alguna referencia de reserva/papel que estás estudiando. No entiendo por qué están conectando el estado de un protocolo de red con el estado de un objeto en una sola pregunta? ¿Dónde podemos encontrar esa información sobre Spring beans que usted mencionó? – Ritesh