HTTP: quelles sont les relations entre pipelining, keep-alive et Server Sent Events?

Question

J'essaie de comprendre ce que sont les connexions HTTP en attente et les connexions HTTP persistantes, et d'essayer d'établir une connexion entre ces deux sujets et la technologie des événements Server Sent.

Pour autant que je comprends, connexion HTTP keep-alive est la valeur par défaut dans HTTP 1.1 façon d'utiliser TCP lorsque la connexion établie une fois TCP est utilisé pour envoyer plusieurs requêtes HTTP un par un. HTTP pipelining est la capacité du client à envoyer des requêtes au serveur alors que les réponses aux demandes précédentes ne sont pas encore reçus en utilisant la même connexion TCP, généralement pas utilisé comme un moyen par défaut dans les navigateurs.

Mes questions:

1) s'il est possible d'envoyer plusieurs demandes au serveur l'un après l'un à l'aide d'une connexion TCP - comment le client peut établir une distinction entre les réponses? Je suppose que le client utilise l'ordre FIFO d'envoyer des réponses par serveur?

2) Pourquoi les demandes non-idempotents telles que les requêtes POST ne doivent pas être pipelinées (selon wikipedia)?

3) Qu'en est-il des limites du serveur web: le nombre de connexions TCP ouvertes possibles limitées? Si oui, si un certain nombre de clients ont des connexions persistantes, les autres ne peuvent pas établir de connexions, ce qui peut entraîner un problème, n'est-ce pas?

4) Les événements sont envoyés du serveur en utilisant la connexion toujours en vie, mais, pour autant que je comprends, SSE n'utilisent pas pipelining. Au lieu de cela, ils parviennent à traiter plusieurs réponses à une demande, ou peuvent simplement envoyer une autre requête lorsque la réponse suivante avec l'événement est arrivée. Quelle est la bonne supposition?

5) Une connexion TCP signifie une prise? Une socket signifie une connexion TCP? La fermeture/ouverture de la prise signifie la fermeture/ouverture de la connexion TCP?

Answer 1

1. Oui, FIFO. TCP/IP garantit la livraison des données dans l'ordre, de sorte que les réponses ne peuvent pas arriver dans un ordre différent (si le serveur/proxy est bogué et envoie des réponses dans le mauvais ordre, alors vous êtes totalement foutu).

2. Je ne me souviens pas de raison par spécification HTTP. C'est peut-être juste de la prudence, car la mise en pipeline est mal implémentée dans certains serveurs proxy.

3. Spécification HTTP suggère 2 connexions par serveur, les navigateurs se sont installés sur 6-8 connexions par serveur, mais il n'y a pas de limite fixe. L'absence de connexions est un vrai problème pour Apache, et pour les situations de charge élevée, il est recommandé de désactiver KeepAlive dans Apache et d'utiliser un proxy (par exemple HAProxy) qui peut fournir des fonctionnalités Keep-Alive aux clients. L'avantage d'un proxy est qu'un proxy peut distribuer des connexions à plusieurs serveurs (aide à la mise à l'échelle) ou peut modifier le trafic (par exemple, gzip compresse tout même si le logiciel côté serveur ne le fait pas).

4. SSE ne repose pas sur Keep-Alive. Il n'utilise pas plusieurs réponses. Il s'agit d'une réponse unique qui prend une éternité à "télécharger", de sorte que la mise en pipeline ou le maintien en vie ne sont pas pertinents pour SSE. La connexion TCP/IP ne peut plus renvoyer de réponses lorsque la réponse SSE est envoyée.
   SSE maintiendra le serveur occupé tant que la connexion est ouverte (donc typicall tout le temps pour chaque utilisateur). C'est pourquoi il est préférable d'utiliser SSE avec Node.js/Tornado qui peut gérer des centaines de milliers de connexions plutôt que PHP/Apache qui est conçu pour quelques connexions à la fois.

5. Les sockets sont des interfaces de programmation pour les connexions TCP/IP. Généralement oui, une prise est une connexion.