¿Cómo se entiende el protocolo sin estado y el protocolo con estado? HTTP es un protocolo sin estado y FTP es un protocolo con estado. Para las aplicaciones web que requieren muchas interacciones, el protocolo subyacente debe ser con estado. ¿Es mi entendimiento correcto?protocolo sin estado y protocolo con estado
Como usted pregunta por una aplicación web, el protocolo siempre será sin estado: el protocolo para la Web es http (o https), y eso es todo lo que ella escribió.
Creo que lo que estás pensando es proporcionar un mecanismo de estado en tu aplicación web. El enfoque típico para esto es crear un identificador único para la sesión del usuario en su aplicación web (un sessionID de una forma u otra es la práctica común) que se transfiere entre el navegador y el servidor. Eso normalmente se hace en una cookie, aunque se puede hacer, con un poco más de molestia para usted, dependiendo de su plataforma/marco, también en la URL.
El código del lado del servidor almacena información de estado (de nuevo, normalmente se llama la sesión del usuario), pero quiere usar el ID de sesión para buscarlo. El tráfico http simplemente devuelve el ID de sesión. Mientras ese identificador esté allí, cada transacción http es completamente independiente de todas las demás, por lo tanto, el tráfico de protocolo en sí es sin estado.
Básicamente, sí, pero no tiene más remedio que usar HTTP, que es donde se sirven los sitios web. Por lo tanto, debe lidiar con compromisos para hacer HTTP con estado, también conocido como gestión de sesiones. Las posibilidades son básicamente pasar una identificación de sesión a través de cada llamada en la URL para que sepa cuándo está hablando con alguien de quien ha hablado antes, o mediante cookies, que logran el mismo objetivo sin saturar la url. Sin embargo, la mayoría de los lenguajes modernos de desarrollo web se encargan de eso; si buscas en Google el idioma que elijas + "gestión de sesiones", deberías obtener algunas ideas de cómo se hace.
HTTP es un protocolo sin estado, en otras palabras, el servidor olvidará todo lo relacionado con el estado del cliente/navegador. A pesar de que las aplicaciones web lo han hecho prácticamente parecer con estado.
Un protocolo sin estado se puede forzar a comportarse como si fuera con estado. Esto se puede lograr si el servidor envía el estado al cliente y si el cliente lo envía nuevamente al servidor, siempre.
Hay tres maneras en que esto se puede lograr de HTTP:
a) Uno es galletas, en cuyo caso se envía el estado y devuelto en las cabeceras HTTP.
b) La segunda es la extensión de URL, en cuyo caso el estado se envía como parte de la URL como respuesta.
c) La tercera es "campos de formulario ocultos", en el que se envía el estado al cliente como parte de la respuesta, y la devuelve al servidor como parte de los datos ocultos de un formulario
escalabilidad y alta disponibilidad
Una de las razones principales por las que HTTP escala tan bien es su apatridia. El protocolo sin estado facilita las preocupaciones de replicación, ya que el estado no necesita ser almacenado en el servidor.
Los protocolos de estado son lógicamente pesados para implementar en Internet de manera confiable. Los servidores sin estado también son fácilmente escalables, mientras que para los servidores con estado la escalabilidad es problemática. La solicitud sin estado se puede enviar a cualquier nodo, en cualquier momento, mientras que con Stateful esto no es un caso.
El protocolo HTTP as Stateless aumenta la disponibilidad para aplicaciones web apátridas, que de otro modo serían difíciles o imposibles de implementar. Si se pierde la conexión, no hay un estado que se pierda, la simple solicitud de reenvío resolverá el problema. Las solicitudes sin estado también se pueden almacenar en caché.
http sin estado es un protocol.all las aplicaciones basadas en la Web son sin estado. cuando se envía una solicitud al servidor, se establece una conexión entre el cliente y el servidor, el servidor recibirá la solicitud, procesará la solicitud y devolverá la respuesta, y la conexión se cerrará. si se envía otra solicitud, se tratará como una nueva solicitud y se establecerá una nueva conexión. para hacer http stateful. usamos técnicas de gestión de sesiones. para que utilice los datos provenientes de una solicitud previa mientras procesa la solicitud actual. Es decir, utiliza la misma conexión para una serie de interacciones de servidor de cliente. las técnicas de administración de sesión son: 1. campo de formulario oculto 2.cookie 3.session 4.url-rewriting;
Su pregunta es acertada, y sí, sería genial si sus transacciones web con su banco se realizaron a través de una conexión con estado. Por desgracia, HTTP es sin estado debido a un error peculiar en FTP y un límite de 12 sockets en la tabla de socket parcial en BSD de 1989. Marcus Ranum lo explicó todo here.
Así que HTTP descarta el estado que hereda de TCP y tiene que volver a crear el estado en la capa de aplicación en forma de cookies. La seguridad de internet es el resultado.
El Seif project propone arreglar todo eso usando "JSON seguro sobre TCP". No se requieren las autoridades de DNS y certificado. El protocolo y seifnode.js están terminados y en github con una licencia MIT.
HTTP no 'hereda' de TCP, sino que lo usa para un transporte. HTTP usa TCP para una conexión con estado, pero luego se desconecta. Más tarde se conectará de nuevo, si es necesario. Entonces, mientras navegas por un sitio web, creas muchas conexiones diferentes. Cada una de esas conexiones es explícita, pero la conversación como un todo no lo es, ya que estás abandonando la conexión con cada conversación.