Comment HTTP devient-il apatride?

HTTP serait apatride. Cela signifie qu'il n'a pas besoin de stocker des informations pour la transmission de données.

Mais HTTP utilise TCP, qui est orienté état.

Si tel est le cas, comment HTTP devient-il apatride?

HTTP ne se soucie pas et est indépendant de tous les protocoles de niveau inférieur utilisés pour se transporter, même s'il est lui-même sans état.

La technologie de transport peut être TCP, ou l'ancien SPX de Novell, ou SCTP, ou tout ce que vous pouvez imaginer, et HTTP fonctionnera toujours de la même manière. HTTP nécessite un streaming ou un protocole orienté connexion - et dépend des URL pouvant être résolues - mais peu importe comment cela est accompli.

C'est l'une des raisons pour lesquelles le modèle en couches ou la pile réseau existe: la couche application n'a pas besoin de se préoccuper des couches inférieures.

Ce n'est pas parce qu'un protocole de niveau inférieur est avec état que quelque chose en plus devient automatiquement avec état ou doit l'être.

HTTP lui-même est sans état. Cela signifie donc que les applications doivent implémenter une autre couche au-dessus de HTTP pour établir l'état. Cela se fait généralement avec des cookies de session.

"HTTP est sans état" signifie que chaque transaction HTTP (paire requête-réponse) peut être traitée indépendamment de tout état de la paire requête-réponse précédente.

Pour transporter la paire requête-réponse particulière, vous avez besoin d'un protocole capable de transporter un bloc arbitrairement grand là-bas et un bloc arbitrairement grand, et pour le faire sur une couche avec une taille de paquet limitée, TCP doit être avec état.

Mais au-delà des frontières des transactions, il n'y a pas d'État. Le client peut interrompre la connexion et en établir une nouvelle pour la prochaine demande. En fait, c'était la seule option dans les premières versions et cela fonctionne toujours comme ça si le client n'inclut pas l'en- Connection: keep-alivetête.

La demande suivante peut également être facilement gérée par un serveur différent et le client ne le saura jamais, car le serveur n'a pas besoin de maintenir un état (sauf si l'application ajoute son propre état au-dessus de HTTP, généralement sous forme de session; les complications qui en découlent dans l'équilibrage de charge est sa punition pour la construction d'un protocole avec état sur HTTP). Cela est utilisé dans l'équilibrage de la charge des serveurs occupés.

La nature "sans état" de HTTP signifie que sur cette couche, aucune information d'état n'est créée ou utilisée.

Vous pouvez le voir dans quelques cas, par exemple dans l'authentification HTTP, les informations d'identification sont envoyées avec chaque demande, et les connexions persistantes ne sont vraiment qu'une optimisation (c'est-à-dire que si j'envoie des informations d'identification, le serveur les oublie après la demande, même si elle laisse la connexion est ouverte).

En revanche, les mécanismes de connexion basés sur les cookies sont avec état, mais ne font pas partie de HTTP.

Vous devez le comprendre comme un ensemble de poupées russes (ou de boîtes si vous le souhaitez) chacune d'entre elles en portant une autre à l'intérieur, c'est grossièrement comment cela fonctionne: TCP porte HTTP "à l'intérieur" mais il s'en fiche ou de ses fonctionnalités.

Afin d'avoir une vue d'ensemble, je recommande de lire sur le modèle OSI car il le rend plus clair.

TCP se trouve quelques couches en dessous de HTTP dans le modèle OSI, chaque couche correspond en fait à un protocole différent.

Dans notre cas, HTTP se trouve dans les couches de présentation et d'application et TCP dans la couche de transport. Ou si vous utilisez le modèle TCP / IP, les protocoles TCP et IP se trouvent dans la couche Liaison réseau et HTTP dans les couches d'application et de présentation.