que veut-il dire quand ils disent que http est sans état

Je suis l'étude java pour le web et il mentionne http est sans état.
ce que cela signifie et comment il les effets de la programmation

J'étais également en train d'étudier le framework spring et là il mentionne quelques grains ont déclaré que les centres de haricots que leurs changements d'état . Que signifie?

  • Nous donner une référence de livre/papier que vous étudiez. Je ne comprends pas pourquoi êtes-vous clubbing ensemble de l'état d'un protocole de gestion de réseau avec un état d'un objet dans une seule question? Où l'on peut trouver l'information sur les beans Spring que vous avez mentionné?
InformationsquelleAutor | 2011-02-06
  1. 62

    HTTP -- c'est le protocole de transport entre le serveur et le client-est "apatride", car il ne se souvient de rien entre les appels. CHAQUE ressource qui est accessible via HTTP est une demande unique sans raccord fileté entre eux. Si vous chargez une page web avec un fichier HTML à l'intérieur il contient trois <img> balises de frapper le même serveur, il y aura quatre connexions TCP négocié et ouvert, quatre transferts de données, quatre connexions fermé. Il n'y a tout simplement pas de l'état conservés sur le serveur à la protocole niveau qui auront le serveur sait rien de vous, comme vous venez.

    (Bon, c'est vrai pour HTTP jusqu'à 1,0 en tout cas. HTTP 1.1 ajoute connexion persistante des mécanismes de diverses sortes, à cause des inévitables problèmes de performance qu'une véritable protocole sans état engendre. Nous allons l'ignorer pour le moment car ils n'ont pas vraiment HTTP stateful, ils ont simplement sale apatrides au lieu de pure apatrides.)

    Pour vous aider à comprendre la différence, imaginez qu'un protocole comme Telnet ou SSH sont apatrides. Si vous voulais me faire une liste de répertoire un fichier distant, vous devez, comme une seule opération atomique, se connecter, connectez-vous, sélectionnez le répertoire et le problème de la ls de commande. Lorsque le ls commande fini d'afficher le contenu d'un répertoire, la connexion serait fermer. Ensuite, si vous souhaitez afficher le contenu d'un fichier spécifique, vous avez à nouveau de vous connecter, de connexion, modifiez le répertoire et maintenant problème de la cat de commande. Lors de la commande de l'affichage du fichier terminé, la connexion devrait se rapprocher de nouveau.

    Quand vous regardez cela de cette façon, si l'objectif de Telnet/SSH, cela semble assez stupide, n'est-ce pas? Eh bien, à certains égards, il est et, à certains égards, il n'est pas. Lorsqu'un protocole est apatride, le serveur peut faire pas mal d'optimisations et les données peuvent être réparties autour facilement. Serveurs à l'aide de protocoles sans état peut évoluer de manière très efficace, de sorte que la personne les transferts de données peuvent être très lente (l'ouverture et la fermeture des connexions TCP n'est PAS bon marché!) l'ensemble du système peut être très, très efficaces et peuvent s'adapter à n'importe quel nombre d'utilisateurs.

    Mais...

    Presque tout ce que vous voulez faire d'autre que de la visualisation de pages web statiques impliquera des sessions et des états. Quand HTTP est utilisé pour son objectif initial (partage d'informations statiques comme les articles scientifiques) le protocole sans état fait beaucoup de sens. Lorsque vous commencez à l'utiliser pour des choses comme des applications web, des boutiques en ligne, etc. puis l'apatridie commence à être une gêne, car ils sont par essence dynamique des activités. Comme résultat que les gens très rapidement venu à barbouiller de l'état sur le haut du protocole sans état. Ces mécanismes ont inclus des choses comme les cookies, comme l'encodage de l'état dans l'Url et avoir le serveur de façon dynamique le feu jusqu'à des données basées sur des ceux qui, comme cachés de l'état des demandes, comme ... eh bien, comme tout un tas de choses jusqu'à et y compris la plus moderne des choses comme les Web Sockets.

    Voici quelques liens que vous pouvez suivre afin d'obtenir une meilleure compréhension des concepts:

    • merci pour les choses utiles , mais supposons que si http2.1 devient stateful alors comment scénario actuel chnage à l'égard de l'affichage des pages web. je veux dire, je veux voir la diff maintenant et puis
    • 1.1, pas 2.1. 😉 Et comme je l'ai dit, HTTP 1.1 ne vont pas vraiment dynamique. Il a juste quelques optimisation des astuces qui vous permettent de réutiliser des connexions, etc. À partir du navigateur web point de vue cela signifie que vos sites web se chargent plus rapidement, car vous n'avez qu'à négocier la connexion TCP à la fois pour ceux fichier HTML + 3 images (pour reprendre mon exemple) au lieu de 4 fois.
    • pourquoi ne peuvent-ils pas de le rendre dynamique . est-il un problème de programmation ou il ne peut pas être fait
    • L'inertie? Je ne peux pas vraiment lire leurs esprits. Il n'y a pas de raison technique pour les empêcher de soutien de la dynamique des connexions (étant donné que les gens sont slathering de l'état sur le dessus de HTTP assez facilement) et, en effet, le point de l'ensemble de Web Sockets est de fournir TCP-comme des connexions TCP (est une dynamique, orienté connexion protocole de bas niveau) via HTTP. C'est un mystère pour moi, personnellement, mais je ne suis pas un protocole de concepteur. Peut-être il ya quelque chose à propos de protocoles sans état, qui en vaut la peine, la douleur.
    InformationsquelleAutor JUST MY correct OPINION
  2. 12

    HTTP est sans état, ce qui signifie que lors de l'utilisation de HTTP le point final n'est pas de se "souvenir" des choses (comme qui vous êtes). Il n'a pas d'état. Ceci est en contraste à une application de bureau - si vous avez un formulaire et que vous passez à une autre forme, puis revenir en arrière, l'etat a été conservé (tant que vous n'avez pas de l'arrêt de l'application).

    Normalement, dans le but de maintenir l'état dans l'application web, on utilise des cookies.

    • u peut donner l'exemple de protocole qui se souviennent de l'état de sorte que je puisse comparer
    • href="http://en.wikipedia.org/wiki/Transmission_Control_Protocol" >TCP est un protocole qui conserve une partie de l'état.
    • bien que n'étant pas prévu por l'utilisation du réseau de la XYZModem de la famille de protocoles (XModem, YModem, et donc fils) sont stateful
    InformationsquelleAutor Oded
  3. 5

    Un protocole sans état ne nécessite pas le serveur afin de conserver des informations ou de l'état de chaque utilisateur pour la durée de plusieurs demandes. Par exemple, quand un serveur web est nécessaire pour personnaliser le contenu d'une page web pour un utilisateur, l'application web peut avoir pour suivre la progression de l'utilisateur à partir de la page à page.

    Une solution commune est l'utilisation de cookies HTTP. D'autres méthodes consistent à côté serveur séances, les variables cachées (lorsque la page en cours est une forme), et de l'URL-rewriting l'aide d'URI paramètres codés, par exemple, /index.le php?session_id=some_unique_session_code.

    ici

    InformationsquelleAutor Luis
  4. 4

    HTTP est appelé un protocole sans état, parce que chaque commande est exécutée de façon indépendante, sans aucune connaissance des commandes qui est venu avant lui.

    Cette lacune de HTTP est adressée dans un certain nombre de nouvelles technologies, y compris les cookies.

    • ActiveX, Java et Javascript ne pas tenir compte du fait que http est sans état, ils ont un effet de levier sur les cookies, la réécriture d'url, etc maintenir l'état
    InformationsquelleAutor ykombinator
  5. 3

    Quand on dit que quelque chose est apatride, cela signifie généralement que vous ne pouvez pas supposer que le serveur suit tout état entre les interactions.

    Par défaut, le protocole HTTP suppose un véritable serveur sans état (stateless. Chaque demande est traitée comme un indépendant demande.

    Dans la pratique, c'est fixed par certains serveurs (la plupart d'entre eux) à l'aide d'un cookie de suivi de la demande pour correspondre à un certain état sur le serveur avec un client spécifique. Cela fonctionne parce que la façon dont les cookies de travail (ils sont affichés sur le serveur à chaque nouvelle demande une fois qu'ils ont été définis sur le client).

    Fondamentalement un serveur qui n'est pas apatride est un obstacle à l'échelle. Vous devez vous assurer que vous acheminer toutes les demandes à partir d'un navigateur spécifique à la même instance ou de faire du backend de réplication des états. C'est généralement un facteur limitant lors de l'essayer à l'échelle d'une application.

    Il y a d'autres solutions pour garder une trace de l'etat (voir les rails de l'état chiffré cookie) mais, fondamentalement, si vous voulez grandir vous avez besoin de trouver un moyen d'éviter de suivi de l'état sur le serveur :).

    InformationsquelleAutor Mihai Toader