java - sinonimo - ¿Qué significa cuando dicen que http es apátrida?
como ser apatrida (5)
Cuando se dice que algo es sin estado, generalmente significa que no se puede suponer que el servidor rastrea ningún estado entre interacciones.
Por defecto, el protocolo HTTP asume un servidor verdaderamente sin estado. Cada solicitud se trata como una solicitud independiente.
En la práctica, algunos servidores (la mayoría de ellos) lo fixed usando 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 cifrado de Rails), pero básicamente, si desea crecer, necesita encontrar una forma de evitar el seguimiento del estado en el servidor :).
Estoy estudiando Java para web y menciona que http es apátrida. ¿Qué significa eso y cómo afecta la programación?
También estaba estudiando el marco de primavera y allí menciona que algunos granos deben declararse como frijoles internos a medida que cambia su estado. ¿Qué significa eso?
HTTP es sin estado: esto significa que cuando se usa 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.
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. 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.
HTTP se denomina protocolo sin estado porque cada comando se ejecuta de forma independiente, sin ningún conocimiento de los comandos que le precedieron.
Esta deficiencia de HTTP se está abordando en varias tecnologías nuevas, incluidas las cookies .
HTTP, que es el protocolo de transporte real entre el servidor y el cliente, es "sin estado" porque no recuerda nada entre las invocaciones. CADA recurso al que se accede a través de HTTP es una única solicitud sin conexión entre ellos. Si carga una página web con un archivo HTML que contiene tres etiquetas <img> llegan al mismo servidor, habrá cuatro conexiones TCP negociadas y abiertas, cuatro transferencias de datos, cuatro conexiones cerradas. Simplemente no se mantiene ningún estado en el servidor a nivel de protocolo que hará que el servidor sepa algo sobre usted a medida que ingrese.
(Bueno, eso es cierto para HTTP hasta 1.0 en cualquier caso. HTTP 1.1 agrega mecanismos de conexión persistentes de varios tipos debido a los inevitables problemas de rendimiento que engendra un protocolo verdaderamente sin estado. Lo pasaremos por alto por el momento porque realmente no lo hacen hacer HTTP con estado, simplemente lo vuelven sucio: sin estado en lugar de puro sin estado).
Para ayudarlo a comprender la diferencia, imagínese que un protocolo como Telnet o SSH era apátrida. 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 el contenido del directorio, la conexión se cierra. Si luego desea mostrar los contenidos 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 miras 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 desee hacer además de ver 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.
Aquí hay algunos enlaces que puede seguir para obtener una comprensión más profunda de los conceptos: