Comment HTTP devient-il apatride?

26

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?

networking tcp web

— Fourmis
source

6

Comment est-ce que ce n'est pas un doublon 5 ans après le lancement de Super User?

— Peter Mortensen

Parce que la plupart des dupes sont sur StackOverflow? Je suis juste en train de deviner.

— trysis

8

Tout simplement parce qu'il passe à travers des câbles (entre autres), n'en fait pas non plus un protocole électrique

— Hagen von Eitzen

stackoverflow.com/questions/13200152/…

— Ali786

42

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.

— LawrenceC
source

1

Le routage se produit au niveau tcp / ip.

— Fiasco Labs

3

Cette image l'explique bien. vichargrave.com/wp-content/uploads/2013/01/…

— JakeGould

2

Par coïncidence, le fait que HTTP ignore l'état complet de la connexion sous-jacente (qui sera presque toujours TCP) est l'une des principales lacunes de performances que diverses approches HTTP2 tentent de résoudre.

— skolima

2

@Fiasco: À proprement parler, le routage se produit au niveau IP. Le routage est basé sur les adresses Internet, aucune information de la couche TCP n'est utilisée dans le routage de base.

— RedGrittyBrick

1

@skolima: d'un autre côté, l'apatridie est la raison pour laquelle HTTP est le protocole le plus évolutif et le plus fiable largement utilisé. HTTP a toujours été explicitement conçu pour l'évolutivité plutôt que pour les performances (oui, c'est différent), donc si vous pensez que vous avez besoin d'une latence faible et dure, vous utilisez soit le mauvais protocole, soit vous l'utilisez incorrectement. Bien que HTTP2 ait l'intention d'améliorer les performances, il le fait d'une manière qui reste fidèle à l'apatridie. Lorsqu'il était utilisé pour ce à quoi il était destiné, je n'avais jamais vu l'apatridie être le goulot d'étranglement d'une application HTTP bien conçue.

— Lie Ryan

10

"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.

— Jan Hudec
source

can also easily be handled by different server and the client will never knowBien que techniquement vrai, cela est trompeur car de nombreuses applications Web utilisent des sessions persistantes, nécessitant un équilibreur de charge pour acheminer les demandes futures de la même session de navigation vers le même serveur. Du point de vue HTTP, les sessions ne sont pas pertinentes, mais votre dernière phrase implique que l'expérience de l'utilisateur final ne sera pas affectée, ce qui serait faux avec des sessions persistantes.

— Brandon

1

@Brandon: De telles applications construisent un protocole avec état au-dessus de HTTP et c'est leur punition!

— Jan Hudec

@Brandon: de nombreux serveurs à charge équilibrée, tels que gmail, n'envoient pas de demandes au même serveur. Au lieu de cela, la session est stockée dans une base de données partagée à laquelle tous les serveurs du cluster peuvent accéder. L'état n'est donc pas géré par le serveur mais par la base de données.

— slebetman

@slebetman: Oui, peu importe. HTTP lui-même n'a pas un tel état, donc pour HTTP c'est simple. Si l'application ajoute un état qui lui est propre, c'est son combat.

— Jan Hudec

Bon, je n'ai pas tout dit. J'en ai dit. Personnellement, je préfère éviter les sessions collantes et, si possible, éviter complètement les sessions. Néanmoins, il existe des logiciels qui ne répondent pas à l'idéal de tout le monde.

— Brandon

2

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.

— Simon Richter
source

1

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.

— runlevel0
source

1

Le problème avec le modèle OSI est qu'il est désormais théorique (il y a eu de réelles tentatives de mise en œuvre, mais elles ont échoué sur le marché en raison de leur complexité). En réalité, il n'y a pas de couches entre TCP et HTTP. De plus, la couche de présentation serait HTML, pas HTTP.

— MSalters

Dans le modèle TCP / IP, TCP ne vit pas dans la couche réseau. Il vit dans la couche de transport au-dessus d'IP, qui est dans le réseau plus tard. Le premier hit google pour "modèle TCP" le démontre: technet.microsoft.com/en-us/library/cc786900(v=ws.10).aspx

— Brandon

@MSalters: TLS n'est-il pas une couche?

— grawity

1

@MSalters: Vous vous rendez compte que HTTPS est simplement le nom donné par HTTP tunnelé par TLS? En tant que tel, TLS est une couche sous HTTP et en plus du combo TCP et TLS / SSL + HTTP est appelé HTTPS.

— slebetman

1

En outre, il existe un autre nouveau nom pour le combo TLS / HTTP. Si le TLS qui transporte le trafic HTTP implémente le multiplexage de socket / flux virtuel, il s'appelle SPDY (mais l'URL dans votre navigateur est toujours HTTPS).

— slebetman