Pourquoi dit-on que «HTTP est un protocole sans état»?

170

HTTP a des cookies HTTP. Les cookies permettent au serveur de suivre l'état de l'utilisateur, le nombre de connexions, la dernière connexion, etc.

HTTP a des connexions persistantes (Keep-Alive) où plusieurs requêtes peuvent être envoyées à partir de la même connexion TCP.

http stateless José Nobile
la source
3
Un autre domaine dans lequel je ne vois pas «apatridie» est celui de l'autorisation - en particulier l'autorisation proxy. Il semble qu'il soit avec état pendant la négociation. Pour l'authentification NTLM, le client doit se souvenir du type d'authentification proxy et le serveur doit être avec état car il existe une séquence vers les types de message NTLM. Je ne suis donc pas sûr de comprendre les réponses.
Lindsay Morsillo
1
Dois-je maintenant ajouter HTTP / 1.1? Parce que je pense que HTTP / 2 a un état.
Jose Nobile
4
HTTP / 2 est avec état. HTTP 1 est sans état. Des ajouts ultérieurs destinés à HTTP 1, comme les cookies, ont ajouté un état. Ces ajouts ne font pas partie de la spécification HTTP 1 "principale". C'est pourquoi HTTP 1 est considéré comme un protocole sans état alors qu'en pratique ce n'est pas le cas. HTTP / 2, d'autre part, a été conçu avec des composants avec état incorporés. Aucun ajout n'a été nécessaire pour satisfaire l'exigence d'être étiqueté «avec état».
Zamicol
Également lié: stackoverflow.com/questions/11067500/… stackoverflow.com/questions/36178447/…
Andrew

Réponses:

130

Même si plusieurs requêtes peuvent être envoyées via la même connexion HTTP, le serveur n'attache aucune signification particulière à leur arrivée sur la même socket. C'est uniquement une question de performance, destinée à minimiser le temps / la bande passante qui serait autrement passé à rétablir une connexion pour chaque demande.

En ce qui concerne HTTP, il s'agit toujours de requêtes distinctes et doivent contenir suffisamment d'informations à elles seules pour répondre à la requête. C'est l'essence même de «l'apatridie». Les demandes ne seront pas associées les unes aux autres en l'absence d'informations partagées dont le serveur a connaissance, qui dans la plupart des cas est un identifiant de session dans un cookie.

