Long Polling vs WebSockets
Published: 2023-12-19 08:41:54

Les applications web ont été initialement conçues comme une architecture client-serveur. Les clients envoient une requête [HTTP/HTTPS](https://www.pubnub.com/guides/http/) au serveur désigné pour demander ou modifier un élément d'information. Par exemple, une application web de base suivra un flux similaire.

1.  Le client demande des données au serveur
    
2.  L'équilibreur de charge achemine les demandes vers le serveur approprié.
    
3.  Le serveur interroge la base de données concernée pour obtenir des données.
    
4.  La base de données renvoie les données demandées au serveur.
    
5.  Le serveur traite les données et les renvoie au client.
    

![ Client Server Communication](https://images.ctfassets.net/3prze68gbwl1/20KLOkp9uPZUiZtjp5VpWn/e4e6f4e48f9f0129766611ead3da8fa6/HTTP_Polling.png)

Une simple requête HTTP est la façon la plus courante de recevoir des informations du serveur. Mais que se passerait-il si vous vouliez récupérer les données dès qu'elles sont ajoutées à la base de données ou envoyées au serveur ? Avec une application web de base conçue comme une architecture client-serveur, vous devriez répéter ce processus encore et encore pour vérifier si de nouvelles informations ont été ajoutées à la base de données. Ce processus est connu sous le nom de [polling](https://en.wikipedia.org/wiki/Polling_(computer_science)) ou parfois appelé "polling court". L'inconvénient de cette approche est que la plupart du temps, les données ne sont pas renvoyées car le serveur n'a pas reçu de nouvelles informations. Résolvons ce problème et discutons des avantages et des inconvénients de l'interrogation longue et des Websockets.

Vue d'ensemble : Interrogation longue et WebSockets
---------------------------------------------------

#### Interrogation longue

L'interrogation longue est une [approche](https://www.pubnub.com/blog/http-long-polling/) dans laquelle le client envoie une requête API au serveur, mais au lieu de recevoir une réponse instantanée du serveur, il maintient la connexion HTTP. Le maintien de la connexion HTTP permet au serveur de répondre ultérieurement lorsque des données sont disponibles ou que le délai d'attente a été atteint. Après avoir reçu la réponse, le client envoie immédiatement la demande suivante.

Au lieu d'envoyer de nombreuses requêtes jusqu'à ce que le serveur reçoive de nouvelles informations, comme dans le cas du polling, le client ne doit envoyer qu'une seule requête au serveur pour obtenir les dernières informations. Après avoir reçu les données, le client peut lancer une nouvelle demande, en répétant ce processus aussi souvent que nécessaire.

Le flux d'une interrogation longue se présente comme suit :

1.  Le client envoie une requête HTTP au serveur pour lui demander des données
    
2.  Le serveur ne répond pas immédiatement avec les informations demandées, mais attend que de nouvelles informations soient disponibles.
    
3.  Lorsque de nouvelles données sont disponibles, le serveur répond avec de nouvelles informations.
    
4.  Le client reçoit ces données et envoie immédiatement une autre demande au serveur, ce qui relance le processus.
    

![](https://images.ctfassets.net/3prze68gbwl1/2FEB0j6VRCXSe28P5ruiSZ/a149b8fdbbdb77e5f3bb81aab9902dac/HTTP_Long_Polling.png)

#### Les WebSockets

Les WebSockets sont une [moderne](https://www.pubnub.com/learn/glossary/what-is-websocket/) moderne construite au-dessus de la pile [TCP/IP](https://www.pubnub.com/guides/tcp-ip/) d'un appareil. La seule relation avec le protocole HTTP est que les serveurs HTTP interprètent sa poignée de main pour établir une connexion. Il s'agit d'un protocole bidirectionnel, [full-duplex](https://en.wikipedia.org/wiki/Duplex_(telecommunications)) bidirectionnel, full-duplex et avec état, ce qui signifie que la connexion entre le client et le serveur persiste jusqu'à ce que l'une ou l'autre des parties décide d'y mettre fin.

Contrairement au polling long, qui n'est qu'une solution semi-duplex, le processus n'a pas besoin d'être répété après avoir reçu les dernières informations du serveur. La technologie WebSocket nous permet de maintenir la connexion en vie après le retour des nouvelles informations et d'effectuer des mises à jour bidirectionnelles. Le client peut renvoyer des informations au serveur et écouter d'autres informations dans la même requête.

Le flux d'une connexion WebSocket se présente comme suit :

1.  Le client initie une WebSocket en envoyant une demande qui contient un en-tête de mise à niveau pour changer le protocole de communication en protocole WebSocket
    
2.  Si le serveur peut établir une connexion et accepte les conditions du client, il envoie une réponse au client en accusant réception de la demande de poignée de main WebSocket.
    
3.  Lorsque le client reçoit une connexion WebSocket réussie, le client et le serveur peuvent commencer à envoyer des données dans les deux sens, ce qui permet une communication en temps réel.
    
4.  Le serveur ou le client décide de mettre fin à la connexion.
    

![](https://images.ctfassets.net/3prze68gbwl1/7LukONcMxY3FxnW3B4xkYI/0ffd1c3ffbbbffc614155918de821e9c/WebSocket-Diagram.png)

Quand choisir l'interrogation longue ou les WebSockets ?
--------------------------------------------------------

La question de savoir s'il convient d'utiliser le protocole Long Polling ou le protocole WebSocket fait l'objet d'un débat. Les deux ont leurs avantages et leurs limites et sont souvent utilisés à des fins différentes. Dans cette section, nous examinerons les principaux avantages du polling long et des WebSockets.

### Avantages du polling long par rapport aux WebSockets

Compatibilité : Le polling long est une technologie plus ancienne, utilisée davantage comme technique, ce qui en fait une option plus compatible que les WebSockets. Elle est construite sur la base de [XMLHttpRequest](https://en.wikipedia.org/wiki/XMLHttpRequest)ce qui la rend compatible avec un plus grand nombre de navigateurs web et de configurations de réseau.

Le réseau : Avec la technologie actuelle, les gens changent constamment de réseau, passant de la 3G à la LTE et au WiFi. Les WebSockets doivent être configurés pour s'adapter à un changement de connexion réseau. Cette configuration s'explique par le fait que la connexion doit être rétablie avec le serveur et qu'elle ne peut pas l'être une fois que le client a choisi de fermer la connexion. Avec le polling long, ce n'est pas un problème car il est configuré de telle sorte qu'après le temps prédéterminé (généralement 20 secondes), le client essaiera d'envoyer une autre requête rétablissant automatiquement une connexion avec le serveur et ne devant pas être traité dans un état d'erreur comme avec les WebSockets.

### Cas d'utilisation pour choisir l'interrogation longue plutôt que les WebSockets

Le polling long et les WebSockets sont généralement utilisés dans les cas où des mises à jour en temps réel sont nécessaires. Parmi les exemples, on peut citer le chat in-app, la tarification en temps réel, la géolocalisation et l'IdO.

L'interrogation longue présente des avantages par rapport aux WebSockets dans les cas d'utilisation avec des mises à jour en temps réel à faible fréquence. Ces avantages s'expliquent par le fait que l'interrogation longue est une solution semi-réelle dans laquelle la connexion doit être rétablie. En outre, comme indiqué plus haut, si les utilisateurs se trouvent dans un environnement à faible bande passante ou avec un fournisseur de réseau instable, le long polling est conçu pour rétablir la connexion sans complications supplémentaires. Cependant, la longue interrogation est une technologie/technique plus ancienne pour effectuer des mises à jour en temps réel. Par conséquent, elle est moins avancée et moins flexible que les WebSockets, mais elle prend mieux en charge les systèmes existants.

Quand choisir WebSockets ou long polling ?
------------------------------------------

### Avantages des WebSockets par rapport au polling long

Utilisation réduite des ressources : Les WebSockets maintiennent une connexion permanente entre le client et le serveur, ce qui réduit la charge de travail liée à l'établissement d'une nouvelle connexion pour chaque mise à jour en temps réel. La connexion constante réduit l'utilisation des ressources du côté du client et du serveur en ce qui concerne la largeur de bande du réseau, la mémoire et l'unité centrale pour réaliser la communication en temps réel.

Amélioration de l'évolutivité : En raison de la nature des WebSockets et de la communication bidirectionnelle entre le client et le serveur, le serveur peut envoyer des mises à jour au client en temps réel, ce qui réduit le nombre de requêtes envoyées. Les longues interrogations doivent rétablir une connexion chaque fois que le client a besoin de nouvelles informations. Au fur et à mesure que le nombre d'utilisateurs augmente, cela peut mettre à rude épreuve un serveur individuel.

Fonctionnalité avancée : Les WebSockets fournissent des canaux de communication en duplex intégral qui permettent un transfert de données en temps réel et une faible latence. L'interrogation longue est parfois considérée comme une solution en demi-temps réel et n'est pas idéale pour les scénarios à fort trafic ou les cas d'utilisation qui nécessitent des mises à jour en temps réel. Les fonctionnalités avancées permettent à l'utilisateur final de bénéficier d'une expérience plus fluide, car il recevra des mises à jour plus transparentes de son application.

### Cas d'utilisation pour lesquels il est préférable d'opter pour les WebSockets plutôt que pour le polling long

Les WebSockets conviennent mieux aux applications qui nécessitent des mises à jour à haute fréquence. Voici quelques exemples [les applications de chat](https://www.pubnub.com/solutions/chat/) ou [flux de données en temps réel](https://www.pubnub.com/solutions/data-streaming/). La connexion persistante permet une transmission efficace, ce qui rend l'expérience plus transparente pour l'utilisateur final. Les jeux multijoueurs et les outils de collaboration utilisent généralement les WebSockets. La communication bidirectionnelle permet au serveur de signaler le client, ce qui peut être utile pour recevoir des mises à jour en temps réel d'autres clients. Par exemple, le serveur peut signaler au client qu'il doit mettre à jour la position d'un autre joueur en fonction de ses actions.

En termes d'évolutivité, ou lorsque le nombre d'utilisateurs commence à augmenter, il est idéal de passer au protocole WebSocket. La pression exercée sur un serveur individuel deviendra trop importante si la base de clients utilise une technologie d'interrogation longue. L'envoi d'une requête toutes les 20 secondes est une mauvaise utilisation et entraînera un ralentissement du serveur au fil du temps, ce qui augmentera la [latence](https://www.pubnub.com/blog/latency-definition/) par requête.

Comment PubNub s'inscrit dans la conversation entre Long polling et WebSockets
------------------------------------------------------------------------------

Les WebSockets et le long polling offrent des solutions intéressantes pour créer des applications en temps réel. Cependant, de nombreuses autres considérations entrent en jeu lorsque l'on s'appuie sur ces cas d'utilisation. Avec la technologie actuelle, rien n'est aussi simple que d'envoyer un message ou des données d'un client à un autre. Le système en temps réel qu'un développeur tente de créer comporte presque toujours une fonctionnalité requise. Par exemple, dans un chat in-app, vous pouvez envisager des mises à jour de présence (signalisation) lorsque les utilisateurs sont en ligne, le filtrage des grossièretés, ou même des messages de lecture/délivrance.

Outre l'ajout de fonctionnalités spécifiques, des problèmes subsistent au niveau de l'infrastructure sous-jacente, tels que la complexité de la gestion de l'évolutivité. Lors de l'utilisation de technologies particulières telles que [Socket.io](https://www.pubnub.com/learn/glossary/what-is-socketio/) pour créer une WebSocket, les développeurs devront toujours s'occuper de la création dynamique de serveurs dans le monde entier, derrière un équilibreur de charge pour gérer l'utilisation de chaque serveur. Ces problèmes deviennent de plus en plus complexes au fur et à mesure que l'on passe à l'échelle supérieure.

Les [API de données en temps réel](https://www.pubnub.com/learn/glossary/what-is-real-time-data/) de PubNub permettent aux utilisateurs de développer des [applications](https://www.pubnub.com/guides/event-driven-architecture/) puissantes, [axées sur les événements](https://www.pubnub.com/guides/event-driven-architecture/) , afin de faciliter la communication en temps réel sur tous les appareils, quel que soit le cas d'utilisation spécifique. PubNub offre une variété de SDK, tels qu'un [SDK JavaScript](https://www.pubnub.com/docs/sdks/javascript) pour les applications web et un [SDK C-Core](https://www.pubnub.com/docs/sdks/c-core) pour les applications IoT, afin d'assurer une intégration transparente avec l'appareil choisi. Avec PubNub, vous n'avez pas à vous soucier de la sélection d'une alternative appropriée ou des complexités sous-jacentes de la mise en œuvre d'une solution en temps réel.

Maintenant que vous savez quand utiliser le long polling par rapport aux WebSockets [inscrivez-vous pour un essai gratuit](https://admin.pubnub.com/#/register) ou [planifiez une démo](https://www.pubnub.com/company/contact-sales/) pour explorer ce que vous pouvez construire avec PubNub.

Comment PubNub peut-il vous aider ?
===================================

Cet article a été publié à l'origine sur [PubNub.com](https://pubnub.com/blog/long-polling-vs-websockets/)

Notre plateforme aide les développeurs à construire, fournir et gérer l'interactivité en temps réel pour les applications web, les applications mobiles et les appareils IoT.

La base de notre plateforme est le réseau de messagerie en temps réel le plus grand et le plus évolutif de l'industrie. Avec plus de 15 points de présence dans le monde, 800 millions d'utilisateurs actifs mensuels et une fiabilité de 99,999 %, vous n'aurez jamais à vous soucier des pannes, des limites de concurrence ou des problèmes de latence causés par les pics de trafic.

Découvrez PubNub
----------------

Découvrez le [Live Tour](https://www.pubnub.com/tour/introduction/) pour comprendre les concepts essentiels de chaque application alimentée par PubNub en moins de 5 minutes.

S'installer
-----------

Créez un [compte PubNub](https://admin.pubnub.com/signup/) pour un accès immédiat et gratuit aux clés PubNub.

Commencer
---------

La [documentation PubNub](https://www.pubnub.com/docs) vous permettra de démarrer, quel que soit votre cas d'utilisation ou votre [SDK](https://www.pubnub.com/docs).