protocolo sin estado y protocolo con estado

HTTP es un protocolo sin estado, en otras palabras, el servidor olvidará todo lo relacionado con el estado del cliente/navegador. Aunque las aplicaciones web han hecho que parezca virtualmente con estado.

Un protocolo sin estado puede ser forzado a comportarse como si tuviera estado. Esto se puede lograr si el servidor envía el estado al cliente, y si el cliente a lo envía de nuevo al servidor, cada vez.

Hay tres maneras de lograr esto en HTTP:

A) Uno es cookies, en cuyo caso el estado se envía y devuelve en encabezados HTTP.

B) La segunda es la extensión URL, en cuyo caso el estado se envía como parte de la URL como respuesta.

C) El tercero es "campos de formulario ocultos", en el que el estado se envía al cliente como parte de la respuesta, y se devuelve al servidor como parte de los datos ocultos de un formulario

ESCALABILIDAD Y ALTA DISPONIBILIDAD

Una de las principales razones por las que HTTP se escala tan bien es su apatridia. Apátridas el protocolo facilita las preocupaciones de replicación, ya que el estado en sí no necesita almacenarse en el servidor.

Los protocolos con 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.

HTTP como protocolo sin estado aumenta la disponibilidad para aplicaciones web sin estado, que de otro modo ser difícil o imposible de implementar. Si se pierde la conexión, no hay ningún estado que se pierda, el reenvío de solicitud simple resolverá el problema. Las solicitudes apátridas también pueden almacenarse en caché.

Ver más aquí

Http es un protocolo sin estado.todas las aplicaciones basadas en web son apátridas. cuando se envía una solicitud al servidor se establece una conexión entre cliente y servidor,el servidor recibirá la solicitud ,procesará la solicitud y devolverá la respuesta., y la conexión está cerrada. si se envía otra solicitud, se tratará como una nueva solicitud y se establecerá una nueva conexión. para hacer http con estado. utilizamos técnicas de gestión de sesiones. para que utilice los datos que vienen de la solicitud anterior mientras se procesa la solicitud actual.es decir, utiliza la misma conexión para una serie de interacciones cliente-servidor. las técnicas de gestión de sesiones son: 1.campo de formulario oculto 2.cookie 3.sesion 4.url-reescritura;

Su pregunta es acertada, y sí, sería genial si sus transacciones web con su banco se realizaran a través de una conexión con estado. Por desgracia, HTTP es apátrida debido a un error peculiar en FTP y un límite de 12 sockets en la tabla de sockets parciales en BSD de 1989. Marcus Ranum lo explicó todo aquí.

Así que HTTP tira el estado que hereda de TCP y tiene que recrear el estado en la capa de aplicación en forma de cookies. La mala seguridad en Internet es el resultado.

El Seif project propone arreglar todo esto usando "secure JSON over TCP". No se requieren DNS ni entidades de certificación. El protocolo y el 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. Por lo tanto, mientras navega por un sitio web, crea muchas conexiones diferentes. Cada una de esas conexiones es stateful, pero la conversación en su conjunto no lo es, ya que está dejando de lado la conexión con cada conversación.

Desde este enlace

Básicamente sí, pero no tiene más remedio que usar HTTP, que es donde se sirven los sitios web. Así que tienes que lidiar con compromisos para hacer que HTTP tenga estado, también conocido como administración de sesiones. Las posibilidades son básicamente pasar un id de sesión a través de cada llamada en la URL para que sepas cuándo estás hablando con alguien de quien has hablado antes, o a través de cookies, que logran el mismo objetivo sin saturar la url. Sin embargo, la mayoría de los lenguajes de desarrollo web modernos se encargan de eso por usted; si busca en Google el idioma de su elección + "gestión de sesiones" usted debe obtener algunas ideas de cómo se hace.