cHao
la source
1
Que se passe-t-il lorsque le serveur se souvient d'une session (côté serveur) et personnalise l'expérience utilisateur en fonction de celle-ci?
NurShomik
3
@NurShomik: consultez stackoverflow.com/a/3521393/319403 pour une explication du fonctionnement des sessions.
cHao
12
@Andrew: HTTP n'est pas "construit sur" TCP, et l'état de TCP n'est pas celui de HTTP. Les deux sont des protocoles entièrement distincts à différentes couches de la pile. Vous pouvez servir HTTP sur des canaux nommés si vous le souhaitez, ou même en envoyant des fichiers, si vous avez suffisamment de masochistes pour accepter de le faire, et cela fonctionnerait précisément parce que HTTP est indépendant du protocole de transport. À ce niveau, ce ne sont que des demandes et des réponses. Cela rend HTTP lui-même sans état, quel que soit l'état qui peut être utilisé / maintenu / requis par des protocoles de niveau inférieur ou supérieur.
cHao
@cHao D'accord, je concède. Si nous définissons l'apatridie comme «n'ayant pas nécessairement besoin d'un état pour fonctionner» (voir la réponse de dimo414 ci-dessous énumérant les options d'état dans HTTP citées sur Wikipedia), et si nous considérons chaque protocole strictement seul et non en fonction des couches en dessous , alors oui, je peux convenir que HTTP est "sans état".
Andrew
101

De Wikipedia :

HTTP est un protocole sans état. Un protocole sans état n'exige pas que le serveur conserve les informations ou l'état de chaque utilisateur pendant la durée de plusieurs demandes.

Mais certaines applications Web peuvent devoir suivre la progression de l'utilisateur d'une page à l'autre, par exemple lorsqu'un serveur Web est nécessaire pour personnaliser le contenu d'une page Web pour un utilisateur. Les solutions pour ces cas incluent:

  • l'utilisation de cookies HTTP.
  • sessions côté serveur,
  • variables masquées (lorsque la page courante contient un formulaire), et
  • Réécriture d'URL à l'aide de paramètres encodés en URI, par exemple /index.php?session_id=some_unique_session_code.

Ce qui rend le protocole sans état, c'est que le serveur n'est pas obligé de suivre l'état sur plusieurs demandes, pas qu'il ne peut pas le faire s'il le souhaite. Cela simplifie le contrat entre le client et le serveur et, dans de nombreux cas (par exemple, la diffusion de données statiques sur un CDN) minimise la quantité de données à transférer. Si les serveurs étaient tenus de maintenir l'état des visites des clients, la structure d'émission et de réponse aux demandes serait plus complexe. En l'état, la simplicité du modèle est l'une de ses plus grandes caractéristiques.

dimo414
la source
21

Parce qu'un protocole sans état n'exige pas que le serveur conserve les informations de session ou l'état de chaque partenaire de communication pendant la durée de plusieurs demandes.

HTTP est un protocole sans état, ce qui signifie que la connexion entre le navigateur et le serveur est perdue une fois la transaction terminée.

Rahul Tripathi
la source
2
Mais, HTTP peut enregistrer des informations sur le serveur, en utilisant des cookies. HTTP avec keep-alive ne ferme pas la connexion à chaque demande.
Jose Nobile
3
Consultez cet article: - ecst.csuchico.edu/~amk/foo/advjava/notes/servlets/Cookies.html
Rahul Tripathi
18
L'enregistrement d'informations sur le serveur ne signifie pas que la connexion est active en permanence.
srijan
1
@srijan Eh bien, non. Alors? Personne ne prétendait le contraire.
Mark Amery
10

HTTP est appelé stateless protocolcar chaque requête est exécutée indépendamment, sans aucune connaissance des requêtes qui ont été exécutées avant elle, ce qui signifie qu'une fois la transaction terminée, la connexion entre le navigateur et le serveur est également perdue.

Ce qui rend le protocole, statelessc'est que dans sa conception originale, HTTP est relativement simple file transfer protocol:

  1. faire une demande pour un fichier nommé par une URL,
  2. obtenir le fichier en réponse,
  3. déconnecter.

Il n'y avait aucune relation entretenue entre une connexion et une autre, même du même client. Cela simplifie le contrat entre le client et le serveur et, dans de nombreux cas, minimise la quantité de données à transférer.

Mobeen Sarwar
la source
3

Si le protocole HTTP est donné en tant que protocole complet d'état, la fenêtre du navigateur utilise une connexion unique pour communiquer avec le serveur Web pour les demandes multiples envoyées à l'application Web.Cela donne la possibilité à la fenêtre du navigateur d'engager les connexions entre la fenêtre du navigateur et les serveurs Web pendant longtemps et de conserver dans un état inactif pendant une longue période.Cela peut créer la situation d'atteindre le maximum de connexions du serveur Web même si la plupart des connexions dans les clients sont inactives.

Rajasekhar reddy
la source
1
HTTP a déjà keep-alive, cela signifie que le serveur ne ferme pas la connexion et que le client peut faire de nombreuses requêtes sur la même connexion.
Jose Nobile
3

HTTP est un protocole sans connexion et c'est un résultat direct que HTTP est un protocole sans état. Le serveur et le client ne se connaissent que lors d'une requête en cours. Ensuite, les deux s'oublient. En raison de cette nature du protocole, ni le client ni le navigateur ne peuvent conserver les informations entre les différentes demandes sur les pages Web.

utilisateur3496740
la source
1

Qu'est-ce que l'apatride ??

Une fois la demande effectuée et la réponse renvoyée au client, la connexion sera abandonnée ou interrompue. Le serveur oubliera tout sur le demandeur.

Pourquoi apatride ??

Le Web choisit d'opter pour le protocole sans état. C'était un choix génial car le but initial du Web était de permettre aux documents (pages Web) d'être servis à des non extrêmement volumineux. des personnes utilisant du matériel très basique pour le serveur.

Le maintien d'une connexion de longue durée aurait été extrêmement gourmand en ressources.

Si le Web avait été choisi comme protocole avec état, la charge sur le serveur aurait été augmentée pour maintenir la connexion du visiteur.

chirag soni
la source
1

HTTPest apatride. TCPest avec état. Il n'y a pas de soi-disant HTTP connection, mais seulement HTTP requestet HTTP response. Nous n'avons besoin de rien à entretenir pour en faire un autre HTTP request. Un en-tête de connexion qui est "keep-alive" signifie que le TCPsera réutilisé par les HTTPdemandes et réponses suivantes, au lieu de se déconnecter et de rétablir la TCPconnexion tout le temps.

Xing
la source
0

Je pense que quelqu'un a choisi un nom très malheureux pour le concept STATELESS et c'est pourquoi tout le malentendu est causé. Il ne s'agit pas de stocker tout type de ressources, mais plutôt de la relation entre le client et le serveur.

Client: Je garde toutes les ressources de mon côté et vous envoie la "liste" de tous les éléments importants à traiter. Fais ton travail.

Serveur: Très bien .. laissez-moi prendre la responsabilité de filtrer ce qui est important pour vous donner la bonne réponse.

Ce qui veut dire que le serveur est "l'esclave" du client et doit oublier son "maître" après chaque requête. En fait, STATELESS se réfère uniquement à l'état du serveur.

https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3

JacobTheKnitter
la source