HTTP, le protocole résidant sur le protocole TCP est sans état et le protocole IP est sans état. Mais comment pouvons-nous en conclure que TCP est sans état ou non?
Vous ne pouvez pas supposer qu'un protocole empilé est un état ou sans état, en regardant simplement les autres protocoles de la pile. Les protocoles avec état peuvent être construits sur des protocoles sans état et les protocoles sans état peuvent être construits sur des protocoles avec état. L'un des points clés d'un modèle de réseau en couches est que le type de relation que vous recherchez (état de tout protocole donné en fonction des protocoles utilisés conjointement) n'existe pas.
Le protocole TCP est un protocole avec état en raison de ce qu'il est, non pas parce qu'il est utilisé sur IP ou parce que HTTP est construit dessus. TCP maintient l'état sous la forme d'une taille de fenêtre (les noeuds finaux se disent combien de données ils sont prêts à recevoir) et l'ordre des paquets (les noeuds finaux doivent se confirmer quand ils reçoivent un paquet de l'autre) . Ce state (combien d'octets l'autre gars peut-il recevoir et s'il a ou non reçu le dernier paquet) permet-il à TCP d'être fiable, même sur des protocoles intrinsèquement non fiables. Par conséquent, TCP est un protocole avec état, car il a besoin que l'état soit utile.
Je voudrais également souligner que, bien que HTTP et HTTPS (en réalité, HTTP sur SSL/TLS) soient essentiellement sans état (chaque requête est une requête autonome valide selon le protocole), les applications construites sur HTTP et HTTPS ne sont pas compatibles. t nécessairement apatride. Par exemple, un site Web peut nécessiter que vous visitiez une page de connexion avant d'envoyer un message. Même si la demande à laquelle le client envoie un message est une demande autonome valide, l'application ne l'acceptera que si le client s'est authentifié auparavant. Cela signifie que l'application implémente l'état over HTTP.
En passant, l'état de HTTP peut être quelque peu déroutant, car plusieurs applications (sur une couche clairement différente couche OSI ) perdront leur état dans HTTP. Par exemple, si un utilisateur tente d'afficher un article de blog inexistant, l'application de blog peut renvoyer une réponse avec le code d'état 404, même si le fichier qui gère la recherche d'article de blog a été trouvé.
Zneak a raison de dire que vous pouvez utiliser n'importe quelle communication à des fins avec état, mais la question est de savoir si le protocole lui-même est avec état.
Wikipédia:
En informatique, un protocole sans état est un protocole de communication qui Traite chaque demande comme une transaction indépendante sans relation avec , De sorte que la communication est constituée de paires de Requêtes indépendantes. et les réponses. Un protocole sans état n'exige pas que le serveur conserve Des informations de session ou des statuts concernant chaque partenaire de communication pendant La durée de plusieurs demandes. En revanche, un protocole qui Requiert le maintien de l'état interne sur le serveur est appelé protocole Avec état.
Pour appliquer cette définition, nous devons d’abord comprendre ce qu’est une "demande".
Cela ferait de TCP un avec état protocole, puisque les parties doivent se rappeler dans quel état se trouve l'autre et quels octets il a. D'où le TCP state diagram .
Ici est une bonne explication:
Considérez le service téléphonique comme étant TCP et considérez votre relation avec les membres distants de la famille comme étant HTTP. Vous allez les contacter avec le service téléphonique. Chaque appel à eux constituerait une connexion TCP avec état. Cependant, vous ne restez pas constamment au téléphone avec eux, car vous allez vous déconnecter et les rappeler ultérieurement. Vous vous attendez certainement à ce qu'ils se souviennent de ce dont vous avez parlé lors du dernier appel. HTTP en soi ne fait pas cela, mais c’est plutôt une fonction du serveur Web qui maintient l’état de la conversation globale.
Pour répondre correctement à la question, nous avons besoin du concept de protocole sans état utilisé pour gérer les ressources externes avec état. La section 2.4 de http://laurel.datsi.fi.upm.es/_media/docencia/asignaturas/ws-modelingresources.pdf concerne un service mettant en œuvre un tel protocole:
Un service qui agit sur des ressources avec état peut être qualifié de «Sans état» s'il délègue la gestion de l'état À un autre composant, tel qu'une base de données ou un système de fichiers. ... Une conséquence De l'apatridie est que tout état dynamique nécessaire à l'exécution d'un échange de messages Doit être:
- explicitement dans le message de demande, que ce soit directement par valeur ou indirectement par référence, et/ou
- implicitement dans d'autres composants du système avec lesquels le service Web peut interagir.
Donc, le protocole http est sans état, si on considère que les fichiers servis, la base de données à laquelle on accède, etc. sont séparés de la mise en oeuvre du protocole lui-même. Un service (qui implémente un protocole) qui est sans état en relation avec les deux côtés pris ensemble peut ne pas paraître sans état de chaque côté, car l'autre côté peut porter un état.